Re: [v6ops] Comments on <draft-horley-v6ops-lab>

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 30 July 2021 07:53 UTC

Return-Path: <prvs=1845a4b268=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE3A3A20C3 for <v6ops@ietfa.amsl.com>; Fri, 30 Jul 2021 00:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MILLION_HUNDRED=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 L73Ox5JVP56z for <v6ops@ietfa.amsl.com>; Fri, 30 Jul 2021 00:53:10 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 037DF3A20C0 for <v6ops@ietf.org>; Fri, 30 Jul 2021 00:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1627631587; x=1628236387; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=nViEXXRS l9Hlm1N7jQSw/Ac7rsbeOXJ1OeAH/A6w7g8=; b=aGw+xOypaQMMOzlRAVtRHlSp 13y3iEtAVz83dc9O0uTrTNC65rmhtj2OT7BZhNlIxsj0CyHZOA2bKYY18OOL2VND usfUiQ/GxfsjtJP5h1OhPU0N4q53l8xDBJKcOhbzuNr436igYJGTCmUp98Q+4lrB 9HnikG37BMrP88Lzk8c=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 30 Jul 2021 09:53:07 +0200
X-Spam-Processed: mail.consulintel.es, Fri, 30 Jul 2021 09:53:06 +0200
Received: from [10.10.10.145] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000650465.msg for <v6ops@ietf.org>; Fri, 30 Jul 2021 09:53:05 +0200
X-MDRemoteIP: 2001:470:1f09:495:b97a:2911:f3a2:25f7
X-MDHelo: [10.10.10.145]
X-MDArrival-Date: Fri, 30 Jul 2021 09:53:05 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1845a4b268=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/16.51.21071101
Date: Fri, 30 Jul 2021 09:53:02 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IPv6 Operations <v6ops@ietf.org>
Message-ID: <9D17704B-7D4A-4C11-985B-773682427E97@consulintel.es>
Thread-Topic: [v6ops] Comments on <draft-horley-v6ops-lab>
References: <A8C22862-FC85-458B-8AF0-4E3A5DA7680F@gmail.com>
In-Reply-To: <A8C22862-FC85-458B-8AF0-4E3A5DA7680F@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Knq_BxtVp3EjO5BsKPTvg98XwKE>
Subject: Re: [v6ops] Comments on <draft-horley-v6ops-lab>
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2021 07:53:15 -0000

I fully agree. There is no need for draft-horley-v6ops-lab neither draft-horley-v6ops-expand-doc.

I've been doing trainings and labs about IPv6 since 2001 and already trained over 75.000 engineers, probably a bit more. I don't recall any of the participants on the trainings or other consultancy and deployment activities to have been confused with just the 2001:db8::/32 prefix, even if the real situation for their own case was a bigger allocation. They were smart to figure out the equivalence and in fact, forcing them to use that helped in better understanding how IPv6 addressing works.

I've trained and consulted people designing networks that required from the RIR allocations close to /24. Always have been able to do any kind of address planning and lab exercises using what we have standardized up to now.

I'm not saying I can't be convinced about an additional documentation prefix or something similar, but not at the scale depicted in those documents.

Note that I'm for doing a good/balanced usage of IPv6 addressing space, and that includes that every subscriber, even residential should get a /48 by default. However, I'm also for a good balancing of real needs. So not being ultra-conservationist, but avoiding unnecesary waste.

Regards,
Jordi
@jordipalet
 
 

El 30/7/21 5:12, "v6ops en nombre de Bob Hinden" <v6ops-bounces@ietf.org en nombre de bob.hinden@gmail.com> escribió:

    Hi,

    I commented at todays V6OPS meeting on <draft-horley-v6ops-lab-01>.  The presentation was:

    https://datatracker.ietf.org/meeting/111/materials/slides-111-v6ops-ipv6-lab-prefix-draft-00

    I have now read the draft and the email thread.   My comments are not significantly different from what I read in email, but I will put them in my own words by topic.

    Size of Allocation:

    Reserving a /7 (specifically 0200::/7) is very very large amount of address to be dedicated to “Lab Use”.

    A /7 is 2^^121, or 2.6584559915698×10^36 addresses.  In words:

    Eighteen quadrillion fourteen trillion three hundred ninety-eight billion five hundred nine million four hundred eighty-one thousand nine hundred eighty-four addresses.

    With some sarcasm, how big is this lab going to be?

    This would allow for 2^57 /64 prefixes, that is 144,115,188,075,855,872 prefixes.   Is your lab going to have that many prefixes?

    This proposal seems like a waste of address space to me.   The main purpose of IPv6 was to create a larger Internet, allocating this much space for “lab use” seems very excessive.   We won’t end up with much bigger Internet, if we aren’t careful with how we allocate the address space.

    I note for comparison that the original intent for this prefix was to accommodate the whole ISO CLNP Internet.

    Global Filtering:

    The draft says that this prefix should be added the list of non-routable prefixes.  I note that this means that every ISP in the world would need to do this.    That’s a big ask and may not actually happen operationally.

    Unintended Consequences:

    As noted on the email thread, this is going to have the unintended consequences of recreating a private IPv6 address space.  The IETF has gone to a lot of trouble to not have private address in IPv6.   The original design has Site Local addresses.  These were deprecated, for very good reason described in RFC 3879.

    The draft call out that the allocated prefix should be declared “non-routeable” and be added to packet filters.   Exactly what would be needed to recreate a new form of Site-Local addresses.

    Unique Local Addresses (ULA):

    The draft describes about why it can’t use ULA addresses.   The ULA prefix also happens to be a /7 and can support the same number of prefixes as what is proposed in the draft.

    Regarding special handling of ULA in source address selection.   That is default behavior that can be changed. It’s also not clear that the old NSAP prefix (0200::/7) will not have a similar or different set of issues, given it is currently reserved and not in the address blocks that are currently allocated for global unicast.

    I strongly that ways can be found to use ULAs to meet the requirements of the “lab use” proposal.   For example, if you need n prefixes, run the algorithm n times and get that number of random prefixes.   Each prefix has have 16-bits for a Subnet ID, that can used to prefix aggregation.   None of this requires any change of standards, allocations, or additional global filtering.


    I think that if you want something beyond what ULAs can accommodate (and can demonstrate a need), you will need to describe that in a lot more detail than what is in the current version of the draft.  I don’t see anything in the draft that justifies an address allocation of this size for “lab use”.

    Bob

    p.s. Thanks for the acknowledgement to Steve Deering and myself in the draft, it is nice, but many people have contributed to IPv6.   This section would be best to list people who have helped with this draft.



    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.