On Apr 16, 2014, at 1:38 PM 4/16/14, George, Wes <[email protected]>
wrote:
> Simon Perreault (and to some lesser extent,I ) has been involved in a fairly
> animated discussion across Homenet and V6Ops about draft-ietf-sunset4-noipv4
> after requesting those WG’s feedback on the draft.
> [...]
>
> I’d encourage folks to take a look and provide input on this list, so that
> the authors have good guidance from the WG on how this WG draft should evolve
> to address the feedback provided.
>
> Thanks,
>
> Wes
I re-read the animated discussion and I have a few thoughts...
I found I had to read the document carefully to pick up some subtle
points. The details are all there in the doc but I missed some of
them during a first reading. And I think the animated discussion may
have missed some of these details, as well.
One of the problems I had with the document was in sorting out the
specific goals and use cases for the proposed mechanisms. I concluded
there are actually two goals:
(1) explicitly command all (or some nodes) on a link to turn off IPv4
(while potentially others continue to use IPv4)
(2) in the case of a router, prohibit advertising IPv4 services on
other interfaces
So, do I have those goals right? If so, it's important to realize
that (1) involves more than just turning off DHCPv4, and is a more
ambitious goal than the goal of RFC7038, which only tried to reduce
DHCPv6 traffic by increasing SOL_MAX_RT without trying to turn off
IPv6 altogether.
In my opinion, it is debatable whether (2) is an appropriate goal for
a router advertisement or host configuration protocol; my preference
would be for an RFC aimed specifically at customer edge routers (like
RFC 7084) that describes in detail how a customer edge router is
configured not to provide IPv4 service.
Regarding (1), my first reaction was that the right mechanism for that
control would be DHCPv4. Seems to me it's about the same amount of
code to detect a DHCPv4 option and turn off IPv4 (including the DHCPv4
client) as to detect a DHCPv6 or RA option and turn off IPv4.
Personally, I think either design can be made to work, both designs
have drawbacks and neither design has strong advantages over the
other. But, if the consensus of the sunset4 WG is to use DHCPv6 and RAs,
then that's the specification that should go forward unless there's
some specific reason why that design won't work. I don't know of a
reason why the DHCPv6/RA design won't work.
Finally, I tried to convince myself that one or the other of DHCPv6 or
RAs would be sufficient. But not every host has a DHCPv6 client, and
RAs won't support differential control of hosts on a link, so it seems
both DHCPv6 and RAs are needed.
- Ralph
_______________________________________________
sunset4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sunset4
