Re: note from the iesg plenary

[Jim Bound <seamus@bit-net.com>]

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


On Thu, 9 Aug 2001, Sean Doran wrote:

> 
> 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.
>