[dhcwg] Comments on draft-ietf-dhc-dual-stack-01

This draft is still missing a discussion of one of the issues that has
been raised a couple times in the past, including during the WG
discussion of this draft last IETF.

Specifically, the issue occurs with any option that includes a list of
addresses of servers (e.g., DNS server addresses).  The reason for
having a list in the first place is to allow the client to try an
alternate address in the event that the first one it tries fails.  When
such a failure occurs, it may be for either of two reasons:
a) The server has failed
b) Connectivity via IPv4 or IPv6 has failed

When you have a set of dual-stack servers and dual-stack clients, and
the first attempt fails, to maximize the chance that the next attempt
will succeed in the absence of being able to distinguish between (a) and
(b), the client should try a different server, via a different protocol.

The problem today is that you get the IPv4 list via DHCPv4 and the IPv6
list via DHCPv6, and the client has no way to really "try a different
server", since that information is lost by the protocol, even though it
may be known by the server.

Just putting merging heuristics in the client cannot provide the best
behavior, since information is lost.  By comparison, if IPv4-mapped
addresses were included in the DHCPv6 option along with IPv6 addresses,
the DHCP server can give an intelligent order that takes into account
which addresses are of the same DNS/whatever server.  Of course, v6-only
clients have to know to discard the v4-mapped addresses in this
solution, and it's much easier to solve this in the combined-DHCP-server
case than in the two-server case.

I believe this draft needs to discuss this dual-stack issue and its
implications.

-Dave

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg