Subject: Volunteer scribe

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 14 Jul 2003 10:04:15 +0200

If someone feel like volunteering as scribe for the meeting this 
afternoon, please let me know.

If someone also feel like 'reporting' this on the jabber session, also 
please let me know.

Best regards,

- - kurtis -

---

From: Geoff Huston <[email-masked]>
Date: Tue, 15 Jul 2003 03:02:32 +1000

Multi 6 Monday 1300 - 1500

Agenda - overview of submitted drafts

Agenda bashing: none

- - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min

         For background:
         draft-moskowitz-hip-arch-03.txt
         draft-moskowitz-hip-07.txt

   Host Identity Protocol (HIP) has been around for some time. New 
namespace protocol with a history of around 4 years. Today sockets are 
bound to IP addresses, forcing the IP address into a dual role of endpoint 
identifiers and forwarding identifiers. HIP introduces a new namespace 
between the network and transport layers. The sockets are bound to host 
identifiers that are dynamically bound to IP addresses. Hosts are 
identified with public keys, not IP addresses, and apps see only the HIP 
identifiers. The apps need not change is the assertion. Hosts can easily 
have both IPv4 and IPv6 addresses, and the assertion is that end-host 
multi-homing and mobility is trivial. HIP Proxies are described as a kind 
of a hack. HIP may be a part of the multi-homing architecture. 4 
Interoperating implementations, intend to send the drafts to the IESG, and 
more work is needed on mobility and multi-homings with NAT traversal. HIP 
is not a working group but is progressing in the background. HIP is a 
multi-address solution with end-to-end. It solves only one aspect of 
multi6, and has no specific solns for address selection or TE

Matsataka Ohta: You said "HIP Proxy" - do you support multi-proxies for backup
Pekka Nikkander: There is no easy way to have multi HIP proxies in some 
situations, and it does represent a single point of failure

- - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min

   SCTP approach - endpoints have multiple addresses, where each IP address 
represents a path to a particular endpoint. SCTP is not aware of the level 
of path distinguishing - it would be good if they were, but this is not a 
known property. SCTP can detect path up/down. (Example of host-to-host with 
2 addrs on each host). Multi-homing open up new horizons for SCTP: add and 
remove ip addresses dynamically to the endpoint, that can support mobility. 
Functionality at the endpoint is asserted to be superior to network 
functions in this regards. It does imply that the host requires a routing 
table - not a big deal for a host is the claim. But a big table is required 
for a system with a large connection load. How to maintain the routing 
table is claimed to be implementation dependant (pre-configured or caching 
the INIT). NATs are in the draft because they wanted to warn everyone how 
bad NATs really are! NAT cases for SCTP generates problems that do no 
appear to have straightforward solutions. From the transport level SCTP is 
claimed to be a 'should work' solution.

Lixia Zhang: How about UDP?
Lode Coene: its the same problem, with the application having to undertake 
the selection.
Erik Nordmark: what algorithms have been used in SCTP work to select source 
and destinations? Any write ups of this work?
Lode Coene: none known to me.

- - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min

   Proposes to use MIPv6 to the multi-homing (mh) problem. Example in 
presentation of recovery from current to backup path (Using alternate 
addresses) Both paths have to be bound and identified _before_ an outage 
using binding update messages. The alternate binding will use the Home 
Address Option. Since MIP already needs the exchange of messages along each 
path, this exchange can be used as a path keepalive. The lifetime of the 
binding is limited to 7 minutes, and this is considered to be very short. 
Possible solutions are proposed

Matsataka Ohta: IPv6 has large timeouts for various purposes. If your 
proposal to have the same property so that the new address can be used quickly.
Marcelo Bagnulo: this issue is to build a path outage detection, and we are 
proposed to use the packet exchange for this purpose. The idea is to use 
the same packet format, but change the timing.

- - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min

   General introduction on IP and IPv6. References 8+8 Locator and endpoint 
I-D. The proposal is to let end systems have multiple addresses. Let the 
other end select the 'best' address. (The host addresses are part of 
multiple upstream aggregates). The general architecture proposed is to let 
the network inform the host about state to allow the hosts to undertake 
address selection. When should a host attempt alternate addresses? Proposed 
in response to ICMP, routing change, timeouts (TCP only). Proposed that 
applications have an IP (and UDP)-defined packet timeout to trigger 
alternate address use. For very short timeouts it is proposed to send 
multi-copies of the packet with multiple addresses. e-2-e mh and IP 
mobility are similar, although there is mobility timing at the IP layer. 
e2emh has been implemented and running on NetBSD with LIN6, with 
modifications to the stack as described in the presentation. The design 
framework proposed is to make everything optional. Exercising no options is 
single-homed. Use 8+8 Locator/Id separation, with packet reception and 
connection identification determined by the ID. Application to mobility is 
also described. Multiple addresses are supplied to the peer by reverse 
query of DNS using an ID query key followed by a forward query, or carry in 
the TCP header or a new DNS query type. e2e approach is proposed as 
scaleable architecture. MH and mobility are related, and the approach uses 
8+8 separation

Pekka Nikkander: You did not mention security issues in your presentation - 
is this to be addressed later on, or do you have comments now?
Matasaka Ohta: The current Internet is weakly secure. Cookie-based security 
for locator change give only the same level of security.

Peter Werny: What is required in the DNS for this to work?
Matasaka Ohta:  this is different from current V6, as it only uses the 
identifier 8 bytes. In DNS we look up locators of location agents using ID 
of hosts.
Peter Werny: Every host has to have a DNS entry?
Matasaka Ohta:If there is no DNS and not TCP then you are single-homed, and 
you cannot use this mechanisms.
PW: Your draft has no mention of DNS update
Matasaka Ohta: Location is not in the DNS - just the location agent.
Erik Nordmark: Are you assuming a structure for the identifiers?
Matasaka Ohta: It should be reverse lookup-able. Its better to have 
hierarchy in the identifier space, but you can do without hierarchy if you 
use TCP instead of the DNS to pass the multiple addresses

- - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min

   Each end application can determine a route to use. Applications select a 
route using a selection of a specific source and destination address pair. 
An end application can select a path without full route information is the 
claim. The attributes are claimed to include redundancy and load balancing. 
Modifications to hosts, routers and routing protocols is needed. Site exit 
router selection using source address routing enables redundancy, load 
sharing with multiple paths. Some mechanisms is needed for 'proper' source 
address selection. Transport layer survivability could be an SCTP mechanism 
or other.

- - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min

   Socket API extensions. Propose to use application layer, rather than the 
network. Uses 8+8 model. The API is for manipulation of multiple addresses 
in the application. LIN6 is based on the 8+8 model. LIN6 does address 
acquisition, notification, registration in a secure manner. Hosts identify 
their peer and themselves using only the identifier part. e2e-mh is seen to 
be an application of the LIN6 model. The trigger to switch locators is seen 
to be ICMP-based using host unreachable. APIs need to manipulate locators, 
to make a multi-locator-ready socket, allow API to change locators on the 
fly, and acquire remote locators. The details of API changes described, in 
socket(), getaddrinfo() and getsockopt()/setsocketopt(). APIs are intended 
for active mh applications. UDP requires application support. Future work 
is to put support in to the TCP level, so that no changes are required for 
API for TCP.

- - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min

   All hosts should have full default-free routing table. This allows 
selector in host to make optimal locator choice, and know when locator is 
unreachable. source address selection for ingress filtering only. The peer 
will not use the source address - it will make its own selection of a 
locator for the peer. Extended example of policy control and filtering.

Pekka Savola: Both of these drafts have been obsoleted
Matasaka Ohta: not a problem!
? (MCI): IF an NLA gets address space from 2 TLAs which does it use?
MO: If gets 2 addresses, as does its customers. The number of prefixes 
cascades down.
? MCI): Scaleaility?
MO: yes, and NLA should be no more than triply homed.
Iljitsch van Beijnum: Why is the information in the routing table superior 
to information you can obtain from the other end?
MO: This does not have scaleability problems if you limit connectivity. 
This is a connectionless system where a host has no information about the 
other end, and the routing table is local information you can use.
Iljitsch van Beijnum: ok, but I disagree with this

- - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min

   Solution for traffic engineering for mh need sites in a multi-address 
environment. Each host has 1 address per upstream provider. Noted that 
choosing a source address implies choosing a provider (assuming providers 
perform source address filtering). Which source? A host has no information 
about which provider to use to reach a destination. Propose to use a 
dedicated agent (server). A host will query the server with a destination 
address, and the server responds with the source to use. The burden of 
selecting the source address is aggregated to a dedicated server. Note it 
gives only a hint to the host about what address to use. NAROS is not 
intended to preserve flows across address changes. SCTP or HIP could be 
used to preserve flows. The server could be anycast, or undertaken without 
provider interaction. The host / server protocol is a query response packet 
exchange. Where multiple choices exist, multiple parameters can be used to 
make the selection.

Pekka Nikkander: is this a new protocol, or, perhaps, ICMP
Cedric de Launois: No particular protocol - it could be ICMP
PN: There are security issues here, like secure neighbor discovery
Michael Richardson: Takes the example and adds further connections, and 
then adds a policy question about 'acceptable traffic' policies. Can NAROS 
deal with this>
CdL: A lot of requirements could be placed in the NAROS server and it could 
be aware of those kind of requirements.
Matsataka Ohta: Anycast does not include increased robustness for server 
failure. A NAROS server crash will not bring down a anycast route. Also 300 
seconds is too large a value.

- - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David
    Kessens, 20 min

   Simple multihoming experiment. A problem statement in a bounded example 
environment. A simple network is a single link where multiple hosts see 
multiple boundary routers where each router is connected to distinct 
upstreams. Addresses from providers are mapped to all the hosts. Asserted 
that this is not uncommon in V4 and that the common solution is to NAT the 
local net and allow the NAT to 'rehome' to each outbound. The consequence 
is flow breakage across the rehoming of the NAT. The bounds are that the 
ISPS do not exchange information, there are provider addresses with an 
assigned prefix per provider. Hosts configure an address with each prefix. 
Need to resolve host choice of egress router selection (as a function of 
the source address)

Erik Nordmark:  There are people talking about movement detection, and this 
gets all routers to advertise all prefixes
Christian Huitema: Thats not incompatible - several routers can advertise 
the same information, provided that the information is equivalent, and the 
routers can handle all such packets.
Pekka Savola: please clarify the applicability. This is only the case where 
hosts are directly connected to all egress routers.
Christian: this is a common case.
MO: You don't need tunnels in a single link network. In a multi-link 
network you need tunnels.
CH: This does nothing for MTU discovery. For single link there is a very 
simple solution and this can be extended for multi-links
MO: Ands I'm saying its impossible
CH: fine!

   No need for tunnels in a single link network, and the routers can pass 
off to each other in the event of dynamic failure. The assertion is that in 
a single link network this requirement can be easily met. Dead exist 
routers or dead ISP require some consideration. If the exit router knows 
that the path is dead it can send a poison advertisement of the prefix. The 
real issue with this form of mh is a very soft definition of 'broken' where 
the link may be up, but the path to the remote end point may be unuseable. 
This kind of problem is an e2e detection issue. Hosts may need to keep 
track of connections and track quality. If you know an ingress path is dead 
do you need to update the DNS to remove the dead prefix from your host 
entry? Of course you may not know and in this case your peer will need to 
work out what address to use. Maintenance of TCP connections is an issue. 
MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he 
connection will fail, and needs to be reestablished. Exit / entrance 
selection is also an issue. One approach is to only advertise the preferred 
address in the DNS if you have a primary / backup scenario. And in a 1 + 1 
scenario, then advertise both. On the outgoing the solution may be a local 
server to assist, or to document preferences in the routers. We appear to 
be able to design solutions that require changes to the IPv6 standards, do 
no require address rewriting at exit points, but it could work,

Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need 
to change both ends?
CH: The support for the connected node in MIPv6 is supposed to be 
implemented everywhere.
PN: You need to change the address in both ends.
CH: The time appears to be around 5 or 6 minutes.
PN: If you are going to change the code at both ends then you should try 
HIP in your experiments as well.
CH: You are free to experiment with HIP
Fujikawa: It seems like an application cannot select different path from 
other applications in a host?
CH: No, not so. The host has several IPv6 addresses. An application that 
want to do path selection can bind to a source address and connect to a 
destination and select a path.
Matasaka Ohta: It is stupid to keep using a complication MIPv6
CH: Complexity is management of the Home agent and security functions to 
certain classes of attacks and you will need  to have some form of security 
in any case.
Matasaka Ohta: This only works in a single link case.

   In a larger site the problem is ingress filtering, because its harder to 
do source-based routing. The simple solution is to work with the ISP to 
lift source filters. Even larger sites have their own PI space and AS#.

IvB: Disable ingress filtering can be down for the local upstream, but the 
chain may extend upward
CH: ingress filtering in the middle of the Internet is a bad idea
MO: what will you do with a large site?
CH: lets call them medium
Bob Hinden: ISPs would be more amenable to break ingress filtering than 
route specifics.
?: Ingress filtering should not be an issues.
Mat Ford: Define a large site?
CH: establish a registry relationship!

- - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min

   Claimed that this is not the best solution in all cases, but better than 
some others. Need to avoid the routing mess of advertising more specific 
and need solutions soon. Approach to use the AS number to create PI space 
for larger enterprises. e.g. 2000:<ASN>::/32. Issues about 16 / 32 bit AS 
numbers, and a claim that 32 bit AS numbers would indicate a RIR policy 
failure.

Moshens VC(?): How do you get uniqueness of the prefix
PS: This is 2000 - it won't collide!
MO: There are already too many ASes deployed
Geoff Huston: You are assuming AS remain at 16bits. What happens when AS 
drain in 2011. and we move to 32 bit AS numbers? This is a relatively short 
term solution with a visible drop dead point - right?
PV: yes.
?: This is good solution
PV: an appendix shows how to deal with 32 bit AS numbers, but I don't lkike 
this solution.
Tim Chen: This cuts out the smaller sites that do not have ASs.
Randy Bush: Why reluctant to give out ASes to routing domains who's policy 
domains are different from their neighbors?

- - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum,
    15 min

   Geographical aggregation. Admitted that topology is not correlated to 
geography, and even if the geo part doesn't work there are still some savings.

MH: This gives little actual aggregation
?: Asymmetrical routes break in your model
IvB: Routing is asymmetrical in multi-homing in any case.
Tony Hain: Aggregatibility is the question. The concept appears fine, but 
you are making assumptions about aggregation boundaries here.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 14 Jul 2003 23:34:42 +0200

>   Geographical aggregation. Admitted that topology is not correlated 
> to geography, and even if the geo part doesn't work there are still 
> some savings.

I did say a little more than that... I'll put the slides up at 
http://www.muada.com/ietf57-isp-int.pdf as soon as I'm online again 
(which should be around the time this message gets out). In the mean 
time:

- Goal is enabling multihoming ASAP. This is a short term solution.
- It works by distributing the global routing table over the routers 
within an (ISP) network rather than giving every router a full copy as 
is done today.
- This would lead to scenic routing but the geo aspect repairs this.
- Unless there is insufficient interconnection between networks, then 
aggregation must be broken.
- Geographic aggregates are internal to each network and not annouced 
externally.
- Correlation between topology and geography is less than 1, but also 
more than 0 and even without geography there are still some savings.
- No real downsides: RIRs must implement geographic address allocation, 
ISPs can implement this (or not) at their convenience.

> IvB: Routing is asymmetrical in multi-homing in any case.

What I said was: today it's assymmetrical anyway (re hot potato 
routing) and when both sides do geo aggregation it is still 
assymmetrical, when one end is geo multihomed and the other isn't it's 
symmetrical. But read the draft as it has a section on exactly this 
issue from an ISP traffic distribution viewpoint.

> Tony Hain: Aggregatibility is the question. The concept appears fine, 
> but you are making assumptions about aggregation boundaries here.

Short answer: you can make your own boundaries or this can even work 
with your (Tony's) geographic addressing plan. Long answer: no time for 
the long answer...

---

From: Geoff Huston <[email-masked]>
Date: Tue, 15 Jul 2003 21:26:32 +1000

Thank you to Iljitsch  and Christian for your corrections.

Heres (what I hope to be the final version of) the minutes of Monday's multi6 wg minutes

Geoff

----------------------

Agenda bashing: none

        For background:

  Host Identity Protocol (HIP) has been around for some time. New
  namespace protocol with a history of around 4 years. Today sockets are
  bound to IP addresses, forcing the IP address into a dual role of
  endpoint identifiers and forwarding identifiers. HIP introduces a new
  namespace between the network and transport layers. The sockets are
  bound to host identifiers that are dynamically bound to IP addresses.
  Hosts are identified with public keys, not IP addresses, and apps see
  only the HIP identifiers. The apps need not change is the assertion.
  Hosts can easily have both IPv4 and IPv6 addresses, and the assertion is
  that end-host multi-homing and mobility is trivial. HIP Proxies are
  described as a kind of a hack. HIP may be a part of the multi-homing
  architecture. 4 Interoperating implementations, intend to send the
  drafts to the IESG, and more work is needed on mobility and multi-
  homing with NAT traversal. HIP is not a working group but is progressing
  in the background. HIP is a multi-address solution with end- to-end. It
  solves only one aspect of multi6, and has no specific solutions for
  address selection or TE

Matsataka Ohta: You said "HIP Proxy" - do you support multi-proxies for
  backup
Pekka Nikkander: There is no easy way to have multi HIP proxies in some
  situations, and it does represent a single point of failure

  SCTP approach - endpoints have multiple addresses, where each IP address
  represents a path to a particular endpoint. SCTP is not aware of the
  level of path distinguishing - it would be good if they were, but this
  is not a known property. SCTP can detect path up/down. (Example of host-
  to-host with 2 addresses on each host). Multi-homing open up new
  horizons for SCTP: add and remove IP addresses dynamically to the
  endpoint, that can support mobility. Functionality at the endpoint is
  asserted to be superior to network functions in this regards. It does
  imply that the host requires a routing table - not a big deal for a host
  is the claim. But a big table is required for a system with a large
  connection load. How to maintain the routing table is claimed to be
  implementation dependant (pre-configured or caching the INIT). NATs are
  in the draft because they wanted to warn everyone how bad NATs really
  are! NAT cases for SCTP generates problems that do no appear to have
  straightforward solutions. From the transport level SCTP is claimed to
  be a 'should work' solution.

Lixia Zhang: How about UDP?
Lode Coene: its the same problem, with the application having to undertake
  the selection.
Erik Nordmark: what algorithms have been used in SCTP work to select
  source and destinations? Any write ups of this work?
Lode Coene: none known to me.

  Proposes to use MIPv6 to the multi-homing (mh) problem. Example in
  presentation of recovery from current to backup path (Using alternate
  addresses) Both paths have to be bound and identified _before_ an outage
  using binding update messages. The alternate binding will use the Home
  Address Option. Since MIP already needs the exchange of messages along
  each path, this exchange can be used as a path keepalive. The lifetime
  of the binding is limited to 7 minutes, and this is considered to be
  very short. Possible solutions are proposed

Matsataka Ohta: IPv6 has large timeouts for various purposes. If your
  proposal to have the same property so that the new address can be used
  quickly.
Marcelo Bagnulo: this issue is to build a path outage detection, and we
  are proposed to use the packet exchange for this purpose. The idea is to
  use the same packet format, but change the timing.

  General introduction on IP and IPv6. References 8+8 Locator and endpoint
  I-D. The proposal is to let end systems have multiple addresses. Let the
  other end select the 'best' address. (The host addresses are part of
  multiple upstream aggregates). The general architecture proposed is to
  let the network inform the host about state to allow the hosts to
  undertake address selection. When should a host attempt alternate
  addresses? Proposed in response to ICMP, routing change, timeouts (TCP
  only). Proposed that applications have an IP (and UDP)-defined packet
  timeout to trigger alternate address use. For very short timeouts it is
  proposed to send multi-copies of the packet with multiple addresses.
  e-2-e mh and IP mobility are similar, although there is mobility timing
  at the IP layer. e2emh has been implemented and running on NetBSD with
  LIN6, with modifications to the stack as described in the presentation.
  The design framework proposed is to make everything optional. Exercising
  no options is single-homed. Use 8+8 Locator/Id separation, with packet
  reception and connection identification determined by the ID.
  Application to mobility is also described. Multiple addresses are
  supplied to the peer by reverse query of DNS using an ID query key
  followed by a forward query, or carry in the TCP header or a new DNS
  query type. e2e approach is proposed as scaleable architecture. MH and
  mobility are related, and the approach uses 8+8 separation
  
Pekka Nikkander: You did not mention security issues in your presentation
  - is this to be addressed later on, or do you have comments now?
Matasaka Ohta: The current Internet is weakly secure. Cookie-based
  security for locator change give only the same level of security.
Peter Werny: What is required in the DNS for this to work?
Matasaka Ohta:  this is different from current V6, as it only uses the
  identifier 8 bytes. In DNS we look up locators of location agents using
  ID of hosts.
Peter Werny: Every host has to have a DNS entry?
Matasaka Ohta:If there is no DNS and not TCP then you are single-homed,
  and you cannot use this mechanisms.
PW: Your draft has no mention of DNS update
Matasaka Ohta: Location is not in the DNS - just the location agent.
Erik Nordmark: Are you assuming a structure for the identifiers?
Matasaka Ohta: It should be reverse lookup-able. Its better to have
  hierarchy in the identifier space, but you can do without hierarchy if
  you use TCP instead of the DNS to pass the multiple addresses

  Each end application can determine a route to use. Applications select a
  route using a selection of a specific source and destination address
  pair. An end application can select a path without full route
  information is the claim. The attributes are claimed to include
  redundancy and load balancing. Modifications to hosts, routers and
  routing protocols is needed. Site exit router selection using source
  address routing enables redundancy, load sharing with multiple paths.
  Some mechanisms is needed for 'proper' source address selection.
  Transport layer survivability could be an SCTP mechanism or other.

  Socket API extensions. Propose to use application layer, rather than the
  network. Uses 8+8 model. The API is for manipulation of multiple
  addresses in the application. LIN6 is based on the 8+8 model. LIN6 does
  address acquisition, notification, registration in a secure manner.
  Hosts identify their peer and themselves using only the identifier part.
  e2e-mh is seen to be an application of the LIN6 model. The trigger to
  switch locators is seen to be ICMP-based using host unreachable. APIs
  need to manipulate locators, to make a multi-locator-ready socket, allow
  API to change locators on the fly, and acquire remote locators. The
  details of API changes described, in socket(), getaddrinfo() and
  getsockopt()/setsocketopt(). APIs are intended for active mh
  applications. UDP requires application support. Future work is to put
  support in to the TCP level, so that no changes are required for API for
  TCP.

  All hosts should have full default-free routing table. This allows
  selector in host to make optimal locator choice, and know when locator
  is unreachable. source address selection for ingress filtering only. The
  peer will not use the source address - it will make its own selection of
  a locator for the peer. Extended example of policy control and
  filtering.

? MCI): Scaleability?
  This is a connectionless system where a host has no information about
  the other end, and the routing table is local information you can use.

  Solution for traffic engineering for mh need sites in a multi-address
  environment. Each host has 1 address per upstream provider. Noted that
  choosing a source address implies choosing a provider (assuming
  providers perform source address filtering). Which source? A host has no
  information about which provider to use to reach a destination. Propose
  to use a dedicated agent (server). A host will query the server with a
  destination address, and the server responds with the source to use. The
  burden of selecting the source address is aggregated to a dedicated
  server. Note it gives only a hint to the host about what address to use.
  NAROS is not intended to preserve flows across address changes. SCTP or
  HIP could be used to preserve flows. The server could be anycast, or
  undertaken without provider interaction. The host / server protocol is a
  query response packet exchange. Where multiple choices exist, multiple
  parameters can be used to make the selection.
  
Pekka Nikkander: is this a new protocol, or, perhaps, ICMP
Cedric de Launois: No particular protocol - it could be ICMP
PN: There are security issues here, like secure neighbor discovery
Michael Richardson: Takes the example and adds further connections, and
  then adds a policy question about 'acceptable traffic' policies. Can
  NAROS deal with this>
CdL: A lot of requirements could be placed in the NAROS server and it
  could be aware of those kind of requirements.
Matsataka Ohta: Anycast does not include increased robustness for server
  failure. A NAROS server crash will not bring down a anycast route. Also
  300 seconds is too large a value.

- - draft-huitema-multi6-hosts-02.txt, Christian Huitema & David
   Kessens, 20 min

  Simple multihoming experiment. A problem statement in a bounded example
  environment. A simple network is a single link where multiple hosts see
  multiple boundary routers where each router is connected to distinct
  upstreams. Addresses from providers are mapped to all the hosts.
  Asserted that this is not uncommon in V4 and that the common solution is
  to NAT the local net and allow the NAT to 'rehome' to each outbound. The
  consequence is flow breakage across the rehoming of the NAT. The bounds
  are that the ISPS do not exchange information, there are provider
  addresses with an assigned prefix per provider. Hosts configure an
  address with each prefix. Need to resolve host choice of egress router
  selection (as a function of the source address)

Erik Nordmark:  There are people talking about movement detection, and
  this gets all routers to advertise all prefixes
Christian Huitema: That's not incompatible - several routers can advertise
  the same information, provided that the information is equivalent, and
  the routers can handle all such packets.
Pekka Savola: please clarify the applicability. This is only the case
  where hosts are directly connected to all egress routers.
Christian: this is a common case.
MO: You don't need tunnels in a single link network. In a multi-link
  network you need tunnels.
CH: This does nothing for MTU discovery. For single link there is a very
  simple solution and this can be extended for multi-links
MO: Ands I'm saying its impossible
CH: fine!

  No need for tunnels in a single link network, and the routers can pass
  off to each other in the event of dynamic failure. The assertion is that
  in a single link network this requirement can be easily met. Dead exist
  routers or dead ISP require some consideration. If the exit router knows
  that the path is dead it can send a poison advertisement of the prefix.
  The real issue with this form of mh is a very soft definition of
  'broken' where the link may be up, but the path to the remote end point
  may be unuseable. This kind of problem is an e2e detection issue. Hosts
  may need to keep track of connections and track quality. If you know an
  ingress path is dead do you need to update the DNS to remove the dead
  prefix from your host entry? Of course you may not know and in this case
  your peer will need to work out what address to use. Maintenance of TCP
  connections is an issue. MIP6 may be an answer, or SCTP for 'new hosts'.
  For 'old' hosts, he connection will fail, and needs to be reestablished.
  Exit / entrance selection is also an issue. One approach is to only
  advertise the preferred address in the DNS if you have a primary /
  backup scenario. And in a 1 + 1 scenario, then advertise both. On the
  outgoing the solution may be a local server to assist, or to document
  preferences in the routers. We appear to be able to design solutions
  that do not require changes to the IPv6 standards, do not require
  address rewriting at exit points, and it could work,
  
Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need
  to change both ends?
CH: The support for the connected node in MIPv6 is supposed to be
  implemented everywhere. 
PN: You need to change the code at both ends.
CH: You don't need to change code if you are satisfied with the default
  timers, which appears to be around 5 or 6 minutes."
PN: If you are going to change the code at both ends then you should try
  HIP in your experiments as well.
CH: You are free to experiment with HIP
Fujikawa: It seems like an application cannot select different path from
  other applications in a host?
CH: No, not so. The host has several IPv6 addresses. An application that
  want to do path selection can bind to a source address and connect to a
  destination and select a path.
Matasaka Ohta: It is stupid to keep using a complication MIPv6
CH: Complexity is management of the Home agent and security functions to
  certain classes of attacks and you will need  to have some form of
  security in any case.
Matasaka Ohta: This only works in a single link case.

  Claimed that this is not the best solution in all cases, but better than
  some others. Need to avoid the routing mess of advertising more specific
  and need solutions soon. Approach to use the AS number to create PI
  space for larger enterprises. e.g. 2000:<ASN>::/32. Issues about 16 / 32
  bit AS numbers, and a claim that 32 bit AS numbers would indicate a RIR
  policy failure.

Moshens VC(?): How do you get uniqueness of the prefix
PS: This is 2000 - it won't collide!
MO: There are already too many ASes deployed
Geoff Huston: You are assuming AS remain at 16bits. What happens when AS
  drain in 2011. and we move to 32 bit AS numbers? This is a relatively
  short term solution with a visible drop dead point - right?
PV: yes.
?: This is good solution
PV: an appendix shows how to deal with 32 bit AS numbers, but I don't
  like this solution.
Tim Chen: This cuts out the smaller sites that do not have ASs.
Randy Bush: Why reluctant to give out ASes to routing domains who's policy
  domains are different from their neighbors?

  Geographical aggregation. Admitted that topology is not correlated to
  geography, and even if the geo part doesn't work there are still some
  savings. Goal is enabling multihoming ASAP. This is a short term
  solution. It works by distributing the global routing table over the
  routers within an (ISP) network rather than giving every router a full
  copy as is done today. This would lead to scenic routing but the geo
  aspect repairs this. Unless there is insufficient interconnection
  between networks, then aggregation must be broken. Geographic aggregates
  are internal to each network and not announced externally. Correlation
  between topology and geography is less than 1, but also more than 0 and
  even without geography there are still some savings. No real downsides:
  RIRs must implement geographic address allocation, ISPs can implement
  this (or not) at their convenience.

MH: This gives little actual aggregation
?: Asymmetrical routes break in your model
IvB: today it's asymmetrical anyway (re hot potato routing) and when both
  sides do geo aggregation it is still asymmetrical, when one end is geo
  multihomed and the other isn't it's symmetrical. But read the draft as
  it has a section on exactly this issue from an ISP traffic distribution
  viewpoint.
Tony Hain: Aggregatibility is the question. The concept appears fine, but
  you are making assumptions about aggregation boundaries here.
IvB: Short answer: you can make your own boundaries or this can even work
  with your (Tony's) geographic addressing plan. Long answer: no time for
  the long answer...

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Jul 2003 20:26:27 +0859 ()

Geoff;

> Matsataka Ohta: IPv6 has large timeouts for various purposes. If your 

< Matsataka Ohta: MIPv6 has large timeouts for various purposes. If your 

> address selection. When should a host attempt alternate addresses? Proposed 
< in response to ICMP, routing change, timeouts (TCP, but not IP nor UDP, has a defact default). Proposed that 

> Matasaka Ohta: The current Internet is weakly secure. Cookie-based security 
< for locator change give JUST the same level of security.

It's overkill to use DSA signature only to confirm that
random peers keep identities.

> locator for the peer. Extended example of policy control and filtering.
< NLAs may have as many peers as necessary and have full control on
< egress policy, though there is small limitation on ingress policy
< control, ingress control is limited from the beginning and is
< not a problem.

							Masataka Ohta

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Wed, 16 Jul 2003 17:56:31 +0900

> - - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min

OHIRA Kenji, who is the first auther, made a presentation instead of me.

> address selection. Transport layer survivability could be an SCTP mechanism 
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
 WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                              E-mail [email-masked]