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

Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com> Sat, 04 March 2017 09:15 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.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 4D79C1294B5 for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 01:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 epULbmEYogSc for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 01:15:43 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3460112943C for <ipv6@ietf.org>; Sat, 4 Mar 2017 01:15:42 -0800 (PST)
Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1ck5mu-0000GaC; Sat, 4 Mar 2017 10:15:40 +0100
Message-Id: <m1ck5mu-0000GaC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
From: Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
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>
In-reply-to: Your message of "Fri, 3 Mar 2017 15:44:02 -0800 ." <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com>
Date: Sat, 04 Mar 2017 10:15:39 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/R_C25mu-kSjBtXesjGND3VPq7h0>
Cc: james woodyatt <jhw@google.com>
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 09:15:45 -0000

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