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 change?
Jari
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
