Subject: Re: you have running code ... I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

From: tom petch <[email-masked]>
Date: Thu, 1 Nov 2018 12:44:59 +0000

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "David Farmer" <[email-masked]>
Cc: "6man WG" <[email-masked]>
Sent: Wednesday, October 31, 2018 7:45 PM

> On 2018-11-01 04:53, David Farmer wrote:
> > On Tue, Oct 30, 2018 at 7:28 PM Brian E Carpenter <
> > [email-masked]> wrote:
> >
> >> On 2018-10-31 10:42, Mark Smith wrote:
......

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

RFC7120
....
   1.  The authors (editors) of the document submit a request for early
       allocation to the Working Group chairs, specifying which code
       points require early allocation and to which document they should
       be assigned.
...
Up to you!  The allocation times out after a year.

Tom Petch

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

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 01 Nov 2018 15:51:22 +0000

On 31 Oct 2018, at 19:45, Brian E Carpenter wrote:

>>>>> What OS vendor will go next?
>>>>>
>>>>
>>>> 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.
>>>
>>

I’d suggest finalise the draft and get the RFC out and not complicate 
matters by diverting energy to sort the bit out.  If we sort the bit out 
it almost means that we want this draft to go out as an RFC, so get it 
out :-)

/bz

---

From: Lee Howard <[email-masked]>
Date: Fri, 2 Nov 2018 11:23:09 +0530

On 11/1/18 1:13 AM, Brian E Carpenter wrote:
> but I haven't seen any proposed text changes since
> the current draft came out.

https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm

Lee

---

From: Lee Howard <[email-masked]>
Date: Fri, 2 Nov 2018 11:39:12 +0530

On 11/1/18 1:13 AM, Brian E Carpenter wrote:
> On 2018-10-31 22:24, Nick Hilliard wrote:
>> Job Snijders wrote on 30/10/2018 22:27:
>>> Can you (or others running FreeBSD EXPERIMENTAL) share reports on how
>>> 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.
> 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.

Doesn't it mean that user space applications on a host that had/expected 
IPv4 would fail?

I think I described my interop concern: 
https://mailarchive.ietf.org/arch/browse/ipv6/?qdr=m&so=frm

IPv4-only hosts, and dual-stack hosts
that do not recognize the new
     flag, may continue to attempt IPv4 operations

If some devices require IPv4 and others disable IPv4, you have lost 
connectivity between systems on a local network. As written, this is not 
considered a misconfiguration by the administrator who sets the flag.

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

I've come into the camp that believes that in 10 or 20 years IPv4 will 
be disabled by default. When people post to stackoverflow complaining 
that their 10-20 year old devices are unreachable from their brand new 
devices, the response will be, "The old stuff might be using the old 
protocol, IPv4. Go into Control Panel, Networking, Protocols, select 
IPv4, click enable."

If that's likely, then this flag is only useful in the interim 5 years. 
During that time, I would like to maximize connectivity.

If a network administrator wants central control over IPv4/IPv6 
enablement in hosts, there are better, more centralized tools for that. 
As a principle, host behavior should be managed by host management 
tools, and not by hints from a router.

Lee

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 02 Nov 2018 10:05:34 +0000

On 2 Nov 2018, at 6:09, Lee Howard wrote:

> Doesn't it mean that user space applications on a host that 
> had/expected IPv4 would fail?
>
> connectivity between systems on a local network. As written, this is 
> not considered a misconfiguration by the administrator who sets the 
> flag.

The draft says “
    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.

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

And heck, if user space applications fail because v4 doesn’t work 
anymore, than they work based on an assumption (and have been for 20 
years) and they’d better get fixed.

Here’s how it goes: (a) network admin turns ipv6-only on, 98 of 100 
hosts are fine;  2 hosts with their secret covert channel no longer talk 
for some obscure thing interacting on the local network only.  (b) users 
panic looking at their “very important service” (e.g., their private 
chat protocol written out of boredom at the end of 1999).  (c) admins 
shrug and move these two machines into a quarantine network where they 
can still talk ipv4 and will be (1) running forever until the hardware 
dies, (2) until someone fixes the software to use ipv6, (3) for the next 
6 months until the vlan is decommissioned.

The answer is: if that service is critical you will (A) be happy you 
found out about that problem if no one knew about it before and (B) 
you’ll do everything to fix it in a good way (and that could also be 
to disable that flag for another two weeks until everything is sorted).  
But you’ll fix that software.    If it’s not relevant it goes into 
“collateral damage” and you are happy that the thing is gone from 
your network and your “network hygiene level just went form orange to 
green”.

I’ve played these games for more than 8 years.  And you have to play 
them a lot less these days compared to 2010.

I guess it all depends how you arrive at the day to “turn the 
IPv6-Only flag on”.  Ideally you have selective removed IPv4 from the 
network before so the flag more or less ends up to be just a “OK, this 
is IPv6-only so make sure it stays that way” for where you have 
critical services.   But this is all “ops” and not 6man.

> protocol, IPv4. Go into Control Panel, Networking, Protocols, select 

Very much like people posted “My token ring can’t talk to my 
ethernet?”  Look in 10 years the IPv4-only Islands will be very much 
understood.  People will be looking for “migrating” these to 
“something entirely new”.

> If that's likely, then this flag is only useful in the interim 5 
> years. During that time, I would like to maximize connectivity.

The flag will still be useful in 127 years when people will do IPv9 and 
there’ll be people around who say “This IPv9 stuff I am not going to 
touch, keep this legacy IPv6 on until everyone else in the world has 
moved.  Then I can go and look.”

> enablement in hosts, there are better, more centralized tools for 
> that. As a principle, host behavior should be managed by host 
> management tools, and not by hints from a router.

Or by hints from a central directory service?  I guess it’s better 
I’ll remove your host entry from my dhcp server as well immediately 
then.  And also stop answering ARP and RS for you.  You can configure 
that using your host tools.

/bz

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Nov 2018 08:20:16 +1300

> Doesn't it mean that user space applications on a host that had/expected 

Well yes, but that is presumably the network administrator's intention,
so I'm not sure I'd characterise it as am interop issue exactly, and it's
not an interop issues *involving the RA message itself*. 
 
> considered a misconfiguration by the administrator who sets the flag.

Indeed not. The admin will presumably be happy at this result.
I don't think we disagree about the effect, just about whether
it's desirable.

> tools, and not by hints from a router.

I'm not sure how that can work on a BYOD network. On a fully managed network,
sure, we could "easily" invent a solution.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Nov 2018 08:22:28 +1300

>> the current draft came out.

Lee, sorry, I still haven't processed your review.

    Brian
> .

---

From: Lee Howard <[email-masked]>
Date: Sat, 3 Nov 2018 17:05:59 +0530

Sorry, I didn't trim because I think it's all context...

> sure, we could "easily" invent a solution.

Taken all-in-all, then, the use case for this flag is a network where 
the administrator:

1. does not know what's on the network,

2. expects that there are some applications using IPv4,

3. understands that IPv4 will continue to work locally, 3b. except for 
dual-stack hosts that honor the flag,

4. understands that applications may have already negotiated IPv4 
connectivity,

5. desires to break communications for 3b and 4, and prevent IPv4 
Internet access.

It's not just that administrator accepts that 3b and 4 won't work, but 
as you said above, "The admin will presumably be happy with this result."

This seems to me a very narrow application.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 4 Nov 2018 10:15:39 +1300

> 1. does not know what's on the network,

May not know what's on the link, or does not have management access
to some devices on the link, or does not have policy control over
some devices on the link. There are many such networks.

> 2. expects that there are some applications using IPv4,

I don't see that. The admin has decided that there are no IPv4
services on the link - presumably no DHCPv4, no DNS over IPv4,
no IPv4 routing. Whether or not some hosts contain IPv4 applications
isn't necessarily known to the admin.

> dual-stack hosts that honor the flag,

It might be fairer to say that the admin doesn't care whether
IPv4 works locally, but has decided to announce to everybody that
there are no IPv4 services on the link, knowing that only 3b hosts
will understand the announcement.

(The fact that RAs are universal, whereas other possible mechanisms
such as DHCPv6 or NETCONF are not, is relevant here.)

> 4. understands that applications may have already negotiated IPv4 

Again - doesn't care.

> 5. desires to break communications for 3b and 4, 

Again - doesn't care.

> and prevent IPv4 

Yes, that's the primary decision. Of course, the assumption is that
IPv6-only access to the Internet is necessary and sufficient.

> as you said above, "The admin will presumably be happy with this result."

Or doesn't care.

> This seems to me a very narrow application.

It's certainly directed at a specific (and future) phase of history, when
IPv6-only is viable and IPv4 has not yet faded into oblivion. How many
links for how many years would be in that phase is an open question.

As the draft recognizes, there are other mechanisms available too.
What strikes me as unique about this mechanism is simply that *every*
dual stack host receives and understands RAs; this is our only way
of getting a bit to every single dual stack device. That's not
narrow, IMHO.

     Brian

---

From: Lee Howard <[email-masked]>
Date: Mon, 5 Nov 2018 11:36:04 +0530

> isn't necessarily known to the admin.

If there are no IPv4 services, there is nothing to turn off using this flag.

> such as DHCPv6 or NETCONF are not, is relevant here.)

Okay, "understands that IPv4 will continue to work locally if enabled on 
hosts."

>> 4. understands that applications may have already negotiated IPv4

The document says:

Administrators MUST 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.

"certain that the link is IPv6-Only" is not the same as "doesn't care if 
there are residual IPv4 connections."

>> 5. desires to break communications for 3b and 4,

The flag is specifically to disable connectivity through IPv4. If you 
don't care about IPv4, you don't set the flag.

>> as you said above, "The admin will presumably be happy with this result."

If she didn't care, she wouldn't set the flag. This administrator is 
intentionally setting the flag for one or more of the reasons given in 
the Introduction.

> of getting a bit to every single dual stack device. That's not

The number of cases where IPv4 might exist and an administrator wants to 
shut it down and has no other tools seems narrow to me. While I agree 
that all dual-stack hosts understand RAs, that doesn't mean they all 
understand this flag. I have counted zero host operating system 
implementers who have said they will take action on this flag, but check 
my math.

In a desire to be constructive, I think we had talked earlier about 
defining the flag to mean, "I have no IPv4 routes." That might be useful 
information for a host, letting it decide whether it needs IPv4 locally 
(or has another IPv4 route), and disable appropriately.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Nov 2018 20:38:49 +1300

While waiting for meetecho to fix the feed I was using...

> If there are no IPv4 services, there is nothing to turn off using this flag.

The host doesn't know that; the flag tells the host not to waste its time.

> Okay, "understands that IPv4 will continue to work locally if enabled on 

Locally = on a traditional broadcast LAN segment with no L2 filters.
But I don't see why this changes anything; we know we can't physically
prevent a host trying to use IPv4 if it insists.

> there are residual IPv4 connections."

Again, I don't see your worry. It's all about the admin's intention, and it's
fair warning to any hosts. This is not a switch, it's literally a flag with
"No IPv4 services" written on it.

> don't care about IPv4, you don't set the flag.

No, the flag is to announce that there is no IPv4 service. That is not
the same thing as "to disable connectivity."

> intentionally setting the flag for one or more of the reasons given in 

Yes, but the real action is *not* enabling IPv4 routing, DHCPv4, or
DNS over IPv4. (And installing L2 filters, maybe.) The flag is only
a flag.

> implementers who have said they will take action on this flag, but check 

As for most IETF proposals, it takes time.
 
> (or has another IPv4 route), and disable appropriately.

That is one of the things it means, along with "I don't grok DHCP" (which
also means "I don't announce a DNS/IPv4 server").

And yes, a host MAY ignore it (that's the complement to the SHOULD
in the draft). We've never said anything else.

   Brian

---

From: Jen Linkova <[email-masked]>
Date: Mon, 5 Nov 2018 18:44:01 +1100

On Fri, Nov 2, 2018 at 5:09 PM Lee Howard <[email-masked]> wrote:
> If some devices require IPv4 and others disable IPv4, you have lost connectivity between systems on a local network. As written, this is not considered a misconfiguration by the administrator who sets the flag.

If some devices require IPv4 and the administrator implemented
ethertype filtering, blocking IPv4 packets on that LAN segment, you
have lost connectivity between systems on a local network. I'd not
considered this a misconfiguration by the administrator who configured
filtering based on ethertypes.

If some devices require IPv4 and the administrator has control over
some other devices and disabled IPv4 on them (as I did on my
workstation), you have lost connectivity between systems on a local
network. Again, I'd not considered this a misconfiguration by the
administrator who disabled IPv4 on devices which are managed.

-- 
SY, Jen Linkova aka Furry

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 5 Nov 2018 11:15:31 +0000

> in the draft). We've never said anything else.

yes, but you have stated "On an IPv6-Only link, IPv4 might be used for 
malicious purposes and pass unnoticed by IPv6-Only monitoring mechanisms".

If you want ipv6only-flag to be advisory, then you need to remove this 
bullet-point from the document because the presence or absence of an RA 
with ipv6only-flag set will not have any effect on malicious use of ipv4 
on an otherwise "ipv6-only" network.

You cannot use security to justify something unless the proposal 
provides a mechanism for enforcement; if you have no means of 
enforcement, it's fluff, not security.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Nov 2018 12:49:31 +0100

> enforcement, it's fluff, not security.

Well there is the Secure Neighbor Discovery protocol (SeND).  With it 
one can claim the link to be secure if IPv6-Only and insecure if IPv4 is 
present.

Simpler but less strong than SeND, there can be mechanisms to ensure a 
certain level of security, about the MAC address in the L2 header of the RA.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 5 Nov 2018 12:13:47 +0000

> one can claim the link to be secure if IPv6-Only and insecure if IPv4 is 

well, there isn't because the presence or absence of SEND won't stop 
anyone from using ipv4, particularly if the use case is malicious.

> certain level of security, about the MAC address in the L2 header of the 

"secure" mac addresses can only be deployed if the network supports l2 
filtering at the user edge, in which case the ipv6only flag is largely 
pointless because you can make ipv4 go away with the same style of ACL, 
with the added benefit that it will actually make your network ipv6-only.

Nick

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 05 Nov 2018 15:50:59 +0000

On 5 Nov 2018, at 6:06, Lee Howard wrote:

> I have counted zero host operating system implementers who have said 
> they will take action on this flag, but check my math.

Well, given you are replying to a thread that has “you have running 
code” in the Subject, check your math*s* please.  You have 1 OS with 
an implementation already (both router and basic host side).  If this 
draft moves forward I’ll make sure the “basic” can be removed from 
that sentence as well.  It’s about 50 LoC.  Double it and dhclient no 
longer tries to run either and I’ll have RX side filters as well as 
well as IPv4 configuration being degraded to run after IPv6.  That’s 
about the end of the story.  Can be implemented and tested in a few 
hours.  Sample code exists.

/bz

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Nov 2018 08:37:38 +1300

> on an otherwise "ipv6-only" network.

Yes, you're correct. There is a slight mitigation effect - hosts that *do*
use the flag to shut down IPv4 operations will not see any malicious IPv4
traffic.

Some rewording is needed.

> enforcement, it's fluff, not security.

Thanks
   Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 6 Nov 2018 09:52:34 +0700

Hi,

> On Nov 6, 2018, at 2:37 AM, Brian E Carpenter <[email-masked]> wrote:
> 

To clarify, the draft says that hosts SHOULD do what the flag specifies.  It doesn’t say it is advisory.   RFC2119 defines SHOULD as:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that 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.

This discussion would be better if we used the words that are in the draft in the discussion.

I do agree that a node that doesn’t support IPv4 will not see IPv4 traffic, this needs to be clarified in the current draft.

Thanks,
Bob

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 6 Nov 2018 07:29:24 +0000

Nick

Just reading you now at the 6MAN WG meeting after making exactly the same point as yours :-(

To busy here to follow all email messages...

-éric

On 05/11/2018, 18:16, "ipv6 on behalf of Nick Hilliard" <[email-masked] on behalf of [email-masked]> wrote:

    

    Nick