Re: A proposal for draft-ietf-6man-rfc4291bis-07

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 04 March 2017 12:24 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 77A01129539 for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 04:24:50 -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 VL-m6bJ8Jsv7 for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 04:24:49 -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 B17CD12952C for <ipv6@ietf.org>; Sat, 4 Mar 2017 04:24:48 -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 v24COkBe001702 for <ipv6@ietf.org>; Sat, 4 Mar 2017 13:24:46 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8E2D52027AD for <ipv6@ietf.org>; Sat, 4 Mar 2017 13:24:46 +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 8501B2008E9 for <ipv6@ietf.org>; Sat, 4 Mar 2017 13:24:46 +0100 (CET)
Received: from [132.166.84.69] ([132.166.84.69]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24COjvB026485 for <ipv6@ietf.org>; Sat, 4 Mar 2017 13:24:46 +0100
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
To: ipv6@ietf.org
References: <CAN-Dau17q_BrUuzfvB1mLDt6p5UxYikphWaHpa8VQ2L-3kx-DA@mail.gmail.com> <a484b60f9d9b4fcea24dc320c550da2c@XCH15-06-11.nw.nos.boeing.com> <ee764408573b4db4b22e58c4ea5f289c@XCH15-06-11.nw.nos.boeing.com> <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <CAN-Dau0bSPiubeDOFeJAg6H0wP0ZNDS514eedmJtkOqHTXWOOw@mail.gmail.com> <D6D5B476-7F21-4F49-A81D-C2A11C30ADEC@google.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <ABE47051-FBFC-460F-89B0-FFD451410F7B@google.com> <m1cjviu-0000EYC@stereo.hq.phicoh.net> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <m1ck5mu-0000GaC@stereo.hq.phicoh.net>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b509aa0e-2ed8-aa63-e962-9f7632454895@gmail.com>
Date: Sat, 4 Mar 2017 13:24:49 +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: <m1ck5mu-0000GaC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZYCxGRAhBlvNXhqFkSkNkt8UWrQ>
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:24:50 -0000


Le 04/03/2017 à 10:15, Philip Homburg a écrit :
>> Im saying that my stack tries to comply with RFC 4862 which
>> requires that it ignore PIO options where the Prefix Length is not
>> 64 on link types that define the length of the IID as 64 bits in
>> the relevant IPv6-over-link document. My stack does that in the
>> hopes of eventually passing the IPv6 Ready certification test,
>> which Ive been through before, and, yes, it tests for that MUST In
>> RFC 4862. It tests both the requirements for processing the A flag
>> as well as the requirements for processing the L flag.
>>
>> If you send me a Prefix Length other than 64 bits, then Im gonna
>> ignore it. Just as RFC 4862 commands.
>
> I find this confusing, you are ignoring an onlink prefix because of
> auto configuration? That is IPv4 thinking. In IPv6 they are supposed
> to be decoupled.
>
> But in any case, ignoring an onlink prefix should be safe from an
> interoperability point of view.

I agree with the IPv6 facility to have many on-link prefixes.  IPv4 does
it too these days anyways.

But I do not agree with mandating there to be multiple on-link prefixes.

The fe80::/64 is there by default.

So if I add a 2001:db8:abba:abb*::/60 on some computer it will get two
different onlink prefixes with different prefix lengths.

Two is too much, because it means ND  messages for that /64.  That is
noise that can create interference.

Ideally, freedom from /64 means that I would only have that /60 prefix
on the link if that's what I mnaually added.

To realize that freedom (avoid ND noise for /64) I have to add the /60
_and_ delete the /64.

Ideally just add the /60 should be sufficient.

Alex

> Without the prefix you have to send the traffic to the default
> router, which will send redirects. So slightly less efficient but no
> big deal.
>
> What I really don't understand is that if you implement RFC 4861 (ND)
> and you get a PIO option with the A bit clear, that you would drop
> that prefix because the address configuration that you are not doing
> anyhow would not allow it.
>
> To me that seems like a completely perverse reading of RFC 4861.
> Maybe the host requirements RFC should clarify this issue.
>
> Note that this prefix could be used for DHCPv6. And even if you
> stack cannnot use those addresses for address configuration, they may
> still be onlink.
>
> Also note that RFC 4861 clearly distinguishes between onlink and
> autoconfiguration with the text: "It also assists with address
> autoconfiguration as specified in [ADDRCONF], for which there may be
>  more restrictions on the prefix length." It would be really weird
> that assume that RFC 4862 can silently update 4861 in this regard.
>
> Ah, RFC 4862 (Section 5.5.3) is even specific about this problem:
> "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.
>
> So this consistency check should only be done if the A bit is set.
> And even then, it is not clear of RFC 4862 can change behavior
> specified by RFC 4861 without explictly saying so.
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>