Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"

[Sander Steffann <[e-mail]>]

Hi,

> But this is what the text says:
> 
> RFC4862:
>> A link-local address is formed by combining the well-known link-local
>> prefix FE80::0
> 
> Hold on?  Isn't that denoting an address?  Rather than a prefix?
> 
> FE80::0 is an address, not a prefix.  Were it a prefix it should have
> been named FE80::/plen.

True, it's written as an address. However, in step 2 it says to set all bits to the right of the prefix to zero. However you choose to read it, you end up with fe80:0000:0000:0000:0000:0000:0000:0000. In step 3 the N rightmost bits of that are overwritten with the N-bits-long IID.

> I suspect the author could not write FE80::/10
> because s/he was not sure whether that should be FE80::/10 or FE80::/64.

The ipv6-on-ethernet explicitly states that on ethernet the link-local prefix is fe80::/64.

> So she came up with FE80::0, ignoring that it can be understood as an
> address by some.

Don't make assumptions.

> And naturally so, because, notationally, it is not clear whether FE80::0
> is even allowed, from the point of view of the "::".  We know the "::"
> can not be preceded by 0s in the same sextet (notation FE80:0::/64 is
> forbidden).  But we dont know whether "::" could be followed by hextets
> made of 0s (we dont know whether FE80::0:0 is allowed).

Of course it is allowed. fe80:: is the same as fe80:0:0:0:0:0:0:0, is the same as fe80:0:0::0:0 etc. Where did you get the idea that some of those notations are forbidden? RFC 4291 only says that "The use of "::" indicates one or more groups of 16 bits of zeros." nothing more nothing less. It doesn't mandate using :: for all groups of 16-bits of zeroes, just "one or more".

> Notationally, we do know that an address written like FE80::1 is a full
> address (there is no plen specified).  It is possible to assign FE80::0
> as an address on an interface.
> 
> Given that, how can the RFC4862 say "the link-local prefix FE80::0"?  If
> so, how much trust can we put in that?  If this approximation is
> permitted, which other approximations are allowed?  What does the point
> 2. actually meant?

If you take it literally and assume that fe80::0 is an address instead of a prefix, then it is a /128 and point 2 doesn't need to do a thing because all those bits are 0 already. If you read it as a prefix then after point 2 you end up with the exact same 128 bits.

However, RFC 4862 explicitly refers to "the well-known link-local prefix FE80::0 [RFC4291]" and although it doesn't write it as a prefix, RFC 4291 section 2.4 is very explicit that the prefix is fe80::/10.

I agree that the wording is a bit unfortunate, but however you read it, after point 2 the result is the same.

> (As a side remark, it is obvious that these things may appear as too
> much detail for the person looking from high up, but the notational
> definition is of utmost importance for someone trying to write a lexical
> analysis and grammar for textual representation of IPv6 addresses.  I.e.
> any of the numerous GUI or CLI interfaces.)
> 
>> 2.  The bits in the address to the right of the link-local prefix are
>> set to all zeroes.
> 
> What is then a "link-local prefix"?  Is it fe80::/10?  Is it fe80::/64?

The link local prefix on ethernet is fe80::/64. Other network types may vary, but on all of them the link-local prefix is within fe80::/10.

> Did the author actually mean "left" instead of "right", and mean "IID"
> instead of link-local prefix?
> 
> We dont know.  But we must make it work.  So we come up with
> interpretations.

?!?? Stop second-guessing the authors. The wording is quite explicit and you "alternative interpretations" are not.

>> It also says "The length of the interface identifier is defined in a
>> separate link-type-specific document". RFC 2464, which is that
>> link-type-specific document for ethernet, specifies in section 5 that
>> on ethernet the prefix for link-local addresses is a fe80::/64 with a
>> 64-bit IID.
> 
> Yes.
> 
>> Everything is specified: the /10 to use as the basis,
> 
> At this time, it seems that /10 is not used for anything else.  It is
> reserved for nothing.  You call it a 'basis' but nobody uses such a
> basis,

On the most common network types it is indeed not uses. It is reserved for whatever happens in the future. Maybe nobody will use it, maybe some future RFC will. What's the problem?

> and it creates confusion as noted above.

No it doesn't. The /10 is reserved, ethernet uses a /64, other network types may use something different. Pretty clear.

> So someone who insists on 64bit IID and 64bit plens can't continue with
> that /10 for any reason.

Why not? No harm in reserving a bit more than you use or need today.

>> the /64 being the length used on ethernet and the bits between the
>> two having to be zero.
>> 
>>> , and it is also the case when PIO in RA has a P1::/63.
>>> 
>>> For this latter case, one wonders: am I allowed to form an address
>>> when all I have is a P1::/63, and an IIDlen 64?  Can I make a
>>> P2::/64 by padding with 0s?
>>> 
>>> The specs dont answer these questions.  The specs think that the
>>> "sum" equation is enough.
>> 
>> It is. A "sum" is a quite clearly defined mathematical concept.
> 
> Well, it is as shady as when we say a=1.  The mathematician reads it
> differently than the programmer.
> 
> A useful equation for programmer is like this: m+n MUST equal 128.  You are not allowed to pad if you receive a /63 in RA, or if you have a IID-shorter-than-64; you are not allowed to make addresses of length 129.
> 
> just the equation is not enough.

The equation is perfectly fine. Do you really want to add "no, you can't single-handedly modify the input to fit the output, stick to the equation and the input provided to you"??? Please stop being silly.

> Moreover, that unclarity leads to deviations like this: 128 can only be made of 2 parts each being 64.

On ethernet that is correct according to current RFCs.

>> As you quoted above RFC 4862 section 5.5.3 says "If the sum of the
>> prefix length and interface identifier length does not equal 128
>> bits, the Prefix Information option MUST be ignored." Let's test
>> this. In your example case: - P1::/63 has a prefix length of 63 -
>> IIDlen (interface identifier length) is 64 - the sum of the prefix
>> length and the interface identifier length is 63 + 64 = 127 - 127
>> does not equal 128 - therefore the Prefix Information option MUST be
>> ignored
> 
> And what if I add a 0 bit between the 63 and 64?  That plen would become
> 64.  At that point the sum would become 128 again.

Again, stop making things up to fit your imagination. The RFC is quite clear.

> It's the same thing that people did when adding 0s between /10 and /64
> of the FE80:://10 to make it become FE80::/64.

Nope, that is explicitly specified as such.

> Why the specifier can silently add 0bits to make plens 64 for the LL,

It's not silent, it's specified.

> but implementer couldnt do the same with a received /63?

Because the RFC explicitly says not to.

>>> Further, because of that, some people think P1::/63 is forbidden
>>> from being advertised on Ethernet.
>> 
>> According to RFC 4862 you can advertise it, but receivers must ignore
>> it.
> 
> And if so then it is wrong.

In none of this I'm saying that I agree with what is written in the current RFCs. There are plenty of things I would have liked to be done differently. But today we have the existing RFCs. If things should be changed then the solution is to write new RFCs, not to play games with the interpretation of the current ones.

> You may be overwhelmed by too many emails from my part, but that's
> another aspect.

No, my head is quite clear today despite the attempted confusion by alternative interpretations.

Cheers,
Sander