A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07

David Farmer <farmer@umn.edu> Mon, 06 March 2017 18:06 UTC

Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 48E1712957D for <ipv6@ietfa.amsl.com>; Mon, 6 Mar 2017 10:06:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Status: No, score=-3.801 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] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xnSdJ_kvgNaZ for <ipv6@ietfa.amsl.com>; Mon, 6 Mar 2017 10:06:34 -0800 (PST)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu []) (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 16EC41294FA for <ipv6@ietf.org>; Mon, 6 Mar 2017 10:06:34 -0800 (PST)
Received: from localhost (unknown []) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 96CE469F for <ipv6@ietf.org>; Mon, 6 Mar 2017 18:06:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([]) by localhost (mta-p5.oit.umn.edu []) (amavisd-new, port 10024) with ESMTP id kF-08WaJOy31 for <ipv6@ietf.org>; Mon, 6 Mar 2017 12:06:33 -0600 (CST)
Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com []) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 450A6603 for <ipv6@ietf.org>; Mon, 6 Mar 2017 12:06:33 -0600 (CST)
Received: by mail-ua0-f198.google.com with SMTP id 62so52227274uas.1 for <ipv6@ietf.org>; Mon, 06 Mar 2017 10:06:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to; bh=cVZFF9NR4V4uhcQwv7Ge40omrJVYCqmUhY7TWDaZqcQ=; b=Mv2gv7NUO15VGanSYarUnLPvKp1vSblje0trY9xGAnzLaTEYG9IqRtTtHkdyI92RDe FWxsYWY6PzYQJM9o7QE71eCEQsK9GmfJ8AUVXFIfwB+HJ4Rct5oCD5vxEOoPrTMyAhNL gOCWupowwJO+HOy3KXUTnWVof9FbIo2XKViq77DTZ03tL+t4aMX3YeMnJGEO7aC0jByZ LhjuJQjbLTmiF28bPgQmJAJjhswHeJVbC+DB7aDyR2xQquwKRqaieoxSoEARzDpRSK/L lUHn+9lH2SIiTBOcPubgcS2dqOhQyHIJzzkNM7bk9xU2z3G8SSZxhTGpTO19kSZl7BzM +ceA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cVZFF9NR4V4uhcQwv7Ge40omrJVYCqmUhY7TWDaZqcQ=; b=O3w4CxV+8et+f8MjKiL1MVrHIqwa767tx2x9njpkanIKHI7MTy6DQiP4gG1IyTTz/r PDMoudiIysK1OVHLpu2AS0314bttzzeZQNbr7kHN26vb7VVeCFwMZEkh0/7KBoQcyIaN 8lazzLearcPcEh4XdwQ+4b58meiW8Zh9zFQV8Nac5o6ylKhsQd/77+C8AVI8791+fg77 XPs0SQaOiMoqTWoyJLvwFYth3GsF6NKuga4YXPjTTzaRtzaMzc0VbuXQtxqPzbIm7J0h bT2VvigD7Kyu3+PP3ydmgVzMfvlKX53UzwieLNIqvT9Z0SPcpIVdYMDBQTCi5sMH/LLc 6ENw==
X-Gm-Message-State: AMke39kw1XhPl1kH7BrmXTruznInPKgGonqwYi9PygGb6PVR53nFb5aJE6QAm63f8DcBiycTN/CaKRCEaFMmptcKKt/pmgkPgE5P5wlVErU9E/8V5sVkQUy95U5xtLI0ZX8oaF5gkW6DqfMTU7s=
X-Received: by with SMTP id e8mr8261290uae.108.1488823592360; Mon, 06 Mar 2017 10:06:32 -0800 (PST)
X-Received: by with SMTP id e8mr8261271uae.108.1488823591995; Mon, 06 Mar 2017 10:06:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Mar 2017 10:06:31 -0800 (PST)
From: David Farmer <farmer@umn.edu>
Date: Mon, 06 Mar 2017 12:06:31 -0600
Message-ID: <CAN-Dau3BOVo3UhyGEdxKR-YgqpLqJVxV7uswCCXFsaQoKRaKHw@mail.gmail.com>
Subject: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07
To: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c12487455a16f054a13c1ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ni3riWR23H92QR-YjkEDl0i9n8A>
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: Mon, 06 Mar 2017 18:06:36 -0000

A few more tweaks, corrections and other changes some based on feed back;

1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608], AKA not
2. SLAAC is commonly used to generate unicast addresses, therefore subnet
prefixes and IIDs are 64 bits for most address.
3. Explicitly allow subnet prefix lengths other than 64 bits for manually
config and DHCPv6 while still recommending 64 bits (most code does this now
and has since the beginning)
4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by an
IPv6-over-foo doc  (we really can't change 64 bit IIDs for SLAAC, it would
break running code, at least not right now, maybe in the future)
5. Sites should get more than a single /64 [BCP157]/[RFC6177], and sites
include mobile
6. Avoid other explicit exceptions or recommendations for longer prefixes,
like RFC6164
7. include references to [BCP204]/[RFC7934] and [RFC6052] in the right

In the current draft, remove the 2nd paragraph of 2.4, then add the
following sentence to the end of the first paragraph of 2.4;

   Furthermore, IPv6 unicast routing is based on prefixes of any length up
to 128 bits

Then add the following two paragraphs at the end of section 2.4;

   Stateless Address Autoconfiguration(SLAAC)[RFC4862] is commonly used
   to automatically create unicast addresses, therefore most unicast
   addresses have 64-bit subnet prefixes and 64-bit interface IDs. The
   rationale for the 64-bit boundary in IPv6 addresses can be found in

   Nevertheless, unicast addresses may also be provided from a node's
   internal configuration (AKA manual or static configuration) or via
   Dynamic Host Configuration Protocol version 6(DHCPv6)[RFC3315]. Such
   addresses are assumed to be opaque 128-bit strings without any
   internal structure. These addresses may be associated with subnet
   prefixes of any length, while 64-bit subnet prefixes are recommended.

Then replace the 4th paragraph of 2.4.1 with;

   When unicast addresses are automatically created from a subnet prefix
   and a interface ID (e.g. Stateless Address Autoconfiguration(SLAAC)
   [RFC4862]), a 64-bit interface ID length is required. An "IPv6 over
   <link>" specification may modify this requirement for a specific link
   type. The rationale for the 64-bit boundary in IPv6 addresses can be
   found in [RFC7421].

And replace 2.4.4 with;

   The general format for IPv6 Global Unicast addresses is as follows:

   |         n bits         |   m bits  |       128-n-m bits         |
   | global routing prefix  | subnet ID |       interface ID         |

   where the global routing prefix is a (typically hierarchically-
   structured) value assigned to a site (a cluster of subnets/links in
   a location or mobile), the subnet ID is an identifier of a link
   within the site, and the interface ID is as defined in Section 2.4.1.

   As noted in Section 2.4, most unicast addresses, including Global
   Unicast addresses, have 64-bit interface IDs (i.e., n + m = 64).

   As discussed in [BCP 157], "it should be easy for an end site to
   obtain address space to number multiple subnets (i.e., a block larger
   than a single /64)" or in other words the subnet ID length should be
   greater than or equal to 1 (i.e., m >= 1). Subnet ID lengths of 4, 8,
   12, and 16 bits, and therefore global routing prefix lengths of 60,
   56, 52, and 48 bits respectively, are in common use and recommended.

   Dynamic Host Configuration Protocol version 6 - Prefix Delegation
   (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution of
   global routing prefixes to sites.

   Global Unicast addresses, and their format, are discussed further in

A couple other quickies;

Insert new paragraph at the end of 2.1

   [BCP 204] recommends that networks provide general-purpose nodes with
   multiple global IPv6 addresses per interface when they attach to a
   link, it also describes the benefits of and the options for doing so.

Insert new sentence at the end of 2.4.5

   Additional IPv6 address that carry an IPv4 address are defined in IPv6
   Addressing of IPv4/IPv6 Translators [RFC6052].


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>