Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

From: Gyan Mishra <[email-masked]>
Date: Thu, 2 May 2019 18:29:13 -0400

I read through the draft as it has had 5 revisions and improvements I understand the rationale behind wanting this flag.

I would say my biggest concern with this flag at least introducing it now as we are not even anywhere close to a 50/50 tipping point that folks that end users would stop using IPv4.

The major downside is security vulnerabilities that can impact the mainstream of traffic flow which is IPV4.  

I could see introducing this flag let’s say we were past the tipping point and the proliferation and penetration of IPV6 was so tremendous that we were well beyond 50% and more like 70% plus and only few remaining stragglers on IPv4.

I would say for that to happen it would be beyond all of our lifetimes that the internet local intranet and extranet are even close to a tipping point

That being said the gains of negligible control plane dhcp traffic reduction is minuscule as compare to impact if their is an IPv4 outage from now newly introduced attack vector.

That being said I do not support this draf.

I would say maybe give it 50 to 100 years and I might change my mind given IPv6 penetration at that point.

Gyan

Sent from my iPhone

> On Apr 30, 2019, at 5:55 PM, Nick Hilliard <[email-masked]> wrote:
> 
> Brian E Carpenter wrote on 30/04/2019 21:48:
>> So I'd rather understand *why* the costs outweigh the benefits. One more thing for an operator to configure and check in each first-hop router, vs reduction of pointless traffic on updated hosts. I'm not sure how to make that an objective rather than a subjective trade-off.
> Hi Brian,
> 
> Email is being a serious barrier to communication in this discussion :-(
> 
> The problem statement just isn't there:
> 
> https://mailarchive.ietf.org/arch/msg/ipv6/GCGYTXhg0V9mQBrcO7zhC5wtnp0
> 
> The contents of this email largely still apply to the current text in -05.
> 
> The cost is too high:
> 
> https://mailarchive.ietf.org/arch/msg/ipv6/NIJ194PI8CLkuZT8U_jKEOY01QI
> 
> You've shown no analysis of realistic use cases.
> 
> For something standards track, and this far down the protocol stack and with such a large security considerations section, the proposal ought to be thoroughly compelling for a wide variety of deployment scenarios, but it isn't.  There are better ways of skinning this cat.
> 
> Nick
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 2 May 2019 18:34:40 -0400

One other important concept of this theoretical distant future of IPv6 only networks is that we would have to be 100% every server on the internet dual stacked IPv6 reachable entire internet local intranets and extranet peering networks to 3rd parties customers have to be 100% dual stacked or only on IPv6 and even if let’s say there is one host 1 url that is not dual stacked that can only be reached via IPv4 then you cannot do IPv6 only.

I get it that the directional is to move to IPv6 but this is not going to make it happen any quicker but the risk with attack vector created is far worse that a little bit of IPv4 traffic.

Gyan

Sent from my iPhone

> On May 2, 2019, at 6:29 PM, Gyan Mishra <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 May 2019 11:44:05 +1200

> I would say my biggest concern with this flag at least introducing it now as we are not even anywhere close to a 50/50 tipping point that folks that end users would stop using IPv4.

End users will automatically stop using IPv4 when ISPs and service/content providers start supporting IPv6. https://www.google.com/intl/en/ipv6/statistics.html shows you how that's going.
 
> The major downside is security vulnerabilities that can impact the mainstream of traffic flow which is IPV4.

Really? Can you explain what is missing in the Security Considerations?
   
> I could see introducing this flag let’s say we were past the tipping point and the proliferation and penetration of IPV6 was so tremendous that we were well beyond 50% and more like 70% plus and on…

That's a judgment that each operator would have to make for its own situation. But they can't make that judgment if the flag isn't defined, and implemented in deployed equipment. So if the IETF is to define it, this will definitely happen years in advance of IPv6-only being widespread in the market.
 
> I would say for that to happen it would be beyond all of our lifetimes that the internet local intranet and extranet are even close to a tipping point

I think the Google data suggest that we are much closer than that.
 
> That being said the gains of negligible control plane dhcp traffic reduction is minuscule as compare to impact if their is an IPv4 outage from now newly introduced attack vector.

It isn't DHCP traffic that we're aiming at. It's any kind of IPv4 traffic.

   Brian

> 
> That being said I do not support this draf.> 
> .

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 May 2019 11:47:23 +1200

> One other important concept of this theoretical distant future of IPv6 only networks is that we would have to be 100% every server on the internet dual stacked IPv6 reachable entire internet local…

That's true, but irrelevant to this draft. 
> I get it that the directional is to move to IPv6 but this is not going to make it happen any quicker but the risk with attack vector created is far worse that a little bit of IPv4 traffic.

Again: what is missing in the Security Considerations? I don't actually see a residual attack vector there that is significant. There is, as others have said, some operational complexity, which is a legitimate objection.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 May 2019 11:52:43 +1200

Nick,
On 01-May-19 09:55, Nick Hilliard wrote:
>> So I'd rather understand *why* the costs outweigh the benefits. One 
>> more thing for an operator to configure and check in each first-hop 
>> router, vs reduction of pointless traffic on updated hosts. I'm not 
>> sure how to make that an objective rather than a subjective 
>> trade-off.
> Hi Brian,
> 

It's a judgment call. IMHO the problem statement is adequate. In your opinion, it isn't.

> For something standards track, and this far down the protocol stack and 
> with such a large security considerations section, the proposal ought to 
> be thoroughly compelling for a wide variety of deployment scenarios, but 
> it isn't.  There are better ways of skinning this cat.

Again, a judgment call. We do refer to Layer 2 solutions and this is clearly positioned as a complementary approach.
 
The authors aren't going to make the final judgment call, obviously.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 2 May 2019 22:29:11 -0700

Gyan,

> On May 2, 2019, at 3:29 PM, Gyan Mishra <[email-masked]> wrote:
> 

The point of the flag is not for today, but in the future when the tipping point is reached and people will want a tool to help turn off IPv4.   If we wait until that happens, then it will be too late to define a protocol mechanism and wait for it to be deployed.  The deployment of any new protocol like this takes a long time.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 2 May 2019 22:33:22 -0700

Gyan,

> On May 2, 2019, at 3:34 PM, Gyan Mishra <[email-masked]> wrote:
> 

In Section 4. IPv6-Only Definition it says:

   It is expected that on IPv6-Only networks it will be common to access
   to IPv4 external services by techniques such as NAT64 [RFC6146] and
   DNS64 [RFC6147]  at the edge of the network.  This is beyond the
   scope of this document.

So it is not expecting that 100% of every server on the internet is dual stack.

Bob

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 3 May 2019 12:17:30 -0400

Brian

IPv6 penetration is honestly really defined by the percentage of content on the internet that is dual stacked which is still pretty far off and has a long ways to go to even get to a tipping point 50/50 mark.

As far as cable and broadband providers for end users they are now starting to dual stack but it will be a long time as I said not until we hit the 100% mark that all content on the internet is dual stacked would broadband providers start thinking about pulling back and disabling IPv6.  

The internet really drives the local corporations and intranet which lags behind so that would be even further down the pike.

All broadband providers small and the big ones like Comcast Verizon Time Warner etc would not want to risk losing customers to their competitors if they pulled back IPv4 early and the internet content was not 100% IPv6.

If they did so god forbid they may be in for a a lot of class action suits as the entire internet majority being IPv4 would now not be accessible.

So bottom line here is that until the internet content is 100% IPv6 there is no way any broadband provider would pull back IPv6 thus in essence making this IPv6 flag literally useless and added on way to early in the game which brings me to my next point.

With regard to security ICMPv6 is not secure and with a SEND secure neighbor discovery that could be secure the iCMPv6 RFC 4861 RS/RA type 133/134 and NS/NA type 135/136.

So the RA that has the reserved field 2 flag bits now allocated to the IPv6 only flag can be subject to a man in the middle attack easily with a sniffer and spoofing the packet from the router manipulation of the the bird setting from all sending routers to 0 and now basically you have a massive outage.  Thinking about this on a larger scale let’s say If a router was exposed to an attack that someone gained accesses via a stack overflow or glitch the the attacker could not manipulate the flag to set the IPv6 only flag on all routers and now you have an IPv4 meltdown and a massive outage.

There are many scenarios of which this is only a few off the top of my head but maybe on a more grand scale since all hosts are talking ICMPv6 let’s say their was malware ddos virus that hit internet wise and was via email or any other type of delivery mechanism that was able to compromise all hosts gain root access and now on the host itself can set this IPv6 only flag to 1 and now you have an internet wide meltdown the  worst in history.

So I a nutshell this IPv6 only flag in my opinion is way ahead of its time and is a good thought but at this point is way jumping the gun as the entire internet community is not ready for this flag as our penetration numbers are not there yet.

I really think we should defer this RFC and put on hold for the future.

Gyan

Sent from my iPhone

> On May 2, 2019, at 7:52 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Nick,

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 3 May 2019 12:25:09 -0400

I forgot to mention that Send RFC 3971 is now being supported after a long time by routers but for the endpoint OS support may be a a lot further off and no roadmap to support like Microsoft the last I heard does not plan to support which is a major player with desktop OS and not sure about Linux and I am not sure about  Google Chromebooks and other desktop flavors.

Really all desktop OSs would have to support Send for this to be even viable from a security standpoint.

Gyan

Sent from my iPhone

> On May 3, 2019, at 12:17 PM, Gyan Mishra <[email-masked]> wrote:
> 
> Brian
>

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 3 May 2019 18:37:44 +0100

> It's a judgment call. IMHO the problem statement is adequate. In your
One point is subjective and fully unquantified, i.e. it has no place in 
a standards track document, and particularly not in a problem statement. 
Two of the points are technically misleading, bordering on incorrect, 
and should be deleted.  Two more are the same issue fleshed out into two 
bullet points.  In other words, the problem statement as it stands boils 
down to a single non-quantified issue about battery powered devices on 
wifi networks.

These are all things that have been raised repeatedly, but nothing 
substantial has been changed in the document.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 May 2019 08:12:47 +1200

> So bottom line here is that until the internet content is 100% IPv6 there is no way any broadband provider would pull back IPv6 thus in essence making this IPv6 flag literally useless and added on…

Sorry but you miss the point. An enterprise might choose to provide only IPv6 service (and presumably some variant of NAT64) this year. What a broadband service provider might decide is a different matter; of course they are driven by their own market.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 May 2019 08:15:23 +1200

I don't expect to see Send in widespread use anytime soon, but again it's irrelevant. That's a general defence against a wide range of malicious attacks, all of which are easier than attacking the ipv6only flag.

Regards
   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 3 May 2019 18:53:25 -0400

Do we or anyone in the WG know of any enterprise that is thinking of going
IPv6 only.  I don't.

I agree you have nat64 and dns64 and 6to4 proxy  for IPv6 only enterprises
to access IPv4 content but if I was an enterprise customer I would go with
dual stack over IPv6 only as that is the recommended mainstream deployment
of IPv6 and IPv6 only is a few and far between  extreme exception that I
don't think will gain traction till we are close to 100% of all internet
content being dual stacked.

Regards

Gyan

On Fri, May 3, 2019, 4:12 PM Brian E Carpenter <[email-masked]>
wrote:

> > So bottom line here is that until the internet content is 100% IPv6
> there is no way any broadband provider would pull back IPv6 thus in essence
> making this IPv6 flag literally useless and added on way to early in the
> game which brings me to my next point.
>
> Sorry but you miss the point. An enterprise might choose to provide only
> IPv6 service (and presumably some variant of NAT64) this year. What a
> broadband service provider might decide is a different matter; of course
> they are driven by their own market.
>
> Regards
>    Brian
>
> > IPv6 penetration is honestly really defined by the percentage of content
> on the internet that is dual stacked which is still pretty far off and has
> a long ways to go to even get to a tipping point 50/50 mark.
> >
> > As far as cable and broadband providers for end users they are now
> starting to dual stack but it will be a long time as I said not until we
> hit the 100% mark that all content on the internet is dual stacked would
> broadband providers start thinking about pulling back and disabling IPv6.
> >
> > The internet really drives the local corporations and intranet which
> lags behind so that would be even further down the pike.
> >
> > All broadband providers small and the big ones like Comcast Verizon Time
> Warner etc would not want to risk losing customers to their competitors if
> they pulled back IPv4 early and the internet content was not 100% IPv6.
> >
> > If they did so god forbid they may be in for a a lot of class action
> suits as the entire internet majority being IPv4 would now not be
> accessible.
> >
> > So bottom line here is that until the internet content is 100% IPv6
> there is no way any broadband provider would pull back IPv6 thus in essence
> making this IPv6 flag literally useless and added on way to early in the
> game which brings me to my next point.
> >
> > With regard to security ICMPv6 is not secure and with a SEND secure
> neighbor discovery that could be secure the iCMPv6 RFC 4861 RS/RA type
> 133/134 and NS/NA type 135/136.
> >
> > So the RA that has the reserved field 2 flag bits now allocated to the
> IPv6 only flag can be subject to a man in the middle attack easily with a
> sniffer and spoofing the packet from the router manipulation of the the
> bird setting from all sending routers to 0 and now basically you have a
> massive outage.  Thinking about this on a larger scale let’s say If a
> router was exposed to an attack that someone gained accesses via a stack
> overflow or glitch the the attacker could not manipulate the flag to set
> the IPv6 only flag on all routers and now you have an IPv4 meltdown and a
> massive outage.
> >
> > There are many scenarios of which this is only a few off the top of my
> head but maybe on a more grand scale since all hosts are talking ICMPv6
> let’s say their was malware ddos virus that hit internet wise and was via
> email or any other type of delivery mechanism that was able to compromise
> all hosts gain root access and now on the host itself can set this IPv6
> only flag to 1 and now you have an internet wide meltdown the  worst in
> history.
> >
> > So I a nutshell this IPv6 only flag in my opinion is way ahead of its
> time and is a good thought but at this point is way jumping the gun as the
> entire internet community is not ready for this flag as our penetration
> numbers are not there yet.
> >
> >> Again, a judgment call. We do refer to Layer 2 solutions and this is
> clearly positioned as a complementary approach.
> >>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 3 May 2019 16:53:08 -0700

Gyan,

> On May 3, 2019, at 3:53 PM, Gyan Mishra <[email-masked]> wrote:
> 
> Do we or anyone in the WG know of any enterprise that is thinking of going IPv6 only.  I don't.  

Yes, Microsoft.   It was stated in 6man several meetings ago that they were planning IPv6 Only and that this was a mechanism that would be a useful tool.

Bob

> 
> I agree you have nat64 and dns64 and 6to4 proxy  for IPv6 only enterprises to access IPv4 content but if I was an enterprise customer I would go with dual stack over IPv6 only as that is the recommended mainstream deployment of IPv6 and IPv6 only is a few and far between  extreme exception that I don't think will gain traction till we are close to 100% of all internet content being dual stacked.
> 
> 
> Regards 
> 
> Gyan
> 
> On Fri, May 3, 2019, 4:12 PM Brian E Carpenter <[email-masked]> wrote:
> > If they did so god forbid they may be in for a a lot of class action suits as the entire internet majority being IPv4 would now not be accessible..
> > 
> > I really think we should defer this RFC and put on hold for the future..
> > 
> > Gyan
> > 
> > Sent from my iPhone
> > 
> >> On May 2, 2019, at 7:52 PM, Brian E Carpenter <[email-masked]> wrote:
> >>
> >> Nick,
> >>>> router, vs reduction of pointless traffic on updated hosts.. I'm not 
> >>> it isn't.  There are better ways of skinning this cat..
> >>

---

From: Mark Smith <[email-masked]>
Date: Sat, 4 May 2019 10:04:26 +1000

> Do we or anyone in the WG know of any enterprise that is thinking of going IPv6 only.  I don't.

Case Study: Facebook Moving To An IPv6-Only Internal Network, 6 June 2014
https://www.internetsociety.org/resources/deploy360/2014/case-study-facebook-moving-to-an-ipv6-only-internal-network/

Microsoft making progress towards IPv6-only, 17 Sep 2018
https://blog.apnic.net/2018/09/17/microsoft-making-progress-towards-ipv6-only/

>
> I agree you have nat64 and dns64 and 6to4 proxy  for IPv6 only enterprises to access IPv4 content but if I was an enterprise customer I would go with dual stack over IPv6 only as that is the recommended mainstream deployment of IPv6

It's debatable.

>and IPv6 only is a few and far between  extreme exception that I don't think will gain traction till we are close to 100% of all internet content being dual stacked.
>
>

Further to what Bob said, we have to expect it may take 3 to 5 years,
perhaps sometimes longer, for our work to become widely available in
implementations.

For example, the current IPv6 Flow Label specification (RFC 6438) was
published in November of 2011. Yet it took somewhere in the order of 2
to 3 years for Mac OS X to be updated to support it, 4 years for Linux
to be updated, and 6 years for Windows to be updated.

We also need to try to have solutions that may last and can be in use
for decades in many different contexts (ideally with one solution
being able to be used in all possible use contexts), not just ISP or
corporate/enterprise networks. We need to have solutions that can and
will be implemented on billions of hosts, because that is literally
how many IPv6 capable hosts are already in end-users' hands.

Here we're doing medium to long term engineering, in contrast to the
relatively short to medium term engineering that takes place when
building and operating production networks.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 May 2019 13:33:42 +1200

> https://blog.apnic.net/2018/09/17/microsoft-making-progress-towards-ipv6-only/

Thanks Mark. And of course the entire motivation of all the work on NAT64, 464XLAT and so on was to *allow* operators and enterprises to make that choice (and thereby reduce operational complexity) without the whole world having dual stack capability. So while I have always been a strong advocate of dual stack, it's clear that there will be a trend for far-sighted enterprises to go IPv6-only sooner rather than later. (Of course, they have to present a dual-stack face to the outside world.)

It's the job of a standards organization to be preemptive and to be out ahead of vendors and operators - years ahead, that is. So personally I think the "too soon" argument is completely wrong. We should probably have worked on this sooner, while NAT64 and 464LAT were still in development, in fact.

I'm definitely sensitive to the operational arguments from Nick and Sander. However, on that topic the authors can only wait for directives from Ole, since we're servants of the WG consensus. If it isn't clear, I at least don't know what else to change in the text in response to those objections. If the WG wants to un-adopt the draft, so be it. But that would need to be a new consensus call.

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 4 May 2019 00:05:20 -0400

Thanks Bob

Thanks for enlightening me on that.  Maybe we should add FB and Microsoft as use cases to the draft as I didn’t see it mentioned.

Based on that I am on board with the IPv6 only flag and support the draft.

Regards

Gyan

Sent from my iPhone

> On May 3, 2019, at 8:04 PM, Mark Smith <[email-masked]> wrote:
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 4 May 2019 00:14:03 -0400

Brian

I am on board with the draft and based on Microsoft and FB both big players driving IPv6 only and since Microsoft has a majority share in the desktop market that makes a big difference.

I have always been and still am a proponent of dual stack but now I understand more clearly that the use case for enterprises would be tpresenting dual stack to the public while being IPv6 only internally. I think this use case idea for enterprises should be added to the draft if not already.

What was Nick and Sanders operator and operational objection as I missed that in an earlier thread.

Thank you 

Gyan

Sent from my iPhone

> On May 3, 2019, at 9:33 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 May 2019 16:28:47 +1200

> What was Nick and Sanders operator and operational objection as I missed that in an earlier thread.

Thanks, I will forward their recent messages off-list to avoid repetition.

    Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 4 May 2019 02:25:13 -0500

Basically, I support this document, in the near-term, I think it will be
useful in some specialized situations, longer-term it may have more general
applicability.

Below are some issues from my detailed review of the current version, it
has been two or three versions since my last detailed review;

1. In my opinion, the following sentence contradicts part of the
applicability statement. I never really liked the document talking about
unmanaged networks, but I couldn't articulate a reason why, until now. My
recommendation is to remove it

   It may also be valuable on unmanaged networks
   using routers pre-configured for IPv6-Only operations and where Layer
   2 filtering is unavailable.

The following is the portion of the Applicability Statement in question;

   Administrators MUST only use this mechanism if they are certain that
   the link is IPv6-Only.

Unmanaged networks do not usually have an administrator, by definition they
are not managed. I think maybe this was intended to suggest an ISP or CPE
manufacture could ship IPv6-Only CPE with this flag set by default.
However, that would also violate the Applicability Statement, neither the
ISP or CPE manufacture could have the certainty required by the
Applicability Statement that IPv4 is not in use on the local network.

I think the use of this flag on unmanaged networks is ill-advised and
should not be discussed in the document. The trade-offs involved in using
this flag as it is currently designed requires someone, the
administrator, with intimate knowledge of the local network to decide if
this flag should be set or not on the router's link. Discussing the use of
the flag on unmanaged networks implies this level of knowledge may not be
necessary. The remainder of the paragraph already covers "networks without
the ability to filter L2 traffic."

If you intend this flag to be used on unmanaged networks it will need to be
much more automatic, as designed it requires an administrator to decide its
appropriate setting.

It might even be appropriate to add that this flag is only intended for use
on managed networks, that have an administrator, but as long as you don't
mention unmanaged networks, that is good enough for me.

2. I think Section 6 should additionally recommend the use of Router Guard
[RFC6105], it is discussed in the Security Considerations Section, but I
think it should be in Section 6 as well. Without Router Guard an IPv6-Only
network is open to the attack discussed in paragraph 4 (not including the
bullets) of the Security Considerations Section. Therefore, I think the use
of Router Guard should be recommended with normative language in Section 6.

3. In Section 7, paragraph 5 seems to repeat the idea in the last half of
paragraph 3, my recommendation is to delete paragraph 5.

4. Previously I asked for the following (slightly edited) and I don't see
where it has been addressed, nor do I find an email explaining why it was
not addressed. The only email I found was Brian saying "your suggestions
below make sense to me," in my mind that included the following;

Finally how about some additional non-normative discussion about taking
precautions to prevent unsuspecting WiFi users from accidentally connecting
IPv4-Only WiFi hosts to IPv6-Only WiFi links. Possibly by including "IPv6"
or "IPv6-Only" in the name of open SSIDs to help inform unsuspecting WiFi
users, using secured SSIDs to prevent unsuspecting WiFi users from
connecting all, or using 802.11u Access Network Query Protocol (ANQP) with
"Address type available" for IPv6 and "Address type not available" for IPv4
to inform the connecting WiFi host instead of the user. Putting this in an
appendix would be fine with me.

Remember the IETF's own discussions regarding this issue. If the IETF isn't
willing to have its default WiFi be IPv6-only, maybe some caution is
warranted for the general population of the earth. :)

Thanks

On Mon, Apr 29, 2019 at 5:02 AM Ole Troan <[email-masked]> wrote:

> At the 6man meeting at IETF 104 in Prague there was support to close the
> working group last call and advance
> draft-ietf-6man-ipv6only-flag-05 to the IESG.
>
> This call is to confirm that decision on the mailing list.
>
> Please give objections and comments to this decision to the mailing list,
> by 2019-05-13.
>
> Best regards,
> Ole, 6man co-chair

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Job Snijders <[email-masked]>
Date: Sun, 5 May 2019 20:04:49 +0000

Dear Ole,

On Mon, Apr 29, 2019 at 02:01:43PM +0200, Ole Troan wrote:
> > On 29 Apr 2019, at 13:03, Nick Hilliard <[email-masked]> wrote:
> > 
> > So, is this ID proceeding on a point of procedure at this point?
> > I.e. is the the slate going to be wiped clean every time an update
> > is issued, no matter how minor, and all previous objections are
> > automatically invalidated?
> 
> Yes, I think that's a somewhat correct reading of working group process.

No.

This interpretation of the working group process is flawed. This is not
all how IETF works.

If we consider "no matter how minor" as just changing the version number
of a draft, we should all be able to see that the act of merely bumping
the version number of a draft absolutely is not an adequate
implementation of "addressing outstanding issues".

Concerns are addressed through dialogue and substantial change to an
Internet Draft.

Conceding when there is a real outstanding technical objection is not
coming to consensus.

The misuse of process has been brought up before
https://mailarchive.ietf.org/arch/msg/ipv6/GAIeuDbH3q1u9YQvQLHYaYK4sXU
It gives me great cause for alarm to observe these proceedings.

Kind regards,

Job

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 May 2019 11:13:27 +1200

> implementation of "addressing outstanding issues".

Correct. But that doesn't apply to the draft in question, so I don't
understand why you mention it.
 
> Concerns are addressed through dialogue and substantial change to an

Correct. But substantial changes can be quite small, and often are small
in the later stages of discussion.
 
> Conceding when there is a real outstanding technical objection is not

No, but the IETF works by rough consensus, which means that a document
may be advanced even with technical objections that cannot be resolved.

In this case, *speaking for myself alone*, I don't know of any more
text changes that would meet the objections that have been raised.
In fact, the only suggestion for change that has been made is to drop
the whole idea. The WG could decide to do that. That's not my decision
to make; as an author of a WG draft, I do what the WG requests.
 
> It gives me great cause for alarm to observe these proceedings.

There's no cause for alarm. There's a difference of opinion - some 
people have expressed support for the proposal, others have said
it is intrinsically bad. Further wordsmithing can't fix that.

There are thoughts about how a WG can resolve such a difference of
opinion in https://tools.ietf.org/html/rfc7282 .

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 May 2019 11:28:49 +1200

Thanks David. In my opinion the main issue now is for the WG to decide whether to proceed or to drop the whole idea, but I comment below assuming that we decide to proceed.

On 04-May-19 19:25, David Farmer wrote:
> Basically, I support this document, in the near-term, I think it will be useful in some specialized situations, longer-term it may have more general applicability. 
> 
> Below are some issues from my detailed review of the current version, it has been two or three versions since my last detailed review;
> 
> 1. In my opinion, the following sentence contradicts part of the applicability statement. I never really liked the document talking about unmanaged networks, but I couldn't articulate a reason why, until now. My recommendation is to remove it
> 

I agree that we should drop "unmanaged" for now. I could argue with some of your points below, but I think it's a distraction and it can be left for future work.

> Unmanaged networks do not usually have an administrator, by definition they are not managed. I think maybe this was intended to suggest an ISP or CPE manufacture could ship IPv6-Only CPE with this flag set by default. However, that would also violate the Applicability Statement, neither the ISP or CPE manufacture could have the certainty required by the Applicability Statement that IPv4 is not in use on the local network. 
> 
> I think the use of this flag on unmanaged networks is ill-advised and should not be discussed in the document. The trade-offs involved in using this flag as it is currently designed requires someone, the administrator, with intimate knowledge of the local network to decide if this flag should be set or not on the router's link. Discussing the use of the flag on unmanaged networks implies this level of knowledge may not be necessary. The remainder of the paragraph already covers "networks without the ability to filter L2 traffic."
> 
> If you intend this flag to be used on unmanaged networks it will need to be much more automatic, as designed it requires an administrator to decide its appropriate setting. 
> 
> It might even be appropriate to add that this flag is only intended for use on managed networks, that have an administrator, but as long as you don't mention unmanaged networks, that is good enough for me.
> 
> 2. I think Section 6 should additionally recommend the use of Router Guard [RFC6105], it is discussed in the Security Considerations Section, but I think it should be in Section 6 as well. Without Router Guard an IPv6-Only network is open to the attack discussed in paragraph 4 (not including the bullets) of the Security Considerations Section. Therefore, I think the use of Router Guard should be recommended with normative language in Section 6.

Seems reasonable to me.

> 3. In Section 7, paragraph 5 seems to repeat the idea in the last half of paragraph 3, my recommendation is to delete paragraph 5.

Yes, good catch.

> 4. Previously I asked for the following (slightly edited) and I don't see where it has been addressed, nor do I find an email explaining why it was not addressed. The only email I found was Brian saying "your suggestions below make sense to me," in my mind that included the following;
> 
> Finally how about some additional non-normative discussion about taking precautions to prevent unsuspecting WiFi users from accidentally connecting IPv4-Only WiFi hosts to IPv6-Only WiFi links. Possibly by including "IPv6" or "IPv6-Only" in the name of open SSIDs to help inform unsuspecting WiFi users, using secured SSIDs to prevent unsuspecting WiFi users from connecting all, or using 802.11u Access Network Query Protocol (ANQP) with "Address type available" for IPv6 and "Address type not available" for IPv4 to inform the connecting WiFi host instead of the user. Putting this in an appendix would be fine with me. 

Yes, this got lost on the editing room floor. I still think it's useful.

Thanks
   Brian
 
> Remember the IETF's own discussions regarding this issue. If the IETF isn't willing to have its default WiFi be IPv6-only, maybe some caution is warranted for the general population of the earth. :) 
> 
> Thanks
> 
> 
> 
> On Mon, Apr 29, 2019 at 5:02 AM Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     At the 6man meeting at IETF 104 in Prague there was support to close the working group last call and advance
>     Please give objections and comments to this decision to the mailing list, by 2019-05-13.
> 
>     Best regards,
>     Ole, 6man co-chair
>     [email-masked] <mailto:[email-masked]>
> David Farmer               Email:farmer@umn..edu <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 May 2019 09:54:01 +1000

> > This interpretation of the working group process is flawed. This is not

<snip>

> may be advanced even with technical objections that cannot be resolved.

This is an important point.

There are some ideas that some people might not fundamentally accept
(for me, it is DNS information in RAs, and /127s). However, minority
objection shouldn't prevent the idea being accepted if the majority
rough consensus on it.

It is worth reading RFC 7282, "On Consensus and Humming in the IETF",
to understand that rough consensus doesn't mean unanimous agreement,
or that a few objections to a mechanism or disagreement as to whether
a problem exists or not, means that consensus cannot be achieved.

On Consensus and Humming in the IETF
https://tools.ietf.org/html/rfc7282

(Related to DNS information in RAs, and Alex's wanting to be removed
as an author from the 64 bit IID RFC, I'm an acknowledged contributor
to the most recent DNS in RA RFC. I've always fundamentally disagreed
with the idea, however I still contributed to that draft to make it
work better for people who choose to do that. In the future, I may
change my mind about DNS information in RAs. If unanimity was
required, I alone could have stopped this RFC being published because
of my disagreement.)

> opinion in https://tools.ietf.org/html/rfc7282 .

Ok, robustness in reference redundancy ;-)

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 May 2019 10:40:25 +1000

Hi David, Brian,

On Mon, 6 May 2019 at 09:29, Brian E Carpenter
<[email-masked]> wrote:

<snip>

> > Finally how about some additional non-normative discussion about taking precautions to prevent unsuspecting WiFi users from accidentally connecting IPv4-Only WiFi hosts to IPv6-Only WiFi links.

I don't think we have to worry about that. An IPv4 only host attached
to an IPv6 only network should already be generating informative
enough error messages for its users to indicate that network
connectivity is not working (such as those we already see in web
browsers when our Internet goes down, or network connectivity problem
popup alerts in window manager notification areas).

> Possibly by including "IPv6" or "IPv6-Only" in the name of open SSIDs to help inform unsuspecting WiFi users,

I'd generally try to avoid providing that advice. It is overloading
SSIDs with information they're not intending to carry, and also is
assuming that the end-users know what the terms "IPv4" or "IPv6" mean.
Most end-users don't. It's only really valid when the end-users are
networking technology aware (IETF and other network engineering
conferences, technical labs, but not many other situations).

> using secured SSIDs to prevent unsuspecting WiFi users from connecting all, or using 802.11u Access Network Query Protocol (ANQP) with "Address type available" for IPv6 and "Address type not available" for IPv4 to inform the connecting WiFi host instead of the user. Putting this in an appendix would be fine with me.
>

It sounds like ANQP is the theoretically correct way to solve this
problem, as it is a network layer agnostic protocol.

However, it seems it is limited to 802.11, where as the issue of
excessive link-layer IPv4 broadcasts can also occur on wired networks
(c.f., RFC6820 - "Address Resolution Problems in Large Data Center
Networks", and I saw link-layer broadcast traffic being a potential
issue on large wired LANs (1200+ PCs in one instance, 4000+ in
another) in large enterprises in the late 1990s (this latter
experience is why I support this ID).

The other thing about using RAs for this is that all IPv6 enabled
hosts are going to understand them because it is a underpinning
requirement for an IPv6 implementation. Hosts that can attach
successfully to an IPv6 Only link are already assured to be able to
receive and process RAs, they just need to be updated to support this
flag, verses having an entirely new ANQP protocol implementation.

Regards,
Mark.

---

From: Job Snijders <[email-masked]>
Date: Mon, 6 May 2019 11:50:08 +0000

i think we are experiencing a breakdown in both communication and
process. this is very unfortunate.

i'll rephrase my words in context of the ietf process: i will appeal,
because i've observed extreme discontent

whoever shepherds this draft should note this.

Kind regards,

Job

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 May 2019 09:47:49 +1200

> process. this is very unfortunate.

Job, I don't think there is any failure of communication. It's
clear enough that you (and Nick and Sander) have reached the
conclusion that the operational costs of the proposal greatly
exceed its value. Other people have reached the opposite
conclusion.

There's also no process failure, because we're still in the process
of determining WG consensus (see the subject field of this thread).
What the WG Chair will conclude is unknown.

> because i've observed extreme discontent

Of course you are entitled to appeal a WG recommendation, or to
raise objections during IETF Last Call, or to appeal an IESG
decision. But we're not there yet.
 
> whoever shepherds this draft should note this.

Actually, no, they shouldn't, because they should reach their
conclusion based on the technical arguments.

Regards,
    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 7 May 2019 08:40:34 +0200 (CEST)

On Fri, 3 May 2019, Gyan Mishra wrote:

> I forgot to mention that Send RFC 3971 is now being supported after a 
> long time by routers but for the endpoint OS support may be a a lot

SEND is basically useless compared to SAVI (first-hop-security). If you 
don't secure your L2 then you're still open to so many attack vectors that 
SEND doesn't help you.

If you don't implement SAVI-like features to secure your L2, then the 
proposed v6-only flag makes no difference in security. With or without it, 
you don't have any security and should have no expectation of security.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 7 May 2019 08:46:43 +0200 (CEST)

> Please give objections and comments to this decision to the mailing list, by 2019-05-13.

I have re-read -05 and think it's useful, in good shape, and I support its 
advancement.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 7 May 2019 14:31:43 +0200

> conclusion based on the technical arguments.

Being able to deal with it in an operational context *IS* a technical argument...

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 7 May 2019 14:41:49 +0200

Hi Brian,

> exceed its value. Other people have reached the opposite

This proposal weighs advantages to a relatively low number of mobile (and maybe enterprise) networks against having to deal with any resulting operational issues in millions of unmanaged home networks.

I understand the people arguing in favour of this. I see that it would make their lives easier, save some battery life etc. But I work a lot with the smaller ISPs and their customers. I know first hand how incredibly hard it is to do remote debugging in an unmanaged third-party network. When the internet was a research project, an academic network and even a business network, I would love to see this draft. But now that the IETF makes protocols that extend into the domains of people who don't have any networking clue we have a duty to make our protocols easy to use, understand and debug. Protocols that are extremely resilient in those domains. And this draft goes against all that.

Please don't pretend that the IETF makes protocols for network engineers, and listen to the rest of the user base and their representatives as well.

Cheers,
Sander

---

From: Bob Hinden <[email-masked]>
Date: Tue, 7 May 2019 09:31:09 -0700

Sander,

> On May 7, 2019, at 5:41 AM, Sander Steffann <[email-masked]> wrote:
> 
> Hi Brian,
> 

Enterprise networks are an important use case for this proposal.

The draft seems to me to be clear it is focused on managed networks.   It uses the word “administrator” 12 times.   There is, of course, no administrator on unmanaged networks.

Would it help if the draft said the focus is for managed networks?

Bob

---

From: Sander Steffann <[email-masked]>
Date: Tue, 7 May 2019 18:54:08 +0200

Hi Bob,

> Would it help if the draft said the focus is for managed networks?

Hmm. Just stating where it's supposed to be used doesn't prevent abuse in other situations. If we can actually limit the potential impact on devices on unmanaged networks then that would be great.

I understand this is not easy, as the same devices will be used on both networks.

Cheers,
Sander

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 07 May 2019 17:35:38 +0000

On 7 May 2019, at 16:54, Sander Steffann wrote:

> Hmm. Just stating where it's supposed to be used doesn't prevent abuse 
> in other situations. If we can actually limit the potential impact on 
> devices on unmanaged networks then that would be great.
>

Given as of the last draft there is an option to disable processing 
despite implementing, OS vendors can implement the draft and do what 
they think suits their users.   Even more so they might leave the 
default to “off” for now as an “advanced option to turn on” and 
with a major OS update, once the world has moved on, flip the switch in 
the future.

I can foresee a time when ISPs really don’t want to deal with the IPv4 
for end users anymore and you’ll be happy to have the option then.  
Based on 8+ years of an ipv6-only unmanaged home network (but some code 
under my control) I can tell you that I’ll be happy if more vendors 
start thinking “what if there’s no DCHPv4 or IPv4 gateway 
anymore?” now!  Especially all the smart gadgets that make it into the 
homes at the moment and multi-function devices.  If it doesn’t happen 
soon, your support calls will come the moment you want to have the flag 
and turn it on and it’s not there.  This is investing in a future to 
come now with the option to leave it off until we get to the point.

That said I am sure ISPs already talking to many of these “smart 
entertainment device vendors” given they probably get enough support 
calls for them anyway..  It’s in your hands to give them an extra bit 
to better prepare for the future, and possibly in the meantime improving 
the dual-stack IPv6 as well.

/bz

---

From: Philip Homburg <[email-masked]>
Date: Tue, 07 May 2019 20:21:55 +0200

> despite implementing, OS vendors can implement the draft and do
> what they think suits their users.   Even more so they might leave
> the default to off for now as an advanced option to turn on and
> with a major OS update, once the world has moved on, flip the switch
> in the future.

This draft has two perspectives:
- a network perspective (hosts trying to configure IPv4 waste bandwidth)
- a host perspective (trying to use IPv4 may impact battery lifetime)

If this draft was part of a complete discussion on what to do with IPv4 
and it became clear that this flag was required, then I would have no
problem supporting the draft.

But nobody is doing any work on what IPv4 should look like in the future.
This draft is just a small hammer looking for a nail.

Without a clear idea of where we want to take IPv4 we can see some things
happening:
- To start with the host perspective. It is very like that many network will
  not set this flag. Simply because there is no operator to decide if this
  flag can be set or not. So hosts will implement counter measures to save
  battery life even if the flag is not set.

  Then because of security risks, it makes sense for hosts to either not
  implement it of leave it off by default.

  Because there is no analysis from an IPv4 perspective, we don't actually
  know if this draft is needed and how much effect it will have. There is
  justs some hints from hosts that are not optimized to live without IPv4.

- for a network, if many hosts do not implement this flag, then the network 
  somehow has to cope. If the vast majority of the hosts do not implement
  this draft then implementing this flag in a router is mostly an accident
  waiting to happen. Something that hardly any network engineer in the 
  field can quickly diagnose. So it makes sense for routers to not implement
  this draft. Which may reinforce host behavior to not rely on this flag.

- Finally, there is an existing code point in DHCPv4 to turn of IPv4 link
  local configuration. Which is safe to implement for hosts and not hard
  to provide for router vendors.

So we have a draft that clearly makes security worse. That has operational
risks if widely implemented. And at same time anybody sane will not
implement the draft. So it probably live on as a useles flag that people will 
remember to filter on their networks.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 07 May 2019 18:33:50 +0000

> But nobody is doing any work on what IPv4 should look like in the 

You mean inside the IETF given sunset4 was concluded without conclusion?

What does SNA, Frame Relay, FDDI, Token Ring, … ok bad examples … 
what does IPX/SPX, Appletalk, VINES IP, XNS, NetBIOS, .. look like 
today?  Should we assume IPv4 will have a different fate?

/bz

---

From: David Farmer <[email-masked]>
Date: Tue, 7 May 2019 13:48:57 -0500

> - a host perspective (trying to use IPv4 may impact battery lifetime)

While I support this draft, I very much support a broader look at the
problems and solutions in a world where IPv4 isn't the dominant Internet
Protocol, IPv6-Only is one manifestation of this world, but I'm quite sure
there are others. I'm thinking something similar to RFC6104 but for the
world where IPv4 isn't the dominant Internet Protocol anymore.

> remember to filter on their networks.

I will grant you that this draft doesn't improve security, but then by my
assessment, it doesn't make things fundamentally any worse either. An
IPv4-only network, without accounting for IPv6 vulnerabilities, is
susceptible to all sort of IPv6 based attacks the most IT or security staff
will be incapable of diagnosing.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 7 May 2019 20:13:38 +0100

Bob Hinden wrote on 07/05/2019 17:31:
> The draft seems to me to be clear it is focused on managed networks.
> It uses the word “administrator” 12 times.   There is, of course, no
> administrator on unmanaged networks.
> 
Not really, no, because when you look at it more closely, it becomes 
apparent that the flag is redundant on managed networks.

What's important about managed networks is that they're managed.  I.e. 
that whatever policy is put in place by the administrator can be 
enforced.  v6only does not and cannot enforce anything, which means that 
from the point of view of policy or enterprise management, it fails 
before it leaves the block.  It fails because all it does is provide an 
advisory hint to the operating system about the intentions of the 
network administrator.

Drilling down further and looking at the issue from the point of view of 
an enterprise network, management would encompass either device 
management or fine-grained network access control, or both.  In each 
case, the management will be enforced because if it's not enforced, it's 
not management: it's hand-waving.

For device management, it might be e.g. Windows group policy, or macos 
workgroup manager, or some orchestration tool (puppet / saltstack / 
etc), or some COTS product to do all this - there are plenty out there. 
The point is that the management of the devices on the network will be 
centralised and will give the administrators of the network the ability 
to enable or disable ipv4 by application of enforced policy.

No sane operating system manufacturer will leave the v6only option 
enabled by default on an out-of-the-box installation because the 
possibility of mischief is far too great. This means that if the 
administrator wants to change this default, they will need to touch the 
configuration of each installation.

But here's the thing: if they already have to change the default 
configuration to enable v6only, why wouldn't they go the whole hog and 
just disable v4 completely?  More to the point, if they need to delve 
into this level of operating system protocol capabilities, their policy 
management tools will be sufficiently fine-grained to enable or disable 
any specific protocol on any specific network that they choose.  In 
other words, the v6only flag is almost entirely irrelevant for managed 
networks where the management capabilities are done on the host devices. 
  The job can be done more simply and more reliably by using existing tools.

The other type of managed network is where control of the network access 
is managed.  I've gone into some detail on this scenario on several 
occasions before, so please forgive me for quoting these URLs:

https://mailarchive.ietf.org/arch/msg/ipv6/NIJ194PI8CLkuZT8U_jKEOY01QI
https://mailarchive.ietf.org/arch/msg/ipv6/a9KBvO88PlPrO0kLr83VOBlGmpw

Summarising:

- L2 ACLs provide vastly superior functionality, and work today.

- even L2 ACLs on core links can reduce the problems assertions in the 
v6only-flag problem statement to background noise.

- gigantic l2 domains were busted about 30 years ago as being terrible 
network design and the ietf has no responsibility to create workarounds 
for people who implement terrible network designs.  And if you really 
need to implement gigantic l2 domains, you need kit which is fit for 
purpose.

I.e. if you want actual management, then you need to manage, and that 
mandates enforcement.  The larger your network, the more effort you need 
to put into designing it properly - and managing it using appropriate 
equipment.

I'm sure it would be possible to contrive scenarios where marginal gain 
in functionality is achieved with the v6only flag, but in 18 months of 
discussion (and draft-perreault-sunset4-noipv4 before it), not even a 
single credible use case has come up where the alternatives weren't better.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 7 May 2019 20:13:54 +0100

Bjoern A. Zeeb wrote on 07/05/2019 19:33:
> What does SNA, Frame Relay, FDDI, Token Ring, … ok bad examples … what 
> does IPX/SPX, Appletalk, VINES IP, XNS, NetBIOS, .. look like today?  

They died all by themselves, and no-one cared.

Nick

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 7 May 2019 14:43:06 -0500

Thus spake Bjoern A. Zeeb ([email-masked]) on Tue, May 07, 2019 at 06:33:50PM +0000:
> What does SNA, Frame Relay, FDDI, Token Ring, … ok bad examples … what does
> IPX/SPX, Appletalk, VINES IP, XNS, NetBIOS, .. look like today?  Should we
> assume IPv4 will have a different fate?

I had worked on migrations of IPX, Appletalk, NetBIOS, and DECNET to IPv4
in a large academic network.  We can debate if you want to call that
a "managed" environment! ;-)

The lesson to me was that they were all migrated in the same manner, by 
removing the services that were making the advertisements causing the
clients to use it.  Slowly as the fileservers, printers, and so on were
turned off the clients became irrelevant.  I recall the SAP broadcast
load at its peak as decidedly non-trivial.

If you want to draw an analogy to IPv4, this would be when the 'A' records 
disappear from DNS and nothing is advertised via mDNS.  There was not a 
"don't use IPX flag" in IPv4 for example, though I don't recall if
netware, apple, or windows did anything special at the application layer.
By the time we got all this turned off, the OS vendors certainly had us 
beat as these protocol stacks were not on by default.

I don't see how IPv4 would be much different.  Yes, we could provide a
hint flags, but removing 'A' records from DNS and whatever the equivalent 
is in mDNS would be more robust.  That leaves with just the IPv4 clients
chirping, which is either mitigated by ethertype filtering in managed
environments, or otherwise negligible in volume in unmanaged networks.

Dale

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 7 May 2019 21:26:02 +0000

> Please give objections and comments to this decision to the mailing list, by 2019-05-13.

I've not changed my mind on this. The flag seems unnecessary, and if anything, can cause confusion and problems. It seems to have been motivated by people wanting to see what it would be like to get all IPv4 users off the network, at an IETF meeting, and then people have been trying to make the case that it would be generically useful.

There are other ways of sunsetting IPv4 if a network wants to, exactly the same as any number of older network protocols have been obsoleted, never needing any new explicit flag for the purpose. And I would way prefer for equipment vendors themselves, such as smartphone vendors, to create their own heuristics, if they feel that IPv4 is so wasteful of battery power. The onus should be on them, IMO, not on the IETF, and certainly not on other users of the network who might not know or pay attention to that flag.

The KISS principle holds. Only add complications if it's essential.

Bert

---

From: David Farmer <[email-masked]>
Date: Tue, 7 May 2019 17:23:01 -0500

Whoops, I lost the list somehow.

---------- Forwarded message ---------
From: David Farmer <[email-masked]>
Date: Tue, May 7, 2019 at 5:13 PM
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
To: Manfredi (US), Albert E <[email-masked]>

On Tue, May 7, 2019 at 4:26 PM Manfredi (US), Albert E <
[email-masked]> wrote:

> I've not changed my mind on this. The flag seems unnecessary, and if
> anything, can cause confusion and problems. It seems to have been motivated
> by people wanting to see what it would be like to get all IPv4 users off
> the network, at an IETF meeting, and then people have been trying to make
> the case that it would be generically useful.
>
> There are other ways of sunsetting IPv4 if a network wants to, exactly the
> same as any number of older network protocols have been obsoleted, never
> needing any new explicit flag for the purpose. And I would way prefer for
> equipment vendors themselves, such as smartphone vendors, to create their
> own heuristics, if they feel that IPv4 is so wasteful of battery power. The
> onus should be on them, IMO, not on the IETF, and certainly not on other
> users of the network who might not know or pay attention to that flag.
>

The two alternatives to this flag I've heard discussed are;

1. Layer 2 filtering of Etherthypes 0x0800 and 0x0806
2. RFC2563 to signal host to not use Link-local IPv4

The problem is, these two options are incompatible with each other. You can
either block IPv4 traffic or signal the host that not to use Link-local
IPv4, you really can't do both at the same time.

I just had a thought, what if the host behavior for the flag was changed to
be more like the behavior specified for RFC2563?

In the presence of the flag, a host MAY attempt DHCPv4 a limited number of
times, but MUST NOT perform Stateless Auto-Configuration of an IPv4 address
and MUST NOT perform any service discovery (such as mDNS) unless it
receives a unicast IPv4 address from DHCPv4 server or relay on the network.

This way a Rogue RA with this flag set is much less dangerous than a Rouge
DHCPv4 server and doesn't directly impede IPv4 internet access. It would
impede Link-local IPv4, but only if there is not a functioning DHCPv4
server or the attacker can also block the DHCPv4 process in addition to
announcing a rogue RA with the flag set.

Would that be acceptable?

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 7 May 2019 22:49:46 +0000

From: ipv6 <[email-masked]> On Behalf Of David Farmer

> 2. RFC2563 to signal host to not use Link-local IPv4

And/or, do not return A records after DNS queries, switch off DHCPv4 entirely, do not make servers reachable even with statically configured IPv4 addresses, do not allow routers to respond to ARP queries. Let the hosts decide for themselves, how long and hard they want to keep trying to use IPv4. Anyone worried about battery power can certainly take those hints! Those not worried, no problem.

The intention of this flag, from those who thought it was important, has always been to prevent *all IPv4 traffic*. And yet, that remains unachievable anyway. You, the user, even if on a well-managed enterprise network, in your office or in your lab, can always install your own IPv4-only peripheral device, to reach with your own dual-stack host. So flag or no flag, you won't necessarily achieve this strict IPv6-only goal.

And quite frankly, who cares? In most networks, managed or unmanaged, no one should care. If you manage an enterprise network, the best you can do is only set up enterprise hosts, servers, and routers, for only IPv6. Employ the measures listed above, and you're as close to being done as you'll ever be. And no new flag needed.

Hey, whether you create a new flag or not, you will require updated logic in hosts, to save battery power. Let the hosts which care about this update themselves, without needing any new flag, and leave the others be.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 11:13:11 +1200

> I understand this is not easy, as the same devices will be used on both networks.

I think we already agreed to remove the sentence about unmanaged networks. The recommended default settings for both hosts and routers would mean that the bit is never set in umanaged networks. Since the bit doesn't even exist in legacy devices, I don't see any risk factor.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 11:18:50 +1200

Nick, excuse top posting but it seems to me that you are
assuming that in a managed network, the hosts are all
managed too. That's certainly a false assumption in my
experienced: managed routers and access points with
BYOD hosts is a very common scenario.

It remains true that even so, in many cases the managed
network could be configured to block IPv4 at layer 2.
I can't argue against that argument.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 11:23:56 +1200

> And quite frankly, who cares? In most networks, managed or unmanaged, no one should care.

We've always said that the aim was to save battery (and spectrum) that would otherwise be consumed by useless IPv4 packets, including multicasts. It's certainly a judgment call whether anybody cares.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 11:50:30 +1200

> But nobody is doing any work on what IPv4 should look like in the future.

I don't understand that sentence. IPv4 is a legacy protocol,
so it will simply fade away.

> This draft is just a small hammer looking for a nail.

The nail has never been unknown, but some people claim it's too
small to be worth hammering.
 
>   battery life even if the flag is not set.

I cerainly hope that's true.

>   implement it of leave it off by default.

The draft already recommends configuring it off by default.

>   know if this draft is needed and how much effect it will have. 

We know that we're talking about a few percent of the traffic on an
IPv6-only network. Quantifying the effect on battery life is not
a reasonable task.

>   There is
>   waiting to happen. 

It's unclear to me what that accident might be, apart from what is
already in the security considerations.

>   Something that hardly any network engineer in the 

No disagreement there. I think we say that in the draft too.

> So we have a draft that clearly makes security worse. 

Not clear to me. Rogue RAs are a well-known danger already.

> That has operational

Sorry but that's a FUD argument.

   Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 7 May 2019 18:50:34 -0500

Furthermore, on a mobile device, you can't just turn off IPv4 on the device
unless anywhere it goes will not have IPv4.  In this case want to turn off
IPv4 on certain networks, not all networks, not even all dual-stack
networks, but only some that we designate as IPv6-Only networks. This is an
important distinction, and it means turning off IPv4 on the host isn't
really an option.

The potentially bad side effects of the flag are a valid concern, but If
the meaning of the flag is changed to be similar to RFC2563, then I think
that mitigates the bad side effects completely.  Basically, the flag has no
meaning or effect by itself, it only has meaning if the host also doesn't
receive a DHCPv4 response. This way you set the flag in the IPv6 RA and you
also have to either layer 2 filter ether types 0x0800 and 0x0806 or
otherwise ensure there are no DHCPv4 responses on the network.

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 11:52:05 +1200

> Being able to deal with it in an operational context *IS* a technical argument...

Correct. But my comment was about the promise to appeal
a decision that hasn't even been made yet.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 12:11:27 +1200

Speaking for myself:

> In the presence of the flag, a host MAY attempt DHCPv4 a limited number of times, but MUST NOT perform Stateless Auto-Configuration of an IPv4 address and MUST NOT perform any service discovery (such as mDNS) unless it receives a unicast IPv4 address from DHCPv4 server or relay on the network.

In effect that expands the current SHOULD NOT text, which says:

>>> A host that receives only RAs with the flag set to 1 SHOULD NOT
>>> attempt any IPv4 operations, unless it subsequently receives at least
>>> one RA with the flag set to zero.

I think that's a reasonable addition, if the document proceeds.

   Brian

On 08-May-19 10:23, David Farmer wrote:
> From: *David Farmer* <[email-masked] <mailto:[email-masked]>>
> To: Manfredi (US), Albert E <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> 
> On Tue, May 7, 2019 at 4:26 PM Manfredi (US), Albert E <[email-masked] <mailto:[email-masked]>> wrote:
> 
> The problem is, these two options are incompatible with each other. You can either block IPv4 traffic or signal the host that not to use Link-local IPv4, you really can't do both at the same time.
> 
> I just had a thought, what if the host behavior for the flag was changed to be more like the behavior specified for RFC2563? 
> 
> In the presence of the flag, a host MAY attempt DHCPv4 a limited number of times, but MUST NOT perform Stateless Auto-Configuration of an IPv4 address and MUST NOT perform any service discovery (such as mDNS) unless it receives a unicast IPv4 address from DHCPv4 server or relay on the network.
> 
> This way a Rogue RA with this flag set is much less dangerous than a Rouge DHCPv4 server and doesn't directly impede IPv4 internet access. It would impede Link-local IPv4, but only if there is not a functioning DHCPv4 server or the attacker can also block the DHCPv4 process in addition to announcing a rogue RA with the flag set.
>  
> David Farmer               Email:[email-masked] <mailto:[email-masked]>
> David Farmer               Email:[email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 May 2019 11:08:26 +1000

> I can't argue against that argument.

Doing that is a lot more work than enabling a flag on typically no more
than the 2 IPv6 routers on the link would be.

Computers are about making things easier, so we get to spend that saved
time on something else.

That's the only reason automated mechanisms like DHCP exist. ARP exists for
the same reason. The jobs they do could have been done manually on each
individual device. In the case of DHCP, it was done manually before DHCP
was invented and supported on PCs. DHCP and ARP fundamentally save time.

Saving battery on mobile devices saves people having to spend time more
regularly recharging their batteries.

This mechanism would be also applicable in data centres. Link-layer
broadcasts are a problem in them too.

Address Resolution Problems in Large Data Center Networks

https://tools.ietf.org/html/rfc6820

Reducing and eliminating IPv4 link-layer broadcasts on large data centre
links delays having to build more links as host numbers increase. Delaying,
reducing and ideally completely avoiding that work saves time.

Regards,
Mark.

---

From: Raymond Burkholder <[email-masked]>
Date: Tue, 7 May 2019 19:53:12 -0600

On 2019-05-07 7:08 p.m., Mark Smith wrote:
> On Wed., 8 May 2019, 09:19 Brian E Carpenter, 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Doing that is a lot more work than enabling a flag on typically no 
> more than the 2 IPv6 routers on the link would be.

Did we already go through the thought process of working with the fact 
that there is already an implicit ipv6-only flag?  Yep.  If there are no 
ipv4 addresses on key gateway links, ipv4 devices won't get anywhere, 
and will either automatically or be required to manually convert over to 
ipv6.  Windows and Linux already have an ipv6 preference I believe.

>
> That's the only reason automated mechanisms like DHCP exist. ARP 
> exists for the same reason. The jobs they do could have been done 
> manually on each individual device. In the case of DHCP, it was done 
> manually before DHCP was invented and supported on PCs. DHCP and ARP 
> fundamentally save time.
If this stuff is turned off, then devices will see there is no ipv4.

> Saving battery on mobile devices saves people having to spend time 
> more regularly recharging their batteries.
Is that up to the network operator to fix?  As time progresses, I think 
there will be a natural evolution away from ipv4.  Marketing pressures 
and market forces, etc.  Newer mobile which might be built to be aware 
of the flag, could just as readily be designed to deal with the 
ipv4/ipv6 issue implicitly.  No see'um ipv4, no use'um ipv4.

> broadcasts are a problem in them too.
See the 'gigantic l2 domains busted' comment further down.  Data center 
operators will probably be aware of their ip4/ipv6 addressing, and will 
be 'addressing' this via end to end (re-)configuration 
(removal/disabling ipv4 stacks).
>
> Reducing and eliminating IPv4 link-layer broadcasts on large data 
> centre links delays having to build more links as host numbers 
> increase. Delaying, reducing and ideally completely avoiding that work 
> saves time.
I'm not sure if the flag buys anything.  Equipment will have to be 
upgraded to be aware of the flag.  Why not just let it evolve away. Ipv4 
is but 'some percentage' of link-layer broadcast.  What with beacons, 
hello's, ND, ... would there be a noticable savings?  In ipv4's case, in 
dhcp, there is the exponential back off to nothingness.  After that, 
arps won't happen because there are no source/destination addresses to 
be resolved.  If an interface can't get an address, the mDNS and related 
services don't talk much.

ipv4 death via suffocation, in other words?

>     > apparent that the flag is redundant on managed networks.
I would tend to agree that a manager/administrator of said network will 
already be dealing with (re-)addressing issues and, well, legacy 
apparatus which they are stuck with.

>     > just disable v4 completely?
>
Agree.

>     > single credible use case has come up where the alternatives
Agree.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 7 May 2019 21:53:26 -0400

Phil

My take initially on this was not supporting due to some of the reasons mentioned.

I really think this IPv6 only flag is futuristic and understand it takes time for OS vendors to implement the flag which is the reason stated to introduce now versus waiting to hit a tipping point towards IPv6 only.

I am glad that we added the option to disable the flag and only enable when ready and on managed networks as I agree on unmanaged this flag really does not apply.

We should make the default for the flag disabled for all OS’s and at the administrator or operators guidance to enable as necessary which completely makes sense and does help eliminate a lot of the issues brought up in this thread and in essence  “defers” the option for future use cases on managed networks only.  

Doing so we get the best of both worlds eliminating issues and security vulnerablities as well as other cons of this flag introducing now and allows the OS vendors to have a long enough lead time to introduce the flag for when managed networks maybe ready to use in the foreseeable future.

In the security section of this draft if we can we add some recommendations for first hop security to protect IPv6 only networks using any DHCPv6 stateful or stateless scenario combinations using security features such as IPv6 snooping, IPv6 source guard to deny traffic from unknown sources and RA guard to only allow RA to be sent from the trusted L2 uplinks to the FHRP routers on the subnet.
Sent from my iPhone

> On May 7, 2019, at 2:33 PM, Bjoern A. Zeeb <[email-masked]> wrote:
> 
> What does SNA, Frame Relay, FDDI, Token Ring, … ok bad examples … what does IPX/SPX, Appletalk, VINES IP, XNS, NetBIOS, .. look like today?  Should we assume IPv4 will have a different fate?
> 
> /bz
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 May 2019 13:48:44 +1000

On Wed., 8 May 2019, 11:53 Raymond Burkholder, <[email-masked]> wrote:

> ipv4 addresses on key gateway links, ipv4 devices won't get anywhere, and
> will either automatically or be required to manually convert over to ipv6.
> Windows and Linux already have an ipv6 preference I believe.
>

Would I be correct in assuming you haven't read the draft at all?

>
> That's the only reason automated mechanisms like DHCP exist. ARP exists
> for the same reason. The jobs they do could have been done manually on each
> there will be a natural evolution away from ipv4.  Marketing pressures and
> market forces, etc.  Newer mobile which might be built to be aware of the
> flag, could just as readily be designed to deal with the ipv4/ipv6 issue
> implicitly.  No see'um ipv4, no use'um ipv4.
>
> operators will probably be aware of their ip4/ipv6 addressing, and will be
> 'addressing' this via end to end (re-)configuration (removal/disabling ipv4
> stacks).
>
>
> dhcp, there is the exponential back off to nothingness.  After that, arps
> won't happen because there are no source/destination addresses to be
> resolved.  If an interface can't get an address, the mDNS and related
> already be dealing with (re-)addressing issues and, well, legacy apparatus
> which they are stuck with.
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 8 May 2019 00:51:08 -0400

I like this option below gives flexibility to the managed networks or use
cases where the desktops are not yet ready for IPv6 only and they can flip
the switch when the time is right in the future.

***From B Zeeb***

Gyan

-- 
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 8 May 2019 01:08:57 -0400

Bob & Brian

At the bottom of page 8 it says...

  An attack would not succeed if the dual stack hosts had active IPv4
configuration. As specified in Section 7, a dual stack host will ignore the
flag if it has active IPv4 configuration.

So lets say Day 0 you have 4 Default gateways and you are trying to migrate
hosts from Dual stack to IPv6 only you could change each of the 4 Default
routers to change to start setting the flag=1 and at that point until the
last router sets the flag the hosts on the subnet are able to communicate
with the DHCPv6 server and have their lease until it hits the rebind time
to renew.  So lets say once the last router sets his flag=1 so now we are
sending all 1's by all default routers the hosts still all have active
leases and lets say the lease time is 7 days.  So then what happens.  Do
they continue to work until thee rebind time to renew and then IPv4 gets
turned off and then all hosts are then migrated dynamically to IPv6-only.

So I guess I can see this flag being actually a very nice method to migrate
all hosts on a subnet from dual stack to IPv6 only dynamically on managed
networks.

>From the support perspective I can see this being a big win and now you can
eliminate from the "Access" user community getting the user community
within an enterprise quickly converted to IPv6 only so that only IPv6 needs
to be supported versus IPv4.  I can see many benefits to that one of which
being IPv4 address depletion but even if you use private space internally
and proxy out to the internet their are gains to be made from a IPv4
address space management overhead perspective and DHCPv4 scopes to be
managed that can all be sunset.

As far as my previous points of why go IPv6 only now I can definitely see
why now even though the internet is far behind that tackling the user
community desktops is an easy "win" so to speak for IPv6 to get converted
to IPv4 and then you can alway use 6to4 nat & 6to4 DNS to communicate with
Servers within the enterprise and 6to4 proxy to communicate IPv4 out to the
internet.

>From a migration strategy you could do the following:

1. Set the flag=1 and migrate Access User community subnets to IPv6 only.
2.  Migrate all internal enterprise servers from Dual stack to IPv6 only.

Use 6to4 nat 6to4 dns and 6to4 proxy to get the v4 resources

Now the entire enterprise is 100% IPv6 only.

I believe this could be a good use case to add to the draft.  I don't think
I saw it mentioned.

Gyan

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 8 May 2019 01:24:00 -0400

Updated migration steps to IPv6-only below:

Can we add this to the draft as a use case for deployment?

As far as IPv6 address management over IPv4 since IPv4 is classful it more
painful and IPv6 his hiearchial so their is tremendous gain as far as
administrative overhead of elimination of IPv4 to go to IPv6-only "NOW!!".

I think there could be a tremendous cost saving from an IT opex & capex
perspective as well.

Day 0 - IPv4 only
Day 1 - Migrate User access community to Dual Stack - IPv6 preferred over
IPv4 by default for all OS's
Day 2 - Migrate all server to Dual Stack - IPv6 preferred over IPv4 by
default for all OS's
Day 3- Set ipv6-only flag=1 all Default routers all subnets - migrating all
User access community to IPv6-only. Enable 6to4 nat, 6to4dns, 6to4 proxy.
Day 4 - Migrate all server to IPv6 only.  Eliminate 6to4 nat & 6to4 dns
internally within the enterprise as now all cilent/server communication is
over IPv6 only.  6to4 proxy remains in place until such time where 100% of
the internet is at a mimimum all dual stacked.
Day 6 - Once 100% of the internet is dual stacked - eliminate 6to4 proxy.
All communication both internally and externally is now all over IPv6.

Gyan

On Wed, May 8, 2019 at 1:08 AM Gyan Mishra <[email-masked]> wrote:

> So lets say Day 0 you have 4 Default gateways and you are trying to
> migrate hosts from Dual stack to IPv6 only you could change each of the 4
> Default routers to change to start setting the flag=1 and at that point
> until the last router sets the flag the hosts on the subnet are able to
> communicate with the DHCPv6 server and have their lease until it hits the
> rebind time to renew.  So lets say once the last router sets his flag=1 so
> now we are sending all 1's by all default routers the hosts still all have
> active leases and lets say the lease time is 7 days.  So then what
> happens.  Do they continue to work until thee rebind time to renew and then
> IPv4 gets turned off and then all hosts are then migrated dynamically to
> IPv6-only.
>
> So I guess I can see this flag being actually a very nice method to
> migrate all hosts on a subnet from dual stack to IPv6 only dynamically on
> managed networks.
>
> From the support perspective I can see this being a big win and now you
> can eliminate from the "Access" user community getting the user community
> I believe this could be a good use case to add to the draft.  I don't
> think I saw it mentioned.
>
>
> Gyan
>
>
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 8 May 2019 01:26:14 -0400

Sorry for the emails..

I can see now why Microsoft is pushing for IPv6-only feature.

Gyan

On Wed, May 8, 2019 at 1:24 AM Gyan Mishra <[email-masked]> wrote:

> Day 3- Set ipv6-only flag=1 all Default routers all subnets - migrating
> all User access community to IPv6-only. Enable 6to4 nat, 6to4dns, 6to4
> proxy.
>>> I like this option below gives flexibility to the managed networks or
>>> use cases where the desktops are not yet ready for IPv6 only and they can
>>> flip the switch when the time is right in the future.
>>>
>>> ***From B Zeeb***

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 8 May 2019 07:54:20 +0200 (CEST)

> just disable v4 completely?  More to the point, if they need to delve

Because in a migration scenario you might have years where the device 
might move between a dual stack environment and a single stack 
environment.

Having a signal from the network at each attachment point what to expect 
would be nice...?

Anyhow, my take from speaking to a few host stack implementors it seems to 
me they'll take this flag as a hint initially and as the future slowly 
progresses it'll become more and more "authoritative" if it seems to work 
well.

As for the security related objections, I just think they're completely 
irrelevant. If you allow unauthorised RAs on the network, you're screwed. 
Screwed. There are so many other ways existing RA mechanisms will screw 
you from a security POV, that this IPv6-only flag is just added background 
noise to the threat model.

The host stack vendors don't trust what the network tells them anyway, not 
without verifying. So at attachment they'll run connectivity checkers 
(does this give me Internet access? Captive Portal?) so they'll just plug 
the state of this flag into that machinery and check and verify, and would 
probably use the flag to do more exponential backoff on trying IPv4.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 8 May 2019 11:19:37 +0100

Brian E Carpenter wrote on 08/05/2019 00:18:
> managed too.

erm, didn't say this. Didn't even imply it!  :-(

>               That's certainly a false assumption in my

If you're running a BYOD network which is large enough that you actually 
care about whether people are attempting ipv4, then it probably falls 
into the gigantic l2 domain category, and you should be using the 
management capabilities of the APs to block ethertypes 0x0800 and 
0x0806.  If your APs don't support this functionality, then this is a 
mixture case of using kit which is unfit for purpose and pretending that 
you're running a "managed network" when the reality is that you aren't 
(and no, having a mess of unmanaged l2 behind a competently provisioned 
layer 3 device is not "managed" in any meaningful sense).  If it's not 
large enough to matter, then the flag isn't really relevant anyway.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 May 2019 12:39:42 +0200

>so it will simply fade away.

If we are ready to let it fade then we would not be discussing a draft that
modifies IPv4 behavior claiming that it is good for (among others)
battery life.

Yes, just let IPv4 fade away and kill this draft. We don't need new protocol
that deals with IPv4.

>small to be worth hammering.

The nail has changed. Early on in sunset4 it would just disable IPv4
unconditionally. Over time the nail has become smaller and smaller and now
we have text basically doesn't mandate anything anymore.

>IPv6-only network. Quantifying the effect on battery life is not

The draft has two bullet points on battery. Battery life of hosts has been
used often to argue for this draft. And now the effect cannot be quantified?

Maybe it is time to actually start with a problem statement that can be
measured?

Of course the same applies to how big of an issue the extra network 
traffic is.

>already in the security considerations.

The security section does not mention accidents. There is a risk that somebody
will accidentally turn this flag on on a official router. In the field it is
very unlikely that people will relate weird IPv4 failures to something that
is sent in an RA.

I don't know if the security considerations are intentionally incomplete,
but they clearly reflect the hammer looking for a nail. Maybe the authors
can take the time to actually experiment with the draft and have 
somebody look at it who knows about security.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 08 May 2019 12:52:12 +0200

> I am glad that we added the option to disable the flag and only
> enable when ready and on managed networks as I agree on unmanaged
> this flag really does not apply.

The draft discusses battery lifetimes. In general battery operated devices
move between managed and unmanaged network. So what is the correct setting?

Is there a way to signal to a host that it is on a managed network in 
some secure way? If there is add a reference to such a protocol in the
draft and explcitly say that the host MUST NOT act upon the flag if it is
in an unmanaged environment. And then what, what does a mobile device do
on an unmanaged network? Probably device vendors will find ways to reduce
IPv4 traffic to a point where battery use is left in the noise.

Then assume a managed network. These networks have RA-guard and can most
likely filter IPv4 at the ethernet level. Is the remaining traffic worth
filtering?

So where do you need this draft and what impact does it have?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 May 2019 22:30:06 +0900

> to put into designing it properly - and managing it using appropriate

I think you're forgetting the case where the network is managed and the
devices are not (e.g., BYOD on enterprise networks). This flag is a perfect
fit for such networks.

The network administrator can, as you say, manage: drop all IPv4 frames,
use L2 ACLs, whatever they want to do. But even if the administrator does
all that, the host has no way of knowing that this network has no IPv4 *by
design*, as opposed to a network that is experiencing an IPv4-only outage,
or because the host's DHCPv4 packets all got unlucky and got taken out by
cosmic rays, or...

On such a network, the flag provides a good way to tell the host: we don't
support IPv4 on this network. The host can trust that or not. If it does,
it can save battery power for its users and reduce airtime impact by
disabling DHCPv4 or retransmitting DHCPv4 less frequently, disabling
features like IPv4 MDNS, etc. etc.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 May 2019 22:36:56 +0900

> progresses it'll become more and more "authoritative" if it seems to work

Right. And as IPv4 becomes less important.

> probably use the flag to do more exponential backoff on trying IPv4.

Right. There are too many misconfigured networks out there for hosts to
blindly do what the network tells them to do.

---

From: Richard Patterson <[email-masked]>
Date: Wed, 8 May 2019 16:22:20 +0100

> devices are not (e.g., BYOD on enterprise networks). This flag is a perfect

Or in a brownfield fixed-line broadband network with plenty of BYOD that
may not (ever) support our chosen IPv4aaS method, so we can't actually
block/disable native IPv4, but we'd still like to strongly suggest to these
non-TR.069-managed devices that they make use of said IPv4aaS method if
they do support it.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 May 2019 15:17:29 -0400

Lorenzo Colitti <lorenzo=[email-masked]> wrote:
    > frames, use L2 ACLs, whatever they want to do. But even if the
    > administrator does all that, the host has no way of knowing that this
    > network has no IPv4 *by design*, as opposed to a network that is
    > experiencing an IPv4-only outage, or because the host's DHCPv4 packets
    > all got unlucky and got taken out by cosmic rays, or...

In particular, imagine you arrive at a conference or hotel and you try to use
link-local IPv4 addresses to speak between your laptop and phone.
It's one of us... It doesn't work due to all the undebuggable L2
magic.... what's going on?  What's broken?

So if all a device did was pop up a note, "This network may not support
legacy IPv4" on the screen, the flag would, for me, have benefit.

    > On such a network, the flag provides a good way to tell the host: we
    > don't support IPv4 on this network. The host can trust that or not. If
    > it does, it can save battery power for its users and reduce airtime
    > impact by disabling DHCPv4 or retransmitting DHCPv4 less frequently,
    > disabling features like IPv4 MDNS, etc. etc.

Does this mean you'll be implementing?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Fernando Gont <[email-masked]>
Date: Sat, 4 May 2019 14:58:35 +0200

> Yes, Microsoft.   It was stated in 6man several meetings ago that they were planning IPv6 Only and that this was a mechanism that would be a useful tool.

The question is probably why not use IPv4 to disable IPv4. Entangling
one protocol with another generally leads to increased complexity, and
interesting attack vectors.

I wonder why, if the issue is really a layer 2- one (e.g., stations
being awaken unnecessarily), the problem is not solved at layer 2- --
e.g. filtering at layer to, based on the Ether Proto.

Thoughts?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 May 2019 08:47:15 +1200

> I believe this could be a good use case to add to the draft.  I don't think I saw it mentioned. 

I'm not sure whether we want to delve into that detail in this draft, but I agree with you. Bjoern had some related discussion in draft-bz-v4goawayflag.

Regards
   Brian Carpenter

On 08-May-19 17:08, Gyan Mishra wrote:
>   An attack would not succeed if the dual stack hosts had active IPv4 configuration. As specified in Section 7, a dual stack host will ignore the flag if it has active IPv4 configuration. 
> 
> So lets say Day 0 you have 4 Default gateways and you are trying to migrate hosts from Dual stack to IPv6 only you could change each of the 4 Default routers to change to start setting the flag=1 and at that point until the last router sets the flag the hosts on the subnet are able to communicate with the DHCPv6 server and have their lease until it hits the rebind time to renew.  So lets say once the last router sets his flag=1 so now we are sending all 1's by all default routers the hosts still all have active leases and lets say the lease time is 7 days.  So then what happens.  Do they continue to work until thee rebind time to renew and then IPv4 gets turned off and then all hosts are then migrated dynamically to IPv6-only.
> 
> So I guess I can see this flag being actually a very nice method to migrate all hosts on a subnet from dual stack to IPv6 only dynamically on managed networks.
> 
> From the support perspective I can see this being a big win and now you can eliminate from the "Access" user community getting the user community within an enterprise quickly converted to IPv6 only so that only IPv6 needs to be supported versus IPv4.  I can see many benefits to that one of which being IPv4 address depletion but even if you use private space internally and proxy out to the internet their are gains to be made from a IPv4 address space management overhead perspective and DHCPv4 scopes to be managed that can all be sunset.
> 
> As far as my previous points of why go IPv6 only now I can definitely see why now even though the internet is far behind that tackling the user community desktops is an easy "win" so to speak for IPv6 to get converted to IPv4 and then you can alway use 6to4 nat & 6to4 DNS to communicate with Servers within the enterprise and 6to4 proxy to communicate IPv4 out to the internet.
> 
> I believe this could be a good use case to add to the draft.  I don't think I saw it mentioned. 
> 
> 
> Gyan
> 
> 
> 
>   
> 
> On Wed, May 8, 2019 at 12:51 AM Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     I like this option below gives flexibility to the managed networks or use cases where the desktops are not yet ready for IPv6 only and they can flip the switch when the time is right in the future.
> 
>     ***From B Zeeb***
>     On Tue, May 7, 2019 at 1:36 PM Bjoern A. Zeeb <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
>     Mobile – 202-734-1000
> 
> 
> 
> -- 
> Gyan S. Mishra
> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
> Mobile – 202-734-1000
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 May 2019 08:54:07 +1200

> Maybe the authors
> can take the time to actually experiment with the draft

Well, Bjoern implemented it for FreeBSD. We've checked with scapy that it doesn't break current hosts. But to experiment on a large scale, we'd need routers, Windows and Apple hosts on board. You know that's impractical for a pre-standard feature at this level of the stack.

Regards
   Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 May 2019 14:34:48 -0700

Fernando,

> On May 4, 2019, at 5:58 AM, Fernando Gont <[email-masked]> wrote:
> 

As it says in the Introduction in the draft:

   Because there is no IPv4 support on an IPv6-Only link, the only way
   to notify the dual stack hosts that this link is IPv6-Only is to use
   an IPv6 mechanism.  

If there is no IPv4 on the link, you can’t use an IPv4 mechanisms to turn off IPv4.

You have read the draft, right?

Bob

---

From: David Farmer <[email-masked]>
Date: Wed, 8 May 2019 16:55:08 -0500

> e.g. filtering at layer to, based on the Ether Proto.

First, I don't think this flag is tangling the streams so to speak, IPv4
and IPv6 are tangled by the dual-stack model. I think of the flag as trying
to untangle IPv6 from IPv4 so we can run IPv6-Only on dual-stack hosts.

The primary signal for a dual-stack host to not configure an IPv4 address
should be the failure to receive an IPv4 address from a DHCPv4 Server
[RFC2131]. This flag should be a secondary signal for a dual-stack host to
not auto-configured an IPv4 Link-Local addresses [RFC3927] assuming an
address has not received via DHCPv4, to not perform any IPv4 service
discovery (such as mDNS [RFC6762]) using IPv4 Link-Local Addresses, and
further, to limit the number of attempts that are made to configure an IPv4
address via DHCPv4.

Otherwise, without this secondary signal, when a dual-stack host does not
receive an IPv4 address from a DHCPv4 Server it would
normally auto-configured an IPv4 Link-Local addresses, perform IPv4 service
discovery (such as mDNS [RFC6762]) using IPv4 Link-Local addresses, and
some dual-stack hosts are quite persistent in their attempt to configure an
IPv4 address. It is these sides effects of not receiving an IPv4 address
from a DHCPv4 Server that the flag needs to mitigate and that are necessary
to untangle IPv6 from IPv4 to run IPv6-Only on dual-stack hosts.

This secondary signal needs to be expressed with an IPv6 mechanism so that
it is compatible with Layer 2 filtering of IPv4 Ethertypes, however, use of
the flag doesn't require this filtering. If this signal is expressed in
IPv4 then it is impossible for the signal to be received in the presence of
Layer 2 filtering of IPv4 Ethertypes.

The following is the rewrite I propose for the logic in the Host Behavior
Considerations Section based on the above restatement of the purpose of the
flag.

---

A host that receives any RAs with the flag set to 1 SHOULD NOT
auto-configured an IPv4 Link-Local Addresses [RFC3927] when it fails to
receive an IPv4 address via DHCPv4 [RFC2131] and therefore SHOULD
NOT perform IPv4 service discovery (such as mDNS [RFC6762]) using IPv4
Link-Local addresses.

A host that receives only RAs with the flag set to 1 SHOULD make a limit
number of attempts to configure an IPv4 address via DHCPv4 and then make no
further attempts. OPTIONAL, such a host could make no attempt to configure
an IPv4 address at all.

As soon as a host receives any RAs with the flag set to 0 it SHOULD attempt
to configure an IPv4 address via DHCPv4 if it does not already have an IPv4
address configured, and MAY continue to periodically attempt to configure
an IPv4 address via DHCPv4 if it does not receive an IPv4 address from a
DHCPv4 Server as long as it is receiving any RAs with the flag set to 0.

A host that successfully configures an IPv4 address received via DHCPv4
SHOULD continue using it and attempt to renew it when necessary regardless
the status of the flag in the RAs it is receiving. Further, it MAY perform
IPv4 service discovery (such as mDNS [RFC6762]) using the configured IPv4
address.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 May 2019 10:26:10 +1200

David,

Regards
   Brian Carpenter

On 09-May-19 09:55, David Farmer wrote:
> 
> 
> On Wed, May 8, 2019 at 2:54 PM Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> 
> First, I don't think this flag is tangling the streams so to speak, IPv4 and IPv6 are tangled by the dual-stack model. I think of the flag as trying to untangle IPv6 from IPv4 so we can run IPv6-Only on dual-stack hosts.
> 
> The primary signal for a dual-stack host to not configure an IPv4 address should be the failure to receive an IPv4 address from a DHCPv4 Server [RFC2131]. This flag should be a secondary signal for a dual-stack host to not auto-configured an IPv4 Link-Local addresses [RFC3927] assuming an address has not received via DHCPv4, to not perform any IPv4 service discovery (such as mDNS [RFC6762]) using IPv4 Link-Local Addresses, and further, to limit the number of attempts that are made to configure an IPv4 address via DHCPv4. 
> 
> Otherwise, without this secondary signal, when a dual-stack host does not receive an IPv4 address from a DHCPv4 Server it would normally auto-configured an IPv4 Link-Local addresses, perform IPv4 service discovery (such as mDNS [RFC6762]) using IPv4 Link-Local addresses, and some dual-stack hosts are quite persistent in their attempt to configure an IPv4 address. It is these sides effects of not receiving an IPv4 address from a DHCPv4 Server that the flag needs to mitigate and that are necessary to untangle IPv6 from IPv4 to run IPv6-Only on dual-stack hosts.
> 
> This secondary signal needs to be expressed with an IPv6 mechanism so that it is compatible with Layer 2 filtering of IPv4 Ethertypes, however, use of the flag doesn't require this filtering. If this signal is expressed in IPv4 then it is impossible for the signal to be received in the presence of Layer 2 filtering of IPv4 Ethertypes. 
> 
> The following is the rewrite I propose for the logic in the Host Behavior Considerations Section based on the above restatement of the purpose of the flag. 
> 
> ---
> 
> A host that receives any RAs with the flag set to 1 SHOULD NOT auto-configured an IPv4 Link-Local Addresses [RFC3927] when it fails to receive an IPv4 address via DHCPv4 [RFC2131] and therefore SHOULD NOT perform IPv4 service discovery (such as mDNS [RFC6762]) using IPv4 Link-Local addresses.
> 
> A host that receives only RAs with the flag set to 1 SHOULD make a limit number of attempts to configure an IPv4 address via DHCPv4 and then make no further attempts. OPTIONAL, such a host could make no attempt to configure an IPv4 address at all. 
> 
> As soon as a host receives any RAs with the flag set to 0 it SHOULD attempt to configure an IPv4 address via DHCPv4 if it does not already have an IPv4 address configured, and MAY continue to periodically attempt to configure an IPv4 address via DHCPv4 if it does not receive an IPv4 address from a DHCPv4 Server as long as it is receiving any RAs with the flag set to 0.
> 
> A host that successfully configures an IPv4 address received via DHCPv4 SHOULD continue using it and attempt to renew it when necessary regardless the status of the flag in the RAs it is receiving. Further, it MAY perform IPv4 service discovery (such as mDNS [RFC6762]) using the configured IPv4 address.
> 
> Thanks.
> 
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 May 2019 10:30:12 +1200

David,

Sorry about the runt message just sent, fat finger trouble.

> A host that receives any RAs with the flag set to 1 

No! That must be

A host that receives only RAs with the flag set to 1 

It is an absolute requirement that all routers must agree that the flag is 1, or else it has no effect.

Otherwise I'm sympathetic to your rewrite, but I see little point in updating the draft until the WG Chair gives us a read-out on the rough consensus.

Regards
   Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 9 May 2019 08:35:04 +1000

The functionality is needed.

> On 9 May 2019, at 8:30 am, Brian E Carpenter <[email-masked]> wrote:
> 
> David,
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 May 2019 08:50:06 +0900

> Does this mean you'll be implementing?

Well, nobody can implement a flag that doesn't exist. if the flag did
exist, I think it would make sense to implement it. The most obvious thing
to do with it would be to reduce the DHCP  client exponential backoff or
perhaps even give up on DHCP altogether if it did not succeed within a
given timeout.

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 May 2019 16:09:54 +1000

On Thu, 9 May 2019 at 07:56, David Farmer <[email-masked]> wrote:

<snip>

> The primary signal for a dual-stack host to not configure an IPv4 address should be the failure to receive an IPv4 address from a DHCPv4 Server [RFC2131].

The primary goal is to reduce and ideally entirely eliminate
link-layer broadcasts on the link caused by IPv4.

DHCPDISCOVERS are link-layer broadcasts. Using any form of DHCPv4 to
disable IPv4 is directly counter to the primary goal.

Link-layer broadcasts cannot be filtered by the interface card based
on the frame's destination address (unlike unicast and multicast), so
they must be passed to the host's general purpose CPU for processing,
typically triggered by an interrupt to the CPU, which causes operating
system context switches etc. to process it. If the frame isn't
intended for the host, there is a relatively high processing cost to
ignoring it.

It is much more efficient to be able to filter and drop frames in the
NIC itself based on destination address . (Even if a NIC is "smart"
and can do internal processing e.g. via Linux XDP, it's still more
battery consumption on a mobile device than just dropping the frame
purely based on destination address).

100s or 1000s of devices on a link results in all of those 100s or
1000s of devices having to receive, process with their general CPU,
and then ignore, each and every one of the link-layer broadcast
DHCPDISCOVERS that each of those devices all emit.

RFC3927 may reduce the volume of DHCPDISCOVERS and IPv4 caused
link-layer broadcasts, but it doesn't eliminate them. Any time a new
device joins the link, a link-layer broadcast will still occur and be
flooded, and have to be processed (by the general purpose CPU) and
ignored by all of the other devices already on the link. On a link
where devices come and go regularly, such as conference or similar
public Wifi, and may leave the link when saving power or being
suspended, that could still be a significant amount of link-layer
broadcast traffic caused by DHCPDISCOVERS upon attachment.

(People may not realise why IPv6 only uses link-layer multicasts,
rather than link-layer broadcasts. It isn't a coincidence, since Steve
Deering both developed multicast and co-designed IPv6:

RFC1112, "Host Extensions for IP Multicasting"

7.4. Extensions to an Ethernet Local Network Module

   To support the reception of multicast IP datagrams, an Ethernet
   module must be able to receive packets addressed to the Ethernet
   multicast addresses that correspond to the host's IP host group
   addresses.  It is highly desirable to take advantage of any address
   filtering capabilities that the Ethernet hardware interface may have,
   so that the host receives only those packets that are destined to it.)

Regards,
Mark.

> This flag should be a secondary signal for a dual-stack host to not auto-configured an IPv4 Link-Local addresses [RFC3927] assuming an address has not received via DHCPv4, to not perform any IPv4 service discovery (such as mDNS [RFC6762]) using IPv4 Link-Local Addresses, and further, to limit the number of attempts that are made to configure an IPv4 address via DHCPv4.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 May 2019 11:08:03 +0200 (CEST)

> Please give objections and comments to this decision to the mailing list, by 2019-05-13.

Having discussed the objections to this draft with multiple people, I 
propose to enhance the document with some text regarding mitigation of the 
rouge RA with bit=1.

The main objections I have seen are:

An attaching host will not start IPv4 operations until it has received 
(and decided it's received all of them) RA answers to its initial RS 
message, because before this it doesn't know what the flag will be. This 
will increase attachment times before a working setup can be had on IPv4 
only links. I think this is a valid concern.

Problematic text:

"   A host that receives only RAs with the flag set to 1 SHOULD NOT
    attempt any IPv4 operations, unless it subsequently receives at least
    one RA with the flag set to zero.  As soon as such an RA is received,
    IPv4 operations MAY be started.
"

This text can be changed so that IPv4 and IPv6 operations MAY be started 
simultaneously and then the presence of this flag means IPv4 DHCP timers 
etc can be agressively backed off and IPv4 LL operations SHOULD NOT be 
performed.

Secondly, In the security section:

"   o  An attack would not succeed if the dual stack hosts had active
       IPv4 configuration.  As specified in Section 7, a dual stack host
       will ignore the flag if it has active IPv4 configuration."

There needs to be text that handles the (today not mentioned) case of a 
device that attaches to a link, wait to see if the flag is set (doesn't 
perform IPv4 operations), and then trusts it. A mitigation section can be 
added that to mitigate this problem, presence of IPv4 can be verified by 
trying IPv4 operations and if no DHCP answer is seen in a timely fashion 
and RA with bit=1 then IPv4 operations SHOULD be ceased. This still 
doesn't handle the case where a host actually should have configured 
itself an IPv4 LL and talked to other IPv4 LL hosts to do something 
useful, but I think this is a quite rare event that the IPv6 only flag=1 
is seen on a network without DHCPv4 and it's desired that IPv4 LL 
operations should exist? Anyhow, text on this case can be part of a 
section as well.

Thoughts?

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 May 2019 11:18:46 +0200

>The most obvious thing

I think there are already plenty of other hints that can be used to backoff
DHCP:
1) If the host has working IPv6 and working IPv4aaS then it can agressively
   backoff DHCPv4 or give up.
2) If a host has working IPv6 it can agressively backoff DHCPv4 until it 
   first resolves a domain that only has an A record and no AAAA (or there is
   another reason to connect to an IPv4 address)
3) In theory, but I don't know if there are operational issues with this,
   if a host sees DHCPv4 discovers from other hosts and no offers then the
   host can agressively backoff DHCPv4. When the host sees an offer it can
   try again.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 May 2019 11:53:16 +0200

>only links. I think this is a valid concern.

I think the proponents of this draft should create an experimental 
implementation in a mobile device (for example Andriod, but I guess a 
laptop running Linux would work as well).

And then actually try to attack that implementation and write both about
implementation guidelines and security issues.

Much better would be to just drop this draft and move on.

---

From: David Farmer <[email-masked]>
Date: Thu, 9 May 2019 08:04:37 -0500

On Thu, May 9, 2019 at 1:10 AM Mark Smith <[email-masked]> wrote:

> > The primary signal for a dual-stack host to not configure an IPv4
> address should be the failure to receive an IPv4 address from a DHCPv4
> Server [RFC2131].
>

As I see it, at least for the foreseeable future, we want dual-stack hosts
to perform equally well on dual-stack networks as on IPv6-Only networks, so
in my opinion, this means we don't want to completely eliminate
DHCPDISCOVERS, at least at the beginning of the attachment process. Maybe
someday in the future, IPv4 will be rare enough we can delay even
initial DHCPDISCOVERS, but at this point, I don't think that is a wise move.

As I see the intent after initial DHCPDISCOVERS we want a positive signal
to a dual-stack host that further DHCPDISCOVERS are futile and that is can
stop. But upon attachment to a network, at least for now, a dual-stack host
should assume it is more likely to be attaching to a dual-stack network as
a IPv6-only one. Therefore, it should sent both an IPv6 R

> > This flag should be a secondary signal for a dual-stack host to not
> auto-configured an IPv4 Link-Local addresses [RFC3927] assuming an address
> has not received via DHCPv4, to not perform any IPv4 service discovery
> (such as mDNS [RFC6762]) using IPv4 Link-Local Addresses, and further, to
> limit the number of attempts that are made to configure an IPv4 address via
> DHCPv4.
> >
> > Otherwise, without this secondary signal, when a dual-stack host does
> not receive an IPv4 address from a DHCPv4 Server it would normally
> auto-configured an IPv4 Link-Local addresses, perform IPv4 service
> > This secondary signal needs to be expressed with an IPv6 mechanism so
> that it is compatible with Layer 2 filtering of IPv4 Ethertypes, however,
> use of the flag doesn't require this filtering. If this signal is expressed
> in IPv4 then it is impossible for the signal to be received in the presence
> of Layer 2 filtering of IPv4 Ethertypes.
> >
> > The following is the rewrite I propose for the logic in the Host
> Behavior Considerations Section based on the above restatement of the
> purpose of the flag.
> >
> > ---
> >
> receive an IPv4 address via DHCPv4 [RFC2131] and therefore SHOULD NOT
> perform IPv4 service discovery (such as mDNS [RFC6762]) using IPv4
> Link-Local addresses.
> >
> > As soon as a host receives any RAs with the flag set to 0 it SHOULD
> attempt to configure an IPv4 address via DHCPv4 if it does not already have
> an IPv4 address configured, and MAY continue to periodically attempt to
> configure an IPv4 address via DHCPv4 if it does not receive an IPv4 address
> from a DHCPv4 Server as long as it is receiving any RAs with the flag set
> to 0.
> >

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 May 2019 15:32:20 +0200

Le 08/05/2019 à 00:23, David Farmer a écrit :
> On Tue, May 7, 2019 at 4:26 PM Manfredi (US), Albert E 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > At the 6man meeting at IETF 104 in Prague there was support to
>     close the working group last call and advance
>     anything, can cause confusion and problems. It seems to have been
>     motivated by people wanting to see what it would be like to get all
>     IPv4 users off the network, at an IETF meeting, and then people have
>     been trying to make the case that it would be generically useful.
> 
>     There are other ways of sunsetting IPv4 if a network wants to,
>     exactly the same as any number of older network protocols have been
>     obsoleted, never needing any new explicit flag for the purpose. And
>     I would way prefer for equipment vendors themselves, such as
>     smartphone vendors, to create their own heuristics, if they feel
>     that IPv4 is so wasteful of battery power. The onus should be on
>     them, IMO, not on the IETF, and certainly not on other users of the
>     network who might not know or pay attention to that flag.
> 

Layer-2 filtering on ethertype is a great idea.  I would concur.

But on cellular links there's no ethertype.  It's what they call a PDP type.

(this is not a support neither not support of  the draft; my own idea of 
the draft is that because is covered by IPR it is basically killed).

Alex

> The problem is, these two options are incompatible with each other. You 
> can either block IPv4 traffic or signal the host that not to use 
> Link-local IPv4, you really can't do both at the same time.
> 
> I just had a thought, what if the host behavior for the flag was changed 
> to be more like the behavior specified for RFC2563?
> 
> In the presence of the flag, a host MAY attempt DHCPv4 a limited number 
> of times, but MUST NOT perform Stateless Auto-Configuration of an IPv4 
> address and MUST NOT perform any service discovery (such as mDNS) unless 
> it receives a unicast IPv4 address from DHCPv4 server or relay on the 
> network.
> 
> This way a Rogue RA with this flag set is much less dangerous than a 
> Rouge DHCPv4 server and doesn't directly impede IPv4 internet access. It 
> would impede Link-local IPv4, but only if there is not a functioning 
> DHCPv4 server or the attacker can also block the DHCPv4 process in 
> addition to announcing a rogue RA with the flag set.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 May 2019 16:00:16 +0200 (CEST)

> But on cellular links there's no ethertype.  It's what they call a PDP type.

This draft is irrelevant in that context because for the PDP type there is 
explicit signaling of the PDP type, so the UE knows whether to use it for 
IPv4, IPv6 or IPv4+IPv6.

So there is no RA flag needed.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 May 2019 16:37:14 +0200

Le 09/05/2019 à 16:00, Mikael Abrahamsson a écrit :
> This draft is irrelevant in that context because for the PDP type there 
> is explicit signaling of the PDP type, so the UE knows whether to use it 
> for IPv4, IPv6 or IPv4+IPv6.
 >
> 

In a sense I agree: since the network sets this PDP type IPv6 then the 
Host can try as hard as it can IPv4 - it wont get through.

On another sense I disagree:  a Host on a cellular PDP type IPv6 and not 
receiving a flag IPv6-only in an RA is in a messy situation.

Alex
PS: I would like to continue the conversation, but I realize I must 
start to rate limit.

---

From: David Farmer <[email-masked]>
Date: Thu, 9 May 2019 10:22:08 -0500

Sorry I had a premature launch of my message. :(

 As I see it, at least for the foreseeable future, we want dual-stack hosts
to perform equally well on dual-stack networks as on IPv6-Only networks. So
in my opinion, this means we don't want to completely eliminate
DHCPDISCOVERS, at least at the beginning of the attachment process. Maybe
someday in the future, IPv4 will become rare enough we can delay even these
initial DHCPDISCOVERS, but at this point, I don't think that is a wise move.

As I see it, we want a positive signal to dual-stack hosts that further
DHCPDISCOVERS, after the initial few, are futile and can be stopped fairly
quickly. But upon attachment to a network, at least for now, a dual-stack
host should assume it is more likely to be attaching to a dual-stack
network than to an IPv6-Only network. Therefore, it should send both an
IPv6 ROUTER SOLICITATION and an IPv4 DHCPDISCOVER at roughly the same time,
moments after the network attachment is stable.

On dual-stack networks, the host will receive a response to both of these
queries and configure both IPv4 and IPv6. However, on an IPv6-Only network,
the host will not receive any DHCPOFFERS in response to the DHCPDISCOVER,
but it will get a response to the IPv6 ROUTER SOLICITATION, one or more
ROUTER ADVERTISEMENTS, hopefully with this flag set. At this point, the
dual-stack host knows it SHOULD NOT auto-configured an IPv4 Link-Local
address [RFC3927]. But it doesn't know for sure that it won't get any
DHCPOFFERS, before the dual-stack host can know that for sure, it needs to
wait long enough to have received all possible ROUTER ADVERTISEMENTS and
make sure all ROUTER ADVERTISEMENTS have this flag set.

If the dual-stack host receives any DHCPOFFERS, it SHOULD accept one of
them regardless of the setting of the flag. Again the lack of DHCPOFFERS is
the primary signal, not this flag. Only after the dual-stack host has
received all ROUTER ADVERTISEMENTS and they all have this flag set is it
safe for a dual-stack host to assume it can cease sending DHCPDISCOVERS.
Further if at any time, a dual-stack host receives a ROUTER ADVERTISEMENT
with this flag cleared, it should continue sending DHCPDISCOVERS
periodically.

Making the lack of DHCPOFFERS the primary signal and this flag a secondary
signal mitigates almost all the risks associated with this flag. So, this
flag is not saying turn off IPv4, this flag is saying assume that the lack
of any DHCPOFFERS is an intentional act and don't auto-configured an IPv4
Link-Local address or perform any IPv4 service discovery with an IPv4
link-local address. Further, if you see only ROUTER ADVERTISEMENTS with
this flag set, you can fairly quickly stop sending DHCPDISCOVERS at all,
they are not going to get answered.

Thanks

---

From: David Farmer <[email-masked]>
Date: Thu, 9 May 2019 10:51:09 -0500

> the draft is that because is covered by IPR it is basically killed).

Is I've said we want the flag to be compatible with Layer 2 filtering of
Etherthypes 0x0800 and 0x0806, but it is not a substitute for the flag.
This filtering will block the dual-stack host's IPv4 DHCPDISCOVERS and
therefore it will receive any DHCPOFFERS. However, without the flag, the
dual-stack host will auto-configure an IPv4 Link-Local address and attempt
to send IPv4 service discovery and continue to send DHCPDISCOVERS, all of
which are futile and waste energy and processing on the host.

In a cell network, this flag probably isn't necessary, but I don't see how
setting the flag would make things any worse for a cell network and it is
possible that badly implemented cell clients might stop sending futile IPv4
DHCPDISCOVERS and IPv4 service discovery traffic because they implemented
and received this flag.

thanks

---

From: David Farmer <[email-masked]>
Date: Thu, 9 May 2019 11:47:50 -0500

On Wed, May 8, 2019 at 5:30 PM Brian E Carpenter <
[email-masked]> wrote:

> Otherwise I'm sympathetic to your rewrite, but I see little point in
> updating the draft until the WG Chair gives us a read-out on the rough
> consensus.
>

Because with this flag now only being a secondary signal and the lack of
any DHCPOFFERS is now the primary signal, it is safe to allow any RA set to
1 to trigger no longer auto-configuring an IPv4 Link-Local address, this
only has an effect if the host also doesn't receive any DHCPOFFERS. So, if
the host receives one RA with the flag set and one RA with the flag
cleared, the host should continue sending DHCPDISCOVERS perodically and
configure an IPv4 address if it gets any DHCPOFFER. However, if it never
gets any DHCPOFFERS it should not auto-configure of an IPv4 Link-Local
address, even though there are conflicting settings of this flag in the RAs.

This at least partially mitigates the malicious sending of an RA with the
flag cleared on an IPv6-Only network, again the lack of DHCPOFFERS controls
if the host configures an IPv4 address or not, this flag only says what to
do if you don't receive any DHCPOFFERS and whether or not to continue
sending periodic DHCPDISCOVERS. Further, you should only stop sending
DHCPDISCOVERS if the flags in RAs received all agree.

Thanks.

---

From: j h woodyatt <[email-masked]>
Date: Thu, 9 May 2019 10:14:19 -0700

On May 8, 2019, at 23:09, Mark Smith <[email-masked]> wrote:
> 
> The primary goal is to reduce and ideally entirely eliminate link-layer broadcasts on the link caused by IPv4.

I don’t think 6MAN can work on that goal. I’m looking at the active charter, and I’m just not seeing where it says it can have that as a goal for its work. There is a clause about addressing "protocol limitations/issues discovered during deployment and operation” but I think it’s a big stretch to tag this goal with that topic. This isn’t a limitation or issue with the IPv6 protocol.

--james woodyatt <[email-masked]>

---

From: Sander Steffann <[email-masked]>
Date: Thu, 9 May 2019 21:11:02 +0200

Hi David,

> Because with this flag now only being a secondary signal and the lack of any DHCPOFFERS is now the primary signal, it is safe to allow any RA set to 1 to trigger no longer auto-configuring an IPv4 Link-Local address, this only has an effect if the host also doesn't receive any DHCPOFFERS.

Making the lack of DHCPOFFERS the primary signal and this flag a secondary signal would take away my strongest objections. I still wonder whether it is worth the effort and the added learning curve and complexity, and whether other heuristics (see Philip Homburg's message for example) aren't as good/good enough. At least the debugging effort for help desks won't be harmed anymore by the flag, because as long as DHCPOFFERS are working the flag doesn't hurt, and solving problems when DHCPOFFERS aren't working is already part of their current procedures.

Cheers,
Sander

---

From: David Farmer <[email-masked]>
Date: Thu, 9 May 2019 16:32:26 -0500

On Thu, May 9, 2019 at 2:17 PM Sander Steffann <[email-masked]> wrote:

> only has an effect if the host also doesn't receive any DHCPOFFERS.
>
> signal would take away my strongest objections.

Thanks, glad to hear that.

> I still wonder whether it is worth the effort and the added learning curve
> and complexity, and whether other heuristics (see Philip Homburg's message
> for example) aren't as good/good enough. At least the debugging effort for
> help desks won't be harmed anymore by the flag, because as long as
> DHCPOFFERS are working the flag doesn't hurt, and solving problems when
> DHCPOFFERS aren't working is already part of their current procedures.
>

I reviewed Philip's messages, I found several heuristics effectively
relating to when to suppressing periodic IPv4 DHCPDISCOVERS.  However, for
when to not auto-configuring an IPv4 Link-Local address, the only
suggestion I found was RFC 2563. And unfortunately, as that requires an
IPv4 DHCPOFFER in response to a DHCPDISCOVER to be successfully returned to
the host, which is basically incompatible with Layer 2 filtering of
Ethertype 0x0800, I guess you could still filter Ethertype 0x0806 though.

Also, while many older OSes seem to support  RFC 2563, I many newer OSes
seem to have dropped support for it or at least as best as I can tell.

I like the idea a positive signal provided via IPv6 to tell dual-stack
hosts to not auto-configuring an IPv4 Link-Local address. I also think
suppressing periodic DHCPDISCOVERS when all the RA flags agree has the
advantage that when there are no longer any valid RAs, you no longer
suppressing periodic DHCPDISCOVERS.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 May 2019 11:01:12 +1200

> laptop running Linux would work as well).

Then I think the proponents of every draft should create an experimental implementation for every operating system.

This style of argument could be used against every new proposal that we ever get.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 May 2019 11:02:02 +1200

> I think there are already plenty of other hints that can be used to backoff

True, but rather irrelevant to the value of *this* hint.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 May 2019 11:11:32 +1200

Regards
   Brian Carpenter

On 10-May-19 04:47, David Farmer wrote:
> 
> 
> On Wed, May 8, 2019 at 5:30 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     David,
> 
> Because with this flag now only being a secondary signal and the lack of any DHCPOFFERS is now the primary signal, 

That's been suggested, but not agreed. I'm reluctant to remove the requirement that all the default routers agree (in the case that there's more than one, of course), because disagreement signals that the network admins have screwed up somehow.

Fairly clearly, if a host observes DHCP(v4) traffic and also observes the IPv6-only flag, the flag loses. If the current wording isn't clear on that, we need changes such as Mikael or you have suggested. But I'm also reluctant to over-specify the heuristic that a host should apply, because different stack implementations are ... different.

    Brian

> it is safe to allow any RA set to 1 to trigger no longer auto-configuring an IPv4 Link-Local address, this only has an effect if the host also doesn't receive any DHCPOFFERS. So, if the host receives one RA with the flag set and one RA with the flag cleared, the host should continue sending DHCPDISCOVERS perodically and configure an IPv4 address if it gets any DHCPOFFER. However, if it never gets any DHCPOFFERS it should not auto-configure of an IPv4 Link-Local address, even though there are conflicting settings of this flag in the RAs.
> 
> This at least partially mitigates the malicious sending of an RA with the flag cleared on an IPv6-Only network, again the lack of DHCPOFFERS controls if the host configures an IPv4 address or not, this flag only says what to do if you don't receive any DHCPOFFERS and whether or not to continue sending periodic DHCPDISCOVERS. Further, you should only stop sending DHCPDISCOVERS if the flags in RAs received all agree.
> 
> Thanks.
> 
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 May 2019 11:17:51 +1200

On 10-May-19 05:14, j h woodyatt wrote:
> On May 8, 2019, at 23:09, Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
>>

The charter is naturally silent on this issue. However, the WG adopted the draft, presumably under "The working group will address protocol limitations/issues discovered during deployment and operation." (Explicitly: discovered on an IPv6-only network several IETFs ago, if you want chapter and verse. The limitation being the absence of a mechanism to signal "IPv6-only" to dual stack hosts.)

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 May 2019 19:40:40 -0400

David Farmer <[email-masked]> wrote:
    > Making the lack of DHCPOFFERS the primary signal and this flag a
    > secondary signal mitigates almost all the risks associated with this
    > flag. So, this flag is not saying turn off IPv4, this flag is saying
    > assume that the lack of any DHCPOFFERS is an intentional act and don't
    > auto-configured an IPv4 Link-Local address or perform any IPv4 service
    > discovery with an IPv4 link-local address. Further, if you see only
    > ROUTER ADVERTISEMENTS with this flag set, you can fairly quickly stop
    > sending DHCPDISCOVERS at all, they are not going to get answered.

Thanks for the well written message, the well explained logic and this
modification of primary/secondary notion.

In order for the network and devices to remain safe in the scenario, at least
IPv4 DHCPOFFERS must be filtered out. (Whether by filtering IPv4 broadcasts,
UDP port 67/68 or all IPv4, it doesn't matter)
Otherwise, the rogue DHCPv4 server captures all the IPv4-legacy traffic.
(Such an attacker system could CLAT46 the traffic and NAT64 it out)

The above attack is present with or without the IPv6-only flag.
With the IPv6-only flag, it becomes possible, in a network with IPv4 L2
filters, to detect that perhaps there is something going wrong.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 10 May 2019 00:06:27 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter

> (Explicitly: discovered on an IPv6-only network several IETFs ago, if you want chapter and verse. The limitation being the absence of a mechanism to signal "IPv6-only" to dual stack hosts.)

Very well and succinctly put, Brian. And that is precisely why I don’t think this draft needs to go further.

Paraphrased, in a "lab experiment" at one IETF, people wondered what would happen if one could just shut off IPv4 entirely. A first, almost knee-jerk reaction was, this lab experiment would be so simple if we only had an explicit bit, transmitted by the network, to say "no IPv4 here."

And yet, upon further reflection, aside from just the momentary curiosity of this "what if no IPv4" experiment, a couple of things became clear: the actual advantage of such a drastic measure was, credibly, only to save some power in battery-powered devices. And there are several other heuristics that hosts can use, to achieve almost completely the same result, in a *decentralized* way, changing no network protocol whatsoever. Furthermore, there are also other ways for the net admin of a managed network, to kill off IPv4 (L2 filtering).

And yet still, in spite of these potential mechanisms which already exist to kill off IPv4, and even in spite of this potential new flag, doggone if people can’t STILL bring their own switch, bring their own peripherals, and run IPv4 in that network anyway!

Not necessary, not sufficient, therefore, IMO, not needed.

Bert

---

From: j h woodyatt <[email-masked]>
Date: Thu, 9 May 2019 17:30:13 -0700

On May 9, 2019, at 16:17, Brian E Carpenter <[email-masked]> wrote:
> 
> The charter is naturally silent on this issue. However, the WG adopted the draft…

…mistakenly, in my view. I think I said so at the time. If I didn’t, then this is me offering my opinion to that effect now.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 May 2019 11:33:25 +0200

>entation for every operating system.

Nice strawman. Really? 

As far as I know there is no host implementation for this draft. It is very
clear that the security section is incomplete. Which should be obvious 
to anyone who would be using a host implementation on a mobile device for a
while.

This is a really sad state of affairs for a draft that tries to modify the
behavor of every possible IPv4 stack in the world.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 10 May 2019 10:06:18 +0000

On 10 May 2019, at 9:33, Philip Homburg wrote:

>> Then I think the proponents of every draft should create an 
>> experimental implem
>> entation for every operating system.
>
> Nice strawman. Really?
>
> As far as I know there is no host implementation for this draft.

Yes there is and the last *two* versions of the draft (-04 and -05) have 
stated that:
A.1.  FreeBSD Implementation  . . . . . . . . . . . . . . . . .  13

And if you followed 6man 104 you’ll find it’s no longer the only one 
apparently:

Listen for 30s from here on (the slides are moving slightly delayed):
https://www.youtube.com/watch?v=TXIbkYj8Ftw&t=11m40s

But you can always check page 3 here as well:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-ipv6-ra-ipv6-only-flag-01

/bz

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 May 2019 11:23:12 +0100

> A.1.  FreeBSD Implementation  . . . . . . . . . . . . . . . . .  13

Bjoern,

the freebsd implementation doesn't really implement what's specified in 
-05, in particular the interaction with dhcpv4 and interface startup 
discipline.

Nick

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 10 May 2019 11:19:41 +0000

On 10 May 2019, at 10:23, Nick Hilliard wrote:

>> Yes there is and the last *two* versions of the draft (-04 and -05) 
>> have stated that:
> the freebsd implementation doesn't really implement what's specified 
> in -05, in particular the interaction with dhcpv4 and interface 
> startup discipline.

Similarly phrased twice in the draft it only says:

    Dual stack hosts that have IPv4 active configuration obtained from
    the network (e.g., via DHCP), can ignore the flag and continue to 
use
    IPv4.

If there is IPv4 configuration on the interface the FreeBSD 
implementation will ignore the RA flag.

It also says:

    A host MAY delay all IPv4 operations at start-up or reconnection
    until a reasonable time has elapsed for RA messages to arrive.  If
    all RAs received have the flag set to 1, a host SHOULD NOT attempt
    IPv4 operations.

And the implementation will do an RS, and briefly wait, before trying to 
do DHCPv4.  No DCHPv4 or ARP requests or IPv4 link-local packet will 
ever end up on the air or the wire with the current implementation 
should the flag be active saving all other devices from “being woken 
up” by receiving the broadcasts.

As to when it comes to having more local savings by not running software 
locally.. how I’ll handle and add infrastructure for any kinds of 
third party software sending any other kind of IPv4 broad-/multicast 
noise will highly depend on what the consensus here will be.  Adding the 
extra 10 lines of code for the infrastructure for this is not the issue. 
  Touching 3rd party software is, as compared to most other OSes the 
general audience here might thinking off (Windows, OSX, iOS, Android 
mostly) FreeBSD like most Linux distributions is not a “blob” 
shipping with all that under one control.  And even on these 
aforementioned OSes any third party software could possibly send raw 
packets unless you take the “socket interface” for IPv4 away (and 
even then there are ways), and that is not what this draft asks for.  
Hence the lower-layer filtering is almost implied even for software 
(unless the consensus will be that IPv4 operation should be continue to 
try acquire configuration, in which case the implementation will become 
complicated, KISS will go, and savings of all this will suffer).  I am 
currently not yet willing to impose the cost of adjusting 3rd party 
software on a lot of maintainers while people are still discussing 
acceptance here.

To re-iterate, the savings that I can see can come from two parts:
(a) the IPv4-related packets not having to be seen and processed by 
everyone else (1 packet send, 1..100s..1000s nodes “woken up”; 
it’s very much like every email re-iterating here what has been said 
before is 1 email sent, read by many)
(b) local software optimising itself to save the world (by consuming 
less resources)

and
(b) is something everyone can do all the time and should do and maybe 
there need to be other changes in the future to other protocols as well
(a) is what takes the noise away that really costs.  How you do that is 
a different story and the draft to my best memory and search skills does 
not say how to achieve it (as others have pointed out before) due to the 
different nature of the different operating systems.

/bz

---

From: Sander Steffann <[email-masked]>
Date: Fri, 10 May 2019 14:55:48 +0200

Hi Bjoern,

>   all RAs received have the flag set to 1, a host SHOULD NOT attempt

And that last bit is exactly where the problem is: it is too strong. Something like "If all RAs received have the flag set to 1, a host SHOULD NOT aggressively retry any failed IPv4 operations (like obtaining a DHCP lease) and operate without using IPv4 as much as possible to reduce unwanted/unnecessary IPv4 traffic on the network. Especially operations that transmit broadcast packets should be avoided to save the battery life of other devices on the network."

So, as has been suggested before: turn it from an off-flag to a useful heuristic. I will remain strongly opposed to a hard off-flag for the reasons explained previously. I still think Bert is right: "Not necessary, not sufficient, therefore, IMO, not needed." so I'll probably never be a supporter of this draft, but if we are talking about a heuristic then I can at least reevaluate my objections to see if we can reach consensus.

Cheers,
Sander

---

From: David Farmer <[email-masked]>
Date: Fri, 10 May 2019 08:47:59 -0500

On Fri, May 10, 2019 at 7:56 AM Sander Steffann <[email-masked]> wrote:

> And that last bit is exactly where the problem is: it is too strong.
> Something like "If all RAs received have the flag set to 1, a host SHOULD
> NOT aggressively retry any failed IPv4 operations (like obtaining a DHCP
> lease) and operate without using IPv4 as much as possible to reduce
> unwanted/unnecessary IPv4 traffic on the network. Especially operations
> that transmit broadcast packets should be avoided to save the battery life
> of other devices on the network."
>
> So, as has been suggested before: turn it from an off-flag to a useful
> heuristic. I will remain strongly opposed to a hard off-flag for the
> reasons explained previously. I still think Bert is right: "Not necessary,
> not sufficient, therefore, IMO, not needed." so I'll probably never be a
> supporter of this draft, but if we are talking about a heuristic then I can
> at least reevaluate my objections to see if we can reach consensus.
>

I have to agree that a "hard off" for IPv4, especially global scope unicast
IPv4 is not necessary, it is not the problem. If a dual-stack host doesn't
get an IPv4 DHCPOFFER, it won't do global scope unicast IPv4. The primary
problem described in the problem statement is RFC 3927 and futile IPv4
service discovery using Link-Local IPv4 addresses. I am suggesting we
change the flag to be a "hard off" only for RFC 3927, and then its a
heuristic hint to fairly quickly stop, or at least severely limit, periodic
IPv4 DHCPDISCOVERS, or a "soft off" for global scope unicast IPv4.

Furthermore, at least in the near-term, I don't believe IPv6-Only networks
are going to be very common. Therefore, I don't think delaying the initial
IPv4 DHCPDISCOVERS until the IPv6 RAs can be analyzed is a good tactic.
While I think it should be permitted, I don't think it should be
encouraged, at least until IPv6-Only networks become the dominant solution
and dual-stack or IPv4-Only networks are rare. Which is by no means the
case today. Today, delaying initial IPv4 DHCPDISCOVERS is bad advice.

Thanks

---

From: Sander Steffann <[email-masked]>
Date: Fri, 10 May 2019 15:50:47 +0200

Hi David,

> I have to agree that a "hard off" for IPv4, especially global scope unicast IPv4 is not necessary, it is not the problem. If a dual-stack host doesn't get an IPv4 DHCPOFFER, it won't do global scope unicast IPv4. The primary problem described in the problem statement is RFC 3927 and futile IPv4 service discovery using Link-Local IPv4 addresses. I am suggesting we change the flag to be a "hard off" only for RFC 3927, and then its a heuristic hint to fairly quickly stop, or at least severely limit, periodic IPv4 DHCPDISCOVERS, or a "soft off" for global scope unicast IPv4.
> 
> Furthermore, at least in the near-term, I don't believe IPv6-Only networks are going to be very common. Therefore, I don't think delaying the initial IPv4 DHCPDISCOVERS until the IPv6 RAs can be analyzed is a good tactic.  While I think it should be permitted, I don't think it should be encouraged, at least until IPv6-Only networks become the dominant solution and dual-stack or IPv4-Only networks are rare. Which is by no means the case today. Today, delaying initial IPv4 DHCPDISCOVERS is bad advice.

That sounds like a good way forward.

Cheers,
Sander

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 May 2019 16:39:32 +0200

>A.1.  FreeBSD Implementation  . . . . . . . . . . . . . . . . .  13

It seems that I missed that. 

It is good that there is at least some implementation experience. That
does raise the question why the security section is so incomplete. I
guess the freebsd project doesn't care as the code is marked experimental
and is disabled by default. 

Am I correct to assume that starting rtsol before dhclient will causes a
3 second delay on IPv4-only networks?

---

From: David Farmer <[email-masked]>
Date: Fri, 10 May 2019 09:52:54 -0500

On Fri, May 10, 2019 at 8:47 AM David Farmer <[email-masked]> wrote:

> I have to agree that a "hard off" for IPv4, especially global scope
> unicast IPv4 is not necessary, it is not the problem. If a dual-stack host
> doesn't get an IPv4 DHCPOFFER, it won't do global scope unicast IPv4. The
> primary problem described in the problem statement is RFC 3927 and futile
> IPv4 service discovery using Link-Local IPv4 addresses. I am suggesting we

I just had an additional thought, should there be any effect on a
statically configured global scope unicast IPv4 address on a host in the
presence of this flag?

This question got me thinking, the problem isn't really having an address
configured on the IPv4 stack or even having the IPv4 stack turned on, the
problem on the wire is IPv4 service discovery and too persistently sending
out periodic IPv4 DHCPDISCOVERS.

So really the effect we needed is not necessarily a "hard off" for the IPv4
stack or even RFC 3927. If the IPv4 stack has an address on it, statically
configured or from RFC 3927, who cares. It is the generation of futile IPv4
service discovery traffic using that address and overly persistently
periodic IPv4 DHCPDISCOVERS that is the issue for local battery and
possibly WiFi airtime.

Therefore, maybe what should be specified is a "hard off" for IPv4 service
discovery in the presence of the flag and limiting IPv4 DHCPDISCOVERS. Then
note depending on the details of the IPv4 stack implementation the
necessary effects can be achieved in several ways;

1. Turn off IPv4 service discovery and limit IPv4 DHCPDISCOVERS.
2. Do not configure an RFC 3927 address, if no IPv4 DHCPOFFER is received
and limit IPv4 DHCPDISCOVERS.
3. Turn off the IPv4 stack altogether.

Noting that the list is in order of preference, but the particulars of the
IPv4 stack implementation will dictate the best solution in each
implementation. Further, option #3 is NOT RECOMMENDED for especially for
general purpose hosts.

Thanks

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 10 May 2019 17:31:42 +0000

> It seems that I missed that.

That’s ok.

> does raise the question why the security section is so incomplete.

You did see the -05 addition in reply to all the “security concerns” 
saying …?

7.  Host Behavior Considerations

    Hosts that support the IPv6-Only RA flag MUST have a configuration
    option to ignore or process the flag.  The motivation for this
    configuration option is for hosts that are capable of processing the
    IPv6-Only flag to only act on the flag if they are configured to do
    so.

So you don’t like the IPv6-only bit, you turn its processing off even 
if it’s implemented.  Maybe it’s even off by default (for the next 
year until your OS vendor thinks the times have changed).  Either way, 
you have full control.  What more can you ask for than a total off 
switch?  Save 40 lines of code?

> I

Well, it’s not so much the project as to that I personally did the 
code and committed it.

Given it’s work in progress, uses IANA unassigned bits, and was 
unclear where it’ll go, I didn’t want to imply any support 
guarantees.
Yet it’s there for people to test, to see how many lines changes an 
implementation needs (“the cost of implementing this”), ..
People here asked for an implementation, they got one, so they could 
see.  Can’t say many seem to have done that, so makes me wonder why 
they asked for one.  And they seem to have gotten another one after 
that, so more than just me thought it’s worth giving it a try.

It was kind-of funny that even the ARP implementing got improved 
alongside implementing this, so this legacy stuff I don’t care about 
gives better feedback after 25 years in a few situations :)

> 3 second delay on IPv4-only networks?

Ever wondered how much delay you have with dhclient running on an 
IPv6-only network (without this flag)?  But that’s a matter of the 
startup framework and software used in this particular case and not 
necessarily generally applicable.  Anyway, you still have to say you 
want IPv6 for it to run in first place.

/bz

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 May 2019 19:37:34 +0200

>stack or even RFC 3927. 

One thing that could work is to turn the flag into a 'no IPv4 link local
in the absence of DHCPv4' flag.

As far as I know, networks that rely on IPv4 link local are quite rare and
in general you would not expect an untrused host to show up on such a network.
That should kill any unwanted service discovery.

Then the flag can be used as a heuristic to reduce the DHCPv4 DISCOVER rate.
That should be safe as long the host just reduces the rate to something
reasonable instead of completely stopping DHCPv4.

Anybody who is worried about the flag would then only have to run a DHCPv4
server, which is what the vast majority of the IPv4 networks already have.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 10 May 2019 17:43:05 +0000

> implementation. Further, option #3 is NOT RECOMMENDED for especially 

I like that thinking.  Keep going.

Here’s a suggestion.  If you were to implement your 1 or 2 or 3 what 
would you still see on your (IPv6 enabled) network if you’d run:

tcpdump -ln -e -s0 [-i <iface>] ipv4 or arp   (or use wireshark or 
equivalent).

Then, here’s the next question, using OSX as an example (you can do it 
on some other OSes in other ways):

networksetup -setv4off <networkservice>			(in the GUI: Configure IPv4: 
off)

and then run the tcpdump again.

Then think what you’d still see if all of that if all hosts would 
implement your 1/2/3?

Then repeat the same experiment on your unmanaged home network, your 
campus network, a coffee shop.

It’s enlightening :-)

/bz

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 May 2019 11:53:12 -0700

At Thu, 9 May 2019 11:08:03 +0200 (CEST),

>     IPv4 operations MAY be started.

This text doesn't read to me that "a host SHOULD NOT start IPv4
operations until it has received an RA with the ipv6only-flag
cleared".  At least literally, it just talks about the host's behavior
*after* it receives an RA with ipv6only-flag on.

Note also that this same section clarifies the case where there's no
IPv6 default router:

   [...]  In other words, at any given
   time, the state of the flag as seen by the host is the logical AND of
   the flags sent by all unexpired default IPv6 routers on the link.

   This also means that if all default routers on the link have set the
   flag, the resulting host state for the link is IPv6-Only.  If the
   lifetimes of all the routers on the link subsequently expire, then
   the host state for the link is not IPv6-Only.

Although the specific situation it discusses is when the lifetimes of
IPv6 default routers expire, I believe it's natural to apply the same
logic to when a host hasn't received any RAs at all (on startup).

If the author's intent is actually different from that on the startup
case, I think it should be more explicitly clarified; if my
understanding of the intent is correct, those objections would be
based on misunderstanding of the text, so it's probably better to
clarify it explicitly.

Note: this comment is independent from whether the proposal is good or
bad (I'm personally mostly neutral about it).  It's basically about
its editorial clarity.

--
JINMEI, Tatuya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 May 2019 22:08:26 +0200 (CEST)

> *after* it receives an RA with ipv6only-flag on.

Some people seems to have read "attempt" in the above text as "should not 
start", meaning it should delay starting IPv4 operations until it knows 
about the status of this flag (the host has no idea about the flag status 
until it has received RAs at attach time).

If we don't want this to happen then the current text in -05 is not clear 
enough on this case. I believe several people have voiced their opinion 
that they would accept the flag being part of the heuristic of deciding 
whether to continue doing DHCPv4 and/or IPv4 LL (or not). The -05 text 
doesn't seem to actually say this, so it should be changed?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 May 2019 08:45:50 +1200

On 11-May-19 01:47, David Farmer wrote:
...
> I have to agree that a "hard off" for IPv4...

Yeah. If we'd proposed that, we'd have been stupid. We didn't.

   Brian

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 10 May 2019 20:59:29 +0000

On 10 May 2019, at 20:08, Mikael Abrahamsson wrote:

> Some people seems to have read "attempt" in the above text as "should 
> not start", meaning it should delay starting IPv4 operations until it 
> knows about the status of this flag (the host has no idea about the 
> flag status until it has received RAs at attach time).
>
> If we don't want this to happen then the current text in -05 is not 
> clear enough on this case. I believe several people have voiced their 
> opinion that they would accept the flag being part of the heuristic of 
> deciding whether to continue doing DHCPv4 and/or IPv4 LL (or not). The 
> -05 text doesn't seem to actually say this, so it should be changed?

As a non-native English speaker, would adding a “.. attempt any 
 >>further<< IPv4 operations, ..” reflect what you mean?

/bz

---

From: David Farmer <[email-masked]>
Date: Fri, 10 May 2019 16:00:03 -0500

On Fri, May 10, 2019 at 3:46 PM Brian E Carpenter <
[email-masked]> wrote:

> ....

It may not have been your intent, but that is how many were interpreting
it, or they were not comfortable with how others might interpret it. I
realize you just didn't want to specify too many specifics allowing room
for implementers to find the right answer for each situation.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 May 2019 13:12:22 +1200

> doesn't seem to actually say this, so it should be changed?

It's always been my opinion that the flag is input to a heuristic; but
from time to time we've had pushback asking for it to be more definitive.

Since I'm remarkably bad at predicting the future, despite much practice,
I really don't know what will be the right heuristic ten or twenty years
from now.

(The Google statistics were up to 28.02% IPv6 on May 4th. The future seems
to be getting closer.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 May 2019 13:14:16 +1200

On 11-May-19 09:00, David Farmer wrote:
> 
> On Fri, May 10, 2019 at 3:46 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> It may not have been your intent, but that is how many were interpreting it, or they were not comfortable with how others might interpret it. I realize you just didn't want to specify too many specifics allowing room for implementers to find the right answer for each situation.  

Exactly. If the document goes forward, this has to be very clear in the final text (see several other recent helpful comments).

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 May 2019 13:23:58 +1200

On 11-May-19 06:53, 神明達哉 wrote:
> Mikael Abrahamsson <[email-masked] <mailto:[email-masked]>> wrote:
> 

It seems to me that the host's internal 'IPv6-only-received' flag
theoretically has three states: Unknown, False, True.

Unknown means it's too soon after interface-up to know the status.
The only safe treatment of Unknown is to treat it as False.
 
> based on misunderstanding of the text, so it's probably better to

Yes, it should be made clear to the reader.

Thanks
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 May 2019 13:03:55 +1200

> That sounds like a good way forward.

I think I agree, except that I don't think the IETF should utter an edict about exactly how hosts do all this, because things will change over time. So whatever we say should be at most a SHOULD, and probably this WG shouldn't get too far into operational recommendations anyway.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 May 2019 08:52:50 +0200 (CEST)

> from time to time we've had pushback asking for it to be more 

It's been my take that regardless what we write in the document, it's 
going to be treated as a signal and the host will do whatever the device 
manufacturer thinks is best. The "SHOULD NOT" in term of "IPv4 operations" 
leave enough room for interpretation for that.

However, others have interpreted the document differently, so it's obvious 
that the text needs changing. I think we have rough consensus on the flag 
being a signal (much like the M/O flag) that the host can act on if it so 
desires. So if the text can be changed to actually say so, it seems to me 
this is acceptable to a rough majority and we could then progress the 
document.

I am not super happy about leaving the ambiguity out there (see the 
earlier discussion on different OSes doing different things when the M/O 
flag changes) but I think it's the prudent way because we can't predict 
all the use-cases out there, and the different types of devices. The 
implementors know this best, and the document could point out in the 
considerations section some things that have been brought up in the 
discussions so far.

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 May 2019 17:02:11 +1000

On Fri, 10 May 2019 at 01:22, David Farmer <[email-masked]> wrote:
>  As I see it, at least for the foreseeable future, we want dual-stack hosts to perform equally well on dual-stack networks as on IPv6-Only networks. So in my opinion, this means we don't want to completely eliminate DHCPDISCOVERS, at least at the beginning of the attachment process. Maybe someday in the future, IPv4 will become rare enough we can delay even these initial DHCPDISCOVERS, but at this point, I don't think that is a wise move.
>
> As I see it, we want a positive signal to dual-stack hosts that further DHCPDISCOVERS, after the initial few, are futile and can be stopped fairly quickly. But upon attachment to a network, at least for now, a dual-stack host should assume it is more likely to be attaching to a dual-stack network than to an IPv6-Only network. Therefore, it should send both an IPv6 ROUTER SOLICITATION and an IPv4 DHCPDISCOVER at roughly the same time, moments after the network attachment is stable.
>

I think this is going backwards. We already prefer IPv6 over IPv4 by
default in terms of address selection and in happy eyeballs.

IPv4 is the legacy protocol, delaying its startup until IPv6 has been
initialised is consistent with the IPv6 preference.

> On dual-stack networks, the host will receive a response to both of these queries and configure both IPv4 and IPv6. However, on an IPv6-Only network, the host will not receive any DHCPOFFERS in response to the DHCPDISCOVER, but it will get a response to the IPv6 ROUTER SOLICITATION, one or more ROUTER ADVERTISEMENTS, hopefully with this flag set. At this point, the dual-stack host knows it SHOULD NOT auto-configured an IPv4 Link-Local address [RFC3927]. But it doesn't know for sure that it won't get any DHCPOFFERS, before the dual-stack host can know that for sure, it needs to wait long enough to have received all possible ROUTER ADVERTISEMENTS and make sure all ROUTER ADVERTISEMENTS have this flag set.
>
> If the dual-stack host receives any DHCPOFFERS, it SHOULD accept one of them regardless of the setting of the flag. Again the lack of DHCPOFFERS is the primary signal, not this flag. Only after the dual-stack host has received all ROUTER ADVERTISEMENTS and they all have this flag set is it safe for a dual-stack host to assume it can cease sending DHCPDISCOVERS. Further if at any time, a dual-stack host receives a ROUTER ADVERTISEMENT with this flag cleared, it should continue sending DHCPDISCOVERS periodically.
>
> Making the lack of DHCPOFFERS the primary signal and this flag a secondary signal mitigates almost all the risks associated with this flag. So, this flag is not saying turn off IPv4, this flag is saying assume that the lack of any DHCPOFFERS is an intentional act and don't auto-configured an IPv4 Link-Local address or perform any IPv4 service discovery with an IPv4 link-local address. Further, if you see only ROUTER ADVERTISEMENTS with this flag set, you can fairly quickly stop sending DHCPDISCOVERS at all, they are not going to get answered.
>
> Thanks
>
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 May 2019 09:11:44 +0200 (CEST)

> initialised is consistent with the IPv6 preference.

Device manufacturers won't do it that way. My take on it is that they will 
do along the lines of what Apple did with their HE deployment. They'll 
start off no advantage for either protocol, gather data, then change to 
delay IPv4 slightly and then perhaps in 10-50 years if IPv6-only with 
IPv4aaS becomes the norm then just use IPv4 as fallback in case IPv6 
doesn't work properly.

We should not mandate anything here about exact device behaviour, we 
should say "this is a signal from the network that the network 
administrator is indicating that this is an IPv6 only network". That's all 
it is, and now the device manufacturer can decide depending on their 
use-case what is the best way to respond to this signal for that 
particular device.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 11 May 2019 11:42:31 +0200

>switch?  Save 40 lines of code?

For those who think that this flag is not needed, it doesn't help to
say that the flag can be off.

For network operators who are worried, it doesn't help to say that the user
can turn it off. 

>want IPv6 for it to run in first place.

Most networks today are IPv4-only. Delaying the common case by
3 seconds strikes me as weird. Also a good reason for users to keep the
flag off. Which makes the whole thing rather useless.

This draft adds almost nothing over what can be achieved with a few
heuristics.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 May 2019 08:35:38 +1200

> e.g. filtering at layer to, based on the Ether Proto.

I think the draft already considers both of those arguments.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 May 2019 13:39:48 -0700

> On May 6, 2019, at 2:47 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Actually, they should, because in their notes to the IESG they are asked whether anyone has threatened to appeal. Job threatened to appeal, and is highlighting the fact with this sentence.

And for the record, Job, Nick, and Sander are not the only ones that are not members of the putative consensus. I have stated (would have to look it up to give you the link to the email and the date) that IMHO the benefits are minor and there is a security loophole. My issues remain unaddressed. So I'm part of the anti-consensus. And I'm pretty sure I'm not alone.

As to "rough consensus" and its nature, the way I have interpreted it multiple working groups - including the IESG - has been that if I have a person that has an issue and simply won't shut up, I focus on listening to the person and making sure that they are heard. The concept is that the majority is often wrong, but a minority may have noticed an issue that will turn out to be important. So it is important to listen carefully to that minority. Their view is only set aside when the working group concludes that they simply are not interested in having the issue resolved, and they are the only speaker. If I have multiple speakers - and especially, in matters of operation such as this one, operational speakers - it's not "rough consensus", it's "failure to achieve consensus."

My $0.02.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 May 2019 08:51:36 +1200

> Actually, they should, because in their notes to the IESG they are asked whether anyone has threatened to appeal. Job threatened to appeal, and is highlighting the fact with this sentence.

Yes, if the document advances, that should be in the writeup. But the decision whether it advances must be based on outcome of the technical arguments.
 
> And for the record, Job, Nick, and Sander are not the only ones that are not members of the putative consensus. I have stated (would have to look it up to give you the link to the email and the dat…

Yes, that's correct. And your issues haven't been addressed because they're intrinsic to the proposal. That's why we're having this discussion.
 
> As to "rough consensus" and its nature, the way I have interpreted it multiple working groups - including the IESG - has been that if I have a person that has an issue and simply won't shut up, I f…

I quite agree. At the moment it's Ole's call what happens next. We've had some good proposals for improving the text, but that doesn't resolve the main question.

Regards
   Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 11 May 2019 17:17:19 -0500

On Sat, May 11, 2019 at 3:39 PM Fred Baker <[email-masked]> wrote:

> And for the record, Job, Nick, and Sander are not the only ones that are
> not members of the putative consensus. I have stated (would have to look it
> up to give you the link to the email and the date) that IMHO the benefits
> are minor and there is a security loophole. My issues remain unaddressed.
> So I'm part of the anti-consensus. And I'm pretty sure I'm not alone.
>

Fred,

Please correct me if I'm wrong, but I believe your objection is that it
would be more efficient to simply perform exponential backoff on the IPv4
DHCPDISCOVERS. Do I have that right? If not please help me better
understand your objection.

In my opinion, you are correct if that were the only or even the primary
source of futile IPv4 traffic. In effect, RFC 3927 configures a Link-Local
IPv4 scoped address if a DHCPOFFER is not received, and then this
Link-Local address is used to perform futile IPv4 service discovery. From
my perspective, this is the primary problem, not futile IPv4 DHCPDISCOVERS.
As you say exponential backoff of the DHCPDISCOVERS would easily control
that issue. However, something also needs to signal the dual-stack host to
not perform IPv4 service discovery because the dual-stack host is on an
IPv6-Only network, I believe this flag serves this purpose well.

Further, as of late I've been trying to listen very closely to the
objections. In listening to the objections, I came up with the concept that
the lack of IPv4 DHCPOFFERS should be considered the primary signal and
this flag is a secondary signal mainly intended to disable IPv4 service
discovery.

Thanks

---

From: David Farmer <[email-masked]>
Date: Sat, 11 May 2019 17:29:56 -0500

> IPv4aaS becomes the norm then just use IPv4 as fallback in case IPv6

Furthermore, in most cases, there is no advantage to delaying the IPv4
DHCPDISCOVERS. If an IPv6-Ony network really cares it should be filtering
the IPv4 packets. For the dual-stack host, it is a trade-off of a little
bit more power for a quick startup of IPv4 if it is there. A few more
packets when the host is already awake isn't going to matter that much to
its power draw. The issue for the host is the power draw over time for
continuing futile IPv4 service discovery and IPv4 DHCPDISCOVERS, especially
after it can be determined that they are futile.

> use-case what is the best way to respond to this signal for that

I don't think we should mandate anything either but we should provide some
suggested actions, maybe something like the following;

The lack of any IPv4 DHCPOFFERS in response to initial IPv4
DHCPDISCOVERS is considered the primary signal for a dual-stack host to not
configure a global scope unicast IPv4 address. The presence of only RAs
with this flag set is considered a secondary signal to fairly quickly stop
or severely limit through the aggressive use of exponential
backoff periodic IPv4 DHCPDISCOVERS and to take one of the
following suggested actions to prevent futile IPv4 service discovery
traffic. This non-exhaustive list is in order of preference, but the
particulars of the IPv4 stack implementation will dictate the best solution
for individual implementations. However, option #3 is NOT RECOMMENDED,
especially for general purpose hosts and mobile devices. However, this
could be an appropriate action by constrained devices.

1. Turn off IPv4 service discovery, such as mDNS [RFC6762].
2. Do not auto-configure an IPv4 Link-Local scope address [RFC3927].
3. Turn off the IPv4 stack altogether.

If a dual-stack host receives an RA with the flag cleared, or all the RAs
with the flag set have expired, periodic IPv4 DHCPDISCOVERS and IPv4
service discovery traffic SHOULD be resumed.

If a dual-stack host receives any IPv4 DHCPOFFERS a global scope unicast
IPv4 address SHOULD be configured regardless of the status of this flag.

While currently not recommended, due to today's prevalence of IPv4, a
dual-stack host MAY delay its initial IPv4 DHCPDISCOVERS until the status
of this flag is known. This could also be an appropriate action by
constrained devices.

Thanks

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sat, 11 May 2019 23:45:31 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Philip Homburg

heuristics.

+1.

(In case some have the mistaken notion that only a couple of stray cats are opposed.)

There will no doubt be a time when equipment vendors will leave IPv4 off by default, and only turn it on if there's some site that can't be reached with IPv6. Like, DNS only sends an A record. That time will come with or without this flag.

I totally agree with those who say that "this flag adds a heuristic." But what bothers me more than a little is, is that reason enough? To merely add a heuristic to a bunch that already exist, requiring a change to the protocol? And perhaps more problematic, to change a protocol to suggest a totally different protocol should be disregarded? What next?

Thinking of this in terms of religious fundamentalism, it sounds quite politically incorrect! ;)

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 May 2019 13:26:35 +1200

Bert,

Two brief comments:
> (In case some have the mistaken notion that only a couple of stray cats are opposed.)

1) The whole argument basically is whether it's "almost nothing" or "something useful", and that very much depends on the deployment scenario, now or at some unknown time in the future.

2) sunset4 failed to document such heuristics. In this thread we have the makings of a useful set of heuristics, with or without the ipv6only flag. But that would presumably be v6ops or opsawg territory.

Regards
   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 12 May 2019 08:12:46 +0200 (CEST)

> 3. Turn off the IPv4 stack altogether.

I think the authors wanted to avoid having examples and specifics, and 
have summed this up as "IPv4 operations". If it helps to progress the 
document that we include more specifics (like above), I'm fine with that.

However, we need to make sure we don't actually become too prescriptive. 
Having some kind of example list of things that "IPv4 operations" means is 
fine, but I want to leave the interpretation of this to the device 
manufacturers. They know best their capabilities and functionalities of 
their devices and use-cases, and we should leave the interpretation up to 
them.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 12 May 2019 17:20:42 +0200

>IPv6-Only network, I believe this flag serves this purpose well.

It is safe to assume that if an interface has no IPv4 address
configured at all then that interface cannot be used for IPv4 service
discovery

We can assume that on an IPv6-only network there will be no DHCPv4 so the
host will not get addresses through that route.

That leaves RFC 3927. I think a simple heurisctic could be the following:
A host SHOULD NOT configure an RFC 3927 on an interface if the host has
working IPv6 on that interface unless the configuration of an IPv4 link local
address is explicitly requested by the user.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 12 May 2019 17:33:52 +0200

>2) sunset4 failed to document such heuristics. In this thread we have the maki
>ngs of a useful set of heuristics, with or without the ipv6only flag. But that
> would presumably be v6ops or opsawg territory.

Sunset4 tried something similar as this draft
(https://tools.ietf.org/html/draft-ietf-sunset4-noipv4-01)
and then failed to get consensus.

Beyond that, there are as far as I know no drafts that specify IPv4
heuristics. There are also no drafts with a problem statement.

So I'm not sure to what extent sunset4 actually tried to document such
heuristics.

---

From: David Farmer <[email-masked]>
Date: Sun, 12 May 2019 11:40:07 -0500

> address is explicitly requested by the user.

Yes, that is a possible solution.  However, that solution continuously
links IPv4 to IPv6 and only unlinks them if the host has been configured to
unlink them. Whereas this flag only links IPv4 to IPv6 if the network
Administrator has consciously decided to do so. Also, as currently written
the host can be configured to ignore the flag and never link IPv4 to IPv6.

The problem is, without a flag to clearly designate a network as IPv6-Only,
then with your proposal if the DHCPv4 server on a dual-stack network ever
decides to not grant an IPv4 address to a client, due to a misconfiguration
or it simply crashes, then that client will inappropriately disable
RFC3927.  Whereas with a flag declaring a network as IPv6-Only, RFC3927 is
only inappropriately disabled when two misconfigurations or a
misconfiguration and a problem occurs.

I contend that having a flag to declare a network as IPv6-only is the only
way to safely change the behavior of the IPv4 stack on dual-stack hosts
without creating corner cases where something happens inappropriately.
Also, for the flag to be safe, it must be a secondary signal, the primary
signal for a dual-stack host to not configure a global scope unicast IPv4
address is the lack of any IPv4 DHCPOFFERS.  This way to inappropriately
disable IPv4 on an operational dual-stack network, or an IPv4-Only network
you have to both set the flag on all RAs and disable the IPv4 DHCP server.

Thanks.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 12 May 2019 12:54:47 -0400

Mikel

It sounds like the OS manufacturers are what is driving this such as Microsoft and in the end they will do what is best for them based on their interpretation so I think as mentioned would be nice to nail it down but from the manufacturer perspective keeping it a little bit broad but crystal clear that it’s a signal to the host that changes IPv4 behavior to be disabled or suppressed.

I think we far as migration strategies I think that is overall a big win from an access perspective in terms of IP administration not having to manage both IPv4 and IPv6 allocations and IPv6 being hierarchical and classless makes IP management simple so a big gain for OS and IT support on managed networks being deployed to go day 1 provision as IPv6 only  and existing networks for gain of IT support staff administrators being able to scale down the support staff could also easily migrate NOW to IPv6 only using the 6to4 nat 6to4 dns and 6to4 proxy to access IPv4 internal and external resources.

Brian

In the draft can we mention simplifying IT address administration being a technical business driver for enterprises to start migrating NOW to IPV6 only and maybe also all newly deployed managed and maybe even unmanaged could also go in Day 1 IPv6 only.

Gyan

Sent from my iPhone

> On May 11, 2019, at 2:52 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> It's always been my opinion that the flag is input to a heuristic; but from time to time we've had pushback asking for it to be more definitive.
> 
> It's been my take that regardless what we write in the document, it's going to be treated as a signal and the host will do whatever the device manufacturer thinks is best. The "SHOULD NOT" in term of "IPv4 operations" leave enough room for interpretation for that.
> 
> However, others have interpreted the document differently, so it's obvious that the text needs changing. I think we have rough consensus on the flag being a signal (much like the M/O flag) that the host can act on if it so desires. So if the text can be changed to actually say so, it seems to me this is acceptable to a rough majority and we could then progress the document.
> 
> I am not super happy about leaving the ambiguity out there (see the earlier discussion on different OSes doing different things when the M/O flag changes) but I think it's the prudent way because we can't predict all the use-cases out there, and the different types of devices. The implementors know this best, and the document could point out in the considerations section some things that have been brought up in the discussions so far.
> 
> --

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 12 May 2019 18:28:15 -0700

> On Apr 29, 2019, at 03:02, Ole Troan <[email-masked]> wrote:
> 

I support this draft. I think many of the concerns associated with this draft are well considered, unfortunately they also cannot fundamentally be resolved using other signals in meaningfully better ways. 

If you're going to use RA options to communicate the presence of routers on a subnet as well is rules for their use and extended to communication other network management properties  as we did in 5175 and 8106 then we've already conceded that it is approve to use for a facility like this. 

We can reasonably expect hosts that have other overriding considerations to ignore such signals, just as today they select their own name servers.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 12 May 2019 21:55:34 -0700

> On May 3, 2019, at 13:15, Brian E Carpenter <[email-masked]> wrote:
> 

Send is a bit of a red herring.  You're  either on a network you can trust and it's therefore irrelevant, or you're on a network which you cannot, and it will not be offered, or will be offered by an unstrustworthy actor, anchoring it to the RPKI  as 6494 does doesn't change that, it just means untrustworthy actors are resource holders.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 May 2019 11:26:07 +0200

>misconfiguration and a problem occurs.

This strikes me as a bad trade-off. You propose that every network that
doesn't want IPv4 link local has to set a flag just to help the rare case
of a DHCPv4 server failing and users able to get useful work done using
IPv4 link local.

So instead of letting IPv4 die. We would add a flag to IPv6 to help in the
case IPv4 has a problem. Does that make any sense?

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 May 2019 13:02:50 +0200

All,

The call is now over. Thank you very much for all the comments from everyone.
You are not making this easy. ;-)

Please allow me a few days to summarise and conclude this call.
Something I will do together with our AD.

Best regards,
Ole (6man co-chair).

> On 29 Apr 2019, at 12:02, Ole Troan <[email-masked]> wrote:
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 13 May 2019 12:50:21 +0000

> On 11 May 2019, at 07:52, Mikael Abrahamsson <[email-masked]> wrote:
> 

That sums up my view very well.

I also agree with Brian when he said "In this thread we have the makings of a useful set of heuristics, with or without the ipv6only flag. But that would presumably be v6ops or opsawg territory."   That's something to take forward in those groups.

Tim

---

From: David Farmer <[email-masked]>
Date: Mon, 13 May 2019 09:28:05 -0500

> case IPv4 has a problem. Does that make any sense?

I don't propose this, I simply contend that it is what RFC3927 and
dual-stack model intends. Per Section 2 of RFC 4213, the dual-stack model
expects dual-stack hosts to be fully compatible with IPv4-Only hosts.
Further, there are good reasons to require this for compatibility between
dual-stack hosts and IPv4-Only hosts. If dual-stack hosts were to do as you
say and not configure a Link-Local IPv4 address if they have a working IPv6
address they would not be able to communicate with IPv4 Link-Local or
global scope unicast IPv4 addresses on the local link unless they receive a
global scope unicast IPv4 address via DHCPv4. Your proposed change breaks
the dual-stack model.

By the way, do you mean any working IPv6 address? Because all IPv6 host
will have an IPv6 Link-Local address. So, do you mean a global scope
unicast IPv6 address?

Without some kind of explicit signal that a network is intended to be
IPv6-Only, per Section 2 of RFC4213 a dual-stack host needs to be fully
compatible with IPv4-Only hosts that could be on the dual-stack network.

Thanks.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 May 2019 17:08:10 +0200

>expects dual-stack hosts to be fully compatible with IPv4-Only hosts.

RFC 4213, Section 2.1 starts with:
"Because the nodes support both protocols, IPv6/IPv4 nodes may be
configured with both IPv4 and IPv6 addresses."

Nowhere does RFC 4213 Section 2 say that IPv4 address configuration has to
be the same between IPv4-only and dual stack.

Beyond that, IPv4 is a legacy protocol. There is no reason we can't publish
a RFC that updates a RFC from 2005.

>global scope unicast IPv4 address via DHCPv4. Your proposed change breaks

Please provide examples where people are actively using IPv4 link local
together with IPv6-only in the case the DHCPv4 server fails.

I clearly wrote that the user should be able override this behavior. So if
a site wants to use IPv4 link local to access legacy devices, then the user
would have to change a setting. That's to be expected if you want to use
legacy devices in a modern network.

IPv4 is a legacy protocol. We should not add protocol complexity just to keep
obscure IPv4 features alive.

>will have an IPv6 Link-Local address. So, do you mean a global scope

Just an IPv6 link-local is not evidence of IPv6 connectivity. My guess is
that checking for any global address is enough. But if a stack wants to
go beyond that and make sure that there is global connectivity and access
to a DNS resolver then that is fine with me.

>compatible with IPv4-Only hosts that could be on the dual-stack network.

There is no need to maintain obscure details of a legacy protocol.

If IPv4 link locals combined with IPv6 are in active use, then obviously that
would make the situation. But, as far as I know, IPv4 link local is
useless, except for some rather obscure edge cases.

For most people, an IPv4 link local just means that DHCP failed. Not some 
thing you use in a network design.

---

From: David Farmer <[email-masked]>
Date: Mon, 13 May 2019 12:44:12 -0500

> be the same between IPv4-only and dual stack.

The very first sentence of RFC 4213 Section 2 says, "The most
straightforward way for IPv6 nodes to remain compatible with IPv4-only
nodes is by providing a complete IPv4 implementation." You are basically
suggesting that RFC3927 isn't needed. Which seems to be part of a complete
IPv4 implementation, at least as far as I can tell.

> a RFC that updates a RFC from 2005.

Yes, we can update it, but we need consensus to do so and doing it the way
you suggest will break or at least make things that work less reliably than
they do today, so I'm not sure we'll get consensus for what you suggest.

Some people didn't link the breakage possible with this flag, at least
before I suggested that it should be a secondary signal and the lack of
IPv4 DHCPOFFERS should be the primary signal to not configure a global
scope unicast IPv4 address.

> together with IPv6-only in the case the DHCPv4 server fails.

The point is RFC3927 is automatic, most of the time you don't even know you
are using it.  But the easy example of what you break would be printing to
a local IPv4-Only printer. If the dual-stack host doesn't receive a global
unicast IPv4 address and it doesn't configure an IPv4 Link-Local address it
won't be able to print to the local IPv4-Only printer. This kind of thing
would be rather common in the home network environment, and RFC3927 is
important when there are issues with the Internet gateway.

> obscure IPv4 features alive.

Then you are saying that it is ok for local access at unmanaged sites to an
IPv4-Only device can be broken when there is an issue with the local
gateway.

> to a DNS resolver then that is fine with me.

I figured that is what you meant, but we need to be specific.

> useless, except for some rather obscure edge cases.

Those edge cases you think are so obscure, happen every day in the home
environments when the provider gateway goes away, and there are IPv4-Only
devices.

> thing you use in a network design.

Yes, but if you want local access to work in the meantime then you need
RFC3927.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 May 2019 01:51:08 -0400

RFC 3927 IPv4 link local use case instance only occurs in a DHCPv4 failed
state where the host failed to get its network configuration.

The goal of the IPv6 only flag is for the host OS to receive this secondary
signal that if the host OS supports the flag it would disable IPv4
operation and when that happens that does break the dual stack model but
that is the goal of the ipv6 only flag is my interpretation as for the use
case for IPv6 only networks.  So as was mentioned the draft implies in my
opinion that rfc 3927 is unnecessary but the goal is to have the host OS
make the decision on whether the flag should be processed and if the OS
processes the flag then it can chose to disable IPv4 if it is not needed
which is the intent of the draft.

The dual stack model works well and I think it is very hard for most
operators including myself to get out of the dual stack mind set that rfc
3927 and 4213 have to be supported and have to work and if that model
breaks then this ipv6 flag option should not be supported which I disagree
that to be a reason to not support the draft.

This flag is for IPv6 only networks so is really mutually exclusive of the
dual stack hosts on the same subnet as all routers on the same subnet would
be sending the flag set to 1 as secondary signal if no offer is received
and the host does not have IPv4 network access then at that point IPv4 can
be disabled if the OS supports and there is no harm in doing so.

Once the IPv4 DHCPv4 fails and the host are in IPv4 link local mode with no
network access so at that point in time they are ready to receive this
secondary signal and process the ipv6 only flag set to 1 so that IPv4 can
be disabled.

The flag to me would be useful in migration of enterprises quickly to IPv6
and not have to support two protocols and the administrative  overhead of
supporting both and IPv4 & IPv6 addressing plan.  So to me this flag seems
like a great way to get all access network within the enterprise quickly
migrated to IPv6 only subnet.  I think would help break up the dual stack
dependency as well and allow for flatter larger L2 networks.  I think their
are a lot of advantages and use cases for this flag to be incorporated into
migration from dual stack to IPv6 only networks.

Gyan

On Mon, May 13, 2019 at 1:44 PM David Farmer <[email-masked]> wrote:

> The point is RFC3927 is automatic, most of the time you don't even know
> you are using it.  But the easy example of what you break would be printing
> to a local IPv4-Only printer. If the dual-stack host doesn't receive a
> global unicast IPv4 address and it doesn't configure an IPv4 Link-Local
> address it won't be able to print to the local IPv4-Only printer. This kind
> of thing would be rather common in the home network environment, and
> RFC3927 is important when there are issues with the Internet gateway.
>
>
> Then you are saying that it is ok for local access at unmanaged sites to
> an IPv4-Only device can be broken when there is an issue with the local
> gateway.
>
>
>> >compatible with IPv4-Only hosts that could be on the dual-stack network..
>>
> RFC3927..

---

From: Philip Homburg <[email-masked]>
Date: Wed, 15 May 2019 00:00:04 +0200

>IPv4 implementation, at least as far as I can tell.

I assume you notice the informal language that is used there. 

I'm saying that in the context of IPv6 connectivity, RFC 3927 is not needed
unless explicitly enabled by the user.

So the only change is that in the context of IPv6 it would be off by default.

>they do today, so I'm not sure we'll get consensus for what you suggest.

Indeed that's a good question. It is not clear if anything new is actually
needed. For networks, filtering type 0x800 is good enough. Mobile devices
with limited battery power can probably come up with something on their own.

>important when there are issues with the Internet gateway.

This kind of thing could become common in the future, or not.

Today, a mobile host without IPv4 connectivity is dead in the water. IPv4aaS
on LANs is very rare. 

Today, just about every network has a DHCPv4 server.

Like I said before, if there is evidence, that there are lots of production
networks today that combine IPv6 with RFC 3927 (and mobile devices), then yes
my heuristic will not work.

If this is about future networks, then requiring a network to explictly 
support legacy devices by running a DHCPv4 server is a small price to pay.

It would be weird to ask all operators of networks without IPv4 to set a
special flag, for all host to check that flag only to support the
few networks that want to put legacy printers in an IPv6-only network and
don't want to run a DHCPv4 server.

>IPv4-Only device can be broken when there is an issue with the local

Yes, that is perfectly fine. In unmanaged sites, when stuff breaks it is
broken. If today, in an unmanaged site, the DHCPv4 server breaks, then you
may have access to the printer but you lost access to the internet. Guess
what most people care about.

There is no expectation that stuff keeps working when routers or servers 
are down. We know about link local, but we are the only ones. For 
everybody else, IPv4 link local is the weird stuff that happens when
DHCP is down.

>environments when the provider gateway goes away, and there are IPv4-Only

Today, when the CPE is up, you get a DHCPv4 lease. Whether there is an
internet connection or not. If the CPE is off, most likely your wifi
network is down. So we are talking edge cases. The CPE needs to be off and
there needs to be a separate network that is up and connects both the
mobile devices and the printer.

It is not reasonable to require all routers on LANs and all hosts to support
a special flag, just to deal with these kinds of edge cases in a legacy
protocol.

---

From: David Farmer <[email-masked]>
Date: Wed, 15 May 2019 08:27:39 -0500

> So the only change is that in the context of IPv6 it would be off by

Ok, I could live with that. But, when I've heard this kind of thing
discussed before there were serious objections to it. The objections I
remenber heraing were the change you propose effectivly breaks local
printing from a dual-stack host to an IPv4-Only printer if there are any
problems with the local DHCP server.

So, I'm not willing to drop what I think is a viable solution to the
problem unless other stakeholders are willing to buy into this kind of
change. In particular, I'm thinking the people maintaining mDNS in dnssd
wg. I can't see making the change proposed above without their buy-in.

In theory, an IPv4 stack could passively detect the filtering of Ethertype
0x0800 and 0x0806 by passively looking for other ARPs and/or IPv4 service
discovery traffic. However, both of these types of MAC layer broadcast
traffic are typically suppressed on most WiFi networks by the use of proxy
ARP and service discovery proxying or other forms of control or filtering
to limit MAC layer broadcast which is very inefficient on WiFi.  And,
battery-powered WiFi devices is where suppressing the futile IPv4 traffic
is most useful in this whole discussion.

So I think we either need the flag or disable RFC 3927 by default on
dual-stack hosts.

So my question to the WG chair and AD is how do we get input from other
stakeholders on the viability of alternatives to an IPv6-Only flag.

Thanks

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 15 May 2019 14:34:29 +0100

> wg. I can't see making the change proposed above without their buy-in.
[...]
> So I think we either need the flag or disable RFC 3927 by default on 

RFC 2563 already specifies a protocol to turn off ipv4 LLs.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 15 May 2019 15:10:16 +0100

David Farmer wrote on 15/05/2019 14:27:
> In theory, an IPv4 stack could passively detect the filtering of 
> Ethertype 0x0800 and 0x0806 by passively looking for other ARPs and/or 
> IPv4 service discovery traffic. However, both of these types of MAC 
> layer broadcast traffic are typically suppressed on most WiFi networks 
> by the use of proxy ARP and service discovery proxying or other forms of 
> control or filtering to limit MAC layer broadcast which is very 
> inefficient on WiFi.  And, battery-powered WiFi devices is where 
> suppressing the futile IPv4 traffic is most useful in this whole discussion.
> 

Mikael kindly pointed out that I misread your email.

If there are ipv4 ethertype filters in place, RFC 2563 will obviously 
not work because dhcp requests will be blocked. This means that any 
traffic from the host device to the network will be broadcast (ARP) or 
multicast (mdns) only.

MAC layer broadcast/multicast from AP to host is inefficient on WiFi 
because it uses basic rate, but we're talking here about a network with 
L2 ACLs in place, so this won't happen.  Host to AP broadcast/multicast 
frames are sent by unicast to the AP, i.e. normal transmit rate, which 
is efficient in terms of power usage.  That said, the low priority 
nature of mdns can be used to deprioritise transmission of these frames, 
i.e. coalescing transmits with other ipv6 packets, so that you don't end 
up with chip wakeups.  Also, you can heuristically determine that if 
there are no mdns replies on ipv4 but plenty on ipv6, that ipv4 isn't 
active on the network.

If there are no MAC ACLs in place, then RFC 2563 provides a solution to 
ipv4 mdns chatter.

Either way, the justification for another flag seems to be limited.

Nick

---

From: David Farmer <[email-masked]>
Date: Wed, 15 May 2019 09:18:20 -0500

> RFC 2563 already specifies a protocol to turn off ipv4 LLs.

Yes, but that is incompatible with link layer filtering of at least
Ethertypes 0x0800 you could probably still filter 0x0806.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 15 May 2019 16:33:27 -0400

Per RFC 2563 as Dave mentioned the option exists to 
disable IPv4 link local on dual stacked hosts.

I have not tried but can printers use IPv6 link local to print 
similar to IPv4 when a dhcp server is not present?

2. The Auto-Configure Option This option code is used to ask whether, and be notified if, auto- configuration should be disabled on the local subnet. The auto- configure option is an 8-bit number. Code Len Value +-----+-----+-----+ | 116 | 1 | a | +-----+-----+-----+ The code for this option is 116, and its length is 1. This code, along with the IP address assignment, will allow a DHCP client to determine whether or not it should generate a link-local IP address. 

2.1. Auto-Configure Values The auto-configure option uses the following values: DoNotAutoConfigure 0 AutoConfigure 1 When a server responds with the value "AutoConfigure", the client MAY generate a link-local IP address if appropriate. However, if the server responds with "DoNotAutoConfigure", the client MUST NOT generate a link-local IP address, possibly leaving it with no IP address.

Gyan
Sent from my iPhone

> On May 15, 2019, at 9:34 AM, Nick Hilliard <[email-masked]> wrote:
> 
>> So, I'm not willing to drop what I think is a viable solution to the problem unless other stakeholders are willing to buy into this kind of change. In particular, I'm thinking the people maintaining mDNS in dnssd wg. I can't see making the change proposed above without their buy-in.
> [...]
>> So I think we either need the flag or disable RFC 3927 by default on dual-stack hosts.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 May 2019 08:44:42 +1200

> RFC 2563 already specifies a protocol to turn off ipv4 LLs.

Yes, an IPv4-based mechanism. The proposal stipulates that we want a mechanism for IPv6-only networks to signal to dual-stack hosts, as did draft-ietf-sunset4-noipv4. That is of course looking to the future, not to most current networks.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 May 2019 18:03:42 -0400

> similar to IPv4 when a dhcp server is not present?

I think mine can.

In fact, the dhcp server on my "corporate" network (the one trusted for
stuff, vs the one the TVs, media, and experiments, and family is on) has been
broken for a few months for hysterical raisons.  {Fixing it involves being
offline for a few hours, while I reconfigure the replacement router... so I
haven't done it yet}.

So my printing is all over IPv6, but it's not always over LL.
I notice the LLv6 comes and goes, and I don't quite know why, so I'll hard
code the DNS/IPv6-GUA name, and then I'll go back to dnssd discovered LL.

The real question is however: how many clients support those DHCPv4 options?

---

From: David Farmer <[email-masked]>
Date: Wed, 15 May 2019 17:18:36 -0500

> The real question is however: how many clients support those DHCPv4

Most older clients support RFC2563. However, at least in my testing newer
clients seem to have dropped it, but that might have been me screwing up
the test.  And, I haven't found time to reverify.

---

From: David Farmer <[email-masked]>
Date: Wed, 15 May 2019 17:29:22 -0500

On Wed, May 15, 2019 at 9:10 AM Nick Hilliard <[email-masked]> wrote:

> up with chip wakeups.

Ok, maybe I buy that, can someone tell me if that done today?

> Also, you can heuristically determine that if

So please expand on how you heuristically determine you don't need mDNS or
maybe IPv4 LL especially in the presence of ARP and service discovery
proxies which are common on WiFi to suppress MAC Layer broadcasts. Which I
believe makes it had to passively see others host's broadcast. I suppose
you could do an mDNS query for all host on the network and then get back
nothing and decide you are on an IPv6-Only network. But then how would you
know for sure you just aren't the only mDNS speaker on a dual-stack network
at the moment.

Talking this through, if you Layer 2 filter on IPv6-only, I agree that you
prevent any IPv4 traffic from waking up other devices on the network. But
dual-stack battery-powered devices will still produce futile IPv4
DHCPDISCOVERS, exponential back-off work for this. I'm not too worried
about the initial round, I think that is good power spent for now since the
host probably on a dual-stack network, not an IPv6-Only network. However,
I'm not seeing a good heuristic for squelching the IPv4 LL service discover
traffic. Now, I'm ok with what Philip proposed just don't do RFC3927 on
dual-stack hosts, but I don't think other stakeholders will go for this,
but I could be proved wrong.

So without a good heuristic for squelching the IPv4 LL service discover
traffic, battery-powered devices will futilely generate traffic, now I
grant you these devices won't use any more power than they would on a
dual-stack network, and in fact maybe a little less because they will never
receive IPv4 back in response. But if this traffic could be squelched,
there would be power savings, but you seem to be claiming this isn't worth
the effort. I think this is where we disagree.

> Either way, the justification for another flag seems to be limited.

A good heuristic for squelching the IPv4 LL service discover traffic isn't
obvious to me.

Dropping RFC3927 on dual-stack hosts would work, but I'm skeptical of
needed buy off for that plan.

I'd be open to changing my mind with a good heuristic for squelching the
IPv4 LL service discover traffic, without it, the justification for the
flag is good enough for me.

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 May 2019 11:01:49 +1000

> Yes, an IPv4-based mechanism. The proposal stipulates that we want a mechanism for IPv6-only networks to signal to dual-stack hosts, as did draft-ietf-sunset4-noipv4. That is of course looking to t…

IPv6 Only means only IPv6.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 16 May 2019 01:13:02 +0000

> similar to IPv4 when a dhcp server is not present?

Mine could do in 2012.  It was living on an IPv6-only network back then 
already (and so does its successor since).

The old one would also learn prefixes from RAs.  It only had a problem 
with SNMP replies and source address selection for supply level 
information when there was more than one prefix announced by different 
routers on the network (didn’t just turn the addresses around but 
replied from a random address confusing the requesting client).

/bz

---

From: Philip Homburg <[email-masked]>
Date: Thu, 16 May 2019 09:56:30 +0200

>RFC 2563 already specifies a protocol to turn off ipv4 LLs.

Keeping IPv4 link local off by default on links with IPv6 provides a clear
path forward to IPv6-only. It provides a clear expectation that without
DHCPv4 there will be no IPv4.

I.e., IPv4 should be off by default and not something that needs to be
filtered. 

Of course that doesn't kill DHCPv4 DISCOVER. But that is something I think
we can live with until hosts have their IPv4 stacks turned off by default.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 16 May 2019 19:19:38 -0400

That’s pretty cool.

I’ll have to try both the LL and global uni printing at home.  Also try the IPv4 LL printing.

So I guess if dhcp option was set to disable IPv4 link local and on your home network your broadband router supported setting the IPv6 only flag so you could turn off IPv4 and your router went down you could still print via IPv6 LL just as you did in your scenario. 

I guess I could convert my home network to IPv6 only and build V4 and V6 port forwarding rules back to my IPv6 only severs at home.  

Gyan

Sent from my iPhone

> On May 15, 2019, at 9:01 PM, Mark Smith <[email-masked]> wrote:
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 16 May 2019 19:49:26 -0400

Verizon fios is behind on dual stacking unfortunately but in this link they do talk about ISPs going to IPv6 only for customers.  

Makes a lot of sense for all broadband providers to go IPv6 only for security but also pulling back IPv4 as space is limited even though CG nat has allowed the reserved block to be allocated to help prolong IPv4 usage not good for IPv6 but their is major gains to be made still for both broadband and 4G and 5G providers to go IPv6 only even well before enterprises get there and lastly the content providers trailing at the very end.

Just thinking about from a broadband or 4G perspective how to access IPv4 resources on the internet once you are IPv6 only how would the broadband providers accomplish that.  

So a 6to4 proxy gateway would provide web but in reality you need a dynamic nat 6to4 gateway for all service ports.

Most customers use web port 80 and 444 are the primary ports but ssh port 22 would be good and also all flavors of VPN being translated 6to4 dynamically. 

Something to think about for the future of an IPv6 only world at the access layer world wide from broadband and WiFi to wireless 4G 5G to enterprises to eventually content providers and hosting services.

Excerpt from link below:

WHY SHOULD VERIZON MAKE IPV6 AVAILABLE FOR CUSTOMERS?
To be clear, Verizon and all other IPS providers still have IPv4 addresses to issue. IPv4 address aren’t running out right away, and the change to IPv6 isn’t happening overnight. But it is happening. IPv6 coverage is increasing every year. There are several major advantages for ISPs to upgrade as soon as possible.  

While the percentage of strictly IPv6-only sites is relatively small, none of them are accessible to current Verizon customers. Many other IPS customers can see these sites. 

Additionally, IPv6 is more secure. Once the switch to IPv6 is made, IPv4 can be turned off. This will help reduce global cyber attacks and other large-scale hacking. The vulnerabilities of IPv4 are already well-known. But IPv6 uses end-to-end encryption, Secure Neighbor Discovery protocol and other sophisticated security procedures. 

Plus, IPv4 was never supposed to be the final version of the Internet. Early internet pioneer Vint Cerf said IPv4 is “the experimental version of the Internet.” IPv6 is considered the more complete and secure version of the Internet – the world has basically been using a beta version this whole time!

https://www.ipv6.com/blog/how-long-will-verizon-take-to-make-ipv6-available-to-fios-customers-we-believe-its-time/#Verizon_Fios_Upgrades

Sent from my iPhone

> On May 16, 2019, at 7:19 PM, Gyan Mishra <[email-masked]> wrote:
> 
> That’s pretty cool.
>

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 17 May 2019 00:22:36 +0000

Strange blog, ISP often written IPS, and the incorporates some old and long obsolete news about “more secure,” particularly when it mentions end to end encryption and SeND.

Oh well. Not everyone religiously keeps up with 6man, eh?

Bert

From: ipv6 <[email-masked]> On Behalf Of Gyan Mishra
Sent: Thursday, May 16, 2019 19:49
To: Mark Smith <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Alternatives to the flag (Was:Confirmation to advance: draft-ietf-6man-ipv6only-flag-05)

Verizon fios is behind on dual stacking unfortunately but in this link they do talk about ISPs going to IPv6 only for customers..

Excerpt from link below:

Plus, IPv4 was never supposed to be the final version of the Internet. Early internet pioneer Vint Cerf said IPv4 is “the experimental version of the Internet.”<https://www.youtube.com/watch?v=17GtmwyvmWE#t=1620> IPv6 is considered the more complete and secure version of the Internet – the world has basically been using a beta version this whole time!

On May 16, 2019, at 7:19 PM, Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
That’s pretty cool.

Gyan

Sent from my iPhone

On May 15, 2019, at 9:01 PM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, 16 May 2019 at 06:45, Brian E Carpenter
<[email-masked]<mailto:[email-masked]>> wrote:

  Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 20 May 2019 22:18:24 -0400

> together with IPv6-only in the case the DHCPv4 server fails.

Actually, in IPv6-only or failing-DHCPv4-server scenarios, some hosts
will normally configure ipv4 link-locals... which will normally be used
when doing e.g service discovery.

> legacy devices in a modern network.

Most usually, it's not sites that decide to use link-locals, but hosts.
-- it's a host-side policy that is *not* selected or configured on a
per-network basis.

That said, in all cases, I expect the network to "just work". Users
should not be required to understand this sort of technical details for
them to get a good experience.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 May 2019 11:37:56 +0200

>them to get a good experience.

Networks don't 'just work', except in rare cases of completely disconnected
networks.

Today the vast majority of all networks has some kind of router. And in 
simple cases like CPEs, they get configuration from the network. My proposal
is specifically in the case a router provides IPv6 connectivity.

If we now tell hosts to stop doing IPv4 links local in that case (i.e. when
IPv6 connectivity is available) then that can save us a lot of headaches
later.

Of course, can choose to not that, just in case in the future a legacy IPv4
printer is around on an IPv6-only network. But in that case we will have to
live with the mess of hosts trying to do service discovery using IPv4 
link local until forever.

If we say: in the context of IPv6, DHCPv4 signals the presence of native IPv4
on a link, then we make it easy for hosts to figure out what is going on.
We also make it easy to get rid of IPv4.

For users that doesn't matter. The CPE can easily have a DHCPv4 server
that will be on by default in the near future and will be off by default
later. And will be dropped completely when there is no IPv4 support anymore.

In managed networks, it makes clear that if the network admin wants IPv4
there is a DHCPv4 server/relay. Without DHCPv4 server, there should be no
IPv4.

Finally, on completely disconnected networks the situation would be unchanged,
so directly connecting a laptop to an IPv4-only printer would work.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 May 2019 12:36:51 -0400

> Networks don't 'just work', except in rare cases of completely disconnected

In the vast majority of cases, the only thing you need to do is select
network and password. The rest happens automagically.

If I understand correctly, you were arguing that IPv4 SD should be
disabled by default for IPv6 only networks.

For the average user, this means that if they actually needed, now they
are in trouble.

> IPv6 connectivity is available) then that can save us a lot of headaches

What saves headaches is to not disable functionality. At the end of the
day, I wonder the extent to which a few IPv4 packets affect battery on a
normal network as opposed to multiple 200MB+ apps  that drain the CPU
for even the most trivial stuff, continuous wake up do to online
presence apps, etc.

Note: This is not an argument against or in favor of this mechanism. BUt
rather a question whether disabling functionality that may very well be
useful.

> link local until forever.

Indeed. Not forever, but certainly for a long period of time.

And no, it's not just the printer. a bunch of the smart devices you can
connect at home (cameras, smart plugs, sensors, etc.) are still IPv4
only. An "IPv6-only network" will just break all that.

Not that I like it. But my personal taste doesn't change reality per se.

> there is a DHCPv4 server/relay. Without DHCPv4 server, there should be no

If you *don't want IPv4*, you filter at layer 2. Otherwise you're mostly
advising your network on the intent.  But nodes are free to communicate
over ipv4 if they wish.

auto-linklocal is, in a sense, -- and by definition --  a kind of
anarchy. Such "anarchy" has proven valuable, both when the network
fails, or there are issues with the infrastructure (or there is no
infrastructure).

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 May 2019 19:08:31 +0200

>For the average user, this means that if they actually needed, now they

Not really. It just means that you need to have a DHCPv4 server if you want
to use IPv4. Whether a CPE ships with DHCPv4 enabled by default can change
over time.

Or to put it in other words, IPv4 SD would only work if supported by DHCPv4.

>for even the most trivial stuff, continuous wake up do to online

It is more than just a bit of SD. I think some (most? all?) stacks assume
that all of IPv4 is onlink when they have an IPv4 link local. So any A
record returned in DNS may trigger ARP traffic for that address. That
requires all applications to deal with broken IPv4.

>only. An "IPv6-only network" will just break all that.

What about running a DHCPv4 server to support those devices? 

>advising your network on the intent.  But nodes are free to communicate

That is true. But most of networking is based on cooperation not on 
enforcement. Describing intent is important.

>fails, or there are issues with the infrastructure (or there is no

In the case of working IPv6 the network is in some sense managed. From a
host (and user) perspective is more clear if the network is actually treated
as managed, and not as half managed (IPv6), half chaos (IPv4).

---

From: David Farmer <[email-masked]>
Date: Thu, 23 May 2019 17:13:50 -0500

> disabled by default for IPv6 only networks.

In my opinion, what he is saying is not about IPv6-Only, because without a
flag a host can't know it is on an IPv6-only network.

What he is saying is a dual-stack host that has functioning IPv6 should not
enable IPv4 LL. And functioning IPv6 means at a minimum it has learned an
IPv6 GUA and probably a default router as well, you could also test for
connectivity beyond the default router, but that

The risk this creates is that on a dual-stack network if a there is an
issue with the DHCPv4 server, such as it crashed or was misconfigured then
the dual-stack host cannot fall back to IPv4 LL and will not be able to
perform Link-Local communications with IPv4-Only devices on the common link
between them.

Personally, I think this is an acceptable risk, but I'm not convinced that
there is a consensus that this is an acceptable risk. Therefore, I'm not ok
with abandoning the IPv6-Only flag until there is a consensus that this is
an acceptable risk. Furthermore, we need more than 6man's consensus on this
risk.

> For the average user, this means that if they actually needed, now they

Yep, there is a non-zero risk of problems.

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 May 2019 15:42:48 +1000

Hi Sander,

Sorry not to get back to you sooner.

On Wed, 1 May 2019 at 00:33, Sander Steffann <[email-masked]> wrote:
>
> Hi Mark,
>
> >> Here is the opinion of operators at the RIPE meeting last fall:
> >> https://ripe77.ripe.net/archives/video/2335/
> >> Reactions at 5:38
> >
> > How many have read the draft?
> >
> > Should they be making judgement and we accept judgement based on a short and single presentation by somebody who has a bias against it?
>
> I gave that presentation after discussing it with Ole to provide some sort of feedback on this draft from the operator community. I presented both the benefits and the dangers. Yes, I am personally against this draft, but I gave an honest representation of both sides.
>

I think the one thing missing from the presentation was a statement of
what sorts of numbers of hosts likely attached to a link where
link-layer broadcast volume may become a consideration or concern.
That would have better set the context for the problem trying to be
solved.

> I haven't seen any active outreach from the IETF, and the operators who do speak up here are often ignored as "single voices" that don't represent the operators, and when someone goes out and tries to get broader feedback its biased. All of this makes it very difficult for operators to deal with the IETF, and I know many who have given up.
>

So I was indirectly hoping to encourage more operators to participate
with this presentation at the 2015 AusNOG conference.

"Why you should read RFCs and Internet Drafts (and what you need to
know to do so)"
http://www.ausnog.net/sites/default/files/ausnog-2015/presentations/1.4_Mark_Smith_AusNOG2015.pdf

I wonder what an operator who tries to participate in the IETF expects?

Regards,
Mark.

> If you have a better way of getting a feel for operator support I am all ears.
>
> Cheers,
> Sander
>

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 24 May 2019 09:58:41 +0100

David Farmer wrote on 23/05/2019 23:13:
> What he is saying is a dual-stack host that has functioning IPv6
> should not enable IPv4 LL. And functioning IPv6 means at a minimum it
> has learned an IPv6 GUA and probably a default router as well, you
> could also test for connectivity beyond the default router, but that
> 
> The risk this creates is that on a dual-stack network if a there is
> an issue with the DHCPv4 server, such as it crashed or was
> misconfigured then the dual-stack host cannot fall back to IPv4 LL
> and will not be able to perform Link-Local communications with
> IPv4-Only devices on the common link between them.
>
> Personally, I think this is an acceptable risk, but I'm not convinced
> that there is a consensus that this is an acceptable risk. Therefore,
> I'm not ok with abandoning the IPv6-Only flag until there is a
> consensus that this is an acceptable risk.. Furthermore, we need more
> than 6man's consensus on this risk.

the usual ietf position is that operational misconfig - including
daemons crashing - is out of scope for protocol development.  If it's 
out of scope, there's no real issue regarding consensus.

Obviously, from an operational point of view, if DHCP service is 
important on a network, the operator is at liberty to install redundant 
servers / relays.

Nick

---

From: David Farmer <[email-masked]>
Date: Fri, 24 May 2019 08:35:34 -0500

> important on a network, the operator is at liberty to install redundant

WHAT ARE ARE YOU SAYING?  The IETF SHOULD NOT concern itself with
accidental misconfiguration? And SHOULD only create fragile and brittle
protocols? The IETF SHOULD NOT seek robustness in its protocols?

If that is the case I think you just said half the work in V6OPS and GROW
is out of the scope of the IETF. And you just said your objection to the
IPv6-Only flag is out of scope. I believe just the opposite, and I believe
your objections to the original formulation of the IPv6-Only flag were well
placed.

Thanks

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 May 2019 16:00:34 +0200

>your objections to the original formulation of the IPv6-Only flag were well

The IPv6-only flag is an additional feature. Before accepting such a 
feature it is worth asking what happens if the feature gets enabled
accidentally or maliciously.

In my opinion that is different from creating workarounds for poorly
maintained services. The normal expectation of a DHCPv4 server failing
is that there will not be any IPv4. Creating workarounds for that creates
operational complexity. 

At the recently concluded RIPE meeting, Geoff Huston suggested that the
reason some networks have very high IPv6 failure rates is because the
failures are masked by happy eyeballs. Networks that rely on IPv6
(i.e. those with NAT64) have very low failure rates.
(https://ripe78.ripe.net/programme/meeting-plan/ipv6-wg/)

---

From: Bob Hinden <[email-masked]>
Date: Fri, 24 May 2019 10:40:04 -0400

Philip,

> On May 24, 2019, at 10:00 AM, Philip Homburg <[email-masked]> wrote:
> 

I wonder if the ipv6only flag could be used to test IPv6 on networks.  That is, turn off IPv4 and see if the IPv6 is working.  Turn off IPv4, then make sure there is working IPv6 connectivity, throughput, etc., then turn IPv4 back on.  

Perhaps a new use case.

Bob

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 May 2019 16:47:58 +0200

>I wonder if the ipv6only flag could be used to test IPv6 on networks.  
>That is, turn off IPv4 and see if the IPv6 is working.  Turn off IPv4, 
>then make sure there is working IPv6 connectivity, throughput, etc., 
>then turn IPv4 back on. 
>
>Perhaps a new use case.

To make that work you have to turn off DHCPv4 as well. So you don't need
the flag.

The bigger problem is that without IPv4, most of the internet is unreachable.
So it is bit hard to test if it is IPv6 that is failing or not.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 May 2019 12:15:08 -0400

> The risk this creates is that on a dual-stack network if a there is an issue
    > with the DHCPv4 server, such as it crashed or was misconfigured then the
    > dual-stack host cannot fall back to IPv4 LL and will not be able to perform
    > Link-Local communications with IPv4-Only devices on the common link between
    > them.

If one assumes a host with some history of connectivity,
(So Linux running NetworkManager, OSX, Windows, iOS and Android), then the
the failure of the DHCPv4 server, can simply be tolerated.

The turn off IPv4 LL heuristic can apply only to the first (few?)
connections.

    > there is a consensus that this is an acceptable risk. Therefore, I'm

I agree.

Where/how does this heuristic get document?
There was an RFC mentioned back in the thread... do you think it's enough for
ipv6only document to reference it?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 May 2019 08:04:34 +1200

On 25-May-19 02:00, Philip Homburg wrote:
...
> accidentally or maliciously.

Yes. That's why these questions have been addressed in the draft
since many versions ago.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Mon, 27 May 2019 09:45:25 +0200

>ipv6only document to reference it?

RFC 4213 (Basic Transition Mechanisms for IPv6 Hosts and Routers) is
Standards Track and defines dual stack.

It should be easy enough to have an RFC that updates it.

Though a question is whether that should be done here or in v6ops. It is
not really new IPv6 protocol, just a small change to how existing protocols
are deployed.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 27 May 2019 14:59:34 +0100

David Farmer wrote on 24/05/2019 14:35:
> WHAT ARE ARE YOU SAYING?

nothing more than the sober reality of GIGO - garbage in, garbage out. 
DHCP, as a protocol, expects correct configuration.

Is it a problem with the protocol if someone mis-types a MAC address in 
the config?  Or specifies the wrong next-hop gateway?  Or makes a 
mistake in an autoconfig URL?  All these things could be fatal for the 
device under configuration.  Fixing this is not a protocol-layer problem.

> The IETF SHOULD NOT concern itself with 

These issues are, to some degree at least, orthogonal to each other: you 
can build solid protocols which are inherently susceptible to problems 
with misconfigs. On the other hand, implementations can be built to work 
around this by implementing sanity checking.

Regarding misconfigs and crashing in general, DHCP has been around for a 
long time. This means that people understand how it works - i.e. 
misconfigs can usually be solved quickly - and the implementations are 
generally pretty robust - i.e. crashes are rare and if you need 
resilience, you can use multiple separate servers / relays (a 
protocol-layer feature).

Nick

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 May 2019 00:58:27 +1000

> resilience, you can use multiple separate servers / relays (a

Hosts should trust the configuration information the network provides.

It's binary.

What I don't understand it some people seem to be quite fine with
rogue RAs, meaning they're happy to have hosts universally trust
received RAs, rogue or not, until this flag was proposed.

If a host can't trust the configuration information that the network
provides, then that obligates the network operator to make the
information that the network provides to always be trustworthy, by
implementing RA Guard, or isolating unstrusted hosts to their own
individual point-to-point links with their only other peer being an RA
issuing router.

If this flag is received and it is to be considered potentially bogus,
then anything already received in any RAs is already potentially
bogus. The whole RA should be considered bogus, as should all other
RAs received from any other RA issuers on the link.

Hosts can be assured of what they received by implementing and
requiring SEND. If a network doesn't implement SEND, then the network
is implying that what ever is received is not bogus, regardless of its
source.

In other words, without any form of authentication i.e. SEND, it is a
simple as trusting everything received or trusting nothing received.
If RAs are being accepted by hosts, rather than being universally
ignored, then they should be trusting everything in the RA received,
including this flag.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 27 May 2019 17:17:24 +0100

> received RAs, rogue or not, until this flag was proposed.

there have always been issues about the wisdom of trusting 
unauthenticated, unsolicited datagrams with no signatures, but this is 
probably something better discussed over beer and peanuts, while 
recounting the times we nuked all the boxes on the LAN by connecting up 
a new sun workstation running routed :-)

Nick

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 27 May 2019 16:21:02 +0000

> To make that work you have to turn off DHCPv4 as well. So you don't 

That wasn’t the case with the earlier initial versions of the draft; 
the ability for that “use-case” only went away with people asking 
for it as they are worried about legacy accidentally turned off by a 
rouge RA packet.

There’s still good ways to use the two options together for testing if 
I think about tuning lifetimes of each of these protocols, etc.

It was all simpler when the draft was simple and I wonder if with the 
(global) flag to turn off enabling of processing the flag, the “IPv4 
address configured on the interface” requirement could be removed 
again from the draft;  that would also avoid cross-protocol-family 
pollutions in the implementations.

In addition to that, I challenge you to see what a network without 
DHCPv4 looks like when you check the “legacy IP noise levels” (even 
if there is no static IPv4 configurations and even more so if you’d 
only send DHCPv4:116).

> So it is bit hard to test if it is IPv6 that is failing or not.

You can still test (a) that your local services on the LAN work with 
IPv6-only, that you can reach (b) important (external) IPv6 enabled 
services, (c) if anything breaks if you go through a proxy or 
translation service, .. (just to name the first three which came to my 
mind).

/bz

---

From: David Farmer <[email-masked]>
Date: Mon, 27 May 2019 14:23:31 -0500

> resilience, you can use multiple separate servers / relays (a

But it's not DHCPv4 we're actually talking about but the robustness IPv4 to
a failure of DHCPv4. So let's be clear, Philip is proposing reducing the
robustness of IPv4 in the presence of IPv6, at least the robustness of
on-link communications with IPv4. Whereas using the flag only reduces the
robustness of IPv4 in the presence of the IPv6-Only Flag. While I'm fine
with either option, many people objected to tying IPv4 and IPv6 together,
but which of these two options does more violence to IPv4?

Thanks

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 27 May 2019 22:08:29 +0100

David Farmer wrote on 27/05/2019 20:23:
> But it's not DHCPv4 we're actually talking about but the robustness IPv4 
> to a failure of DHCPv4.  So let's be clear, Philip is proposing reducing 
> the robustness of IPv4 in the presence of IPv6, at least the robustness 
> of on-link communications with IPv4. Whereas using the flag only reduces 
> the robustness of IPv4 in the presence of the IPv6-Only Flag. While I'm 
> fine with either option, many people objected to tying IPv4 and IPv6 
> together, but which of these two options does more violence to IPv4?

personally, I don't think either of these options is compelling - and 
separately, would tend to agree with the idea that causing different 
protocols to share fate is something that should be avoided, unless 
there are overwhelmingly good reasons to do so.  So the question of 
which "does more violence to ipv4" seems more like a question along the 
lines of "each option has its problems, but which is the least bad?", to 
which I'm inclined to answer: "well, neither is necessary, nor 
advisable, so maybe neither option would be best".

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 May 2019 09:50:23 +1200

> pollutions in the implementations.

Agreed. I think this discussion has been drifting into layers of
operational and implementation implications of how dual stacks will
in general deal with a world in which IPv4 is becoming redundant.
We're going to have to face those issues with or without an IPv6-only
flag.

     Brian

---

From: David Farmer <[email-masked]>
Date: Mon, 27 May 2019 17:13:18 -0500

> advisable, so maybe neither option would be best".

I'm sorry if you don't seem to think there is a problem worth solving, so
of us think this is a real problem especially if you want to simplify your
operations to single stack that isn't IPv4.  I don't want to be stuck in an
IPv4 world forever, and the current dual-stack model effectively requires
this. The problem is ever since we created the dual-stack model, the fate
IPv4 and IPv6 have been intertwined. Be it happy eyeballs or simply
preferring one version over the other, the stack has to choose which one to
use and if it chooses badly the user experience sucks, the fates of the two
protocols are intertwined by the dual-stack model.  I think what we are
attempting to do is separate their fates. In particular sperate IPv6 from
IPv4.

Tuning of IPv4, at least over the wire, really only makes sense if you are
doing NAT64 or something like it where IPv4 is a service over IPv6 the IPv4
on the wire is redundant. Since many seem to be interested only in a
heuristic approach, maybe tie the heuristic to for tuning off IPv4 LL and
the presence of a pref64 in the RA from draft-ietf-6man-ra-pref64. That way
the IPv6-Only state is only triggered if there are no IPv4 DHCPOFFERS and
there is a Perf64 defined, then IPv4 LL SHOULD NOT be configured.

Thanks

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 May 2019 00:20:45 +0200

Hi Nick,

> Op 27 mei 2019, om 23:08 heeft Nick Hilliard <[email-masked]> het volgende geschreven:
> 
>> But it's not DHCPv4 we're actually talking about but the robustness IPv4 to a failure of DHCPv4.  So let's be clear, Philip is proposing reducing the robustness of IPv4 in the presence of IPv6, at least the robustness of on-link communications with IPv4. Whereas using the flag only reduces the robustness of IPv4 in the presence of the IPv6-Only Flag. While I'm fine with either option, many people objected to tying IPv4 and IPv6 together, but which of these two options does more violence to IPv4?
> 
> personally, I don't think either of these options is compelling - and separately, would tend to agree with the idea that causing different protocols to share fate is something that should be avoided, unless there are overwhelmingly good reasons to do so.  So the question of which "does more violence to ipv4" seems more like a question along the lines of "each option has its problems, but which is the least bad?", to which I'm inclined to answer: "well, neither is necessary, nor advisable, so maybe neither option would be best".

I agree.

I think for migrating to IPv6 the RFC2563 option is perfectly acceptable: as long as you have IPv4 clients on your network, tell them in their own "language" that there is no IPv4 service on this link. When those clients disappear over time stop providing DHCPv4 completely and happily enjoy a clean IPv6 network. There won't even be a legacy ipv6only flag ;)

Cheers,
Sander

PS: yes, I know there are some with a purist "I don't want ANY non-IPv6 packet on my network" view, but seriously, let's focus on real-life problems…

---

From: David Farmer <[email-masked]>
Date: Mon, 27 May 2019 17:53:56 -0500

On Mon, May 27, 2019 at 5:20 PM Sander Steffann <[email-masked]> wrote:

> >> But it's not DHCPv4 we're actually talking about but the robustness
> IPv4 to a failure of DHCPv4.  So let's be clear, Philip is proposing
> reducing the robustness of IPv4 in the presence of IPv6, at least the
> robustness of on-link communications with IPv4. Whereas using the flag only
> reduces the robustness of IPv4 in the presence of the IPv6-Only Flag. While
> I'm fine with either option, many people objected to tying IPv4 and IPv6
> protocols to share fate is something that should be avoided, unless there
> are overwhelmingly good reasons to do so.  So the question of which "does
> more violence to ipv4" seems more like a question along the lines of "each
> option has its problems, but which is the least bad?", to which I'm
> inclined to answer: "well, neither is necessary, nor advisable, so maybe
> neither option would be best".
>
> I agree.
>
> I think for migrating to IPv6 the RFC2563 option is perfectly acceptable:
> as long as you have IPv4 clients on your network, tell them in their own
> "language" that there is no IPv4 service on this link. When those clients
> disappear over time stop providing DHCPv4 completely and happily enjoy a
> clean IPv6 network. There won't even be a legacy ipv6only flag ;)
>
> Cheers,
> Sander
>
> PS: yes, I know there are some with a purist "I don't want ANY non-IPv6
> packet on my network" view, but seriously, let's focus on real-life
> problems…
>

Then stop telling people to filter Ethertype 0x0800 because you can't use
RFC2563 in the presence of such filters. Further, there really aren't IPv4
clients and separate IPv6 clients anymore, just about everything that
matters is dual-stack. So you are really saying, tell dual-stack clients to
not use IPv4 using IPv4. So who is the purist? You're saying you can't
block IPv4 because you have to use IPv4 to tell dual-stack clients they
shouldn't use IPv4, now that's a catch 22.

Again this is a real problem is some at least a few situations, and they
are fairly common situations, just not in the home broadband world at least
today.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 May 2019 01:04:33 +0200

Hi David,

This is starting to feel like a personal attack...

> Then stop telling people to filter Ethertype 0x0800 because you can't use RFC2563 in the presence of such filters.

Those are different options, depending on your situation.

> Further, there really aren't IPv4 clients and separate IPv6 clients anymore, just about everything that matters is dual-stack.

Of course.

> So you are really saying, tell dual-stack clients to not use IPv4 using IPv4. So who is the purist? You're saying you can't block IPv4 because you have to use IPv4 to tell dual-stack clients they shouldn't use IPv4, now that's a catch 22.

Block the ethertype if you don't want any traffic, use the DHCP option if you want to explicitly inform clients, I don't care. There are plenty of options.

> Again this is a real problem is some at least a few situations, and they are fairly common situations, just not in the home broadband world at least today.

And there are solutions already available. Just pick one instead of inventing a new one...

Cheers,
Sander

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 May 2019 09:25:44 +1000

> On 28 May 2019, at 9:04 am, Sander Steffann <[email-masked]> wrote:
> 
> Hi David,
> 
> And there are solutions already available. Just pick one instead of inventing a new one…

Actually their isn’t a alternative solution.  There are several things trying to be achieved.

1) remove ALL IPv4 traffic from the network.
2) stopping hosts attempting to send IPv4 traffic onto the network.
3) being able to turn off IPv4 on the router interface.
4) needs to work on a BYOD network.
5) eventually being able to turn off ALL IPv4 packet processing in the router.

If you have a solution that achieves all these goals without signalling via IPv6 I’d like to see it.  Filtering can’t achieve 2.  RFC2563 can’t achieve 1 and 5.

Mark

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 May 2019 01:43:52 +0200

Hi,

> Actually their isn’t a alternative solution.  There are several things trying to be achieved.

This reads as a list of goals invented to justify the solution...

> 1) remove ALL IPv4 traffic from the network.

Why?

> 2) stopping hosts attempting to send IPv4 traffic onto the network.

Considering the noise they cause I agree that this is a worthwhile goal.

> 3) being able to turn off IPv4 on the router interface.

Why?

Agree.

> 5) eventually being able to turn off ALL IPv4 packet processing in the router.

Definitely.

> If you have a solution that achieves all these goals without signalling via IPv6 I’d like to see it.  Filtering can’t achieve 2.  RFC2563 can’t achieve 1 and 5.

A "hard" ipv6only flag would achieve that but doesn't have consensus. A "soft" flag used as a heuristic could get consensus but doesn't achieve all those goals either.

While many devices still have IPv4 turned on by default RFC2563 can keep the noise down (2). When IPv4 becomes less and less common (3) and (5) are fine. Optionally with filtering on ethertype as well if you really want (1).

There have been many protocols on Ethernet that have disappeared all by themselves, possibly enforced by filtering. I'm still not convinced we need anything more than what we already have.

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 May 2019 11:54:53 +1200

Sander,
> This is starting to feel like a personal attack...

I hope not. Really. You happen to be presenting a certain
point of view, that's all.

> Those are different options, depending on your situation.

Well, yes. But if an operator chooses to filter 0x0800 and wishes to actively
inform hosts that IPv4 is unavailable, only an IPv6 mechanism can do so.
So here we are.

   Brian

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 May 2019 02:06:08 +0200

Hi Brian,

> inform hosts that IPv4 is unavailable, only an IPv6 mechanism can do so.

Why would an operator choose that? What operational problem is being solved?

Cheers,
Sander

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 28 May 2019 00:17:42 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Mark Andrews

> 1) remove ALL IPv4 traffic from the network.

I agree with Sander that we shouldn’t need to invent a new mechanism, only to be eventually left with this legacy wasted flag, taking up what could be precious spare space.

You, the netadmin, cannot even hope to remove all IPv4 from the network. The best you can do is to remove all IPv4 services from the network nodes you, the netadmin, control. Flag or no flag. Unless you post cops at every building entrance, and confiscate IPv4 equipment.

> 2) stopping hosts attempting to send IPv4 traffic onto the network.

Layer 2 filtering, at network nodes managed by netadmin. Hosts that use private switches and peripherals can’t be stopped anyway.

> 3) being able to turn off IPv4 on the router interface.

Netadmin can trivially do that, and no IPv4 client remaining would even be able to find the MAC address of such routers.

> 4) needs to work on a BYOD network.

No flag can achieve that. I bring my own switch and peripheral device, use these only in my office, IPv4 address statically configured.

> 5) eventually being able to turn off ALL IPv4 packet processing in the router.

Easy to do, anytime.

> If you have a solution that achieves all these goals without signalling via IPv6 I’d like to see it.  Filtering can’t achieve 2.  RFC2563 can’t achieve 1 and 5.

Layer 2 filtering (800 and 806), consequently, no ARP to or from network nodes, provide no A records from DNS, you, the netadmin, have done all that needs doing.

Honestly, the rest is the hosts' problem. For example, those hosts that fuss over battery life. Not a netadmin problem. Let the vendors figure it out.

Bert

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 May 2019 10:31:46 +1000

Hi Sander,

<snip>

> And there are solutions already available. Just pick one instead of inventing a new one...

That's really arguing against ever making things better. Plenty of
things exist that replaced existing, harder or more time costly and
usually manual mechanisms; DHCPv4, DNS, automatic transmissions and
power windows in cars, dishwashers and clothes washing machines etc.

Blocking 0x800/0x806 on individual link-layer ports would prevent IPv4
traffic including link-layer broadcasts on the link, but it doesn't
stop hosts initialising their IPv4 stack and trying to acquire an IPv4
address via DHCP. It requires link-layer per-host port configuration,
which would involve configuring 100s if not 1000s of individual ports.

RFC2563 should stop an IPv4 host sending IPv4 packets after the
initial DHCP transaction. However, it doesn't prevent link-layer
broadcast DHCPDISCOVERS, which is flooded to all other hosts on the
link and has to be processed by their main OS CPU to be discarded,
because the NIC can't filter them using the DA. This is where the main
battery cost will be when mobile nodes join the link, likely
continuously on big Wifi networks at e.g. conferences.

A link with a DHCPv4 server on it supporting RFC2563 is not an IPv6
Only link, because IPv4 is still present on the link. There should be
no IPv4 services/infrastructure and no IPv4 packets on an IPv6 Only
link, including IPv4 zero-conf link-local traffic. An IPv4 only
zero-conf printer should not work on an IPv6 Only link, intentionally.

The combination of those two mechanisms would go close to achieving
what this flag would, except that the first mechanism prevents the
second from working.

So individually or in combination, neither of these are a solution to
the problem of achieving an IPv6 only link.

Since the flooded link-layer broadcasts is probably more of a problem
than hosts trying to acquire addresses via DHCPv4, say the choice is
to block 0x800, 0x806 on all host ports.

Is that easier than setting a flag on one or usually no more than two
IPv6 routers to set this flag? I think it is far harder and far more
prone to error.

An IPv6 Only RA flag is better mechanism because it is both easier and
quicker to use than the existing alternatives, and also achieves
something that the existing potential alternatives can't.

Regards,
Mark.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 May 2019 02:47:09 +0200

Hi Mark,

> which would involve configuring 100s if not 1000s of individual ports.

Most switch operating systems and/or automation solutions provide easy ways to do that, but let's look a bit further.

> continuously on big Wifi networks at e.g. conferences.

Do you have numbers on this? I'd like to see whether this is a significant drain on batteries.

> zero-conf printer should not work on an IPv6 Only link, intentionally.

This is what I consider an overly restrictive view ("purist") of an IPv6-only link. Telling your clients that ask for IPv4 using DHCP that there isn't any isn't an operational problem.

> The combination of those two mechanisms would go close to achieving what this flag would, except that the first mechanism prevents the
> second from working.
> 

Ok. SAVI then instead of full ethertype filtering. Widely implemented and it allows DHCP, DHCP filtering and if the clients don't get addresses assigned it will drop their traffic.

Cheers,
Sander

PS: it's almost 3am here. Don't expect more replies until tomorrow :)

---

From: Raymond Burkholder <[email-masked]>
Date: Mon, 27 May 2019 19:07:07 -0600

> inform hosts that IPv4 is unavailable, only an IPv6 mechanism can do so.
'only an IPv6 mechanism can do so'  -- is that necessarily true?

This time I did read through 
https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-05.  I see 
there is an inclusion of the IPv4 Sunset draft for turning off ipv4 (and 
someone else did point out that the Sunset WG has been itself 
'sunsetted' I believe).

I also took a look at table called 'EtherType values for some notable 
protocols' at https://en.wikipedia.org/wiki/EtherType

A network link may have many other protocols other than ipv4 or ipv6: 
PTP, MacSec, LLDP, PBB, CFM, RoCE, ATAoE, MPLS, PPPoE, .... not to 
mention STP and the like which is very noisy.  I didn't see a summary in 
the document of how that might be handled.

So I guess this is IPv6-only in the sense of IPv6 with no IPv4.

I can't remember if there was mention of IPv4 only hosts knowing how to 
evaluate an IPv6 flag in an IPv6 protocol, or how vendors 
would/could/want to implement such a thing.

Maybe rather than saying IPv6 only, maybe create another EtherType which 
network stacks would know how to interpret, and it could be used to turn 
off other protocols.  Maybe some networks might want to run IPv4 and 
turn off IPv6 (saying half jokingly).

This independent protocol could be used to turn off other protocols that 
the network stack might see as well.  The flags then become universally 
applicable to any stack that has been designed to interpret xxx-only 
flags.  It would then have long lasting applicability, as protocols come 
and go.

Raymond.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 27 May 2019 21:24:39 -0400

Raymond,

> On May 27, 2019, at 9:07 PM, Raymond Burkholder <[email-masked]> wrote:
> 
> This time I did read through https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-05.  I see there is an inclusion of the IPv4 Sunset draft for turning off ipv4 (and someone else did point out that the Sunset WG has been itself 'sunsetted' I believe).
> 
> I also took a look at table called 'EtherType values for some notable protocols' at https://en.wikipedia.org/wiki/EtherType
> 
> A network link may have many other protocols other than ipv4 or ipv6: PTP, MacSec, LLDP, PBB, CFM, RoCE, ATAoE, MPLS, PPPoE, .... not to mention STP and the like which is very noisy.  I didn't see a summary in the document of how that might be handled.
> 

Yes, it says that in Section 4. "IPv6-Only Definition”.  Reading the actual document is helpful in these discussions, not just the email thread :-)

Bob

> 
> I can't remember if there was mention of IPv4 only hosts knowing how to evaluate an IPv6 flag in an IPv6 protocol, or how vendors would/could/want to implement such a thing.
> 
> Maybe rather than saying IPv6 only, maybe create another EtherType which network stacks would know how to interpret, and it could be used to turn off other protocols.  Maybe some networks might want to run IPv4 and turn off IPv6 (saying half jokingly).
> 
> This independent protocol could be used to turn off other protocols that the network stack might see as well.  The flags then become universally applicable to any stack that has been designed to interpret xxx-only flags.  It would then have long lasting applicability, as protocols come and go.
> 
> Raymond.
> 
>

---

From: Raymond Burkholder <[email-masked]>
Date: Mon, 27 May 2019 19:32:32 -0600

> Yes, it says that in Section 4. "IPv6-Only Definition”.  Reading the actual document is helpful in these discussions, not just the email thread :-)
In light of the fact that there are other protocols on the link besides 
IPv6 and IPv4, should the enablement of this flag be approved, would it 
be better to name it for what it actually is: IPv4-disable?

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 May 2019 12:26:26 +1000

Hi Sander,

> Do you have numbers on this? I'd like to see whether this is a significant drain on batteries.

I think the impact of link-layer broadcasts on battery life is going
to be pretty similar to that of multicast RAs that are also link-layer
flooded to all-nodes, as they both have to be passed up to the general
purpose OS and CPU for processing.

The impact of multicast RAs on battery life has been enough that we've
published a BCP on using unicast RAs when possible to reduce devices'
energy consumption.

"Reducing Energy Consumption of Router Advertisements"
https://tools.ietf.org/html/bcp202

There are numbers in section 4 discussing the battery consumption
costs of flooded multicast RAs.

It is self-evident that doing nothing is more efficient and effective
than spending resources on doing something that is of no use and has
no value. The latter is the definition of the word "waste".

Link-layer broadcasts caused by IPv4 on an IPv6 Only link are wasting
mobile devices' battery capacity.

It's been advice to reduce or avoid link-layer broadcasts, well before
battery powered mobile devices were common.

"But broadcasts must be used with discretion, since all hosts that
receive one incur a certain amount of software overhead, if only to
discard it."

"Practical Considerations in Ethernet Local Network Design", by Ronald
C. Crane and Edward A. Taft
October 1979, revised February 1980

https://ethernethistory.typepad.com/papers/PracticalConsiderations.pdf

> This is what I consider an overly restrictive view ("purist") of an IPv6-only link. Telling your clients that ask for IPv4 using DHCP that there isn't any isn't an operational problem.

It's not being purist, it is being literal. It is complying with the
literal definition of the word "only".

You can't call your link an "IPv6 Only" link if there is any IPv4 is
present on it.

A link with DHCPv4 and RFC2563 is an "IPv6 Mostly" link, not an "IPv6
Only" link.

> Ok. SAVI then instead of full ethertype filtering. Widely implemented and it allows DHCP, DHCP filtering and if the clients don't get addresses assigned it will drop their traffic.

Doesn't solve the problem of hosts needlessly, wastefully and
persistently trying to acquire IPv4 addresses that they'll never get.

It's making hosts into hamsters in wheels, activity with no progress.

Regards,
Mark.

---

From: Brian Carpenter <[email-masked]>
Date: Tue, 28 May 2019 16:33:51 +1000

Is that really a question we need to answer today? istm that this flag, if
approved today & implemented tomorrow, is a tool for operators many years
in the future, beyond what we can analyse today.

Regards
    Brian
    (via tiny screen & keyboard)

---

From: Brian Carpenter <[email-masked]>
Date: Tue, 28 May 2019 16:41:21 +1000

Raymond, we are targetting dual stack hosts with an o/s that has extra code
to avoid wasting resource on IPv4. Please re-read the draft.

Regards
    Brian

On Tue, 28 May 2019, 11:07 Raymond Burkholder, <[email-masked]> wrote:

> > Then stop telling people to filter Ethertype 0x0800 because you can't
> use RFC2563 in the presence of such filters.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 May 2019 19:06:21 +1200

Bert,

On 28-May-19 12:17, Manfredi (US), Albert E wrote:

<snip>

> Honestly, the rest is the hosts' problem. For example, those hosts that fuss over battery life. Not a netadmin problem. Let the vendors figure it out.

That seems like a very high-handed approach. The proposal is a specific mechanism to help the host operating system figure it out by announcing the *intent* of the operators. Don't you think there is an obligation on service providers to tell their users what services are intentionally no longer available?

If you commuted to work on the #400 or the #600 bus, wouldn't you think the bus operator was obliged to tell you that the #400 was not running any more? Probably by posting a notice on board the #600?

Now, we can decide to issue this notice in an IPv6 protocol that is pretty much obligatory and universal (i.e. RAs) or we can decide to issue it in a non-universal way such as DHCPv6, PVDs, NETCONF, etc. But my prediction is that we will end up issuing it one way or another, even if not all operators see the need today.

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 28 May 2019 04:36:22 -0400

Raymond,

> On May 27, 2019, at 9:32 PM, Raymond Burkholder <[email-masked]> wrote:
> 
> In light of the fact that there are other protocols on the link besides IPv6 and IPv4, should the enablement of this flag be approved, would it be better to name it for what it actually is: IPv4-disable?

An earlier version that was the case, but after a lot of discussion on the list it was renamed to IPv6-Only for what it is doing.  That is, make the link only run IPv6.

Bob

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 May 2019 10:44:33 +0200

Hi Mark,

> purpose OS and CPU for processing.

This is incorrect. RAs are constantly repeated. A single DHCP discover followed by a RFC2563 response is much less common and will therefore have much less impact.

> A link with DHCPv4 and RFC2563 is an "IPv6 Mostly" link, not an "IPv6 Only" link.

Literally true, but practically and operationally an insignificant distinction.

> It's making hosts into hamsters in wheels, activity with no progress.

Hosts that persistently keep asking for IPv4 leases despite being told "no" can be fixed much easier than by adding a new flag to IPv6... And hosts that keep misbehaving can't be expected to implement the flag either.

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 May 2019 13:28:38 +0100

Sander Steffann wrote on 28/05/2019 09:44:
> Hosts that persistently keep asking for IPv4 leases despite being
> told "no" can be fixed much easier than by adding a new flag to
> IPv6... And hosts that keep misbehaving can't be expected to
> implement the flag either.

stepping back up the problem stack a bit, no adequate problem 
characterisation has been performed. So far, a single ipv6-only 
deployment case has been identified which merits some examination in the 
context of the draft's problem statement, namely large partially-managed 
wifi networks with BYOD.  Fully managed networks can use host management 
or ACLs to block ipv4 chatter.  Fully unmanaged large wifi networks are 
outside scope.

Last week with the help of some RIPE NCC staff, we did some rough 
characterisation of background chatter on the nat64 network at the RIPE 
meeting in Reykjavik.  The results showed that by packet count, in 
excess of 60% of the background ipv4 traffic was mdns and another 20-25% 
was netbios.  The remainder was a mixture of things (ARP, SSDP, random 
link-local, etc). Less than 1% of packets were DHCP requests.

These are very rough figures btw, i.e. barely anecdote-grade, but they 
suggest that support for the RFC2563 DHCP flag to disable IPv4 LL 
addresses should be sufficient to squish the overwhelming bulk of ipv4 
background noise.  If the numbers are even remotely representative of 
longer term data, then the remaining chatter would be operationally 
irrelevant.

We're planning to set up a more comprehensive set of counters at the 
next ripe meeting to get some better quality numbers.

Nick

---

From: David Farmer <[email-masked]>
Date: Tue, 28 May 2019 07:53:34 -0500

On Mon, May 27, 2019 at 7:47 PM Sander Steffann <[email-masked]> wrote:

> Most switch operating systems and/or automation solutions provide easy
> ways to do that, but let's look a bit further.
>

Personally, I'm not particularly worried about DHCPDISCOVERS at least in
most cases, there are a few badly behaved clients, but in general
exponential backoff in the client should deal with this nicely. Personally,
my issue is IPv4 LL, in particular, service advertisement/discovery traffic
using IPv4 LL. This service advertisement/discovery traffic can be sizable
and is already problematic for many WiFi networks so the elimination of
such traffic that is by definition futile is an unqualified win in such
situations.

> This is what I consider an overly restrictive view ("purist") of an
> IPv6-only link. Telling your clients that ask for IPv4 using DHCP that
> there isn't any isn't an operational problem.
>

Let's stop calling each other names, it's not helpful. Yes, the idea of
wanting to block all IPv4 traffic is restrictive, but equally, the idea
that IPv6 should not impact IPv4 in any way is also restrictive. We simply
disagree which is more desirable, different people and networks can have
different priorities.

> The combination of those two mechanisms would go close to achieving what
> this flag would, except that the first mechanism prevents the
> second from working.
>
> Ok. SAVI then instead of full ethertype filtering. Widely implemented and
> it allows DHCP, DHCP filtering and if the clients don't get addresses
> assigned it will drop their traffic.
>

Using RFC2563 with SAVI and ARP filtering (Ether type 0x0806) is an
interesting option, or maybe filtering IPv4 LL traffic.  However, both of
these require much more thought than simply filtering Ethertypes 0x0800 and
0x0806.  Filtering by Ethertype is simple and elegant, further, it is a
basic feature supported by many more network devices than the
more sophisticated Layer 3 aware filtering otherwise required to not also
block the DHCPv4 exchange required for RFC2563 to work.

I want a belt and suspenders approach; I want to signal dual-stack clients
that IPv4 isn't available, or at least that they SHOULD NOT autoconfigure
an IPv4 LL address, RFC2563 does this nicely, the belt. However, for any
dual-stack clients that ignore the signal provided, I also want to filter
the unwanted and futile IPv4 traffic on the network to ensure that it
doesn't bother other dual-stack clients on the network, the suspenders.

So, RFC2563 with fairly sophisticated Layer 3 aware filtering is an option
that achieves the desired results, at least my desired results. However,
the IPv6-Only flag has the added advantage of allowing the use of simple
and more widely available Ethertype filtering.

Also, the testing that I did shows that most newer clients no longer
support RFC2563. I'd be happy to be wrong on this and I'm not 100% sure my
test was valid, but even if I'm wrong this shows that making RFC2563 work
as desired isn't trivial.

Thanks.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 May 2019 15:22:53 +0100

David Farmer wrote on 28/05/2019 13:53:
> Personally, my issue is IPv4 LL, in particular, service 
> advertisement/discovery traffic using IPv4 LL. This service 
> advertisement/discovery traffic can be sizable and is already 
> problematic for many WiFi networks so the elimination of such traffic 
> that is by definition futile is an unqualified win in such situations.

quantifying this, if you are able to use ethertype ACLs, all the host 
will see is its own mdns transmits.  These are typically small scale (< 
1pps measured over longer timescales); they would be coalesced with 
other transmits on wifi devices, and the transmit mechanism for these 
multicast frames would be wifi unicast to the AP, i.e. cheap.  There 
would be no transmits from AP to host.

If RFC2563 were used to block ipv4 LL autoconfig, then LL traffic would 
in theory disappear and all you'd be left with would be the occasional 
DHCP request.

I.e. in both cases, background ipv4 chatter would drop to operationally 
insignificant levels.

In respect of unqualified wins, there ain't no such thing as a free 
lunch.  Each option has its costs and will be a balance between 
complexity, protocol purity, efficiency, security, ease of 
implementation, scope of application and many other things.

Operationally, dropping 95%+ of ipv4 background chatter would be a great 
win.  This is trivial with ethertype ACLs, and my suspicion is that 
widescale implementation of RFC2563 would give comparable results.  The 
remaining chatter is not very important in the scale of things.

> support RFC2563. I'd be happy to be wrong on this and I'm not 100% sure 
> my test was valid, but even if I'm wrong this shows that making RFC2563 
> work as desired isn't trivial.

that may well be the case, but the protocol exists.  It's difficult to 
justify a new protocol when an existing standard which does 95%+ of what 
the new one proposes hasn't been widely implemented.

Nick

---

From: David Farmer <[email-masked]>
Date: Tue, 28 May 2019 09:57:15 -0500

Again you seem to have gone back to either using RFC2563 or filtering
separately and have completely ignored the requirement to do both.

Filtering by itself leaves hosts sending futile traffic and wasting battery
power, and RFC2563 by itself leaves the network susceptible to hosts that
ignore the signal from RFC2563.

The requirement to do both seems perfectly reasonable to me. If you are
going to ignore peoples requirements don't be surprised if they ignore your
solutions.

Thanks

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 May 2019 18:00:49 +0200

>going to ignore peoples requirements don't be surprised if they ignore your

It seems to me that any switch that can implement RA-guard can also limit
IPv4 traffic to just DHCPv4.

In addition, any host that is really concerned about battery lifetime can
just keep IPv4 LL disabled until needed by an application, i.e. a phone could
enable IPv4 LL only when the user wants to print something and other ways to 
discover a printer fail.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 May 2019 18:32:54 +0100

> separately and have completely ignored the requirement to do both.

The draft assumes that neither is an option, so why do some of us 
continue to bring these things up at all (see below)?

> Filtering by itself leaves hosts sending futile traffic and wasting 
> battery power, and RFC2563 by itself leaves the network susceptible to 
> hosts that ignore the signal from RFC2563.

And the ipv6only-flag option proposes to fix this by implementing fate- 
sharing between ipv4 and ipv6, while offering a mechanism that can 
either promise hard ipv4 shut-down by protocol and open serious security 
problems in the process or else implement the flag as one of potentially 
many heuristic inputs to hint to the host device to tune down ipv4 
services, in which case it doesn't have as many security issues, but 
also doesn't fulfil the stated objective of shutting down ipv4 services.

So the question is: what are we actually trying to achieve here?

We can probably all broadly agree that there are some situations where 
we might want to tune down excessive ipv4 chatter on some types of 
network segment, including those which might only support ipv6 as a 
working protocol.  We've sort-of identified that some types of large, 
flat, semi-managed, byod, wifi networks merit investigation in this regard.

We're now over 1000 emails into this discussion and at least to me, the 
working group seems to be hopelessly split on almost everything else 
raised over the last 2.5 years.  Probably others disagree about this 
assessment, but ultimately it doesn't matter because it's not our call - 
it's the chairs' call.

So at this point, it would be helpful if Ole could make a determination 
on whether there is consensus to move the document forward.

Nick

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 28 May 2019 20:10:00 +0000

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 

> Don't you think there is an obligation on service providers to tell their users what services are intentionally no longer available?

Not explicitly, they never do! For example, in our enterprise net years ago, DECnet was supported. There is no explicit indication that DECnet is no longer supported. Or, is IP multicast supported? Who knows? MPLS? Any number of examples like this exist.

Hosts already have many ways of determining whether some protocol or other is supported on the network.

> If you commuted to work on the #400 or the #600 bus, wouldn't you think the bus operator was obliged to tell you that the #400 was not running any more? Probably by posting a notice on board the #6…

Perhaps so, but do I expect that information to appear on the sign in front of the bus, as it is arriving at the bus stop? Or do I expect that information to be provided to me "out of band," e.g. by the bus driver, as I board the bus, or at the transport service's web site?

I'm saying, the bus rider has many ways of determining whether that bus route will continue to operate next week, without needing an explicit indication on the bus itself.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 May 2019 09:46:58 +1200

Thanks Nick, actual data are always good.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 May 2019 09:54:27 +1200

> enable IPv4 LL only when the user wants to print something and other ways to 

Wait, on that argument the host shouldn't waste resources on IPv6 either. The
theory here is that the desired endpoint is IPv6-only in switches, routers
and hosts, in a world where dual stack hosts have to be ready for dual stack
operation for obvious reasons.

    Brian

---

From: Sander Steffann <[email-masked]>
Date: Wed, 29 May 2019 02:08:52 +0200

Hi David,

> Personally, I'm not particularly worried about DHCPDISCOVERS at least in most cases, there are a few badly behaved clients, but in general exponential backoff in the client should deal with this nicely. Personally, my issue is IPv4 LL, in particular, service advertisement/discovery traffic using IPv4 LL. This service advertisement/discovery traffic can be sizable and is already problematic for many WiFi networks so the elimination of such traffic that is by definition futile is an unqualified win in such situations.

Definitely

> Let's stop calling each other names, it's not helpful.

My apologies if you felt this was calling names. I merely use the term to describe an overly restrictive and in my view harmful requirement that has no basis in operational need. I fully agree with the goal of limiting any unnecessary traffic is useful, but requiring that not a single IPv4 packet may be used is not very helpful, realistic or necessary.

I have strong objections to such an unnecessary requirement being used to justify protocol design choices.

I think this draft needs to be put on hold until we have a decent problem statement on what we're trying to achieve. That should include intended deployment scenarios, existing possible solutions etc. There are still too many different discussions going on at once (hard/soft flag, intended goals etc) to have any chance of reaching consensus.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 May 2019 10:57:53 +1000

I hesitate to respond, because when people start resorting to
classifications/name calling, changing the problem definition to suit
their alternative solutions, even the meaning of base words in the
English language, the discussion has probably devolved that time would
be better spent elsewhere.

On Tue, 28 May 2019 at 22:53, David Farmer <[email-masked]> wrote:
> Personally, I'm not particularly worried about DHCPDISCOVERS at least in most cases,
> there are a few badly behaved clients, but in general exponential backoff in the client should deal with this nicely. Personally, my issue is IPv4 LL, in particular, service advertisement/discovery traffic using IPv4 LL. This service advertisement/discovery traffic can be sizable and is already problematic for many WiFi networks so the elimination of such traffic that is by definition futile is an unqualified win in such situations.
>>

The thing about DHCPDISCOVERS is that they're a fundamental indicator
of whether or not a host has IPv4 enabled or not.

They're important here because if a host has stopped issuing
DHCPDISCOVERS, then unless it has a manually configured IPv4 address,
the host also won't be sending any other IPv4 traffic you mention.
That means no sending of ARP DUD (ACD), mDNS, Netbios or any other
IPv4 triggered link-layer broadcasts or multicasts.

An IPv4 host without an IPv4 address has no need to use and is unable
to use those other protocols. It is an IPv6 Only host now, rather than
a Dual Stack host.

> Let's stop calling each other names, it's not helpful. Yes, the idea of wanting to block all IPv4 traffic is restrictive, but equally, the idea that IPv6 should not impact IPv4 in any way is also restrictive. We simply disagree which is more desirable, different people and networks can have different priorities.
>>

> Using RFC2563 with SAVI and ARP filtering (Ether type 0x0806) is an interesting option, or maybe filtering IPv4 LL traffic.  However, both of these require much more thought than simply filtering Ethertypes 0x0800 and 0x0806.  Filtering by Ethertype is simple and elegant, further, it is a basic feature supported by many more network devices than the more sophisticated Layer 3 aware filtering otherwise required to not also block the DHCPv4 exchange required for RFC2563 to work.
>
> I want a belt and suspenders approach; I want to signal dual-stack clients that IPv4 isn't available, or at least that they SHOULD NOT autoconfigure an IPv4 LL address, RFC2563 does this nicely, the belt. However, for any dual-stack clients that ignore the signal provided, I also want to filter the unwanted and futile IPv4 traffic on the network to ensure that it doesn't bother other dual-stack clients on the network, the suspenders.
>
> So, RFC2563 with fairly sophisticated Layer 3 aware filtering is an option that achieves the desired results, at least my desired results. However, the IPv6-Only flag has the added advantage of allowing the use of simple and more widely available Ethertype filtering.
>
> Also, the testing that I did shows that most newer clients no longer support RFC2563. I'd be happy to be wrong on this and I'm not 100% sure my test was valid, but even if I'm wrong this shows that making RFC2563 work as desired isn't trivial.
>
> Thanks.
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 May 2019 17:11:34 +1200

On 29-May-19 12:08, Sander Steffann wrote:
...
> requiring that not a single IPv4 packet may be used is not very helpful, realistic or necessary.

Just to be clear, the draft does not require that. But it does have the property of working in an environment where the switches drop all IPv4 and DHCPv4 packets.

Regards
     Brian

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 May 2019 11:37:45 +0200

>Wait, on that argument the host shouldn't waste resources on IPv6 either. 

That might be the best reason we don't have to care about hosts.

If hosts can deal with IPv4-only without running into battery issues, then
hosts can deal with IPv6-only networks as well.

>The

If we were talking about IPv6-only hosts, then there would be no need to
discuss what to do with IPv4.

So we can assume that hosts are dual stack (or IPv4-only). The easiest
solution for network operators is to just configure switches to drop 0x800
and 0x806. Problem solved. No need to update routers, no need to worry
about IPv4-related security issues.