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

[james woodyatt <[e-mail]>]

On Mar 3, 2017, at 14:30, Philip Homburg <[e-mail]> wrote:
> 
>>   Shorter james: if IETF will insist that I modify my host IPv6
>>   stack so that, on Wi-Fi links, it will do on-link determination
>>   with prefix lengths other than 64 bits, then I want to see that
>>   in its own draft and not in the successor to RFC 4291.
> 
> Did I miss a couple of rounds somewhere?

It looks like you’re assuming that I don’t have to comply with requirements in RFC 4862 when processing RA messages with Prefix Information Options (PIO). Like every good IPv6 host implementation, mine implements SLAAC. It therefore needs to comply with RFC 4862, especially if I ever hope for it to achieve IPv6 Ready certification for hosts. Lots of hosts are required to implement RFC 4862. You probably have one in your pocket.

> Onlink prefixes come from PIO options in RAs with the L bit set. Since
> forever, these options have a prefix length field.
> 
> Section 4.6.2 of RFC 4861 has this to say about prefix length:
> "8-bit unsigned integer.  The number of leading bits
> "in the Prefix that are valid.  The value ranges
> "from 0 to 128.  The prefix length field provides
> "necessary information for on-link determination
> "(when combined with the L flag in the prefix
> "information option).  It also assists with address
> "autoconfiguration as specified in [ADDRCONF], for
> "which there may be more restrictions on the prefix
> "length.
> 
> So there are extra restriction for SLAAC, but not for use as an onlink
> prefix.
> 
> Are you saying that your stack completely ignores that prefix length and
> hardcodes it to 64?


I’m saying that my stack tries to comply with RFC 4862 which requires that it ignore PIO options where the Prefix Length is not 64 on link types that define the length of the IID as 64 bits in the relevant IPv6-over-link document. My stack does that in the hopes of eventually passing the IPv6 Ready certification test, which I’ve been through before, and, yes, it tests for that MUST In RFC 4862. It tests both the requirements for processing the A flag as well as the requirements for processing the L flag.

If you send me a Prefix Length other than 64 bits, then I’m gonna ignore it. Just as RFC 4862 commands.

It’s technically true that *if* my stack did not implement SLAAC, then it would have no need to comply with RFC 4862, and it could therefore accept Prefix Length other than 64 bits on Ethernet (and Wi-Fi) link types, by complying only with RFC 4861 and not RFC 4862.

But let’s be honest. Who would buy gear intended for home networks that cannot do SLAAC?


--james woodyatt <[e-mail] <mailto:[e-mail]>>