In message <[email protected]>
Michael Richardson writes:
> --=-=-=
> Content-Transfer-Encoding: quoted-printable
>
>
> >>>>> "Brian" =3D=3D Brian E Carpenter <[email protected]> writes:
> Brian> Aliases, as you describe them, sound like a hack. I'd like to
> Brian> hear from Microsoft (for example) whether their support of
> Brian> multiple IPv6 addresses per interface is a hack or genuine. I
> Brian> don't care about IPv4, but the IPv6 model is very clear. You
> Brian> can't read the ND spec and imagine the arrival of a new
> Brian> address resetting sessions that use other addresses.
>
> On Linux and *BSD, (possibly including OSX, but I don't know, but I
> could do an experiment with my officemate), new addresses get added
> without an interface flap.
> Old addresses expire as they expire, no interface flap need occur.
> Linux does this all in the kernel, *BSD does it in rtsold.
> I can't speak of what happens with dhcpv6.
Thanks. I just took a look at rtsold and rtadvd. If Linux kernel has
a similar function (wrong place to put this IMHO, but ...), then
perhaps in both rtsold and the Linux kernel in addition to an
interface down and up event, a suspend and resume event should trigger
a router solicitation.
BTW- In BSD neighbor discovery is in the kernel and router
solicitation and router advertisement are in userland.
Note that in rfc4862 (SLAAC) we have:
5.5.4. Address Lifetime Expiry
A preferred address becomes deprecated when its preferred
lifetime expires. A deprecated address SHOULD continue to be
used as a source address in existing communications, but SHOULD
NOT be used to initiate new communications if an alternate
(non-deprecated) address of sufficient scope can easily be used
instead.
The RFC indicates that an old address should remain preferred. It
might be better if a newer address was preferred slightly more and
could serve as a tie breaker.
> The choice of which one to use for new connections essentially depends
> upon the metrics on the route to that destination. Typically, for
> off-link destinations, it's the default route that matters.
>
> Where I think we see interface flaps is as a result of DHCPv4.
> If we lose connectivity to the DHCPv4, then the dhclient-daemon will
> reset the interface and start again. With wifi, this is often more
> frequent. I have had IPv6 connections survive such events, but not
> always.
If you have a USB interface and pull it out, dhcpv4 is killed and does
clean up and is restarted. In bsd the netif script is run with stop
and start. Otherwise, if you just hop to another channel on the
wireless, or unplug and plug the ethernet, the old address gets
deleted (ifconfig ... -alias) and the new address added (ifconfig
... alias).
> Michael Richardson <[email protected]>, Sandelman Software Works=20
It would be nice if for both IPv4 and IPv6 hopping to another channel
on the wireless did not break old connections and did the right thing
with new ones.
Routers have a solution to any interface going down, but that solution
is to put a routable address on the loopback. That works fine because
the provider can carry the IPv4 /32 or IPv6 /128 routes within its
borders, adding only one host route for each router, well worth it for
the reliability gain.
Within an enterprise, roaming around a building is supported by
bridging all the hubs together at layer-2. This won't work for a home
user roaming outside the home and down the block to a WiFi hotspot (in
my case about 3-4 miles, so I'd have to rely in a lot of neighbors
with open wifi).
This roaming across subnets case could be made workable using a GUA on
the loopback and forcing a tunnel back to the home when roaming
outside the home. This could also be a feature supported by a
wireless carrier, retaining an address on the loopback given at the
tower where the connection started until that address was no longer
needed.
It would be up to IETF (maybe homenet) to describe how this should
work (as described above is a candidate) and then up to home devices
to include support for it. Being able to road at will without ever
losing connections would be a valuable feature.
Curtis
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
