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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 06 March 2017 20:47 UTC

Return-Path: <alexandre.petrescu@gmail.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 024C8129A0D for <ipv6@ietfa.amsl.com>; Mon, 6 Mar 2017 12:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level:
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 m9cJs0027pMp for <ipv6@ietfa.amsl.com>; Mon, 6 Mar 2017 12:47:02 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37924129A07 for <ipv6@ietf.org>; Mon, 6 Mar 2017 12:47:02 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v26KkxPg023065 for <ipv6@ietf.org>; Mon, 6 Mar 2017 21:46:59 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E4E5A20A337 for <ipv6@ietf.org>; Mon, 6 Mar 2017 21:46:59 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DB3EA20A221 for <ipv6@ietf.org>; Mon, 6 Mar 2017 21:46:59 +0100 (CET)
Received: from [132.166.84.158] ([132.166.84.158]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v26Kkw9t030262 for <ipv6@ietf.org>; Mon, 6 Mar 2017 21:46:59 +0100
Subject: Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07
To: ipv6@ietf.org
References: <CAN-Dau3BOVo3UhyGEdxKR-YgqpLqJVxV7uswCCXFsaQoKRaKHw@mail.gmail.com> <CAKD1Yr2UFnVyFptyLD5EqchLNWJyGhoBk2RKNavP1Gc2_zSUVw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <e8b5d239-e6d1-9996-12ab-96729763ab9b@gmail.com>
Date: Mon, 6 Mar 2017 21:47:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr2UFnVyFptyLD5EqchLNWJyGhoBk2RKNavP1Gc2_zSUVw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lEOJoaWmTzv1HzEv3JkEp_Ai8lA>
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 20:47:05 -0000

agreed with some of the things that I cut but I have one question.

Le 06/03/2017 à 19:46, Lorenzo Colitti a écrit :
> If we allow the boundary to change, there is a near certainty that
> too-small subnets *will* be configured in some places,

and is IETF a place to make recommendations of making big or small
subnets?  Isnt it for the RIRs to make such recommendations?

I mean RIRs decide what to allocate, when there is shortage or not.

But with 64 you seem to be wanting to keep a limit there in order to be
able to unlimit later, or something like that, right?

Alex

> and over time, host software will adapt to the lowest common
> denominator. There is a very real risk end up with solutions that
> "mostly work most of the time" - things like NAT traversal, and NAT
> keepalives - over more robust solutions that rely on strong
> guarantees from the network layer. The risk is that the IPv6 Internet
> will be constrained by IPv4 address scarcity even after IPv4 is
> gone.
>
> It's up to us to avoid that risk. I continue to be amazed by the
> people on this thread who are advocating that we run it.
>
> On Tue, Mar 7, 2017 at 3:06 AM, David Farmer <farmer@umn.edu
> <mailto:farmer@umn.edu>> wrote:
>
> 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 classful! 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
> places
>
> 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 [BCP198].
>
> 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
> [RFC7421].
>
> 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
>  [RFC3587].
>
> 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].
>
> Thanks
>
> -- =============================================== David Farmer
> Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu> Networking &
> Telecommunication Services Office of Information Technology
> University of Minnesota 2218 University Ave SE        Phone:
> 612-626-0815 <tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell:
> 612-812-9952 <tel:(612)%20812-9952>
> ===============================================
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
>
>
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>