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

[Ole Troan <[e-mail]>]

Hi Alexandre,

> These are three tries for a problem statement:
> 
> 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)
> 
> Do you disagree with the recommendation of this Errata?

The errata claims an inconsistency.
I do agree with the errata rejection if that's what you are asking.

Whichever way I try to interpret this "try #1 for a problem statement", I cannot find a reading that resolves into an actual problem.

> 2 IPv6 link-local addresses are typically self-configured according to 4
>  RFCs and relying on the fe80::/10 IANA allocation, RFC 54 0 bits, and
>  RFC MAC-based 64bit Interface IDs.  In some cases, it is advantageous
>  to manually configure link-local addresses.  This is useful for easy
>  remembering by humans, and for parameter resilience during
>  network interface replacement.
> 
>  Manual configuration of an LL may use short IID and Subnet ID
>  The Subnet ID presence in the link-local address is useful in some
>  wireless settings where the subnet structure parameters depend on the
>  link locality.  Other settings may also benefit.
> 
>  When manually setting the link-local address it is necessary to know
>  the length of the prefix of the subnet on which this link-local
>  address is present.  This length is necessary for on-link
>  determination.

There is nothing in our documents that prohibit you from doing manual configuration of link-local addresses.
You can achieve easy to type and addresses you can remember, and that are different per-subnet simply by doing something like:

FE80::<16-bit subnet id>:<48-bit "station-id">

>  Implementation status: manually configuring link-local addresses is an
>  operation permitted by some Operating Systems but forbidden by others.
>  The ones that permit it need a parameter for the length of the prefix.
>  The length of the prefix is sometimes 10 (cf. IANA allocation), at
>  times 64 (cf. RFC assignment), at times 128 (cf. 2 RFCs) and other
>  intermediary values are known to work.
> 
> Is this 2nd try along your line of thought?

Sure, and what with my solution doesn't solve your problem?

> 3 more problem statements about 'some wireless settings' can be found in
>  the IPWAVE WG Problem Statement draft.
> 
> Is this 3rd kind of problem statement something that may be answering your request to provide a problem statement?

Sorry, I see nothing in draft-ietf-ipwave-vehicular-networking that directly points to the length of the link-local prefix being a problem.

Cheers,
Ole