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

james woodyatt <jhw@google.com> Fri, 03 March 2017 19:00 UTC

Return-Path: <jhw@google.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 B04FB129974 for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 11:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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=google.com
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 YvNahY33xkRP for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 10:59:59 -0800 (PST)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7103812998A for <ipv6@ietf.org>; Fri, 3 Mar 2017 10:59:59 -0800 (PST)
Received: by mail-pg0-x22c.google.com with SMTP id 25so46752093pgy.0 for <ipv6@ietf.org>; Fri, 03 Mar 2017 10:59:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=rh1du2htLNPL7vZ08JjsMI3n2XTuOI7GLjqCrpEgvT8=; b=eSY1s1vZauQJhio3827/7VifmTbFfSc/DjErokVGTaBC17pr7lzVMj9NYszttN4nKF 7wKY0B17Kehq3KBK0Mgt8yuyePWHQwYhfiIOf0gMC+RIyypbOe4n0lZdWMdtPHKOTuuJ 2CyjO7hUGznFLJhB0plROj4a9Hq8Vwk2UeDl9oG1rP14nvHQQR3XxYIij9TuW/+cdN9C S5lLfI2lntugh3FBRkBqy0iBXGriau5rlrFRqHunl3WqGFxCoBTbBBDU/D/8ivP0gm/c qbXR9X49Hk00pK0e+hZFNr81t27OQN0qDp8D5xBD6LZ0hCtpN6ZE9EYBKJfHciERcdBk f2Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=rh1du2htLNPL7vZ08JjsMI3n2XTuOI7GLjqCrpEgvT8=; b=VCLWVxYBayvgL1WrbO4uzovoE9t8DQ6eSsFI/nzoBmfsPvxEqNQWoi0L6aSFU2CXhb AZQFEhvbZtm4gtLo6C6gwK1NMLRn5zR5n5P4N0PlWzdnAs8ZvZTiLq9/EKBsJLNNns7F KkJPmBf7h6Yru6+6UgFP6G4i56Rn0uDpqrGqU66R3MCWXbCgf/eRGzWHIqevfCDvDPyA IHAvezSWpAN8jP5Va9HpgJOEk+hrgHFY+3XXs45okzlyL1ZVDP2+sZ9Vz7Gakh7XwWO9 CX7cyGwWxx7EFsyicqk88gnwtrpS8VPxI/vcgIpeA1rfcXNtGKYZH0rGk99bB516Q28W HoPg==
X-Gm-Message-State: AMke39ma21OK8blkqWA1pbLcWg9E6b4T7i4NBThbkytJfz7/e5P3oTyXMSNgAdCd1to8/wHc
X-Received: by 10.98.9.14 with SMTP id e14mr5201499pfd.117.1488567598757; Fri, 03 Mar 2017 10:59:58 -0800 (PST)
Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id a90sm4344223pfg.78.2017.03.03.10.59.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 10:59:57 -0800 (PST)
From: james woodyatt <jhw@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7569BCFD-F142-4B94-89A3-D9B37C283E45"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
Date: Fri, 3 Mar 2017 10:59:56 -0800
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>
To: David Farmer <farmer@umn.edu>, 6man WG <ipv6@ietf.org>
In-Reply-To: <CAN-Dau0bSPiubeDOFeJAg6H0wP0ZNDS514eedmJtkOqHTXWOOw@mail.gmail.com>
Message-Id: <D6D5B476-7F21-4F49-A81D-C2A11C30ADEC@google.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YMjHRHbAiwkcJX-icwQeScbqQGM>
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 19:00:00 -0000

On Mar 2, 2017, at 17:55, David Farmer <farmer@umn.edu>; wrote:
> On Thu, Mar 2, 2017 at 7:29 PM, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> On 03/03/2017 13:34, Manfredi, Albert E wrote:
> > From: ipv6 [mailto:ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>] On Behalf Of David Farmer
> >
> >> 3. IIDs are REQUIRED to be 64 bits
> >
> > I think that RFC 4291 bis should not retain a constraint that has been applied so far, out of convenience, in the earliest stages of IPv6 deployment.
> 
> Agreed. And I think there are actually two things to say here:
> 
> 3.1. Any IPv6-over-foo spec must specify a recommended IID length.
> 3.2. In the absence of such a spec, the recommended IID length is 64 bits.
> 
> Again, that breaks no running code, and it respects the architectural
> statement that prefix_length + IID_length == 128, and the use of CIDR
> routing and variable-length subnet masks.
> 
>     Brian
> 
> I'd be fine with that, but others seem to feel otherwise. Lorenzo and James?

I’m not sure my response to this is necessary, but since it was invited…

p1. For consistency with IPv6 Stateless Address Autoconfiguration [RFC 4862], I don’t think it’s a good idea to require IPv6-over-foo documents to specify IID length. Okay to state that they MAY do so, but not that they MUST do so, and if they don’t then the length is 64 bits, citing [RFC 7421]. [*]

p2. Section 5.5.3 Router Advertisement Processing in RFC 4862 discusses at length how to process the Prefix Information Option (PIO) in Router Advertisement (RA) messages. Some details relevant to this discussion:

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

  B. "The length of the interface identifier is
      defined in a separate link-type specific document, which should
      also be consistent with the address architecture [RFC4291] (see Section 2).

  C. "It is the responsibility of the system administrator to ensure
      that the lengths of prefixes contained in Router Advertisements
      are consistent with the length of interface identifiers for that
      link type. It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  […]
      [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.”

p3. There is another relevant point observed in Section 3 Design Goals of RFC 4862:

  A. "A large site with multiple networks and routers should not require
      the presence of a DHCPv6 server for address configuration.  In
      order to generate global addresses, hosts must determine the
      prefixes that identify the subnets to which they attach.  Routers
      generate periodic Router Advertisements that include options
      listing the set of active prefixes on a link."

I think this is a pretty clear statement to general purpose host operating system developers that Prefix Length advertised in PIO options, even those with zero for both A and L flags, are required to be 64 bits on all the typical link types in general use today and for the foreseeable future, because the IID for those links is specified to be 64 bits. Give us a new link type with a 32 bit IID, and we would then require all the PIO to have plen=96.

At the risk of being excessively repetitive, I will again say that I think it’s important to say that subnet prefixes for networks intended to connect general purpose hosts to the Internet are always 64 bits in length, and they should be 64 bits in length for all other subnets except where expressly recommended otherwise by IETF standards actions (including IPv6-over-foo specifications). I think that’s a shorter way of expressing all that stuff above.

—

[*] As an example, consider the case of IPv6 Over IEEE 802.15.4 [RFC4944]. For some reason, it was carefully written not to specify a limitation on the length of the IID except for use with stateless autoconfiguration, which expressly limits the IID to exactly 64 bits. It then proceeds to define the LOWPAN_HC1 common compressed header encoding, which allows for address compression provided that either A) the IID is derived accordingly from one of the two possible forms of IEEE 802.15.4 address it recognizes, or B) the subnet prefix is exactly 64 bits. These compression methods apply regardless of whether SLAAC is used or not. This gets even more squirrelly in [RFC6282] where LOWPAN_IPHC provides compression for addresses with a 64-bit IID derived from either the EUI-64 address or the IEEE 802.15.4 “short” 16-bit address.

--james woodyatt <jhw@google.com <mailto:jhw@google.com>>