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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 03 March 2017 21: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 09C3612896F for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 13:09:49 -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 FrYHYAZq-HGF for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 13:09:47 -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 CA8341294AE for <ipv6@ietf.org>; Fri, 3 Mar 2017 13:09:46 -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 v23L9hBT028188; Fri, 3 Mar 2017 22:09:43 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D160920D852; Fri, 3 Mar 2017 22:09:43 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C385B20D7ED; Fri, 3 Mar 2017 22:09:43 +0100 (CET)
Received: from [132.166.84.88] ([132.166.84.88]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23L9hYu029375; Fri, 3 Mar 2017 22:09:43 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
References: <20170223134026.GI5069@gir.theapt.org> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <de4988be-6031-08d9-84ce-21c3fa4f9bc9@gmail.com> <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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com>
Date: Fri, 3 Mar 2017 22:09:47 +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: <CAJE_bqcOLSK061p_biSD3GK1y464Ld=8Zp3-hAuJqQ2R2t3JRw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/aezrm2LvVRgmFVMRpC6Wh7kugws>
Cc: IPv6 IPv6 List <ipv6@ietf.org>
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 21:09:49 -0000


Le 03/03/2017 à 20:03, 神明達哉 a écrit :
> At Thu, 2 Mar 2017 13:36:44 +0100, Alexandre Petrescu
> <alexandre.petrescu@gmail.com>; wrote:
>
>> Yes, the IP-over-Eth RFC2464 mandates "An IPv6 address prefix used
>>  for stateless autoconfiguration [ACONF] of an Ethernet interface
>> must have a length of 64 bits".
>>
>> It does not say which prefix of [ACONF/RFC2462] must be /64?  Is it
>> a global prefix in RA?  Or is it the link-local prefix?  Both these
>> prefixes are relevant for the above phrase, both are mentioned in
>> ACONF, yet only one is present in RA (the one linux complains about
>> when at 65).  Is the mandate cited above applying to the prefix in
>> RA?  Or to the link-local prefix?  If the mandate applies to the
>> prefix in RA then
>
> 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?

>> linux is right to complain, on Ethernet.  If the mandate applies
>> only to the LL prefix, then linux is wrong to complain about 65 in
>>  RA.  If the mandate applies to both then RFC4291 is wrong when it
>>  says fe80::/10.
>
> Like in my previous message, I don't know what "it says fe80::/10"
> in this context.  I also don't know implementation details of the
> Linux kernel either, but the BSD implementation uses:
>
> - 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.

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

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

>> RFC2464 does not say "the prefix in an RA on Ethernet MUST be 64".
>
> That's fine.  The only thing this RFC is expected to say is the
> length of IIDs.

Well, let's clarify: the RFC2464 does say too that the prefix length
should be.  It does say it must be 64.

> RFC4862 defines how we use the IID to (auto)configure addresses. And
>  RFC4862 applies it to both link-local and global.

Yes.

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

> If the sum of the prefix length and interface identifier length does
>  not equal 128 bits, the Prefix Information option MUST be ignored.

YEs, that's what RFC4862 says, and I agree.

>> Besides, RFC4862 (successor to 2462) says "If the sum of the
>> prefix length and interface identifier length does not equal 128
>> bits, the Prefix Information option MUST be ignored." And linux
>> does _not_ ignore a /63 in the RA: it adds a rt entry for that /63
>> prefix. That's not normal either.
>
> I suspect you're probably conflating SLAAC with on-link prefix
> determination.

I dont conflate.

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

As such, either rfc4862 or rfc4861 should be modified to make it work
together.  Maybe rfc4862 should not require the Host to refuse a
received plen+IID not making for 128.


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

> Nothing wrong here.

That is your view, and I respect it.

Alex

>
> -- JINMEI, Tatuya
>