On Oct 7, 2011, at 8:41 AM, Jari Arkko <[email protected]> wrote:
> Fred,
>
>
>>> 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.
>
> Linux actually does configure multiple addresses, and seems capable of using
> them in different situations. Maybe yesterday's comment about Linux behavior
> was more about what it does when a set of addresses has no clear preference
> (RFC 3484 or otherwise. My experience is that it does then use one
> address/router unless something changes. (Indeed, this is often problem as an
> earlier version had a bug that old networks didn't go down despite moving to
> a new network, and if I happened to use the old router's address I was having
> a bad day.)
>
>
>>
>> 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.
>>
>
> I was scanning RFC 4861 and did not see anything about IA_PD or delegation,
> just saw a 30 day default value for the valid lifetime. Where is the text
> that you would like to
The text in question may be in RFC 3633, section 12.1, which requires that the
valid lifetime for the prefix in the RA must be no later than the valid
lifetime in the IA_PD.
- Ralph
> change?
>
> Jari
>
>
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
