[sunset4] discussion on sunset4-noipv4 draft in other WGs

[George, Wes]

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.
Here’s a quote from one of Ted Lemon’s posts that might help to summarize the discussion:
"We've gotten some good feedback that the document isn't clear enough, particularly with respect to how multiple interfaces are handled, and we've gotten some good feedback about how to handle validity of the assertion that IPv4 shouldn't be used, and about how to deal with various attacks that could be launched by shutting down IPv4.
...
there's also been a lot of discussion about whether to use DHCPv4 or IPv6 configuration protocols for signaling,"

Additionally there were questions about whether or not the scope should be limited to shutting down DHCPv4, or still include shutting IPv4 off altogether, and whether there should be guidance on things like lifetimes, back off behavior in clients, etc.

This link should pull up the relevant threads all in one place via the new mail archive search tool.
https://mailarchive.ietf.org/arch/search/?qdr=a&start_date=&end_date=&email_list=v6ops%2Chomenet&q=text%3A%28%22the+no+ipv4+draft%22%29&as=1

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

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

[Ralph Droms]

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