Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux

Fred Baker <fredbaker.ietf@gmail.com> Fri, 03 March 2017 22:51 UTC

Return-Path: <fredbaker.ietf@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 9A3691293DB for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 14:51:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pHwo9MddkyUA for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 14:51:20 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBC3124281 for <ipv6@ietf.org>; Fri, 3 Mar 2017 14:51:20 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id s67so48306763pgb.3 for <ipv6@ietf.org>; Fri, 03 Mar 2017 14:51:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PQaMeHQ7M/YkOLCHmIpVwojNooH1dbBjm/6LP8rPJUs=; b=EoNwyhz5lD5ExffSvcv36tZDX0y2nI4YqNgRvRXzC50YYDpn3DIo6ov0QvUHoiD4Zv D1tPMiZ/YHkKSg/u19E/5ILCO70qP41mdWl+bhKBGRXdGxm9lkzdsfseG/Koq7GzJpQJ m+gS6Dcp5sOrShm43JOYy60+Vp9qurmnK4haO5qBig9TfCcKluRdVP3AaHdQOJ55Ygur 5xts9uPWuKasqc1juRno2tf6YNRNjn3p3Z1ky8hbTu9vZqt99+qcUMYY+4B3gTMeyf8h xEqfzXCEOktNTFxF+q0+3dUC2DT5qk8t2lhpA2PyM/7Xug9EEYJY0ftHpfDcVOlH+nGj SDvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PQaMeHQ7M/YkOLCHmIpVwojNooH1dbBjm/6LP8rPJUs=; b=hT5/odNaEacpSsDsGenPuGNWxrEqUai3U8q49m1i+cfCelaH7QYGhuFulRN446wjXu hKD4Gx8N4a5TO7HIQXlEbqE2rFprsSYkgdPufGiv9HmFCV8MGFYguVcPliETtkjkXT1+ oci9uC+SGPl0+/1ERtlZcm9mfTTl2Bhu+S8aNBYKTT3BHrsiKiiHhTAbD3ZHvGSSaTsg M/LPA4X181d2IVDDTUiKjn97olkhChrs5v3wSXePDEX3z8hZc9fwovWNVbjTP3oPMy3T gIJzJVsc6951Zqx2ghM/uwPjpz32gM31RiuMWAJSHr6aQ2cg0zNovbthg2RXpyLDlGxK 8UOQ==
X-Gm-Message-State: AMke39kWYmIpFz/r3KD75ZGi1wh4wF7wvEE27aMsMZtCfBoveV5nXF4k+af7FNTptqr8jQ==
X-Received: by 10.98.134.142 with SMTP id x136mr6300952pfd.64.1488581480118; Fri, 03 Mar 2017 14:51:20 -0800 (PST)
Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id y187sm25252545pfy.123.2017.03.03.14.51.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 14:51:19 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <a630f8b8-e6ed-885a-a909-6c75dfd79892@gmail.com>
Date: Fri, 03 Mar 2017 14:51:17 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <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>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YoO2kCvuCGrPfK24_hIAx2-OsrQ>
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: Fri, 03 Mar 2017 22:51:22 -0000

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