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

Hi James,

Since this was added in the update from RFC 2461 to 4861 I went to go look
for why this was added and found the following thread.

Discussion:
https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw

Final Decision:
https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4

This is clearly about the spirit of this clarification, the working group
when adding this text wanted to allow prefix lengths much larger then 64
(80 is the example).

~Tim

On Wed, Mar 8, 2017 at 3:20 PM, james woodyatt <jhw@google.com> wrote:

> On Mar 7, 2017, at 13:41, otroan@employees.org wrote:
>
> On 7 Mar 2017, at 22:22, james woodyatt <jhw@google.com> wrote:
>
>
> 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?
>
>
> We're not writing law, we're specifying what it takes to have
> implementations of a specification interoperate.
>
>
> I agree, and I contend there's something missing here in what we’ve said
> it takes to interoperate.
>
> That implementation would fail to interoperate.
>
>
> As I wrote to the other participants in this exchange off list, I remain
> convinced that the interoperability issue here is due to system
> administrators ignoring the recommendation in RFC 4862 to always use a
> valid Prefix Length for the link type in PIO elements without also ensuring
> that all hosts on the link implement behavior that RFC 4861 implies is
> OPTIONAL for performing on-link determination.
>
> Here I will add that I’m not going to push for changes to LwIP either
> locally or upstream until I’m persuaded this interpretation of the existing
> text is wrong.
>
>
> --james woodyatt <jhw@google.com>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR