Subject: note from the iesg plenary

From: [email-masked] (Sean Doran)
Date: Thu, 9 Aug 2001 00:06:21 +0200 (CEST)

it was noted that there has been little attention payed in the ietf
to scoped addresses of various types in the ipv6 standard (e.g., link
or anycast addresses).  

for our wg (from me, not from the floor): can these different address
varities, when a host uses them, be considered as a form of multiple-address
multihoming?    likewise, those approaches which change the routing system
in some fashion: how can/do they deal with such addressing types?

	Sean.

ps - several questions are coming up and unfortunately i am too slow a typist:
how does one choose and forward addresses for anycast objects, how does
one deal with sites which are not convex, how does one scope addresses
beyond a site boundary.  there were others.  if someone can identify
the questioner from the floor, i would like to invite her to ask the
same questions here.   as noted, with my other hat, irtf-rr is a reasonable
place to ask (not necessarily ipv6-specific) similar questions, but
note well that the irtf is *NOT* the ietf, whereas this is.

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Aug 2001 23:09:29 +0100

> varities, when a host uses them, be considered as a form of
> multiple-address multihoming?  likewise, those approaches which change the
> routing system in some fashion: how can/do they deal with such addressing
> types?

routing as we know it, does not have sufficient scoping / reachability
constraint mechanisms to handle the seeming semantics.

randy

---

From: Jim Bound <[email-masked]>
Date: Thu, 9 Aug 2001 01:39:46 -0400 (EDT)

Sean,

If the node knows that the target is onl the link, the site, and global
then yes.  But a node knowing that is not known except by the interface
the packet goes or enters and most do not believe we should try to parse
that type of a priori knowledge today because its complex.

But if I knew my ISP was global and part of my site and had DNS recs for
each address type then if one address was down the other could be used if
also true for ISP #2.

But if we specify SCTP for example and IPv6 default address selection if
this is implemented the end result is the scoping should work for the
multihome case.

I think one piece of work for someone who knows the ICMPv6 protocol
implementation well and router renumbering would be to see if we can
define a mechanism to inform an end node that an ISP interface is down
would be a good exercise.  We would get this with SCTP for free (no
response or heartbeat probe) but if the ISP routers were proactive the
convergence time for the end node to use another SCTP connection would be
useful if lets say 20 times faster than SCTP failover convergence.

regards,

/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 9 Aug 2001 01:47:07 -0400 (EDT)

Routing does not but the end node could.  Routing would be transparent to
the solution.

I think the best multi6 proposal would be one that can start alleviating
the pain of multihoming in v6 while we work the routing issues in general
in the IETF.  Also this will help as IPv6 deployment is eminant and will
not wait for us to finish.  By defining a mechanism like SCTP and use of
proper scoping with address selection much of the multihome problem can be
solved using the ideas from ohta-san, peter tatam et al and we can get
this in our IPv6 production code bases by late 2002 or early 2003.
Possbily earlier with code patches with a shim I suggested to Brian on
other mail thread.  Do not assume the market will wait or can be held up
at least in Asia and Europe, and now even certain target markets will
begin early adoption in the U.S. and have already although in test phase
now.

/jim

---

From: Peter Tattam <[email-masked]>
Date: Thu, 9 Aug 2001 16:21:45 +1000 (EST)

> begin early adoption in the U.S. and have already although in test phase

Are multihoming issues likely to bite any current rollout taking place? If so,
there will need to be a temporary workaround in the contingency plan, with a
strict stipulation that such a workaround has a limited lifetime.  If not, no
need to worry.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Joe Abley <[email-masked]>
Date: Thu, 9 Aug 2001 03:33:45 -0400

Hi Peter,

> strict stipulation that such a workaround has a limited lifetime.  If not, no

There is a requirement that any host that is modified to facilitate
multihoming interoperates with other hosts that have not received such
modifications (see 3.2.3 in requirements-01).

I think that covers both the cases of stack rollout and network rollout
(not sure which you were referring to). I believe the former is of
greater concern amongst people here than the latter, based on what
I have heard so far.

Joe

---

From: Jim Bound <[email-masked]>
Date: Thu, 9 Aug 2001 08:40:40 -0400 (EDT)

Hi Peter,

> strict stipulation that such a workaround has a limited lifetime.  If not, no
Not for current IPv6 deployment which is for others:
1. Core IPv6 Specs (Base, ND, ICMP, PMTUD, Base API, et al)
2. Core Trans Mech (Base Trans Mech, init 6to4, et al)
3. Core Internet Apps (telnet and friends, netutilities, send-mail, nfs,
et al).

So what we see are first IPv6/IPv4 nodes are deployed in
departments/labs/et al.  THen tunnels are used to connect across IPv4
ocean.

To keep it short initial deployment will not be seen by ISPs et al hence
no IPv6 routing table issues which is why deployment has started and
continue and because it will start in Intranets to the Edge and tunnel
across the core we have time.  Two variable where IPv6 could show up at
the core are 802.11b and 3G wireless.  But in these cases it will probably
not use the traditional Internet still as this will be done by the telco
providers not the standard ISPs.  It will take them time to see any IPv6
routing pain as they will use the Internet also as IPv4 ocean to tunnel
across. 

Now if someone causes a market of 3 billion IPv6 handhelds well then
everything breaks clearly.  I don't see that happening at least for two
years but it could.  

Sorry for the diatribe but I wanted to be clear by what I mean IPv6
deployment.  I am not speaking of native IPv6 packets across the core
backbone of the Internet.  I guess it could happen in Asia and Europe and
if that happens I fear they will build their own Internet and bypass the
U.S. issues I guess ???

As far as product rollout if sctp as one example was used it would adhere
to the current multi6 reqs and work with non Ipv6 multihomed nodes or non
ipv4 multihomed nodes for transition.

My vision of shim to support AF_SCTP (for V6) also would adhere to multi6
req above.  

Plus once we see this is something we want to experiment with we add that
specific test to UNH, ETSI, and Kame Test Suites for IPv6.  Most all IPv6
is tested at interop events before we move to production mode.

So I think we are OK but the code always is the final truth.

/jim

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Aug 2001 15:18:57 +0200

In your previous mail you wrote:

=> I disagree: we know we have no good solution in the current code base.
I believe the solution will be in hosts and compatible with the current
IPv6, but nodes which will be to used it will get extra functionalities
(so we'll like to switch to them). But I agree we have to search and *find*
a workable solution ASAP. Something like HIP seems to be promising (I was
at the HIP meeting so I should be still biaised  :-).

Regards

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Fri, 10 Aug 2001 06:05:37 -0400 (EDT)

I was speaking of future code base.  

What has the shim to do with HIP?

/jim

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Aug 2001 12:30:38 +0200

=> what I have (mis?)understood is that we can't adopt very new things
like HIP because the code was frozen and will be delivered to customers
ASAP. This implies (that was the introducing statement of your mail
I have lost in editing after a connection reset (the only one, BT
seems stronger than Code Red :-)) that the solution has to be implemented
in routers and not in hosts (modulo the shim stuff).

=> nothing... A shim should not be enough to add HIP.
   
Regards