Subject: Proposed text for draft-ietf-6man-ipv6only-flag

From: Bob Hinden <[email-masked]>
Date: Thu, 8 Nov 2018 10:51:02 +0700

Hi,

Based on the discussion during the 6man session in Bangkok on Tuesday, here is the proposed text for the draft.   The goal is make the IPv6-Only flag more robust by not turning off IPv4 if the host has active IPv4 connections.   I think this makes sense given the operational experience at IETF 101 in Singapore that caused this draft to be proposed at IETF 101 in Singapore.  That is, a new link that was IPv6-Only.   As dual stack hosts connected to it, they tried to discover IPv4 services that didn’t exist on this link.  The goal of the draft is tell the hosts to stop trying to find IPv4 resources in IPv6-Only environments.

Suresh asked a few people to come up with text to address this issue and propose it to the working group.   People involved in this included Lorenzo Colitti, Ian Farrer, Mikael Abrahamsson, and myself, and it was reviewed by Brian Carpenter.

The text is to replace the second paragraph in Section 7. "Host Behavior Considerations”.   The current and proposed text is:

   CURRENT 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.

   /OLD TEXT

   PROPOSED TEXT *********************

   A host that receives only RAs with the flag set to 1 SHOULD NOT
   attempt any further IPv4 operations.  If IPv4 configuration has
   already been obtained from the network (e.g., via DHCP), the flag can
   be ignored and IPv4 operations can continue.  The host MAY implement
   a policy overriding these default behaviours.

   In the event that the host subsequently receives at least one RA with
   the flag set to zero IPv4 operations MAY be started.

   /PROPOSED TEXT

Please review and comment on this change.

If there is agreement on this text, I think some similar text should go into Section 3. "Applicability Statement" too.

Thanks,
Bob

---

From: Jen Linkova <[email-masked]>
Date: Thu, 8 Nov 2018 16:46:48 +1100

Hi Bob,

>    the flag set to zero IPv4 operations MAY be started.

I suggest that the static IPv4 configuration should be covered as well.
Shall we say ' If IPv4 configuration has already been obtained (e.g.
via static configuration or from the network via DHCP),'
?

-- 
SY, Jen Linkova aka Furry

---

From: David Farmer <[email-masked]>
Date: Thu, 8 Nov 2018 00:27:23 -0600

I like this and think this is close, but at least to me, it is ambiguous if
the terms "IPv4 operations" and "IPv4 configuration" are intended to
include IPv4 Link-Local and that has been a big part of the discussion at
least on the email list.

Maybe use the terms "routed IPv4 operations" and "routed IPv4
configuration", and then add something like the following;

This flag does not speak to a host configuring or using of an IPv4
Link-Local address [RFC3927]. However, it is RECOMMENDED that dual-stack
hosts implementing this flag also implement [RFC2563], which provides a
DHCPv4 option to signal that an IPv4 link-local address MUST NOT be
generated.

On Wed, Nov 7, 2018 at 9:51 PM Bob Hinden <[email-masked]> wrote:

> Hi,
>
> Based on the discussion during the 6man session in Bangkok on Tuesday,
> here is the proposed text for the draft.   The goal is make the IPv6-Only
> flag more robust by not turning off IPv4 if the host has active IPv4
> connections.   I think this makes sense given the operational experience at
> IETF 101 in Singapore that caused this draft to be proposed at IETF 101 in
> Singapore.  That is, a new link that was IPv6-Only.   As dual stack hosts
> connected to it, they tried to discover IPv4 services that didn’t exist on
> this link.  The goal of the draft is tell the hosts to stop trying to find
> IPv4 resources in IPv6-Only environments.
>
> Suresh asked a few people to come up with text to address this issue and
> propose it to the working group.   People involved in this included Lorenzo
> Colitti, Ian Farrer, Mikael Abrahamsson, and myself, and it was reviewed by
> Brian Carpenter.
>
> The text is to replace the second paragraph in Section 7. "Host Behavior
> Considerations”.   The current and proposed text is:
>
> If there is agreement on this text, I think some similar text should go
> into Section 3. "Applicability Statement" too.
>
> Thanks,
> Bob
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
===============================================
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: Sander Steffann <[email-masked]>
Date: Thu, 8 Nov 2018 10:25:36 +0100

Hi Bob,

> Based on the discussion during the 6man session in Bangkok on Tuesday, here is the proposed text for the draft.

Thanks, this update helps a lot for me.

>   the flag set to zero IPv4 operations MAY be started.

The new text does cause a race condition though. When the RA is received before DHCPv4 is tried then it can still cause problems. How about:

  A host that receives only RAs with the flag set to 1 SHOULD NOT
  attempt any further IPv4 operations.  If IPv4 configuration has
  been obtained (e.g. via static configuration or from the network
  via DHCP), the flag can be ignored and IPv4 operations can continue.
  If this flag is received before the host has tried to obtain IPv4
  configuration it is RECOMMENDED to try at least once to confirm
  that there is indeed no IPv4 on the network.  The host MAY implement
  a policy overriding these default behaviours.

  /PROPOSED TEXT

The "RECOMMENDED" is debatable. SHOULD or MAY can be used as well, depending on how strongly people feel about this.

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 8 Nov 2018 09:41:09 +0000

Sander Steffann wrote on 08/11/2018 09:25:
> The new text does cause a race condition though. When the RA is
> received before DHCPv4 is tried then it can still cause problems. How
> about:
... or when a DHCP server is temporarily offline (e.g. cpe rebooting). 
This allows a window where a dhcp service outage can be used a malicious 
actor to wedge the process for configuring ipv4.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Thu, 8 Nov 2018 10:46:30 +0100

Hi Jen,

> via static configuration or from the network via DHCP),'?

Yep, makes sense.

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 8 Nov 2018 10:52:43 +0100

Hi,

> Op 8 nov. 2018, om 10:41 heeft Nick Hilliard <[email-masked]> het volgende geschreven:
> 
> ... or when a DHCP server is temporarily offline (e.g. cpe rebooting). This allows a window where a dhcp service outage can be used a malicious actor to wedge the process for configuring ipv4.

That window is extremely small though. It would only affect devices that are new to the network and haven't seen the DHCPv4 server already.

If we want to address this edge case, how about:

 A host that receives only RAs with the flag set to 1 SHOULD NOT
 attempt any further IPv4 operations. If IPv4 configuration has
 been obtained (e.g. via static configuration or from the network
 via DHCP), the flag can be ignored and IPv4 operations can continue.
 If this flag is received before the host has tried to obtain IPv4
 configuration it is RECOMMENDED to try at least once to confirm
 that there is indeed no IPv4 on the network.  The host MAY implement
 a policy overriding these default behaviours, for example if it
 has remembered that IPv4 has been available on the network before.

 /PROPOSED TEXT

Still wouldn't solve it completely for new hosts that have not been connected to that network before and try their DHCPv4 request during the window that the DHCPv4 server is not available. That's the reason I put in "try at least once" to not prevent the host from retrying completely.

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 8 Nov 2018 10:05:56 +0000

Sander Steffann wrote on 08/11/2018 09:52:
> Still wouldn't solve it completely for new hosts that have not been
> connected to that network before and try their DHCPv4 request during
> the window that the DHCPv4 server is not available. That's the reason
> I put in "try at least once" to not prevent the host from retrying
> completely.
this highlights the primary problem with Bob's suggested update: the 
text is now weakened to the point that I question whether it would be 
worth implementing, all other practical concerns put aside.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Nov 2018 17:08:34 +0700

> worth implementing, all other practical concerns put aside.

Even if the only thing this flag does is reduce the DHCPv4 backoff or
retransmit timers, it will save enough power to have been worth
implementing.

---

From: Sander Steffann <[email-masked]>
Date: Thu, 8 Nov 2018 11:12:36 +0100

Hi Nick,

> this highlights the primary problem with Bob's suggested update: the text is now weakened to the point that I question whether it would be worth implementing, all other practical concerns put aside.

Yep, I feel exactly the same. I still strongly feel this flag is not needed. That objection still stands. But if it goes forward it needs to be at least not harmful.

I still think that the benefit/cost+risk ratio is bad for this draft, and just dropping it would be my preferred option. When someone can show realistic use cases where this flag will provide a significant benefit over alternative solutions I will withdraw this objection.

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 8 Nov 2018 11:15:48 +0100

Hi Lorenzo,

> Even if the only thing this flag does is reduce the DHCPv4 backoff or retransmit timers, it will save enough power to have been worth implementing.

That is useful information coming from an implementer. I would be perfectly happy with that.

Thanks!
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2018 11:16:11 +0100 (CET)

> worth implementing, all other practical concerns put aside.

I was involved in trying to put together this text. It's on purpose weak, 
because I do not think we'll get consensus on any strongly typed text.

The device vendors will evolve their response to this signal over time as 
they see fit. I have talked to some of the major ones and this is the 
compromise I see will work to get through the IETF consensus progress.

This is why we need weak next to allow for this. If you own the device and 
can hit the vendor over the head, get them to implement policy for 
behaviour that you need. If it's BYOD, just accept that vendor will make 
the device behave in a way vendor sees best fit the interests of 
customers, vendor and network operation together (which are not aligned).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Nov 2018 17:17:53 +0700

For the record, that was my view when the draft was first filed, and I have seen nothing to change my view. If a device has no IPv4 address, it's not going to do much with IPv4 besides periodically request one or concoct an IPv4 link-local address (169.254.0.0/16). We can make recommendations about the period of such a timer. I don't see the point of commenting further in an IPv6 message, or consuming a bit in one, about IPv4.

But my view doesn't seem to have affected much, so it simply remains my view.

> On Nov 8, 2018, at 5:12 PM, Sander Steffann <[email-masked]> wrote:
> 
> Hi Nick,
> 

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

---

From: Ola Thoresen <[email-masked]>
Date: Thu, 8 Nov 2018 11:21:55 +0100

> That is useful information coming from an implementer. I would be perfectly happy with that.

But is there anything preventing the vendors from doing that already?

If the device has got IPv6, and it has not received response to a couple 
of DHCPv4-requests, and it considers the IPv6 routes and network info to 
be "good enough" to function - can't it just back off or slow down 
further DHCPv4 requests without requiring a whole new flag in RAs?

If you want to save power on _all_ networks - that is definitely what 
_I_ would do if I were a vendor, as you can not (at least not for a long 
time) trust that ALL routers will have this flag correctly implemented.

/Ola (T)

---

From: Ole Troan <[email-masked]>
Date: Thu, 8 Nov 2018 17:23:38 +0700

Fred,

While I might share your view, the observation that triggered this was that some IPv4 hosts are very chatty, even without getting a global IPv4 address. Typically caused by mdns and other service discovery traffic. 

If those hosts had been better behaved, this might never have been necessary. 

Cheers,
Ole

> On 8 Nov 2018, at 17:17, Fred Baker <[email-masked]> wrote:
>

---

From: Ola Thoresen <[email-masked]>
Date: Thu, 8 Nov 2018 11:26:36 +0100

> If those hosts had been better behaved, this might never have been necessary.

But do you believe these hosts would behave better if this flag was sent?

These hosts should already behave better, but their vendors obviously 
don't care about power saving or network usage.  Why would that change 
if the flag was implemented in a few (or even a lot, but not all) of 
networks?

/Ola (T)

---

From: Ole Troan <[email-masked]>
Date: Thu, 8 Nov 2018 17:32:40 +0700

> On 8 Nov 2018, at 17:26, Ola Thoresen <[email-masked]> wrote:
> 
> These hosts should already behave better, but their vendors obviously don't care about power saving or network usage.  Why would that change if the flag was implemented in a few (or even a lot, but not all) of networks?

What one would hope was that this flag could make behavior testable and make it into compliance tests like the IPv6 ready logo. 

This flag is to prepare us for the future, perhaps 5-10 years down the line. And as we all know predicting the future is hard. :-)

Is the ROI here worth it? Well, that’s what I want the working group’s opinion on. 

Cheers 
Ole

---

From: Bob Hinden <[email-masked]>
Date: Thu, 8 Nov 2018 17:34:58 +0700

Ola,

> On Nov 8, 2018, at 5:26 PM, Ola Thoresen <[email-masked]> wrote:
> 

That’s not correct, they behave this way because they are expecting to be on an IPv4 capable link where this is reasonable behavior.   The point here is to tell them they are not (that is, an IPv6-Only link) and get them to stop.  Yes, I expect them implement this correctly.

Bob

---

From: Ola Thoresen <[email-masked]>
Date: Thu, 8 Nov 2018 11:38:28 +0100

> This flag is to prepare us for the future, perhaps 5-10 years down the line. And as we all know predicting the future is hard. :-)

Hopefully, 5-10 years from now, most vendors will behave this way 
already, flag or no flag. Simply because it is the most effective way.

> Is the ROI here worth it? Well, that’s what I want the working group’s opinion on.

In my mind, no.  There are so many more pressing issues getting IPv6 to 
actually work smoothly in a real world that should be prioritized.

/Ola (T)

---

From: Sander Steffann <[email-masked]>
Date: Thu, 8 Nov 2018 11:47:48 +0100

Hi,

> Hopefully, 5-10 years from now, most vendors will behave this way already, flag or no flag. Simply because it is the most effective way.

That is my feeling as well, but I'm not a vendor. Lorenzo says it will help. We haven't heard from other vendors yet.

> In my mind, no.  There are so many more pressing issues getting IPv6 to actually work smoothly in a real world that should be prioritized.

+1

Cheers,
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Nov 2018 17:56:27 +0700

> But is there anything preventing the vendors from doing that already?

The fact that it's possible (though perhaps unlikely) that IPv4 will
actually start working after a while.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 08 Nov 2018 12:28:03 +0100

>    Even if the only thing this flag does is reduce the DHCPv4
>    backoff or retransmit timers, it will save enough power to have
>    been worth implementing.

Given that most unmanaged networks are unlikely to set this flag, it may
make sense to backoff DHCPv4 in any case, once a global IPv6 address is
configured.

Or do you assume that hosts will continue to burn power just because the
flag was not set?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Nov 2018 18:34:38 +0700

> Or do you assume that hosts will continue to burn power just because the

Hosts already do exponential backoff. The flag could be used as a hint to
increase the maximum backoff interval.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 08 Nov 2018 12:44:45 +0100

>    Hosts already do exponential backoff. The flag could be used as
>    a hint to increase the maximum backoff interval.

Does that give realworld power savings, or is the difference left in the 
noise?

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 08 Nov 2018 13:19:26 +0000

On 8 Nov 2018, at 3:51, Bob Hinden wrote:

> Suresh asked a few people to come up with text to address this issue 
> and propose it to the working group.   People involved in this 
> included Lorenzo Colitti, Ian Farrer, Mikael Abrahamsson, and myself, 
> and it was reviewed by Brian Carpenter.
>
> The text is to replace the second paragraph in Section 7. "Host 
> Behavior Considerations”.   The current and proposed text is:
>

As others said the “configuration” and “obtained from network” 
doesn’t sound like a good idea.

(a) It doesn’t matter how I got working, routed IPv4, what matters is 
that I do have “working non-link-local-only IPv4”.  So to do this 
without any probing the best I can think of doing is (i) check if I have 
a non-link-local, specified (not 0/0) IPv4 address in the interface of 
that link, and (ii) an IPv4 default route. Worst I could possibly check 
(iii) that I do have a valid entry in the ARP table for the IPv4 default 
gateway address.  (That’s a lot of checking already).   Everything 
beyond that sounds like piling up hacks and heuristics to me.  And yes, 
if you care about routed IPv4 multicast you better speak up now.

(a2) now there will be people who say I have IPv4, I have DHCP working, 
but I have no default gateway as I am on a secure living island not 
talking to the outside world using L3 forwarding.  Touché.  So really 
all I can do is to check if I have a non-link-local, specified IPv4 
address on the interface on that link.  Does that sound simple and 
non-ambiguous enough to people?  And we all know what a link, and 
interface, and an IPv4 non-link-local, specified IPv4 address is?  Maybe 
that’s just it?

(b) Can we please add 0x8035 (RFC 903) to all the places where we 
“filter” IPv4 or ARP, just to rule that out as well.  Hope no one 
comes and says “FrameRelay”(*). Thanks.  (*) Don’t worry if you 
don’t get this ;-)

/bz

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Nov 2018 21:50:13 +0700

> Does that give realworld power savings, or is the difference left in the

It depends on the numbers. IIRC RFC 7772 says a wake-up every 7 minutes
costs 2% of battery in steady state.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 08 Nov 2018 16:02:39 +0100

>costs 2% of battery in steady state.

To quote from the RFC:
"An impact of 2% relative to measured idle current is negligible,
"since on this sort of device average power consumption is
"typically much higher than idle power consumption.

This suggests that allowing the DHCP timeout to increase to 10 minutes while
the device is idle, would take care of any power issues related to DHCPv4.

Though sending a packet may be more expensive than receiving one.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 8 Nov 2018 15:48:08 +0000

> costs 2% of battery in steady state.

I'm not sure if I understand why an explicit wake-up is necessary for 
egress frames.  CPU wakeups will drain battery to some degree - we get 
that.  But if outgoing dhcp requests are queued to be handled if and 
only only when the cpu is already awake for any other reason, then the 
battery drain would be marginal and nothing near what's quoted in that 
rfc.   Most phones these days perform background tasks.  By way of 
anecdote, the mobile devices in my household seem to issue between 10 
and 100 dns requests per hour each, during periods where I know they're 
not being used, and this doesn't include consequent ip conversations. 
So background chatter seems pretty normal.

For ingress frames towards the device, ipv4 will not be configured due 
to there being no replies to dhcp requests, so this would mean that the 
wifi microcontroller can drop everything unconditionally and there would 
be no requirement to wake the main processor.

Incidentally, it would be great to see RFC 7772 updated for how this is 
handled in silicon from the last couple of years, along with a 
reasonable sample of measurements.  The language used for the numbers 
provided in the document is a little vague, and there are no references 
given.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Nov 2018 08:51:13 +1300

On 2018-11-09 00:28, Philip Homburg wrote:
> Given that most unmanaged networks are unlikely to set this flag, 

That's a reasonable assumption today. But 10 years from now, who knows?

> it may

I agree. I expect to see this heuristic take over some years from now.

> Or do you assume that hosts will continue to burn power just because the

Those are the ones that would benefit from the flag. I fully agree that it's
a judgment call whether this is enough to justify the proposal. Ole's message
<https://mailarchive.ietf.org/arch/msg/ipv6/WA2Mi2GbR2IPyL9cS5g5aaFODjY>
is exactly right.

   Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 8 Nov 2018 19:52:41 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Nick Hilliard

Perhaps, it should be weaker still. Many exceptions and qualifications in the proposed text. If we do a (1 - text cases) operation, I think a clearer picture emerges. Which is, "this router won't route IPv4." Full stop. And there are other ways for a modern dual stack host to obtain that same info, as already discussed, to allow itself to save power.

The problem I see is that the flag came as a result of legacy IPv4 hosts being chatty, in an IETF meeting in Singapore, and people wanting to run an experiment. Let's have the network stop all IPv4 traffic. As a result of this desire for an experiment, we are now potentially giving a net admin way too much authority. And there are draconian ways of carrying out such a one-off experiment anyway, which need no flag. Use managed switches, block IPv4 and ARP Ethertypes.

In the real world, in general, a net admin has no business telling hosts what protocols to run, if the net admin's equipment is unaffected. Even the new text has to worry about IPv4 already set up internally, statically or otherwise, or heaven forbid, someone installs a new IPv4-only box in his LAN. If this is an enterprise net, that's a special case that should not put all other networks in jeopardy (potentially, depending how vendors interpret this flag). The enterprise net IT, and the security guards at the entrances to the office space, can be responsible for what people are allowed to bring into the office networks.

The main issue with me is that equipment vendors can use this new flag to give net admins a power they were never supposed to have. Just like that "do not copy" flag in TV broadcasts, when the Supreme Court had already previously decided that home equipment can always be used for time shift recording.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Nov 2018 11:05:35 +1300

On 2018-11-09 08:52, Manfredi (US), Albert E wrote:
> The main issue with me is that equipment vendors can use this new flag to give net admins a power they were never supposed to have.

Bert, they have the power to provide no IPv4 services, and they have the power to actively block IPv4 packets with L2 filters. The flag doesn't add to these powers; it's an announcement.

    Brian

> Just like that "do not copy" flag in TV broadcasts, when the Supreme Court had already previously decided that home equipment can always be used for time shift recording.
> 
> Bert
>

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 8 Nov 2018 23:05:28 +0000

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

> Bert, they have the power to provide no IPv4 services, and they have the power to actively block IPv4 packets with L2 filters. The flag doesn't add to these powers; it's an announcement.

Brian, yes indeed, but in that case, the equipment vendor is not a co-conspirator. Where the vendor potentially does more harm with the way he interprets the flag, than even the net admin had intended. (And parenthetically, a user can still bring his own switch, and the user's equipment would work just fine with IPv4, in such a case.)

Perhaps another way to solve this issue, in my fevered brain anyway, would be to rename the flag. So that there are no misunderstandings possible. The new name would be, "no IPv4 routed here flag."

Bert

---

From: 神明達哉 <[email-masked]>
Date: Thu, 15 Nov 2018 11:48:49 -0800

At Thu, 8 Nov 2018 11:47:48 +0100,
Sander Steffann <[email-masked]> wrote:

> >> This flag is to prepare us for the future, perhaps 5-10 years down the
line. And as we all know predicting the future is hard. :-)
>
> That is my feeling as well, but I'm not a vendor. Lorenzo says it will
help. We haven't heard from other vendors yet.

Same here.  Personally I've never been convinced it's worth doing this
particular way and today.  I don't have a strong objection to the
proposal or find critical technical errors in it either, and so I
abstained in the WGLC.  But if the WG is also checking the view about
its ROI, I can say it doesn't seem to worthwhile.

--
JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Fri, 16 Nov 2018 08:45:01 +0100

Jinmei,

> its ROI, I can say it doesn't seem to worthwhile.

If I can try to state the authors’ intent, it is to prepare for the IPv4 end-game.
Would it be valuable to have this implemented in stacks, say 5 years from now?

As a consensus calling chair, I would certainly prefer a resounding ‘yes’ answer to that from the working group.
As opposed to what I read now which is a ‘perhaps in some scenario’ or ‘probably not’.

Best regards,
Ole

---

From: Fred Baker <[email-masked]>
Date: Thu, 15 Nov 2018 23:56:44 -0800

> On Nov 15, 2018, at 11:45 PM, Ole Troan <[email-masked]> wrote:
> 

From my perspective, something I expressed quite a long time ago but seems to have been lost in the desire to pursue the draft, the fact that the device attempted to obtain an IPv4 address and failed, and has never heard an ARP request from another device that actually has an assigned IPv4 address, seems like a big hint. The fact that some IPv6-only router - or all of the IPv6-only routers on a LAN - have no IPv4 address or think that they should send the flag, doesn't mean that there are no IPv4-capable routers (or for that matter, devices) on the LAN. I would far rather that IPv4-capability be derived from (lack of) IPv4 things than from IPv6-capable things or IPvFuture-capable things. Don't cross the streams.

There seems, IMHO, to be a place for exponential backoff, perhaps with a drop-dead threshold.

---

From: Ole Troan <[email-masked]>
Date: Fri, 16 Nov 2018 10:01:08 +0100

Fred,

> There seems, IMHO, to be a place for exponential backoff, perhaps with a drop-dead threshold.

Let me clear up the misconception you have about the mechanism, because I think it will distract from your main point:
 - IPv6 only routers do not autonomously set this flag. It is a configuration flag. The operator of the link decided to set this flag and by doing so, asserts that this is an IPv6 only link.
 - There are by definition no IPv4 only routers on that link. If there were, that would be a configuration error.

Now to your main point.
Yes, I think many people are uncomfortable about the “crossing of the streams” that this draft proposes.

Many of todays stacks do generate quite a bit of IPv4 traffic even without a global IPv4 address. mDNS and friends are the typical culprits.
mDNS is an unfortunate experiment that escaped, I don’t know if it can be reined in with better implementations, ongoing work in dnssd or if we need a recommendation from the IETF on “IPv4 link-local behaviour on IPv6 only links” document.

Cheers,
Ole

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 16 Nov 2018 10:32:35 +0000

On 16 Nov 2018, at 7:45, Ole Troan wrote:

> As a consensus calling chair, I would certainly prefer a resounding 
> ‘yes’ answer to that from the working group.

 From a developer, admin, and user, you get my “yes!”  (and you’d 
have gotten it 5 years ago).

/bz

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 16 Nov 2018 12:03:31 +0100

Le 16/11/2018 à 11:32, Bjoern A. Zeeb a écrit :
>  From a developer, admin, and user, you get my “yes!”  (and you’d have 
> gotten it 5 years ago).

HEre is one from me too.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 16 Nov 2018 11:43:20 +0000

Ole Troan wrote on 16/11/2018 09:01:
> Many of todays stacks do generate quite a bit of IPv4 traffic even
> without a global IPv4 address. mDNS and friends are the typical
> culprits.
> mDNS is an unfortunate experiment that escaped, I don’t know if it
> can be reined in with better implementations, ongoing work in dnssd
> or if we need a recommendation from the IETF on “IPv4 link-local
> behaviour on IPv6 only links” document.
then this would involve a wider discussion about zeroconf services, 
which falls outside the scope of 6man.

For better or worse, vendors made a decision that zeroconf was useful 
over either ipv4 or ipv6; users either like the functionality that it 
provides, and probably don't notice that it's been enabled.  RFC2563 
provides a mechanism that can be used to disable the mechanism for ipv4, 
except that most vendors don't seem to have thought that this was 
interesting enough to implement in their ipv4 stacks.

If ipv4 mdns chatter were to quieten due to RFC2563 deployment, and dhcp 
requests were to back off, there would be very little background ipv4 
chatter left to get concerned about.  If we're looking for network noise 
reduction wins, this is likely to be a better approach to take, but 
again this is not a 6man issue.

Regarding the ipv6only-flag, although it's been pitched as being an 
ipv6-related protocol, all the discussion has been about its impact, 
which relates exclusively to ipv4 chatter.  On a procedural point of 
view, it's not clear whether this is inside the scope of 6man to start with.

Nick

---

From: Ole Troan <[email-masked]>
Date: Fri, 16 Nov 2018 12:50:41 +0100

Nick,

> then this would involve a wider discussion about zeroconf services, which falls outside the scope of 6man.

Yes.

> 
> For better or worse, vendors made a decision that zeroconf was useful over either ipv4 or ipv6; users either like the functionality that it provides, and probably don't notice that it's been enabled.  RFC2563 provides a mechanism that can be used to disable the mechanism for ipv4, except that most vendors don't seem to have thought that this was interesting enough to implement in their ipv4 stacks.
> 
> If ipv4 mdns chatter were to quieten due to RFC2563 deployment, and dhcp requests were to back off, there would be very little background ipv4 chatter left to get concerned about.  If we're looking for network noise reduction wins, this is likely to be a better approach to take, but again this is not a 6man issue.
> 
> Regarding the ipv6only-flag, although it's been pitched as being an ipv6-related protocol, all the discussion has been about its impact, which relates exclusively to ipv4 chatter.  On a procedural point of view, it's not clear whether this is inside the scope of 6man to start with.

I don’t see a problem doing ipv6-only here, “what to do with other residual IPv4 chatter” that I think would not.

Cheers,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 16 Nov 2018 12:18:01 +0000

Ole Troan wrote on 16/11/2018 11:50:
> I don’t see a problem doing ipv6-only here, “what to do with other
> residual IPv4 chatter” that I think would not.
These might be two separate issues in theory, but it doesn't seem to be 
nearly as clear-cut in practice.

Nick

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 16 Nov 2018 12:34:32 +0000

On 16 Nov 2018, at 7:56, Fred Baker wrote:

> I would far rather that IPv4-capability be derived from (lack of) IPv4 
> things than from IPv6-capable things or IPvFuture-capable things. 
> Don't cross the streams.

Can you write the code which tells you when you have the no IPv4 
“thing” without trying the IPv4 thing on a network which by 
definition should not have the IPv4 thing where you want people not to 
try the IPv4 thing?

I think the worst bit of crossing these streams which regularly bothers 
me is IPv4-mapped addresses.  Clever idea.  Massive pain.  So happy when 
IPv4 is gone.

And you should be aware that the draft doesn’t cross the streams.  It 
only says “I am IPv6 and I am the only IP version here”;  IPv4 is 
just a predominant example;  we should probably add a sentence “If any 
other IP version has a similar claim, this is also a configuration 
error, as by definition there is no other version in use on this link, 
and all such claims SHOULD be ignored and logged.”

/bz

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 16 Nov 2018 14:14:50 +0000

On 16 Nov 2018, at 14:09, Philip Homburg wrote:

>> thing without trying the IPv4 thing on a network which by definition
>> should not have the IPv4 thing where you want people not to try
>> the IPv4 thing?
>
> Just filter ethernet packet types 0x800 and 0x806. Problem solved. If you
> care about your network you already have L2 equipment with RA-guard. So
> filters for IPv4 and ARP are just a tiny extension.
>
> There are plenty of ways to deal with these problems without the need to
> introduce a new flag.

And you did read the draft?

“The remainder of this document therefore assumes that neither
   effective Layer 2 filtering nor the RFC 2563 DHCP option is
   applicable to the link concerned.”

/bz

---

From: Philip Homburg <[email-masked]>
Date: Fri, 16 Nov 2018 15:09:51 +0100

---

From: Philip Homburg <[email-masked]>
Date: Fri, 16 Nov 2018 15:30:37 +0100

> The remainder of this document therefore assumes that neither
>    applicable to the link concerned.

I'm strongly opposed to this problem statement. The draft solves a tiny
niche problem while creating complexity everywhere.

This draft is highly disruptive in networks without RA-guard. So the future
is in buying equipment with RA-guard and L2 filtering. Not creating new
protocol flags for networks that that rely on overly cheap equipment.

Because the L2 issues can be solved with RFC 2563, the draft has to go out of
its way to also assume that no DHCP-capable router is available either.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 16 Nov 2018 15:03:17 +0000

> From: Fred Baker <[email-masked]>
>
> From my perspective, something I expressed quite a long time ago but
> seems to have been lost in the desire to pursue the draft, the fact that the
> device attempted to obtain an IPv4 address and failed, and has never heard
> an ARP request from another device that actually has an assigned IPv4
> address, seems like a big hint. The fact that some IPv6-only router - or all of
> the IPv6-only routers on a LAN - have no IPv4 address or think that they
> should send the flag, doesn't mean that there are no IPv4-capable routers
> (or for that matter, devices) on the LAN. I would far rather that IPv4-
> capability be derived from (lack of) IPv4 things than from IPv6-capable things
> or IPvFuture-capable things. Don't cross the streams.
> 

I am usually worried about autonomous/decentralized "stand down" / "kill yourself" behaviors, because some unforeseen circumstances could lead to the entire network "standing down".

For example, if there is a power outage and the v4 NAT device does not come back within the "drop-dead" threshold, we'd need to restart every single device again, once the NAT is repaired/brought online.  (If that NAT sends a gratuitous ARP upon startup, things could possibly get unstuck, unless some smart switch/bridge already "stood down" v4, or that grat-arp simply got dropped due to congestion/radio interference.)

- Igor

---

From: 神明達哉 <[email-masked]>
Date: Fri, 16 Nov 2018 09:26:34 -0800

At Fri, 16 Nov 2018 08:45:01 +0100,

> As opposed to what I read now which is a ‘perhaps in some scenario’ or
‘probably not’.

In fact, I think I can only say "perhaps" to the above question.  It's
not clear (to me) how much it helps the host devices in terms of
energy saving (or other touted benefits), not least because it gives
the hosts quite a lot of leniency (but if it doesn't it could be
overkilling).  I also don't see this as an urgent matter; if the
expected time frame is 5-10 years from now, it seems to me that we can
still have time to understand the problem and assess whether a
dedicated protocol is really necessary or it can be sufficiently
addressed through operational practices.

It seems to me that we're jumping to the protocol based solution for a
relatively longer term problem based on a lot of speculation (where
one can easily make an argument for them that others cannot definitely
deny; I guess that's one reason why we've seen such a long and not so
productive discussion threads).  If this is an urgent and critical
issue, we may have to make a decision and give it a try anyway, but I
don't think it's the case here.  Since introducing any new protocol
has its own cost and risk, I don't think the expected return is
sufficiently substantial for the cost and risk.  This is the base of
my answer to the ROI question.

I understand this is more or less a subjective opinion and others can
validly have totally different views.  I just gave mine as I thought
you (as a a consensus calling chair) sought it.

btw: I nevertheless still believe in the spirit of respecting running
code, and I appreciate Bjoern's effort very much.  Experiments with
running code may hopefully provide data points for more constructive
discussions, and I see some chicken&egg situation: if we want to have
more solid evidences before publishing the protocol it's less likely
to have useful experiments that may provide the evidences.  It may
make sense to publish the protocol if only to facilitate this process.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Nov 2018 08:33:00 +1300

> Nick,

<snip>

> I don’t see a problem doing ipv6-only here, “what to do with other residual IPv4 chatter” that I think would not.

As far as I can tell, only 6man is competent to assign a bit in the RA message.
So we could have submitted a short draft assigning the bit and stating its
meaning and the processing rules. Most of what people have been discussing
here would be out of scope for such a draft (and would probably belong in
v4ops if such a WG existed). But that would have been a bit artificial.

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 16 Nov 2018 11:34:20 -0800

Philip,

> On Nov 16, 2018, at 6:09 AM, Philip Homburg <[email-masked]> wrote:
> 

This is discussed in the draft:

   In networks with managed infrastructure whose equipment allows it,
   these problems could be mitigated by configuring the Layer 2
   infrastructure to drop IPv4 and ARP traffic by filtering Ethertypes
   0x0800 and 0x0806 [IANA-Ethertype].  IPv6 uses a different Ethertype,
   0x86DD, so this filtering will not interfere with IPv6 traffic.
   Depending on the equipment details, this would limit the traffic to
   the link from an IPv4 sender to the switch, and would drop all IPv4
   and ARP broadcast packets at the switch.  This document recommends
   using such mechanisms when available.

Not all environments have this L2 capability.

Bob

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 16 Nov 2018 19:50:05 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Fred Baker

> There seems, IMHO, to be a place for exponential backoff, perhaps with a drop-dead threshold.

Fully concur. Any host which was updated to read this new flag can just as easily have been updated to make better decisions on whether to use IPv4 at all.

Plus, I'll say again, it is none of the net admin's business (in most cases, aside from enterprise nets) whether users on a given link might need to use IPv4, for local purposes. So from my perspective, it would be less objectionable to me if the flag were renamed "no IPv4 routed here." That also solves the problem of some other router still routing IPv4.

Bert

---

From: Simon Hobson <[email-masked]>
Date: Fri, 16 Nov 2018 20:01:09 +0000

Bjoern A. Zeeb <[email-masked]> wrote:

> Can you write the code which tells you when you have the no IPv4 “thing” without trying the IPv4 thing on a network which by definition should not have the IPv4 thing where you want people not to try the IPv4 thing?

We've been here before - I don't think there is any way to write an algorithm that can differentiate between "I can see IPv4 chatter and I should join in because this network is completely IPv6 only yet" and "I can see IPv4 chatter and I shouldn't join in because this network is supposed to be IPv6 only but some other nodes don't understand that". If a key part of the algorithm is "there aren't other IPv4 nodes chattering" then you only need one device on the network to prevent everything else shutting down IPv4.

---

From: Simon Hobson <[email-masked]>
Date: Fri, 16 Nov 2018 20:55:43 +0000

I wrote:

> We've been here before - I don't think there is any way to write an algorithm that can differentiate between "I can see IPv4 chatter and I should join in because this network is completely IPv6 only yet" ...

Oops, that should say "this network is **not** completely IPv6 only yet"

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Nov 2018 10:11:33 +1300

> We've been here before - I don't think there is any way to write an algorithm that can differentiate between "I can see IPv4 chatter and I should join in because this network is completely IPv6 onl…

Which is exactly why the semantics of the flag are defined as: it is the
aministrator's intention that no IPv4 services are supported on this link,
specifically including IPv4 routing and IPv4 address assignment.

In what way does that prevent unsupported link-local services from operating?

   Brian

---

From: Lee Howard <[email-masked]>
Date: Fri, 16 Nov 2018 16:46:57 -0500

> In what way does that prevent unsupported link-local services from operating?

Because the unsupported link-local services are using link-local IPv4, 
which some devices have disabled because the router told them there was 
only IPv6?

Your point is, "Yes, the administrator can shoot herself in the foot 
with this flag."

My point is, if we expect the administrator to know for certain that 
nothing on the network is dependent on IPv4, then the administrator can 
disable IPv4 on each host, since they've had to watch packet traces for 
a while to be sure of it. Either that, or the administrator wants to 
turn off IPv4 from the router because they're curious about what breaks, 
but don't actually have the ability to fix it.

Lee

---

From: Simon Hobson <[email-masked]>
Date: Fri, 16 Nov 2018 22:24:47 +0000

Lee Howard <[email-masked]> wrote:

> Your point is, "Yes, the administrator can shoot herself in the foot with this flag."

A network administrator can do many things that will break stuff, if that were a reason for not allowing a feature then we'd never have got as far as IPv4 !
The point of this flag is that where a network has made the transition to IPv6, no IPv4 services are provided (and presumably some transition mechanism is in place for those remaining IPv4 services, eg IPv4 only web sites), and the admin wishes to reduce the chatter from IPv4 - then he can set this flag and many hosts will STFU. Yes you can filter IPv4 packets - but that won't prevent devices from self assigning a link-local address and still broadcasting ARP and mDNS packets. It's a signal "please don't IPv4 here" - a bit like the signs saying "no smoking please" - some devices(people) will ignore it or not know what it means, but if most devices(people) do obey it then it makes the air(airwaves) cleaner for everyone.

> My point is, if we expect the administrator to know for certain that nothing on the network is dependent on IPv4, then the administrator can disable IPv4 on each host, since they've had to watch packet traces for a while to be sure of it. Either that, or the administrator wants to turn off IPv4 from the router because they're curious about what breaks, but don't actually have the ability to fix it.

So the administrator can turn off IPv4 on each host can he ? Will that really work on a network where, say, several thousand people bring their own devices to some event and connect them to the event provided WiFi ? It may work for, say, a corporate network where many (but not all) devices are managed - but not in the general case.

There is one other thing that hasn't been mentioned ...
All the talk about airtime being used by wasted packets appears to be discussing large networks in isolation - eg some major sports event or conference. In many places there are a lot of networks in close proximity - if even a small proportion of these actually "turned off" IPv4 when it was no longer in use, then that would free up bandwidth for other users as well as themselves. I vaguely recall a report from a good few years ago now where they estimated that something like 95% of available bandwidth was taken up by signalling/handshaking in some densely populated areas - and since then, while available bandwidth has gone up, so has the ubiquity of WiFi.
Obviously for this flag to make a significant difference, it would need some automation - otherwise few networks will set it.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 16 Nov 2018 22:28:17 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Lee Howard

with this flag."

In large measure, because the flag is given a presumptuous name. It assumes that a net admin knows everything that can ever operate in that link, and has the authority to block anything else.

Your first example only makes sense in an enterprise network, where this admin can make such decisions for hosts. As to the experiment example, the net admin can simply disable IPv4 in the router she controls. Disable DHCPv4, disable IPv4-formated DNS, disable IPv4 packet routing, and see what breaks/who hollers.

But, change the name of the flag, and the effect, and the intent, become more sensible (IMO).

Bert

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 16 Nov 2018 23:05:30 +0000

Simon Hobson wrote on 16/11/2018 22:24:
> Obviously for this flag to make a significant difference, it would
> need some automation - otherwise few networks will set it.

which brings up an interesting point: who's the administrator of these 
networks?  And what does that even mean?

In the case of e.g. docsis or TR069 CPEs, the service provider would 
have more control over the router settings than the customer, but would 
not be inclined to configure a setting like this because it would break 
grandpa's printer, the heating remote control system or the garage door. 
  When that happens, the service provider will get a support call, and 
that will have a cost.  The "problem" would be resolved by disabling the 
ipv6only-flag.  So where's the impetus for service providers to start 
making judgement calls like this on the part of their customer base? 
What problem would it resolve for service providers?

On the other hand, how realistic would it be to expect regular 
mom-n-pops to set a flag like this?  I could easily envisage a situation 
where access service providers would have this option disabled on the 
CPEs they sold, purely to cut down on the number of support calls they 
get by well-intentioned people setting the flag and then finding out 
that it breaks stuff.  It would be easier and cheaper to block the 
option from appearing on the CPE in the first place.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sat, 17 Nov 2018 10:15:25 +1100

"IPv6 Router Advertisement IPv6-Only Flag"
https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-04

"It SHOULD be only used in
   IPv6-Only links (see below for definition)."

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

"IPv6-Only is defined to mean that no other versions of Internet
   Protocol than IPv6 are intentionally in use directly on the link."

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 16 Nov 2018 23:18:12 +0000

> "Administrators MUST only use this mechanism if they are certain that

indeed, which would put it out of scope for solving the problem that 
Simon noted, in the general case.

Nick

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sat, 17 Nov 2018 01:18:25 +0000

I think CPEs would readily include this option, though the default would be off. This is not unlike home WiFi APs having an option to support 801.11 b/g/n or g/n or only n. The default is permissive, but practically all APs let the administrator change the default to optimize their network at a risk of breaking that grandpa's Widows XP laptop than only supports 801.11 b.

- Igor

-----Original Message-----
From: Nick Hilliard [[email-masked]]
Received: Friday, 16 Nov 2018, 6:06PM
To: Simon Hobson [[email-masked]]
CC: 6man WG [[email-masked]]
Subject: Re: Proposed text for draft-ietf-6man-ipv6only-flag

Nick

---

From: Philip Homburg <[email-masked]>
Date: Sat, 17 Nov 2018 09:31:08 +0100

>"Administrators MUST only use this mechanism if they are certain that

So what do we have:

- The flag is set by an admin. This rules out just about every home network
and many other networks that don't really have an admin.

- The network doesn't have L2 filter capabilities

- The network is big enough that the IPv4 background chatter actually matters.
  (currently there are dual stack networks of all sizes, somehow this doesn't
  create a big operational issue).

- And finally, the admin is unable to deploy a DHCPv4 server in the network.

Yes, I'm sure the internet is big enough that such a network will extist
somewhere. But do we really need to allocate a flag for such a situation?

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Sat, 17 Nov 2018 14:07:19 +0000

On 16 Nov 2018, at 22:28, Manfredi (US), Albert E wrote:

> Your first example only makes sense in an enterprise network, where 
> this admin can make such decisions for hosts. As to the experiment 
> example, the net admin can simply disable IPv4 in the router she 
> controls. Disable DHCPv4, disable IPv4-formated DNS, disable IPv4 
> packet routing, and see what breaks/who hollers.

That’s an assumption that from a developers time of view is not true 
either;  there is a difference if the application tries and tries and 
has to implement back-off and eventually gives up or if the first packet 
is triggering an “Address family not supported by protocol family”.

Think of people dropping packets and you keep sending TCP SYNs or people 
actively rejecting sending an ICMP or RST back and you know “don’t 
try again”.

Two very different failure modes to deal with.

/bz

---

From: Sander Steffann <[email-masked]>
Date: Sat, 17 Nov 2018 18:56:25 +0100

> somewhere. But do we really need to allocate a flag for such a situation?

This.
Sander

---

From: Bob Hinden <[email-masked]>
Date: Sat, 17 Nov 2018 10:22:27 -0800

Simon,

> On Nov 16, 2018, at 2:24 PM, Simon Hobson <[email-masked]> wrote:
> 
> 

I agree.

In my day job corporate network, all of the windows devices are actively managed, but all of the phones and tablets (iOS and Android), and a few Macs are not.   Given everyone has phone and/or tablet and connects it to the office wifi, the percentage of managed to unmanaged devices is a little less than 50%.

I suspect this is fairly typical in enterprise networks that allow people to connect their phones to Wifi.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Nov 2018 09:03:16 +1300

> and many other networks that don't really have an admin.

My personal expectation is that if the flag is standardised and implemented,
this provision will likely change in a more mature market - indeed it might
end up that the flag is set by default in domestic CEs shipped by ISPs that
decide to go IPv6-only (with some form of NAT64-based solution in place,
of course). But for now, restricting it to managed networks seems reasonable.

> - The network doesn't have L2 filter capabilities

As noted in the draft, there will be residual battery and spectrum
wastage even if there is L2 filtering.
 
>   create a big operational issue).

As Bob pointed out, ~50% of devices on a corporate network with BYOD
might be affected by that battery and spectrum wastage. No, it isn't a
*big* effect, but it's widespread.
 
> - And finally, the admin is unable to deploy a DHCPv4 server in the network.

Or *does not wish* to deploy a DHCPv4 server, or any other legacy stuff.

> somewhere. But do we really need to allocate a flag for such a situation?

It's a crystal ball exercise, for sure. To ask your question more positively,
if we provide this flag, do we alter the future in a way that encourages
IPv6-only deployment and IPv4-legacy removal?

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Sat, 17 Nov 2018 12:18:49 -0800

> IPv6-only deployment and IPv4-legacy removal?

I will add that IMHO, we should be providing tools that make this transition easier.

Bob

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 18 Nov 2018 01:02:15 +0000

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

Not worth worrying about. An updated host that might know to read this flag is an updated host that could just as easily know to expect that IPv4 might be unavailable, and not to waste minutes waiting on IPv4 services. (Especially if the host has already noticed that IPv6 is available.)

Even that isn't terribly compelling. One, because corporate networks probably have separate WiFi networks, for corporate or for BYOD devices. And two, same reason as above.

> Or *does not wish* to deploy a DHCPv4 server, or any other legacy stuff.

So ..., don't!

My issue with the flag is the harm it can do, depending how device makers interpret it. And most specifically, if device makers interpret it to mean what the name says: "IPv6-only in this link." Unless you add a "wink-wink," some devices might take that literally. (Not sure why this doesn't seem to bother others.)

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Nov 2018 14:41:56 +1300

> My issue with the flag is the harm it can do, depending how device makers interpret it. And most specifically, if device makers interpret it to mean what the name says: "IPv6-only in this link." Un…

I'm trying to keep my fingers off the keyboard, but on that point: if a device
understands the flag, it's by definition IPv6-capable. So no, it doesn't bother
me at all if it decides not to bother with IPv4, since the link offers IPv6
services.

But yes, there's a "wink-wink", more commonly known as an RFC2119 "SHOULD",
because clearly some developers or deployers will have reasons to do
otherwise.

That doesn't break anything. It's the risk of malicious actors that creates
potential breakage.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Sat, 17 Nov 2018 17:51:07 -0800

> On Nov 17, 2018, at 12:18 PM, Bob Hinden <[email-masked]> wrote:

I would opine that the need for tools remains to be proven. I can imagine an exponential backoff of DHCP requests for an IPv4 address. Beyond that, if the only thing that works is IPv6 and the person using the computer has been told that only IPv6-capable applications will actually work, I’m not sure what else is required.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 18 Nov 2018 13:08:32 +0100

>of course). But for now, restricting it to managed networks seems reasonable.

Maybe I'll change my mind when this happens. But at the moment that is
not what the draft says. Nor are CPE vendors asking for this flag.

>wastage even if there is L2 filtering.

So we can agree that from a network management point of view the draft
is redundant?

If so, please rewrite the problem statement to exclude network issues. Then
we can focus on host issues.

>*big* effect, but it's widespread.

With L2 filtering, spectrum wastage is close to zero. On wifi networks,
multicasts eat a lot of spectrum, but only on the down link. With L2 filtering,
you would only see a small amount of IPv4 multicast on the uplinks, which
is left in the noise.

>Or *does not wish* to deploy a DHCPv4 server, or any other legacy stuff.

So each time somebody doesn't like an exsiting solution, we just add new
protocol that basically does the same?

I can think of some features I would like to have, if that is the new policy
for this group.

>IPv6-only deployment and IPv4-legacy removal?

In the past, IPv6 standards have managed to break existing networks. I
think it is a bad idea to break IPv4 just because we like IPv6.

---

From: Mark Smith <[email-masked]>
Date: Mon, 19 Nov 2018 00:17:57 +1100

> not what the draft says. Nor are CPE vendors asking for this flag.

Why would a CPE vendor ask for this? CPEs predominantly are mains powered.

End-hosts and their users, in particular mobile BYO hosts such as
smartphones, are the primary beneficiary of this mechanism.

> So we can agree that from a network management point of view the draft

So, on a LAN with 1000 hosts, you want to configure 1000 layer 2 ports with
Ethertype filters (and for every new host, configure the new host's port
with an Ethertype filter), instead of configuring likely no more than 2
IPv6 routers with this flag, and then never having to worry about it again
for any new hosts attached to that LAN segment?

(1000 hosts on a LAN is conservative, back in the IPX days of the 1990s I
saw one LAN operating successfully with 4000+ hosts attached to it. I'd
hate to be trying to consistently configure 4000+ LAN ports verses
consistently configuring a 2 IPv6 routers.)

> >> - The network is big enough that the IPv4 background chatter actually
> matter
> >s.
> >>   (currently there are dual stack networks of all sizes, somehow this
> doesn'
> >t
> With L2 filtering, spectrum wastage is close to zero.

Doing nothing will always be more efficient than doing something and then
throwing it away. Mobile BYO hosts not spending battery power sending
useless packets will always be more efficient and effective.

Multiply a minor energy saving by millions and possibly billion of devices
such as smartphones, and it becomes a major energy saving.

On wifi networks,
> protocol that basically does the same?

It's not basically the same, because the population of hosts benefit by not
expending energy on totally useless IPv4 transmissions.

Even if you view this to be the same as layer 2 filtering, realise that
very little innovation is truly inventing something new. Most of the time,
it is just making an existing outcome simpler, cheaper and quicker to
achieve.

Configure a couple of IPv6 routers with this flag, or configure 1000 LAN
ports with Ethertype filters; which is the simpler, cheaper and quicker
option?

Got a dishwasher? Got a washing machine? Have an automatic gearbox in your
car? None of them do anything than wasn't being done before they existed.
None of them are necessities.

ARP wasn't necessary; people could have manually configured MAC/IPv4
address tables in individual hosts. ARP is a convenience, not a necessity.

BOOTP/DHCPv4 wasn't necessary; people could have continued to manually
configure individual hosts with their addresses and other parameters.
BOOTP/DHCPv4 is a convenience, not a necessity.

DNS wasn't necessary; people could have learnt hosts' identities by their
IP addresses, similar to how people learnt phone numbers. DNS is a
convenience, not a necessity.

Email wasn't necessary; people could have continued to write letters and
send them in paper envelopes. Email is a convenience, not a necessity.

If you think the threshold of innovation acceptance is totally new
invention, then the majority of things you have and use daily wouldn't
exist.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Nov 2018 09:01:03 +0900

On Fri, Nov 9, 2018 at 12:48 AM Nick Hilliard <[email-masked]> wrote:

> only only when the cpu is already awake for any other reason

Often in the absence of a network connection there is no such reason. We
changed the DHCP retransmit to a wakeup alarm several years ago because it
was observed that on wifi-only devices, when the initial DHCP request was
lost, DHCP would time out because nothing would wake up the device.

> provided in the document is a little vague, and there are no references

If you are able to take new measurements, I'd be happy to see them.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 19 Nov 2018 11:43:34 +0100 (CET)

> I will add that IMHO, we should be providing tools that make this transition easier.

I agree. I will sum up my support for this flag as:

1. It's a signal from the network administrator. Nothing more, nothing 
less. It's an potential optimization.

2. Host implementers can do what is best for their users based on this 
information. We should not prescribe exact behavior. Host implementers 
knows best what to do. based on their experience of how their devices are 
used depending on interface type, device type etc.

3. Over time this behavior can be changed as conditions change and 
different approaches are tested and evaluated. We can document it in an 
v6ops BCP in a few years if we feel the need.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 19 Nov 2018 15:06:52 +0100

>smartphones, are the primary beneficiary of this mechanism.

In my experience, the only people who have direct control over CPE vendors are
large ISPs who pay for custom firmware, or have enough buying power to get a
CPE vendor to add what they want.

Most end users have no clue about networks. And the few end users that do have
no buying power.

So it is reasonable to expect that this flag will not have any effect on CPEs.
It doesn't solve any problem the CPE vendor might have. It doesn't solve any
problem an ISP may have. Worse, if such an option would prevent access to an
old IPv4-only printer, then the ISP is likely to get a support call. So
ISPs have an incentive to disable support for this flag in CPEs they ship.

>for any new hosts attached to that LAN segment?

If there still are 1000 port networks where network admins configure ports by
hand, then maybe this will encourage using more modern tools.

In any case, even if you would configure L2 filters by hand, on wired ethernet
it would be enough to configure them on the uplink of the switch. Any
individual switch has more than enough backplane capacity for a few IPv4
multicasts.

However, in any modern network, each port already has a vlan tag. In every
serious network we expect every port to have an RA-guard setting. So adding
L2 filtering fits right in. Modern switch firmware can easily have a global
setting that disables IPv4 and ARP on all ports.

>such as smartphones, and it becomes a major energy saving.

Because it is very unlikely that unmanaged networks (such as home networks)
will set this flag, mobile hosts will already deal with this issue without
relying on this flag being set.

At the same time, we can expect this flag to be set accidentally (or
maliciously) which will waste significant resourses in trying to figure
out what went wrong.

>expending energy on totally useless IPv4 transmissions.

Which can be signalled using an exiting DHCPv4 option.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 19 Nov 2018 15:21:47 +0100 (CET)

> Which can be signalled using an exiting DHCPv4 option.

In future IPv6 only devices (to provide IPv6 services) I don't even want 
them to implement an IPv4+DHCPv4 stack.

So signalling "no IPv4 here" using IPv4 is a no-go, long term.

---

From: [email-masked]
Date: Mon, 19 Nov 2018 17:09:12 +0100 (CET)

> In future IPv6 only devices (to provide IPv6 services) I don't even
> want them to implement an IPv4+DHCPv4 stack.
> 

But you want them to implement IPv4 *without* DHCPv4? That doesn't
make sense to me. And if the device doesn't implement IPv4 at all,
of course, the flag is not needed in the first place.

Steinar Haug, AS2116

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 19 Nov 2018 17:17:26 +0100 (CET)

> of course, the flag is not needed in the first place.

I am talking about my router that sends the RA. It doesn't need an IPv4 
stack but I still want it to signal to hosts that this is an IPv6 only 
LAN.

This is not about the device receiving the signal, it's about the one 
sending it.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 19 Nov 2018 19:20:38 +0000

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

+1. Especially the second part, where mobile hosts can find other ways of saving energy, without relying on a new flag.

I would say, accidentally, maliciously, *or* the flag can be interpreted cluelessly, by the host. To create a problem where a problem should never have existed.

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

But it's possible, using the 169.254.x.x. APIPA address, or using static configuration, or what the heck, even adding your own local IPv4 router, with its own DNCPv4 server, to set up internal IPv4 routes. EVEN IF the default router to the ISP doesn't speak IPv4.

I keep coming back to the logical intersection of sets, in this thread. What it keeps boiling down to is that, with the *possible* exception of enterprise nets, what this flag actually says is that this one router won't route IPv4. I really think that the desire to conduct the one IPv6-only experiment, at the Singapore IETF meeting, has colored the motivations here. That scenario might not be generic enough to deserve its own special solution?

Bert

---

From: Mark Smith <[email-masked]>
Date: Tue, 20 Nov 2018 11:04:49 +1100

> ISPs have an incentive to disable support for this flag in CPEs they ship.

So I considered you were using the term CPE more generically, rather than
ISP CPE specifically.

It sounds like you're thinking that this mechanism is specifically designed
for a residential ISP CPE scenario. That's not the case.

It's more general than that, per the Introduction and Applicability
sections in the draft.

This flag may be useful in an ISP scenario, if, and only if, the ISP
operates the customers CPE and knows absolutely that IPv4 is intentionally
not going to be used on the link where this flag would be enabled. If the
ISP doesn't know that, then they would be enabling this flag at their own
peril, and at the direct cost to them of an increase in helpdesk calls and
an indirect cost of a decrease in customer satisfaction with the Internet
service they're proving to customers. In other words, there are very strong
incentives for an ISP not to switch on this flag unless they know quite
absolutely they can safely.

> it would be enough to configure them on the uplink of the switch.

 Any

> setting that disables IPv4 and ARP on all ports.

This is all ignoring the goal of having hosts not spend resources sending
useless and entirely unnecessary IPv4 packets (specifically initial and
repeated link-layer broadcast DHCPv4 DISCOVER packets for which there will
never be an answer on an IPv6 Only link).

> Which can be signalled using an exiting DHCPv4 option.
It is inefficient to require enabling IPv4 and a DHCPv4 server on an IPv6
Only link for the single and sole purpose of disabling IPv4, and
ineffective at achieving the goal of removing all IPv4 and ARP traffic from
the IPv6 Only link and having hosts not send or receive any IPv4 packets on
an IPv6 Only link.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Nov 2018 00:08:00 -0300

> I don’t see a problem doing ipv6-only here, “what to do with other residual IPv4 chatter” that I think would not.

It would seem to be that definition of the flag belongs here, but
reaction to the flag does not. And in order to have a spec about this,
you need both?

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Nov 2018 18:48:40 +1300

> reaction to the flag does not. And in order to have a spec about this,

Yes, it would in theory be entirely possible to have a rather
short 6man document that assigns the flag and describes its meaning,
and a longer v6ops document that covers usage. If that's what the
community wants, it could be done. The issue is that we'd first
need consensus to define the flag, and the discussion has shown that
this decision is closely tied to the usage.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Tue, 20 Nov 2018 14:11:17 +0100

>In other words, there are very strong

In other words, any mobile device that is expected to be used in a
residential environment cannot rely on this flag.

This makes the flag redundant for mobile devices. 

Any device vendor has to consider the case where the flag is set accidentally.
So the safest option is to continue probing for IPv4 even if the flag is set.

So at the end of the day, the flag will be a no-op for mobile devices.

>never be an answer on an IPv6 Only link).

Which is very nice, and mostly covered by an existing DHCPv4 option.

In any case, even with the flag set, it makes sense for a host to continue
with DHCPv4 because robustness is more important than saving a trivial amount
of energy.

>the IPv6 Only link and having hosts not send or receive any IPv4 packets on

Removing all IPv4 traffic sounds like an aesthetic requirement. 

L2 filters are more than enough to deal with any network issues, including
IPv4-based attack vectors.

As discussed before, hosts are likely to adapt to IPv6-only environments and
conserve energy even if there is no explicit notification from the network.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 20 Nov 2018 14:21:45 +0100 (CET)

> So at the end of the day, the flag will be a no-op for mobile devices.

I have spoken to people who implement mobile device OS and they both said 
they'd take the flag and most likely do more agressive exponential backoff 
if they see this flag.

They can then implement telemetry/diagnotics information to gather how 
often IPv4 is available even in the precense of this flag being set and 
then decide how to proceed in the years to come.

This is a long game.