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

From: Bob Hinden <[email-masked]>
Date: Fri, 17 Nov 2017 14:42:03 +0800

Hi,

Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND Router Advertisements.  From the Introduction:

   Hosts that support IPv4 and IPv6, usually called dual stack hosts,
   need to work on IPv6 only networks.  That is, a link where there are
   no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
   networks, for example at the IETF 100 meeting in Singapore, shows
   that current dual stack hosts will create local auto-configured IPv4
   addresses and attempt to reach IPv4 services.  A mechanism is needed
   to inform hosts that there is no IPv4 support and that they should
   turn off IPv4.

   Because there is no IPv4 support on these links, the only way to
   notify the dual stack hosts on the link is to use an IPv6 mechanism.
   An active notification will be much more robust than attempting to
   deduce this state by the lack of IPv4 responses or traffic.

   IPv4-only hosts, and dual-stack hosts that do not recognize the new
   flag, will continue to attempt IPv4 operations, in particular IPv4
   discovery protocols typically sent as link-layer broadcasts.  This
   legacy traffic cannot be prevented by any IPv6 mechanism.  The value
   of the new flag is limited to dual-stack hosts that recognize it.

We were originally thinking it would be an April 1 submission, but after reading the discussion on the IPv6 list, we decided it makes sense as a real submission :-)

Please review and comment.

Thanks,
Bob and Brian

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hinden-ipv4flag-00.txt
> Date: November 17, 2017 at 2:36:31 PM GMT+8
> To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden" <[email-masked]>, "Brian Carpenter" <[email-masked]>
> 
> 
> A new version of I-D, draft-hinden-ipv4flag-00.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-hinden-ipv4flag
> Revision:	00
> Title:		IPv6 Router Advertisement IPv4 Availability Flag
> Document date:	2017-11-17
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
> 
> 
> Abstract:
>   This document specifies a Router Advertisement Flag to indicate that
>   there is no IPv4 service on the advertising router.  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: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 17 Nov 2017 15:21:42 +0800

At first sight, looks fine to me.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Bob Hinden <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 17 de noviembre de 2017, 14:42
Para: IPv6 List <[email-masked]>
CC: Bob Hinden <[email-masked]>
Asunto: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt

    Hi,

    

    
    Thanks,
    Bob and Brian

    Begin forwarded message:

    

    

    Abstract:

    
    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 <http://tools.ietf.org>.
    
    The IETF Secretariat

    

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Nov 2017 15:57:52 +0800

HI, BOb,

Comments/questions:

* How about the case in which a user employs an IPv4-only printer on an
IPv6-only network?

* Does this document imply that IPv6 is bootstrapped first than, or in
parallel of, IPv4?

* If IPv4-has already been bootstrapped, would 4=1 still cause the node
to disable IPv4?

* If 4=1, but later 4=0, shuld that transition of the 4 bit trigger IPv4
configuration?

* Sec cons: see RFC7113 -- it seems that still the current state of
affairs for many implementations (unfortunately).

Thanks!

Cheers,
Fernando

On 11/17/2017 02:42 PM, Bob Hinden wrote:
> Hi,
> 
> Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND
> Router Advertisements.  From the Introduction:
> 
> We were originally thinking it would be an April 1 submission, but after
> reading the discussion on the IPv6 list, we decided it makes sense as a
> real submission :-)
> 
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for draft-hinden-ipv4flag-00.txt*
>> *Date: *November 17, 2017 at 2:36:31 PM GMT+8
>> *To: *"Robert M. Hinden" <[email-masked]
>> <mailto:[email-masked]>>, "Robert Hinden" <[email-masked]
>> <mailto:[email-masked]>>, "Brian Carpenter"
>> <[email-masked] <mailto:[email-masked]>>
>>
>>
>> Name:draft-hinden-ipv4flag
>> Revision:00
>> Title:IPv6 Router Advertisement IPv4 Availability Flag
>> Document date:2017-11-17
>> Group:Individual Submission
>> Pages:5
>> URL:
>>            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
>> Htmlized:
>>       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
>>
>>
>> Abstract:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Nov 2017 21:15:23 +1300

> * How about the case in which a user employs an IPv4-only printer on an

That question makes my head hurt. Why would you configure the flag =1 on
such a network?

> * Does this document imply that IPv6 is bootstrapped first than, or in

First. Maybe we need to state that.

> * If IPv4-has already been bootstrapped, would 4=1 still cause the node

There is a cunning "should not" in the text to cover corner cases. But
we probably need to discuss the corner cases anyway.

> * If 4=1, but later 4=0, shuld that transition of the 4 bit trigger IPv4

Yes, we need to say something about that - linked to router lifetimes, I
think.

me -> airport shortly.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 17 Nov 2017 16:17:40 +0800

Fernando,

> On Nov 17, 2017, at 3:57 PM, Fernando Gont <[email-masked]> wrote:
> 
> HI, BOb,
> 
> Comments/questions:
> 

That’s not an IPv6-only network.  If the user or networks wants to use IPv4, then it shouldn’t set Flag=1.

> * If IPv4-has already been bootstrapped, would 4=1 still cause the node

The flag is to tell the host to not use IPv4.  Once the host see the Flag=1, it should stop sending IPv4.

> * If 4=1, but later 4=0, shuld that transition of the 4 bit trigger IPv4

Then start using IPv4 again.

> affairs for many implementations (unfortunately).

OK, thanks.

Bob

---

From: David Farmer <[email-masked]>
Date: Fri, 17 Nov 2017 07:50:12 -0600

I think this is a good start. It covers the basic use case.  However as
currently defined, it says IPv4 is definitively not available and means the
network will not provide any backward compatibility for IPv4-only hosts. Or
for that matter, any early dual-stack hosts that do not support or can not
properly initialize a transition mechanism, such as NAT64. Further, if a
network operator wants to provide such backward compatibility it must
essentially provide a separate service to do so, such as a separate WiFi
SSID, and users need to understand the capabilities of there host to select
the proper service, which is not auto-configuration, or a very friendly
user experience.

It seems to me if we made a subtle change to the meaning of the flag, a
single service could support both IPv6-only and IPv4-only hosts. If the
meaning of the flag were modified to indicate that there is either no IPv4
service on the advertising router, or that any IPv4 service provided is
intended to be limited to only hosts needing it for backward
compatibility.  Primarily intended to support IPv4-only hosts, but could
also be used by dual-stack hosts that do not support or can not properly
initialize the transition mechanism(s) they support.

How is this different than providing dual-stack service as we know it
today?  Full dual-stack service needs to support IPv4 at scale for all
hosts on the network, what I'm proposing allows a limited scale legacy IPv4
service to be provided instead of a full scale IPv4 service.

I also suggest a "Host behavior" section be added.  Move the last paragraph
of section 2 into it, add that dual-stack hosts that support this flag and
properly initialize a transition mechanism that allows communication with
other the IPv4-only networks SHOULD NOT initialize their IPv4 stack.
Dual-stack hosts that support this flag and that do not support or cannot
initialize such a transition mechanism MAY attempt to initialize their IPv4
stack. It is expected that IPv4-only hosts and dual-stack hosts that do not
support this flag will attempt to initialize their IPv4 stack.

 Thanks.

On Fri, Nov 17, 2017 at 1:21 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

>     Brian and I took a cut a defining an IPv4 Availability Flag for IPv6
> ND Router Advertisements.  From the Introduction:
>
>     We were originally thinking it would be an April 1 submission, but
> after reading the discussion on the IPv6 list, we decided it makes sense as
> a real submission :-)
>
>     To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden" <
> [email-masked]>, "Brian Carpenter" <[email-masked]>
>
>
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 17 Nov 2017 09:00:05 -0500

Hi Bob,

How is this different from
https://tools.ietf.org/html/draft-ietf-sunset4-noipv4-01 ?

Thanks,
Simon

2017-11-17 1:42 GMT-05:00 Bob Hinden <[email-masked]>:

> *From: [email-masked]
> *To: *"Robert M. Hinden" <[email-masked]>, "Robert Hinden" <

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 17 Nov 2017 14:05:34 +0000

> Router Advertisements.  From the Introduction:

this idea was previously discussed in draft-ietf-sunset4-noipv4 /
draft-perreault-sunset4-noipv4 in ~april 2014.  At the time it failed to
gain consensus.

Nick

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 17 Nov 2017 22:08:01 +0800

I’ve the feeling reading your proposal that you’re assuming that the dual-stack hosts have the transition mechanism built-in. However, this is happening mainly in smartphones when attached to the 3G/LTE link.

If the case is for devices in a home or corporate network, and there is a need for IPv4, then it is the CE or router the one that manages the flag, and in that case, either the CE or router supports some transition mechanism (such as MAP or 464XLAT), or will set the flag to shop “no IPv4 available”.

So, unless I’m missing something, I don’t see the point for changing the flag from the actual text.

Regards,
Jordi

-----Mensaje original-----
De: David Farmer <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 17 de noviembre de 2017, 21:50
Para: Jordi Palet Martinez <[email-masked]>
CC: IPv6 List <[email-masked]>
Asunto: Re: New Version Notification for draft-hinden-ipv4flag-00.txt

    I think this is a good start. It covers the basic use case.  However as currently defined, it says IPv4 is definitively not available and means the network will not provide any backward compatibility for IPv4-only hosts. Or for that matter, any early dual-stack hosts that do not support or can not properly initialize a transition mechanism, such as NAT64. Further, if a network operator wants to provide such backward compatibility it must essentially provide a separate service to do so, such as a separate WiFi SSID, and users need to understand the capabilities of there host to select the proper service, which is not auto-configuration, or a very friendly user experience. 
    
    It seems to me if we made a subtle change to the meaning of the flag, a single service could support both IPv6-only and IPv4-only hosts. If the meaning of the flag were modified to indicate that there is either no IPv4 service on the advertising router, or that any IPv4 service provided is intended to be limited to only hosts needing it for backward compatibility.  Primarily intended to support IPv4-only hosts, but could also be used by dual-stack hosts that do not support or can not properly initialize the transition mechanism(s) they support.
    
    How is this different than providing dual-stack service as we know it today?  Full dual-stack service needs to support IPv4 at scale for all hosts on the network, what I'm proposing allows a limited scale legacy IPv4 service to be provided instead of a full scale IPv4 service.
    
    I also suggest a "Host behavior" section be added.  Move the last paragraph of section 2 into it, add that dual-stack hosts that support this flag and properly initialize a transition mechanism that allows communication with other the IPv4-only networks SHOULD NOT initialize their IPv4 stack. Dual-stack hosts that support this flag and that do not support or cannot initialize such a transition mechanism MAY attempt to initialize their IPv4 stack. It is expected that IPv4-only hosts and dual-stack hosts that do not support this flag will attempt to initialize their IPv4 stack.
    
     Thanks.
    
    On Fri, Nov 17, 2017 at 1:21 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:

    Regards,
    Jordi

    -----Mensaje original-----
    De: ipv6 <[email-masked]> en nombre de Bob Hinden <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: viernes, 17 de noviembre de 2017, 14:42
    Para: IPv6 List <[email-masked]>
    CC: Bob Hinden <[email-masked]>
    Asunto: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
    
        Hi,

    

    
        Thanks,
        Bob and Brian

        Begin forwarded message:

    

    

        Abstract:

    
        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 <http://tools.ietf.org> <http://tools.ietf.org>.
    
        The IETF Secretariat

    

    

    

    
    -- 
    ===============================================
    David Farmer               Email:[email-masked] <mailto:[email-masked]>
    Networking & Telecommunication Services
    Office of Information Technology
    University of Minnesota   
    2218 University Ave SE        Phone: 612-626-0815 <tel:(612)%20626-0815>
    Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(612)%20812-9952>
    ===============================================

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Nov 2017 09:49:51 -0500

> no IPv4 routers and/or IPv4 services. Monitoring of IPv6-only

Didn't we do all of this in sunset4 two years+ ago? I'm sure Lorenzo or Jen
remembers the debate and will correct my mis-representations.

I don't recall what happened to that work.

There is/was real pressure to tell the zillions of v4 machines on the cable model
networks to stop with the DHCPv4 queries, because they took up bandwidth.

Some had religious misgivings about using IPv6 to say something about IPv4.

The security consideration discusson went something like this:
    - this is a trivial DOS if there is really an IPv4 network
    - hosts that want to do v4 must therefore take this as advice, rather
      than gospel, and try the IPv4 anyway.
    - since they will try the IPv4 anyway, the goal of shutting them up
      fails.

However, I am enthusistic about such a flag, even if it is advice only and
everyone has to ignore it for security reasons.  It announces a desired
policy for the router issuing it.  It says, "I do not offer native IPv4"

It can moderate the hosts' enthuasiam for finding an IPv4, can ask the human
for advice, and if you want to mount a DOS against the IPv4 network, just use
DHCPv4 as people do now.

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

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Nov 2017 10:39:06 -0800

> The flag is to tell the host to not use IPv4.  Once the host see the Flag=1, it should stop sending IPv4.

The draft is very confused about what the flag means. And both of the conflicting descriptions in the draft are in conflict with this statement. Here are the three conflicting positions (I’m wondering how many will emerge before this can be sent back to the April 1 queue).

  — "IPv4 is Not Available on this Router"

  — "A host that receives only RAs with the flag set to 1 should not attempt IPv4 operations, unless it subsequently receives at least one RA with the flag set to zero."

  — "A host that receives Flag=1 should stop sending IPv4" (to what routers? on which interfaces? until what condition arises?).

Please send this draft back into the For Comedy Purposes Only category and leave the serious business of this topic to the SUNSET4 working group, which is actually chartered to deal with it.

--james woodyatt <[email-masked]>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 18 Nov 2017 07:31:58 +0800

James,

Cutting to the end:

> On Nov 18, 2017, at 2:39 AM, james woodyatt <[email-masked]> wrote:
> 

That’s harsh.

I note that the relevant draft in sunset4 has been updated in 3 years, and Sunset four hasn’t meet since IETF97.  Doesn’t seem like anything will happen there.

We wrote this to solve what I think is a real issue observed with the use of NAT64 on the IETF100 network.

Bob

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Nov 2017 18:20:03 -0800

> I note that the relevant draft in sunset4 has been updated in 3 years, and Sunset four hasn’t meet since IETF97.  Doesn’t seem like anything will happen there.

The SUNSET4 working group still has an active charter.

> We wrote this to solve what I think is a real issue observed with the use of NAT64 on the IETF100 network.

It’s not a good solution. The issue is quite a bit more complex than jamming a new flag into the RA message will allow.

Consider the current behavior of some of the products that my employers produce, which send RA messages (lifetime=0) on their Wi-Fi interfaces to distribute PIO elements to hosts that need ULA addresses in the Nest Weave fabric space. Under this draft, each currently fielded Nest device would cancel the 4=1 flag sent by any IPv6-only default gateway. Which is a kinda silly thing to do when you’re a router between Wi-Fi™ and Thread™ and Thread™ is an IPv6-only link layer. Wouldn’t you think setting 4=1 to be a good idea in that case? Alas, it’s not. If we do that, then any dual-stack hosts on a network with an IPv4-only CE router will shut off their IPv4 activity, and they will not get any IPv6 service through us. This is probably not what anyone wants, so we would of course never ever, not in a million years, never send 4=1 in our RA messages.

Now, you might say we shouldn’t send RA messages at all (even with lifetime=0) unless we are willing to be a default router. You might say that the default router should forward our Weave fabric prefix to us from hosts on the LAN. And I would say, that sounds like a capital idea, except each and every one of the workable technical alternatives to get hosts to self-assign on-link addresses, and set host route entries for a working route to the rest of the Weave fabric behind our local router, or at least to have a reliable means of routing on home networks through the usual default route at the CE router, have all been roundly rejected by industry and at least three separate IETF working groups. We do what we can because it’s the only thing that works.

So, no… we’re not going to stop sending RA messages (lifetime=0) . And so, we’re going to step on this 4=1 bit until the end of time. In other words, this draft won’t do what it hopes to do.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 18 Nov 2017 10:39:34 +0800

James,

> On Nov 18, 2017, at 10:20 AM, james woodyatt <[email-masked]> wrote:
> 

I hadn’t thought of this use case (using IPv6 on a link with only IPv4 internet connectivity), I agree that you would not want to be setting the flag to 1 unless you had knowledge of there not being any IPv4.

Would the issue be resolved if the text said something to the effect of only act on this flag if the router is also saying it is a default router, that is lifetime > zero?  I think that is the intent.   Seem to me this would allow you to continue your current operation and not disrupt the IPv4 on the link.

Also, who am I to argue that you shouldn’t use ULA addresses :-)

Bob

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 18 Nov 2017 17:46:42 +0900

On Sat, Nov 18, 2017 at 11:20 AM, james woodyatt <[email-masked]> wrote:

> Wouldn’t you think setting 4=1 to be a good idea in that case? Alas, it’s
> not. If we do that, then any dual-stack hosts on a network with an
> IPv4-only CE router will shut off their IPv4 activity, and they will not
> get any IPv6 service through us. This is probably not what anyone wants, so
> we would of course never ever, not in a million years, never send 4=1 in
> our RA messages.
>

Yep, a single flag won't work unless all routers agree on it. What about an
option that signified there was no IPv4 on the network? If the option is
sent by any of the routers on the link, then hosts would not attempt IPv4
configuration.

Not sure how that would support IPv4 becoming available once the option has
been set. Also, not clear how to deal with the DOS scenario where a rogue
RA disables all IPv4 on the network until the end of time.

---

From: Simon Hobson <[email-masked]>
Date: Sat, 18 Nov 2017 11:09:25 +0000

Lorenzo Colitti <[email-masked]> wrote:

> What about an option that signified there was no IPv4 on the network? If the option is sent by any of the routers on the link, then hosts would not attempt IPv4 configuration.

Doesn't that come with exactly the same problem as described ? If *ANY* router on the network provides IPv6 only, then it'll signal that there's no IPv4 on the network even though there may well be. Since that router may or may not actually provide full connectivity, and even if it does it may not be what the network people want devices to be using, then the end result is "device sends RA, breaks network".

> Not sure how that would support IPv4 becoming available once the option has been set.

Presumably the device would stop signalling that there's no IPv4, and then it's up to the hosts to decide if they will try configuring it.

> Also, not clear how to deal with the DOS scenario where a rogue RA disables all IPv4 on the network until the end of time.

That's not really a new threat. A rogue device can issue RAs and make itself the default router and break IPv6 - so the only new aspect is that it can break hosts that do try connecting via both IPv4 and IPv6. Looking ahead to the final destination of having no IPv4, then the end effect is the same - a rogue device can use RAs to break the network.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 18 Nov 2017 12:51:49 +0000

On Sat, 18 Nov 2017, 20:10 Simon Hobson, <[email-masked]> wrote:

> > What about an option that signified there was no IPv4 on the network? If
> the option is sent by any of the routers on the link, then hosts would not
> attempt IPv4 configuration.
>
> Doesn't that come with exactly the same problem as described ? If *ANY*
> router on the network provides IPv6 only, then it'll signal that there's no
> IPv4 on the network even though there may well be.
>

It would be up to the administrator to ensure that no router sent the
option unless the network were truly IPv4-only. So the situation you
describe would be a configuration error.

That would mean that the option could only be used in managed networks.

Not great, I agree.

---

From: Erik Kline <[email-masked]>
Date: Sat, 18 Nov 2017 22:12:28 +0900

I like this, and it seems similar to something that came out of some
sidebar conversations I was having in Singapore.

Here are a few changes I might suggest, followed by how I could see
implementing such a thing in an OS like Android.

    [1] I would propose making it an EFO bit and leave the reserved
bits for potentially more IPv6-critical information signaling.

    [2] I would not say that 0 means "IPv4 is Available on this
Router" but rather "this router makes no attestation about the
availability or lack thereof of IPv4".

The actual implementation that I could see being reasonable is as follows.

Because every OS starts IPv4 and IPv6 configuration paths in parallel
on link-up/link-attach, I think the most reasonable thing to do is to
interpret this flag as the "save your electrons flag".

In Android I think I would propose that we consider the bit only after
we have satisfactory global IPv6 provisioning, which I would define
as:

    [a] at least one valid (i.e. non-deprecated), non-ULA, GUA

    [b] at least one valid (i.e. non-deprecated) default route

    [c] at least one valid (i.e. non-deprecated) DNS server

Additionally, we could include a successful internet connectivity
check as a requirement, just to make sure we keep trying IPv4 until
any captive portal has been passed.

Finally: once IPv6 can be categorized as "working", and we saw no
other RAs with 0 in the extended flags options nor any RAs without
extended flags options, and we hadn't yet found any DHCPv4 server,
then we could use the "save your electrons" flag as a signal to stop
our DHCPv4 client.  Operating Systems that implement IPv4 link-local
communications (Android does not) might use this signal to disable
that as well.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 18 Nov 2017 13:15:34 +0000

Lorenzo Colitti wrote:
>     Doesn't that come with exactly the same problem as described ? If
>     *ANY* router on the network provides IPv6 only, then it'll signal
>     that there's no IPv4 on the network even though there may well be.
> 

there would also be a SAVI implication here; otherwise any connected
host on an l2 domain would be able to disable ipv4 on any host that was
listening to a flag of this form.

These and other issues were brought up before in the context of the
sunset4 draft.

Nick

---

From: Tim Chown <[email-masked]>
Date: Sat, 18 Nov 2017 13:24:13 +0000

> On 18 Nov 2017, at 13:12, Erik Kline <[email-masked]> wrote:
> 

So the flag might be the IPv4 equivalent hint to the IPv6 M/O flag, or it might be a stronger hint to also not auto configure a v4 LL.  I think when sunset4 last discussed this idea the focus was on the former case.

Perhaps this is this something to introduce with the PvD work?  The presence or not of v4 service is a property of a PvD, and in scenarios with multiple PvDs the host can choose to use v4 (or not) for each PvD?

Tim

---

From: Erik Kline <[email-masked]>
Date: Sat, 18 Nov 2017 22:41:37 +0900

> Perhaps this is this something to introduce with the PvD work?  The presence or not of v4 service is a property of a PvD, and in scenarios with multiple PvDs the host can choose to use v4 (or not)…

PvD information is for configuration information above and beyond
bootstrapping configuration.  Whether or not IPv4 service is available
on-link is part of the bootstrapping configuration.  Besides, the PvD
may provide IPv4 service via NAT64, but that's separate from what's
available on the link.

I think it should be a hint, yes.  But you raise a good point: IPv4
Internet access not being available on-link is different from, say,
0x0800 ethertype being filtered out by the infrastructure (perhaps 2
bits?).  Still, a hint would be useful for us to save transmitting
useless packets and we could even install a hardware filter to drop
all 0x800 in the wifi chip, further saving us from wake-ups (on
networks where 0x800 wasn't dropped).

---

From: Jen Linkova <[email-masked]>
Date: Sun, 19 Nov 2017 01:39:42 +1100

Hi Bob,

To be honest I'm not convinced that there is a real problem to be solved..
The draft says

'A mechanism is needed  to inform hosts that there is no IPv4 support
and that they should turn off IPv4.'
and it would be great to have more detailed problem statement IMHO...

It looks to me that when you are saying 'there is no IPv4 support on a
link' you mean 'a router does not provide IPv4 connectivity'.  However
it still might be
IPv4 connectivity within the given broadcast domain and the router has
nothing to do with it.

If the problem is 'IPv4 broadcast noise on the link' then it should be
solved on L2 level and the network should not switch ethertype 0x0800.
If the problem is 'all those noisy DHCPv4 requests the first-hop
router has to drop because DHCP relay is not configured' then the
router interface should not accept IPv4 packets at all, problem
solved.

Also it's not clear what a host is supposed to do if it'd been
receiving RAs with that flag set 0 and at some point subsequent RAs
started to arrive with that bit set to 1...
Shall the host stop all IPv4 operations attempts? Basically how that
information could be updated?

On Fri, Nov 17, 2017 at 5:42 PM, Bob Hinden <[email-masked]> wrote:
> reading the discussion on the IPv6 list, we decided it makes sense as a real
> submission :-)
>
> To: "Robert M. Hinden" <[email-masked]>, "Robert Hinden"
> <[email-masked]>, "Brian Carpenter" <[email-masked]>
>
>

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Nov 2017 20:00:09 +0800

> Bob Hinden <[email-masked]> wrote:
[....
> for advice, and if you want to mount a DOS against the IPv4 network, just use

It is not the same: the IPv5 could be protected sith something a la
dhcp-snooping, and unprotected nn the IPv6 side. And this mechanism
could allow an IPv4 DoS where otherwise not possible.

Note: The above is *not* an argument against this proposal, but rather
feedback aimed at raising awareness about possible issues. The above
should be described in the Sec Cons section.

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Nov 2017 20:14:41 +0800

On 11/18/2017 04:46 PM, Lorenzo Colitti wrote:
> On Sat, Nov 18, 2017 at 11:20 AM, james woodyatt <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Wouldn’t you think setting 4=1 to be a good idea in that case? Alas,
>     it’s not. If we do that, then any dual-stack hosts on a network with
>     an IPv4-only CE router will shut off their IPv4 activity, and they
>     will not get any IPv6 service through us. This is probably not what
>     anyone wants, so we would of course never ever, not in a million
>     years, never send 4=1 in our RA messages.
> 
> 
> Yep, a single flag won't work unless all routers agree on it. What about
> an option that signified there was no IPv4 on the network? If the option
> is sent by any of the routers on the link, then hosts would not attempt
> IPv4 configuration.

What would be the difference between encoding the info in an option vs
in a flag?

> Not sure how that would support IPv4 becoming available once the option
> has been set. Also, not clear how to deal with the DOS scenario where a
> rogue RA disables all IPv4 on the network until the end of time.

The only "fix" would be accepting that both versions of IP have become
more and more entangled, and as soon as there's an attack vector  in one
of them, the other version of the protocol can be screwed up. --
something along the lines of RFC7123 and  RFC7359.

Me, I'm generally of the idea of keeping both protocols as
separate/isolated as possible. But if the wg decides to pursue the idea
in this document, the above model of "now one version of the protocol
can be attacked via the other version" should be clearly stated.

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Nov 2017 08:59:22 +1300

Regards
   Brian Carpenter

> and it would be great to have more detailed problem statement IMHO...

Indeed. If there is no serious problem, don't fix. What I seemed to hear
in Singapore was that people weren't happy with just ignoring the small
amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurement
by Bob Hinden). However, from what I saw, most of it is layer 2 broadcast
traffic, which is more of a burden for the infrastructure. We need to decide
whether we care.

(As to whether this belongs in 6man or sunset4, that's a secondary question.
As for the other comments on this thread, I am too jet lagged to respond
right now... later.)

     Brian

---

From: Christian Huitema <[email-masked]>
Date: Sat, 18 Nov 2017 21:25:18 +0100

...
> traffic, which is more of a burden for the infrastructure. We need to decide

If people really care, they should just program the local routers and switches to block the IPv4 related multicast traffic. That will be much more direct than a bit in some RA.

> As for the other comments on this thread, I am too jet lagged to respond

How about a transition rule for dual stack implementations? If there is IPv6 connectivity, don’t bother trying to establish IPv4? Maybe qualify that rule with availability of a 6to4 prefix?

Yes, looks for something sunset4 should work on, if sunset4 is actually alive.

— Christian Huitema

---

From: Simon Hobson <[email-masked]>
Date: Sat, 18 Nov 2017 20:37:59 +0000

> traffic, which is more of a burden for the infrastructure. We need to decide

On that basis, isn't the simplest and most compatible (in that it doesn't need any systems to be updated to support it*) to configure filters in the infrastructure as already suggested ?

>> router interface should not accept IPv4 packets at all, problem

* The only requirement is that the infrastructure (APs, switches, routers) have the facility. And all this is in the hands of the network operator regardless of the nature of the clients connecting though it.

---

From: David Farmer <[email-masked]>
Date: Sat, 18 Nov 2017 16:07:03 -0600

> As for the other comments on this thread, I am too jet lagged to respond

Here is some analysis of the issues as I see them, hopefully this can help
lead us toward a problem statement;

I believe there are two separate issues here;

1. Security exposure; the inverse of the problems discussed in RFC7123,
basically malicious or accidental IPv4 service.
2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits,
IPv4-LL, ARP, service discovery, etc...

There are several solutions available already;

A. Filter Ethertypes 0x0800 and 0x806 altogether
B. Rogue DHCP server filtering or DHCP snooping
C. Proxy ARP
D. Service Discovery Proxy or Filtering

How much of an actual problem the issues are and the efficacy of solutions
depends on the type of network technology and the environment its used in;

For wired networks, the residual IPv4 traffic, even the fact that it's
mostly broadcast, isn't a significant issue.  The primary problem in here
is the security exposure, and solution B is usually sufficient protection,
but if that isn't, solution A will totally eliminate this risk.

For WiFi networks it's a little more complicate; low density WiFi
environments are similar to wired networks, the primary issue being the
security exposure, with the same solutions, discussed above. However, there
is an additional secondary issue, the residual IPv4 broadcast traffic could
unnecessarily impact other devices, especially battery powered devices.
Frequently, at least in enterprise WiFi networks, solutions C and D are
implemented to reduce the impact of IPv4 broadcast traffic in operational
WiFi networks, they will have the same effect on the residual IPv4
broadcast traffic in this case.  But, again solution A implemented within
the WiFi network will totally eliminate both the security exposure and the
impact of broadcast traffic on other devices.

However, the residual IPv4 traffic still consumes radio airtime, even if
the WiFi network discards the traffic. In very high dentistry and therefore
typically congested WiFi environments this unnecessary traffic only
increase the over-the-air congestion. Furthermore, broadcast traffic in a
WiFi networks consume more airtime that comparable unicast traffic (worst
case as much as 300 times, but 10-50 times is very typical), increasing the
impact of the residual IPv4 traffic that is mostly broadcast. Only a
solution that keep hosts from generating the residual IPv4 traffic in the
first place can help reduce over-the-air congestion in these environments.

Thanks

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Nov 2017 07:50:28 +0000

Agree with your analysis, but the problem I see is that many WiFi networks are very simple, even with high level of congestion, and they may not be able to apply such simple filters. Even home networks may have the same issues.

One way or the other, hosts get updated frequently, but switches, APs and L2 infrastructure don’t, even CEs or small routers in many hotspots don’t get updated.

Also, IPv4-only devices are typically never updated. For example, you buy today an IP camera, and is not easy to find one which is dual-stack. Of course, in this case the problem is different, because they will not work in a NAT64 IPv6-only network …

Because most of this traffic is created by laptops, tablets and smartphones that are the ones with frequently get updated, may be the ideal solution will be something in the stack, not relaying in the router update (so not relaying in RA, options, etc.), that automatically detects the lack of IPv4 support (trying to avoid fake DHCP servers), so they automatically stop sending any IPv4 traffic, or even using IPv4 link-local?

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de David Farmer <[email-masked]>
Responder a: <[email-masked]>
Fecha: sábado, 18 de noviembre de 2017, 22:07
Para: Brian E Carpenter <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

    On Sat, Nov 18, 2017 at 1:59 PM, Brian E Carpenter <[email-masked]> wrote:

    Regards
       Brian Carpenter

    
    
         Brian

    Here is some analysis of the issues as I see them, hopefully this can help lead us toward a problem statement;

    1. Security exposure; the inverse of the problems discussed in RFC7123, basically malicious or accidental IPv4 service. 
    2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits, IPv4-LL, ARP, service discovery, etc...

    
    How much of an actual problem the issues are and the efficacy of solutions depends on the type of network technology and the environment its used in;
    
    For wired networks, the residual IPv4 traffic, even the fact that it's mostly broadcast, isn't a significant issue.  The primary problem in here is the security exposure, and solution B is usually sufficient protection, but if that isn't, solution A will totally eliminate this risk.
    
    For WiFi networks it's a little more complicate; low density WiFi environments are similar to wired networks, the primary issue being the security exposure, with the same solutions, discussed above. However, there is an additional secondary issue, the residual IPv4 broadcast traffic could unnecessarily impact other devices, especially battery powered devices. Frequently, at least in enterprise WiFi networks, solutions C and D are implemented to reduce the impact of IPv4 broadcast traffic in operational WiFi networks, they will have the same effect on the residual IPv4 broadcast traffic in this case.  But, again solution A implemented within the WiFi network will totally eliminate both the security exposure and the impact of broadcast traffic on other devices.    
    
    However, the residual IPv4 traffic still consumes radio airtime, even if the WiFi network discards the traffic. In very high dentistry and therefore typically congested WiFi environments this unnecessary traffic only increase the over-the-air congestion. Furthermore, broadcast traffic in a WiFi networks consume more airtime that comparable unicast traffic (worst case as much as 300 times, but 10-50 times is very typical), increasing the impact of the residual IPv4 traffic that is mostly broadcast. Only a solution that keep hosts from generating the residual IPv4 traffic in the first place can help reduce over-the-air congestion in these environments. 

    Thanks

---

From: Simon Hobson <[email-masked]>
Date: Sun, 19 Nov 2017 10:50:00 +0000

> Agree with your analysis, but the problem I see is that many WiFi networks are very simple, even with high level of congestion, and they may not be able to apply such simple filters. Even home netw…

I would suggest that the sort of network (ie one aimed as very high user-counts) where the traffic is a real issue are also the sort of network running on "higher end" kit with the capability required, and run by people who understand the issues. For home networks, it's not going to be a real issue - other than in high-density situations (apartment blocks) where just things like 2.4GHz band congestion is already an issue.

> One way or the other, hosts get updated frequently

Not completely. See my post in the other thread, there's a lot of legacy stuff around. OK, Windows XP and WiFi in a sports stadium isn't going to be a significant issue, but a lot of users do not upgrade their phones every year or two - I'm only on my second in 2 decades ! And for older models, manufacturers have a tendency to simply abandon them so they won't get updates - for "older", this can mean "sold last month" if some of the anecdotes are correct.

> , but switches, APs and L2 infrastructure don’t, even CEs or small routers in many hotspots don’t get updated.

Again, I would suggest that where it matters, they'll get updated. If the operator sees a lot of IPv4 traffic and it's impacting on network performance, then they have an incentive to do something about it.

> ... that automatically detects the lack of IPv4 support (trying to avoid fake DHCP servers), so they automatically stop sending any IPv4 traffic, or even using IPv4 link-local?

How ?
How do you differentiate between a network with a missing DHCP4 server and one that doesn't run IPv4 at all ? If you simply assume that "no DHCP4 == no IPv4" then all that automagical networking using IPv4 LL will break. So realistically you can only assume there's no IPv4 if explicitly told - which comes back to having to have a mechanism to tell, and update everything involved to know about it.

Probably the best that can be done by the client is to be "less aggressive" in trying to configure IPv4 when IPv6 is available and you don't seem to see IPv4 traffic from other nodes. That way, if a network does employ L2 filtering, nodes will reduce their IPv4 broadcast traffic - but it shouldn't impact anything else.
Don't forget that in the cases being discussed (high density networks), the network operators typically have zero control over the clients connecting.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 19 Nov 2017 13:34:15 +0000

On Sun, 19 Nov 2017, 04:59 Brian E Carpenter, <[email-masked]>
wrote:

> However, from what I saw, most of it is layer 2 broadcast

Let's not forget about battery life. According to the numbers in RFC 7772,
on a phone even just sending DHCPv4 packets every 2 minutes could reduce
battery life by ~8% compared to a completely idle device.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 19 Nov 2017 14:25:07 +0000

Lorenzo Colitti wrote:
> Let's not forget about battery life. According to the numbers in RFC
> 7772, on a phone even just sending DHCPv4 packets every 2 minutes could
> reduce battery life by ~8% compared to a completely idle device.

is there any guarantee in this situation that any other apps would not
be chattering in the background over ipv6 anyway?  From what I've seen
on tcpdump, mobile phones tend to be extraordinarily noisy, and a dhcpv4
packet every two minutes would, in any situation where I've examined
mobile phone traffic from normal handsets, be nothing more than
background noise.

Also, the whole internet isn't a mobile phone network, and what might be
relevant or appropriate on a cell network might not be in any way
relevant to another type of network.  Without meaning to state the
obvious, it would be important to take this into account when framing
any problem statement.

One relatively straightforward way of dealing with extraneous dhcpv4
packets would be to create a new dhcpv4 reply option hinting to the
requester to cease DHCPv4 requests on the interface in question, or to
slow down the request rate from one every two minutes to one every X
minutes where X is network defined.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 19 Nov 2017 15:53:48 +0100 (CET)

> rogue RA disables all IPv4 on the network until the end of time.

I think any "No IPv4"-flag would need to be just a hint to the hosts, and 
it would only be relevant to the router actually sending that RA.

So if your normal DHCPv4 "give up" time is X, then if this flag it set, 
shorten X to something much less?

The IPv6 specs say M=1 is a hint that tells the host that it might use 
DHCPv6 to acquire addresses if it so wants, right? Nothing says it can't 
do IA_NA request if M=0, and nothing says a host does the wrong thing if 
it doesn't do IA_NA request? I think this flag should be the same level of 
hint, and then the rest is up to the host implementation to do what it 
think is best.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Nov 2017 08:28:49 +1300

On 20/11/2017 03:25, Nick Hilliard wrote:
> relevant to another type of network.  

My phone has been instructed to prefer WiFi when there is a choice.

> Without meaning to state the

The hypothesis of this draft is that there is no IPv4 support, hence
nobody to send a DHCP(v4) reply.

otoh, unable to resist solutionism even in this thread, a minor update
to RFC2131 would allow battery-powered devices to slow down the
DHCPDISCOVER rate as much as they want to.

    Brian

---

From: Simon Hobson <[email-masked]>
Date: Sun, 19 Nov 2017 21:05:15 +0000

> My phone has been instructed to prefer WiFi when there is a choice.

I think you've missed the point. Yes, there's a lot of phones around, but there are laptops, desktops, embedded systems, thermostats, doorbells/locks, ..... So it's not about whether a phone uses the mobile network or WiFi, it's about all those other devices that aren't mobile phones connected to networks that aren't mobile phone networks.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Nov 2017 10:19:46 +1300

> I think you've missed the point. Yes, there's a lot of phones around, but there are laptops, desktops, embedded systems, thermostats, doorbells/locks, ..... So it's not about whether a phone uses t…

Of course. What I meant is that you can't exclude cell phones from
the problem of what happens on WiFi, regardless of how they behave
on cellular.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 19 Nov 2017 22:10:31 +0000

> nobody to send a DHCP(v4) reply.

It just seems operationally simpler to create a new option in dhcpv4
with simple and clear semantics than define a new flag in RA, requiring
a vendor-defined (but out-of-scope for the ID) mechanism on each host to
get each client kernel to communicate something to the dhcpv4 client to
do the same thing.  There are a lot of things to go wrong in that path,
but far fewer if you have a stub dhcpv4 server handing out "ain't no
ipv4 here" messages on an otherwise unconnected ipv4 address.

> DHCPDISCOVER rate as much as they want to.

this would seem like an obvious and sensible optimisation.

Nick

---

From: David Farmer <[email-masked]>
Date: Sun, 19 Nov 2017 16:36:55 -0600

On Sun, Nov 19, 2017 at 1:50 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> Agree with your analysis, but the problem I see is that many WiFi networks
> are very simple, even with high level of congestion, and they may not be
> able to apply such simple filters. Even home networks may have the same
> issues.
>
> One way or the other, hosts get updated frequently, but switches, APs and
> L2 infrastructure don’t, even CEs or small routers in many hotspots don’t
> get updated.
>
> Also, IPv4-only devices are typically never updated. For example, you buy
> today an IP camera, and is not easy to find one which is dual-stack. Of
> course, in this case the problem is different, because they will not work
> in a NAT64 IPv6-only network …
>
> Because most of this traffic is created by laptops, tablets and
> smartphones that are the ones with frequently get updated, may be the ideal
> solution will be something in the stack, not relaying in the router update
> (so not relaying in RA, options, etc.), that automatically detects the lack
> of IPv4 support (trying to avoid fake DHCP servers), so they automatically
> stop sending any IPv4 traffic, or even using IPv4 link-local?
>
> Regards,
> Jordi
>

We're not going to be able drain the swamp of unmanaged networks and
devices.  They already have serious problems with rogue DHCP server, too
many broadcasts not letting battery powered devices sleep, security
problems like crazy, etc... Changing them to IPv6-only isn't going to
fundamentally fix their problems. In fact changing them to IPv6-only, I'm
afraid will only make their problems worse, not better.  I think IPv6-only
(tuning off IPv4) is a way forward for managed networks, not for unmanaged
networks. Unfortunately, I think unmanaged networks are better off with
dual-stack and keeping classic IPv4 support.

The open question in my mind is can a managed IPv6-only network support
unmanaged BYOD devices, that is my goal for this work. If both the network
and the devices are managed you should be able to do IPv6-only right now,
the 3G/LTE guys have shown that.  The open question is can we do the same
thing on managed WiFi and BYOD, with literally no control over the devices.

Thanks.

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Nov 2017 17:47:19 -0500

> How about a transition rule for dual stack implementations? If there is
    > IPv6 connectivity, don’t bother trying to establish IPv4? Maybe qualify
    > that rule with availability of a 6to4 prefix?

    > Yes, looks for something sunset4 should work on, if sunset4 is actually alive.

I think that Erik's description got things: it's about saving joules of power
by not trying too hard to find IPv4 when it's just not around.

I think that you (Christian) bring up the question for a future where IPv4
networks are rare and IPv6 is universally deployed.   Should we make some
provision today for that eventuality so that products in the field will do
the right thing at the right time?   What exactly do we mean by that?
(Not every device is a smartphone that gets replaced every two years and
firmware upgraded a few times a year)

Jen makes the good point that if we are concerned about the infrastructure
being bothered by 0x800 packets (and perhaps more annoying arp broadcasts),
then we should just block the packets in the right places.  I think that this
is sometimes good advice.  But, I'm a bit concerned when we advise blocking
things like that... how many of us have tried to run IPv6 LL traffic over an
infrastructure that decided anything !0x800 must be was evil?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 10:05:32 +0900

On Sun, Nov 19, 2017 at 11:25 PM, Nick Hilliard <[email-masked]> wrote:

> be chattering in the background over ipv6 anyway?

No, but a lot of that can be dropped in firmware more cheaply. Waking up to
send a packet is more expensive.

> relevant to another type of network.

The most relevant of which being, of course, DHCPv4 itself, which is not
used on cell networks. :-)

> minutes where X is network defined.

That would certainly work. Like any other DHCP option it would require
constant polling on the part of the client, but if X is high enough that
doesn't matter. Also, unlike the RA option, it makes it impossible to
change the flag with a network push, but in the long term that doesn't
matter either.

A harder problem is how to add this to DHCPv4 in a way that doesn't
negatively affect 20+ years of deployed client implementations. It can't
just be another option in the OFFER or ACK packets, since those contain the
client's IP address. I don't think it can be a new option in the NAK since
RFC 2131 says that if a client gets a NAK it should restart, and I bet
there are clients out there that restart immediately without waiting (which
would cause a loop). A new message type, with consequent modifications to
the DHCPv4 state machine? That seems pretty heavyweight.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 10:16:11 +0900

> DHCPDISCOVER rate as much as they want to.

I don't think the backoff schedule of current clients is dictated so much
by RFC2131 (e.g., Android already uses 120 seconds instead of 64) as it is
by operational expectations: if IPv4 appears you probably want to start
using it after a reasonable amount of time. In the absence of explicit
indication from the network, is it reasonable to back off sending
DHCPDISCOVER to once per hour? Day? Week? Year?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 11:44:51 +0900

> What would be the difference between encoding the info in an option vs

A flag only has two values, 0 or 1. A boolean option can have three values:
not present, 0 or 1. The same can be achieved through two flags, of course.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Nov 2017 15:16:49 +1100

> minutes where X is network defined.

The idea of using a protocol X to tell device 'there is no protocol X
on this link' sounds very entertaining ;)
If I run a single-stack network I do not want to configure IPv4
addresses, dhcp relays etc on v6-only interfaces
and most likely I have no desire to run DHCPv4 for those segments. I
might not even allow v4 traffic on the link at all
(as it reduces the attack surface).

There are two unrelated things which could be done:
A) To protect the network from excessive amount of undesirable (v4)
traffic some actions need to be taken on the network level. Those
actions
could not be completely delegated to hosts as most likely we are
talking about large number of devices, uncontrolled, potentially
outdated etc.
However the network indeed could provide some hints to hosts in case
those hosts are willing to listen. Here comes B)
B) To improve the device performance at v6-only network, the device
can do smth to detect the lack of IPv4 on the link (either explicitly,
like the RA flag we are discussing) or implicitly (no DHCPv4 replies
-> back-off etc).

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 16:28:30 +0900

> (as it reduces the attack surface).

Sure. But you wouldn't need complicated infrastructure for this - if all
that's necessary is to respond to a DHCPv4 request with a canned "no DHCPv4
here" packet that is always the same, that's a lot easier to deploy than a
full DHCPv4 infrastructure.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 20 Nov 2017 08:51:21 +0100 (CET)

On Mon, 20 Nov 2017, Lorenzo Colitti wrote:

> that's necessary is to respond to a DHCPv4 request with a canned "no 
> DHCPv4 here" packet that is always the same, that's a lot easier to 
> deploy than a full DHCPv4 infrastructure.

This functionality doesn't exist today in any access network I know of. 
It's also non-trivial to do considering how access networks are done. 
Preferrably one would like to ahve an ethertype filter on the access port 
to only allow 0x86dd and nothing else. Then putting this flag into IPv4 
means this isn't possible.

IPv6 is the next generation IP protocol. I prefer that it can signal that 
the legacy version is not available, instead of having to keep legacy IP 
functionality around.

... or we put it in some other L2 protocol, such as LLDP.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Nov 2017 15:33:05 +0100

Le 20/11/2017 à 08:51, Mikael Abrahamsson a écrit :
>> Sure. But you wouldn't need complicated infrastructure for this - if 
>> all that's necessary is to respond to a DHCPv4 request with a canned 
>> "no DHCPv4 here" packet that is always the same, that's a lot easier 
>> to deploy than a full DHCPv4 infrastructure.
> 

That may not exist, but the counterpart functionality of blocking all 
that is _not_ IPv4 may exist.

On my enterprise IPv4-only network my laptop's RJ45 leds did not even 
blink this morning.  It was because I had unchecked IPv4 on my Windows, 
because I used in the Terminal Room at IETF, which was IPv6 only.

I suppose the switches on my enterprise network block all RJ45 that dont 
reply to IPv4, and block them hardly (RJ45 leds are off).

Same laptop connected to a dumb hub had the leds on.

Alex

[snip]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Nov 2017 15:50:06 +0100

Le 19/11/2017 à 08:50, JORDI PALET MARTINEZ a écrit :
> Agree with your analysis, but the problem I see is that many WiFi 
> networks are very simple, even with high level of congestion, and 
> they may not be able to apply such simple filters. Even home
> networks may have the same issues.
> 
> One way or the other, hosts get updated frequently, but switches,
> APs and L2 infrastructure don’t, even CEs or small routers in many 
> hotspots don’t get updated.
> 
> Also, IPv4-only devices are typically never updated. For example,
> you buy today an IP camera, and is not easy to find one which is 
> dual-stack.

I tend to agree with this text, Jordi.

Recently I contacted a manufacturer of advanced camera-like lidars.
They do IPv4 only and broadcast to 255.255.255.255.  They request the
user to use closed circuits to avoid the noise due to broadcast.  They
said they dont have plans for IPv6 in the camera, in their roadmaps.

So we filed a ticket to add IPv6 in the device, hoping for some
resolution in a certain future.

Alex

  Of course, in this case the problem is different, because
> they will not work in a NAT64 IPv6-only network …
> 
> smartphones that are the ones with frequently get updated, may be
> the ideal solution will be something in the stack, not relaying in
> the router update (so not relaying in RA, options, etc.), that 
> automatically detects the lack of IPv4 support (trying to avoid fake 
> DHCP servers), so they automatically stop sending any IPv4 traffic, 
> or even using IPv4 link-local?
> 
> Regards, Jordi
> 
> 
> -----Mensaje original----- De: ipv6 <[email-masked]> en
> nombre de David Farmer <[email-masked]> Responder a: <[email-masked]>
> Fecha: sábado, 18 de noviembre de 2017, 22:07 Para: Brian E
> Carpenter <[email-masked]> CC: 6man WG <[email-masked]>
> Regards Brian Carpenter
>> To be honest I'm not convinced that there is a real problem to be 
>> solved.. The draft says
>> 
>> 'A mechanism is needed  to inform hosts that there is no IPv4 
>> support and that they should turn off IPv4.' and it would be great 
>> to have more detailed problem statement IMHO...
> 
> Indeed. If there is no serious problem, don't fix. What I seemed to 
> hear in Singapore was that people weren't happy with just ignoring 
> the small amount of residual IPv4 traffic on ietf-nat64 (about 1% in 
> the measurement by Bob Hinden). However, from what I saw, most of it 
> is layer 2 broadcast traffic, which is more of a burden for the 
> infrastructure. We need to decide whether we care.
> 
> (As to whether this belongs in 6man or sunset4, that's a secondary 
> question. As for the other comments on this thread, I am too jet 
> lagged to respond right now... later.)
> 
> Brian
> 
> 
> 
> Here is some analysis of the issues as I see them, hopefully this
> can help lead us toward a problem statement;
> 
> 1. Security exposure; the inverse of the problems discussed in 
> RFC7123, basically malicious or accidental IPv4 service. 2. Residual 
> IPv4 traffic, especially broadcast traffic; DHCP solicits, IPv4-LL, 
> ARP, service discovery, etc...
> 
> A. Filter Ethertypes 0x0800 and 0x806 altogether B. Rogue DHCP
> server filtering or DHCP snooping C. Proxy ARP D. Service Discovery
> Proxy or Filtering
> 
> How much of an actual problem the issues are and the efficacy of 
> solutions depends on the type of network technology and the 
> environment its used in;
> 
> For wired networks, the residual IPv4 traffic, even the fact that 
> it's mostly broadcast, isn't a significant issue.  The primary 
> problem in here is the security exposure, and solution B is usually 
> sufficient protection, but if that isn't, solution A will totally 
> eliminate this risk.
> 
> environments are similar to wired networks, the primary issue being 
> the security exposure, with the same solutions, discussed above. 
> However, there is an additional secondary issue, the residual IPv4 
> broadcast traffic could unnecessarily impact other devices, 
> especially battery powered devices. Frequently, at least in 
> enterprise WiFi networks, solutions C and D are implemented to
> reduce the impact of IPv4 broadcast traffic in operational WiFi
> networks, they will have the same effect on the residual IPv4
> broadcast traffic in this case.  But, again solution A implemented
> within the WiFi network will totally eliminate both the security
> exposure and the impact of broadcast traffic on other devices.
> 
> However, the residual IPv4 traffic still consumes radio airtime,
> even if the WiFi network discards the traffic. In very high dentistry
> and therefore typically congested WiFi environments this unnecessary 
> traffic only increase the over-the-air congestion. Furthermore, 
> broadcast traffic in a WiFi networks consume more airtime that 
> comparable unicast traffic (worst case as much as 300 times, but 
> 10-50 times is very typical), increasing the impact of the residual 
> IPv4 traffic that is mostly broadcast. Only a solution that keep 
> hosts from generating the residual IPv4 traffic in the first place 
> can help reduce over-the-air congestion in these environments.
> 
> 
> Thanks
> 
> -- =============================================== David Farmer 
> Email:[email-masked] <mailto:[email-masked]> Networking & 
> Telecommunication Services Office of Information Technology 
> University of Minnesota 2218 University Ave SE        Phone: 
> 612-626-0815 <tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell:
> 612-812-9952 <tel:(612)%20812-9952> 
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> ********************************************** IPv4 is over Are you 
> ready for the new Internet ? http://www.consulintel.es The IPv6 
> Company
> 
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents 
> of this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If
> you are not the intended recipient be aware that any disclosure,
> copying, distribution or use of the contents of this information,
> even if partially, including attached files, is strictly prohibited,
> will be considered a criminal offense, so you must reply to the
> original sender to inform about this communication and delete it.
> 
> 
> 
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 20 Nov 2017 10:54:02 -0400

Hello,

El 20/11/17 a las 10:33 a.m., Alexandre Petrescu escribió:
> blink this morning.  It was because I had unchecked IPv4 on my
> Windows, because I used in the Terminal Room at IETF, which was IPv6
> only.
>
> I suppose the switches on my enterprise network block all RJ45 that
> dont reply to IPv4, and block them hardly (RJ45 leds are off).

What a interesting situation..., may I ask which switches are you using?
(if you don't want to mention it publicly I accept unicast)

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 20 Nov 2017 15:59:32 +0000

> It's also non-trivial to do considering how access networks are done.

Both of these statements also apply to encoding a no-ipv4 flag in an RA
message.

> Preferrably one would like to ahve an ethertype filter on the access
> port to only allow 0x86dd and nothing else. Then putting this flag into
> IPv4 means this isn't possible.

if you can filter everything except 0x86dd (or the equivalent for
different media, e.g. docsis, pppoe, etc), then the ipv4 problem
statement which draft-hinden-ipv4flag is intended to solve has already
been handled.

> IPv6 is the next generation IP protocol. I prefer that it can signal
> that the legacy version is not available, instead of having to keep
> legacy IP functionality around.
> 

It comes down where in your stack you want to put your hacks.  A sentry
dhcpv4 agent is simple to define in terms of protocol scope, behaviour
and meaning, and has relatively well constrained requirements in terms
of the amount of ipv4 infrastructure required to sustain it (virtually
none, in the minimal case).

If you want to define and implement this functionality via some other
protocol, it requires potentially substantial complication on the client
side, as well as creating a requirement to define what is meant by "no
ipv4".  This, IIRC, was one of the issues that led to the sunset4 draft
not progressing further.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 13:29:32 +1300

Hi,

Here are some consolidated responses to a very long thread:

> draft-ietf-sunset4-noipv4

Sorry we were unaware of that. I think that a new look at
this approach is needed given the increased experience
that we now have. But at the very minimum our draft
should recognize the earlier work.

>  If the
> compatibility... what I'm proposing allows a limited scale legacy IPv4

I think that semantic ("we have IPv4 but please don't use it") is
unlikely to work in our dog-eats-dog Internet.

> I also suggest a "Host behavior" section be added.

Good idea.

> I’ve the feeling reading your proposal that you’re assuming that the dual-stack hosts have the transition mechanism built-in

That's certainly not my intention. Cellular networks are different,
but in a general-purpose network, classical dual stack hosts is
the only safe assumption. We should clarify the document scope.

> - this is a trivial DOS if there is really an IPv4 network

Any single occurrence of flag==0 says IPv4 is available. Any number
of flag==1 does not change this. So this attack does not exist.
 
>   — "A host that receives Flag=1 should stop sending IPv4" 

Yes, that is wrong as a stand-alone statement; it needs to be
qualified (in the simplest case, "only Flag=1", but it needs
to refer to unexpired router lifetimes, so more words are needed.)
 
> So, no… we’re not going to stop sending RA messages (lifetime=0) . And so, we’re going to step on this 4=1 bit until the end of time. In other words, this draft won’t do what it hopes to do.

So who is defeating the intent of the existing standards there?
OK, maybe we'd better not have that conversation. We'll think
about whether special-casing lifetime==0, but the solution is
fail-safe: even one unexpired RA with flag==0 will override any
number of flag==1. We will never switch off IPv4 in such a case.

> Yep, a single flag won't work unless all routers agree on it.

That's a feature, not a bug. That's why the proposal is fail-safe.

> option unless the network were truly IPv4-only.

No. It's router-by-router, so *all* routers must send flag==1 to
change host behaviour to IPv6-only. Default host behaviour is
dual stack.

> bits for potentially more IPv6-critical information signaling.

Don't you think that switching off IPv4 is IPv6-critical? :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 13:39:56 +1300

Hi,

This time, not truncated by fat-fingering.

Good idea.

 

> availability or lack thereof of IPv4"

I'm not sure.  It doesn't really matter, because it's only when
there are no unexpired RAs with flag==0 that we switch off IPv4.
So the only assertion that matters is that flag==1 means "I don't
route IPv4, but I don't know what other routers do."

> listening to a flag of this form.

No. As long as at least one unexpired RA has flag==0, nobody stops
trying IPv4. A bad actor can send as many flag==1 bogons as it
wants; they will be no-ops.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Nov 2017 14:42:26 +1300

> If people really care, they should just program the local routers and switches to block the IPv4 related multicast traffic. That will be much more direct than a bit in some RA.

Layer 2 or layer 3 blocking is fine, but it doesn't help
the battery life of the dual stack hosts.

> How about a transition rule for dual stack implementations? If there is IPv6 connectivity, don’t bother trying to establish IPv4? Maybe qualify that rule with availability of a 6to4 prefix?

I really hope you didn't mean "6to4". But that heuristic will only help
if all apps are IPv6-capable, which the IP stack cannot know. (It also
leaves IPv4 literals out in the cold.)

> IPv4-LL, ARP, service discovery, etc...

The proposal addresses only one thing: attempting to reduce
futile IPv4 traffic. It neither creates nor blocks IPv4 traffic.

> In very high dentistry and therefore
> typically congested WiFi environments...

A new view of dentist's office networking ;-)

> Probably the best that can be done by the client is to be "less aggressive" in trying to configure IPv4 when IPv6 is available and you don't seem to see IPv4 traffic from other nodes.

Indeed, but that's mainly an implementation choice. This proposal offers
a hint to assist that heuristic, if you like.

> Let's not forget about battery life.

Agreed. Every little helps.

> It just seems operationally simpler to create a new option in dhcpv4

I don't see how that works on a network with no DHCPv4 server.

> if IPv4 appears you probably want to start
> using it after a reasonable amount of time.

Indeed. And under the proposal, any RA with flag==0 would be
an instant trigger to wake up the IPv4 stack. (And no, that
isn't a serious DOS risk, since it is no worse than what
we have today.)

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Nov 2017 06:49:11 +0100 (CET)

> It comes down where in your stack you want to put your hacks.  A sentry

Indeed. And I'd rather put this hack in IPv6, as it requires adding code 
to configure and send an additional RA option compared to requiring a 
complete IPv4 stack and DHCPv4 code to send some option there.

In 5-10 years, I might not want an IPv4 stack in a lot of network 
equipment.

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Nov 2017 12:39:30 +0100

We might consider disabling IPv4 on a network in the same fashion that we did it for AppleTalk, Apollo Domain, Banyan VINES, DECNet, CLNS, XNS, IPX...

This isn't a new problem.

Ole

> On 21 Nov 2017, at 06:49, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Indeed. And I'd rather put this hack in IPv6, as it requires adding code to configure and send an additional RA option compared to requiring a complete IPv4 stack and DHCPv4 code to send some option there.
> 
> In 5-10 years, I might not want an IPv4 stack in a lot of network equipment.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Nov 2017 13:32:44 +0100 (CET)

> This isn't a new problem.

The new thing is that most devices nowadays are connected using radio and 
not wired, the way they were before. Also, back on those days security 
typically wasn't high on the agenda. How many worried about MITM attacks 
on those protocols?

Also, they were typically used in managed environments. BYOD wasn't really 
a thing back then.

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Nov 2017 07:43:43 -0600

...

> futile IPv4 traffic. It neither creates nor blocks IPv4 traffic.

That might be, but this thread is about a problem statement, and
conceivably that could add to the draft. Anyway we shouldn't ignore #1, I
think at least something should be said in the security considerations
section on the subject.  Also since this uses RAs, the security
considerations section should probably say something about rogue RAs and
the options to protect against them.

> A new view of dentist's office networking ;-)

Serendipitous and amusing autocorrecto :)

....

> isn't a serious DOS risk, since it is no worse than what

Should Router Preference [RFC4191] play in this equation?  Should an RA
with a Router Preference = High and this flag = 1 be overridden by
different RA with Router Preference = Low and this flag = 0. I'm not sure I
have an answer, but this probably should be addressed in the draft either
way.

I bring this up as setting Router Preference to High is a common technique
to help protect against at least accidental RAs. Yes malicious RAs can use
a Router Preference of High, but all rogue RAs I've seen in the wild had a
medium (default) Router Preference.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Nov 2017 15:47:04 +0000

> complete IPv4 stack and DHCPv4 code to send some option there.

I agree it will simplify things on the operator side, slightly.  The
complication on the client side is substantial though, and it's usually
the client side where we run into deployment problems due to high levels
of heterogeneity and in this case, layering issues, i.e. using ipv6 to
signal to a kernel which needs to message-pass to a dhcpv4 userland
process to stop issuing queries on a specific interface or to otherwise
implement what we mean by this flag.  There would also be a requirement
for the network edge to be able to filter out RAs with this option,
given that the ipv6 / RA model is to be able to deploy multiple routers
and we cannot assume that this flag would be limited to e.g. cellular
networks or resi access networks or whatever.  This added complication
is why I question the wisdom of the RA approach.  Simple, even if it
doesn't solve everything, is usually better.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Nov 2017 17:17:24 +0100 (CET)

> doesn't solve everything, is usually better.

Then I guess we should not do anything on the protocol side, and just have 
a sunset4 document that tells hosts that "if you get IPv6 and there seems 
to be no IPv4 in any timely fashion, stop asking for IPv4 information".

I think this is what Ole is saying he wants.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Nov 2017 01:18:13 +0900

On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard <[email-masked]> wrote:

> complication on the client side is substantial though,

As an implementer I don't think it would make much of a difference. Yes,
maybe the DHCPv4 option is slightly simpler, but in practice IPv4 and IPv6
provisioning need to be tightly coordinated anyway for things to work well.

> There would also be a requirement

Why is it not sufficient to configure the routers that emit the RAs?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Nov 2017 13:28:47 -0500

Mikael Abrahamsson <[email-masked]> wrote:
    nick> is why I question the wisdom of the RA approach.  Simple, even if it
    nick> doesn't solve everything, is usually better.

    > Then I guess we should not do anything on the protocol side, and just have a
    > sunset4 document that tells hosts that "if you get IPv6 and there seems to be
    > no IPv4 in any timely fashion, stop asking for IPv4 information".

    > I think this is what Ole is saying he wants.

And hosts should do this for both v4 and v6 by heuristic anyway, because no
matter what we do, it won't be deployed tomorrow.
So that BCP is worth writing.

I'd also like to see a recommendation not to configure IPv4 LL so quickly,
the way that many systems do today, preferring to use v6LL.  Why? because I
think that v4-ARPs wake up more hosts than v6 NDs, and we also have efficient-ND.

We had a WG a decade ago called Detecting Network Attachment (DNA)... I'm
sure that there are documents we could reference... and I think this (BCP) work
belongs in sunset4.

I wonder if we can get consensus on the above statement?

====

Having SAID all of that, I still believe that an RA option (not flag bit)
that declared on behalf of the router, "I do not speak IPv4" might be worth
standardizing.  Perhaps, we should rather name the option, "I speak only IPv6"
since many of the devices also do not not speak XNS or AppleTalk.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 21 Nov 2017 21:38:32 +0100

Le 21/11/2017 à 12:39, Ole Troan a écrit :
> We might consider disabling IPv4 on a network in the same fashion
> that we did it for AppleTalk, Apollo Domain, Banyan VINES, DECNet,
> CLNS, XNS, IPX...
> 

Let me remember.
When I switched a PC AT 286 from IPX to TCP/IP it was because the latter
gave access to remote servers and persons rather than just big disk on a
local LAN.  Sunsite.doc.ic.ac.uk was important because, among other
things, gave access to RFCs, which IPX LAN server wouldnt.

This would translate today into putting the RFCs and I-Ds on IPv6 only.
(datatracker, tools.ietf.org, etc)  Or the email lists, or the other
services.

Alex

>> Indeed. And I'd rather put this hack in IPv6, as it requires adding
>> code to configure and send an additional RA option compared to
>> requiring a complete IPv4 stack and DHCPv4 code to send some option
>> there.
>> 
>> -- Mikael Abrahamsson    email: [email-masked]
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 21 Nov 2017 21:03:17 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu

> When I switched a PC AT 286 from IPX to TCP/IP it was because the
> latter gave access to remote servers and persons rather than just
> big disk on a local LAN.  Sunsite.doc.ic.ac.uk was important because,
> among other things, gave access to RFCs, which IPX LAN server wouldnt.

Enterprise nets were running multiple protocols including IP, and it became easier to just use IP. I would say, analogous to running dual stack today, and then eventually you drop IPv4.

In my case, we had all switched over to WFWG at some point, so we all had the IP stack installed in hosts already. Over time, the only app we were using DECnet for became e-mail (VMSmail), so we simply switched over to a different e-mail system. That seems like where we might end up with IPv4, but not there yet.

At home, ISP dialup service was always IP and only IP. That followed after the enterprise network at work, though.

> (datatracker, tools.ietf.org, etc)  Or the email lists, or the other

Not really comparable, right? The vast majority of people can't even spell IETF, let alone care about reading RFCs. Yes, even the vast majority of people on enterprise networks, couldn't care less about reading RFCs. So this would just become a nuisance for many people, especially those whose enterprise nets do not support IPv6 yet.

Bert

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Nov 2017 22:33:05 +0000

> Why is it not sufficient to configure the routers that emit the RAs?

because you're assuming congruity between ipv4 and ipv6 connectivity on
a network, which is not codified in any ietf document that I'm aware of.
 If there is a incongruity between management of the two protocols, then
the l2 network must have a mechanism to stop an ipv6 gateway from
attempting shutting down ipv4 services.

Nick

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 Nov 2017 22:40:20 +0000

> since many of the devices also do not not speak XNS or AppleTalk.

I agree it should denote "I'm IPv6-only".  But I don't think we need
to take a full 8 bytes (minimum ND option size) to say this.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Nov 2017 13:15:02 +1300

> attempting shutting down ipv4 services.

This is a very interesting point. If every IPv6 router on a link believes
there is no IPv4 router/DHCP service, they would all send flag==1 in the
proposed solution. So the proposal only works if at least one IPv6 router
is colocated with an IPv4 router, and therefore knows to send flag==0.
Oops.

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 22 Nov 2017 00:23:39 +0000

> is colocated with an IPv4 router, and therefore knows to send flag==0.

This would lead to a race condition on the client + a requirement for
suitable semantics to be defined in the spec to work out what to do if
mixed signals were received from different ipv6 routers.  This assumes
that you can send out an RA with flag==0 in order to mean that ipv4
should be re-enabled again.

Nick

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Nov 2017 16:35:38 -0800

I read through the thread and part of the draft. I think there is a fundamental issue.

>    there is no IPv4 service on the advertising router.

That doesn't tell the receiver anything about other routers, and especially IPv4-only routers that might exist in the environment. I don't think one can conclude from the receipt of an RA, or for that matter every RA from every IPv6-capable router in the environment, that there is no IPv4 service in the environment. One might conclude that from the lack of a response to a DHCP request for an IPv4 address. What I would expect the host to do is an exponential backoff to only asking for an address every mumble minutes, which would be lost in the noise.

I don't see the point.

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Nov 2017 18:42:22 -0600

> is colocated with an IPv4 router, and therefore knows to send flag==0.

This is a problem only if the flag is set automatically and their is no
mechanism to override the automatic setting.  Most routers with an IPv6
address configured on an interface by default will send an RA unless you
configure them not to.  So, an IPv6 router without IPv4 configured on the
interface should set this flag, unless configured otherwise.  In other
words you need to be able to tell an IPv6 router there is IPv4 on the
interface even if router is not providing it.

It is quite possible that the IPv6 topology is incongruous from the IPv4
topology, however it is doubtful than the management is also incongruous.

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Nov 2017 15:32:27 +1300

> topology, however it is doubtful than the management is also incongruous.

Yes, but do you think we should push a mechanism that assumes correct
configuration by humans in order to work reliably? 
(Arguing against my own proposal, not for the first time ;-).

     Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Nov 2017 21:52:17 -0600

> (Arguing against my own proposal, not for the first time ;-).

If you have the funds to build two separate infrastructures, which is what
we are talking about here, one for IPv4 and separate one for IPv6, you
should have the funds to pay for humans smart enough to manage the two
separate infrastructures.  An IPv6 topology incongruous from the IPv4
topology is not going to be a common deployment model, at least for anyone
who will be relying on auto-configuration.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Nov 2017 18:37:11 +0900

> attempting shutting down ipv4 services.

I don't get it. That's a configuration error. If the operator misconfigures
the network, then the network doesn't work.

Sure, the proposed solution won't work when IPv4 and IPv6 are managed by
different operators. That doesn't seem like a big drawback, since this
situation is quite rare.

---

From: james woodyatt <[email-masked]>
Date: Mon, 27 Nov 2017 11:41:47 -0800

On Nov 18, 2017, at 05:12, Erik Kline <[email-masked]> wrote:
> 
> Operating Systems that implement IPv4 link-local communications (Android does not) might use this signal to disable that as well.

Dear Apple and Microsoft: please do not do that or you will break Nest Weave pairing on your handsets in networks where IPv6 multicast is blocked at the Wi-Fi access point. We fall back to IPv4 link-local broadcast when we can’t use IPv6 link-local multicast for service discovery.

---

From: james woodyatt <[email-masked]>
Date: Mon, 27 Nov 2017 12:14:16 -0800

On Nov 18, 2017, at 06:39, Jen Linkova <[email-masked]> wrote:
> 
> It looks to me that when you are saying 'there is no IPv4 support on a link' you mean 'a router does not provide IPv4 connectivity'.  However it still might be IPv4 connectivity within the given broadcast domain and the router has nothing to do with it.

Indeed, and this is an important to distinction to bear in mind. I hope everyone involved in this discussion remembers it.

> If the problem is 'IPv4 broadcast noise on the link' then it should be solved on L2 level and the network should not switch ethertype 0x0800.

Better would be not to switch Ether Type 0x806 when the PTYPE=0x800. Or it should reject configuration via IPCP. Or or or...

> If the problem is 'all those noisy DHCPv4 requests the first-hop router has to drop because DHCP relay is not configured' then the router interface should not accept IPv4 packets at all, problem solved.

If the problem is noisy hosts using IPv4 group communication for mDNS and DHCP discovery, then the problem is the same as “IPv4 broadcast noise on the link” and it should be handled the same way.

If you want to stop link-local IPv4 communication on the link, the right way to do that is by blocking ARP with PTYPE=0x800, and probably some kind of ARP packet that specifically tells IPv4 implementations that this network will never deliver an ARP packet with PTYPE=0x800 to a host so it can stop trying.

If you want to stop noisy hosts trying to reach Internet via IPv4 via an unprovisioned route, then the right way to tell them to shut them up is to decline DHCP requests for IPv4 default router address, and tell host operating system developers that when the only DHCP server on the link is declining to configure any IPv4 default router address, it’s not a misconfiguration: the network really means it, there is no default IPv4 router. (In the PPP case, provide only an IPv4 link-local address.)