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

David Farmer <farmer@umn.edu> Fri, 03 March 2017 05:41 UTC

Return-Path: <farmer@umn.edu>
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 860B212947C for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 21:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.8
X-Spam-Level:
X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=umn.edu
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 h5GGRkfr3Qqg for <ipv6@ietfa.amsl.com>; Thu, 2 Mar 2017 21:41:44 -0800 (PST)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AF612940A for <ipv6@ietf.org>; Thu, 2 Mar 2017 21:41:44 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 8599EC50 for <ipv6@ietf.org>; Fri, 3 Mar 2017 05:41:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zcer4-O4ee0 for <ipv6@ietf.org>; Thu, 2 Mar 2017 23:41:43 -0600 (CST)
Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 3C841C22 for <ipv6@ietf.org>; Thu, 2 Mar 2017 23:41:43 -0600 (CST)
Received: by mail-ua0-f197.google.com with SMTP id q7so33195293uaf.0 for <ipv6@ietf.org>; Thu, 02 Mar 2017 21:41:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rDIeBZIWu3+PSwaV22kBhbqIpSSc4M8KhYKH8xsrz0s=; b=O2NU99I8h5bmNagipl5H+kjXdQDoi2Z5WDfFuwde8Mej9yAgtk3Mu9PcfNdsh+Eh0w I/jYYreMt85R42FeuSxI4keA0Cya4Q+DO4lmBAl6qCgU7O0Wy95rvFyICqiskVuWokoD xMcKIe187Ed9aeJZIyhCaPvjwc+DitIv48j4q4a1FJWd8THK7vso2FHGTXFAumcuDRQF rlVGqA6yAvEWRRXqlPK8V2Ez/dKM1stJEs4Nb1J8RwUujtqp2xMcfg0Pz6FSJN1Wg7ae 67d9AspfAm9/YMt3nt8WU6CN/0J/VtDmmCmN2Po34k7dpDYmtOweSt/qppc7tJWOjklx Am6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rDIeBZIWu3+PSwaV22kBhbqIpSSc4M8KhYKH8xsrz0s=; b=M+RiUYFvMetjOP7rC/PjUkd/gtbmhKJgRcyEeSel4iazsJKIT5YyZs8CMQshHJHUSe 5UpKJXqUYtYR322HerncaOO5z1zGA38gCRgux/guDAadUFT74HC8g43fkEEkw+H2uoLY ZLMc6wbc2L17ZZVtgSVNXTCy5INoogS0e7fjsiK/imBO6YZqFCkhy+WODPBXxWc/+RFU lwfPLITIcbs7o/sz3CoE2Fw9wdKJA7bsEu0ltS4mA5mhBey5d0wLpcywokWKUmvU+Hng OV/jO3k344OZ6LcWef94ElGiQqVL8xamuibtWJgiePGcSeBmt6tXKP8gWcAhSfAEn1x/ 9YDA==
X-Gm-Message-State: AMke39k1aWCdzkY6qq9DFY5t7Eu9Xf5JaU8Gb16/E/D7w8aIEL3+r0ffBHlub4g/sN3pzQQ+I8nLKgoTrJivQ3kzXbD0m3EI1VHTI4l5k4i65DG4L4BNtQoid26diPs3uD/4PbaoPL37YuywBDQ=
X-Received: by 10.31.49.81 with SMTP id x78mr368941vkx.82.1488519702516; Thu, 02 Mar 2017 21:41:42 -0800 (PST)
X-Received: by 10.31.49.81 with SMTP id x78mr368937vkx.82.1488519702197; Thu, 02 Mar 2017 21:41:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.89.71 with HTTP; Thu, 2 Mar 2017 21:41:41 -0800 (PST)
In-Reply-To: <0128cd94732b435a9a8873501de171cf@XCH15-06-11.nw.nos.boeing.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> <2126862bab4f49f492c40639ff1b829a@XCH15-06-11.nw.nos.boeing.com> <CAN-Dau0kDKhT97yKBh3eGyaWvT-9XGHzYSV7Xn5YBbRUnmDgCA@mail.gmail.com> <0128cd94732b435a9a8873501de171cf@XCH15-06-11.nw.nos.boeing.com>
From: David Farmer <farmer@umn.edu>
Date: Thu, 2 Mar 2017 23:41:41 -0600
Message-ID: <CAN-Dau0=pvkE9cy8hUg4iw4ov3oGioHo=7wEaCgF3TJimX6-KQ@mail.gmail.com>
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Content-Type: multipart/alternative; boundary=001a114388b01753e10549cd0030
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bUVBiKwuPSS4CCPj4Gmko00XqgA>
Cc: 6man WG <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 05:41:45 -0000

On Thu, Mar 2, 2017 at 8:55 PM, Manfredi, Albert E <
albert.e.manfredi@boeing.com>; wrote:

> From: David Farmer [mailto:farmer@umn.edu]
>
> > Because, it doesn't say IIDs are themselves required.
>
> I see this as being a semantic game. As long as an address consists of a
> prefix, and it has to in order for the packet to be forwarded "the usual
> way" across routers, the remaining bits will be an ID pointing to a
> specific interface. I don’t think we are suggesting here that any prefix
> greater than 64 bits MUST result in a flat network. Or at least, I'm not.
>
> > In fact it says "at a minimum, a node may consider that unicast
> > addresses (including its own) have no internal structure".
>
> As a minimum, sure, that's always the case. A node might possibly assume
> this, as a minimum. "As a minimum" the rule can apply to any IPv6 node,
> even /64 nodes. A router, for instance, might be configured to only route
> ten 128-bit addresses, each one to a particular egress interface, and
> blindly send the rest over an 11th egress interface, for all other traffic.
> That works fine, as long as the number of 128-bit addresses doesn't grow
> too much.
>
> > And I'd now suggest it should say, if you use an IID it must be
> > 64 bits unless overridden my an IPv6-over-foo spec.
>
> But this would make "as a minimum" phrase lose all its meaning? Now it
> says that this flat routing scheme must be the only one allowable, for
> prefixes > 64. So I don’t think that's right.
>
> Bert
>

Well I'll agree it's subtle, it needs to be explained better in RFC4291bis,
and I probably haven't hit the mark yet, but it's more than just
semantics.  If I configure an interface as 2001:DB8::1/64, that is saying
that the interface has 128 bit address and a subnet length of 64 bits.
It's not saying the subnet prefix is 2001:DB8::0/64 and the IID is 1 with
an IID length of 64.

Similarly, if I configured my interface with 2001:DB8::1/120, that is
saying that the interface has 128 bit address and a subnet length of 120
bits. It's not saying the subnet prefix is 2001:DB8::0/120 and the IID is 1
with an IID length of 8.

Now I could also configure the address of an interface as 2001:DB8::1 with
no prefix length, it then should look for an RA for that link and if there
is a PIO for prefix 2001:DB8::0, and lets say it has a prefix length of 120
and with an "L" flag and no "A" flag.  In my opinion that should work and
communicate with another host on the link with an interface configured
similarly, with say 2001:DB8::2.  Furthermore, if another host on that link
had an interface configure with 2001:DB8::1001, they shouldn't communicate,
as that address isn't on link by that PIO.

And in all of those cases, 2001:DB8::1/64, 2001:DB8::1/120, or 2001:DB8::1,
2001:DB8::2, 2001:DB8::1001 with no prefix length, there is also a link
local address with an IID of length of 64 and a prefix of FE80::0/64 and
was auto generated with SLAAC.

And stateful DHCPv6 doesn't provide an IID either, it provides a full 128
bit IPv6 address, but doesn't provide a prefix length or a router, that is
learned from the RA and it's PIOs.  I agree with Randy that's another thing
to fix, but that's a fight for a different day, and completely independent
of this.

So saying that all IIDs are required to be 64 bits, doesn't actually imply
all subnet prefixes are /64.  It only says you can't generate an IPv6
address using an IID on a network with a subnet prefix other than /64, and
you probably can't (or at least shouldn't) set the "A" flag on PIO for
prefix other than /64. However, can manually configure or get an address
via DHCPv6 for subnet prefix other than /64.  This why we have to correct
RFC4291bis by recommending /64 subnet prefixes, because it's ambiguous now,
and would be much cleaner if it was clearly recommended.

Thanks.




-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================