Subject: WGLC: draft-ietf-6man-ipv6only-flag-02

From: Ole Troan <[email-masked]>
Date: Wed, 5 Sep 2018 19:40:55 +0200

This message starts a two week 6MAN Working Group Last Call on advancing:

Title        : IPv6 Router Advertisement IPv6-Only Flag
Authors      : R. Hinden, B. Carpenter
Filename     : draft-ietf-6man-ipv6only-flag-02.txt
Pages        : 11
Date         : 2018-08-14

   https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02

as a Proposed Standard. Substantive comments and statements of support
for publishing this document should be directed to the mailing list.
Editorial suggestions can be sent to the author. This last call will
end on 19 September 2018.

An issue tracker will be setup to track issues raised on this document.

Thanks,
Ole

---

From: David Schinazi <[email-masked]>
Date: Thu, 06 Sep 2018 15:56:43 -0700

Hello 6man,

I am strongly opposed to advancing draft-ietf-6man-ipv6only-flag to Proposed Standard.

The first motivation defined in this document is that it reduces resources used by IPv4. But to do that it requires all client devices to support it, which will take many years. This motivation can be solved simply by having the router drop all IPv4 traffic.

The document even tries to claim that it improves security by reducing malicious IPv4 traffic. That is simply false as hosts are free to ignore the flag, and malicious ones will. This doesn't even protect hosts that implement this flag as a malicious node can send an RA without this flag to make them use IPv4. Again, the correct solution is to have routers drop IPv4 traffic.

This document is also harmful with regards to future developments of the Internet Protocol. What happens when the next version of IP is standardized? Does this flag prevent using the new version on "IPv6-only networks"? So do operators now need to disable this flag and end up with triple stacked hosts?

I think the problems described in this document would be better solved by having routers drop all IPv4 traffic and potentially having a mechanism to let the clients know of this policy - but that mechanism should live either at layer 2, or in IPv4 - it has no place in IPv6. Not to mention the small number of RA flags we have left.

While I can't comment on future products, the odds of us deploying this are very low. And since this option is not useful without most client devices supporting it, network operators will not get the improvements they seek.

For all these reasons, I think this proposal does not adequately solve the problem it describes, and is harmful to future developments of IP. It is therefore premature to promote this draft to Proposed Standard. I would rather see this problem solved elsewhere, potentially in DHCPv4.

Thank you,
David Schinazi

> On Sep 5, 2018, at 10:40, Ole Troan <[email-masked]> wrote:
> 
>    https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02 <https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Sep 2018 17:53:38 -0700

In addition, security issues were pointed out when the concept was first proposed that to my knowledge remain unanswered. Mine were that the fact that a given IPv6-only router knows of no IPv4 subnet or routers on a given LAN doesn't mean that they are not there; it only means that the router in question doesn't know of them and a host that is wondering such things should probably stop trying after some number of attempts to get an IPv4 address. If it's an IPv6-only router, that is almost a given.

+1 to your comments, though.

> On Sep 6, 2018, at 3:56 PM, David Schinazi <[email-masked]> wrote:
> 
> Hello 6man,
> 

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Sep 2018 14:20:32 +1200

Hi,

David has sent his objections before, and the authors updated the draft
considerably as a result. I don't really see what more we can do except
say that the draft already contains responses to all these objections.

Regards
   Brian

On 2018-09-07 10:56, David Schinazi wrote:
>> On Sep 5, 2018, at 10:40, Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Sep 2018 14:27:20 +1200

Fred,
> In addition, security issues were pointed out when the concept was first proposed that to my knowledge remain unanswered. Mine were that the fact that a given IPv6-only router knows of no IPv4 subn…

That's how it works. I don't see any way that it's a security issue. It's exactly
what we describe in the draft: if the admin has set the bit in all routers, hosts
SHOULD avoid IPv4 unless they have a good reason not to. That's really all
there is to it.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 7 Sep 2018 14:17:33 +1000

HI David,

> The first motivation defined in this document is that it reduces resources used by IPv4. But to do that it requires all client devices to support it, which will take many years. This motivation can…

I don't think it solves the problem, it only mitigates other hosts
receiving (typically link-layer broadcast DHCPv4) packets that they're
not interested in.

The sending hosts still spend effort forming and sending periodic
packets, needlessly consuming their own energy doing so, as well as
capacity on the link-layer media.

The only way to solve the problem is to inform sending hosts that
sending those types of packets will never succeed, so they shouldn't
waste their resources forming and sending them. This flag is that
signal.

It may take years for this flag to be widely supported, however that
is better than nothing. Layer 2 filters in the network do nothing to
prevent hosts creating and sending these useless packets (even layer 2
filters pushed down into the hosts still wouldn't prevent these
useless packets being created.)

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Sep 2018 17:42:01 +1200

Just a few points that I noticed on a second reading:
On 2018-09-07 10:56, David Schinazi wrote:
...
> The document even tries to claim that it improves security by reducing malicious IPv4 traffic.

It does not make that claim. It does observe that malicious IPv4
traffic is a risk and it mentions that the proposed mechanism will mitigate
various risks including that one. Please check the meaning of "mitigate":
"make (something bad) less severe, serious, or painful."

> That is simply false as hosts are free to ignore the flag, and malicious ones will. 

Of course. We don't claim otherwise.

> This doesn't even protect hosts that implement this flag as a malicious node can send an RA without this flag to make them use IPv4.

That point is specifically discussed in the second paragraph of the security
considerations. The only case where this could apply is if the one and only
IPv6 router on the link is taken over by malicious code, in which case all
is lost anyway.

> Again, the correct solution is to have routers drop IPv4 traffic.

s/routers/routers, switches and bridges/

Of course. But that's a different topic (discussed with respect to Layer 2
filtering in Section 1 of the draft).

    Brian

---

From: [email-masked]
Date: Fri, 07 Sep 2018 07:51:09 +0200 (CEST)

> end on 19 September 2018.

With my ISP hat on: We have no plans to ask our equipment vendors to
support this, or to configure it if it was available. We see this as
a completely unnecessary change.

Not supported.

Steinar Haug, AS2116

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Sep 2018 08:43:22 +0200

> a completely unnecessary change.

Right, there probably isn’t much of a use case for an ISP. If considering the PE - CE link, RFC7083 is probably the only thing akin to this. Apart from public WIFI. 

Cheers 
Ole

---

From: [email-masked]
Date: Fri, 07 Sep 2018 09:05:54 +0200 (CEST)

> Right, there probably isn’t much of a use case for an ISP. If considering the PE - CE link, RFC7083 is probably the only thing akin to this. Apart from public WIFI. 

We're also considering managed Wifi solutions for customers - and the
answer is still no.

Steinar Haug, AS2116

---

From: David Schinazi <[email-masked]>
Date: Fri, 07 Sep 2018 09:45:38 -0700

Hi Brian,

The updates to the draft do not address my comments.
Saying that the draft contains responses is not sufficient if you want to reach working group consensus.

Regards,
David

> On Sep 6, 2018, at 19:20, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
>>> On Sep 5, 2018, at 10:40, Ole Troan <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: David Schinazi <[email-masked]>
Date: Fri, 07 Sep 2018 09:52:00 -0700

Hi Mark,

Responses inline.

> On Sep 6, 2018, at 21:17, Mark Smith <[email-masked]> wrote:
> 

It solves part of the problem - and in my mind those are the most important parts.

> waste their resources forming and sending them. This flag is that

As I mentioned in my previous message, there might be value for *a* flag,
but not necessarily for *this* flag. IPv6 RA flags are not the right vehicle for this.

> useless packets being created.)

No, this is not better than nothing, it is worse than nothing. It uses up an
RA flag and creates pain down the road when we want to update IP again.

Regards,
David

---

From: David Farmer <[email-masked]>
Date: Fri, 7 Sep 2018 12:19:46 -0500

On Fri, Sep 7, 2018 at 2:05 AM, <[email-masked]> wrote:

> > Right, there probably isn’t much of a use case for an ISP. If
> considering the PE - CE link, RFC7083 is probably the only thing akin to
> this. Apart from public WIFI.
>

I have a couple questions for you. When you say "no" to this are you saying
no you won't deploy IPv6-only networks? Or, are you saying you will deploy
IPv6-only networks but you would never set the flag if it were provided?

Or put another way, are you saying it's not useful because you won't ever
deploy IPv6-only networks?

Thanks.

-- 
===============================================
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: Nick Hilliard <[email-masked]>
Date: Fri, 7 Sep 2018 18:38:18 +0100

Mark Smith wrote on 07/09/2018 05:17:
>> The first motivation defined in this document is that it reduces
>> resources used by IPv4. But to do that it requires all client
>> devices to support it, which will take many years. This motivation
>> can be solved simply by having the router drop all IPv4 traffic.
> 
> receiving (typically link-layer broadcast DHCPv4) packets that
> they're not interested in.
> 

fundamentally, this doesn't matter.  The only situation where it has any 
relevance is on wifi networks.

If there is no default route on the device, then the only traffic of 
relevance is link-local traffic.  Everything else will be dropped in the 
o/s kernel because there won't be a route for it.

If the AP blocks ARP, then the device will never receive ARP broadcast 
requests from other hosts, and will never receive ARP replies from the 
ARP requests that it sends out.

This will cause the underlying operating system to block all unicast 
ipv4 traffic, because the OS will have no ARP mapping for the IP 
addresses that the device is trying to reach.

So immediately, the scope of the problem is reduced from trying to 
handle lots of random ipv4 background chatter, to rate-limiting or 
otherwise constraining outbound ARP requests and other broadcast traffic 
for 169.254.0.0/16, or possibly 0.0.0.0/8 address space.

Reminder: outbound broadcast traffic from the station to the 
access-point is sent via unicast (i.e. not at wifi basic rate), and the 
OS would easily be able to coalesce arp requests into bursts, instead of 
issuing them piecemeal at a higher resource cost.

However it's handled, the 6man wg should probably assume that the 
handheld device manufacturers would be better able to assess battery 
optimisation methodologies in this situation, because that's their day 
job and they're pretty good at it.

Nick

---

From: [email-masked]
Date: Fri, 07 Sep 2018 20:12:22 +0200 (CEST)

> IPv6-only networks but you would never set the flag if it were provided?

IPv6-only networks are not in our current plans. That may change over
time, obviously. However, even with IPv6-only I don't see us using
this flag.

The reasons this flag is not a good idea has been well explained by
Nick Hilliard, David Schinazi and others.

Steinar Haug, AS2116

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 7 Sep 2018 19:35:52 +0000

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

> I have a couple questions for you. When you say "no" to this are you saying no you won't deploy IPv6-only networks? Or, are you saying you will deploy IPv6-only networks but you would never set the flag if it were provided?

> Or put another way, are you saying it's not useful because you won't ever deploy IPv6-only networks?

Not answering for the other guys, Dave, but in this latest go-around, I thought the point made was that to achieve the goal of IPv6-only networks, all routers filtering IPv4 out at layer 2 was the best answer.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Sep 2018 08:33:40 +1200

> Right, there probably isn’t much of a use case for an ISP. If considering the PE - CE link, RFC7083 is probably the only thing akin to this. Apart from public WIFI. 

Correct. It's a solution for certain scenarios, and it's a market decision
which scenarios justify the cost.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Sep 2018 08:38:37 +1200

> job and they're pretty good at it.

Exactly. This is a tool in the toolkit, but it's their job to figure
out if it's useful. For all I know, this is a tool that might sleep
for years until engineering tradeoffs change and it becomes useful.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Sep 2018 08:43:50 +1200

> Not answering for the other guys, Dave, but in this latest go-around, I thought the point made was that to achieve the goal of IPv6-only networks, all routers filtering IPv4 out at layer 2 was the…

And the proposal recognises that. But it isn't "routers" because routers
are at level 3; it's layer 2 devices, *if* they have that capability. As
explained in the draft, this solution is for scenarios where that isn't
the case.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Sep 2018 08:53:30 +1200

> The updates to the draft do not address my comments.

They are intended to explain how this proposal fits in with the
alternative (layer 2 solutions). The draft doesn't suggest that it's
an exclusive solution; it's entirely complementary to layer 2 solutions,
and it *adds* an explicit signal to dual stack nodes telling them that
they SHOULD NOT send IPv4 packets. Of course, it's an engineering choice
whether that is a win, but like all IETF standards, this would be for
the market to decide.

   Brian

> Saying that the draft contains responses is not sufficient if you want to reach working group consensus.> 
> Regards,
> David
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Sep 2018 09:09:42 +1200

David,

> but not necessarily for *this* flag. IPv6 RA flags are not the right vehicle for this.

Why not? Just because spare bits are rare? 

What would be a better vehicle?

> RA flag and creates pain down the road when we want to update IP again.

I don't see that. Admittedly, the original name ("IPv4 Unavailable flag")
was better in this respect, and it might be cleaner to define this one
as meaning "No IP with version <6 on this link", but when IPvN comes along,
it could choose to signal "No IP with version <N on this link".

Regards
    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 7 Sep 2018 23:22:54 +0100

Brian E Carpenter wrote on 07/09/2018 21:53:
> and it*adds*  an explicit signal to dual stack nodes telling them that

Brian,

It's not ok to brush technical critique off with answers along the lines 
of "you may have a point ... but the market will decide".  The IETF has 
a duty to assess drafts on the basis of whether they solve 
clearly-defined problems in technically appropriate ways, and any draft 
going through a WG should be able to withstand reasonable commentary and 
criticism.  There's been a substantial number of serious technical 
concerns posted in this WG about this draft, both in terms of the 
problem statement and the proposed solution.  Most of these remain fully 
unaddressed in any reasonable way in terms of either discussion on the 
mailing list or updates to the document.

I can see why the ipv6only flag might seem attractive from an 
ideological point of view, but from the point of view of production 
engineering, the problem statement does not withstand scrutiny.  Even if 
it did, the issues identified in the draft could be handled more 
comprehensively and more simply in several other ways.  Sorry to be so 
brutally utilitarian - if not harsh - but there are fundamental problems 
here, and these problems must be addressed adequately before the draft 
progresses.

Nick

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 7 Sep 2018 22:38:54 +0000

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 

>> Not answering for the other guys, Dave, but in this latest go-around,
>> I thought the point made was that to achieve the goal of IPv6-only
>> networks, all routers filtering IPv4 out at layer 2 was the best answer.
>

Okay, but routers do have the Ethernet interface(s) and driver(s), presumably. So the ISP that configures routers, in particular the edge router in the home modem, let's say, which typically incorporates something like a 4-port layer 2 switch, and sometimes also a WiFi access point, could readily prevent any IPv4 from crossing over into the ISP network.

In effect, doing quite well what the flag hopes to achieve.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Sep 2018 11:15:32 +1200

> In effect, doing quite well what the flag hopes to achieve.

But no, because what the flag hopes to achieve is to prevent hosts
wasting resource on sending IPv4 packets, or doing anything except
discard them if they arrive. There's no way to do that except by
sending *something* to the hosts.

    Brian

   Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 7 Sep 2018 23:27:07 +0000

> which scenarios justify the cost.

Have you spoken to vendors or ISPs / enterprise who would either implement or use this flag?

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Sep 2018 11:29:33 +1200

On 2018-09-08 10:22, Nick Hilliard wrote:
> criticism.  

Yes, which is what we're doing here.

> There's been a substantial number of serious technical 

I think we've made it clear (on the list and in the draft) that we
are proposing something in addition to switch-based solutions, that
(as I just wrote to Bert) can only be achieved by sending a signal
to the hosts. That said, I really don't know which technical concerns
haven't been addressed. Can you be explicit, because we considered
all previous comments when producing the current draft?
 
> engineering, the problem statement does not withstand scrutiny.

   o  Such traffic may drain battery power on wireless hosts that have
      no interest in link-local IPv4 traffic.  [RFC7772] indicates how
      this risk might be quantified.

   o  Similarly, hosts may waste battery power on futile attempts to
      access IPv4 services.

Those are the problem statements concerning hosts. What's wrong
with them? (I agree that the other problems listed can be mitigated
by switches. We could reorganise the text to make this clearer.)

> Even if 
> comprehensively and more simply in several other ways.  

How else could we tell hosts to ignore IPv4 completely?

    Brian

> Sorry to be so

---

From: Mark Smith <[email-masked]>
Date: Sat, 8 Sep 2018 11:11:58 +1000

> It solves part of the problem - and in my mind those are the most important parts.

What do you consider to be the most important parts?

I consider both reducing unnecessary link-layer broadcasts on a link
and having hosts not expending unnecessary cycles sending useless
packets to be equally important as the goals of this flag.

Related to saving hosts' energy, we even consider saving battery power
on portable devices important enough that we've published a BCP on
reducing the energy consumption consequences of RAs - BCP 202 -
"Reducing Energy Consumption of Router Advertisements"

Micro-savings of individual hosts' energy multiplied by billions of
hosts can be a major energy saving.

> but not necessarily for *this* flag. IPv6 RA flags are not the right vehicle for this.

IPv6 RAs can be considered an out-of-band protocol to carry this IPv4
information.

Another IPv4 out-of-band protocol such as a link-layer protocol e.g.
LLDP could be used to convey this information instead. However,
adoption of either a new link-layer protocol, or a modification to one
like LLDP and its subsequent widespread adoption, is going to take far
longer than adoption of this RA flag in hosts and routers that will
already need to and are speaking IPv6.

Somebody suggested using ARP for this. Trouble is that ARP is a
link-layer broadcast packet, and is also a companion legacy IPv4
protocol that this flag is inherently also trying to disable when it
can be.

> RA flag and creates pain down the road when we want to update IP again.

Everything is a trade off. If the benefit outweighs the cost, then the
cost is worth paying.

Not that we should be worrying about the next version of IP (and won't
need to for in the order of at least 50 years), but how will this
create pain to upgrade to the next version of IP? We don't even know
what the next version of IP will look like.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Sep 2018 14:13:52 +1200

> Have you spoken to vendors or ISPs / enterprise who would either implement or use this flag?

I'll leave that to Bob, but there were enough positive comments during
the WG adoption call that it seemed to me there was real interest.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 8 Sep 2018 12:31:57 +1000

On Sat, 8 Sep 2018 at 03:38, Nick Hilliard <[email-masked]> wrote:
> fundamentally, this doesn't matter.

Fundamentally it does matter. We don't have endless amounts of energy.

>  The only situation where it has any

There are 100s of millions of them. Nearly every home has one.

> o/s kernel because there won't be a route for it.

Packets are still being built and not sent == wasted effort.

I'm wasting effort repeating these points ...

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 8 Sep 2018 13:44:18 +0100

> all previous comments when producing the current draft?

I've already done this, repeatedly and at some length, and you have 
either agreed with, ignored or inadequately addressed the points that 
were brought up.  If you compare versions -00 and -02 of the draft, the 
changes are minimal and for the most part don't substantially address 
the technical comments that have been made either by me or anyone else, 
going right back to before WG adoption when the draft was still 
draft-hinden.

> with them?

For starters, these two particular points are in fact the same point 
fleshed out to make it looks it's two points. One concerns traffic 
received by battery-powered wifi hosts; the other concerns traffic sent 
by battery-powered wifi hosts.  This point should be coalesced this into 
a single point because it's the same underlying issue.  As I've 
repeatedly said, this particular point has some limited legitimacy, but 
it is strongly bounded by the fact that it is of most relevance on 
poorly designed large networks and in any case there are far better ways 
of dealing with it than draft-ietf-6man-ipv6only-flag could ever hope to 
achieve.

Secondly, I wasn't just talking about problem statements concerning 
hosts.  I was talking about all the points because they're all weak.  If 
you number them in order, 1 to 5:

1. is a general L2 design issue, i.e not relevant to this draft.  The 
last time this was relevant was the 1990s, when we learned that gigantic 
l2 domains was a terminally broken approach to IP networking.  This 
point needs to be deleted.

2. is a red herring and needs to be removed.  In my email of Aug 16, I 
had originally fleshed out why switches don't store ipv4 hardware state 
in general, but deleted the text before sending because I had thought it 
should have been obvious enough.  But in the interests of completeness, 
I will reply later on that part of the thread because you are largely 
incorrect on a point of fact.

3. / 4. are the same point dressed up to look like two different points 
and are of limited scope in terms of overall relevance. I.e. the 
relevant is only to battery powered wifi devices and is of no particular 
relevance to any other type of host on any other network medium.

5. this point needs to be removed entirely. If link security is an 
issue, it is something that needs to be policed rather than depending on 
advisory flags which may not even be implemented by the hosts on the 
network.  Leaving this point in the document displays a disconcerting 
misunderstanding of the fundamentals of network security.

> (I agree that the other problems listed can be mitigated

> How else could we tell hosts to ignore IPv4 completely?

You need to start out by not putting the cart before the horse, i.e. 
sort out your problem statement. Right now, it boils down to:

1. we allege that a flag of this form could be useful for power 
management on battery-powered wifi-enabled devices on unmanaged wifi 
networks

Nick

---

From: "Liu,Shu@CATR" <[email-masked]>
Date: Sun, 9 Sep 2018 20:30:03 +0800

Hi all
I don't like the idea ipv6-only network, when you think about the upnp and auto-ip, the ipv4 still works in a LAN environment without dhcpv4 server.

andrew
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Saturday, September 8, 2018 7:27 AM
To: Brian E Carpenter
Cc: [email-masked]
Subject: Re: WGLC: draft-ietf-6man-ipv6only-flag-02

On 7 Sep 2018, at 21:33, Brian E Carpenter <[email-masked]> wrote:
>>>> as a Proposed Standard. Substantive comments and statements of 
>>>> support for publishing this document should be directed to the mailing list.
>>>> Editorial suggestions can be sent to the author. This last call 
>>>> will end on 19 September 2018.
>>> 
> Correct. It's a solution for certain scenarios, and it's a market 
> decision which scenarios justify the cost.

Tim

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Sep 2018 13:44:14 -0400

> alternative (layer 2 solutions). The draft doesn't suggest that it's an
    > exclusive solution; it's entirely complementary to layer 2 solutions,
    > they SHOULD NOT send IPv4 packets. Of course, it's an engineering
    > choice whether that is a win, but like all IETF standards, this would
    > be for the market to decide.

A home (or coffee shop gateway) that saw the IPv6-only flag on it's upstream
link might well take that as a clue that it ought to implement the layer-2
solutions on *its* ethernet/wifi.

Would I want to enable this functionality by default on a device that was
intended for FutureShop? No.

Would I want it this functionality enabled on devices intended for coffee shops
that I support, whose ISPs are transitioning to IPv6 and IPv6-only uplinks?
Yes.

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

---

From: Simon Hobson <[email-masked]>
Date: Sun, 9 Sep 2018 20:01:51 +0100

> I don't like the idea ipv6-only network, when you think about the upnp and auto-ip, the ipv4 still works in a LAN environment without dhcpv4 server.

And (rhetorical question) do the equivalents not work in IPv6 ?
The thing is, if you have completely transitioned to IPv6, then the same things will work - auto IP via SLAAC and/or use of link local address(es), device/service discovery via mDNS, and so on. So "turning off" IPv4 by setting this flag wouldn't be noticed by users - the printer would still "just work", the NAS would "just be there", and so on but using IPv6 instead of IPv4.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 9 Sep 2018 19:22:07 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Michael Richardson

> A home (or coffee shop gateway) that saw the IPv6-only flag on it's
> upstream link might well take that as a clue that it ought to implement
> the layer-2 solutions on *its* ethernet/wifi.

I suppose so, although Brian's point is that the flag is primarily intended for hosts in the local subnet, e.g. to not waste energy trying to acquire an IPv4 address.

Although here's another thought, concerning a layer 2-only solution, which might achieve much the same effect. Given that this flag's primary user appears to be hosts, hosts need to be updated too. So, forgetting about a new layer 3 flag, why not program hosts to only very infrequently attempt anything at IPv4, when ARP or DHCPv4 fail (as a result of all 1s broadcast and IPv4 Ethertype failing to work with the local routers)? As long as hosts need to be changed anyway, this seems as easy as any change to read and react to a new flag at layer 3?

And too, we can fine tune how this layer 2 solution works. The layer 2 blocking of IPv4 (and ARP) can occur only on the actual router interface, let's say in that home or coffee shop net, or also on WiFi and Ethernet ports inside that home or coffee shop. So in principle, in cases where the gateway itself won't handle IPv4, you could still run IPv4 apps inside that venue.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Sep 2018 08:49:18 +1200

On 2018-09-10 07:22, Manfredi (US), Albert E wrote:
> Although here's another thought, concerning a layer 2-only solution, which might achieve much the same effect. Given that this flag's primary user appears to be hosts, hosts need to be updated too. So, forgetting about a new layer 3 flag, why not program hosts to only very infrequently attempt anything at IPv4, when ARP or DHCPv4 fail (as a result of all 1s broadcast and IPv4 Ethertype failing to work with the local routers)? 

Yes, that's a good idea - basically a change to the backoff timers. My thought was
that the v6only flag could trigger such behaviour. Whether we could persuade all
IPv4 stack developers to make such an update without the flag to act as a signal
is another question.

> As long as hosts need to be changed anyway, this seems as easy as any change to read and react to a new flag at layer 3?

Well, it introduces state anyway. Instead of state saying "I have seen the IPv6-only
flag from every router" it would be state saying "I have seen no ARP or DHCP response,
so my backoff timer is now T".

> And too, we can fine tune how this layer 2 solution works. The layer 2 blocking of IPv4 (and ARP) can occur only on the actual router interface, let's say in that home or coffee shop net, or also o…

Using IPv4 link-local addressing, yes, as briefly mentioned in the draft. But it
seems to me that filtering on the Ethertype would block even that.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Sep 2018 07:23:12 +1000

On Mon, 10 Sep 2018 at 06:50, Brian E Carpenter
<[email-masked]> wrote:
> that the v6only flag could trigger such behaviour.

So I think this is where there is still some ambiguity with the name.

As a signal to hosts, the name "IPv6 only" says to me that it is a
statement that the link only supports IPv6 - IPv4 is intended not to
work by policy, so don't bother trying to do use it. In other words,
switch off any attempts to acquire IPv4 addresses, and if any
applications try to open any IPv4 sockets, the host OS generates an
error immediately because there is no IPv4 address available to use,
with this always occurring on an "IPv6 Only" link.

If a host may still be able to use IPv4 on the link for the IPv4 Link
Local address case, then "IPv6 only" isn't the truth.

It seems there are really two situations here that are trying to be
represented by a single flag:

- IPv4 off-link won't work, so only IPv4 Link Local will work, if it
is necessary. Only IPv6 is supported for both on-link and off-link
destinations.

- IPv4 on-link and off-link won't work by policy, so don't bother even
trying to bring up IPv4, even IPv4 Link-Local. This may be further
enforced by layer 2 filters that drop 0x800 and 0x806.

The name "IPv6 Only" suits the latter, however I don't think it suits
the former.

I think that argues for either a less definite and more accurate name
than "IPv6 Only", or perhaps two flags for these two situations -
"Only IPv4 Link-Local Supported" and "IPv6 Only Link".

Regards,
Mark.

>Whether we could persuade all

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 10 Sep 2018 13:00:28 +0000

> > I don't like the idea ipv6-only network, when you think about the upnp and
> auto-ip, the ipv4 still works in a LAN environment without dhcpv4 server.
> 
> The thing is, if you have completely transitioned to IPv6, then the same
> things will work - auto IP via SLAAC and/or use of link local address(es),
> device/service discovery via mDNS, and so on. So "turning off" IPv4 by
> setting this flag wouldn't be noticed by users - the printer would still "just
> work", the NAS would "just be there", and so on but using IPv6 instead of
> IPv4.

Apparently, this isn't a rhetorical question. The answer is "no". There are many IPv4-only devices that are using IPv4 "Auto IP". The vast majority of these will never support IPv6 and would never support this flag. If routers started blocking IPv4 at L2, these devices will stop working. That provides no benefit to the devices that stop working, and the devices that respect the flag and stop doing IPv4 won't care. If the goal is to help hosts-that-respect-the-flag save power, then disabling IPv4 at L2 is completely unnecessary, and potentially harmful.

I'm with Andrew (Liu,Shu@CATR) on this.

I don't object to the flag as a potential aid to battery-challenged devices. I do object to proposals that IPv4 be disabled at L2.
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Sep 2018 10:01:59 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > Apparently, this isn't a rhetorical question. The answer is "no". There
    > are many IPv4-only devices that are using IPv4 "Auto IP". The vast
    > majority of these will never support IPv6 and would never support this
    > flag. If routers started blocking IPv4 at L2, these devices will stop
    > working.

If the operator of the network wants these devices to continue operating,
then they don't set the flag, and they don't block IPv4 at L2.

(Maybe there is some scenarios where one sets the flag, but doesn't block
IPv4, or maybe even the opposite.  Both are intentional acts)

    > That provides no benefit to the devices that stop working, and
    > the devices that respect the flag and stop doing IPv4 won't care. If
    > the goal is to help hosts-that-respect-the-flag save power, then
    > disabling IPv4 at L2 is completely unnecessary, and potentially
    > harmful.

    > I don't object to the flag as a potential aid to battery-challenged
    > devices. I do object to proposals that IPv4 be disabled at L2.

It's not like we are forcing operators to either:
  1) disable IPv4 at L2
  2) set the ipv6-only flag

For those that want to set the flag, the flag can exist.

So, can we stop thinking that this is being forced on all networks, all the time?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 10 Sep 2018 14:40:18 +0000

> From: Michael Richardson <[email-masked]>
> 

I agree that there are 2 intentional acts being discussed -- I disagree as to what the 2 acts are (or rather, should be). I believe the 2 acts are (1) a flag that tells hosts they don't need to do any IPv4 and shouldn't expect to find any DHCPv4 server; and (2) preventing all LL IPv4 from working.

If the goal of the flag is to benefit hosts who want to save power by not doing DHCPv4 (or any IPv4), then L2 blocking is orthogonal to this goal. Such hosts are perfectly capable of not using IPv4 (including "Auto IP" LL IPv4). Disabling LL IPv4 has absolutely nothing to do with helping battery-constrained hosts. 

To suggest that managed networks are only permitted to benefit from this flag if they also break legacy devices' use of "Auto IP" LL IPv4 makes the flag harmful and undesirable.

Since we're talking about managed routers, there is no reason why configuring this flag and blocking IPv4 ethertype need to be combined. They can (and should be) be completely distinct configuration settings. 
 
> So, can we stop thinking that this is being forced on all networks, all the time?

I'm not suggesting it's being forced on all networks, all the time. I'm objecting to suggestions that we either need 2 flags (if you're going to have 2 things to set, just make the 2 things the "no need for IPv4" flag and "block IPv4 ethertype"), or that we need to automatically block IPv4 if the single proposed flag is set. The linkage of flag and IPv4 blocking makes the flag much more likely to be harmful and adds no value.

Barbara

---

From: Simon Hobson <[email-masked]>
Date: Mon, 10 Sep 2018 21:06:38 +0100

> flag. If routers started blocking IPv4 at L2, these devices will stop

Then the network isn't transitioned to IPv6 only. It's rather implicit in saying a network is IPv6 only that you have no devices left that need IPv4.

> then they don't set the flag, and they don't block IPv4 at L2.

Indeed.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2018 08:36:59 +1200

Excuse front-posting but, of course, what a network admin chooses to
do about L2 blocking of IPv4 is *irrelevant* to the normative part
of this draft. It's clear from some of the comments that some operators
might choose to block the IPv4 Ethertypes at L2. It's also clear (to me)
that by even mentioning this in the draft, we've ended up confusing
the issue (the opposite of what we intended). So I think we need
to do some rewriting. 

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2018 08:44:39 +1200

> Then the network isn't transitioned to IPv6 only. It's rather implicit in saying a network is IPv6 only that you have no devices left that need IPv4.

But the operator may or may not know that. In a large network (in particular
with BYOD) it may even be unknowable.

This gets back to Michael Richardson's point. The operator can know for
sure that the network provides neither DHCP nor IPv4 routing. That's all the
flag says definitively in the current definition. Whether link-local IPv4
works is a separate issue.

>> then they don't set the flag, and they don't block IPv4 at L2.
See above...

    Brian

---

From: Simon Hobson <[email-masked]>
Date: Mon, 10 Sep 2018 22:42:01 +0100

> works is a separate issue.

That does not change the argument. If the network owner/operator/admin has decided that the network is now IPv6 only then they presumably will have decided one or more of the following (which are really the same thing) :
1) They have decided that there are no devices left on the network that need IPv4 **AND** that they are concerned about still working
2) They've made a business decision to not support IPv4 and if some Internet-of-Tat junk doesn't work then "someone" (it's BYOD owner for example) will need to upgrade or replace it if they want it to work.

At some point, when IPv4 use is sufficiently declining, various networks will be making such decisions - and there'll be a decision to be made as to where the line is drawn between the costs of continuing to support the legacy protocol, and the costs of dropping it.

So yes, it is valid to say that a network can be IPv6 only but have devices that don't do IPv6. Those devices will then be broken - and if they are needed then something will need to be done about it (such as buying one that's not stuck in the 20th century). If you need them to work and can't/won't upgrade them, then you keep IPv4 working and the network is not IPv6 only - so the admin doesn't set the flag.

TL;DR - if you need some IPv4 devices to work then you have not transitioned to IPv6 only. Don't set the "no IPv4 spoken here" flag.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2018 10:19:35 +1200

Simon,

> TL;DR - if you need some IPv4 devices to work then you have not transitioned to IPv6 only. Don't set the "no IPv4 spoken here" flag.

I think that misses a subtlety. The "operator" (who may be no expert) might
not be aware of situations like the following:

Some of the devices (installed long ago and forgotten) are IPv4-only smoke
alarms. They can use link-local IPv4 to communicate with a more modern
dual stack master alarm, which communicates with the outside world via
IPv6.

So in that situation there is a crucial difference between IPv4 "not
routed" and "IPv4 blocked by the switches." In the latter case, the
legacy smoke alarms won't work.

The flag as currently defined is "IPv4 not routed". That is less drastic
than "IPv4 blocked". It may even be helpful information for that dual
stack master alarm.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2018 10:21:34 +1200

>    https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-02

So, those 2 weeks are well past. The authors will think about next steps,
given the complicated discussion.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Sep 2018 08:26:17 +1000

On Tue., 11 Sep. 2018, 07:42 Simon Hobson, <[email-masked]> wrote:

> >> Then the network isn't transitioned to IPv6 only. It's rather implicit
> in saying a network is IPv6 only that you have no devices left that need
> IPv4.
> >
> That does not change the argument. If the network owner/operator/admin has
> decided that the network is now IPv6 only then they presumably will have
> decided one or more of the following (which are really the same thing) :
> 1) They have decided that there are no devices left on the network that
> need IPv4 **AND** that they are concerned about still working
> 2) They've made a business decision to not support IPv4 and if some
> Internet-of-Tat junk doesn't work then "someone" (it's BYOD owner for
> example) will need to upgrade or replace it if they want it to work.
>
> At some point, when IPv4 use is sufficiently declining, various networks
> will be making such decisions - and there'll be a decision to be made as to
> where the line is drawn between the costs of continuing to support the
> legacy protocol, and the costs of dropping it.
>
> So yes, it is valid to say that a network can be IPv6 only but have
> devices that don't do IPv6. Those devices will then be broken - and if they
> are needed then something will need to be done about it (such as buying one
> that's not stuck in the 20th century). If you need them to work and
> can't/won't upgrade them, then you keep IPv4 working and the network is not
> IPv6 only - so the admin doesn't set the flag.
>
> TL;DR - if you need some IPv4 devices to work then you have not
> transitioned to IPv6 only. Don't set the "no IPv4 spoken here" flag.
>

Who is arguing that? I'm not, and I'm pretty sure Brian and others aren't.

If you still want off-link IPv4 to work, you'll have a default IPv4 router
and most likely a DHCPv4 server. Why would any operator purposely set an
"IPv6 Only" flag in that scenario, unless it is a step as part of removing
IPv4 support from the link?

IPv4 is a legacy protocol, and on these links is purposely being treated as
a second class protocol by the link operator.

If a link doesn't provide full IPv4 support, mainly meaning no default
router, so no off-link IPv4, isn't the nice and best thing to do for the
hosts and their end-users to tell them so?

This is in effect an "ICMPv4 destination unreachable" message for all
off-link IPv4 destinations, except that it avoids all the IPv4 protocol
initialisation and infrastructure (hosts acquiring IPv4 addresses, a DHCPv4
server, default router with no IPv4 routes) that would be needed to send
those ICMPv4 messages for all off-link destinations.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Sep 2018 06:50:50 +0200

Brian,

> On 11 Sep 2018, at 00:21, Brian E Carpenter <[email-masked]> wrote:
> 

It might have felt like two weeks, but the last call doesn’t end before September 19th. 

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2018 17:19:33 +1200

> It might have felt like two weeks, but the last call doesn’t end before September 19th. 

Silly me, sorry, I misread the date (new computer, still fiddling with font sizes etc.). Doesn't change my conclusion that we have to work on the draft...

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Sep 2018 08:27:25 +0200

>> On 11 Sep 2018, at 07:19, Brian E Carpenter <[email-masked]> wrote:
>> 

Right. Trying to categorize the comments:

1) Not deploy.  This doesn’t fit with our model of network operations. 

2) No need. It’s sufficient to block IPv4 traffic in the network and no need to signal hosts. 

3) Implications of flag. Does the flag mean an IPv6 only link, ie no IPv4 packets on it or does it only mean that routers don’t forward IPv4. 

Please add if there are some I have missed.

In my view 1+2 are relevant in judging if we should do this work at all, and if there’s consensus to proceed.

While 3 is more relevant to what we traditionally discuss during a last call. Is the document clear, solution described interoperable etc. 

Cheers 
Ole

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Sep 2018 10:11:28 +0000

> On 10 Sep 2018, at 23:19, Brian E Carpenter <[email-masked]> wrote:
> 
> Simon,
> 

Well, "IPv4 not routed by the device sending this RA".

I would not expect L2 blocking as a default action of this flag being set, but it all depends on the context of the network where it's being used.  Even if only IPv6 is routed externally to the LAN, I would still expect IPv4 LL and SD to work, even when the IPv4 SD messages are likely to be duplicates of the same IPv6 SD messages, given a dual-stack device will typically issue the same SD messages over both protocols.

Tim

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Sep 2018 12:23:32 +0200

> I would not expect L2 blocking as a default action of this flag being set, but it all depends on the context of the network where it's being used.  Even if only IPv6 is routed externally to the LAN…

In my view this flag should not be about what the network does.
It should be configuration information to the host. “Please disable IPv4 on the interface connected to this link. “

Ole

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 11 Sep 2018 15:33:39 +0100

> Please add if there are some I have missed.

it hasn't been discussed in the context of the WGLC for this draft, but 
the security implications of this flag give me the heebie-jeebies.  Do 
we need to discuss this?

Nick

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Sep 2018 17:00:26 +0200

Nick,

> On 11 Sep 2018, at 16:33, Nick Hilliard <[email-masked]> wrote:
> 
> it hasn't been discussed in the context of the WGLC for this draft, but the security implications of this flag give me the heebie-jeebies.  Do we need to discuss this?

Yes, most definitely. 
We cannot publish something with heebie-jeebies security. :-)

Cheers 
Ole

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 11 Sep 2018 18:08:05 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan

> 3) Implications of flag. Does the flag mean an IPv6 only link, ie no IPv4 packets on it or does it only mean that routers don’t forward IPv4.

I might modify 2 slightly, to say, "It's sufficient to block IPv4 traffic at layer 2, and have that blocking act as an implicit signal to hosts, that the router is not forwarding IPv4 packets." (Timers in hosts would have to be modified to make use of this. On the other hand, a new flag would also involve changes to hosts.)

One could conceivably not block all the internal traffic at layer 2, but only what is sent to the router itself. So in a home net, potentially, the layer 2 switch part of the modem/router could allow 0x800 and 0x806 through to the other internal ports, but block those to the router, preventing DHCP from working and preventing the default router MAC address to be found, for IPv4 routing.

Bert

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Sep 2018 16:55:20 -0400

>>>>> ipv6  <<[email-masked]> On Behalf Of Ole Troan> writes:
Manfredi (US), Albert E <[email-masked]> wrote:
    > I might modify 2 slightly, to say, "It's sufficient to block IPv4
    > traffic at layer 2, and have that blocking act as an implicit signal to
    > hosts, that the router is not forwarding IPv4 packets." (Timers in
    > hosts would have to be modified to make use of this. On the other hand,
    > a new flag would also involve changes to hosts.)

That actually won't work automatically in many hosts today.
Many hosts/UIs have a set of flags that today says:
     [x] IPv4 required for this connection to be valid.
     [ ] IPv6 required for this connection to be valid.

This works just fine with Dual-Stack, or IPv4 only.

If you block IPv4 "implicitely", then with this makes the connection
mysteriously fail.  The ipv6-only flag makes it clear that this combination
isn't going to work, and the OS can either suggest something different,
or could even be told to automatically swap this for new connections.

The flag is useful, even if all it does is put up a dialogue box the first
one it is used that:  "This network is 128-bit. Yeah!"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Sep 2018 15:02:00 +1200

On 2018-09-11 18:27, Ole Troan wrote:
...
> Please add if there are some I have missed.

I've got

4) Not useful enough to justify burning an RA flag bit.

5) Is the flag useful to test the migration to IPv6-Only mode?

6) Security heebie-jeebies
> In my view 1+2 are relevant in judging if we should do this work at all, and if there’s consensus to proceed.

Well, 1) is fine for anybody to say, but it seems other people find the flag useful,
that's fine too, so I think it's a wash.

The draft itself argues against 2) by saying that layer 2 blocking doesn't
work in all cases and only partly mitigates the battery and spectrum
arguments. YMMV.

Honestly I believed we had covered those arguments during the WG adoption
call. The people who disagreed then also disagree now.

   Brian

> .

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Sep 2018 21:20:02 +0200

Hi Nick,

> It's not ok to brush technical critique off with answers along the lines of "you may have a point ... but the market will decide".  The IETF has a duty to assess drafts on the basis of whether they solve clearly-defined problems in technically appropriate ways, and any draft going through a WG should be able to withstand reasonable commentary and criticism.  There's been a substantial number of serious technical concerns posted in this WG about this draft, both in terms of the problem statement and the proposed solution.  Most of these remain fully unaddressed in any reasonable way in terms of either discussion on the mailing list or updates to the document.

Would you mind enumerate the technical issues with draft so we can put those in the tracker?
Please spell them out, because I have reviewed the thread without quite understanding what the technical issues are.

Best regards,
Ole