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

Alexandre Petrescu <> Sat, 04 March 2017 12:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77A01129539 for <>; Sat, 4 Mar 2017 04:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.353
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VL-m6bJ8Jsv7 for <>; Sat, 4 Mar 2017 04:24:49 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B17CD12952C for <>; Sat, 4 Mar 2017 04:24:48 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v24COkBe001702 for <>; Sat, 4 Mar 2017 13:24:46 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 8E2D52027AD for <>; Sat, 4 Mar 2017 13:24:46 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 8501B2008E9 for <>; Sat, 4 Mar 2017 13:24:46 +0100 (CET)
Received: from [] ([]) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24COjvB026485 for <>; Sat, 4 Mar 2017 13:24:46 +0100
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
References: <> <> <> <> <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> 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 Administrative
> Requests:
> --------------------------------------------------------------------