Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 04 March 2017 12:09 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFD912946A for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 04:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level:
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu8NKqsfWWmM for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 04:09:35 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CBBD129481 for <ipv6@ietf.org>; Sat, 4 Mar 2017 04:09:34 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v24C9W0C014247; Sat, 4 Mar 2017 13:09:32 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 64E4D201037; Sat, 4 Mar 2017 13:09:32 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5507E200CD2; Sat, 4 Mar 2017 13:09:32 +0100 (CET)
Received: from [132.166.84.69] ([132.166.84.69]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24C9V1G029031; Sat, 4 Mar 2017 13:09:31 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes
To: Fred Baker <fredbaker.ietf@gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <CAO42Z2z7v4gDk91b6Of-1sczV88m3B9kzn0MeJU_VBJ416k6Ww@mail.gmail.com> <ae35b45a-0398-840f-fc0d-1f64dd2fcc58@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <alpine.DEB.2.02.1703012051590.30226@uplift.swm.pp.se> <b5784622-c24e-a531-4e68-249b03701941@gmail.com> <CAAedzxrSTFe0GgYuvtXPNE=R_ZCXotxL7HbKdj5A4-869rncmw@mail.gmail.com> <ba025be6-709d-87b4-f388-d6f143408277@gmail.com> <alpine.DEB.2.02.1703021029010.30226@uplift.swm.pp.se> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <bead3cd8-f7f9-37b3-66f9-e76ae94056d1@baanhofman.nl> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <CAJE_bqcOLSK061p_biSD3GK1y464Ld=8Zp3-hAuJqQ2R2t3JRw@mail.gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> <CAJE_bqc7cFrhCaiGMGeSUf1zMsXpcoDUVvYQ13L-Soe4Rwf6RA@mail.gmail.com> <a630f8b8-e6ed-885a-a909-6c75dfd79892@gmail.com> <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com>
Date: Sat, 04 Mar 2017 13:09:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jeYseSlgKONFqNvZMif7P3OgWeQ>
Cc: IPv6 IPv6 List <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Mar 2017 12:09:38 -0000

Fred,

I think the problem I have - agreed, on my side - is that "fe80::/10" is
sometimes read as a link-local address, other times as a prefix
configured on a computer, other times as just the first 10bits of an LL
address.

The difficulty is in that people say "prefix" meaning the first bits
from left to right, and other times "prefix" meaning what is configured
on a computer.  They are different.

This "fe80::/10" seems to be the first ten bits of a link-local address;
"fe80::/10" is not an address and not a prefix to be configured on a
computer, even though whenever we write "P::/X" we understand it as a
prefix configured on a computer.

The prefix configured on a computer is "fe80::/64" and the LL address is
"fe80::1".

I had the same problem with textual representation of site-local "fec0",
with the default route "2001::/3", with the two ULAs "fc00::/7"
"fd00::/7" and recently with the 16 prefixes denoted by
2001:db8:ffff:cafe::/60 despite the mandatory presence of a single
character (the 'e' in cafe could have been 0, 1, 2... f).

I propose to introduce new ASCII characters in the textual
representation of IPv6 addresses:

fe80:://10 means the first 10 bits of an address, it does not mean it is
the configured prefix of an address in the rt table, nor is it a prefix
used for on-link determination.

fg00:://7 means the first 7 bits of a ULA, also represented as
"fc00::/7" or as "fd00::/7".

2001:db8:ffff:caf*::/60 means one or more configured prefixes from 0 to
f at the place of *.

I will try to use these characters in conversation to see what it gives.

Alex


Le 03/03/2017 à 23:51, Fred Baker a écrit :
> Read the fine RFC, Alexandre. We used to have something called a
> site-local address, which was fe80::/10 with 54 bits that were not
> all zero and a 64 bit IID, and the link-local address was fe80::/10
> with 54 bits of zero. We deprecated the site-local address, but
> link-local is still fe80::/10 followed by 54 bits that are all zero.
>
>> On Mar 3, 2017, at 2:40 PM, Alexandre Petrescu
>> <alexandre.petrescu@gmail.com> wrote:
>>
>>
>>
>> Le 03/03/2017 à 23:02, 神明達哉 a écrit :
>>> At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu
>>> <alexandre.petrescu@gmail.com> wrote:
>>>
>>>>> Both, and I believe at least most implementers have had no
>>>>> difficulty in interpreting the spec that way.
>>>>
>>>> If it is both, then it requires that the prefix used for
>>>> address autoconfiguration of LL addresses to be 64bit length.
>>>>
>>>> But the LL prefix is fe80::/10.
>>>>
>>>> "fe80::/10" means it is a prefix.  It does not mean it is "a
>>>> mask for implementation in BSD and other OSs C macros to
>>>> recognise the LL address".
>>>>
>>>> So, what goes between /10 and /64?  Why?
>>>
>>> For (auto)configuring a link-local address?  If so, it's all-0
>>> bits, as defined in Section 2.5.6 of RFC4291:
>>>
>>> |   10     | |  bits    |         54 bits         |          64
>>> bits |
>>> +----------+-------------------------+----------------------------+
>>>
>>>
>>>
|1111111010|           0             |       interface ID         |
>>> +----------+-------------------------+----------------------------+
>>
>>
>>>
>>>
Is that figure picturing a fe80::/10 or a fe80::/64?
>>
>> Is the prefix extended from fe80::/10 to fe80::/64 with 0s?  Or is
>> the IID len extended from 64 to to become an IID len==108?
>>
>> If we stopped saying fe80::/10 then it would be clearer.
>>
>> But one seems to be forced to continue talking about fe80::/10.
>>
>> Otherwise we would never write text reading "fe80::/10".
>>
>>>>> - uses the 64-bit IID (as specified in RFC2464) - uses the
>>>>> fe80::/64 prefix (as defined in RFC4291 Section 2.5.6)
>>>>
>>>> And ignores the same document's fe80::/10.  And some
>>>> implementer does not appreciate that.
>>>
>>> I'm not sure what you mean by this here, but out of curiosity,
>>> who is that implementer and what does it actually do by not
>>> appreciating that?
>>
>> Let us say that I talked to many IPv6 stack implementers and I
>> continue to.  So to answer this question there is not one person
>> in particular that I could name, but rather the name of a few
>> persons, and a sort of average I make from my discussions.
>>
>> Moreover, whenever I invoke such 3rd person, it is the very
>> optimistic view.  I avoid saying all the bad things that I heard,
>> and I keep the good things.
>>
>>> Auto-configuring a link-local address that does not match
>>> fe80::/64?
>>
>> I mean this: is one implementer mandated to bzero() the bits from
>> /10 to /64?  Or not?  Nobody is telling her so.
>>
>> If one writes code that generate an LL address by using a /64
>> mask, and then tries to make sure by recognising it by using a /10
>> macro, there is obviously place for false negatives or false
>> positives.
>>
>> If the 4291 spec wrote everywhere that the prefix is "fe80::/64"
>> (and never write "fe80::/10"), then the implementer would be
>> helped a lot. She would generate and reognise by always using a
>> 64bit mask.
>>
>> But that would be wrong to put in an IPv6 Addressing Archi,
>> because 64 is too much of a limit, anyways.
>>
>> Additionally, when we talk  about the first 3 bits 000, we dont
>> write "::/3" because "::/3" is a prefix and there is a risk of
>> confusion.
>>
>> You may remember the discussion about how to denote a default
>> route.
>>
>>>>> - combine these to configure a link-local address
>>>>> fe80::<64-bit IID> as specified in Section 5.3 of RFC4862
>>>>
>>>> And who tells the implementer what to put between /10 and /64?
>>>
>>>> Should that be 0s?  1s?  An arbitrary random mix of 0s and 1s?
>>>
>>> 0s, as described in RFC4291 Section 2.5.6.
>>
>> Are these 0s part of the plen or part of the IID?
>>
>>>>> To me there's nothing confusing or unclear here, and I
>>>>> suspect the Linux implementation essentially does the same
>>>>> thing.
>>>>
>>>> I think you dont want to see the potential confusion because
>>>> you do not ask yourself what to put between /10 and /64.  I
>>>> think you silently assume that should be 0s.
>>>
>>> If "what to put between /10 and /64" is for (auto)configuring
>>> link-local addresses, yes, I assume it's 0s.  But not "silently"
>>> - it's based on Section 2.5.6 of RFC4291.
>>
>> That section 2.5.6 does not say whether the 0s are part of the
>> plen or part of the IID.
>>
>> It is your reading, with an inclined view to make everything work,
>> that makes it read so.
>>
>> But read it with an inquiring view: is the 0 part of the IID or of
>> the plen?  The section does not answer.
>>
>>> BTW, I do not necessarily disagree that there may be "some
>>> confusion" if one sees this:
>>>
>>> Link-Local unicast   1111111010           FE80::/10       2.5.6
>>> (Section 2.4 of RFC4291)
>>>
>>> and this:
>>>
>>> |   10     | |  bits    |         54 bits         |          64
>>> bits |
>>> +----------+-------------------------+----------------------------+
>>>
>>>
>>>
|1111111010|           0             |       interface ID         |
>>> +----------+-------------------------+----------------------------+
>>>
>>>
>>>
(Section 2.5.6 of RFC4291)
>>>
>>> like, wondering "what if the intermediate 54 bits are non-0?
>>> should it be called a link-local address?".
>>
>> I agree with the doubt.
>>
>>> But, at least in terms of auto-generating link-local addresses,
>>> the specs are clear enough to me that these bits should be set
>>> to 0. That's why I always try to clarify the context is to
>>> auto-generate a link-local address in this conversation.
>>
>> Yes, it's clear it should be 0.  But it's not clear whether the 0s
>> are part of the plen or part of the IID.
>>
>>> If you want to further clear any possible confusion between the
>>> intermediate 54 bits, I wouldn't discourage you to write a
>>> "mystery of the intermediate 54 bits for fe80::/10" draft:-)
>>
>> I agree :-)  When I hear this I think I need to stop talking
>> because I cant write so many drafts as I write emails :-)
>>
>> But some of these things are indeed doubts there for a long time.
>>>
>>>>>> It does not forbid that that 64bit prefix be formed by
>>>>>> self-appending a 0 to a /63 from the RA, or other
>>>>>> mechanism.
>>>>>
>>>>> It's not the job of RFC2464.  RFC4862 imposes the restriction
>>>>> through its Section 5.5.3 bullet d):
>>>>
>>>> Well then, it should.
>>>>
>>>> BEcause currently RFC2464 says "An IPv6 address prefix used for
>>>> stateless autoconfiguration [ACONF] of an Ethernet interface
>>>> must have a length of 64 bits".
>>>>
>>>> If we go by your recommendation above, then it means RFC2464
>>>> must not say that.
>>>
>>> I guess we're just not on the same page...trying to rephrase my
>>> point, it doesn't matter that RFC2464 "does not forbid that that
>>>  64bit prefix be formed by self-appending a 0 to a /63 from the
>>> RA", since RFC4862 forbids it anyway (by the "sum must be 128"
>>> requirement).
>>
>> I dont understand you.
>>
>> I want to say this: RFC2464 does require the prefix len to be 64.
>>
>>
>>>>> I guess that "rt entry for that /63 prefix" is to treat the
>>>>> /63 prefix as on-link (assuming the corresponding PIO has L
>>>>> bit on).
>>>>
>>>> YEs.
>>>>
>>>>> If so, that's the correct behavior per RFC4861 (not 4862).
>>>>
>>>> So RFC4862 should not require the Host to ignore a received
>>>> non 128 plen+IID, because RFC4861 accepts it.
>>>
>>> Here I actually see conflating.  RFC4862 only says the host MUST
>>>  ignore such prefix *for SLAAC*.
>>
>> That emphasis is yours, it's not in the document.  The document
>> says it must ignore it.
>>
>>> It doesn't say, for example, it should ignore the entire RA or
>>> even for that particular PIO for other purposes than SLAAC.
>>
>> It says it must ignore the PIO.  IT does not say for what to
>> ignore it.
>>
>>> But I admit this point may be subtle and can easily be
>>> misunderstood. RFC4862 tried to clarify that subtlety a bit in
>>> the following paragraph of that section (that was actually
>>> written by me):
>>>
>>> It is the responsibility of the system administrator to ensure
>>> that the lengths of prefixes contained in Router Advertisements
>>> are consistent with the length of interface identifiers for that
>>> link type.  It should be noted, however, that this does not mean
>>> the advertised prefix length is meaningless.  In fact, the
>>> advertised length has non-trivial meaning for on-link
>>> determination in [RFC4861] where the sum of the prefix length
>>> and the interface identifier length may not be equal to 128.
>>> Thus, it should be safe to validate the advertised prefix length
>>> here, in order to detect and avoid a configuration error
>>> specifying an invalid prefix length in the context of address
>>> autoconfiguration.
>>
>> It reads reasonable.  But the other paragraph requiring to ignore
>> the PIO which is non 64 is still there.  These two paragraphs are
>> contradictory.
>>
>> One requires consistency, the other requires 64.
>>
>> We are going to write the same for IPv6 Addressing Architecture?
>> A paragraph requiring 64 and another requiring variable length?
>>
>>> but this conversation seems to suggest it's still not clear
>>> enough.
>>
>> BEcause when writing RFCs it is not by adding paragraphs that
>> things get clearer. Clarification paragraphs may be good, but
>> often removing some paragraphs can also improve clarity.
>>
>> There are readers out there, most often the programmers.  They
>> dont care about the earlier discussion involving pride and other
>> feelings.  They want consistency - things that can be easily
>> implemented.
>>
>>>> As such, either rfc4862 or rfc4861 should be modified to make
>>>> it work together.
>>>
>>> 4861 and 4862 already work together.  But, we could make it even
>>>  clearer that prefix length validation for on-link determination
>>>  (actually there's no restriction for this) and prefix length
>>> validation for SLAAC are independent, if and when we want to
>>> update these RFCs.
>>>
>>>> Maybe rfc4862 should not require the Host to refuse a received
>>>>  plen+IID not making for 128.
>>>
>>> No, it should still require that, as there's currently no defect
>>> in the spec even if it may still not be crystal clear for some.
>>> However, you have the right to propose loosening the
>>> requirement, so if you think that change is necessary, please
>>> feel free to write a draft.
>>
>> Ah this invitation.  The title reads great!  "Mistery of...".
>> Thanks, but no, not at this time :-)
>>
>>>>> It's also correct to ignore that prefix for SLAAC per RFC4862
>>>>> (not 4861).
>>>>
>>>> If some RFC requires the Host to ignore the PIO and some other
>>>> RFC requires the Host to interpret it, and both RFCs are
>>>> mandatory to implement, under the same conditions, isn't there
>>>> a conflict?
>>>
>>> No, there's no conflict, once one understands the two types
>>> validations are independent:
>>>
>>> - RFC4861 does not impose any restriction on the prefix length
>>> in PIO for on-link determination purpose (and therefore the host
>>> is expected to accept any length of prefix for on-link
>>> determination) - RFC4862 requires the host to ignore the PIO of
>>> some particular length for the purpose of SLAAC (and therefore
>>> the host is expected to not use a prefix of "invalid length" to
>>> configure an address)
>>>
>>> Both can coexist.  BSDs literally implement it.  From your
>>> previous message, I guess so does Linux.  I also suspect so do
>>> other major OS implementations such as Windows or Solaris, as
>>> this separation has been in fact one of common test cases in
>>> IPv6 protocol conformance test suites.
>>
>> Ok.
>>
>> Alex
>>
>>>
>>> -- JINMEI, Tatuya
>>>
>>
>> --------------------------------------------------------------------
>>
>>
>>
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>>
>>
>