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

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

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

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

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

A version number is specified for Windows and no other OS; probably
unnecessary.
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.

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

"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.
Do all networks use ethertypes?

"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"?
For a VLAN, IPv4 would only be disabled on VLANs on which the option was
received, not every VLAN on the physical port?

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
* Run a DHCP server that sends the DHCP option to disable IPv4 stateless
   auto-configuration [RFC2563]

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.

4. IPv6-Only Definition
"beyond the scope of this document"
Inon-default IPv6 routers." The double negative
is a bit awkward, and might be clearer as "The flag only applies to default
routers."

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

Typo: 0x806 should be 0x0806 (ARP)

A version number is specified for Windows and no other OS; probably
unnecessary.
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.

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

"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.
Do all networks use ethertypes?

"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"?
For a VLAN, IPv4 would only be disabled on VLANs on which the option was
received, not every VLAN on the physical port?

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
* Run a DHCP server that sends the DHCP option to disable IPv4 stateless
   auto-configuration [RFC2563]

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.

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.

"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.
It might also be useful if it was used to block service advertisements
for IPv4 addresses.

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

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

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

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.

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

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

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

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.

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

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

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

I hope this is useful.

Lee

---

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

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

I agree it is unnecessary.

It'd be hard to compare 10 of Windows with 4.x of Linux, and 'Windows' 
to 'Linux' for that matter, because one is an OS distribution and the 
other a kernel.  We could compare Windows 10 to Fedora 10, or Windows 
_kernel_ (if such a name exists) to linux.

Worse, linux (the kernel, not the distrib) as such does not have a 
default configuration for dual or single stack.  Or I may be wrong.

> TVs, game consoles, etc.) do.

I fully agree.  There are very many embedded OS devices running OS 
distributions based on linux kernels (including android OS 
distributions) that default to IPv4.  I think that is the majority.

[...]

>    auto-configuration [RFC2563]

I think that is a good list that could be expanded.

Disabling IPv4 on hosts also could be detailed: BSD kernel _can_ remove 
its IPv4 stack whereas linux kernel can not.  But disabling could happen 
also with 'ifconfig del IPv4 address' on each interface.

> is a bit awkward, and might be clearer as "The flag only applies to default

I agree, for what is worth.

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

I agree, but I also think the values are equivalent.

Alex

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