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

[Mark Smith <[e-mail]>]

Hi Alex,

I don't think it is necessary to come up with a further text representation
to distinguish between addresses and prefixes.

A prefix is a general concept, it specifies, within a set of bits, the set
and values of the bits that are defined, and the range of bits that are
ignored, in the context where the prefix is used.

fe80::/10 is the link-local prefix from within which all more specific link
local prefixes come from.

An address is a specific example of a prefix, where all bit's value are
defined, meaning none are ignored. An address is therefore a prefix with a
/128 prefix length.

A prefix without a shown prefix length is assumed to have a prefix length
of /128. If that doesn't make sense in context, then the error is that the
prefix length hasn't been specified. That's the fault of the writer not the
reader.

We could entirely eliminate the term 'address' by replacing it with '/128
length prefix'. It would be entirely correct, but clumsy.

This is all true for IPv4 too, as that is where it has come from. It has
been accurate for long enough that trying to change it may cause more
confusion not less.

Regards,
Mark.


On 8 Mar. 2017 2:06 am, "Alexandre Petrescu" <[e-mail]>
wrote:



Le 07/03/2017 à 13:15, Sander Steffann a écrit :

> Hi Alex,
>
> Op 7 mrt. 2017, om 11:44 heeft Alexandre Petrescu
>> <[e-mail]> het volgende geschreven:
>>
>> Le 07/03/2017 à 02:11, 神明達哉 a écrit : [...]
>>
>>> But this thread and another similar discussion seem to suggest
>>> that it's still not clear enough for some people.  At least two
>>> different readers interpret this text:
>>>
>>> If the sum of the prefix length and interface identifier
>>>> length does not equal 128 bits, the Prefix Information option
>>>> MUST be ignored.
>>>>
>>>
>> Let me say that there are some interpretations of that sum from
>> people struggling to make it work.  These interpretations may be
>> surprising to the specifier.
>>
>> The specifier is tempted to think that that "sum" equation is a
>> good way to tell everything in just one phrase.
>>
>> But some people face the problem of making that sum be 128 even
>> though the plen is less than 64 and the IID is 64.
>>
>> It is the case with the fe80:://10 needing to become a fe80::/64
>>
>
> Which is explicitly specified in RFC 4862 section 5.3. The /10 is
> used as the basis and adapted to the IID length on the link. It
> explicitly says that all bits between fe80::/10 and the IID are zero
>  (point 2).
>

That is how you read it, and you read it so because you want to make it
work.

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.  I suspect the author could not write FE80::/10
because s/he was not sure whether that should be FE80::/10 or FE80::/64.
 So she came up with FE80::0, ignoring that it can be understood as an
address by some.

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).

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?

(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?

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.


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, and it creates confusion as noted above.

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


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.

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


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.

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.

Why the specifier can silently add 0bits to make plens 64 for the LL,
but implementer couldnt do the same with a received /63?


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.


Others think fe80:://10 is the same as fe80::/64.
>>
>
> As you can see above the fe80::/10 prefix is used as the basis for
> the link-local addresses, with the actual prefix length defined per
> link-type. For ethernet that has been specified as 64-bits, so that
> leads to fe80::/64 on ethernet.
>
> Please read the RFCs. All the examples you provide are quite
> explicitly covered there...
>

I read many times these RFCs...  I know what I talk about.

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

Alex


> Cheers, Sander
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------