Re: encoding link ID in link-local addrs (Re: about violation of standards) - problem statement

[Philip Homburg <[e-mail]>]

> 1 A rejected Errata to RFC4291 "IPv6 Addr Archi" on the topic of
> link-
>    local addresses 'would need' a draft.  (The errata ID is 4406;
>    the URL is https://www.rfc-editor.org/errata/eid4406)

One of the goals of internet standards is to provide interoperability between
independently developed implementations.

In this case, as long as you stick to fe80::/64, Linux and BSDs can
interoperate. However, if you go outside of RFC-4291, you will find that
Linux and BSDs can no longer interoperate.

You propose to amend RFC-4291 to allow the reserved bits be set to something
other than zero. If such a proposal would be accepted then BSDs would no 
long comply with the amended RFC.

At this stage of standardisation of IPv6 it is bad to render currently 
complying implementations non-compliant unless there is a serious reason to do
so. 

It is also quite likely that it will be quite a bit of work for the BSDs
to implement the change you want.

Now what is so massively broken that it would be worth marking the BSDs as
non-compliant with one of the core IPv6 RFC?

The main example you gave is somebody typing IPv6 literals while sitting in a
car. 

In my opinion, there are so many other options to debug a network that it 
doesn't make sense declaring existing BSDs non-compliant just for this reason.

I cannot find anything in draft-ietf-ipwave-vehicular-networking-08 that
says that link local with 64-bit IIDs cannot work. Maybe you can be more
specific about the IPWAVE requirements.