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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 04 March 2017 12:33 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 9ED351294F0 for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 04:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xHIwByY7la-Y for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 04:33:06 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF0F1294A1 for <ipv6@ietf.org>; Sat, 4 Mar 2017 04:33:05 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v24CX2oZ003496; Sat, 4 Mar 2017 13:33:02 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A1F1E203EA6; Sat, 4 Mar 2017 13:33:02 +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 92285201037; Sat, 4 Mar 2017 13:33:02 +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 v24CX1bQ004508; Sat, 4 Mar 2017 13:33:01 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes - DOI
To: Fred Baker <fredbaker.ietf@gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <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> <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <1693b650-f79b-e569-be94-2bcb8d9af522@gmail.com>
Date: Sat, 4 Mar 2017 13:33:05 +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: <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MR0aHmKja5epv52CpLPFjh2lJog>
Cc: IPv6 IPv6 List <ipv6@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <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:33:08 -0000

This proposal has now a DOI: 10.13140/RG.2.2.30828.36484

Alex

Le 04/03/2017 à 13:09, Alexandre Petrescu a écrit :
> 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
>>> --------------------------------------------------------------------
>>
>>>
>>>
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------