On Oct 7, 2011, at 3:48 AM, Fred Baker wrote:
> As one might expect, a lot of the discussion was non-controversial. Points 
> that raised discussion started with the issue of multihoming as shown on 
> slide 9. A question arose on how multi-address interfaces work on typical 
> operating systems including Windows, MacOSX, and various Linux variants. It 
> was observed that rather than actually forming an address in each prefix as 
> one would expect in a multi-prefix network, Linux sees the various prefixes 
> advertised in an RA and selects one, forms an address in it, and uses that 
> address until it expires. Per RFC 4861, the lifetime on such a prefix is the 
> same as the lifetime on the IA_PD granted by the upstream network, which is 
> generally on the order of weeks. In the event that we have multiple routers 
> to multiple upstream networks each advertising a prefix and one fails - not 
> just the link, but the router and therefore the DHCPv6 server in it - the 
> host will continue using that prefix until it is actively rescinded.

Speaking strictly for myself, here, this seems actively broken in several ways. 
First, if the design of IPv6 calls for an address in each prefix advertised in 
an RA, what would it take to get Windows, MacOSX, FreeBSD, Linux, Linux, Linux, 
and Linux to do that? All discussion of RFC 3484 seems wasted if the device has 
exactly one address.

But also, the notion of tying the lifetime of a prefix on the LAN with the 
lifetime of the prefix grant seems ill-considered. The purpose of the lifetime 
on the prefix grant (RFC 3363) is to enable an upstream to not need to be asked 
every 30 seconds for something it wants to leave unchanged for a long period of 
time and yet make "a long time" not be "forever". That's reasonable. But in the 
case called out here, it seems like the lifetime of the prefix in an RA should 
be long enough that a host can miss an RA refresh and not lose the address, and 
short enough that we don't have to call in the national guard if someone trips 
over a cable or a power supply goes spitzensparken.

What do we need to do to change that RFC 4861 requirement? If what is required 
is an Internet Draft in 6man (and I would expect it is), I'd be willing to 
write that draft.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to