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

"Manfredi, Albert E" <> Fri, 03 March 2017 20:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0C92129622 for <>; Fri, 3 Mar 2017 12:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4_tqrTL_zVf0 for <>; Fri, 3 Mar 2017 12:42:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B24A812961E for <>; Fri, 3 Mar 2017 12:42:44 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v23Kgi5V065031; Fri, 3 Mar 2017 13:42:44 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v23KgYx3064958 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 3 Mar 2017 13:42:34 -0700
Received: from (2002:8988:efdc::8988:efdc) by (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Mar 2017 12:42:34 -0800
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Fri, 3 Mar 2017 12:42:34 -0800
From: "Manfredi, Albert E" <>
To: james woodyatt <>, 6man WG <>
Subject: RE: A proposal for draft-ietf-6man-rfc4291bis-07
Thread-Topic: A proposal for draft-ietf-6man-rfc4291bis-07
Thread-Index: AQHSlFBZc0GC3/s6VkejKSh9uOtZ66GDjGtw
Date: Fri, 3 Mar 2017 20:42:34 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
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: Fri, 03 Mar 2017 20:42:46 -0000

From: ipv6 [] On Behalf Of james woodyatt

> 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]. [*]

I'm okay with saying that SLAAC should by default assume 64-bit IIDs, at least over Ethernet and some other link layers, in today's reality.

> 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

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

Okay, nothing here suggests that 64-bit IIDs should be mandatory. Matter of fact, RFC 4862 says explicitly,

      Note that a future revision of the address architecture [RFC4291]
      and a future link-type-specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers.

And we are just now discussing such an RFC 4291 rev. Says quite clearly here to not assume 64 bit IID to be a constant.

> 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 interpret that to say that global addresses should not ONLY be assigned with DHCPv6. There should also be a SLAAC option and/or, presumably, static configuration. That comment does not make a case for mandating 64-bit IIDs. Only if SLAAC uses 64-bit IIDs would the SLAAC-generated global addresses necessarily use 64-bit IIDs. RAs could be advertising prefixes > 64, which may be used with IIDs < 64 assigned by DHCPv6, or potentially also with a non-64-bit IID SLAAC?

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

I don't this this implied. Plus, RFC 4862 is only about SLAAC.