appropriate length of fe80:: prefix and new IP-over-foo drafts

[Alexandre Petrescu <[e-mail]>]

I wanted to let the group know that at least two new IP-over-foo drafts 
do use 64 as prefix length for link-local addresses. 
(draft-ietf-lpwan-ipv6-static-context-hc-18 and  draft-hou-6lo-plc).

I think it should not be that way.

I think the prefix length of link-local addresses is a minimum 10 and a 
maximum 127. (draft-petrescu-6man-ll-prefix-len-06)

Alex

Le 14/12/2018 à 15:37, Yucel Guven a écrit :
> Alex,
> Absolutely agree.  "A 'prefix' must have a prefix length."
> 
> Not specific for Link-Local, but I suggest to add your draft:
> "prefix: a contiguous string of bits valid for forwarding operations
> and for subnet formation. A prefix must have an integer length value 
> from 1 to 127
> and prefix-length must be indicated in its textual representation."
> 
> -Yucel Guven
> 
> On Mon, Dec 10, 2018 at 9:28 PM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 
>     Le 30/11/2018 à 19:57, 神明達哉 a écrit :
>      > At Fri, 30 Nov 2018 10:33:01 +0100, Alexandre Petrescu
>      > <[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      > wrote:
>      >
>      >> [...]> Why? Since everybody agrees that the 54 bits are always
>      >> zero,
>      > I have
>      >>> no idea what the problem is that led to this thread.
>      >>
>      >> Brian, I trust this question is not provokative.  Also, I seriously
>      >> try to avoid the situation Ole points about disagreeing just for
>      >> the easiness of it.
>      >>
>      >> Let me try to explain my problem.
>      >>
>      >> I am routinely confronted with links on which link-local addresses
>      >> are very important: ptp links on 4G, intermediary router-to-router
>      >> WiFi GUA-less links, and others.
>      >>
>      >> I am under a strong requirement from end users migrating to IPv6 to
>      >> use simple to memorize IPv6 addresses (they routinely do IPv4
>      >> 192.168.1.2 hard-coded in many places).  This primes over the
>      >> privacy requirements, which are present too, but as a second.  This
>      >> phase of using IPv6 with simple to remember addresses but an
>      >> initial step, before bringing in more complex addresses.  If I fail
>      >> this initial step then IPv6 will not be used, because IPv4 is
>      >> simpler to be used there.  The users must be able to be quickly
>      >> succeed with ping6 as they are with ping.
>      >>
>      >> Under these circumstances I am led to design a WiFi ad-hoc network
>      >> of routers with LL prefixes and addresses like fe80:1::2/32.  The 1
>      >> means the LL Subnet ID 1, and 2 means the IID of a particular
>      >> router.
>      >
>      > So far it's understandable (except, of course, that fe80:1::2
>      > violates Section 2.5.6 of RFC4291 and is not standard-compliant).
>      >
>      >> Is fe80:1::2 a link-local address?  Yes and no.  Yes, because it
>      >> falls within the "fe80::/10" block reserved by IANA for LL
>      >> purposes.  No, because it has a 1 somewhere in the 54bits thus
>      >> contradicting RFC4291's definition of a link-local address.
>      >
>      > Now you're unnecessarily making your actual problem a terminology
>      > nitpicking.
> 
>     It is not nitpicking.
> 
>     It is true that hexadecimal 3FA is the leftmost 10 bits of an IPv6
>     link-local address (binary 1111111010).  We just cant write 3FA with our
>     existing IPv6 textual notation method which groups 'hextets'; because of
>     that notation we must write fe80::/10.  Yet that does not make 3fa a
>     prefix, no more than 1111111010 is.  A 'prefix' must have a prefix
>     length.
> 
>     I will update the draft about this, calling this a Difficulty.
> 
>     Alex
> 
> 
> 
> 
>         I suspect that's one major reason why we cannot have very
>      > productive discussion in this thread.  Even if there's some kind of
>      > small ambiguity about the term of "link-local unicast address (or
>      > prefix)", as long as we have Section 2.5.6 of RFC4291 it doesn't
>      > affect the fact that you can't use fe80:1::2 without being
>      > non-compliant.
>      >
>      > If you have a specific operational problem that could be resolved by
>      > loosening the requirement of Section 2.5.6 of RFC4291 (i.e.,
>      > allowing non-0 values for the intermediate 54 bits), you should
>      > simply propose that with the problem description.  The proposal may
>      > or may not be accepted, of course, but at least the discussion will
>      > be more focused that way.
>      >
>      > BTW, I don't know if it helps in your specific case, but you may
>      > want to look at RFC4007.  It tries to answer this exact problem with
>      > an extended syntax for scoped addresses.  So, you might use
>      > "fe80::2%1" instead of "fe80:1::2".
>      >
>      > -- JINMEI, Tatuya
>