Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07

[james woodyatt <[e-mail]>]

Hi Tim,

To be clear, I’m not trying to be combative. I’m trying to prepare a case for the LwIP maintainers so that when I ask for my pull request to be considered I can refer them to this thread. Please be patient with me here.

On Mar 7, 2017, at 11:18, Timothy Winters <[e-mail]> wrote:
> 
> The NOTE in 4861 states implementations can choose to process them independently.    I'm not sure where you it allows for dropping on-link determination if it fails.     Can you point me at the line that allows this?

Okay, I’m going to go through this line by line, because I think the case that LwIP is clearly violating RFC 4861 is open to question. Furthermore, I think the inference from the informative text rather clearly implies that LwIP is not violating even the *spirit* of the text, much less the letter of its RFC 2119 keyword language.

Please help me find where this argument fails.

In RFC 4862, §6.3.4 Processing Received Router Advertisements:

>> Similarly, [ADDRCONF] may impose certain restrictions on the prefix length for address configuration purposes.

I read this to say that additional requirements language MAY apply to processing the Prefix Length field in PIO elements (the relevant sections are quoted below) for hosts capable of stateless address configuration.

>> Therefore, the prefix might be rejected by [ADDRCONF] implementation in the host.

I read this as recognizing implicitly that it’s OPTIONAL (implicitly, because of the use of “might” instead of “may” here is not RFC 2119) for a host to reject a PIO because of the additional “certain restrictions on prefix length” it imposes, cited in RFC 4861.

>> However, the prefix length is still valid for on-link determination when combined with other flags in the prefix option.

I read this at face value: prefixes are valid for on-link determination when combined with other flags in the PIO element *and*, in light of the preceding sentence, when the “certain restrictions on prefix length” imposed by RFC 4862 do not apply, because for example, the host is configured not to use stateless address configuration for the interface where the RA message was received.

Further discussion is entailed here, because this where the argument gets a little twisty and legalistic, but as I said, I’m trying to prepare a case for defending the correctness of the USGv6 and IPv6 Ready Logo tests to the maintainers of the LwIP project by taking the opposite view.

At this point in the text, it’s an open question which document has primacy over the validity of a PIO in the case of a host that claims to conform with both RFC 4861 and RFC 4862, but see the following Note, which seems to be there for the express purpose of resolving the question.

>>       Note: Implementations can choose to process the on-link aspects of
>>       the prefixes separately from the stateless address
>>       autoconfiguration aspects of the prefixes by, e.g., passing a copy
>>       of each valid Router Advertisement message to both an "on-link"
>>       and an "addrconf" function.  Each function can then operate
>>       independently on the prefixes that have the appropriate flag set.

I read this as RFC 4861 again recognizing implicitly that it's OPTIONAL (using “can” instead of “may”) whether hosts process PIO elements for on-link determination even when they are rejected by RFC 4862.

For this reason, for hosts that choose to reject PIO elements, even for on-link determination, when the “certain restrictions on the prefix length” in RFC 4862 apply, the relevant text from RFC 4862 needs to be consulted.

In RFC 4862, §5.3 Creation of Link Local Addresses:

>> If the sum of the link-local prefix length and N is larger than 128, autoconfiguration fails and manual configuration is required.  The length of the interface identifier is defined in a separate link- type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2).  These documents will carefully define the length so that link-local addresses can be autoconfigured on the link.

The key sentence in this passage is "The length of the interface identifier is defined in a separate link- type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2).”

As we are preparing to publish a successor to RFC 4291, I will quote the relevant (and controversial) section of I-D.ietf-6man-rfc4291bis-07:

>> IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes on inter-router point-to-point links.  However, the Interface ID of all unicast addresses, except those that start with the binary value 000, is required to be 64 bits long.  The rationale for the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

In light of the plethora of updates to RFC 4291, I believe the above to be a reasonable clarification of the existing text in RFC 7136, §5, which expressly updates the original text in RFC 4291, §2.5.1 as follows:

>> For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long.  If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format.

In both cases, RFC 4291 (updated by RFC 7136) and I-D.ietf-6man-rfc4291bis-07 (currently awaiting IESG writeup), the requirement is that IID length for all unicast addresses starting with 0b000 is 64 bits. Which is relevant to the excerpt above in RFC 4862, §5.3 saying that “the length of the interface identifier is defined in a separate link- type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2).”

Note Well: the SHOULD in that sentence is a recommendation not a requirement.

So, I read RFC 4862 to REQUIRE that the IID length be defined in a separate link-type document and to RECOMMEND that the IID length be 64 bits. (Note: the LwIP implementation only supports link types where the IID length is already defined in standard documents to be 64 bits).

Now, this is important because RFC 4862, §5.5.3 Router Advertisement Processing is the text that imposes the “certain restrictions on prefix length” referenced in RFC 4861, §6.3.4 Processing Received Router Advertisements. Here’s what that says in ¶d after specifying how to form an address by stateless address configuration:

>> If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored.

Reading this in light of the Note in RFC 4862, §6.3.4, it clearly imposes “certain restriction on prefix length” for the validity of PIO elements. It further REQUIRES that PIO elements with invalid Prefix Length fields not be used for stateless address configuration. It does not, however, explicitly override the Note in RFC 4862, §6.3.4 that clarifies that it is OPTIONAL for hosts to process PIO elements for on-link determination even when they have invalid Prefix Length for stateless address configuration.

>> The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2).

Here again, RFC 4862 repeats its previous guidance to REQUIRE that the IID length be defined in a separate link-type document and to RECOMMEND that the IID length be 64 bits (which LwIP requires of all supported interface types).

But we’re not done. RFC 4862 continues:

>> It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type.

I do not read this as any requirement on the host implementer to accommodate system administrators who use Prefix Length values that are not consistent with the IID length defined for the link type in use.

>> It should be noted, however, that this does not mean the advertised prefix length is meaningless.

This is informative and helpful, and not normative text.

>> In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128.

Indeed, as I read RFC 4861, this recognizes *explicitly* that hosts MAY use advertised prefixes with invalid Prefix Length for address configuration, for example, for the purpose of on-link determination.

>> Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration.

This is not in conflict with the observation of RFC 4861 that processing Prefix Lengths for on-link determination that are invalid for address configuration is not REQUIRED and merely OPTIONAL. 

>> Note that a future revision of the address architecture [RFC4291] and a future link-type-specific document, which will still be consistent with each other, could potentially allow for an interface identifier of length other than the value defined in the current documents.  Thus, an implementation should not assume a particular constant.  Rather, it should expect any lengths of interface identifiers.

As I read this excerpt, this is RFC 4862 expressly recognizing that future standards action could introduce new valid IID lengths for address configuration other than 64 bits. This hasn’t happened yet. (And there is still some controversy about whether RFC 4291 should not be revised unless it is changed to do so.)

Another text relevant to this discussion is IPv6 Subnet Model [RFC 5942], which has this to say in §5 Observed Incorrect Implementation Behavior:

>> One incorrect implementation behavior illustrates the severe consequences when the IPv6 subnet model is not understood by the implementers of several popular host operating systems.  In an access concentrator network ([RFC4388]), a host receives a Router Advertisement message with no on-link prefix advertised.

For the purposes of this discussion, I invite the reader to imagine in this scenario the additional consideration that the Prefix Length is not valid for stateless address configuration and the A flag is also zero. In other words, a scenario where the rules in question here are relevant.

>> An address could be acquired through the DHCPv6 identity association for non-temporary addresses (IA_NA) option from [RFC3315] (which does not include a prefix length), or through manual configuration (if no prefix length is specified).

This address would have to have a valid IID for the link type, according to RFC 4291. The PIO element here with A=0 and L=0 and Prefix Length > 64 is simply advertising legitimately that the router provides reachability to this longer prefix only to a subset of the valid host addresses on the subnet. Hosts are not required to add the prefix to the on-link prefix list, nor to configure an address in that prefix.

Hosts could be manually configure addresses with that prefix or obtain them from DHCPv6 (they would be reachable), but they cannot use SLAAC to assign addresses with that prefix. And RFC 5942 says they cannot add the prefix to the on-link prefix list. (It does have some squirrels bits about RFC 4903.)

The rest of this text in RFC 5942 goes on to describe the observed incorrect behavior in this scenario, and it’s behavior that LwIP does not have.

>> The host incorrectly assumes an invented prefix is on-link.

In other words, it’s violating RFC 4861 by failing to recognize what L=0 signifies.

>> This invented prefix typically is a /64 that was written by the developer of the operating system network module API to any IPv6 application as a "default" prefix length when a length isn't specified. This may cause the API to seem to work in the case of a network interface initiating stateless address autoconfiguration (SLAAC); however, it can cause connectivity problems in Non-Broadcast Multi-Access (NBMA) networks.  Having incorrectly assumed an invented prefix, the host performs address resolution when the host should send all non-link-local traffic to a default router. Neither the router nor any other host will respond to the address resolution, preventing this host from sending IPv6 traffic.

I should observe again here that LwIP performs correctly here, despite having an implementation defined restriction on link types that have IID length of 64 bits. It does not add the prefix for two reasons, not just one: the L flag is zero, and the Prefix Length is invalid.

Its behavior also complies with all the rules defined in RFC 5942, §4 Host Rules, which I will not repeat here.

—

In summary, there is a deficit of RFC 2119 keyword language here, and we have to make the case that the standards texts make a sufficiently strong implicit case rather than an explicit normative requirement.

As explained above, it sure looks to me like a very fair reading of the implicit requirements language is that LwIP is within the limits of RFC 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring PIO elements with invalid prefix length for IID on the underlying link type.

Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights to apply additional requirements beyond the IETF standards, but it seems like a strict interpretation of the standards allow for LwIP to claim conformance.

How can we counter this argument?


--james woodyatt <[e-mail]>