Subject: Re: review of draft-ietf-6man-ipv6only-flag

From: Brian E Carpenter <[email-masked]>
Date: Sun, 4 Nov 2018 11:05:16 +1300

Finally getting to this message...
On 2018-10-21 04:41, Lee Howard wrote:
> Notes. . .
> 
> 1. Introduction
> 
> "The flag does not apply to o non-default IPv6 routers." The double negative
> is a bit awkward, and might be clearer as "The flag only applies to default
> routers."

Ack

> 
> "That is, a link where there are no IPv4 routers and/or IPv4 services."
> Sentence fragment. Good device, that. Will be used more later.

Ack. If we miss any, the RFC Editor would catch them.

> 
> Typo: 0x806 should be 0x0806 (ARP)  /g

Ack.
 
> A version number is specified for Windows and no other OS; probably
> unnecessary.

Hmm. My observation is that the Windows default settings have evolved
quite a bit; probably what we say is true of all Windows since #7,
but having recently switched from 7 to 10 I've noticed subtle differences.
So my inclination is to stick to "Windows 10" to be sure we're accurate.

> I agree that every general-compute OS supports dual-stack, but I'm not sure
> that most printers do, and I know that very few embedded OS devices (IoT,
> TVs, game consoles, etc.) do.

s/printers/some printers/

> 
> "Such traffic may drain battery power on wireless hosts that have no 
> interest
> in link-local IPv4"
> Sounds like what you need there is a L2 message to the switch saying, 
> "No IPv4
> here, thanks"

Yes, as discussed later, L2 filtering has its place, but it doesn't
stop hosts from trying IPv4.

> 
> "In managed networks..."
> Well, managed networks generally have managed devices, on which IPv4 
> could be
> disabled by managers using whatever management tools they use to manage
> devices.

Right, but we're distinguishing between managed *infrastructure* and managed
hosts. Needs a wording tweak or two.

> Do all networks use ethertypes?

Pass
 
> "this is an IPv6-Only link"
> I've lost track of previous discussion of this draft; does the IPv6-only 
> flag
> mean the router has no IPv6 on any other link, and therefore won't 
> forward, or
> that the local link has no IPv4-dependent hosts or services? It sounds like
> that latter, which may be a lot for a layer 3 router to assert about a 
> layer
> 2 domain. In other words, does it mean "I am an IPv6-only router" or "the
> link on which this IPv6 multicast message is received has no IPv4"?

It means "I, the administrator, assert that there's no IPv4 service
of any kind on this interface to this link" (and of course it's only
effective if all IPv6 default routers make the same assertion). I think
that's unambiguous in the draft.

> For a VLAN, IPv4 would only be disabled on VLANs on which the option was
> received, not every VLAN on the physical port?

Good point. We need to clarify this.

> 
> Thinking about several objections I've seen, maybe it would make sense to
> consolidate the preferred mechanisms for disabling IPv4, rather than having
> them spread throughout the introduction:
> * Filter Ethertypes 0x0800 and 0x0806
> * Disable IPv4 on hosts

You can't do that if the hosts are not managed (regardless of whether
the network infrastructure is managed).

> * Run a DHCP server that sends the DHCP option to disable IPv4 stateless
>    auto-configuration [RFC2563]

We are trying to make the text flow better in each version.

> 3. Applicability Statements
> "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.  "
> Does that mean a service the host advertises over IPv4, or one that the
> host has seen advertisements for? If the host respects the flag, the it
> would not see future IPv4 LL advertisements, of course.
> 
> "Administrators SHOULD only use this mechanism if they are certain
>     that the link is IPv6-Only."
> That sounds like a MUST to me. If you do this when you are not sure
> there is no IPv4, or when there is a need to use IPv4, you are breaking
> interoperability. If there are "valid reasons in particular circumstances
> to ignore" it, it's a SHOULD. There are no valid reasons to disable IPv4
> is IPv4 is still needed.

I think you're right.

> 4. IPv6-Only Definition
> "beyond the scope of this document"
> I think it's worth saying that a host that is capable of doing IPv4-IPv6
> translation (for instance, CLAT) or tunneling, in support of IPv4
> connectivity, SHOULD NOT disable its transition mechanism(s), but should
> only send IPv6 on the local link. The IPv6 on the local link might include
> tunneled or translated IPv4.

I really think the text directly implies that.

> "IPv6-Only provides no information about other network
>     protocols than IP running directly over the link layer"
> Well, earlier you suggested blocking Ethertype 0x0806 (ARP), and blocking
> ARP is one of the justifications for the flag. Later you're explicit about
> it.

Yes, clearly ARP is included.

> It might also be useful if it was used to block service advertisements
> for IPv4 addresses.

Sorry, what do you mean?

> 
> 5. IPv6-Only Flag
> Again I think the SHOULDs are probably MUSTs, unless someone can give a
> reason it wouldn't be.

Well, here we definitely intend SHOULD because it seems certain that some
host scenarios will vary from the norm.

> 
> 6. Router and Operational Considerations
> "on an IPv6-Only link SHOULD"
> I think this should is a MAY, since right at the beginning you said this
> flag was OPTIONAL.

It's arguable. IMHO that OPTIONAL is generic - all IETF standards are
optional, ultimately. But operationally, a SHOULD makes sense to me.
 
> However, I am very concerned about the use of MAY and OPTIONAL here;
> RFC2119 says:
>     An implementation which does not include a particular option MUST be
>     prepared to interoperate with another implementation which does
>     include the option, though perhaps with reduced functionality. In the
>     same vein an implementation which does include a particular option
>     MUST be prepared to interoperate with another implementation which
>     does not include the option
> I don't know how devices that do turn off IPv4 interoperate with dual-stack
> devices that don't turn it off.

If the dual stack devices try both v4 and v6, what's the problem?

If they don't and the admin has decided to only support v6, why
would the admin care?

> 
> typo: "routers interface" should be "router's interface"
> For that matter, since earlier in the document it says:
>     when there are intended to be IPv4-only
>     hosts or IPv4 routers on the link, setting this flag to 1 is a
>     configuration error.
> Then instead of "MAY log a configuration error" I'd prefer:
>    It is RECOMMENDED that routers report an error if the flag is set...

Agreed.

> 7. Host Behavior Considerations
> "the flag with value 0, a dual stack host SHOULD NOT assume that
>     the link is IPv6-Only."
> I think that's a MUST NOT. But it could be, "MUST NOT unless the host has
> been otherwise configured for IPv6-only." That could be interpreted as a
> SHOULD, but that's why I like qualifying SHOULDs.

Agreed.

> "at start-up" does this include "wake-up"? Or connection to a new network?
> Could be awkward for mobility.

Ack

> "have the flag set" means "set to 1" and not "set to 0"  /g

Ack

> "choose to" Do hosts make choices? Sounds anthropomorphic.

My laptop certainly has a will of its own at times ;-)
  
> I hope this is useful.

Yes, definitely, sorry it took some time to process.

Regards
    Brian

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Sat, 03 Nov 2018 23:15:40 +0000

>> Do all networks use ethertypes?

No, think of PPP.  There you just don’t negotiate IPCP (or you do) 
depending on whether you are IPv6-Only or not.  Just an example.

> Good point. We need to clarify this.

If this is for L2/switch filtering, then yes, you might want to.

Otherwise, you don’t as we are talking IPv6 and not 0x8100 or 0x88A8 
(staying with ethertypes as that’s where VLANs are).  Likewise you’d 
not filter it on an ATM link but on a VC/VP there.  Be careful to not 
over-specify things.

>> to ignore" it, it's a SHOULD. There are no valid reasons to disable 

There could possibly be IPv4 left and you want to make it shut up and 
see what happens.  We are allowed to break things (on purpose).  As the 
draft also says “A possible subsidiary use of the IPv6-Only flag is 
using it to trigger IPv6-Only testing and validation on a link.”  
SHOULD.

>>    It is RECOMMENDED that routers report an error if the flag is 

As in the above example I can see cases where you want to turn the flag 
on and yet still have IPv4 on the link (yes, contrary to the draft), to 
not break IPv4-only or dual-stack hosts which do not understand/respect 
the flag, yet to see how much IPv4 you can get rid off which is actually 
no longer needed;  that can be a very helpful “transition” phase for 
a network admin to narrow the remaining IPv4 down as well.  Whether this 
is a configuration error in that case is questionable, certainly the 
link is not expected to be IPv6-only (yet) but could be that in a week 
it will be should there be no more IPv4 traffic.  There’s just so many 
more use-cases beyond what the draft tries to accomplish as the 
“end-goal”.

>> Could be awkward for mobility.

Good point.  “When attaching to a link a host MAY delay all IPv4 
operations on that link until a ..”