Subject: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

From: [email-masked]
Date: Tue, 16 Oct 2018 16:09:31 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : IPv6 Router Advertisement IPv6-Only Flag
        Authors         : Robert M. Hinden
                          Brian Carpenter
	Filename        : draft-ietf-6man-ipv6only-flag-03.txt
	Pages           : 12
	Date            : 2018-10-16

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6only-flag/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-03
https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6only-flag-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6only-flag-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Oct 2018 14:39:56 +1300

Hi,

We've attempted in this version to respond to the comments received during WGLC.

The most important change is this:
      *  Reorganized text about problem statement and applicability
We hope the new text makes it clear how the solution relates to other
solutions (layer 2 filtering or using a DHCPv4 option).

There are a number of other changes:
      *  Added note about shortage of flag bits
      *  Clarified text about logging configuration error in Section 6
      *  Editorial changes.

Regards
    Brian + Bob

-------- Forwarded Message --------
Subject: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt
Date: Tue, 16 Oct 2018 16:09:31 -0700
From: [email-masked]
Reply-To: [email-masked], [email-masked]
To: [email-masked]
CC: [email-masked]

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 17 Oct 2018 18:08:49 +0200

>        *  Clarified text about logging configuration error in Section 6

Brian

-03 polishes some peripheral stuff but doesn't substantially address any 
of the issues I've brought up over the last couple of months.

Chairs: none the issues I've raised previously have been substantially 
addressed in this revision.  Do we need to go through all these issues 
again, individually, on the mailing list for them to be considered as 
outstanding in this draft?

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Oct 2018 08:54:53 +1300

Nick,
> of the issues I've brought up over the last couple of months.

The authors think that all your points are in fact dealt with in the
text. You may not agree with the way they are dealt with, but we believe
that we have made it clear that the proposed mechanism is an optional
addition to other mechanisms and that it is adequately secure. Whether
it gets implemented and deployed is, as for every proposed extension,
outside our control.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 17 Oct 2018 23:48:27 +0200

Hi Nick,

> -03 polishes some peripheral stuff but doesn't substantially address any of the issues I've brought up over the last couple of months.
> 
> Chairs: none the issues I've raised previously have been substantially addressed in this revision.  Do we need to go through all these issues again, individually, on the mailing list for them to be considered as outstanding in this draft?

If you believe there are comments within the scope of the draft that hasn’t been addressed I suggest you bring them back to the list. 

If there are several I can set up an issue tracker for this draft. 

Cheers 
Ole

---

From: David Schinazi <[email-masked]>
Date: Thu, 18 Oct 2018 10:28:24 -0700

Hello,

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

-03 does not address my concerns, it adds notes acknowledging my points,
but the notes do not solve the underlying issues I raised. IPv6 RAs are not
necessarily the right place to solve the issue described, and I have yet to
hear client host manufacturers indicate they are interested in this work.
Is there even running code of this proposal? I think making this a standard
would be premature at this point.

Thanks,
David Schinazi

On Wed, Oct 17, 2018 at 2:48 PM Ole Troan <[email-masked]> wrote:

> If you believe there are comments within the scope of the draft that
> hasn’t been addressed I suggest you bring them back to the list.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 18 Oct 2018 21:09:37 +0200

Hi David,

> I am still opposed to advancing draft-ietf-6man-ipv6only-flag to Proposed Standard.
> 
> -03 does not address my concerns, it adds notes acknowledging my points, but the notes do not solve the underlying issues I raised. IPv6 RAs are not necessarily the right place to solve the issue described, and I have yet to hear client host manufacturers indicate they are interested in this work. Is there even running code of this proposal? I think making this a standard would be premature at this point.

Do I understand you correctly that your objections are not with the proposed protocol mechanism in the draft? I.e. the technical part, but you believe that doing this with an RA is the wrong solution.
Do I understand you correctly that there is no text in the draft that could resolve this, as you are principally against an RA based solution?
It would be great if you could expand on your reasoning for the objection, because I’m not sure I have understood it.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Oct 2018 13:20:04 +0200

Le 18/10/2018 à 19:28, David Schinazi a écrit :
[...] Is there even running code of this proposal?

Do you think it is difficult?

I am asking because I see three parts to 'running code' of this proposal:

1. realizing in practice that there is a problem.  This part of the
    implementation is ok, because there is reporting of testing it
    (Singapour).

2. sending an RA with IPv6-only flag: it's not difficult to add one
    bit to open source radvd, odhcp (openwrt's RA implementation) or
    scapy.

3. receiving the IPv6-only flag: the easiest thing to do right now is
    for the receiver to ignore it.

The point 2 could thus be the most critical, if this is what you meant.

Alex

  I think making
> this a standard would be premature at this point.
> 
> Thanks,
> David Schinazi
> 
> 
> 
> On Wed, Oct 17, 2018 at 2:48 PM Ole Troan <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Nick,
> 
>      > -03 polishes some peripheral stuff but doesn't substantially
>     address any of the issues I've brought up over the last couple of
>     months.
>      >
>      > Chairs: none the issues I've raised previously have been
>     substantially addressed in this revision.  Do we need to go through
>     all these issues again, individually, on the mailing list for them
>     to be considered as outstanding in this draft?
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Jen Linkova <[email-masked]>
Date: Fri, 19 Oct 2018 23:22:16 +1100

Speaking as a network operator: the more I think about this draft the
more I like it.
It looks like the main concern is potential attack vectors. However...

1) IPv6-Only network (== the network which is configured by the
network administrator as Ipv6-only): I do not see any security issues
here. Actually  signalling hosts that IPv4 could be disabled might
even reduce the attack vector (one less protocol to be attacked from
onlink). Attacker might send a rogue RA and *enable* Ipv4 on hosts but
obviously RA Guard should be deployed on v6-only networks. In other
words, there is nothing which could be done with that flag which could
not be done w/o it.

2) Dual-stack networks. As in such a network there will be at least
one router sending RA w/o that flag - I could not see an attack vector
here.

3) IPv4-only network. This is most tricky part.
3.1)  A device accidentally configured as an IPv6-only sends an RA
with GUA PIO and advertised itself as a default gateway. Happy
Eyeballs might help for systems which support them;
3.2) An attacker intentionally sets up an IPv6 router on IPv4-only
network. It should be noted that in case of an intentional attack
Happy Eyeballs would not help at all, as nothing would prevent an
attacker to respond, for example, to TCP SYN.  It's even worse if you
think about RDNSS etc. Basically,  intentional RA_based attacks on
v4-onoy networks are mugh worse than just 'turn off v4 anyway';
3.3) A device accidentally configured as an IPv6-only sends an RA with
v6-only flag set.  Well, not as bad as 3.2, worse than 3.1. However it
would require an explicit action from the device admin (as the flag
need to be explicitly configured). And the easy solution? Routers in
v4-only networks need to support v6 and send RAs with the flag set to
0 (as well as zero default router lifetime) - might help with rogue
RAs too..

Obviously, this draft does not make the situation worse for the
malicious/rougue router scenario. An attacker can easily do more
damage w/o this flag if RA Guard is not deployed. The only concerning
case seems to be accidentally configured devices.  Maybe it would help
to say that the host SHOULD ignore the flag if the RA does not contain
GUA PIO?

Other thing: it looks like there is a real need to implement IPv6
security even on v4-only networks. Sounds like v6ops-scope draft (or
maybe there is one? I'm happy to craft smth if it does not exist).

-- 
SY, Jen Linkova aka Furry

---

From: Job Snijders <[email-masked]>
Date: Fri, 19 Oct 2018 14:35:34 +0200

I think it would be good to have some running code before advancing this to
IESG review and RFC publication. I don’t mean someone being able to send
the flag in a RA, but an operating system reacting to receiving a RA with
the flag set.

Operating system implementers will be able to provide valuable feedback to
the working group on how to mitigate risk for some of the suspected attack
vectors - and it’ll be educational to see how this works in practice. I
think running code will improve this specification.

Kind regards,

Job

---

From: Alejandro Acosta <[email-masked]>
Date: Fri, 19 Oct 2018 08:46:01 -0400

Hello,

  +1 to Job's comment.

Alejandro,

El 19/10/18 a las 08:35, Job Snijders escribió:
> I think it would be good to have some running code before advancing
> this to IESG review and RFC publication. I don’t mean someone being
> able to send the flag in a RA, but an operating system reacting to
> receiving a RA with the flag set.
>
> Operating system implementers will be able to provide valuable
> feedback to the working group on how to mitigate risk for some of the
> suspected attack vectors - and it’ll be educational to see how this
> works in practice. I think running code will improve this specification.
>
> Kind regards,
>
> Job
>
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Oct 2018 23:53:53 +1100

> It looks like the main concern is potential attack vectors. However...
<snip>
> maybe there is one? I'm happy to craft smth if it does not exist).

I haven't read it, however the Title and ToC look like it is
addressing that topic:

"Security Implications of IPv6 on IPv4 Networks"
https://tools.ietf.org/html/rfc7123

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Oct 2018 15:20:42 +0200 (CEST)

> maybe there is one? I'm happy to craft smth if it does not exist).

https://securityblog.switch.ch/2014/08/26/ipv6-insecurities-on-ipv4-only-networks/

That article from 2014 talks about exactly that. I'm sure there are more.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Oct 2018 15:48:02 +0200 (CEST)

On Fri, 19 Oct 2018, Job Snijders wrote:

> Operating system implementers will be able to provide valuable feedback 
> to the working group on how to mitigate risk for some of the suspected 
> attack vectors - and it’ll be educational to see how this works in 
> practice. I think running code will improve this specification.

I don't see how it would, since it doesn't mandate the hosts to do 
anything.

"Dual stack hosts that have a good reason to use IPv4, for example for
    a specific IPv4 link-local service, can attempt to do so.  Therefore
    respect of the IPv6-Only flag is recommended, not mandatory, for
    hosts."

So this is just one more input into whatever heuristics a host might have 
to decide how to behave. For instance do more agressive exponential 
backoff for IPv4 operations but not turn it off completely.

For security... as long as you have a shared LAN without first-hop 
security (SAVI), you're screwed 50 times already. There is nothing you can 
do to fix this at the edges of this L2 network. It just doesn't work. SEND 
doesn't fix it, nothing can fix it. Without network control, anyone can 
send anything and pretend to be anything, spoof whatever MAC address they 
choose and trick the MAC learning mechanism etc.

I am actually quite disappointed people keep bringing up "oh, but if we do 
this then someone can do that". This has been known for 20 years at least, 
that an "open and stupid" LAN presents unfixable security and/or denial of 
service problems. Can we just agree on this and declare this unfixable in 
the hosts?

If you don't run IPv6 and the network doesn't have IPv6 first-hop 
security, the network needs to filter 0x86dd packets. Whatever ethertype 
it forwards, it need to have some kind of security mechanism to stop hosts 
from pretending to be network equipment such as routers/dhcp servers etc.

This is already done using SAVI (which I am disappointed of the lack of 
interest in these crucial mechanisms from people participating in the 
IETF).

https://datatracker.ietf.org/wg/savi/documents/

There are proprietary implementations of these and they go by many names, 
RA guard, forced-forwarding etc. These mechanisms are ~15-16 years old at 
least. I first ran into the need for these when doing ETTH deployments in 
circa 2001.

---

From: Job Snijders <[email-masked]>
Date: Fri, 19 Oct 2018 15:51:18 +0200

> backoff for IPv4 operations but not turn it off completely.

I’m suggesting that two or three operating systems do something with the
flag. Demonstrate how the flag can be used and observe if there are any
gotchas.

If running code isn’t possible, I don’t think the document needs to be
published at all.

Kind regards,

Job

---

From: Ole Troan <[email-masked]>
Date: Fri, 19 Oct 2018 15:54:55 +0200

Job,

> I’m suggesting that two or three operating systems do something with the flag. Demonstrate how the flag can be used and observe if there are any gotchas. 
> 
> If running code isn’t possible, I don’t think the document needs to be published at all.

Agree. Let’s see some running code at the IPv6 only network at the IPv6 sessions in Prague!

Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 19 Oct 2018 15:56:33 +0200

> I don't see how it would, since it doesn't mandate the hosts to do anything.
> 

There should be a SHOULD disable IPv4 processing on the interface in there somewhere.
If it is not then I think the SHOULD MUST be added.

Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Oct 2018 16:00:46 +0200 (CEST)

> If it is not then I think the SHOULD MUST be added.

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

The word "MUST" is never used in the document as a requirement to turn off 
IPv4. The only must is here (why isn't it upper case BTW?):

"If a default router expires (i.e.,
    no RA is received that refreshes its lifetime), the host must remove
    this router's flag value from consideration."

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Oct 2018 16:12:26 +0200 (CEST)

On Fri, 19 Oct 2018, Mikael Abrahamsson wrote:

> IPv4.

Btw, I have no problem to make this language even less prescriptive. I do 
not want the host to turn off IPv4 all of a sudden if it has passed its 
captive portal check and deems it has fully working IPv4 connectivity to 
the Internet.

I want this RA flag to be the input of a decision the host makes to turn 
off IPv4, but one of potentially several. If you all of a sudden see this, 
don't turn off IPv4 immediately but perhaps wait 5-10 minutes since you 
last had working ARP or saw DHCPv4 reply. If you see it on network attach, 
do try DHCPv4 a few times and see if something answers. Perhaps do higher 
exponential backoff on your re-tries for DHCPv4 messaging.

Since I don't know much about how hosts treat IPv4 internally and we don't 
have an v4ops group to discuss it in, I don't think this is 6mans job to 
come up with exact descriptions what host operating systems do with this 
information.

The only thing I as an network operator want is to lessen the load of 
multicasts/broadcasts in the air for devices never-endingly trying to do 
IPv4. From what I can tell, IETF has no working group with critical mass 
to work on this problem. Sunset4 is gone.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Oct 2018 18:42:03 +0200

Hi Mikael,

> I want this RA flag to be the input of a decision the host makes to turn off IPv4, but one of potentially several. If you all of a sudden see this, don't turn off IPv4 immediately but perhaps wait 5-10 minutes since you last had working ARP or saw DHCPv4 reply. If you see it on network attach, do try DHCPv4 a few times and see if something answers. Perhaps do higher exponential backoff on your re-tries for DHCPv4 messaging.

This would take away most (maybe all) of my objections to this draft. An "if you don't get IPv4 working then don't worry, it's intentional" flag to change retries and timers wouldn't be a problem and would actually be very helpful.

> Since I don't know much about how hosts treat IPv4 internally and we don't have an v4ops group to discuss it in, I don't think this is 6mans job to come up with exact descriptions what host operating systems do with this information.

I don't agree with that. We can describe that intention without going into details. How about:

"""
On IPv6-only networks there will be no DHCPv4 server. Hosts that fail to acquire addresses with DHCPv4 and that see this flag set in all RAs from its default gateways SHOULD treat that in the same way as a network with the DoNotAutoConfigure option set as described in RFC 2563. A host SHOULD also increase its timers for retrying DHCPv4 to avoid causing unnecessary background noise on the network.
"""

> The only thing I as an network operator want is to lessen the load of multicasts/broadcasts in the air for devices never-endingly trying to do IPv4. From what I can tell, IETF has no working group with critical mass to work on this problem. Sunset4 is gone.

I recognise this desire, and with what is described above I would be happy.

My main fear is for SMB networks which often are still IPv4-only (which also needs to be fixed, but that's a separate issue), don't have managed switches or WiFi controllers with no RA Guard etc. There are many of such networks. Those networks are vulnerable to rogue RAs already, but happy eyeballs can mitigate the impact of someone messing with that. If this flag can kill IPv4 on the network then hosts become completely disconnected and happy eyeballs won't be able to mitigate anymore.

Yes, a serious attacker can do more harm even without this flag. This flag could however make it possible for kids/students/disgruntled employees/me/etc to bring down the network with a single packet. Such networks have no capacity for debugging anyway, and because of the low number of packets necessary to sustain the attack won't know what hit them. ISPs will get calls about the internet being broken, ICT consultants will spend hours searching for the cause of the problem, they will all blame "that annoying IPv6 thingy" etc etc etc. Let's avoid all of that.

Cheers!
Sander

---

From: Jen Linkova <[email-masked]>
Date: Sat, 20 Oct 2018 03:52:23 +1100

On Sat, Oct 20, 2018 at 3:42 AM Sander Steffann <[email-masked]> wrote:
> Yes, a serious attacker can do more harm even without this flag. This flag could however make it possible for kids/students/disgruntled employees/me/etc to bring down the network with a single packet.

All those people can take the whole network (almost) down with a
single packet w/o the v6-only flag anyway.
How about this:
- kids/students/disgruntled employees/you can send an RA with GUA PIO
and RDNSS option;
- hosts start sending IPv6 traffic to IPv6-enabled destinations to the
rogue host;
- it would be enough for the attacker to respond with SYN/ACK to TCP
handshake to take Happy Eyeballs out of the picture for TCP traffic;
- the attacker can also answer DNS requests and make the situation
even worse (if the victims prefer to use RDNSS servers);

>Such networks have no capacity for debugging anyway, and because of the low number of packets necessary to sustain the attack won't know what hit them. ISPs will get calls about the internet being broken, ICT consultants will spend hours searching for the cause of the problem, they will all blame "that annoying IPv6 thingy" etc etc etc. Let's avoid all of that.

I agree we shall avoid all of that. But the way to do this is not by
setting/unsetting some flags in RAs but by implementing proper IPv6
security.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Oct 2018 19:09:09 +0200

Hi,

> handshake to take Happy Eyeballs out of the picture for TCP traffic;

And here you go beyond "a single packet".

> even worse (if the victims prefer to use RDNSS servers);

Same here.

> setting/unsetting some flags in RAs but by implementing proper IPv6

The world of SMBs and home networks is not like that... The vast majority of SMBs don't even have a manageable switch.

Cheers
Sander

---

From: Jen Linkova <[email-masked]>
Date: Sat, 20 Oct 2018 04:14:57 +1100

> And here you go beyond "a single packet".

I don't think so. A single packet is enough to redirect all v6 traffic
to the attacker.

> The world of SMBs and home networks is not like that... The vast majority of SMBs don't even have a manageable switch.

Oh in that case they don't even need an RA to make the network unusable.
Rogue DHCP server etc.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Oct 2018 19:32:42 +0200

Hi,

> I don't think so. A single packet is enough to redirect all v6 traffic

Yes, but to prevent happy eyeballs from working: "it would be enough for the attacker to respond with SYN/ACK".

> Oh in that case they don't even need an RA to make the network unusable.

Again, not a single packet but a much more active attack.

Cheers,
Sander

---

From: 神明達哉 <[email-masked]>
Date: Fri, 19 Oct 2018 11:20:58 -0700

At Fri, 19 Oct 2018 14:35:34 +0200,

> think running code will improve this specification.

I tend to agree.

If I recall the discussion in this group accurately, I've not yet seen
a host OS implementor interested in implementing this idea, while they
should be one of the primary stake holders who can benefit from this
option.  In fact, some implementors were even explicitly negative
about it.

IMO this is not a good sign, and suggests we might be developing
something useless at best, or harmful at worst.  I've seen the usual
response to that concern: "we IETF can't enforce developers to
implement anything; all we can do is to write a good protocol
specification and let the market decide".  That may be true in the
end, but I'm not comfortable with accepting the argument without even
seeing an attempt of actually implementing and running the proposal.

I guess we can also learn from the "DNS camel" discussion held in the
London meeting in March:
https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01
I'm afraid that mainly "standardizers" (see p.24 of the slides)
drive the discussion toward publication right now, while developers
and (at least some) operators raise concerns.  In my past experiences,
that's often a sign of having troubles in the future, when the latter
group of people will have to deal with them, while the "standardizers"
are now more interested in developing the next cool thing.  Hopefully
I'm wrong this time, but to be proved incorrect I'd like to see more
concrete evidences with running code and experiments, rather than just
having email discussions which are often hypothetical and where anyone
can validly make their arguments.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Oct 2018 08:34:51 +1300

Job,
On 2018-10-20 01:35, Job Snijders wrote:
> IESG review and RFC publication. 

Why is this proposal special in that respect? This is not an IETF requirement
and despite the BCP advocating an Implementation Status section, very few drafts
do this.

Note, I am all for some trial implementations, but why does *this* draft
need one when so many others don't?

> I don’t mean someone being able to send

Well, both are needed for a real test (plus a demonstration that legacy
stacks ignore the flag). Personally I don't have the Linux smarts to do
this, but of course it would be great if somebody volunteers.
 
> think running code will improve this specification.

s/this/any/

Regards
     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Oct 2018 08:37:14 +1300

> IPv4. The only must is here (why isn't it upper case BTW?):

Good catch, thanks.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Oct 2018 08:40:31 +1300

On 2018-10-20 03:12, Mikael Abrahamsson wrote:
> off IPv4, but one of potentially several. 

Agreed, and the current text is supposed to allow that. One example is the
dual stack fire alarm - if I had one of those, I'd want it keep looking for
both v4 and v6 connectivity whatever happens, although possibly reducing
the probe frequency.

   Brian

> If you all of a sudden see this,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Oct 2018 08:47:12 +1300

Sander,

A single packet containing a forged RA with the v6-only flag set cannot take
down a network. The condition is that a host sees *only* RAs with the flag
set. The opposite applies: a single RA with the v6-only flag *clear* tells
all hosts that they may try IPv4 as much as they want.

As the draft says, if a bad actor takes over all IPv6 routers on the link,
then they can break IPv4, but so what? They can break anything.

Regards
   Brian

On 2018-10-20 06:09, Sander Steffann wrote:
> .

---

From: Ole Troan <[email-masked]>
Date: Fri, 19 Oct 2018 22:25:20 +0200

Job et al,

> If running code isn’t possible, I don’t think the document needs to be published at all.

Asking for implementations also comes with responsibility.
There will be much larger resistance to change after implementations are written.
Even if a feature is implemented as an experiment, it is out in the wild, and you have to consider interoperability and backwards compatibilty.
And we need to listen to implementors, both with regards to changes required based on implementation experience and not to make changes, because it affects implementations written.

I hope we can’t screw this up to badly with a single bit though.

Ole

---

From: [email-masked]
Date: Fri, 19 Oct 2018 22:37:39 +0200 (CEST)

> need one when so many others don't?

Whatever happened to "We believe in rough consensus and running code"?

	 https://www.ietf.org/how/runningcode/

That certainly *used* to be one of the big differences between the
ISO/OSI standardization process and the Internet standardization
process...

Steinar Haug, AS2116

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Oct 2018 08:55:11 +1100

On Sat., 20 Oct. 2018, 7:38 am , <[email-masked]> wrote:

> this to

It isn't "We require ..."

---

From: Ole Troan <[email-masked]>
Date: Sat, 20 Oct 2018 00:12:54 +0200

> On 19 Oct 2018, at 23:55, Mark Smith <[email-masked]> wrote:
> 
> 
> 

It isn’t. But it’s quite a big span between “it’s a hint” and “though shall disable ipv4 unless you have bloody good reason not to”. 

In my view, I don’t see much purpose in the bit unless it’s prescriptive. As in the last category. 

We might have to go through having running code before we can agree on which of the above it’s going to be, if any. 

Cheers 
Ole

>> Administrative Requests: https://www..ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Oct 2018 14:42:32 +1300

> Whatever happened to "We believe in rough consensus and running code"?

It hasn't gone away, although formally it only applies for promotion
above "Proposed Standard" status. And I believe in it, and that's why
there's running code for GRASP (draft-ietf-anima-grasp-15). But for
something that has to go into the basic IP stack, it's not so easy to
prototype, and I am still not seeing why people would raise the barrier
for this particular minor extension rather than, say, for the extension
mechanism for RA flags that appears to be completely unimplemented.

In other words: if this is what you want for ipv6only-flag, then
I'd like the same rule for all the other draft-ietf-6man documents
from now on, please.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Oct 2018 14:43:53 +1300

> I hope we can’t screw this up to badly with a single bit though.

Not on the router side. But on the host side, the way it's used
is essentially a heuristic, so there are screw-up opportunities.

   Brian

---

From: Lee Howard <[email-masked]>
Date: Sat, 20 Oct 2018 11:37:12 -0400

I've been meaning to say the same thing. I don't think there's astronger 
advocate for IPv6-only than I am, but I have some misgivings on this 
document that I haven't quite been able to articulate.

I haven't been following the discussion closely, but have we heard from 
any OS developers about what they plan to do if they see the flag?

I don't need to see code deployed in the wild, but I sure would like to 
have some hint from implementors what will happen in the wild. Different 
implementations might well intepret the flag differently, which might 
result in some surprising behaviors on the wire(less).

For instance:
Devices come up with at least IPv4 enabled and start sending some kind 
of local multicast, maybe doing service discovery over IPv4. Then a 
router sends the IPv6-only flag. If some hosts recognize it and others 
don't, they may try a service that has previously been advertised over 
IPv4.
Does Happy Eyeballs solve this? I don't know whether printer services 
implement that, though I know that on my dual-stack network I can't 
print if I lose IPv6.

So I'd like to see how OSs will detect and recover.

Lee

---

From: Ola Thoresen <[email-masked]>
Date: Sat, 20 Oct 2018 19:34:15 +0200

On 20/10/2018 00:12, Ole Troan wrote:

> It isn’t. But it’s quite a big span between “it’s a hint” and “though 
> shall disable ipv4 unless you have bloody good reason not to”.
>

On this, we can agree. Having a flag as a "hint" does not make much 
sense.  You can't trust it, so you would STILL need to verify if the 
flag is actually telling the truth, or if it is just set - either 
malicious, or by mistake.

On the other hand, I do not see how this can be a hard requirement.  Or 
at least I can not see operating systems actually obyeing such a flag.  
IF the client administrator has configured IPv4 dhcp client settings, 
why should the OS trust a flag in an RA-packet more than the OS-admins 
configuration?

Just look at the already defined flags "O" and "M" - which are not even 
breaking the barrier between the IP-protocols.  I know at least a couple 
of implementations which will send a DHCPv6-request no matter what the 
RA is signaling in its M and O-flags.  And I know implementations that 
will not automatically send dhcp-requests no matter what flags are set 
in the RA-packets.

We don't need even more flags that might or might not be ignored by the 
operating systems.  And which have a somewhat vague definition.

We don't have a flag to tell the OS to not run DECnet, Appletalk or 
IPX.  We simply disable these on the clients.  And even if we had such a 
flag in DHCPv4 or RA, I - as an admin - would prefer the clients to not 
rely on such a flag, but try to get some kind of network access on any 
enabled network protocol in the client.

Rgds.

Ola (T)

---

From: Job Snijders <[email-masked]>
Date: Sat, 20 Oct 2018 20:06:15 +0200

> I'd like the same rule for all the other draft-ietf-6man documents

Yes please! I’d love to see more working groups require multiple
interoperable implementations (like IDR does) before documents advance to
publication. I believe this will improve the working group’s output.

Kind regards,

Job

Ps. I brought this topic up for this draft because the discussion around it
shows me there is some controversy, which perhaps can be resolves by
demonstrating the concept in running code.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Oct 2018 10:22:31 +1300

> IF the client administrator has configured IPv4 dhcp client settings,

It seems to me that for 99.99% of hosts today, there is no admin in that
sense and what you get is the O/S factory default setting. For example,
if the factory default is to reduce the frequency of DHCP solicitations
when it sees this flag, then it's mission accomplished: less battery and
air time wasted on IPv4 packets.

But anyway, can you point to language in the draft that is incompatible
with what you wrote?

> operating systems.  And which have a somewhat vague definition.

Where is the vagueness in the definition? Which sentences in the -03 draft
are vague?

> IPX.  We simply disable these on the clients.  

But that is *managed* clients. Most clients, especially BYOD clients,
are unmanaged and arrive with dual stack IP enabled.

> And even if we had such a 

Even if that drains the batteries on constrained devices?

     Brian

---

From: Mark Andrews <[email-masked]>
Date: Sun, 21 Oct 2018 06:27:05 +0800

Then you as the administrator would not set the flag. It is a straw man to make such arguments.

BYO networks and home networks need this flag.  I really don’t want to have to figure out how to disable IPv4 in every device in the home network once I get to the stage that every device I care about supports IPv6.  Lots of extra noise for zero benefit. 

-- 
Mark Andrews

> On 20 Oct 2018, at 23:37, Lee Howard <[email-masked]> wrote:
> 
> I've been meaning to say the same thing. I don't think there's astronger advocate for IPv6-only than I am, but I have some misgivings on this document that I haven't quite been able to articulate.
> 
> I haven't been following the discussion closely, but have we heard from any OS developers about what they plan to do if they see the flag?
> 
> I don't need to see code deployed in the wild, but I sure would like to have some hint from implementors what will happen in the wild. Different implementations might well intepret the flag differently, which might result in some surprising behaviors on the wire(less). 
> 
> For instance:
> Devices come up with at least IPv4 enabled and start sending some kind of local multicast, maybe doing service discovery over IPv4. Then a router sends the IPv6-only flag. If some hosts recognize it and others don't, they may try a service that has previously been advertised over IPv4. 
> Does Happy Eyeballs solve this? I don't know whether printer services implement that, though I know that on my dual-stack network I can't print if I lose IPv6. 
> 
>> I think it would be good to have some running code before advancing this to IESG review and RFC publication. I don’t mean someone being able to send the flag in a RA, but an operating system reacting to receiving a RA with the flag set.
>> 
>> Operating system implementers will be able to provide valuable feedback to the working group on how to mitigate risk for some of the suspected attack vectors - and it’ll be educational to see how this works in practice. I think running code will improve this specification.
>> 
>> Kind regards,
>> 
>> Job
>> 
>>

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 21 Oct 2018 13:19:13 +0200

>    that the link is IPv6-Only.  This document updates RFC5175.

I love the concept of something that break IPv4, I really do.

But I somehow doubt this can actual work in reality. Can it be implement
without breaking tons of internals?

So I am with Job on this one, running code please. Running code on this
also mean someone from the implementation side has to get involved in this
process.

--- Roger J ---

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 21 Oct 2018 21:25:15 +0100

> hasn’t been addressed I suggest you bring them back to the list.
Ole,

Almost the entire discussion surrounding the ipv6only-flag draft and its 
predecessors has been notable in that the authors either fully ignored 
the technical feedback on the wg mailing list, or acknowledged feedback 
but left it either partly or wholly unaddressed in the document.

Here's an example.  Drafts -00 to -02 contained the following:

>    o  In particular, this may overload switches in multi-segment
>       wireless networks because it will create IPv4 state for every dual
>       stack host.

I posted an analysis on Sep 8 
(https://mailarchive.ietf.org/arch/msg/ipv6/Yoy1Bo8A6WiRryqogTfr_R7FH9I) 
which went into some nuances about how switches work in the context of 
forwarding ipv4 frames, but the summary was:

"...layer 2 switches do not carry ipv4 state in any meaningful sense. 
It is technically misleading, bordering on flat-out incorrect, to 
suggest otherwise."

The draft was then updated from:

 > this may overload switches [...] because it will create IPv4 state

to:

 > this may overload switches [...] if the switches create IPv4 state

I'm at a loss as to how to respond to this other than to say that 
switches don't create ipv4 state and that it is disturbing to have to 
explicitly state something so fundamental in an IETF working group, 
particularly in the context of statements like: "the authors think that 
all your points are in fact dealt with in the text".

This is just one example from the draft, but there are several others, 
some as egregious as this.

What's happened now is that a new revision of the draft has been posted, 
and the process of posting it seems to have white-washed all the 
outstanding technical issues.  The onus of bringing these issues back to 
the working group has been piled on the plate of those who made the 
arguments in the first place, after having had them repeatedly dismissed 
any time they were brought up before.  This is not ok.

None of the issues I've brought up have been addressed properly.  As far 
as I'm concerned, they all remain open and the onus should be on the 
authors to address them.  There's a mailing list archive and it's 
searchable.  They need to do the work on this one.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Oct 2018 14:00:31 +1300

On 2018-10-22 09:25, Nick Hilliard wrote:
> switches don't create ipv4 state 

Wait, are you saying that no switches contain ARP caches? That would
truly surprise me.

> and that it is disturbing to have to 
> outstanding technical issues.

If by "white-wash" you mean "observe that they are side-issues for
the proposed mechanism", you'd be right. This isn't about the best way
to ensure IPv6-onlyness of a link; it's about one particular mechanism
towards that goal. We could say less, or nothing at all, about other
such mechanisms.

The WG may of course conclude that the mechanism isn't worth the bother.
If that's the conclusion, the draft will not advance.

> The onus of bringing these issues back to 
> None of the issues I've brought up have been addressed properly.  

IMO this draft is not the place to do so. Some other (v6ops?) document
about how to operate a v6only link would be the place for that.

   Brian

> As far

---

From: [email-masked]
Date: Mon, 22 Oct 2018 06:35:01 +0200 (CEST)

> Wait, are you saying that no switches contain ARP caches? That would

A managed switch normally contains an ARP cache used for the management
IP. It doesn't contain an ARP cache for the other L2 traffic through
the switch.

Steinar Haug, AS2116

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Oct 2018 07:22:26 +0200 (CEST)

> Wait, are you saying that no switches contain ARP caches? That would

The only IPv4 state that an L2 switch might contain for purpose of 
forwarding packets is if that switch implements SAVI like functionality.

The L2 switch doesn't need an ARP cache to perform its basic function. I 
have plenty of stupid L2 switches here in my household that doesn't have a 
management interface and doesn't understand IP at all. They only do 
ethernet header functions.

---

From: Ole Troan <[email-masked]>
Date: Mon, 22 Oct 2018 09:07:09 +0200

Hi Nick,

[deleting all text apart from the technical point]

> I posted an analysis on Sep 8 (https://mailarchive.ietf.org/arch/msg/ipv6/Yoy1Bo8A6WiRryqogTfr_R7FH9I) which went into some nuances about how switches work in the context of forwarding ipv4 frames, but the summary was:
> 
> "...layer 2 switches do not carry ipv4 state in any meaningful sense. It is technically misleading, bordering on flat-out incorrect, to suggest otherwise."
> 
> I'm at a loss as to how to respond to this other than to say that switches don't create ipv4 state and that it is disturbing to have to explicitly state something so fundamental in an IETF working group, particularly in the context of statements like: "the authors think that all your points are in fact dealt with in the text”.

Firstly, this seems to be background information, provided in the draft to justify the solution.
I say this to distinguish the point from the real technical issues with the protocol mechanism itself.

To your point. You are right of course. Maybe the authors have conflated bridges and routers? And that they are really talking about a router (aka L3 switch) that has limited TCAM space for forwarding state? Regardless I think this is a weak point, given that IPv6 in those terms use far more state. Easily an order of magnitude.

If no-one else in the working group feels strongly for this point, I would suggest we simply remove that bullet.
Or make a very vague statement about "disabling IPv4 completely on a link, ensures that no IPv4 state is required in the network or in hosts."

Best regards,
Ole

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2018 09:59:52 +0000

> On 22 Oct 2018, at 06:22, Mikael Abrahamsson <[email-masked]> wrote:
> 
> The only IPv4 state that an L2 switch might contain for purpose of forwarding packets is if that switch implements SAVI like functionality.
> 
> The L2 switch doesn't need an ARP cache to perform its basic function. I have plenty of stupid L2 switches here in my household that doesn't have a management interface and doesn't understand IP at all. They only do ethernet header functions.

There may be some examples where there are "helpers" supported, such as IGMP snooping, to store state about observed multicast sources, but those are more likely in enterprise deployments than home networks.

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2018 10:04:16 +0000

> On 22 Oct 2018, at 02:00, Brian E Carpenter <[email-masked]> wrote:
> 

I'm currently leaning to the "don't bother" side.

There is currently no evidence of any vendor interest in implementing support for the flag.

Were they to come forward, I suspect interpretation and implementation would vary, given the vagueness of the flag's nature as a hint, causing inconsistent behaviour between various hosts/devices.

Tim

---

From: Philip Homburg <[email-masked]>
Date: Mon, 22 Oct 2018 16:52:16 +0200

>There is currently no evidence of any vendor interest in implementing support 

I wondered about that myself. I don't like this draft at all, but the
bigger question is who is actually going to implement this?

There is benefit for battery powered devices, but I haven't seen any vendor
of mobile devices stand up and say that they will implement it. And my guess
is that any dev team will find more robust ways of saving battery power than
relying on this option.

At the same time, if room full of operators at a RIPE meeting say they have no
need for this option, then who is going to set it on routers?

>From a technical point of view, if nobody implements the flag, it doesn't do 
any harm.

Beyond a narrow technical view, it does harm. It makes the total IPv6 protocol
bigger, so harder to analyse, harder for people to learn about IPv6 or to
teach others.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Oct 2018 18:04:48 +0200 (CEST)

> need for this option, then who is going to set it on routers?

How many heard about this for the first time during that lightning talk 
and had an informed idea about this? How many do even run IPv6 at all? On 
wifi where this is most important probably?

What I would like to hear is from wifi experts, how much does the IPv4 
broadcast traffic cause problems in large wifi deployments? Arena settings 
for instance?

Because this isn't just an individual device optimization, it has 
consequences for how much airtime is eaten up by potentially duplicated 
traffic?

---

From: Philip Homburg <[email-masked]>
Date: Mon, 22 Oct 2018 19:24:41 +0200

>wifi where this is most important probably?

This draft was also mentioned in the IPv6 WG. Typically there are quite a few
people going to IPv6 WG sessions, though of course it is hard to say
how many of them are actually running IPv6.

>broadcast traffic cause problems in large wifi deployments? Arena settings 

Maybe we can turn this around and ask the wifi experts to compare this draft
to the DHCPv4 option and ether type filtering to see if this draft actually
saves enough that mobile device vendors would actually implement it.

This draft contains the most vague hand waving: 
"It may result in an undesirable level [...]" What's the real number if
you employ ether type filtering?
"In particular, this may overload switches [...]" How is that ever going
to happen?

If this is a real operational problem, then maybe somebody can measure it,
write an article and a future draft can reference the article.

This draft is pointless if host operating systems ignore it. And right now,
ignoring this draft does seem to be the most sensible approach.

---

From: Lee Howard <[email-masked]>
Date: Mon, 22 Oct 2018 13:32:22 -0400

On 10/22/18 12:04 PM, Mikael Abrahamsson wrote:
> How many heard about this for the first time during that lightning 
> talk and had an informed idea about this? 

Depends on what you mean by "informed." They have a pretty well-informed 
idea about their own networks.

How well-informed are the participants in 6man? Is it obvious that once 
someone subscribes to 6man and reads the background of this doc, they 
will be supporters?

Is there clear consensus?

> How many do even run IPv6 at all? On wifi where this is most important 
> probably?

I haven't checked the list of meeting attendees against ASNs with IPv6, 
but I would expect it's much higher than average. No idea whether it's 
higher than the networks of IETF attendees, but then, most IETF 
attendees aren't network operators.

> broadcast traffic cause problems in large wifi deployments? Arena 
> settings for instance?
>
> consequences for how much airtime is eaten up by potentially 
> duplicated traffic?

Maybe someone from the IETF NOC could weigh in. I don't know whether any 
large WiFi operators are here. Do you know any? If their input is 
important, maybe we should go find some?

Lee

---

From: 神明達哉 <[email-masked]>
Date: Mon, 22 Oct 2018 10:56:48 -0700

At Sat, 20 Oct 2018 14:42:32 +1300,
Brian E Carpenter <[email-masked]> wrote:

> prototype,

I don't think it's that hard to develop a PoC host implementation.
There's a standard socket API for a user space application to receive
and inspect RAs (in fact, in my understanding many open source
implementations of RFC8106/6106 work that way).

And then, when it detects the link is IPv6-only per the draft, the
application could configure IPv4 host firewall rules to drop any
outgoing IPv4 packets.  This implementation won't help the device
itself avoid wasting its battery, but will avoid disturbing others.
Accessibility from applications to such firewalls would depend on
operating system details, but at least it should be readily available
on general purpose systems such as BSDs or Linux.

--
JINMEI, Tatuya

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 22 Oct 2018 22:56:03 +0100

[continuing down this minor rathole]

> draft to justify the solution.

it's more than background information - it forms part of the problem 
statement / solution justification, but is just one example of where the 
problem statement is weak.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 22 Oct 2018 23:20:59 +0100

Ole Troan wrote on 22/10/2018 08:07:
> Or make a very vague statement about "disabling IPv4 completely on a
> link, ensures that no IPv4 state is required in the network or in
> hosts."
There's no need to be vague: IPv4 state is not meaningfully maintained 
on networks and IPv4 state on hosts which aren't talking ipv4 is not 
going to extend much further than increasing the size of arp caches, 
i.e. the overhead is inconsequential.

Nick

---

From: David Farmer <[email-masked]>
Date: Mon, 22 Oct 2018 17:29:03 -0500

> I'd like the same rule for all the other draft-ietf-6man documents

I don't think "running code" needs to be a requirement for this draft or
generally in 6man. However, in this case, where there doesn't seem to be a
clear and obvious consensus, running code or some sign that there will be
running code could help promote consensus.

Personally, I'm in the probably not camp at this point, I don't see
fundamental flaws in the spec, but I have serious doubts about client
implementations of the spec occurring. And, I'm not excited to use one of
the two remaining native router advertisement flags (not using the RFC 5175
extension option) if there are doubts about there being any host
implementations of the spec.

However, the existence running code or even a few host developers coming
out and saying they intend to implement this spec if published as standards
track would go a long way to dispelling many of my doubts about this draft.

I did ask for at least some commentary about "about taking care to prevent
unsuspecting WiFi users from accidentally connecting IPv4-only WiFi hosts
to IPv6-only WiFi links", such as by using "IPv6" or "IPv6-only" in open
SSIDs, using PSK or other authentication, or using 802.11u Access Network
Query Protocol (ANQP) with "Address type available" for IPv6 and "Address
type not available" for IPv4.  I think my other comments were covered, but
I don't see where this was covered in the new version.

Further, last week at the Internet2 TechEX in Orlando, we ran some
experiments with the RFC2563 option, and the initial unvalidated results
are not good, all clients seemed to not request the option and still
generated IPv4 link-local addresses.  We still have some work to do to
completely understand the results and to ensure it wasn't some kind of
screw up on our part configuring the DHCP server.

Also, as I've been thinking about this situation, and I'd also like to see
a new DHCPv4 option for Dual Stack clients that are capable of utilizing
IPv4AAS on their own, signaling that the provided IPv4 address should be
configured only if they cannot make IPv4AAS work over the IPv6 service
provided. This allows a network to service newer Dual Stack Client in
IPv6-only mode, while still servicing older Dual Stack clients and
IPv4-only clients with a provided IPv4 address. This allows networks to
gracefully transition to IPv6-only and have data to determine when IPv4 can
be safely be turned off on a link and then maybe eventually turning on the
IPv6-only flag for the link, assuming we can find consensus to do the
IPv6-only flag.

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: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2018 00:57:27 +0200

On 10/20/18 11:22 PM, Brian E Carpenter wrote:
[....]
> Even if that drains the batteries on constrained devices?

Is trying DHCPv4 what really drains the batteries?

-- 
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: Tue, 23 Oct 2018 01:01:29 +0200

> mechanism for RA flags that appears to be completely unimplemented.

+1

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Oct 2018 10:04:45 +1100

> There may be some examples where there are "helpers" supported, such as IGMP snooping, to store state about observed multicast sources, but those are more likely in enterprise deployments than home…

I don't have experience with them (been in carrier/ISP land for a
quite a while) or knowledge of how widely it is used, however
enterprise Wifi APs look to be performing ARP caching to reduce
link-layer broadcast traffic, which is IPv4 state being maintained in
a layer 2 device. e.g.

https://www.cisco.com/web/techdoc/wireless/access_points/online_help/eag/123-04.JA/1100/h_ap_services_arp.html

I think David Farmer might have mentioned it being used some time here
in the past.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2018 15:02:15 +1300

> https://www.cisco.com/web/techdoc/wireless/access_points/online_help/eag/123-04.JA/1100/h_ap_services_arp.html

Thanks, that's exactly what I meant. My knowledge of actual products
is way out of date, but I remember this being a selling point many
years ago. That's a 2005 web page - has this feature faded away?

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 23 Oct 2018 10:32:07 +0100

> link-layer broadcast traffic, which is IPv4 state being maintained in

arp proxying can be implemented on several types of network devices 
(wifi APs, evpn l2 domain edge ports, etc). This is handled in the 
management plane of those devices and does not impact on the forwarding 
plane capacity, i.e. it is not affected by the number of ipv4/mac 
mapping entries in any meaningful way.  It's a non issue.

Nick

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Oct 2018 10:44:57 +0000

> On 23 Oct 2018, at 00:01, Fernando Gont <[email-masked]> wrote:
> 

I think the problem is that we don't even have "rough consensus" here, yet alone "running code".

Tim

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2018 19:28:00 +0200

> I think the problem is that we don't even have "rough consensus" here, yet alone "running code".

That's kind of my take, as well However, I think that asking for an
implementation of the ipv6-only flag is a requirement that I have never
seen for taking new work or publishing it, so it would be unfair to ask
that to the authors of this particular I-D.

Thanks,

---

From: Sander Steffann <[email-masked]>
Date: Tue, 23 Oct 2018 20:05:30 +0200

Hi,

Changed the subject because this discussion is now moving away from any specific draft.

> that to the authors of this particular I-D.

I'd like that to become the norm though. Having a running prototype can help enormously when writing specifications. My preference would be to move back to a base principle of running code and rough consensus, instead of only rough consensus.

Cheers,
Sander

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Oct 2018 14:26:28 -0400

> On Oct 23, 2018, at 2:05 PM, Sander Steffann <[email-masked]> wrote:
> 
> Hi,
> 

If the WG decides to go on this path, I will be fully supportive of that. This model has worked out well for idr (see https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement). What I am uncomfortable with is that criterion being *selectively* applied to this draft as a prerequisite for progress. 

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2018 20:27:19 +0200

> I'd like that to become the norm though. Having a running prototype can help enormously when writing specifications. My preference would be to move back to a base principle of running code and roug…

Not that I disagree, but... wouldnt that be something that should be
discussed IETF-wise?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2018 20:31:30 +0200

> If the WG decides to go on this path, I will be fully supportive of that. This model has worked out well for idr (see https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement). What I am uncom…

I think that you might also expect bigger divergence between
implementations and specs. If something is implemented, as is deemed as
working well, it is likely that it will be committed and used before we
agree its a good idea. Or that what gets deployed is some draft version
of the spec as opposed to what ends up in the actual RFC. Just me
thinking out loud.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 23 Oct 2018 20:33:01 +0200

Hi,

I don't think this can be enforced and even less for a specific ID or WG.

And this will be discriminatory also if applied to all the IETF work.

There are many authors that don't have time, resources, access to the source code from vendors, or even knowledge, among many many many other possible reasons, to implement an ID they submit. Also, there will be IDs which are not "implementable", etc., and clearly that doesn't disqualify that it may be a perfectly valid work.

I guess this is a discussion that should be held at the general area list.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Suresh Krishnan <[email-masked]>
Fecha: martes, 23 de octubre de 2018, 20:26
Para: Sander Steffann <[email-masked]>
CC: Fernando Gont <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

    
    Thanks
    Suresh

**********************************************
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: Ole Troan <[email-masked]>
Date: Tue, 23 Oct 2018 20:55:15 +0200

Hi Suresh,

> If the WG decides to go on this path, I will be fully supportive of that. This model has worked out well for idr (see https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement). What I am uncom…

At least from my side (as the non-author co-chair) this wasn’t intended to apply a new requirement on this particular draft.
It was intended as a possible avenue for a draft that currently does not  have enough support in the working group to advance.

Best regards,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Oct 2018 14:57:02 -0400

Hi Jordi,

> On Oct 23, 2018, at 2:33 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi,
> 

> There are many authors that don't have time, resources, access to the source code from vendors, or even knowledge, among many many many other possible reasons, to implement an ID they submit.

I don’t think there is an expectation that the implementations have to necessarily come from the draft authors. e.g. look at the codestand work

https://codestand.ietf.org/codestand/

where people can request implementations. The underlying thesis is that there are people who have implementation skills who might be looking for guidance on what to implement.

> Also, there will be IDs which are not "implementable", etc., and clearly that doesn't disqualify that it may be a perfectly valid work.

Right. I am pretty sure this will be applicable only to Standards Track documents and the “not implementable” documents you mention will not be subject to this.

> I guess this is a discussion that should be held at the general area list.

We have had this discussion multiple times over the past years.

RFC1264 (coincidently written by Bob) was the first document in this space requiring implementations before heading to Proposed Standard
RFC4794 obsoleted RFC1264 specifically pointing to the following text RFC2026  (which postdated RFC1264)

      Usually, neither implementation nor operational experience is
      required for the designation of a specification as a Proposed
      Standard.  However, such experience is highly desirable, and will
      usually represent a strong argument in favor of a Proposed
      Standard designation.

      The IESG may require implementation and/or operational experience
      prior to granting Proposed Standard status to a specification that
      materially affects the core Internet protocols or that specifies
      behavior that may have significant operational impact on the
      Internet.

and allows WGs to set their own rules. This is where things stand right now.

The current state of the art BCP is RFC7942 (which obsoleted RFC6982) that allows providing optional info about existing implementations and Section 4 of that document lists some of the benefits of doing so.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Oct 2018 15:15:51 -0400

Hi Ole,

> On Oct 23, 2018, at 2:55 PM, Ole Troan <[email-masked]> wrote:
> 
> Hi Suresh,
> 

I did not mean your response at all :-). There were other mails in the thread that implied this (and I do not fault them either for asking).

> It was intended as a possible avenue for a draft that currently does not  have enough support in the working group to advance.

I think that makes perfect sense to try that possibility. I also think an implementation might be helpful here as RFC2026 eloquently states:

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Oct 2018 08:39:34 +1300

> mapping entries in any meaningful way.  It's a non issue.

So, to be a bit picky, your statement that switches don't hold per-host
IPv4 state wasn't quite right. You're stating that they may hold such
state but it doesn't measurably impact forwarding capacity. Fair enough,
and duly noted.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Oct 2018 08:43:09 +1300

Tim,
> I think the problem is that we don't even have "rough consensus" here, yet alone "running code".

I think it's a bit worse than not having rough consensus. We have people
saying "this is useful, somebody should code it up" and others saying
"this is potentially harmful and a waste of effort."

    Brian

---

From: Lee Howard <[email-masked]>
Date: Tue, 23 Oct 2018 15:50:56 -0400

On 10/23/18 2:57 PM, Suresh Krishnan wrote:
>
> RFC1264 (coincidently written by Bob) was the first document in this 
> space requiring implementations before heading to Proposed Standard
> The current state of the art BCP is RFC7942 (which obsoleted 
> RFC6982) that allows providing optional info about existing 
> implementations and Section 4 of that document lists some of the 
> benefits of doing so.
>
> Thanks
> Suresh

Thanks for this!

Looking at recent (past two years) 6man documents. . .

draft-ietf-6man-segment-routing-header
I think multiple interoperable implementations exist.

draft-ietf-6man-icmp-limits
Specifies ICMPv6 error messages.
It's -00, but we should look for running code before publication.

draft-ietf-6man-rfc4941bis-00
Also -00, but I'd hope to see code before publication.

RFC 8425 (was draft-ietf-6man-ndpioiana)
IANA Considerations for IPv6 Neighbor Discovery Prefix Information 
Option Flags
No running code applicable.

RFC 8319 (was draft-ietf-6man-maxra)
Support for Adjustable Maximum Router Lifetimes per Link
I think we had seen code; not sure, but I don't recall objections from 
implementers.

RFC 8200 (was draft-ietf-6man-rfc2460bis)
Internet Protocol, Version 6 (IPv6) Specification Errata 2017-07
Decades of running code.

RFC 8201 (was draft-ietf-6man-rfc1981bis)
Path MTU Discovery for IP version 6
Decades of running code.

RFC 8096 (was draft-ietf-6man-ipv6-mibs-obsolete)
The IPv6-Specific MIB Modules Are Obsolete
No running code applicable.

RFC 8106 (was draft-ietf-6man-rdnss-rfc6106bis)
IPv6 Router Advertisement Options for DNS Configuration
We had running code.

RFC 8064 (was draft-ietf-6man-default-iids)
Recommendation on Stable IPv6 Interface Identifiers
No running code applicable

RFC 8021 (was draft-ietf-6man-deprecate-atomfrag-generation)
Generation of IPv6 Atomic Fragments Considered Harmful
No running code applicable.

So, requesting running code for the ipv6only-flag isn't really a change 
in practice for 6man. We just haven't had to ask before.

Lee

---

From: 神明達哉 <[email-masked]>
Date: Tue, 23 Oct 2018 13:01:34 -0700

At Tue, 23 Oct 2018 14:26:28 -0400,
Suresh Krishnan <[email-masked]> wrote:

> > I'd like that to become the norm though. Having a running
> > prototype can help enormously when writing specifications. My
> > preference would be to move back to a base principle of running
> > code and rough consensus, instead of only rough consensus.

> If the WG decides to go on this path, I will be fully supportive of that.
This model has worked out well for idr (see
https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement). What I am
uncomfortable with is that criterion being *selectively* applied to this
draft as a prerequisite for progress.

I agree as a general statement, but I believe we should carefully look
into the context for this particular case.  I supported the idea of
seeing an implementation of this draft in my own comment because the
draft has been controversial and there has not even been an interest
in (let alone an attempt of) implementing it even if host implementors
should be a primary beneficiaries of this proposal.  Given these I
believe it's reasonable and fair to suggest to hold off a while and
see if there's someone at least trying to have a prototype
implementation and if we can learn from it.  My general impression of
this thread is that others who supported the idea did so more or less
for the same reason, i.e, taking into account the situation instead of
abruptly raising the bar just because they didn't like the proposal.

Whether we should generally/always require an implementation as a wg
is a different topic.  I personally support at least the sense of the
idea (how strictly it should apply would still be a different
question), but I understand different people will have different
opinions on that point.

--
JINMEI, Tatuya

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 23 Oct 2018 22:03:35 +0200

Hi Suresh,

Very interesting pointers, however the point is not even the authors implementing something.

Let’s suppose there is a draft and nobody wants to implement it. Another draft is implemented. May be after some time the one that was not implemented get more market success than the other one.

This is discriminating both drafts in the IETF process, and we must not do that. It may happen even “you have programmers” that are good friends, they will do for me and in the other way around. Or I’m a vendor, so I’ve the resource to do it.

This will mean at the end that we balance the IETF work towards those that can (somehow), get things implemented, even if is a bad work (I understand that still need to follow the consensus, etc.).

At the end, we may have open source implementation of a draft, and not being adopted by vendors, or in the other way around. That’s not a good way to classify “good” or “bad” IETF work, also because after some years, what was “bad” is adopted as good, and viceversa.

I understand that when IETF started, it was very few work and it was very easy to ask for code for everything, but our industry changed and we can’t enforce that, even at WG level.

Regards,

Jordi

De: Suresh Krishnan <[email-masked]>
Fecha: martes, 23 de octubre de 2018, 20:57
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Sander Steffann <[email-masked]>, Fernando Gont <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

Hi Jordi,

Hi,

 

Thanks

Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Oct 2018 16:43:40 -0400

Hi Lee,

> On Oct 23, 2018, at 3:50 PM, Lee Howard <[email-masked]> wrote:
> 
> 
> 
> IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
> I think we had seen code; not sure, but I don't recall objections from implementers.
> 
I did implement this just to check if there were no crazy side effects of this.
> So, requesting running code for the ipv6only-flag isn't really a change in practice for 6man. We just haven't had to ask before.
> 
Not to take away from your point, but a lot of these are bis documents and I would have expected running code at this time :-).

Thanks
Suresh

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 23 Oct 2018 21:54:42 +0100

> state but it doesn't measurably impact forwarding capacity. Fair enough,

Brian,

your pickiness was foreseen and is dealt with in my email of Sep 8 :-)

The one-sentence summary is: switches don't carry ipv4 state.  The 
two-sentence summary adds that sometimes there is state handled in the 
control plane, but it doesn't affect forwarding and it isn't appropriate 
to claim that adding an ipv4 address or two or ten thousand to a network 
is going to make a difference to the forwarding capacity of the device, 
because it won't.

Sometimes there is some state held about some things on the control 
plane, but it does not impact forwarding capacity.  The term "measurably 
impact" is inaccurate - the impact is zero.  This is because switch 
asics - i.e. the bits of silicon that do the forwarding - don't have the 
hardware smarts to carry state.  This is easily demonstrated at e.g. 
IXPs where there are gigantic numbers of ip addresses being forwarded, 
but the switches remain blissfully unaware of them.  They're just 
frames.  Similarly on large L2 domains, the only thing that counts is 
the number of MAC addresses, and these are the same whether the 
ethertype is for ipv4 or ipv6.

Looking at arp proxies from a helicopter point of view, these are 
management-plane daemons which are fed frames punted up from the 
forwarding plane of the networking device, whether that's an AP or an 
EVPN l2 domain or whatever.  It really doesn't matter whether there are 
10, or 100, or 10000 entries in the lookup table because the data 
structures used to hold them are tiny and handled in standard RAM, which 
is plentiful on the sort of kit that would need to implement an ARP 
proxy to start with.  On any competently coded stack, the lookup 
mechanism will be implemented with a hash table which will give 
something close to O(1) lookups. In other words, control planes which 
implement arp (and ND) proxies are coded in a way which allows them to 
act efficiently on the control plane, and in a way which does not touch 
the forwarding plane.

Otherwise, the rest of my email from Sep 8 will fill you in on how 
control planes handle overloading.

Standard caveats apply about bad design and using kit which is unfit for 
purpose.

Someone mentioned multicast: this is slightly different, but is excluded 
from this discussion on the basis that it needs to be explicitly 
configured on a per-switch + per-vlan basis, whereas any network which 
doesn't want to run ipv4 is unlikely to have done this, and if they 
have, it's a misconfiguration and they badly need to make up their 
minds.  As as side note, this is one of the things that makes multicast 
scale badly - it injects state into otherwise stateless networks.

I hope this explains some of the nuances involved.

Nick

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Oct 2018 21:24:46 +0000

> On 23 Oct 2018, at 19:26, Suresh Krishnan <[email-masked]> wrote:
> 

I think there are good grounds in this case.  There is (apparently) no vendor interest, but it's also a very vague document, where if any vendors do decide to implement, it's highly likely that those implementations will result in different host behaviour.  Thus exploring interpretations of the draft on specific platforms, and observing the resulting behaviours and interactions, seems a pretty prudent step.  This may help refine the draft to be more specific, and uncover perspectives that as yet have not been considered.  It's not like the draft needs to be rushed through quickly.

Tim

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Oct 2018 17:26:01 -0400

Hi Jinmei-san,

> On Oct 23, 2018, at 4:01 PM, 神明達哉 <[email-masked]> wrote:
> 
> Suresh Krishnan <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > If the WG decides to go on this path, I will be fully supportive of that. This model has worked out well for idr (see https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement <https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement>). What I am uncomfortable with is that criterion being *selectively* applied to this draft as a prerequisite for progress. 
> 
> should be a primary beneficiaries of this proposal. 

And in fact, I found your response to be most helpful in the way of how this can be implemented. Thanks for that! I think the crux of the issue is about what to do on a host implementation. e.g. installing iptables entries to filter IPv4 may or may not be acceptable to some of the people who commented on this thread. 

> Given these I

> question), but I understand different people will have different

Yep. Agree.

Thanks
Suresh

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Oct 2018 21:26:25 +0000

> On 23 Oct 2018, at 20:43, Brian E Carpenter <[email-masked]> wrote:
> 
> Tim,

Feel free to rename it draft-ietf-6man-marmite-flag ;)

Tim

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Oct 2018 17:56:16 -0400

> On Oct 23, 2018, at 5:26 PM, Tim Chown <[email-masked]> wrote:
> 

or probably draft-ietf-6man-vegemite-flag ;-) since Brian is in NZ.

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Oct 2018 18:09:44 -0400

Hi Tim,

> On Oct 23, 2018, at 5:24 PM, Tim Chown <[email-masked]> wrote:
> 
> I think there are good grounds in this case.  There is (apparently) no vendor interest, but it's also a very vague document, where if any vendors do decide to implement, it's highly likely that those implementations will result in different host behaviour.  

I think it would be better to clear up the vague pieces so that we can have a reasonable conversation about the draft. I personally think just the existence of an implementation is not a sufficient step to clear this up. Let me give you an example to show why I think so. I had an implementation of the M and O bit flags on the router side and I have seen several implementations of the flags on the host side, but the results were still a crapshoot. You could not tell up front for a given combination of the flags what a host would do. I have had customers ask me “I want the host to use stateless DHCPv6 to get config information but I do not want them to try to use stateful DHCPv6 (IA_NA)”. I told them to use M=0 and O=1 but the results were all over the place. 

> Thus exploring interpretations of the draft on specific platforms, and observing the resulting behaviours and interactions, seems a pretty prudent step.  This may help refine the draft to be more specific, and uncover perspectives that as yet have not been considered.  It's not like the draft needs to be rushed through quickly.

Yep. We have been fine this long without it. Agree that we should not rush it.

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Oct 2018 00:13:46 +0200

Hello, Lee,

Just to provide a different perspective... ;-)

On 10/23/18 9:50 PM, Lee Howard wrote:
[....]
> I think multiple interoperable implementations exist.

.. which go against RFC8200 and the consensus of this wg. (eh insertion)

> It's -00, but we should look for running code before publication.

Should look at the doc.. but implementations normally do rate limiting,
already.

> Also -00, but I'd hope to see code before publication.

... or not. If there are, there will be more cycles spent on it as/if
the document is tweaked on the way to its publication.

> I think we had seen code; not sure, but I don't recall objections from

Many implementers don't follow our process, though. And there can also
be cases of folks working with the network code of an OS, without
devoting a lot of thought to protocol design/engineering. (it may or may
not be the case)

> Internet Protocol, Version 6 (IPv6) Specification Errata        2017-07

Yes and not. Flow Label is pretty recent. There's not much real-world
experience with EHs at global scale, and some of the updates were fairly
recent (although there was running code).

> Path MTU Discovery for IP version 6

This one is tricky. Code was "running", but PMTUD known to be
problematic on the public Internet. (That's why we produced PLPMUTD in
the first place).

> No running code applicable

There was running code for RFC7217, which is what RFC8064 recommends. By
the time RFC7217 was published, there was, at east, a Linux kernel
implementation. Most implementations came after RFC7217 -- although I
did do my best to socialize stable-privacy with developers.

> No running code applicable.

By the time this go published, the corresponding change had already been
comited to the Linux kernel.

> in practice for 6man. We just haven't had to ask before.

I'd say there have been varying experiences. As an author, getting
implementers involved (no matter there's code or not) helps spot stuff
that should be clarified, learn about details of different
implementations (e.g. some of our assumptions may not apply to all
implementations), etc. However, what happens with one implementation
need not apply to others. For example, it is probably quite different to
do RFC7217 in the kernel vs in a daemon such as dhcpcd (which many OSes
employ nowadays).

In this particular case (ipv6-only flag), what goes on the wire is
simple enough that..I don't think having an implementation will buy much
wrt how different implementations interoperate with each other. And the
insights you'll gain from an implementation are most likely "out of the
scope of the I-D", since how you disable the IPv4 stack is certainly
going to be very implementation-dependent. (me thinking out loud)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Oct 2018 00:57:27 +0200

On 10/24/18 12:09 AM, Suresh Krishnan wrote:
> Hi Tim,
> 
>> On Oct 23, 2018, at 5:24 PM, Tim Chown <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> On 23 Oct 2018, at 19:26, Suresh Krishnan <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> On Oct 23, 2018, at 2:05 PM, Sander Steffann <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'd like that to become the norm though. Having a running prototype
>>>> can help enormously when writing specifications. My preference would
>>>> be to move back to a base principle of running code and rough
>>>> consensus, instead of only rough consensus.
>>>
>>> If the WG decides to go on this path, I will be fully supportive of
>>> that. This model has worked out well for idr (see
>>> https://trac.ietf.org/trac/idr/wiki#ImplementationRequirement). What
>>> I am uncomfortable with is that criterion being *selectively* applied
>>> to this draft as a prerequisite for progress. 
>>
>> I think there are good grounds in this case.  There is (apparently) no
>> vendor interest, but it's also a very vague document, where if any
>> vendors do decide to implement, it's highly likely that those
>> implementations will result in different host behaviour.  
> 
> I think it would be better to clear up the vague pieces so that we can
> have a reasonable conversation about the draft. I personally think just
> the existence of an implementation is not a sufficient step to clear
> this up. Let me give you an example to show why I think so. I had an
> implementation of the M and O bit flags on the router side and I have
> seen several implementations of the flags on the host side, but the
> results were still a crapshoot. You could not tell up front for a given
> combination of the flags what a host would do. I have had customers ask
> me “I want the host to use stateless DHCPv6 to get config information
> but I do not want them to try to use stateful DHCPv6 (IA_NA)”. I told
> them to use M=0 and O=1 but the results were all over the place. 

Well, yes. A bit orthogonal, but: Automatic configuration is a bit of a
mess. That's why I asked about "architecture" in a different thread. It
all looks like many folks don't expect DHCPv6 to be actually used, and
whenever there's something DHCPv6 might be useful for, the functionality
is replicated  into SLAAC. Still, DHCPv6 continues to be actively
developed (and dhc wg operating).

>> Thus exploring interpretations of the draft on specific platforms, and
>> observing the resulting behaviours and interactions, seems a pretty
>> prudent step.  This may help refine the draft to be more specific, and
>> uncover perspectives that as yet have not been considered.  It's not
>> like the draft needs to be rushed through quickly.

That's why I noted that, in order for this to be of use, we should
expect all hosts to react in the same way, modulo some cornercases. BUt
many folks assume that in the short term, the "exceptions" to the
"SHOULD" in ipv6-onlyflag will rule, and that will eventually change in
the future. FWIW, that doesn't seem to be a good outcome.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Oct 2018 02:18:50 +0200

Hi, Jen,

On 10/19/18 2:22 PM, Jen Linkova wrote:
> onlink).

Depends on the pov: removes a vector if you don't employ v4, creates one
if you do.

>  Attacker might send a rogue RA and *enable* Ipv4 on hosts but
> obviously RA Guard should be deployed on v6-only networks. 

If only RA-Guard implementations had been fixed as described in RFC7113.
As far as I know, most haven't.

> In other

If you have v4 security in place, but no v6 securty in place, you *can*
do something that otherwise couldnt.

> attacker to respond, for example, to TCP SYN. 

That assumes that you have "hijacked" the RDNSS in the first place. And
that you can get a copy of what the victim sends (unicast) on the
network -- can be done, but ned not be the case.

>  It's even worse if you

But yes, this is a problem, indeed. See e.g.:  RFC7359

> 0 (as well as zero default router lifetime) - might help with rogue

If the network si meant to be ipv4 only, you better drop v6 at layer 2.

> maybe there is one? I'm happy to craft smth if it does not exist).

It does: RFC7123 :-)

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Oct 2018 15:54:48 +1300

On 2018-10-24 11:13, Fernando Gont wrote:

<snip>

> going to be very implementation-dependent. (me thinking out loud)

Exactly right. There isn't actually an interop requirement of any kind.
This is a one-way signal from the routers to each host, and each host
may choose what to do with that information. Legacy hosts will ignore
it, for example. A host with a sophisticated connection manager might
use a complicated heuristic, and there are many possibilities in
between, which is the reason that the draft uses SHOULD language.

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Oct 2018 05:20:40 +0200

> between, which is the reason that the draft uses SHOULD language.

Without endorsing or opposing to the proposal what I would expect is
that it's quite clear what is expected from hosts in response to the bit.

If, when sending the bit set you get each node doing it's own thing (one
reduces timers, another disables the stack forever, another disables it
but might re-enable it when the bit is no longer set, etc.), that would
be an undesirable outcome. Me, I think it should be clear what to do
with the bit, and the exceptions (the corner cases when you might go
against the advice) should be spelled out.

(things like e.g. what we have with SLAAC/DHCPv6 interaction ar, IMO,
quite undesirable)

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Oct 2018 08:14:53 +0200

> On 24 Oct 2018, at 05:20, Fernando Gont <[email-masked]> wrote:
> 

+1

Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Oct 2018 08:47:30 +0200 (CEST)

> against the advice) should be spelled out.

I don't think we'll ever get to an agreement on what a device should do, 
short term. There could be some kind of BCP document, but that'd have to 
be an operational document and that would definitely require running 
code to test it out.

Also we have no working group where we can discuss it, sunset4 is no more.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Oct 2018 10:44:04 +0200

Le 22/10/2018 à 12:04, Tim Chown a écrit :
>>> What's happened now is that a new revision of the draft has been
>>> posted, and the process of posting it seems to have white-washed
>>> all the outstanding technical issues.
>> 
>> the proposed mechanism", you'd be right. This isn't about the best
>> way to ensure IPv6-onlyness of a link; it's about one particular
>> mechanism towards that goal. We could say less, or nothing at all,
>> about other such mechanisms.
>> 
>> The WG may of course conclude that the mechanism isn't worth the
>> bother. If that's the conclusion, the draft will not advance.
> 

Well, maybe not in RA, but certainly there is huge vendor support on
cellular links of a similar functionality: PDP type IPv6 (option among 
IPv4, IPv6 and IPv4IPv6).

Earlier, some of these vendors moved from IPv6 w/o any RA, to some RA
functionality.  In this direction one could expect these vendors to move
that functionality (specify PDP type to be IPv6) from link-layer
messaging to RA.

But yes, it is just speculation on my side.

> Were they to come forward, I suspect interpretation and
> implementation would vary, given the vagueness of the flag's nature
> as a hint, causing inconsistent behaviour between various
> hosts/devices.

I agree.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Oct 2018 11:10:49 +0200

Le 23/10/2018 à 20:33, JORDI PALET MARTINEZ a écrit :
> There are many authors that don't have time, resources, access to
> the source code from vendors, or even knowledge, among many many
> many other possible reasons, to implement an ID they submit.

An additional reason is the following: it can be a waste of time
implementing something whose spec gets scrapped.

This reason typically applies when implementing an individual proposal 
Internet Draft.

Alex

> Also, there will be IDs which are not "implementable", etc., and
> clearly that doesn't disqualify that it may be a perfectly valid
> work.
> 
> Regards, Jordi
> -----Mensaje original----- De: ipv6 <[email-masked]> en 
> nombre de Suresh Krishnan <[email-masked]> Fecha: martes, 
> 23 de octubre de 2018, 20:26 Para: Sander Steffann 
> <[email-masked]> CC: Fernando Gont <[email-masked]>, 
> "[email-masked]" <[email-masked]> Asunto: Re: Running code (Was: I-D 
> Action: draft-ietf-6man-ipv6only-flag-03.txt)
> 
> 
>>> That's kind of my take, as well However, I think that asking for 
>>> an implementation of the ipv6-only flag is a requirement that I 
>>> have never seen for taking new work or publishing it, so it
>>> would be unfair to ask that to the authors of this particular
>>> I-D.
>> 
> I am uncomfortable with is that criterion being *selectively*
> applied to this draft as a prerequisite for progress.
> 
> Thanks Suresh
> 
> ********************************************** 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: Job Snijders <[email-masked]>
Date: Wed, 24 Oct 2018 12:30:57 +0200

On Tue, Oct 23, 2018 at 10:03:35PM +0200, JORDI PALET MARTINEZ wrote:
> Let’s suppose there is a draft and nobody wants to implement it.

full stop. then the document does not need to be published.

> Another draft is implemented. May be after some time the one that was
> not implemented get more market success than the other one.

fantastic, at that point the document can move forward again in the
publication process. 'market success' implies running code came into
existence.

> This is discriminating both drafts in the IETF process, and we must
> not do that. It may happen even “you have programmers” that are good
> friends, they will do for me and in the other way around. Or I’m a
> vendor, so I’ve the resource to do it.

This is not discrimination. If authors don't have the capability to
develop running code themselves, and also don't have access to resources
nor are able to convince others to implement a protocol specification...
the IETF's prime directive of interoperability can't be met anyway.

Some ideas gain traction, some don't - this happens to all of us.

> This will mean at the end that we balance the IETF work towards those
> that can (somehow), get things implemented, even if is a bad work (I
> understand that still need to follow the consensus, etc.).

Bias towards getting things implemented is an excellent way to foster a
stream of healthy specifications. Invariably the creation of running
code leads to higher quality specifications as implementers provide
their feedback to the WG. We don't work in the void, we're here to do
tangible things. This is not an academic exercise.

> At the end, we may have open source implementation of a draft, and not
> being adopted by vendors, or in the other way around. That’s not a
> good way to classify “good” or “bad” IETF work, also because after
> some years, what was “bad” is adopted as good, and viceversa.

I don't understand your 'open source' vs 'vendors' statement, they are
the same, both are vendors. The publication license and cost are
irrelevant.

> I understand that when IETF started, it was very few work and it was
> very easy to ask for code for everything, but our industry changed and
> we can’t enforce that, even at WG level.

I don't think 'our industry changed' means that we can now do without
code. We can absolutely enforce it, also at the WG level. IDR working
group is living proof. The QUIC and TLS13 groups have done excellent
work and only got to the point where they are by investing time &
resources to produce lots of running code.

Raising the bar is a good thing!

Kind regards,

Job

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 24 Oct 2018 13:08:07 +0200

Then the vendors that have the power to implement everything they want, definitively win, only because they are able to implement it, not necessarily because it is good or bad, and the argument of the implementation will be a tool to reach consensus, even if it takes longer, more versions, etc. This is real life.

Very good ideas that don't become standards because during the ID development don't get implemented (even if they will become implemented once they become RFCs), lose.

I'm sure there have been already many IETF documents that have been in both situations. Market decides at the end. But that's the thing: at the end, most of the time only when there is an RFC.

A couple of examples I can remember, IPv6 site local (it was an RFC) and draft-ietf-ipv6-dns-discovery, different process stages, both got implemented by many OS vendors and also Linux. No longer used.

I'm sorry but it is discrimination.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Job Snijders <[email-masked]>
Fecha: miércoles, 24 de octubre de 2018, 12:31
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: Fernando Gont <[email-masked]>, Suresh Krishnan <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

    

    

    

    

    
    Kind regards,
    
    Job

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Oct 2018 14:43:20 +0200

Hi,

Le 24/10/2018 à 12:30, Job Snijders a écrit :
[...]
> develop running code themselves, and also don't have access to
> resources nor are able to convince others to implement a protocol
> specification... the IETF's prime directive of interoperability can't
> be met anyway.

On windows install python and scapy, then make an RA[*] and write
b.res=1. This sets the 6th Reserved flag, now called 'IPv6-Only'.

I just sent one, hoping sky wouldnt fall on my head :-)

Alex
[*] how to make an RA with scapy tool is described at
https://samsclass.info/124/proj11/proj9xN-scapy-ra.html

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Oct 2018 15:17:42 +0200

correction: b.res=2 (instead of 1).

attached the packet capture

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Oct 2018 15:30:48 +0200

context: I sent this RA with IPv6-only flag in a switched sizeable
IPv4-only office network.

To my surprise I now keep receiving TCP SYNs from some neighbours who
insist on reaching a few particular GUAs starting with 2620:, 2a00: and
2a02:. These neighbors self-configured addresses in the "d00d" prefix
that is specified in that scapy RA howto, and this woke up their IPv6 stack.

An hour passed and have not received a call from IT department, which is
good. (typically they call very soon when there is some security risk).

I think the IPv6-only flag does not break anything at this time (the TCP
SYN flood I get is because I put a fake prefix there d00d; but IPv6
Hosts should learn to not blindly trust someone sending an RA for playing.)

Alex

Le 24/10/2018 à 15:17, Alexandre Petrescu a écrit :
>> Le 24/10/2018 à 12:30, Job Snijders a écrit : [...]
>>> This is not discrimination. If authors don't have the capability
>>> to develop running code themselves, and also don't have access
>>> to resources nor are able to convince others to implement a
>>> protocol specification... the IETF's prime directive of
>>> interoperability can't be met anyway.
>> 
>> Alex [*] how to make an RA with scapy tool is described at 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Job Snijders <[email-masked]>
Date: Wed, 24 Oct 2018 15:52:33 +0200

Dear Jordi,

On Wed, Oct 24, 2018 at 1:08 PM JORDI PALET MARTINEZ <[email-masked]> wrote:
> Then the vendors that have the power to implement everything they
> want, definitively win, only because they are able to implement it,
> not necessarily because it is good or bad, and the argument of the
> implementation will be a tool to reach consensus, even if it takes
> longer, more versions, etc. This is real life.

I wouldn't position yourself as 'powerless': you can fork any Linux or
BSD IP stacks yourself and make modifications - or you can hire people
to do so, or work with students. We are all vendors if we choose to be -
we all have this "power". And even if it takes longer, if drafts need to
go through more revisions - it usually is a sign the quality and
readability are increasing.

> Very good ideas that don't become standards because during the ID
> development don't get implemented (even if they will become
> implemented once they become RFCs), lose.

Can you point me to a protocol extension specification that was a
valuable publication, specifically as RFC, but does not have any
implementations? I see no harm for such drafts to wait for publication
until some implementation is done.

> I'm sure there have been already many IETF documents that have been in
> both situations. Market decides at the end. But that's the thing: at
> the end, most of the time only when there is an RFC.
>
> A couple of examples I can remember, IPv6 site local (it was an RFC)
> and draft-ietf-ipv6-dns-discovery, different process stages, both got
> implemented by many OS vendors and also Linux. No longer used.

No longer used? Consider proposing them to be deprecated! Pruning
specifications that turned out to be "not the best idea" is also an
important part of protocol maintenance.

> I'm sorry but it is discrimination.

I really don't see it, for more information on what discrimination means
to people please take a look at https://en.wikipedia.org/wiki/Discrimination

I suspect you are using such strong words to make an appeal to emotion.

Kind regards,

Job

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Oct 2018 10:46:25 -0400

The IDR working group does have requirements on having implementations 
of drafts before they complete their work on the draft.

I would prefer not to extend that as a requirement to other working 
groups.  Treating it as desirable, something we ask for, etc. is fine 
and makes sense.

In my case, I am not in a position (and have not been for many years) to 
implement these things myself.  I do work with the implementors.  While 
I can not commit for my product line folks who set schedules, the 
primary reason i have for working on a draft is that it is something we 
want to put in our product.  Getting resources to put it in even a 
demonstration version NOW however is MUCH harder.  Sometimes it happens. 
  Usually, I can't do that.  And even if I can get it implemented early 
to check things, I may not be permitted to talk about that implementation.

Yours,
Joel

---

From: Lee Howard <[email-masked]>
Date: Wed, 24 Oct 2018 12:10:10 -0400

> IPv4-only office network.

Thanks for trying this. I don't think it satisfies my desire for 
implementation, which was to see how clients would respond. I gave the 
specific case where clients responding differently might actually stop 
interoperating (i.e., if some used IPv4 and others did not).

> that is specified in that scapy RA howto, and this woke up their IPv6 

You sent an "ipv6only" flagged RA to an IPv4-only network, and now some 
devices on the network are trying to use you for IPv6 connectivity?

> good. (typically they call very soon when there is some security risk).

If it's an IPv4-only network, could it be that they have no tools for 
assessing IPv6 security risks?

This sounds pretty broken. Great example of why all networks need IPv6: 
if you're not running IPv6 on your network, somebody else (maybe 
Alexandre) is.

> Hosts should learn to not blindly trust someone sending an RA for 

That, too.

Lee

---

From: Lee Howard <[email-masked]>
Date: Wed, 24 Oct 2018 12:21:50 -0400

On 10/24/18 7:08 AM, JORDI PALET MARTINEZ wrote:
> Then the vendors that have the power to implement everything they want, definitively win,

Yes. The people who write the code that implements the protocols we use 
on the Internet are the ones who. . . do that.

>   only because they are able to implement it, not necessarily because it is good or bad, and the argument of the implementation will be a tool to reach consensus, even if it takes longer, more versions, etc. This is real life.

If two implementers can't tell from a draft what to do to make sure 
their implementations can interoperate, the draft should not advance, 
regardless of how good the idea is. In this case, one OS could say, 
"That's advisory, I'll ignore it and do everything over IPv4," another 
could say, "The router has no IPv4 but I'm using IPv4 for service 
discovery, so I'll keep doing it," and a third could say, "RA says no 
IPv4, I'm disabling the stack." All comply with the document as written, 
but those three systems would have a very hard time communicating.

What guidance would you give those implementers? Can we put that 
guidance into the draft?

> A couple of examples I can remember, IPv6 site local (it was an RFC) and draft-ietf-ipv6-dns-discovery, different process stages, both got implemented by many OS vendors and also Linux. No longer u…

Implementation is not a guarantee of deployment.

Non-implementation is a guarantee of non-deployment.

> I'm sorry but it is discrimination.

Yes. We are trying to discriminate between clear documents and vague 
documents. From what I can see, developers can write completely 
compliant implementations that break communications between systems on a 
network.

We also discriminate between ideas that help and those that hurt, or 
even those that do no harm but are useless. If we never discriminated, 
we would publish every draft.

Lee

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Oct 2018 19:33:20 +0200

On Wed, Oct 24, 2018 at 12:21:50PM -0400, Lee Howard wrote:
> If two implementers can't tell from a draft what to do to make sure their
> implementations can interoperate, the draft should not advance, regardless
> of how good the idea is.

Agreed

> A) In this case, one OS could say, "That's advisory,
> I'll ignore it and do everything over IPv4,"

> B) another could say, "The router
> has no IPv4 but I'm using IPv4 for service discovery, so I'll keep doing
> it,"

> C) and a third could say, "RA says no IPv4, I'm disabling the stack."

> All
> comply with the document as written, but those three systems would have a
> very hard time communicating.

Why would any of those nodes have problems communicating via IPv6 with
each other ?  Its a basic happy eyeball problem of selecting the IP version
that works best in dual stack, right ? If they fail to communicate via IPv6 it
sounds to me A) or B) are violating those pre-existing requirements.

The way i see it, the resulting behavior on a host MUST NOT be anything
that is not already defined behavior, just triggered differently, or
else the new behavior has to be spelled out by the draft and the
interop with existing hosts/happy-eyeball recommendations has to be
described.

C) is existing behavior, it's called non-dual-stack-IPv6-only-host,
just thats its triggered here differently so thats safe i think.

A) is also existing behavior, that's safe too.

I am not sure what exactly you mean with B), but it sounds broken
already in the absence of the new RA option because if it doesn't
interop with C) it wouldn't interop with an IPv6 only host on he LAN
either.

The draft does mention IMHO new behaviors like 

D) Bring up IPv4 on-demand. Thats new and i mentioned that previously in
email, IMHO thats something that should be defined separately and vetted
separately. Sounds like a cool IPv4 sunset option, but quite difficult.

E) Do not do RFC3927. Sounds fine to me, because i think this is
pre-existing functionality in many IPv4 nodes (i hope there is no
host requirement to support RFC3927). 

> What guidance would you give those implementers? Can we put that guidance
> into the draft?

Agree on as specific guidance as is agreeable to the WG to be put into
the draft.  Just don't think that consistency (one single recommendation) across
all hosts on a LAN is necessary. See above.

> Implementation is not a guarantee of deployment.

Implementation is a guarantee to make bad ideas big pains for years to
come. Especially when its conception process is as nasty as site local was. 
There is a lot to be said about well vetted drafts before implementing.

> documents. From what I can see, developers can write completely compliant
> implementations that break communications between systems on a network.
> 
> We also discriminate between ideas that help and those that hurt, or even
> those that do no harm but are useless. If we never discriminated, we would
> publish every draft.

And there are different hurts.

I think hurt to operations can be eliminated through above discussed
better guidance, e.g.: "don't make hosts do new things to IPv4, just
use this as a new trigger for existing modes to operate or non-operate
v4".

I'd be even happy if no host use the trigger and its just for
diagnostics showing up in a GUI (IPv4 not supported on this network).

The hurt to the RA codepoint space is IMHO a more difficult problem to
vet because i have no idea about the likelyhood of running out and
workarounds if one does, so the value of this options seems to need to
be quite high to justify the desired encoding. IMHO it would help a lot
to use an encoding that wouldn're quire justifing a high-value of the
feature.

Cheers
   Toerless

---

From: Lee Howard <[email-masked]>
Date: Wed, 24 Oct 2018 14:24:34 -0400

> sounds to me A) or B) are violating those pre-existing requirements.

Case A could decide to use/prefer/do everything over IPv4.

There is no requirement to implement Happy Eyeballs. Indeed, it is 
intended for eyeball applications, where users get tired of waiting, not 
for deciding which IP version to use underlying a service discovery 
protocol, for instance.

> interop with C) it wouldn't interop with an IPv6 only host on he LAN

The document specifically says, "IPv4-only hosts, and dual-stack hosts 
that do not recognize the new
    flag, may continue to attempt IPv4 operations, in particular IPv4
    discovery protocols typically sent as link-layer broadcasts."

> host requirement to support RFC3927).
RFC3927 "

  Dynamic Configuration of IPv4 Link-Local Addresses"

i.e., 169.254.0.0/16

Now, the draft does say:
    Administrators SHOULD only use this mechanism if they are certain
    that the link is IPv6-Only.  For example, in cases where there is a
    need to continue to use IPv4, when there are intended to be IPv4-only
    hosts or IPv4 routers on the link, setting this flag to 1 is a
    configuration error.
~

But that's a SHOULD not a MUST (as I noted in previous comments). Now 
that we're discussing further, I think it's wrong to say "the link is 
IPv6-Only," but needs to say, "there are no hosts using (or dependent 
on) IPv4 on the link." Saying a "link" is IPv6-Only might mean no more 
than a router interface has an IPv6 address and IPv4 unnumbered, or even 
less than that, since links don't get addresses.

> There is a lot to be said about well vetted drafts before implementing.

Huh? Not even slightly.

Many implementations never see production deployment, and are simply 
proofs-of-concept.

Many implementations are well-executed and are good ideas.

I can't wrap my head around this assertion.

> use this as a new trigger for existing modes to operate or non-operate
I agree that would reduce the risk.
> to use an encoding that wouldn're quire justifing a high-value of the

Interesting point. The draft does point out that there are only two bits 
left, but extended space is available (Section 4 of rfc5175 "IPv6 RA 
Flags Options").

Of course, if no one will implement and/or no one will deploy, then the 
hurt is to the time of the people participating in this discussion.

Lee

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Oct 2018 21:36:12 +0200

On Wed, Oct 24, 2018 at 02:24:34PM -0400, Lee Howard wrote:
> There is no requirement to implement Happy Eyeballs. Indeed, it is intended
> for eyeball applications, where users get tired of waiting, not for deciding
> which IP version to use underlying a service discovery protocol, for
> instance.

Hmm. Maybe i am overexpecting what dual stack hosts should do, maybe
what i am thinking of is not called happy eyeballs but categorized
differently. ICE for example tries to figure out which combination of
local/remote addresses works best across all address families and i
thought there where various more lightweight similar methods not tied to just
ICE/STUN capable apps.

> The document specifically says, "IPv4-only hosts, and dual-stack hosts that
> do not recognize the new flag, may continue to attempt IPv4 operations,
> in particular IPv4 discovery protocols typically sent as link-layer broadcasts."

Sure, but thats just a statement of fact (can't change behavior of nodes
you can't influence), not a goal of the proposal.
See your discuss about rfc3927 below for more.

>  Dynamic Configuration of IPv4 Link-Local Addresses"

Right.

> But that's a SHOULD not a MUST (as I noted in previous comments). Now that
> we're discussing further, I think it's wrong to say "the link is IPv6-Only,"
> but needs to say, "there are no hosts using (or dependent on) IPv4 on the
> link." Saying a "link" is IPv6-Only might mean no more than a router
> interface has an IPv6 address and IPv4 unnumbered, or even less than that,
> since links don't get addresses.

The SHOULD could cover the case where the LAN hosts some IPv4 only hosts
whose mutual communication will not be impacted by this feature, in
which case it is still OK to set the flag.

I think a better statement would be to say that the flag indicates the
operators desire to enable and support only IPv6 communications  on the
subnet and optimize it for those nodes supporting the feature.
Additional IPv4-only host communication may continue to run as ships in
the night.

Which leaves the question about the impacts of communications between
dual-stack nodes and partial feature support where i'll stick to my
notion that the most lightweight guidance is what the behavior of a node
should be one of already used modes, just triggered in a new way. Which
may not be complete, but would need to be reminded better of current
expected or possible happy-eyeball style requirements/options.

> I can't wrap my head around this assertion.

Is it my english ? I agree with your statements, but i don't think my
statements contradict them. I was just saying that specs should be
worked out as good as possible, and not lazily hope for implementations to find
bugs that could have been found in design/review of the spec.

> left, but extended space is available (Section 4 of rfc5175 "IPv6 RA Flags
> Options").

Use the extended space then ?

> Of course, if no one will implement and/or no one will deploy, then the hurt
> is to the time of the people participating in this discussion.

Talking about guidelines, i can't remember where i heard
"Never stand in the way of a bad idea", but it solves that issue:
Spend time only on ideas you think could be(come) useful or be made better by
your input.

Of course, it's not ideal, but i think everyone who has tried to reject
a bad idea in IETF in the past knows how that can be a lot more time
consuming than just ignoring it, and the outcome is at most that you
have to spend more time pitching a better solution to the problem to
customers confused by bad ideas. And if ultimately what you continue to
think is a bad idea wins big in the market place, you may have been
technically right but practically wrong anyhow.

Oh, and while we are at it, another unsolicited service reminder:

The "We reject: kings" part of the IETF dogma is suspended for Thailand.
;-)

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Oct 2018 08:54:28 +1300

> against the advice) should be spelled out.

That's exactly the reason for using an RFC2119 SHOULD - but spelling out
all the corner cases seems like an impossible task.

> (things like e.g. what we have with SLAAC/DHCPv6 interaction ar, IMO,

Agreed. But if that was easy to fix, we'd have fixed it years ago.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Oct 2018 23:38:11 +0200

> all the corner cases seems like an impossible task.

I'd expect that, say, you spell out the cases that made you use "SHOULD"
rather than "MUST". Put another way: what are the scenarios that you
have already envisioned where hosts shouldn't disable the IPv4 stack?

If I had to code the host part, for example, I'd wonder: Should I
disable IPv4 for mDNS? If the network is marked as IPv6-only does it
meant that I shouldn't even try to find, say, a network printer using
IPv4 link-local addresses (169...)?

Putting this mechanism (ipv6-only flag), I am not sure the extent to
which you might want to disable IPv4 completely. For instance, there are
networks that, whether we like it or not, end up learning the RDNS
address via DHCPv4, because e.g. they employ a version of MS Windows
that predates W10.

Or the network might not use IPv6 itself, but nodes might need IPv4 for
"peer to peer" stuff withing the network (whether transferring files,
printing documents, etc.). And those services are not provide by "the
network", so the networrk admin doesn't have much of a say about them
(i.e., he/she might not even know about apps that might require IPv4).

> Agreed. But if that was easy to fix, we'd have fixed it years ago.

I'd say it's worse than that: we don't even seem to have much of a model
for automatic configuration, and keep contributing to that mess. I
believe we should have a clear model about what goes where, etc....
rather than continuing adding features (normally to SLAAC) with the
implicit idea of "well, if the feature is needed, and since nobody is
gonna use DHCPv6, we should add it to slaac". (which I don't necessarily
object.. but if we're really going to do that, we better stop working on
dhcpv6).

For some of us that at times have to explain IPv6 to newcomers, the part
where we get to autoconfiguration is... quite uncomfortable, so to
speak. (particularly when it gets to how to convey info about RDNSS, no
routes in DHCPv6, etc.)

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Oct 2018 11:15:21 +1100

> On 25 Oct 2018, at 8:38 am, Fernando Gont <[email-masked]> wrote:
> 

When you as the administrator of the host know that the administrator of
router erred.

When you as the administrator of the host configure the host to only talk
to a subset of otherwise reachable machines over IPv4.

When you as a administrator of the host want to test something.

> IPv4 link-local addresses (169…)?

Yes.  The assumption when the flag is set is that all the boxes are IPv6
capable.

> address via DHCPv4, because e.g. they employ a version of MS Windows

If I was implementing it the interface would become un-numbered for IPv4,
the DHCP client would be disabled, mDNS would not be attempted over IPv4.

I might gate that decision on whether there is a working IPv4 lease or not
(see SHOULD).

> (i.e., he/she might not even know about apps that might require IPv4).

Then the network is not IPv6-only and you shouldn’t be setting the flag.

You can do a thousand "what if someone does something stupid”.   

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

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 25 Oct 2018 03:04:44 +0000

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

capable.

Okay, you are speaking as the network admin.

And, as a network admin, wanting to stop all IPv4 traffic for whatever network admin reason, it is feasible tout de suite, today, to simply filter Ethertypes 0x0806 and 0x0800, in your switches and router Ethernet interfaces. No need to wait for the IETF.

And similarly, from an equipment vendor's perspective, say your goal as smartphone maker is to extend battery life, make it your own responsibility to do what's best for your user. Don’t expect the network admin to care. Probe the network, see if IPv6 is sufficient for your user's needs, and if yes, then no op the IPv4 stack. The network admin couldn't care less, potentially. Why count on him/her?

So in short, why do we actually need any flag in the IP header?

Bert

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Oct 2018 14:16:17 +1100

> On 25 Oct 2018, at 2:04 pm, Manfredi (US), Albert E <[email-masked]> wrote:
> 

It isn’t a flag in the IP header.

Not all equipment can filter on Ethertypes.

Heuristics are not enough.  I know of no machine that can say “There are no IPv4 only devices are expected to be connected to this network in the future” based on heuristics.  Just trying to work out if you can connect to every device on the network over both IPv4 and IPv6 for every service they offer is a impossible task which is where you would need to be to decide to automatically shutdown IPv4 link-local.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Oct 2018 16:20:29 +1300

> So in short, why do we actually need any flag in the IP header?

Please read the draft again, since it intends to answer that exact question. (Nick and others have objected to some assertions in the text, but regardless of that... the draft intends to answer your question.)

   Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 25 Oct 2018 05:29:08 +0000

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

> Please read the draft again, since it intends to answer that exact question. (Nick and others have objected to some assertions in the text, but regardless of that... the draft intends to answer you…

   However, hosts transmitting IPv4 packets would still do so, consuming
   their own battery power and some radio bandwidth.  The intent of this
   specification is to provide a mechanism that prevents such traffic,
   and also works on networks without the ability to filter L2 traffic,
   or where there are portions of a network without the ability to
   filter L2 traffic.  It may also be valuable on unmanaged networks
   using routers pre-configured for IPv6-only operations and where Layer
   2 filtering is unavailable.
   ...
   Because there is no IPv4 support on IPv6-only routers, the only way
   to notify the dual stack hosts that this link is IPv6-Only is to use
   an IPv6 mechanism.  An active notification will be much more precise
   than attempting to deduce this fact by the lack of IPv4 responses or
   traffic.

So, the network doesn't want to support IPv4. Is it not possible for the devices on the network to use their own updated heuristics? Their own timeout timers, without having to rely on the network admin? This much we already discussed briefly, earlier on. Is it not just as easy to tell device makers that some networks may be dropping IPv4 altogether, and let these device makers do what's right, instead of saying that the network will transit this flag, to achieve that same purpose? Either way, the hosts will need updating. (Some device makers will eventually give IPv6 priority.)

In networks where IPv4 can legitimately be dropped, in principle, the admin will have determined that all legitimate hosts can reach everything with IPv6. EtherType filtering primarily protects the network. If no EtherType filtering is possible in parts of the network, then what help is a flag? The hosts that will create nuisance broadcasts would be unable to read that flag anyway, because they are not updated, presumably. Still, the network can simply not route IPv4, not provide IPv4 addresses in the DNS, not respond to DHCPv4 requests. Without EtherType filtering, IPv4 broadcasts would remain a nuisance in those parts of the network, until those users give up. Yes, legacy IPv4 users will be irritated by long waits, and then failure. But no flag will help that. Those hosts are not updated to read the flag anyway. And updated hosts will have the new heuristics, to minimize or prevent these nuisances.

For networks that support both stacks, but the equipment vendor is serious about conserving battery power, that device may try IPv6 first, regardless of any flag, would adjust IPv4 timers regardless of any flag, and so on. Just to save power. Why rely on a network admin?

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

In this case, flag or no flag, any device with the updated IPv4 timeout timers, and especially those which try first to use IPv6, will be happy. Devices which will instead waste time insisting on IPv4, are not updated, and therefore, they won’t understand any flag.

   The intent is that the administrator of the router configures the
   router to set the IPv6-Only flag if she/he wants to tell the hosts on
   the link that the link is IPv6-Only.  This is a configuration flag,
   it is not something that the router decides on it's own.  Routers MAY
   log a configuration error if the flag is set and IPv4 is still active
   on the routers interface to the link.

I think I covered that above. It's a bit of a paradigm shift. Even without any new flag, the IETF can make device makers aware of this threat of no IPv4 service in some networks in the near future, and to take their own action. I don’t know how prevalent unmanaged switches are, in parts of the network that a network admin controls, but again, that is for network self-protection, mostly.

Bert

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Oct 2018 16:53:55 +1100

> On 25 Oct 2018, at 4:29 pm, Manfredi (US), Albert E <[email-masked]> wrote:
> 
> So, the network doesn't want to support IPv4. Is it not possible for the devices on the network to use their own updated heuristics?

Please go write down the heuristics that you think hosts should use to say “now is the time to turn off
IPv4 on this interface” and get it right?  I can’t think of any set of rules that will achieve that.

> Their own timeout timers, without having to rely on the network admin? This much we already discussed briefly, earlier on. Is it not just as easy to tell device makers that some networks may be dropping IPv4 altogether, and let these device makers do what's right, instead of saying that the network will transit this flag, to achieve that same purpose? Either way, the hosts will need updating. (Some device makers will eventually give IPv6 priority.)
> 

Because that really is the ONLY way to determine if a network that could be dual stack should be IPv6-only.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Oct 2018 15:35:03 +0200

Le 24/10/2018 à 18:10, Lee Howard a écrit :
> implementation, which was to see how clients would respond.

Maybe someone will write a client receiving this RA.

> I gave
> the specific case where clients responding differently might actually
> stop interoperating (i.e., if some used IPv4 and others did not).
> 
>> 
>> To my surprise I now keep receiving TCP SYNs from some neighbours
>> who insist on reaching a few particular GUAs starting with 2620:,
>> 2a00: and 2a02:. These neighbors self-configured addresses in the
>> "d00d" prefix that is specified in that scapy RA howto, and this
>> woke up their IPv6 stack.
> 
> You sent an "ipv6only" flagged RA to an IPv4-only network, and now
> some devices on the network are trying to use you for IPv6
> connectivity?

YEs.

>> An hour passed and have not received a call from IT department,
>> which is good. (typically they call very soon when there is some
>> security risk).
> 

Yes and no.  They do have many necessary tools, and their 3d version, so 
to say.  I do not know IPv4 vs IPv6.

> This sounds pretty broken. Great example of why all networks need
> IPv6: if you're not running IPv6 on your network, somebody else
> (maybe Alexandre) is.

Well, thank you :-)

I am happy many Hosts on this IPv4-only network already do a lot of IPv6 
chatter (DHCPv6, ICMPv6, LLMNR, MDNS, NTP, SSDP, TCP, UDP).

But, at the same time, I sense a little bit of worry of what might 
happen with these RAs.

I hope currently ALL Hosts silently ignore the bit 6 that is Reserved in 
the RA.

Alex

>> I think the IPv6-only flag does not break anything at this time
>> (the TCP SYN flood I get is because I put a fake prefix there d00d;
>> but IPv6 Hosts should learn to not blindly trust someone sending an
>> RA for playing.)
>> 
>> Alex
> 
> 
> That, too.
> 
> Lee
> 
> 
>> 
>> 
>>>>> This is not discrimination. If authors don't have the
>>>>> capability to develop running code themselves, and also don't
>>>>> have access to resources nor are able to convince others to
>>>>> implement a protocol specification... the IETF's prime
>>>>> directive of interoperability can't be met anyway.
>>>> 
>>>> On windows install python and scapy, then make an RA[*] and
>>>> write b.res=1. This sets the 6th Reserved flag, now called
>>>> 'IPv6-Only'.
>>>> 
>>> IETF IPv6 working group mailing list [email-masked]
>>> Administrative Requests:

---

From: Simon Hobson <[email-masked]>
Date: Thu, 25 Oct 2018 20:47:13 +0100

> When you as the administrator of the host know that the administrator of

From the OS vendor PoV, that's not a valid statement. The OS vendor does not know anything about your network - so really this is a case of providing a host specific configuration flag to over-ride something. In that respect, it's no different to manually configuring IPv6 addresses, manually setting routes, etc.

> You can do a thousand "what if someone does something stupid”.

Indeed, and if you wanted to cater for all possible such admin errors then you might as well go home because the more you make something foolproof, the more ingenious you find the fools are.

Manfredi (US), Albert E <[email-masked]> wrote:

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

> So, the network doesn't want to support IPv4. Is it not possible for the devices on the network to use their own updated heuristics? Their own timeout timers, without having to rely on the network…

OK, go ahead and state how you think that might work :D
Lets look as some possible clues to look at.

No DHCPv4 service on the network. Well it could be because the network doesn't do IPv4, or it could be that the server is down or unreachable at the moment, or it could be that devices on this network are manually configured, or it could be that this network is using all self-assigned addresses.

So lets look and see if there's already some IPv4 traffic on the network. So we see some mDNS traffic - does that mean we should be using IPv4, or does it mean that the other device got it wrong. So can't use that as a clue since any device transmitting IPv4 traffic would "wake up" IPv4 on all the other hosts - and it's already accepted that there will almost certainly be devices around that won't recognise this flag, and so will continue trying to use IPv4.

I think it's safe to say that any attempt to "figure it out" would be prone to getting it wrong - quite a lot. One thing I can say from <a few years> in IT is that one of the worst things to come across is some bit of software that makes assumptions about how my network runs. Or put another way, I would be really, **really**, **REALLY** p**sed off to find devices randomly turning IPv4 on/off according to what would appear to be about as reliable as reading the tea leaves. Dealing with that problem would be much much more work than dealing with the problems this flag is intended to solve. Like trying to get serious work in done in MS Word without turning off all the "helpful" auto-something features.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Oct 2018 08:52:58 +1300

>> So, the network doesn't want to support IPv4. Is it not possible for the devices on the network to use their own updated heuristics?

There's certainly no universal heuristic. For example, as I've said before,
there will be some devices that will never stop trying IPv4 whatever you tell
them - it doesn't really matter whether those are legacy devices or devices
whose implementer took a specific decision to ignore the flag. And there
will probably be devices that don't bother to look at the flag because
they don't even have an IPv4 stack in the first place.

I don't see why this matters. There's no interop problem here; the goal is to
reduce pointless IPv4 traffic, especially multicast. If different hosts
behave differently, so what?

> IPv4 on this interface” and get it right?  I can’t think of any set of rules that will achieve that.

No, because there's no universal right answer.

> Because that really is the ONLY way to determine if a network that could be dual stack should be IPv6-only.

Right. We're talking about the administrator's *intention* and computers aren't
very good at guessing human intention.

>> I think I covered that above. It's a bit of a paradigm shift. Even without any new flag, the IETF can make device makers aware of this threat of no IPv4 service in some networks in the near future…

Sure.

Look, it's entirely possible that we could suggest a heuristic that would work
for most hosts most of the time *without* this flag, based on tuning the
timers for DHCPv4 and other IPv4 actions. I think the notion of a v6ops draft
on this topic is a good one. The authors aren't going to insist on defining
a flag if there's a convincing case for an operational solution that works
without one. In the end we're after a statistical solution that stops most
useless IPv4 traffic most of the time. Because of differing host behaviours,
you can't stop all useless IPv4 traffic all of the time.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 26 Oct 2018 03:26:31 +0700

[top-posting]

OK, if this flag is not about providing host configuration, then I suggest we look at this from a different perspective. 

This is about providing meta-information about the link. Does it connect to the Internet / walled garden, free/charge structure etc.

There is existing work on this. prefix-properties, coloured prefixes that led to provisioning domains. And perhaps most appropriate from a layer perspective 802.11u. 

Cheers 
Ole

> On 26 Oct 2018, at 02:52, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 25 Oct 2018 21:53:09 +0000

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

> No DHCPv4 service on the network.

That's one possible hint. Another, perhaps better one, would for the host to see if it has any IPv4 default router available at all. From DHCP, from listening for router advertisements, or if one is set statically, can it be reached? Does ARP always fail? Are any ARP requests ever received from the network?

> So lets look and see if there's already some IPv4 traffic on the network. So we see some mDNS traffic - does that mean we should be using IPv4, or does it mean that the other device got it wrong.

That would be another hint. Does DNS give me any IPv4 addresses? As to whether anyone got anything wrong, well, the flag can also have been wrong. Was there a flag set on all routers, or was the IPv4 router only temporarily unavailable. We can play this game all day long.

I realize that many like to shut off ICMP, but ICMP would provide any number of hints too, when available, such as, ping the default router. I just don’t think it's very difficult for a clever host to probe the network for IPv4 service, which would serve the same purpose as the flag. And I don’t see a very convincing argument that a small number of such tests would be more prone to failure than a flag?

I mean, it's not like we have a huge mob begging for this flag. Many seem to be unhappy with it, for different reasons. So, put the onus on the equipment vendors, in case the netadmin wants to shut off IPv4, to determine how to proceed.

Bert

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 25 Oct 2018 21:56:42 +0000

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

> I think the notion of a v6ops draft

+1

Let's see if they are as opposed to the idea as RIPE NCC.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Oct 2018 18:51:29 +0200

> When you as the administrator of the host know that the administrator of

Administrator of the host? You must be operating in a different
environment? I'd bet the closest thing to "admnistrator" in a growing
and growing number of nodes is the app doing automated updates.

> When you as a administrator of the host want to test something.

Same as above.

> Yes.  The assumption when the flag is set is that all the boxes are IPv6

...and apps.

In which case, make the "SHOULD" a "MUST", and put an applicability
statement noting that.

> I might gate that decision on whether there is a working IPv4 lease or not

I would like that there is less of "I would", "I might" with "MUSTs" in
the spec.

> Then the network is not IPv6-only and you shouldn’t be setting the flag.

It depends what you mean by "the network". Only stuff that yu the net
admin runs? Does it also include nodes you don't control? If the later,
than "you never know".

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Oct 2018 10:19:28 +0200

Hi Jobs,

-----Mensaje original-----
De: Job Snijders <[email-masked]>
Fecha: miércoles, 24 de octubre de 2018, 15:52
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Job Snijders <[email-masked]>, Fernando Gont <[email-masked]>, Suresh Krishnan <[email-masked]>, 6man WG <[email-masked]>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

    Dear Jordi,

I was programming 45 years ago even in assembly with several CPUs and even ported a complete Real Time Unix to Motorola 6809, and did that for many years, but not recently, so I really doubt I'm a powerful programmer.

 
I think Lee provided a list of RFCs that aren't widely implemented or implemented at all.

Yes, this is the contrary case. Site-local was implemented, then deprecated. ipv6-dns-discovery was only a draft, was implemented, it worked, but even do didn't reached the RFC status.

    

It may be a language issue. For a Spanish, discrimination (not applied as a treatment to persons), it is "select excluding", for example "discriminate traffic flows".
    
    Kind regards,
    
    Job

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Oct 2018 10:20:56 +0200

This is a perfect example, even not knowing who is your employer, is not that easy to get that work, or to openly talk about that ...

Regards,
Jordi

-----Mensaje original-----
De: "Joel M. Halpern" <[email-masked]>
Fecha: miércoles, 24 de octubre de 2018, 16:46
Para: Job Snijders <[email-masked]>, JORDI PALET MARTINEZ <[email-masked]>
CC: Fernando Gont <[email-masked]>, Suresh Krishnan <[email-masked]>, 6man WG <[email-masked]>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

    
    
    Yours,
    Joel

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Oct 2018 10:25:28 +0200

Interoperability is a different thing, and this is the way we will actually be able to move RFCs to STDs (demonstrated interoperability and widely implemented).

If we don't allow documents, even before they are implemented (or as Joel said, before they can talk openly about the implementation), to get to RFCs, then we will not be able to move most of the work that vendors are waiting to become an RFC to implement or openly talk about that implementation ...

If something is discovered as broken or incomplete during the implementation, that's fine, we have -bis, or erratas, etc., same as we can deprecate something with demonstrates is useless or completely broken.

"to err is human"

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Lee Howard <[email-masked]>
Fecha: miércoles, 24 de octubre de 2018, 18:22
Para: <[email-masked]>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

    

    

    

    
    Lee

---

From: Simon Hobson <[email-masked]>
Date: Fri, 26 Oct 2018 10:07:03 +0100

Manfredi (US), Albert E <[email-masked]> wrote:

> That's one possible hint. Another, perhaps better one, would for the host to see if it has any IPv4 default router available at all.

A default (or any) router is not needed for IPv4 to be running and needed - so not really a good hint.

> Are any ARP requests ever received from the network?

Like, from all the other nodes trying to see if IPv4 should be used ? As I said, if some nodes are trying to figure it out, then they'll all see "IPv4 traffic" and assume it needs to be used - so it'll never be shut off.

>> As to whether anyone got anything wrong, well, the flag can also have been wrong. Was there a flag set on all routers, or was the IPv4 router only temporarily unavailable. We can play this game all day long.

Yes, we can compare apples and oranges all day. If the flag is set incorrectly then that's a positive action the administrator has taken - and if "stuff breaks" then the administrator can undo that action. In the same manner, perhaps we shouldn't allow administrators to manually set DNS servers in DHCPv4 - after all, if they set it wrong it will break the network !
If (or rather, when) the heuristics fail, you get random network failures which will be a right PITA to diagnose and even harder to fix. In practice I expect it would be a case of visiting each host and manually over-riding the heuristics.

> I realize that many like to shut off ICMP, but ICMP would provide any number of hints too, when available, such as, ping the default router.

The problem you have is that you are only considering the sort of network you seem to be familiar with. There are lots and lots of network topologies - some of which are isolated networks with no routers.
As I said earlier, one of the most "irritating" problems to deal with are those caused by vendors making assumptions about the network their equipment will be connected to. Such as having a UI that won't allow ".0" or ".255" as an address (assumes all networks are /24), UI that won't allow 192.168.x.x addresses to have larger than a /24 network (assumes 192.168 addresses are class C and won't allow supernetting, assume that the router will be doing DNS and don't allow other addresses to be used (the user won't want to use other servers), don't allow DHCP to be turned off (this must the the only router on the network), don't allow the default router address to be set in DHCP (again assumes this is the only router), etc, etc.
And you propose that the vendors come up with much more complicated, obscure, and harder to deal with assumptions about the networks the equipment be connected to.

> I just don’t think it's very difficult for a clever host to probe the network for IPv4 service, which would serve the same purpose as the flag. And I don’t see a very convincing argument that a small number of such tests would be more prone to failure than a flag?

OK, write down the rules to be used. No hand waving about "if <this> then that's a hint" - solid unambiguous rules, "if <this> then <that>".

Some hints to guide you :
There may (actually, almost certainly will) be devices on the network that won't be trying to turn off IPv4. They may be IPv4 only devices that the network admin doesn't care about breaking. So bear in mind that you can expect to see some IPv4 traffic on an "IPv6 only" network.
You may be on a network without a default router and/or without DHCP. Neither can be taken to signal lack of IPv4 service.
Some networks (part of the reason for support for this flag) don't have facilities to filter at L2, so on these networks you'll see all broadcast traffic.

So over to you, if it's not very difficult then you'll have no trouble will you ;-)

> So, put the onus on the equipment vendors, in case the netadmin wants to shut off IPv4, to determine how to proceed.

That's the surest way to guarantee failure. Without a standard to work to, you will get zero or more different ways - and if more than zero, then guaranteed interoperability issues. Most likely the vendors will turn round and say "so how do you want it doing ?" and we'd be back to discussing a network wide flag of some sort.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Oct 2018 17:55:53 +0200

Sounds like a good possible context to consider putting this work into.

Would be interesting to summarize how much guidance is given in that
work for how hosts should react to this information and primarily
whether the same documents that define the information also define
how hosts could or should react to it. The little i remember, that
reaction behavior is defined quite loosely so i am also curious
how much concern about interoperability in the face of host freedom
was brought up in that work.

Cheers
    Toerless

On Fri, Oct 26, 2018 at 03:26:31AM +0700, Ole Troan wrote:
> >> Please go write down the heuristics that you think hosts should use to say ???now is the time to turn off
> >> IPv4 on this interface??? and get it right?  I can???t think of any set of rules that will achieve that.
> > 
> >>> In this case, flag or no flag, any device with the updated IPv4 timeout timers, and especially those which try first to use IPv6, will be happy. Devices which will instead waste time insisting on IPv4, are not updated, and therefore, they won???t understand any flag.
> >>> 
> >>> I think I covered that above. It's a bit of a paradigm shift. Even without any new flag, the IETF can make device makers aware of this threat of no IPv4 service in some networks in the near future, and to take their own action. I don???t know how prevalent unmanaged switches are, in parts of the network that a network admin controls, but again, that is for network self-protection, mostly.
> > 
> > Sure.
> > 

-- 
---
[email-masked]

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 26 Oct 2018 18:31:21 +0000

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

> A default (or any) router is not needed for IPv4 to be running and needed - so not really a good hint.

Actually, I think that is one of the two best hints. The other one is DNS. Of course, any network which is "IPv6-only" can always have IPv4 islands in it, e.g. for that isolated lab. Bring your own switch(es). That's also true with any flag. You're right, an IPv4 router is not essential, but if not there, if no IPv4 addresses show up from the DNS, then you would naturally try IPv6. If you had not tried IPv6 before all of this.

> Like, from all the other nodes trying to see if IPv4 should be used ?

Yeah, I'm with you on this one.

> The problem you have is that you are only considering the sort of network you seem to be familiar with. There are lots and lots of network topologies - some of which are isolated networks with no r…

And these pose no problem at all. They would exist even if they were connected, and even if all of the IPv6 routers had that IPv6-only flag set. It will always be possible to create such IPv4 networks that have no DNS and no routing.

If I were to design a heuristic, at a time when IPv4 is actually being sunset, I would have the host always try IPv6 first. If it works, don’t even try IPv4. You try IPv4 only if IPv6 doesn’t work, or doesn’t work for a particular destination.

> There may (actually, almost certainly will) be devices on the network that won't be trying to turn off IPv4.

That's why it's best to use the network's equipment in the heuristic. Default routers and DNS being good bets, DHCP being a secondary choice, not so good. And, if you always try IPv6 first, and have success, you'll never even attempt to use IPv4.

> That's the surest way to guarantee failure. Without a standard to work to, you will get zero or more different ways - and if more than zero, then guaranteed interoperability issues.

And yet, this is the way it works for many potential network malfunctions. What Windows does is not the same as what Linux might do.

Bert

---

From: Simon Hobson <[email-masked]>
Date: Fri, 26 Oct 2018 20:01:49 +0100

> If I were to design a heuristic, at a time when IPv4 is actually being sunset, I would have the host always try IPv6 first. If it works, don’t even try IPv4. You try IPv4 only if IPv6 doesn’t work,…

Bzzzt, fail. You've just designed hosts which break their networking. So you try IPv4 if you can't reach a destination by IPv6 - but how do you even know about an IPv4 destination if you are relying on (for example) mDNS to find them ? If you configure IPv4 so as to be able to find them, then you've defeated one of the main points of doing this in the first place which is to avoid expending battery power on doing IPv4 when it's not required.

So, here's the challenge which you seem to be holding back from, write down the actual rules. No hand waving that "that's a good clue", but actual rules that "if you see <some observable state> then <do some specific action>".

Desired result - on a network that is, by the subjective criteria decided on by the network operator/admin, IPv6 only; you disable IPv4 and don't try sending IPv4 packets.
You must not break anything that does not meet this criteria - which is a subjective decision made by humans.

Put another way, you can connect to network A and be expected to disable IPv4; but connecting to network B which may look exceedingly similar, you do not disable IPv4. The decision whether you should or not is down to a subjective choice made by a human - now write your heuristics to do that.

So, challenge laid down, you're the one saying it's not difficult ;-)

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 26 Oct 2018 19:49:44 +0000

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

> Bzzzt, fail. You've just designed hosts which break their networking. So you try IPv4 if you can't reach a destination by IPv6 - but how do you even know about an IPv4 destination if you are relyin…

I will mostly assume that L2 filtering is NOT available, since that was stipulated as an extra obstacle. Your host device has a link to a destination. It tries to reach that link. Chances are, mDNS won’t have the address of any destination outside of this admin domain, but either way, a network which does not support IPv4 will not provide IPv4 addresses. No IPv4 address from mDNS or regular DNS, no further IPv4 attempt by the host device.

Besides which, if your host always tries IPv6 first, and it consistently works because your network TRULY IS IPv6-only, then you will rarely run into this problem. And if you do, the timeout timers can be adjusted so you don’t sit there waiting forever, before getting a destination unreachable notification.

> Desired result - on a network that is, by the subjective criteria decided on by the network operator/admin, IPv6 only; you disable IPv4 and don't try sending IPv4 packets.

Not even the flag will achieve this "desired result." As I said, IPv4 islands are always permissible (plug in your own switch(es)), and, you have no idea whether someone will plug in some older IPv4-only device. Only L2 filtering will truly disable IPv4 from the nodes controlled by the net admin. Having the hosts alone make that IPv6-only determination is, in fact, very close to the best you can do with a flag.

> Put another way, you can connect to network A and be expected to disable IPv4; but connecting to network B which may look exceedingly similar, you do not disable IPv4. The decision whether you shou…

It's just not that big of a deal. Plus, it is possible to give the user a setting, such as many settings already are:

1. Allow host to use IPv6 and IPv4 (recommended - default)

2. Use only IPv6.

The recommended default will naturally be used most of the time, and it will work just fine. Any extra chatter for IPv4 attempts will be kept to a minimum, and in an IPv6-only network, will only happen if IPv6 is screwing up. Plus, L2 filtering will keep network devices free of any IPv4.

Bert

---

From: Brian Haberman <[email-masked]>
Date: Fri, 26 Oct 2018 15:51:07 -0400

Hi Bert,

> Actually, I think that is one of the two best hints. The other one is DNS. Of course, any network which is "IPv6-only" can always have IPv4 islands in it, e.g. for that isolated lab. Bring your own…

WRT DNS... Are you referring to DNS answers that contain IPv4 addresses
(e.g., A records) or are you referring to DNS answers that arrive via
IPv4 transport? The latter appears to be a viable heuristic, the former
is not. The other aspect that we have to be careful of is the potential
deployment of DNS-over-HTTP(s), which adds a layer (or two) of indirection.

Regards,
Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 26 Oct 2018 20:00:57 +0000

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

Brian, I was actually thinking about A records. However, your better idea works too.

So okay, even in the case of egregious indirection, because DNS is lying about IPv4 destinations, the host won't be able to use any IPv4 default router. So, only un-updated IPv4 hosts will insist on waiting and retrying forever, and only on networks without L2 filtering would this even be a problem.

Bert

---

From: Simon Hobson <[email-masked]>
Date: Fri, 26 Oct 2018 23:11:40 +0100

> I will mostly assume that L2 filtering is NOT available, since that was stipulated as an extra obstacle. Your host device has a link to a destination. It tries to reach that link. Chances are, mDNS…

You've missed the fact that most nodes these days will autoconfigure a link-local IPv4 address. So "no address = no protocol" doesn't work. "no address (other than link-local) = no protocol" doesn't work either as it would break any network using link-local addressing - they do exist.

> Not even the flag will achieve this "desired result." As I said, IPv4 islands are always permissible (plug in your own switch(es)), and, you have no idea whether someone will plug in some older IPv…

It's accepted that if devices ignore the flag then they can still play around in IPv4 link-local space - but that's not the intent of the flag. The flag is to inform nodes that IPv4 isn't supported on the network and so they can disable the protocol, saving battery (and probably memory) as well).

> Plus, it is possible to give the user a setting, such as many settings already are:
> 

A setting for it is not practical for a number of reasons. Firstly, it will need to be changed when the user moves between different networks, secondly in most of the scenarios talked about, the user device is unknown to and the network operator and not managed by them. The aim is to be able to give the devices a flag which will **relliably** and **automatically** tell them that they can save the resources they'd otherwise expend on IPv4 operations.

I'm afraid I still see vague hand waving that implies trying stuff and if it doesn't work then adjusting stuff. That's either manual (yeah, forget that) or it's prone to problems. Apart from the acknowledged attack vector to IPv4 only networks, using an RA flag as suggested will be quite reliable and deterministic.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 26 Oct 2018 16:15:07 -0700

Simon,

> On Oct 26, 2018, at 3:11 PM, Simon Hobson <[email-masked]> wrote:
> 

That is the the intent of what the draft is designed to do.  I would add that it provides information from the administrator of the router.   From the draft:

   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.

> I'm afraid I still see vague hand waving that implies trying stuff and if it doesn't work then adjusting stuff. That's either manual (yeah, forget that) or it's prone to problems. Apart from the ac…

Agreed.

Bob

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sat, 27 Oct 2018 00:05:52 +0000

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

> You've missed the fact that most nodes these days will autoconfigure a link-local IPv4 address. So "no address = no protocol" doesn't work. "no address (other than link-local) = no protocol" doesn'…

No problem, right? With the IPv6-ony flag set, what would a host do? If it does autoconfigure an IPv4 address, maybe to talk to some old printer, it can do so also with the new heuristic. What the host will know is that it can’t route anything outside. There is nothing here that the flag changes. And besides, who knows what hosts will do when they receive that IPv6-onky flag. We are simply speculating. Whether the better heuristics, or this new flag, makes little difference.

> It's accepted that if devices ignore the flag then they can still play around in IPv4 link-local space - but that's not the intent of the flag. The flag is to inform nodes that IPv4 isn't supported…

And our new heuristics can do exactly the same thing, without a flag. To conserve power, try first IPv6, and use only IPv6 if it works. If not, give IPv4 a short try. See if a default router exists and if DNS works in IPv4 format. If not, stop wasting power on IPv4. All of this caveated the same way. A host might still want to go to that old printer which only uses IPv4, but the host will know that nothing routed outside will work with IPv4.

> A [user-entered] setting for it is not practical for a number of reasons. Firstly, it will need to be changed when the user moves between different networks, secondly in most of the scenarios talked about, the user device is unknown to and the network operator and not managed by them. The aim is to be able to give the devices a flag which will **relliably** and **automatically** tell them that they can save the resources they'd otherwise expend on IPv4 operations.

Reliably and automatically is to allow the device to use IPv6 and IPv4, i.e. the default. It will do just what the flag intends.

I just don’t see why the insistence on this flag, if I can do just as well without, and furthermore, without having to trust a net admin to set this flag. The simple fact is, no one is begging for this flag, it seems. I've been following the entire debate. An equipment vendor serious about saving power has other options he can pursue on his own. A network operator serious about preventing IPv4 chatter is perfectly capable of L2 filtering, wherever that's available, and otherwise providing no IPv4 services.

Either way, the only hosts which will NOT holler, when you shit off IPv4, are the updated ones. Updated to read this flag, or updated with the better heuristics, makes no big difference.

Bert

---

From: Simon Hobson <[email-masked]>
Date: Sat, 27 Oct 2018 12:44:20 +0100

Manfredi (US), Albert E <[email-masked]> wrote:

> No problem, right? With the IPv6-ony flag set, what would a host do? If it does autoconfigure an IPv4 address, maybe to talk to some old printer

OK, explain how the device is to know whether or not it should be turning on IPv4 to see if there's an IPv4 printer it needs to talk to ?
If it does turn on IPv4, then you've missed the opportunity to save battery power generating IPv4 packets.
If it doesn't turn on IPv4 then it won't know if the printer is there to be found.

And since the printer may not be switched on when it first does the checks, then it would need to keep IPv4 on "just in case".

> There is nothing here that the flag changes.

Yes there is.
If the host sees that all RAs carry this flag set, then they can know that the admin is declaring that there aren't any IPv4 only devices that the device need be bothered with. It can leave IPv4 turned off, and not worry about not finding something it might need to.

IFF there is an old IPv4 only printer that the user needs to access, then the admin would not set this flag. The point you continue to miss is that the humans responsible will know what is and isn't there, and what can and can't be ignored. So if (for example) all printers (and other devices) are now IPv6 enabled OR ARE BEING DEPRECATED, then it's OK to set this flag.
There is NO WAY WHATSOEVER for ${random_device} to know this. It cannot differentiate between IPv4 traffic that's there because there are IPv4 only devices it may need to communicate with, and IPv4 traffic that's there because some devices haven't turned it off and you have no need to talk to them via IPv4.

I could even imagine networks where DHCPv4 is still provided, there is still IPv4 being actively used by legacy devices, but this flag is set because any device "new enough" to understand this flag and act on it doesn't need to still use IPv4.

If you think a device can figure out all this by itself, then again I suggest you write down explicit rules.

> And besides, who knows what hosts will do when they receive that IPv6-onky flag. We are simply speculating. Whether the better heuristics, or this new flag, makes little difference.

Well the advice in the RFC is to stop using IPv4. If they don't then it won't break anything else on the network, it'll just prevent them taking advantage of the battery/CPU/memory usage savings available.

> And our new heuristics can do exactly the same thing, without a flag. To conserve power, try first IPv6, and use only IPv6 if it works. If not, give IPv4 a short try.

So IPv6 works - as it should on any IPv6 only **OR** dual-protocol network. So why do you think that gives you any clue about whether IPv4 is still in use ?

> A host might still want to go to that old printer which only uses IPv4

In which case, the admin won't set the flag - if they do then that's a misconfiguration just the same as setting wrong information in DHCP would be. Really this is just basic network admin stuff - like "don't turn off your IPv4 routing if there are still IPv4 only devices needing it" !

> I just don’t see why the insistence on this flag, if I can do just as well without, and furthermore, without having to trust a net admin to set this flag.

You still don't get it do you. Continuing to use IPv4 when it's no longer supported on the network has a cost - it takes power, CPU cycles, memory, and network bandwidth. For battery powered devices, any saving is desirable; for wireless networks, bandwidth saving is desirable. So by having devices use this information, they can have better battery life, and all users of the wireless network can have better performance.

> The simple fact is, no one is begging for this flag

Well they have been begging for this flag - enough to keep this discussion going through quite a few revisions of the text etc.

> An equipment vendor serious about saving power has other options he can pursue on his own.

No they aren't - you have yet to come up with plausible rules for a host to do this on it's own. And remember, these rules need to work both for the IPv6 only networks **AND** not break any other networks the device may connect to.

> A network operator serious about preventing IPv4 chatter is perfectly capable of L2 filtering, wherever that's available,

L2 filtering does not completely remove the chatter - devices will still be sending ARP packets, they can still generate link-local addresses, they can still send (eg) mDNS packets. OK, filtering them will reduce (possibly eliminate depending on where it's done) the re-broadcast of them on the wireless network - but it won't prevent them being generated and taking up some bandwidth.

> Either way, the only hosts which will NOT holler, when you shit off IPv4, are the updated ones. Updated to read this flag, or updated with the better heuristics, makes no big difference.

Again, you've missed the point - it's not about hosts hollerin, it's about allowing hosts to operate more efficiently. It's already been talked about - "what about the legacy devices ?". Well these will be no worse off when you remove IPv4 services from the network, but they could actually be better off with the chatter removed from the devices that honour this flag.

---

From: Brian Haberman <[email-masked]>
Date: Sat, 27 Oct 2018 10:44:35 -0400

Hi Bert,

> No problem, right? With the IPv6-ony flag set, what would a host do? If it does autoconfigure an IPv4 address, maybe to talk to some old printer, it can do so also with the new heuristic. What the…

I think your observation is key for everyone. The flag only indicates
that the router(s) will not route IPv4 off the link. There is nothing
stopping devices from using IPv4 locally on the link to communicate with
other such devices.

The same thing occurs today with devices using IPv6 link-locals on
IPv4-only links.

Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 27 Oct 2018 17:02:11 +0200 (CEST)

On Sat, 27 Oct 2018, Manfredi (US), Albert E wrote:

> Either way, the only hosts which will NOT holler, when you shit off 
> IPv4, are the updated ones. Updated to read this flag, or updated with 
> the better heuristics, makes no big difference.

For me, this flag has always been an additional input to the heuristics 
engine.

We discussed this in sunset4 about exponential backoffs etc. This flag can 
just be additional inputs.

But yes, I also see the possibility of the host trying to configure itself 
IPv4 but if it sees no answers to questions and doesn't see any IPv4 
traffic at all, after a while it "gives up" and just goes "IPv4 dormant" 
and sits there and monitors to see if it sees any IPv4 traffic. It might 
restart IPv4 operations when it sees other IPv4 traffic (0x0800 or 
0x0806).

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 28 Oct 2018 00:41:40 +0000

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

IPv4-only links.

Agreed.

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

> OK, explain how the device is to know whether or not it should be turning on IPv4 to see if there's an IPv4 printer it needs to talk to ?

That should occur when you set up the printer, when you load the printer driver. In my own experience, I have had to enter the actual IP address, EVEN OF enterprise printers, when the DNS for some reason or other didn't contain its name. So that's one way the host can determine to use IPv4, for that printer.

And too, even in an enterprise net, one can potentially have a printer or other specialty device, like a CD-ROM label maker, in an office, or in a suite, where that specialty device is not under the control of the IT people, and access to it has to be IPv4. A flag, or heuristics, c'est la même chose.

> IFF there is an old IPv4 only printer that the user needs to access, then the admin would not set this flag.

What Brian said. Sorry, that's wrong. If any host uses the flag that way, that host is broken. Which is part of the risk of the IETF creating such a flag, without very explicit instructions on its use by hosts. Instructions which the equipment designer might simply want to ignore, along with the flag itself.
 
Mikael says it would be used as an extra input to the heuristics, which is IMO the actual way it would ever get used.

> Again, you've missed the point - it's not about hosts hollerin, it's about allowing hosts to operate more efficiently.

I missed no such point. There are two interests here: a network admin wanting to shut off IPv4, for whatever reason, and a host wanting to conserve energy. I'm simply saying, if the network wants to shut off IPv4, chances are, flag or no flag, someone's going to holler. Flag makes zero difference. Anyone with an older device will be unhappy.

Bert

---

From: Simon Hobson <[email-masked]>
Date: Sun, 28 Oct 2018 08:57:45 +0000

> That should occur when you set up the printer, when you load the printer driver. In my own experience, I have had to enter the actual IP address, EVEN OF enterprise printers, when the DNS for some…

You are still looking at this in a "this is my known network" manner.

You go onto a network you've not been on before, how does your device know whether it should be using IPv4 to look for a printer via mDNS ? If you turn on IPv4 to look for what could be a non-existent printer then you've missed the opportunity to save power, if you don't then you may not know about a printer that should be available to you.
There is no set of heuristics that will solve that for you. If you think there is, then write it down !

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 28 Oct 2018 19:31:14 +0000

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

> You go onto a network you've not been on before, how does your device know whether it should be using IPv4 to look for a printer via mDNS ?

Does the device see IPv4 mDNS, listing A records? That's a hint, in a network you've never been on previously. If no IPv4 DNS, no IPv4 default router configured (or reachable, if an old static default router still set in your device), no DHCPv4, stop attempting IPv4, assuming you have ever attempted IPv4.

What you seem to be missing, all this IPv6 flag means is "no IPv4 packets transit THIS router." That's the extent of it. You seem to be attributing a lot more to the flag than it actually intends.

Here's another example. In a network where all routers have the flag set, can you bring your own IPv4 router, and then use a ROUTE command in your host, to send IPv4 packets to a particular device across that router? Could be a tinynet of peripheral devices, for example. Yes, you can. This would be a case of BYOR, as opposed to BYOS, which should also be perfectly okay.

> If you turn on IPv4 to look for what could be a non-existent printer then you've missed the opportunity to save power, if you don't then you may not know about a printer that should be available to 

You have just violated one of the new heuristics I mentioned. Look at it this way: no matter what, these new hosts will need updated heuristics. Flag or no flag, makes no difference. With the heuristics I have already described, if you are not bringing along IPv4 peripherals with you, and IPv6 seems to be available (DNS, RAs, etc.), then your device will have *no reason* to attempt IPv4. Same goal is achieved. The flag may perhaps help, as an extra input to the new heuristics, but you are giving it much too much importance!

Bert

---

From: Simon Hobson <[email-masked]>
Date: Sun, 28 Oct 2018 21:06:42 +0000

Manfredi (US), Albert E <[email-masked]> wrote:

> With the heuristics I have already described, if you are not bringing along IPv4 peripherals with you, and IPv6 seems to be available (DNS, RAs, etc.), then your device will have *no reason* to attempt IPv4. Same goal is achieved.

Err no, you've explicitly broken some networks - specifically just about every dual stack network !
The MOST IMPORTANT think is for whatever is done to NOT BREAK EXISTING NETWORKS. This flag does that - it only has an effect when manually set by the administrator who we have to assume has got some sort of clue. Thus the default is to not break anything - ie the flag not set.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 28 Oct 2018 21:47:37 +0000

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

> Err no, you've explicitly broken some networks - specifically just about every dual stack network !

Not hardly.

Again, an equipment designer, intent on saving battery power, would not need to use IPv4 ever, if IPv6 provides all the needed services. In a dual-stack network, SAME THING. That's why an equipment vendor who wants to do what's best will still need updated heuristics, with or without a flag. The interests of the network are not necessarily aligned with the interests of the host.

> The MOST IMPORTANT think is for whatever is done to NOT BREAK EXISTING NETWORKS. This flag does that - it only has an effect when manually set by the administrator who we have to assume has got som…

Not even close. The heuristics I described break nothing. A dual-stack host on a dual-stack network, where the host can do everything the user asks with IPv6 only, breaks absolutely nothing, and saves power. Plus, I repeat, the host will see IPv4 services are available, from the DNS and the presence of an IPv4 default router. So that, should there be something IPv6 is unable to do, or reach, the host can try IPv4.

The flag adds very little indeed.

Bert

---

From: Mark Smith <[email-masked]>
Date: Mon, 29 Oct 2018 11:23:29 +1100

> For me, this flag has always been an additional input to the heuristics

I don't think heuristics are really necessary.

A host doesn't really need an IP address (IPv4 or IPv6) unless and
until it starts running an application that wants to use the network.

I think the current convention for hosts to acquire addresses upon
boot or more recently upon attachment to a (new) link is probably more
of a tradition from back when minicomputers were the norm and network
interface configuration was always static. Hosts now widely support
dynamic address acquisition or generation, and release.

Hosts acquiring or generating addresses at boot or upon link
attachment could be seen as an optimisation, with the optimisation
being to avoid address acquisition latency at the time of the first
application network API call.

With IPv4 being the legacy protocol in this scenario, IPv4 addresses
could be acquired and released on demand by hosts when IPv4
applications need them.

I think on-demand IPv4 would be a compliment to an IPv6 Only flag
signalled by an IPv6 only router. There are still optional things that
Dual Stack hosts do that aren't really networked application driven,
such as responding to ICMP Echo Requests or registering host presence
via a HINFO record using Multicast DNS.

An IPv6 Only flag would be an explicit signal to a Dual Stack host
that these optional IPv4 things should be switched off. If they're the
only thing remaining that uses IPv4, then the host would cease to use
DHCPv4 to acquire an IPv4 address.

When a host stops running any applications the use IPv4, and these
other optional IPv4 hosts do are switched off, then the host would
cease sending or receiving an IPv4 or IPv4 related ARP packets
entirely.

Regards,
Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Oct 2018 14:08:29 +1300

On 2018-10-29 08:31, Manfredi (US), Albert E wrote:
...
> What you seem to be missing, all this IPv6 flag means is "no IPv4 packets transit THIS router."

No, it still doesn't mean that. It means, if and only if all IPv6 default routers
send it, that the network manager has *decided* that there should be no IPv4
traffic on the link.

> That's the extent of it. You seem to be attributing a lot more to the flag than it actually intends.

Frankly Bert, you seem to be ignoring the words in the draft.

On 2018-10-29 10:47, Manfredi (US), Albert E wrote:
...
> The flag adds very little indeed.

It adds the *intention* of the network manager that there should be no
IPv4 traffic on the link. Of course, a host can decide to ignore that
intention, and protocol police in the form of layer 2 filters may enforce
the intention.

Personally, if I was in a position to write the heuristic that a host
uses, I would use this flag as a heavily weighted input that would
either prevent any IPv4 activity whatever, or increase the backoff
timers to a very large value, since it's a clear signal that, for example,
mDNS over IPv4 is simply not available.

   Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 29 Oct 2018 01:16:09 +0000

-----Original Message-----
From: Mark Smith <[email-masked]> 

Or more precisely, when IPv4-only applications need them. If an app needs access to a printer, scanner, the OS should be able to oblige, with IPv6 or IPv4. If an IPv6-only flag is set at every router, the presumption usually would be, IPv6 printers, and other such basic services, have been provided on the network, by the net admin. Normally. The question is, without that flag, are there other clues? (Yes, there are.)

Except, they aren’t necessarily the only thing that uses IPv4. They are the only thing the network admin might have had control over, that used IPv4. But a robust host should not be programmed to preclude functionality that users have come to expect. Go to Best Buy, buy whatever printer, and make it work, on that network. Seamlessly, 

Yes. And so in your post, you have listed several heuristics. I agree with these improved heuristics. I'd be hard pressed to make the case that a flag is the only way, or even the most robust way, to achieve any of this.

But, why is this not a relief, for 6man? You can achieve increased efficiencies in hosts, you can shut off IPv4 services in the network, and you don’t even need to add complexity to an already complex-enough IPv6.

Bert

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 29 Oct 2018 01:37:30 +0000

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

But Brian, the network manager (usually, often) has no business making such decisions, other than for the services net admin provides. *Especially* if the protocol police filters at layer 2, the network user should be legally and ethically able to bring his own IPv4 peripherals, and switch and/or IPv4 router, and have them work. With no negative impact to anyone else.

We already know that the flag is set individually, at each router. You may have three routers that have the flag set, and one that does not. So this says quite clearly, do not bother trying to route IPv4 packets through the routers with flag set. It does not say that the net manager doesn’t want IPv4 traffic in the link. Push comes to shove, the flag means only, this router won’t transfer IPv4 packets.

If there's any intention for this flag to be misconstrued by some equipment vendors, creating a clever puzzle to be solved by perfectly legitimate users, every time they need to add equipment, then I'd say, let's avoid that. No?

Maybe so. Or maybe, after spending time writing the new logic, the equipment designer writing the heuristics will determine they can mostly ignore the flag? That's always been my question, in this thread.

Bert

---

From: Mark Smith <[email-masked]>
Date: Mon, 29 Oct 2018 12:48:43 +1100

> We already know that the flag is set individually, at each router. You may have three routers that have the flag set, and one that does not. So this says quite clearly, do not bother trying to rout…

You're misunderstanding the mechanism. This flag is not a router
capability flag.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 29 Oct 2018 02:08:22 +0000

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

capability flag.

Not meant to be, anyway:

   Hosts receiving the Router Advertisement SHOULD only process this
   flag if the advertising router is a Default Router.  Specifically, if
   the Lifetime field in the Router Advertisement is not zero, otherwise
   it SHOUD be ignored.  This is done to allow some IPv6 routers to
   advertise information without being a Default Router and providing
   IPv6 connectivity.

...

   If there are multiple IPv6 default routers on a link, they might send
   different values of the flag.  If at least one IPv6 default router
   sends the flag with value 0, a dual stack host SHOULD NOT assume that
   the link is IPv6-Only.  If all IPv6 default routers send the flag
   with value 1, a dual stack host SHOULD assume that this is an
   IPv6-Only link.

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

This seems to say that only when all "default routers" have the flag set, would the link truly be IPv6 only. (And even then, bring your own peripherals should not be precluded?) So in effect, all said and done, does this not say only that *this* router won't route IPv4?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Oct 2018 16:29:26 +1300

On 2018-10-29 15:08, Manfredi (US), Albert E wrote:
> ....
> This seems to say that only when all "default routers" have the flag set, would the link truly be IPv6 only. 

Or rather, only then is the network administrator declaring the link to be IPv6-only.

(And even then, bring your own peripherals should not be precluded?)

That's a policy question. For example, I'm not supposed to plug in
unauthorized devices on the network in my office.

> So in effect, all said and done, does this not say only that *this* router won't route IPv4?

No.

   Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 29 Oct 2018 03:41:35 +0000

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

>> So in effect, all said and done, does this not say only that *this* router won't route IPv4?

Okay, all I can say then, this flag can be easily misconstrued. Perhaps this thread proves just how differently it might be interpreted, by equipment vendors. Going through the logic in the draft, the only "intersection of sets" seems to be, IPv4 not accepted at this router. Not more than that.

(I'll bet that the "policy question" has much more to do with security, than it does with devices breaking the network with a protocol!)

Bert

---

From: Simon Hobson <[email-masked]>
Date: Mon, 29 Oct 2018 18:47:14 +0000

> Not even close. The heuristics I described break nothing. A dual-stack host on a dual-stack network, where the host can do everything the user asks with IPv6 only, breaks absolutely nothing, and sa…

Lets get this clear, your algorithm is "if IPv6 appears to work then don't enable IPv4" ?
That's a situation a lot of us would love to get to - but it'll be a lot of years before that's even remotely practical. As I said, on the vast majority of current networks, doing what you propose will BREAK networking for the user - because very few networks so far have reached the "don't need any IPv4" stage yet.

> But Brian, the network manager (usually, often) has no business making such decisions, other than for the services net admin provides.

No, the network admin almost always has the business of applying business policies. That may not happen in isolation (eg servers may be managed by a different group), but it is a minority of networks where the network admin does NOT apply policies well beyond what you seem to think.
If the business (collectively - including all the interested parties) decides that sunsetting IPv4 in the network is policy, then it comes down to the network manager to implement that (including by setting this flag in all IPv6 routers if it makes it into use).

> *Especially* if the protocol police filters at layer 2, the network user should be legally and ethically able to bring his own IPv4 peripherals, and switch and/or IPv4 router, and have them work. With no negative impact to anyone else.

On most networks, doing so will get you a "stern talking to", and I've been involved with networks where plugging in your own router would result in you being escorted out of the door. Funnily enough, a few "diagnose WTF is going on" jobs over the last few years have been due to such additions by clueless users.
But even taking your suggestion at face value - yes, if you want to ignore company policy and setup your own island of IPv4 then that's your prerogative. It certainly does not change any of the arguments already made.

> We already know that the flag is set individually, at each router. You may have three routers that have the flag set, and one that does not.

Strictly speaking that a bit of a misconfiguration. The reason for that language is to avoid any ambiguity - and make the result "safe". It also means that a rogue router can't set this flag on a network where it's not appropriate and break IPv4.
If everything is correctly configured, then all routers will send the same flag setting. Your inference is incorrect.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 30 Oct 2018 14:47:00 +0100

> So, here's the challenge which you seem to be holding back from,
> write down the actual rules. No hand waving that "that's a good
> clue", but actual rules that "if you see <some observable state>
> then <do some specific action>".

My take on it:

1) If a host has a global IPv6 address and is unable to reach a DHCPv4
   server, then after a short while agressively reduce the rate of DHCP
   multicast messages
2) If a host has a global IPv6 address and it configures an IPv4 link local
   address then the host should consider only 169.254.0.0/16 to be 
   onlink.

Note: this second requirement makes sure that any global IPv4 address that
the host knows or learns will not result in any traffic, because the host
does not have a default router.

3) If a host has a global IPv6 address and a link local IPv4 address then
   the host should agressively reduce the rate of any service discovery
   multicasts on IPv4.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Oct 2018 16:18:48 +0100

>    server, then after a short while agressively reduce the rate of DHCP

IMHO:

If the host sees the ipv6only flag from all IPv6 routers, it MUST NOT
perform IPv4 DHCP.

Why:

The flag is a clear indication that these IPv6 routers indicate that
there must not be any global IPv4 on this subnet. Even if the DHCP
operations would result in finding a router tht disagrees, then this
is clearly a misconfiguration of the subnet and the host has to make
a choice whose guidance to follow, and this document mandates
that it must be the IPv6 routers flags.

>    address then the host should consider only 169.254.0.0/16 to be 

The "then" portion of this sentence is just restating rfc3927.

The question is whether the ipv6only flag is meant to indicate that
there should be no global IPv4 operations on the subnet or no global
nor link-local ipv6. The current draft seems to intend the latter
to be able to fully shut down the stack. It could be useful to have
another flag indicating whether ipv4 link-local is still
to be used on the subnet.

> does not have a default router.

nothing new vs. rfc3927.

>    the host should agressively reduce the rate of any service discovery

I am not aware of any IP protocol version specific optimization options
for mDNS. If there are common ways to make mDNS less chatty without
slowing down discovery, they should be defined independently of the
v6only flag discussion. 

Confounding the situation like you propoose is like "make ipv4 service
discovery less chatty to a point that it may break because it doesn't
matter if ipv6 is running" - and thats not a correct approach given how
the service in question may be ipv4 only.

There may be optimization options to prefer IPv6 over IPv4 discovery
for dual-stack cases, maybe there is something already defined, but 
that could only be IMHO through timing - e.g.: look for service
first via IPv6 and only try IPv4 adfter some short timeout. But that
too would better be defined independently of the ipv6only flag
discussion because its IMHO useful independent of the flag.

Cheers
    Toerless

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 30 Oct 2018 17:56:08 +0000

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

DNS in IPv4 format might be a good hint too.

>From my standpoint, I have yet to see anything that the flag adds, that can't be done just as well, and less ambiguously, with heuristics. I'd like to see one scenario that the flag resolves, that can't be done otherwise. But this should be a good thing. It puts the onus on the people who are responsible. The responsibility of saving power should be on the guy designing that box, not on a net admin, who has his own interests.

Bert

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Oct 2018 19:34:16 +0100

> DNS in IPv4 format might be a good hint too.

Example ?
> From my standpoint, I have yet to see anything that the flag adds, that can't be done just as well, and less ambiguously, with heuristics. I'd like to see one scenario that the flag resolves, that…

Depends a bit on how the flag is refined:

If as i suggested the flag really means to trust IPv6 routers more than
IPv4 routers (aka: don't do IPv4 even if some IPv4 router tells provides
DHCP addresses), then it would be an explicit mechanism for IPv6 to
superceed IPv4. I would support that interpretation on the rough
estimate on my side that it simplifies policies and evolution. Without
that interpretation, you have more complex policies whom to trust
in an automatic way.

The second interpretation is vs. this means to just not even try to
do DHCP to get global IPv4 addressing/router, or whether it means
to not do IPv4 at all, including no link-local multicast. IMHO both
options are valid and would best be indicated through two separate
flags.

I think with just a single flag, the best value and distinction would be
had if the interpretation is a) Trust these IPv6 announcement more than
any IPv4 you see, and b) do not do any IPv4 at all, including no
ipv4 link-local

I don't think there is any way to achieve complete disablement of
ipv4 operations automatically without using some additional signaling
across non-IPv4. I think it would be cleaner to do this signaling at L2,
but given the overhead/politics of anything like that with IEEE, i think
its fine to have this signaling in IPv6. I don't think there is any
simpler/better way than at least one such flag.

As also mentioned, i would prefer to also have mechanisms described by
which routers would automatically determine whether to set this flag.

Cheers
    Toerless

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 30 Oct 2018 19:34:45 +0000

-----Original Message-----
From: Toerless Eckert <[email-masked]> 

superceed IPv4.

Except that contradicts the current draft wording. Which says, only if all default routers have the flag set, does it mean that the net admin doesn't appreciate IPv4 on the link. (And I still think that local IPv4 traffic is, and must, be completely legit, so that too needs to be stated explicitly.) IPv6 has added complexities of allowing multiple default routers to advertise, pick the best prefix for your needs. Which says to me, it is reasonable to think that IPv4 *is* allowed, across one or more of these default router choices, but not on those with the flag set.

> I would support that interpretation on the rough

Agreed. It is "more complex," because any one flag set does not mean that IPv4 can't be used. For instance, as a simplest case, it is fair enough for my ISP to say, "I am not routing IPv4 over my network." It is not okay for my ISP to say, "You are not allowed to use your old HP printer."

So, IMO, the flag is not necessary. The ISP can simply not provide a default IPv4 router, not provide IPv4 DNS to resolve outside names, and that gives a less ambiguous message. A host should be able to do the right thing, under those circumstances, sans flag.

Yes, and we can increase complexity that way. Or, hosts decide whether to start with IPv6, rather than creating more complexity in IPv6. And again, it's not the business of the net admin, if I want to have internal IPv4 available to me. Imagine the annoyance that would create, for the average user, who knows nothing about any flag. So, suddenly, after a router update the user is totally clueless about, his peripherals, or other equipment, don't work. Aaaargh!

Agreed on L2, but "complete disablement of IPv4" should be out of the question. That breaks things that do not need to be broken. If net admin doesn't route IPv4, fine and good. IMO, stop there.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2018 08:43:40 +1300

>> then <do some specific action>".

If by "rules" you mean "a typical heuristic", sure. But there will
be hosts that follow a different logic for their own good reasons.
That simply isn't the IETF's business.

The draft is quite clear on this:

   Dual stack hosts that have a good reason to use IPv4, for example for
   a specific IPv4 link-local service, can attempt to do so.  Therefore
   respect of the IPv6-Only flag is recommended, not mandatory, for
   hosts.

On 2018-10-31 04:18, Toerless Eckert wrote:
...
> If the host sees the ipv6only flag from all IPv6 routers, it MUST NOT

Who cares? Legacy hosts will try DHCP anyway. We don't want an updated
host to waste spectrum on this, but that's a SHOULD NOT, because such
traffic won't actually break anything.

    Brian

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 30 Oct 2018 20:12:38 +0000

>    that the link is IPv6-Only.  This document updates RFC5175.

You have running code:

https://lists.freebsd.org/pipermail/svn-src-head/2018-October/119360.html

I wish the discussions would be as short as the code changes that are 
needed to implement a minimalistic set of this.

Love and peace and no more IPv4 noise.

/bz

---

From: Job Snijders <[email-masked]>
Date: Tue, 30 Oct 2018 21:27:44 +0100

Dear Bjoern,

It is great to see people produce running code for experimentation -
congratulations!

Can you (or others running FreeBSD EXPERIMENTAL) share reports on how
this pans out in practise? What gaps between reality and documentation
are uncovered, or whether the patch was complete/not-complete?

What OS vendor will go next?

Kind regards,

Job

---

From: Simon Hobson <[email-masked]>
Date: Tue, 30 Oct 2018 20:50:02 +0000

Manfredi (US), Albert E <[email-masked]> wrote:

> For instance, as a simplest case, it is fair enough for my ISP to say, "I am not routing IPv4 over my network." It is not okay for my ISP to say, "You are not allowed to use your old HP printer."

There is absolutely no element of that stated or implied in the draft. What your ISP tells you on your uplink to them is **NOT** the same as what you configure your router to tell your own devices on your side of the router. For example, your ISP might provide an IPv6 only link - but that wouldn't prevent you getting IPv4 via a tunnelled service (like some of us do with IPv6 at the moment).
So it would be up to you to set or not the flag on RAs sent by your router on your local network.

But, if by ISP you mean (for example) when you connect to the WiFi provided at a large sports event or conference. In that sort of case, bringing your old HP printer along is not going to be part of the equation.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Oct 2018 22:00:20 +0100

On Tue, Oct 30, 2018 at 07:34:45PM +0000, Manfredi (US), Albert E wrote:
> Except that contradicts the current draft wording. Which says, only if all default routers have the flag set, does it mean that the net admin doesn't appreciate IPv4 on the link.

What i wrote is meant to be in support of what you cited from the draft.
Maybe i wasn't writing that clearly enough, but not sure where you see
the difference.

> (And I still think that local IPv4 traffic is, and must, be completely legit, so that too needs to be stated explicitly.)

As i stated in before, i am too in favor of having an explicit notion of
"IPv4-link-local-only(no-global) as a separate flag, but i think that
this may need more regurgitation to fully conclude that that
functionality can not equally well be achieved with heuristics.

It is a lot more easy to conclude that you need some non-IP signaling
to indicate that the IPv4 stack should be disabled completely (IMHO
simple logic tells us that). 

> IPv6 has added complexities of allowing multiple default routers to advertise, pick the best prefix for your needs. Which says to me, it is reasonable to think that IPv4 *is* allowed, across one or more of these default router choices, but not on those with the flag set.

True. Which is why the draft is correct in stating that only if all
IPv6 routers announce the flag wold it be considered to be active.
> Agreed. It is "more complex," because any one flag set does not mean that IPv4 can't be used. For instance, as a simplest case, it is fair enough for my ISP to say, "I am not routing IPv4 over my n…

Definitely. As i wrote in my prior email, the most lightweight
interpretation is that we want a signal to tell hosts not to bother
switching on IPv4 and ideally routers figure this out automatically.

Why would the network operator make that decision explicitly ?

In one case because we can't figure out good enough heuristics so that
the routers can announce the flag automatically. Thats a fair reason,
but i would have to be persuaded that this is really necessary.

In another case, the operator wants to announce the flag even though
there could be IPv4 devices on the network to talk to and he wants
to prohibit that. Thats a lot less interesting to me because it
brings up all type of followup questions. At best this is a
desriable mutually agreed upon router announced policy that consenting
upgraded routers could or should comply to. is that really worth it ?
And it can't be enforced without additional enforcement. 

> So, IMO, the flag is not necessary. The ISP can simply not provide a default IPv4 router, not provide IPv4 DNS to resolve outside names, and that gives a less ambiguous message. A host should be ab…

The host would still continue to try to do IPv4 forever in DNS
and simultaneously enable link-local scope IPv4 addressing, and
both these activities are just useless trash activites making
diagnostics more difficult and likley also being issues for
wireless. So i think it would be great if the IPv6 router would
be able to help out dual-stack hosts, telling them when they can
skip these attempts into IPv4.

> Yes, and we can increase complexity that way. Or, hosts decide whether to start with IPv6, rather than creating more complexity in IPv6.

But lets get back to the most core point: Heuristics on every
host would eiher need to be explicitly standardized or we'll
end up with very difficult to troubleshoot environments where
every host stsack does the same thing. AND i can never completely
disable the IPv4 stack if i want my host to do heuristics.

So its a lot easier model if the router(s) figure out if IPv4 is
needed and signal that to the hosts. And given how the hosts
we care about have IPv6 but may not have any other L2 protocols,
it is logical to put it into IPv6. No strong feeling in this respect
into which field of which protocol to put it. I assume the authors
choose a pretty good location (except eating up on of the last bits
in the encoding).

> And again, it's not the business of the net admin, if I want to have internal IPv4 available to me. Imagine the annoyance that would create, for the average user, who knows nothing about any flag. So, suddenly, after a router update the user is totally clueless about, his peripherals, or other equipment, don't work. Aaaargh!

Right. automatic setting of the flag(s) by routers. Routers can IMHO
easily figure out if there are IPv4 link-local only nodes on the LAN.

As said in before, even without automatically setting flags, i think
the diagnostic itself we could get from routers tracking what type of
hosts are present: IPv4-link-local, IPv4-global, IPv6/IPv6, IPv6
would IMHO be very helpfull.

> Agreed on L2, but "complete disablement of IPv4" should be out of the question. That breaks things that do not need to be broken. If net admin doesn't route IPv4, fine and good. IMO, stop there.

If you don't have IPv4 only hosts on the subnet and no routers routing
IPv4, then IMHO IPv4 is unnecessary and should be completely disabled.

What would be the argument agains this conclusion ?

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Oct 2018 22:03:31 +0100

Brian,

I think i would be happier with a stronger goal of the flag
relying less or not at all on heuristics of hosts.

Give me a reason why dual-stack hosts should want to do IPv4
on a subnet if there is no IPv4-only host and no router routing IPv4. 

This seems like the most simple case to discuss about and agree
what to do for it. TO me it seems that it would be great to
recognize this case and automatically disable IPv4 stack/interface
because of a flag from routers on all dual-stack hosts.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 30 Oct 2018 21:09:34 +0000

On 30 Oct 2018, at 20:27, Job Snijders wrote:

Hi,

> this pans out in practise?

Well, it would be great if I could turn the flag on on various other 
default routers on the networks I am normally on.  Hope $C and $J and $A 
at least will have this one shipping quickly once it’s an RFC.

> What gaps between reality and documentation
> are uncovered,

I’ve shared little notes with Bob and Brian and I am sure they’ll 
update things;  I’ll send some of that out there the next days (if 
they don’t beat me).  I also patched tcpdump to see the flag and I can 
share some ifconfig/ndp output if it’s desirable.

> or whether the patch was complete/not-complete?

Software is never complete ;-)   As I said “implement a minimalistic 
set of this”.  That’s what it is.
If I would add to this (and I am sure I will) it’ll be the following 
(in order):
(a) RX filter based on interface flag so packets don’t make it up the 
stack at least anymore
(b) a global (system-wide, not per-link) flag to allow an administrator 
to overrule the decision (for whatever reason)
(c) allowing the system admin to set the interface specific IPV6_ONLY 
flag in a sticky way manually without the RAs (hey I am fine with 
v6only, don’t try v4 even if you could);   also great for apps people 
to test if they can’t get a full test network to play with.
(d) deal with dhclient and do make ipv6 start before ipv4 as indicated 
in the draft.

I could go and teach gazillions of user space applications about it 
(dhclient probably one of the most nagging ones) to save local battery 
cycles as well, but then I could just compile a FreeBSD client without 
INET support (which we did in 2011) and be done with it.   I think what 
I am trying to say:  why waste time on software which is almost 
obsolete?

I’ve done an experiment years ago, running an “IPv6-only” kernel 
with EAFNOSUPPORT coming back earlier in the stack rather than later.  
Also we have a library function in FreeBSD which indicates if the 
feature “inet” or “inet6” (and others) are present or compiled 
out.  So it’s been there for apps people to test with for 7+ years..  
=this is just yet another flag to care about.

> What OS vendor will go next?

All hopefully :-)

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Oct 2018 08:42:28 +1100

> What OS vendor will go next?

IANA better allocate the bit first.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 30 Oct 2018 21:45:55 +0000

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

> What would be the argument agains this conclusion ?

No argument, Toerless. And, just as you have to have an updated host to read the IPv6-only flag, to make the decision to shut off IPv4 entirely, that same updated host could simply be running the better heuristic. Which says, I have no peripherals configured which require IPv4, I have no old IPv4 PCs with which I'm sharing drives, I have access to one or more IPv6 default routers, so I don't need to use IPv4 for anything.

Your point about assisting in troubleshooting might have merit. A possible counterargument being, possibly, the flag creates errors, that would require troubleshooting.

True story. Years ago, when I was still watching and/or recording TV programs the old-fashioned way, my Philips recording device would sometimes fail to record the program I had set up. I tried updating its software, I was super careful to set it up recording sessions correctly, and yet, sporadically, no recording when I went to watch. Irritation!

So I had to do some research. Come to find out, even though the US Supreme Court had decided that time-shift recording is perfectly legal, a "do not copy" flag was still configured, in these recording devices. So, I called the engineer from the one station giving me this problem, and the nice guy on the other end had no idea they were transmitting this blasted flag. But, the problem did go away after that.

Lesson learned (for me, anyway): best to avoid flags that aren't really essential.

Bert

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Oct 2018 23:34:59 +0100

> Your point about assisting in troubleshooting might have merit. A possible counterargument being, possibly, the flag creates errors, that would require troubleshooting.

I don't think i can figure out that there is no IPv4 on the network
needed without even trying. So much better done by the router and then
summarizing (in one bit ;-) to the hosts so they don't ave to try.
Also much easier to diagnose and troubleshoot.

> Lesson learned (for me, anyway): best to avoid flags that aren't really essential.

In the architecutre i see, the router is helpipng the hosts with the
flags. If the user of a host sees evidence that the help is incorrect,
there can always be manual overrides.

In the case of the copy-bit, the SP box is fully policing the STB,
and STB MUST NOT have overrides or else its not certified for use.

Pretty big difference in semantic IMHO.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2018 13:28:29 +1300

> IANA better allocate the bit first.

Yes, that's an interesting chicken/egg issue since there is no
designated experimental/local use bit. But hard to avoid if people
want running code before Proposed Standard. But Bjoern did already
verify an important point:

>>>   Tested the code (slightly earlier version) with 2 FreeBSD
>>>   IPv6 routers, a FreeBSD laptop on ethernet as well as wifi,
>>>   and with Win10 and OSX clients (which did not fall over with
>>>   the "6" flag set but not understood).

So at least some important legacy clients behave correctly (i.e.
silently ignore the bit).

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2018 13:36:44 +1300

> on a subnet if there is no IPv4-only host and no router routing IPv4. 

The example I've used is a an IP-based smoke detector trying to connect
to an IP-based central fire alarm system. Because human safety is
involved it needs to try every possible type of connectivity in any case,
so giving up on IPv4 because the IPv6 routers say so is not the right
answer. IMHO, a perfect case for an RFC2119 SHOULD:
  "... there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

      Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 31 Oct 2018 08:39:42 +0100

>Depends a bit on how the flag is refined:

The problem with this flag is that is solves such a remote corner case that 
the flag will cause more problems than it solves.

There are two areas where just keeping the IPv4 stack running as always is a
problem:
1) battery powered devices
2) big wifi networks

In the first case, the heuristics I presented are likely to be enough.
Tweeking mDNS may require some work, but there is no reason to assume it 
can't be done.

A vendor can show up here and say that they tried, and really need a flag.
I haven't seen that yet. At the same time, we can expect many operators to
be ignorant of the flag. So any vendor of a battery powered device will try
to reduce power consumption even if the flag is not set.

In the second case, filtering all IP/ARP traffic is likely to be enough
(the problem is actually sending the multicasts, filtering takes care of that)
We can assume that any professionally run big wifi network has at least RA
guard so telling operators to select equipment that can do ether type filtering
is not a big thing.

Which leaves us with smaller, mostly unmanaged wifi network that don't have
filtering capabilities. Most of the really small wifi networks are not
overloaded, so IPv4 traffic is not an issue. Those networks are often unmanaged
so nobody is going to set the flag anyhow.

In my opinion it is a very bad idea to increase the complexity for everyone
just because some people have an overloaded wifi and can't be bothered to buy
equipment that can do ether type filtering.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 31 Oct 2018 10:20:20 +0100

> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/119360.html

Excellent.

I looked at the patch.

I understand how it creates and sends the RA with the flag.

But I do not understand what the computer does when it receives the RA 
with the flag bit set.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 31 Oct 2018 11:24:39 +0200

> this pans out in practise?
Looking at the code, it acts by blocking outbound ipv4 frames from being 
transmitted on ethernet interfaces.  This would mean - for example - 
that if there were a default route already configured on the receiving 
device, any userland code attempting to use ipv4 services would block 
until ARP times out for the default route (default 20 minutes on freebsd).

The only part of the ipv6only discussion that was uncontroversial was 
implementation of the kernel processing side of this flag - there's very 
little to go wrong when toggling a single flag.

The problem area is how to handle the interpretation of this flag in 
userland and in the kernel, which is a much more difficult problem. 
This in turn depends on consensus in 6man about what the flag actually 
means, and there doesn't seem to be much consensus on that.

This also disregards the issue of whether the flag was either necessary 
or a good idea to start with, and nearly 700 emails into this 
discussion, the WG seems to be hopelessly divided on these issues.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 31 Oct 2018 10:30:29 +0100

Le 30/10/2018 à 22:09, Bjoern A. Zeeb a écrit :
[...]
> I also patched tcpdump to see the flag and I can share some 
> ifconfig/ndp output if it’s desirable.

ifconfig/ndp and tcpdump output would be great to see.

Also, a packet dump, would be great.

Please see attached my packet dump of RA IPv6-only flag generated with 
scapy on windows.  I guess there could be interoperability.

Alex
> set of this”.  That’s what it is. If I would add to this (and I am
> sure I will) it’ll be the following (in order): (a) RX filter based
> on interface flag so packets don’t make it up the stack at least
> anymore (b) a global (system-wide, not per-link) flag to allow an
> administrator to overrule the decision (for whatever reason) (c)
> allowing the system admin to set the interface specific IPV6_ONLY 
> to test if they can’t get a full test network to play with. (d) deal
> with dhclient and do make ipv6 start before ipv4 as indicated in the
> draft.
> 
> 
> (dhclient probably one of the most nagging ones) to save local
> battery cycles as well, but then I could just compile a FreeBSD
> client without INET support (which we did in 2011) and be done with
> it.   I think what I am trying to say:  why waste time on software
> which is almost obsolete?
> 
> I’ve done an experiment years ago, running an “IPv6-only” kernel with
>  EAFNOSUPPORT coming back earlier in the stack rather than later.
> feature “inet” or “inet6” (and others) are present or compiled out.
> So it’s been there for apps people to test with for 7+ years.. =this
> is just yet another flag to care about.
> 
> 
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories. This draft is a work item of the
>>>> IPv6 Maintenance WG of the IETF.
>>>> 
>>>> Authors         : Robert M. Hinden Brian Carpenter Filename
>>>> : draft-ietf-6man-ipv6only-flag-03.txt Pages           : 12 
>>>> Date            : 2018-10-16
>>>> 
>>>> 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.
>>> 
>>> You have running code:
>>> 
>>> I wish the discussions would be as short as the code changes that
>>> are needed to implement a minimalistic set of this.
>>>

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Oct 2018 20:31:44 +1100

> But I do not understand what the computer does when it receives the RA

Implementation specific. The goal is to stop hosts sending and receiving
IPv4 packets on the layer 2 media.

Linux and Windows have ways to manually disable IPv6, and since they both
provide the Sockets API, a similar technique could be used to disable IPv4
and make it unavailable to applications (i.e., error on Sockets API calls)

This draft could provide suggestions, but cannot be prescriptive because
that is IPv4 stack implementation specific.

Regards,
Mark.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 31 Oct 2018 09:42:27 +0000

Manfredi (US), Albert E <[email-masked]> wrote:

> Which says, I have no peripherals configured which require IPv4

how do you know in advance that there are no peripherals that the user might want to connect to which are IPv4 only ?

> I have no old IPv4 PCs with which I'm sharing drives

how do you know that the user won't want to connect to an IPv4 only share ?

> I have access to one or more IPv6 default routers

describes pretty well every dual-protocol network)

> so I don't need to use IPv4 for anything.

So your user of a device on a dual-protocol network goes into whatever UI they have to find local devices (printers, file shares, etc). They didn't previously have any persistent IPv4 connections defined*, the network is dual-protocol so you have at least one default router for IPv6 - by your heuristics the user will not find any IPv4 only devices. So you have broken the network for them.

Using the administratively set flag model, they will not have a problem because (unless he's a twit) the admin won't have set this flag for this network.

* For whatever reason - it may be that this device is new to the network and so has no prior knowledge of the devices on it. Or may be a freshly imaged device which is effectively the same thing.

> A possible counterargument being, possibly, the flag creates errors, that would require troubleshooting.
> 

The lesson learned from this is that the flag is the right way to do it. The flag was incorrectly set causing a **hard** fault, it was diagnosed and unset, problem solved.

The alternative ? Your recorder makes guesses and indeterminately fails to record programs that it thinks (according to some obscure heuristics) shouldn't be copied. Harder to diagnose as it's a soft fault, and even harder to fix.

Had the station not turned the flag off, then your option to work around the misconfiguration would have been the same as if the heuristics model been used - you'd need to hack the recorder to disable the feature.

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Oct 2018 20:51:32 +1100

On Wed., 31 Oct. 2018, 20:43 Simon Hobson <[email-masked] wrote:

> how do you know in advance that there are no peripherals that the user
> might want to connect to which are IPv4 only ?
>

Because the network operator has actively asserted that there aren't, by
actively choosing to set this flag.

If any such devices attached to an IPv6 only link, they shouldn't have
been, and it is a network connection policy violation for the link. They'll
fail to work and should fail to work, because they don't talk IPv6.

If IPv4 only devices can be legitimately connected to this link, then
clearly it isn't an IPv6 Only link, and the flag shouldn't be set.

We're getting into trying to prevent insanity territory with these sorts of
corner cases.

> So your user of a device on a dual-protocol network goes into whatever UI
> they have to find local devices (printers, file shares, etc). They didn't
> previously have any persistent IPv4 connections defined*, the network is
> dual-protocol so you have at least one default router for IPv6 - by your
> heuristics the user will not find any IPv4 only devices. So you have broken
> the network for them.
>
> Using the administratively set flag model, they will not have a problem
> because (unless he's a twit) the admin won't have set this flag for this
> network.
>
> * For whatever reason - it may be that this device is new to the network
> and so has no prior knowledge of the devices on it. Or may be a freshly
> imaged device which is effectively the same thing.
>
>
> > True story. Years ago, when I was still watching and/or recording TV
> programs the old-fashioned way, my Philips recording device would sometimes
> fail to record the program I had set up. I tried updating its software, I
> was super careful to set it up recording sessions correctly, and yet,
> sporadically, no recording when I went to watch. Irritation!
> >
> > So I had to do some research. Come to find out, even though the US
> Supreme Court had decided that time-shift recording is perfectly legal, a
> "do not copy" flag was still configured, in these recording devices. So, I
> called the engineer from the one station giving me this problem, and the
> nice guy on the other end had no idea they were transmitting this blasted
> flag. But, the problem did go away after that.
> >
> The lesson learned from this is that the flag is the right way to do it.
> The flag was incorrectly set causing a **hard** fault, it was diagnosed and
> unset, problem solved.
>
> The alternative ? Your recorder makes guesses and indeterminately fails to
> record programs that it thinks (according to some obscure heuristics)
> shouldn't be copied. Harder to diagnose as it's a soft fault, and even
> harder to fix.
>
> Had the station not turned the flag off, then your option to work around
> the misconfiguration would have been the same as if the heuristics model
> been used - you'd need to hack the recorder to disable the feature.
>
>

---

From: Simon Hobson <[email-masked]>
Date: Wed, 31 Oct 2018 09:59:51 +0000

Brian E Carpenter <[email-masked]> wrote:

> answer.

I very strongly disagree with this example.
As it's a "safety of life" issue, these devices should NEVER EVER be on anything but a safely segregated network. If they aren't, then they are NOT part of a proper fire detection system. There's a reason that fire detection and alarm systems are normally hard wired, with their own systems, using fire resistant cables (at least for the alarm annunciators). I find it hard to believe that any IP based system just randomly plugged into a general purpose network would pass even the basics of requirements for a fire detection & alarm system.
Having a little knowledge of how commercial fire detection systems operate - there is a lot of work goes into fault detection and mitigation. Once you get past the basic small systems, they even have automated faulty cable detection and isolation - so get a cable short, no problem, the system will isolate that section (losing a few sensors but not the whole loop) and raise a fault alarm.

Given the number of failure modes for such an arrangement (detectors plugged into random IP network with everything else), the only sane option would be that upon loss of connectivity with the sensor, the system would have to go into fire alarm mode - there is no other option as the control system could not differentiate between a fire that's taken out power to the sensors, fire that's taken out the non-fire rated cable to the sensor, a switch failure, a power failure taking out the switch, something nicking the IP address, or an admin being unaware of this safety critical system on the network and "turning off" IPv4.

Mind you, if the system did lose connectivity by setting this flag - then it presumably understands IPv6 and will be using it, so the failure mode of setting this flag incorrectly is moot. On the other hand, if the admin decides that IPv4 is dead and filters IPv4 traffic at L2 in the switches (and the fire detection system is IPv4 only) - well that would break things and he'd get to know about it fairly quickly.
From experience, it's "a tad embarrassing" to set off the fire alarm because you've forgotten that part of one of your systems links into it when you're doing the periodic checks - and before you can get to the alarm panel to cancel the alarm, people are already heading out of the door :-(

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 31 Oct 2018 10:08:35 +0000

On 31 Oct 2018, at 9:24, Nick Hilliard wrote:

> Looking at the code, it acts by blocking outbound ipv4 frames from 
> being transmitted on ethernet interfaces.

and wifi and all other kinds that use the common code.  Yes.

> This would mean - for example - that if there were a default route 
> already configured on the receiving device, any userland code 
> attempting to use ipv4 services would block until ARP times out for 
> the default route (default 20 minutes on freebsd).

That would have to be a manual configuration as on an IPv6-only link you 
would not have that at the time the flag turns up; otherwise it is a one 
time event and the admins  could do a better job.

And no an app wouldn’t block; it gets an immediate EAFNOTSUPPORT when 
it tries to send something and can got into normal error handling as for 
any socket code, try another address, or core dump if it’s that kind 
of software quality.

The point is: the noise is contained and not spread.

/bz

---

From: Simon Hobson <[email-masked]>
Date: Wed, 31 Oct 2018 10:12:08 +0000

Mark Smith <[email-masked]> wrote:

> Because the network operator has actively asserted that there aren't, by actively choosing to set this flag.

I agree - that would be the case using the flag. But Albert (to whom the question was asked) asserts that heuristics such as "IPv6 appears to work and we have no active IPv4 connections" is sufficient to determine whether or not to enable IPv4.

> If any such devices attached to an IPv6 only link, they shouldn't have been, and it is a network connection policy violation for the link. They'll fail to work and should fail to work, because they don't talk IPv6.

Yes

> If IPv4 only devices can be legitimately connected to this link, then clearly it isn't an IPv6 Only link, and the flag shouldn't be set.
> 
> We're getting into trying to prevent insanity territory with these sorts of corner cases. 

I agree. Setting the flag where IPv4 is expected to continue working would be a configuration error - and one that the network admin can fix by unsetting the flag.
Doing it by heuristics is prone to soft errors that would be hard to diagnose and harder to fix. But I don't seem to be getting through to Albert on this one.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 31 Oct 2018 13:49:45 +0100

> slowing down discovery, they should be defined independently of the

True.  I think the IPv6 version of mDNS is probable more chatty than the 
IPv4 version, in some cases.  But even then, removing the IPv4 mDNS 
could only save battery, compared to IPv4+IPv6 versions of mDNS.

As a side note, it is possible to improve other aspects of the IPv6 
version of mDNS only and not care about the IPv4 version.  One could ask 
Apple to make an improvement for the IPv6 version of mDNS with respect 
to privacy: stop putting the MacBook Pro owner's name in the mDNS 
request, because anybody on the link can see it and attach it to the 
global address.

One would not ask Apple to do that for IPv4, because IPv4 is not worth 
the effort, and because there is no privacy risk there (the IP address 
is behind NAT).

Alex

---

From: David Schinazi <[email-masked]>
Date: Wed, 31 Oct 2018 07:37:57 -0700

Hello Alexandre,

The DNSSD working group is working on privacy-preserving service discovery,
to avoid your device name and service list being disclosed to everyone on
link. If this is of interest, please join us Thursday afternoon session 1:
https://datatracker.ietf.org/meeting/103/materials/agenda-103-dnssd-01

That said, this is independent of IPv4/IPv6/IPv6-only-bit. The problem will
be solved at the DNSSD layer, not inside IPv4 or IPv6.

David

On Wed, Oct 31, 2018 at 5:50 AM Alexandre Petrescu <
[email-masked]> wrote:

> IPv4 version, in some cases.  But even then, removing the IPv4 mDNS could
> only save battery, compared to IPv4+IPv6 versions of mDNS.
>
> Apple to make an improvement for the IPv6 version of mDNS with respect to
> privacy: stop putting the MacBook Pro owner's name in the mDNS request,
> because anybody on the link can see it and attach it to the global address.
>
> One would not ask Apple to do that for IPv4, because IPv4 is not worth the
> effort, and because there is no privacy risk there (the IP address is
> behind NAT).
>
>
>
> Alex
>
>
>
> IETF IPv6 working group mailing [email-masked]
> IETF IPv6 working group mailing [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 31 Oct 2018 15:41:30 +0100

In IPv4 that person's name is not a problem (the IP address is behind NAT).

Alex

Le 31/10/2018 à 15:37, David Schinazi a écrit :
> Hello Alexandre,
>
> The DNSSD working group is working on privacy-preserving service 
> discovery, to avoid your device name and service list being disclosed 
> to everyone on link. If this is of interest, please join us Thursday 
> afternoon session 1:
> That said, this is independent of IPv4/IPv6/IPv6-only-bit. The problem 
> will be solved at the DNSSD layer, not inside IPv4 or IPv6.
>
> David
>
> On Wed, Oct 31, 2018 at 5:50 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>
>     True.  I think the IPv6 version of mDNS is probable more chatty
>     than the IPv4 version, in some cases.  But even then, removing the
>     IPv4 mDNS could only save battery, compared to IPv4+IPv6 versions
>     of mDNS.
>
>     As a side note, it is possible to improve other aspects of the
>     IPv6 version of mDNS only and not care about the IPv4 version. 
>     One could ask Apple to make an improvement for the IPv6 version of
>     mDNS with respect to privacy: stop putting the MacBook Pro owner's
>     name in the mDNS request, because anybody on the link can see it
>     and attach it to the global address.
>
>     One would not ask Apple to do that for IPv4, because IPv4 is not
>     worth the effort, and because there is no privacy risk there (the
>     IP address is behind NAT).
>
>
>
>     Alex
>
>>>     Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
>>     Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Oct 2018 16:30:48 +0100

Ok, so more generalized, the argument is 

"Trust the sum of all IPv6 router on a subnet more than a possible
IPv4 router" may not apply in cases where the host wants to try all
it can do to communicate. Example: emergency communications.

Qualitatively this is not wrong, i am just not sure if this should
really be considered for standards track behavior now.

One argument is that it does not make sense to introduce this level
of complexity before an even more important level of resiliency is
not done either. For example IMHO it would be even more important
to rethink resilience in the presence of multiple routers of the
same address family first and for example make such a device/app
try in parallel to reach the remote server in parallel across all of
the found IPv6 routers. Unless there is a different IPv6
prefix assigned to the host for each such router, there is no
way for a host stack to do this because the standard transport APIs do not
offer knowledge about the different routers (You would have to hack
this). 

So, in my book this means that we should not bother about third priority
considerations unless we've resolved all second tier priorities,
and then we can still write an update of this document.

Aka: KISS to make the approach more attractive.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 31 Oct 2018 15:43:42 +0000

> In IPv4 that person's name is not a problem (the IP address is behind 

That’s an assumption.  Not everyone in this world has been infected by 
NAT.  Some people still have pure unfiltered DFZ IP as we all used to 
until the mid/late 90s.

/bz

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Oct 2018 16:47:37 +0100

> I agree - that would be the case using the flag. But Albert (to whom the question was asked) asserts that heuristics such as "IPv6 appears to work and we have no active IPv4 connections" is suffici…

I am asserting that routers can can assert whether there are 
any IPv4 only hosts on the LAN and only when there are none,
and if the router itself is also not configured to route IPv4
would it automatically set the v6only flag.

> I agree. Setting the flag where IPv4 is expected to continue working would be a configuration error - and one that the network admin can fix by unsetting the flag.

To me any new solution that requires more configuration is always
a downer. Primarily, everthing new we do should be autoconfiguring,
and only when sufficient analysis ha been done that this is not
possible should we continue discussing manual config requirements.

I have not seen sufficient discussion concluding that this flag
can not be autoconfigured by routers.

> Doing it by heuristics is prone to soft errors that would be hard to diagnose and harder to fix. But I don't seem to be getting through to Albert on this one.

Right. either we're able to specify explicit algorithms
for things or we're just doing a half-baked job.

Also i thought you have to say NN/DL/AI and not "heuristic" to
get funding ;-)

Cheers
   Toerless

-- 
---
[email-masked]

---

From: David Farmer <[email-masked]>
Date: Wed, 31 Oct 2018 10:53:44 -0500

On Tue, Oct 30, 2018 at 7:28 PM Brian E Carpenter <
[email-masked]> wrote:

> want running code before Proposed Standard.
>

Regardless if this document is published and any misgivings anyone has, I
think we need to have IANA allocate the code point to this purpose NOW!  We
asked to have running code, we now have some, it is extremely dangerous to
have code out in the wild without some level of an official designation of
the code point.

I'm not sure of the procedure, but for all effective purposes if we expect
there to be more running code we had better officially designate the code
point.

Thanks.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 31 Oct 2018 15:54:50 +0000

> would it automatically set the v6only flag.

There are TWO really big and in practical terms insurmountable problems there.

Firstly, wanting to deprecate IPv4 (in as far as this flag assists it) is an administrative function. it is not a case of whether there are any IPv4 only devices on the network - as has been mentioned several times, there may well be legacy devices still operating but for most devices "we don't care about being able to talk to them".
If you make this (no IPv4 devices) a pre-condition of setting the flag then it's highly unlikely that you'll ever set it given how many of them there are.

Secondly, an IPv6 only router won't know if there are any IPv4 devices there.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Oct 2018 16:59:27 +0100

> only save battery, compared to IPv4+IPv6 versions of mDNS.

As said, i am more interested in getting rid of IPv4 on dual stack
capable hosts to simplify device operations, host stacks, diagnostics, etc.
And because link-local-scope IPv4 sucks (because of IPv4).

Lower power consumptions is cool, but a more constrained use case right now
(would become a lot more important i hope in the future though).

> As a side note, it is possible to improve other aspects of the IPv6 version
> of mDNS only and not care about the IPv4 version.  One could ask Apple to
> make an improvement for the IPv6 version of mDNS with respect to privacy:
> stop putting the MacBook Pro owner's name in the mDNS request, because
> anybody on the link can see it and attach it to the global address.

I always liked the notion of trusted, private networks where you can be
open and friendly and everybody can know you. Which i guess is the
history of appletalk networks, at least in the 90th. On todays home networks
where you have uncounted embedded devices from companies that all try to
improve their margins by abusing your data that notion went down the
drain *sigh*. 

> effort, and because there is no privacy risk there (the IP address is behind
> NAT).

See above. I am sure my printers with cloud-print functionality are
listening to all mDNS multicasts and report the names of other devices on the LAN
to the printer vendors cloud service.

Would be great if there could be trusted third parties vetting companies
and handing out certifies to only those devices that will not enable
spying on you. think today it would be very simple to start such a
service. It would just not be able to hand out any certificates *sigh*.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Oct 2018 17:47:03 +0100

Simon,

The basic level of autoconfiguring which version of IP needs to be
active on a host is IMHO not an administrative function, but just
an automatic simplification of host stack operations, and beside
simplification it also can help to save battery (hopefully, as said
i wouldn't want to quantify that aspect). Thirdly, it would
automatically retire IPv4 in man subnets and solve IMHO the most
obnoxious unnecessary proliferaion of IPv4: you only have
external IPv6 connectivity, no old IPv4only host, and yet,
every device in the subnet still enables stupid IPv4 link-local.

So, its kinda completely incomprehensible how we would NOT want to
try to eliminate this most easy and most obnoxious IPv4
remains. All the other places where we would want to get rid of IPv4
are more difficult to deal with automatically IMHO.

You are right that a manual choice of "there are IPv4only devices,
but i still set the flag, because all "new" devices undersstanding
the flag would not need to talk to the old IPv4only devices. This
is fine, but its somewhat of a freeby to me: If we define
automastic operation of the flag thats as useful as stated above,
i don't reject manually configured overrides in the good old
tradition of allowing admins to shoot themselves or their
users in the feet.

> Secondly, an IPv6 only router won't know if there are any IPv4 devices there.

Good point. So for automatic settings of the flag, an IPv6only
router would need to implement listening to those IPv4/ARP packets
that would indicate presence of IPv4 only hosts. Or the feature
really is only supported on dual-stack routers configured
(or defaulting ) accordingly for only IPv6, in which case maybe
a second flag would be good for IPv6only routers indicating
"ipv6only-router", in which case that routers announcement
can be ignored on hosts trying to figure out whether IPv4 needs
to be enabled.

But maybe instead of starting delving into the technical issues,
the question is what type of problem we're trying to solve in
order of priority, and whether or not the top priority should be
to eliminate unnecessary enabling IPv4 on hosts AUTOMATICALLY - 
as i claim. Or battery saving as the draft claims.

Lastly: Yes, there are still new consumer devices with IPv4 only
stacks. The worst offenders are probably all those devices
where IP multicast is a key function and companies being too lazy
to move to IPv6 because they want to avoid duplicating content
in both IPv4 and IPv6 multicast. The most egregious new offender
IMHO is SES with its SAT-IP standard in europe thats also IPv4 only.
In this case it would be perfectly eay to also support IPv6 IMHO

*sigh*.
    Toerless

-- 
---
[email-masked]

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 31 Oct 2018 18:23:48 +0000

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

> how do you know in advance that there are no peripherals that the user might want to connect to which are IPv4 only ?

Does not matter. The updated host prefers IPv6. If there has been nothing configured that requires IPv4, IPv4 is not used. If the user has to set up a new peripheral that is IPv4-only, the OS will have to be informed of that, when the user sets it up. (Might also involve installing new drivers.) All part of the process. The user, of course, can be oblivious of these details.

> how do you know that the user won't want to connect to an IPv4 only share ?

Same answer. Absolutely nothing here, flag or no flag, must ever preclude starting up IPv4, if the need arises. The flag does not change anything. Even with flag set, you cannot create a case where things suddenly start breaking, only because the user's device got a software update.

> describes pretty well every dual-protocol network)

Not necessarily. You boot up your device on this new network, and you are presented with IPv6 default router options via RAs. You have no IPv4 default router configured, no router advertisements to use to set up any IPv4 default router, no peripherals set up which require IPv4, but you do have IPv6 default routers and IPv6 DNS. So, why bother even trying IPv4? You don't need to ... not yet anyway. If your device is not already configured to use IPv4 assets of any sort, then it won't need to transmit IPv4. That could change, in the future, and nothing must prevent this.

> So your user of a device on a dual-protocol network goes into whatever UI they have to find local devices (printers, file shares, etc). They didn't previously have any persistent IPv4 connections d…

A device which really wants to save power will prefer the IPv6 printer(s). It's easy enough, if you want to "find all other printers available," to start IPv4, without involving any net admin. This breaks nothing. The device maker and the user are perfectly capable on deciding just how much they are into saving power, even on dual stack networks.
 
>> True story.

> The lesson learned from this is that the flag is the right way to do it. The flag was incorrectly set causing a **hard** fault, it was diagnosed and unset, problem solved.

Problem didn't need to exist! The Supreme Court had already decided. Users should not have to do research, to use their equipment legally. The obvious course of action would have been for the manufacturer to send an update, which disabled reading of the "do not record" flag entirely, on this particular device. There should no longer be any situation in which a broadcaster can prevent the user from doing what is perfectly legal, in his home equipment.

Same with this IPv6-only flag. You eliminate unnecessary risk, you don't try to dream up obscure corner cases, where just maybe, some of the time, it might help. The heuristic model is trivially easy, in this case. It's called, "recording the broadcast program, for the purposes of any in-home time shifting device like this one, is always permissible." In our case, starting to use IPv4, for internal network usage, e.g. for a new peripheral in my local network, id always permissible.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Nov 2018 08:43:05 +1300

> userland and in the kernel, which is a much more difficult problem.

It's a question, but I don't know why it's a problem. It isn't an interop
problem, because each host is an independent actor in this. And we now have
running code proof that legacy hosts aren't affected. So I'd say that from
a protocol spec point of view, it's actually a non-issue.

> means, and there doesn't seem to be much consensus on that.

There is specific text in the draft. For the purpose of verifying the
draft via running code, that's fine. Of course, we would need WG rough
consensus to proceed, but I haven't seen any proposed text changes since
the current draft came out.

> discussion, the WG seems to be hopelessly divided on these issues.

I'll leave that one to the WG chair who isn't a co-author. But I will
say that in my mind the issue is whether the feature is one that will
be valuable in 5, 10 or 20 years time rather than whether it's valuable
today.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Nov 2018 08:45:59 +1300

> there to be more running code we had better officially designate the code

There is a procedure for requesting early allocation, and of course an allocation
can always be rescinded later. Whether there's any real practical risk is a
judgment call.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Nov 2018 12:01:53 +1300

Toerless,
> really be considered for standards track behavior now.

It's only an argument for SHOULD rather than MUST. And you know that in
the real world of product development, everything is SHOULD anyway, if that
suits the vendor better.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Nov 2018 12:04:41 +1300

> can not be autoconfigured by routers.

The router cannot perceive the *intention* of the network administrator.
(Not until NMRG and ANIMA have finally decide what "Intent" is, anyway. ;-)
 
> for things or we're just doing a half-baked job.

That isn't really in scope for this draft though. I think we probably have
far too much text in the draft already.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Nov 2018 12:11:03 +1300

On 2018-10-31 22:59, Simon Hobson wrote:
> As it's a "safety of life" issue, these devices should NEVER EVER be on anything but a safely segregated network. If they aren't, then they are NOT part of a proper fire detection system. 

You're completely correct**. But that doesn't actually change the logic
of my example. If a safety-critical device is (incorrectly) attached to
the wrong network, it's going to do whatever it can to correct the situation,
and no RFC can stop it.

   Brian

** Speaking as someone who in about 1980 ditrectly caused a beam dump
in the CERN Antiproton Accumulator because some idiot had connected the
power supply for the human safety systm to our computer room's UPS,
and I switched on a new computer that had a hard-wired ground fault
that tripped the UPS.

> There's a reason that fire detection and alarm systems are normally hard wired, with their own systems, using fire resistant cables (at least for the alarm annunciators). I find it hard to believe that any IP based system just randomly plugged into a general purpose network would pass even the basics of requirements for a fire detection & alarm system.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Nov 2018 01:29:48 +0100

> (Not until NMRG and ANIMA have finally decide what "Intent" is, anyway. ;-)

Haha. Lets not rathole on Intent here ;-)
Yes, agreed, but the autoconfigured part i was suggesting would IMHO not
be intent but an always-correct autoconfiguration that hosts SHOULD follow.

> far too much text in the draft already.

Its true that the mechanisms/algo on routers to autoconfigre the flag
would be more text but it would provide one strong reason for the flag
that does not depend on operator intent and could threefore make the
flag stronger.

I am happy if the flag  draft would go through as is unchanged though
because the automatic mechanism on routers can always be added later. I
just brought it up to show how the flag does not need to depend on
complex analysis/intent by the operator.

Cheers
    Toerless

-- 
---
[email-masked]