Subject: Fwd: New Version Notification for draft-hinden-ipv4flag-04.txt

From: Bob Hinden <[email-masked]>
Date: Mon, 16 Apr 2018 10:31:08 -0700

Hi,

Based on the recent discussion a revised ID has been posted.  See links below.  There are a number of changes that the authors think should resolve some of the issues raised in the adoption call.  These include:

  - Changed the name of the document and flag to be the IPv6-Only flag.   This was that intent of the draft and this makes
    the intended use clearer.   With the name change, the flag name is also changed.  It turns out that bit 6 in the flags field is
    proposed to be called the “IPv6-Only” flag.

  - Rewrote text to make it affirmative that this is used by an administrator to tell the hosts that the link
    is IPv6-Only.

  - The draft now uses SHOULD language.   That is, do this unless there is a good reason to not do so.

   - Added an Applicability Statements section to scope the intend use.

   - Added Requirements Language section with references to [RFC2119] and [RFC8174].

Please review.  We think with these changes this version should reduce some of the concern with adopting this draft.

Bob & Brian

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hinden-ipv4flag-04.txt
> Date: April 16, 2018 at 10:20:07 AM PDT
> To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden" <[email-masked]>, "Brian Carpenter" <[email-masked]>
> 
> 
> A new version of I-D, draft-hinden-ipv4flag-04.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-hinden-ipv4flag
> Revision:	04
> Title:		IPv6 Router Advertisement IPv6-Only Flag
> Document date:	2018-04-16
> Group:		6man
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-ipv4flag-04
> 
> Abstract:
>   This document specifies a Router Advertisement Flag to indicate to
>   hosts that the administrator has configured the router to advertise
>   that the link is IPv6-Only.  This document updates RFC5175.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Apr 2018 09:27:23 +0200

Thanks Bob!

Now that the document clearly specifies what a host is supposed to do, that resolves my concern.Any other

Any other views?

Best regards,
Ole

> On 16 Apr 2018, at 19:31, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 26 Apr 2018 19:08:42 +0000

> resolves my concern.Any other

Yes, I now have concerns I didn't have before. :)
In section 6 (Host Behavior) the term "IPv4  operations" is undefined. It isn't clear exactly what hosts should not attempt. Based on Section 5, it appears "IPv4 operations" may mean something like "transmitting IPv4 packets on the same lower layer interface that the RA was received on". This would include DHCPv4/IPv4 on the same lower layer interface; so it shouldn't be necessary to call DHCPv4 out, specifically.

Since the advice is only "SHOULD NOT" (actually "SHOULD not", but I think it means "SHOULD NOT"), that would not preclude devices that really want to continue with auto IPv4 addresses (169.254../16) from doing so. They could be excused for having a really good reason to ignore the advice.

But some things that aren't addressed (and one of the reasons I think "IPv4 operations" needs to be much more precise) are:
 - If the host has multiple interfaces and the RAs on one lower-layer interface are all 1 but on another are 0, the host should probably not do IPv4 on the first interface but should continue IPv4 on the 2nd interface. BTW, if the 2nd interface is, for example, PPPoE, then this 2nd interface will never see any RA. The advice in the current draft would indicate that since all received RAs (which were only received on the 1st interface) were 1 then no IPv4 on any interface. Which to me would not be desirable behavior.
 - Tunneling IPv4 over IPv6 or doing 464XLAT could also be considered "IPv4 operations" by many people. But I would be opposed to suggesting hosts that are configured to tunnel IPv4 over IPv6 or do 464XLAT should have operation of these technologies stopped by this flag. In fact, it might be reasonable for one of these technologies to be auto-enabled on receipt of this flag in some use cases (e.g., if the host is also a router with IPv4 devices operating on its LAN, or it has IPv4-only applications running).

I still see normative language for host behavior as unnecessary; but if others are going to insist on it, then the language needs to be very precise so as not to have unintended consequences.

Barbara

> > Based on the recent discussion a revised ID has been posted.  See links
> below.  There are a number of changes that the authors think should resolve
> some of the issues raised in the adoption call.  These include:
> >
> >   - Changed the name of the document and flag to be the IPv6-Only flag.
> This was that intent of the draft and this makes
> >     the intended use clearer.   With the name change, the flag name is also
> changed.  It turns out that bit 6 in the flags field is
> > Please review.  We think with these changes this version should reduce
> some of the concern with adopting this draft.
> >
> > Bob & Brian
> >
> >> Begin forwarded message:
> >>
> >> To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden"
> >> <[email-masked]>, "Brian Carpenter"
> >> <[email-masked]>
> >>
> >>
> >> A new version of I-D, draft-hinden-ipv4flag-04.txt has been
> >> successfully submitted by Robert M. Hinden and posted to the IETF
> >> repository.
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Apr 2018 22:43:29 +0200

Hi Barbara,

> In section 6 (Host Behavior) the term "IPv4  operations" is undefined. It isn't clear exactly what hosts should not attempt. Based on Section 5, it appears "IPv4 operations" may mean something like…

"IPv4 operation" as in disable IP4 on the interface connected to that link.
Don't enable an address, don't send IPv4 packets out the interface, drop any received IPv4 packets...

> Since the advice is only "SHOULD NOT" (actually "SHOULD not", but I think it means "SHOULD NOT"), that would not preclude devices that really want to continue with auto IPv4 addresses (169.254../16…

Right.

> - If the host has multiple interfaces and the RAs on one lower-layer interface are all 1 but on another are 0, the host should probably not do IPv4 on the first interface but should continue IPv4 o…

The flag only says something about the properties of the link that the RA is received on. That must be clear. Although this is how all RA information is used.

> - Tunneling IPv4 over IPv6 or doing 464XLAT could also be considered "IPv4 operations" by many people. But I would be opposed to suggesting hosts that are configured to tunnel IPv4 over IPv6 or do…

If the flag was received over a tunnel with IPv6 transport, then yes it would behave like any other link. I would be quite concerned about implying anything else by this flag, e.g. enabling any of the transition mechanisms.

Best regards,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 26 Apr 2018 23:46:23 +0100

> do, that resolves my concern.Any other
tl;dr: this draft should not be adopted for practical reasons.

Meaningful implementation of this flag is going to require changes to 
every dual-stack host operating system. This is a substantial undertaking.

On the sorts of networks that the Introduction section identifies as 
having problems due to the presence of unwanted ipv4 chatter, filtering 
ethertypes 0x0800 and 0x0806 on network segment boundaries will, 
assuming random distribution across segments, cause the amount of ipv4 
chatter to drop by (1 - 1/n)*100%, where n is the number of segments. 
For example, on a small wifi network with 3 access points, sensible 
application of filters might cause a drop of 2/3.   On a larger network, 
say 20 access points, you might end up with a drop of maybe 90-95% of 
unwanted chatter.  The same principals apply to non wifi networks.

The thing is, host-to-host communications on a standard AP based wifi 
network will all go through the AP, e.g. host transmits ipv4 frame, AP 
picks it up, AP retransmits to destination host or broadcasts the frame. 
  There is no particular reason that the AP cannot implement ingress 
frame filtering, at least not that I'm aware of.  My understanding is 
that the same principal applies to cellular networks.

IPv4 chatter isn't a huge issue on traditional wired networks, or on 
docsis networks.  We got all excited about v4 broadcast domains in the 
1990s because of gigantic campus networks, but then learned how to deal 
with it, mostly by not creating gigantic layer 2 networks.

Taking the helicopter point of view, the draft specifies a set of 
actions which impacts host behaviour at a low level, and this is the 
sort of thing that has a good degree of scope for causing wide-scale 
breakage because many applications and operating systems assume the 
presence of ipv4.

 From a network operator point of view, I'm left scratching my head 
about why an immediate 66% or 75% or 95% solution is considered a less 
good option for dealing with chatter.  It's available right now and is 
trivial to deploy even on low cost switching hardware.  Or we could to 
push for a 100% solution for eliminating all ipv4 chatter by pushing for 
vendors to implement ethertype filtering on APs and base stations.

draft-hinden-ipv4flag, if it eventually ends up as a standards track 
rfc, will take years to be implemented across enough operating systems 
for it to be a viable means of fixing the problems it sets out to fix; 
it would be very expensive to implement for vendors, and difficult to 
implement consistently across platforms, if it were implemented at all, 
and there's really no guarantee that it would be, given the scope for 
causing problems on host stacks right up to application level stuff. 
Even in the best case scenarios, it would be years before we'd see results.

I really don't think that this draft should ever end up as an IETF 
standards track document. The operator community needs simple, reliable 
and enforceable.  This draft is none of these things and we already have 
alternative means of going a good way towards implementing the draft's 
aims on today's hardware, with a viable path to having an enforceable, 
100% solution.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Apr 2018 14:10:00 +1200

> Don't enable an address, don't send IPv4 packets out the interface, drop any received IPv4 packets...

Are you sure? What prevents the host doing IPv4 link-local stuff? Even if we said
MUST NOT, it's another example of unenforceable rules.

> The flag only says something about the properties of the link that the RA is received on. That must be clear. Although this is how all RA information is used.

Yes, if that isn't clear to the reader it needs to be added unambiguously.

> If the flag was received over a tunnel with IPv6 transport, then yes it would behave like any other link. I would be quite concerned about implying anything else by this flag, e.g. enabling any of…

Agreed.

>> I still see normative language for host behavior as unnecessary; but if others are going to insist on it, then the language needs to be very precise so as not to have unintended consequences.

Right, but I think the above points cover that.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Apr 2018 14:41:02 +1200

> every dual-stack host operating system. This is a substantial undertaking.

True, but there is no flag day requirement so the work, and the results,
can be spread over many years.

> unwanted chatter.  The same principals apply to non wifi networks.

True. But that isn't really in 6man's scope, or even in the IETF's scope.
 
> with it, mostly by not creating gigantic layer 2 networks.

True, but we do create pretty large and often unmanaged and overloaded
802.11 networks.
 
> breakage because many applications and operating systems assume the 

But on the target networks, by definition there is no IPv4 support.
(As there wouldn't be with Ethertype filtering.) So it makes no
difference to legacy hosts and legacy apps. The impact is only
that updated hosts generate less useless IPv4 chatter. The question
is whether that saving is worth the bother.

> vendors to implement ethertype filtering on APs and base stations.

Go for it. (Seriously.) But that eliminates chatter *between* segments,
not on individual segments.

> it would be very expensive to implement for vendors, 

Well yes, but any patch to the TCP/IP stack is expensive.

> and difficult to 
> implement consistently across platforms, 

The basic behaviour is fairly unambiguous, so I think the inconsistency
would be in the way apps behave. In this context we don't care how
IPv4-only apps behave, so the question is how dual-stack apps will
behave when they don't get an IPv4 address at all. Haven't we already
run that experiment on ietf-nat64 and ietf-v6only?

> if it were implemented at all, 

True.

    Brian

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Fri, 27 Apr 2018 09:52:41 +0200

Hi Nick,

I think you mainly judge from the perspective of a network operator.
The draft also mentions advantages for the end-systems and they
_are_ an incentive to implement this in the operating systems.
IMHO saving battery by avoiding transmission of IPv4 chatter into the
network would be a huge benefit for smart phones, i.e., avoiding
traffic at the source is always the better solution in the end
(additional filtering in the network won't hurt though).

Regards,
 Roland

Am 27.04.2018 um 00:46 schrieb Nick Hilliard:
> From a network operator point of view, I'm left scratching my head about
> why an immediate 66% or 75% or 95% solution is considered a less good
> option for dealing with chatter.  It's available right now and is

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 27 Apr 2018 11:39:50 +0100

> (additional filtering in the network won't hurt though).

There are two aspects to this: chatter transmitted by the host device 
and chatter received.

Transmitted chatter is largely the business of the host device.  If 
there is partial or complete ethertype filtering implemented at the 
network layer, then the device will emit mostly or only broadcast 
frames, i.e. ARP and various broadcast discovery packets using rfc3927 
auto-addressing.  Unicast won't generally be used as the host's arp 
cache will not be populated due to ethertype filtering blocking ARP 
requests from being propagated.

draft-hinden-ipv4flag could have a minor impact on this, but as 
power-constrained devices are free to manage transmitted chatter in 
whatever way works best for them anyway, it may be wiser to assess the 
scale of the problem first, and to engage vendors to try to figure out 
what would work best for them, rather than creating a fix on the basis 
of assumptions.

Chatter received by the host device can be managed by the network 
operator by judicious use of ethertype filtering, either at the AP/base 
station or further up the l2 domain.  This is already very manageable 
using current generation equipment.

Nick

---

From: Tim Chown <[email-masked]>
Date: Fri, 27 Apr 2018 11:05:20 +0000

Hi,

> On 27 Apr 2018, at 03:41, Brian E Carpenter <[email-masked]> wrote:
> 

This is a good point.

So would it be better, if the PvD work which seems to have good support is being progressed over time as well, to instead use the IPv4 service flag in draft-ietf-intarea-provisioning-domains-01?

"L-flag      :   (1 bit) 'Legacy' flag stating whether the router is
      also providing IPv4 information using DHCPv4."

which would allow PvD-aware hosts to selectively turn off IPv4 for that specific PvD conveyed in that RA.  See Section 5 of that draft for how that could be done.

I'm not sure that's the intent of the L-bit in that draft (it may be designed to correlate IPv4 and IPv6 PVD information), but it could also be interpreted that way?

Tim

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 27 Apr 2018 13:17:53 +0200 (CEST)

> what would work best for them, rather than creating a fix on the basis 

Just taking one of the latter email in this chain, so not to Nick 
specifically.

3GPP has its bearer concept, IPv4, IPv6 or IPv4v6. They don't need a flag, 
the functionality we're talking about can be inferred by the bearer. You 
don't send IPv4 traffic out an IPv6 bearer. So this leaves wifi as the 
large access technology that might benefit frmo this.

The functionality of this flag primarily is aimed to help hosts save power 
it seems. When reading this email chain, I found some email from at least 
one vendor who said it was unclear what this flag meant and didn't support 
adoptoion. It's now been another 4 weeks, and I don't know if things are 
clearer now.

Can we get some vendor/OS input on the latest versions/changes of the 
text, do they think this is a good idea as it stands? Will they implement 
support for this flag? Do we have supporters from people running large 
Wifi networks, saying ethertype based filtering in APs doesn't solve 
anything?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 27 Apr 2018 13:00:54 +0100

> can be spread over many years.

The yardstick needs to be effort vs return.  draft-hinden-ipv4flag 
provides an undefined return in the long term, but requires substantial 
effort over an extended period.  I don't think the time-scales are 
especially relevant - mostly the overall effort required.

Current technology provides high short term yields and guaranteed very 
high long term yields, at much lower overall cost.

The engineering balance doesn't look right.

> True, but we do create pretty large and often unmanaged and overloaded

We learned 25 years ago that creating large, unmanaged and overloaded 
layer 2 domains of any form is unwise, whether 802.11 or anything else. 
There's no good reason for people either to deploy networks like this, 
or to use them as justification for protocol development.

> not on individual segments.

If you can implement ingress ethertype filtering on APs, then that will 
eliminate ipv4 backscatter across the network.  All you're left with 
then is the issue of transmission from wifi host devices.  This 
inherently reduces the scope (and utility) of draft-hinden-ipv4flag by a 
large degree and places the remaining problem firmly on the front door 
of the vendors.

> Well yes, but any patch to the TCP/IP stack is expensive.

Indeed - Bert Hubert's recent talk about the DNS Camel comes to mind.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Apr 2018 09:13:41 +1200

> I'm not sure that's the intent of the L-bit in that draft (it may be designed to correlate IPv4 and IPv6 PVD information), but it could also be interpreted that way?

Well, I can't predict the future so I don't really know whether PvDs will become
a success, especially for smaller, simpler devices that care about battery usage.
But it does sound as if the semantics of that flag need to be tightened up
in the same way we were asked to tighten the semantics of draft-hinden-ipv4flag.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 29 Apr 2018 10:02:02 +1000

Hi,

On 17 April 2018 at 03:31, Bob Hinden <[email-masked]> wrote:

>     the intended use clearer.   With the name change, the flag name is
> also changed.  It turns out that bit 6 in the flags field is

So I think the new name for the flag is better, however I think it still
isn't quite accurate:

".  Applicability Statements

   The mechanism is designed to allow administrators to notify hosts
   that the link is IPv6-Only.  It SHOULD be only used in IPv6-Only
   links."

- so IPv6 should be the only version of the Internet Protocol that appears
on the link.

"Dual stack hosts that have a good reason to use IPv4, for example
   IPv4 link-local services, can continue to do so.  This is consistent
   with the SHOULD language in this document."

Yet it is possible for IPv4 to also appear on the link if hosts choose to
bring it up? But isn't the link supposed to be IPv6 Only?

So it seems what this flag is really declaring is that there are no IPv4
default routers on the link (when the set of all default IPv6 routers have
set this flag). If hosts wish to use IPv4, they're being informed that IPv4
reachability is limited to the link itself, and it isn't possible to reach
IPv4 off-link destinations, should they somehow want to.

I wouldn't think it is declaring that there aren't DHCPv4 servers on the
link, just that the DHCPv4 server(s) won't provide default gateway
information if they are present. If hosts want to use IPv4, they could and
probably should use IPv4 LL address generated without relying on a DHCPv4
server, however there might be reasons to have a DHCPv4 server on the link
handing out RFC1918 addresses (e.g. some or all host don't support IPv4 LL
address generation).

So possibly more accurate (although far more clumsy) names for this flag
could be something like:

"No IPv4 Default Routers on Link"

"Link Limited IPv4 Traffic Link"

"On-Demand Local IPv4 Traffic Only Link"

Regards,
Mark.

<snip>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Apr 2018 14:12:09 +1200

> bring it up? But isn't the link supposed to be IPv6 Only?

No protocol police...

> information if they are present. 

That's a choice we could make, but the current version is intended
to say that neither routing nor DHCP addresses are provided. So any
local traffic will have to use link-local IPv4 addresses. We could cite
RFC3927 to be even more explicit.

> If hosts want to use IPv4, they could and

Why do we care what legacy systems can or cannot do?

> "No IPv4 Default Routers on Link"

That was our original idea. What we have now is the result of previous
discussions on the list.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Sun, 29 Apr 2018 15:26:09 -0700

Mark,

Jumping to the end.

> On Apr 28, 2018, at 5:02 PM, Mark Smith <[email-masked]> wrote:
> 
> Hi,
> 
> 
> 
> So I think the new name for the flag is better, however I think it still isn't quite accurate:
> 
> - so IPv6 should be the only version of the Internet Protocol that appears on the link.
> 
> 
> Yet it is possible for IPv4 to also appear on the link if hosts choose to bring it up? But isn't the link supposed to be IPv6 Only?
> 
> So it seems what this flag is really declaring is that there are no IPv4 default routers on the link (when the set of all default IPv6 routers have set this flag). If hosts wish to use IPv4, they're being informed that IPv4 reachability is limited to the link itself, and it isn't possible to reach IPv4 off-link destinations, should they somehow want to.
> 
> I wouldn't think it is declaring that there aren't DHCPv4 servers on the link, just that the DHCPv4 server(s) won't provide default gateway information if they are present. If hosts want to use IPv4, they could and probably should use IPv4 LL address generated without relying on a DHCPv4 server, however there might be reasons to have a DHCPv4 server on the link handing out RFC1918 addresses (e.g. some or all host don't support IPv4 LL address generation).
> 
> So possibly more accurate (although far more clumsy) names for this flag could be something like:
> 
> "On-Demand Local IPv4 Traffic Only Link”

I think could be addressed (assuming the draft is adopted) by defining what IPv6-Only means.   The current draft doesn’t do that.  I think your list is pretty close, except it might be the administrator chose to limit all IPv4 traffic at the link level, so even IPv4 local traffic wouldn’t work.

I still think a SHOULD is correct from a practical sense, in that what’ I think will happen anyway.

Bob

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 29 Apr 2018 22:26:46 +0000

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

On 29/04/2018 12:02, Mark Smith wrote:

>> Yet it is possible for IPv4 to also appear on the link if hosts
>> choose to bring it up? But isn't the link supposed to be IPv6 Only?
>
> No protocol police...

Unless I missed something along the way, I would have answered that that the flag merely states that this router, which would frequently be the one and only router, and the default router, won’t route IPv4 and won’t provide DHPv4 service. Did anyone suggest that the flag must only be transmitted after appropriate inter-router communications, all routers agreeing not to offer IPv4 services, on networks with multiple routers? I could have missed that threat.

> So any local traffic will have to use link-local IPv4 addresses.

Any local traffic could use link-local IPv4, *if* the devices are set up for APIPA (automatic private IP addressing). But RFC 1918 addresses, or for that matter, more risky but still feasible, any other statically configured IPv4 address? I know it's risky, but just for the sake of argument, if the router transmitting this IPv6-only flag is the only router in the broadcast domain, then that network is isolated from the IPv4 Internet. Any IPv4 address space should be technically workable.

Some time ago, I offered a scenario where there one or more antique PCs in the local subnet, presumably unable to do IPv6 *and* unable to do auto-configured IPv4 link-local addresses. That or those antique PCs could legitimately communicate with other antique PCs, or with dual stack modern PCs, in that local network. I don’t think this new flag would prevent such operation.

Bert

---

From: Bob Hinden <[email-masked]>
Date: Sun, 29 Apr 2018 15:44:15 -0700

Bert,

> On Apr 29, 2018, at 3:26 PM, Manfredi (US), Albert E <[email-masked]> wrote:
> 

No, except if the administrator was blocking IPv4 at L2.  That is consistent with the SHOULD used in the document.

I think it comes down to what it means for the administrator to assert that the link is IPv6 only.

Thanks,
Bob

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 29 Apr 2018 23:03:17 +0000

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]] 

> I think it comes down to what it means for the administrator to assert that the link is IPv6 only.

Bob, even then, what can the administrator "block" at L2? Only packets addressed to boxes under the control of this administrator, no?

In a home net, or even in a corporate net where at least some PCs are used by people with admin privileges, you could have PCs intercommunicating with IPv4. Take, for example, a lab, inside a corporate IPv6-only network. I'm not sure how the IT folk can, or should, prevent boxes inside that lab from using IPv4?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Apr 2018 12:00:14 +1200

> Bob, even then, what can the administrator "block" at L2? Only packets addressed to boxes under the control of this administrator, no?

They can block all packets with the IPv4 Ethertypes that would otherwise be
relayed by the L2 switch. On switched Ethernet, that would be a complete
block. On 802.11, that would be a complete block on broadcast, which means
no ARP. It would also be a block on any unicast to a destination on a
different wireless segment in the same LAN. That doesn't look good for IPv4 apps.

If you're still running Ethernet on coax... no, let's not finish that sentence.

There's no doubt, as Nick said, that the ability to block Ethertypes in the
switches is a more powerful tool than ipv4flag. But that isn't something
the IETF controls.

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Sun, 29 Apr 2018 17:07:40 -0700

Brian, Bert,

> On Apr 29, 2018, at 5:00 PM, Brian E Carpenter <[email-masked]> wrote:
> 

This is mentioned in the draft in Section 5:

   Operators of large IPv6-only wireless links are advised to also use
   Layer 2 techniques to drop IPv4 and DHCPv4 packets (Ethertypes 0x0800
   and 0x806) at all switches, and to ensure that IPv4 and DHCPv4 Layer
   3 features are disabled in all switches.

Bob

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 30 Apr 2018 00:11:24 +0000

-----Original Message-----

> They can block all packets with the IPv4 Ethertypes that would
> otherwise be relayed by the L2 switch. On switched Ethernet, that
> would be a complete block.

That's why I stipulated "under the control of that admin." Even in a wired switched Ethernet, I can bring my own L2 unmanaged switches into the lab, connect to a port in one of those corporate switches, to run my IPv4-only test devices. Potentially. 

> On 802.11, that would be a complete block on broadcast, which means
> no ARP.

Yeah, except that I can being my own WiFi, say in a home net. It's true that many home routers now incorporate an 802.11 AP, but they also have Ethernet ports, which allow the home user to set up his own AP very easily.

But don’t get me wrong. I still think the flag is useful. Because it tells those dual-stack boxes what not to waste time doing. For instance, don’t waste time waiting for DHCPv4 responses, don’t waste time trying to route IPv4 packets to the default gateway, and so on.

Bert

---

From: David Farmer <[email-masked]>
Date: Sun, 29 Apr 2018 23:06:16 -0500

On Thu, Apr 26, 2018 at 5:46 PM, Nick Hilliard <[email-masked]> wrote:

> ethertypes 0x0800 and 0x0806 on network segment boundaries will, assuming
> random distribution across segments, cause the amount of ipv4 chatter to
> drop by (1 - 1/n)*100%, where n is the number of segments. For example, on
> a small wifi network with 3 access points, sensible application of filters
> might cause a drop of 2/3.   On a larger network, say 20 access points, you
> might end up with a drop of maybe 90-95% of unwanted chatter.  The same
> principals apply to non wifi networks.
>
> There is no particular reason that the AP cannot implement ingress frame
> filtering, at least not that I'm aware of.

I agree having the APs filter ethertypes 0x0800, and 0x0806 mitigates most
of the impact on other devices from the broadcast and multicast traffic.
However, WiFi is a shared media, and the airtime is still used even if the
packets are filtered the AP, worse yet since it is broadcast and multicast
traffic it is sent at the base rate, frequently 1Mb, even with very high
bandwidth unicast encodings.  In high-density WiFi environments, this
airtime impact can be significant, degrading performance of all devices
even devices on diffrent SSIDs, if there are using the same channel. To
mitigate this frequently managed high-density WiFi environments set the
base rate up to 5Mb or more, but that still doesn't eliminate the airtime
impact completly.

My understanding is that the same principal applies to cellular networks.
> with it, mostly by not creating gigantic layer 2 networks.

There are only so many WiFi channels, especially in 2.4Ghz band.  It really
doen't matter how small you make the loagical broadcast domains, in
high-density WiFi environments the channels are going to overlap. Therfore,
unnecessary IPv4 chatter matters, especially in high-density WiFi
environments

-- 
===============================================
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: Ole Troan <[email-masked]>
Date: Mon, 30 Apr 2018 07:56:54 +0200

> On 30 Apr 2018, at 06:06, David Farmer <[email-masked]> wrote:
> 
> 
> 
>> Meaningful implementation of this flag is going to require changes to every dual-stack host operating system. This is a substantial undertaking.
>> 
>> On the sorts of networks that the Introduction section identifies as having problems due to the presence of unwanted ipv4 chatter, filtering ethertypes 0x0800 and 0x0806 on network segment boundaries will, assuming random distribution across segments, cause the amount of ipv4 chatter to drop by (1 - 1/n)*100%, where n is the number of segments. For example, on a small wifi network with 3 access points, sensible application of filters might cause a drop of 2/3.   On a larger network, say 20 access points, you might end up with a drop of maybe 90-95% of unwanted chatter.  The same principals apply to non wifi networks.
>> 
>> The thing is, host-to-host communications on a standard AP based wifi network will all go through the AP, e.g. host transmits ipv4 frame, AP picks it up, AP retransmits to destination host or broadcasts the frame.  There is no particular reason that the AP cannot implement ingress frame filtering, at least not that I'm aware of. 
> 
> I agree having the APs filter ethertypes 0x0800, and 0x0806 mitigates most of the impact on other devices from the broadcast and multicast traffic. However, WiFi is a shared media, and the airtime is still used even if the packets are filtered the AP, worse yet since it is broadcast and multicast traffic it is sent at the base rate, frequently 1Mb, even with very high bandwidth unicast encodings.  In high-density WiFi environments, this airtime impact can be significant, degrading performance of all devices even devices on diffrent SSIDs, if there are using the same channel. To mitigate this frequently managed high-density WiFi environments set the base rate up to 5Mb or more, but that still doesn't eliminate the airtime impact completly.

Multicast from station is sent unicast to the AP. 

Regardless, I think this is a distraction. This flag only asserts that the link is IPv6 only, it doesn’t say anything about IPv4 being blocked. 

It’s not going to have the exact same behavior on Ethernet as refusing to negotiate IPCP on a PPP link. 

Ole

>> IPv4 chatter isn't a huge issue on traditional wired networks, or on docsis networks.  We got all excited about v4 broadcast domains in the 1990s because of gigantic campus networks, but then learned how to deal with it, mostly by not creating gigantic layer 2 networks.
> 
> There are only so many WiFi channels, especially in 2.4Ghz band.  It really doen't matter how small you make the loagical broadcast domains, in high-density WiFi environments the channels are going to overlap. Therfore, unnecessary IPv4 chatter matters, especially in high-density WiFi environments
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Apr 2018 08:30:30 +0200 (CEST)

> to negotiate IPCP on a PPP link.

Right, I had some thoughts on this earlier in the week. For PPP and 
3GPP/GTP you can assert what L3 protocols can be run on the link (IPCP for 
PPP and inherently GTP type for 3GPP networks). For wifi/wired ethernet 
you cannot today, and that's partly why we're having this discussion, I 
guess.

I am not aware of any way an ethernet switch or wifi AP can tell end 
systems "I'm dropping all packets with ethertypes not 0x86dd". Whatever we 
come up with here for signaling on L3 if v4 is available or not, we should 
probably tell IEEE (and others) that it would be beneficial if they 
included this kind of signaling in their L2 network capabilities 
negotiation?

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 30 Apr 2018 12:16:00 +0100

David Farmer wrote:
> I agree having the APs filter ethertypes 0x0800, and 0x0806 mitigates 
> most of the impact on other devices from the broadcast and multicast 
> traffic. However, WiFi is a shared media, and the airtime is still used 
> even if the packets are filtered the AP, worse yet since it is broadcast 
> and multicast traffic it is sent at the base rate, frequently 1Mb, even 
> with very high bandwidth unicast encodings.

breaking this down, there are two situations to consider: broadcast / 
multicast traffic transmitted from the station to the AP and B/M traffic 
transmitted from the AP. The former is unicast from station to AP, so 
doesn't hog base basic rate bandwidth.  There would be a small issue 
here relating to amount of power consumption, but this has been 
discussed in previous emails to 6man.

B/M traffic transmitted from the AP is sent at the basic rate, and this 
is expensive in terms of spectrum allocation.  However, if the AP (+ the 
rest of the l2 domain infrastructure) implements ingress ethertype 
filtering, then no ipv4 / arp traffic will be transmitted, so the 
problem effectively disappears.  If the l2 domain implements ethertype 
filtering on its segment boundaries, then there will be savings 
according to how many stations are associated with each AP, and the 
problem will be reduced proportionally.

> In high-density WiFi 
> environments, this airtime impact can be significant, degrading 
> performance of all devices even devices on diffrent SSIDs, if there are 
> using the same channel. To mitigate this frequently managed high-density 
> WiFi environments set the base rate up to 5Mb or more, but that still 
> doesn't eliminate the airtime impact completly.

Yep, sure, but going back to the problem statement, the draft doesn't 
seem to tackle any pressing problems that really need to be solved for: 
service provider access technology, i.e. docsis, fttx, adsl, 
point-to-point wireless, cellular / mobile access technology, or any 
hosting technology, any cabled enterprise access, and it seems to be of 
only limited practical use in home networking situations.

The problem statement in draft-hinden-ipv4flag appears mostly to tackle 
a single issue relating only to large, managed wifi networks, namely 
broadcast / multicast backscatter emitted by APs, chewing up basic rate 
spectrum and causing excess power usage on battery-enabled devices.

The issue that this WG needs to determine is whether it's worth 
progressing draft-hinden-ipv4flag in order to solve this particular 
problem.  As far as I can see, ethertype filtering on APs is a better 
technical solution to the problem, and the engineering cost is orders of 
magnitude lower.

Nick