Re: [IPv6] Variable IIDs

Mark Smith <markzzzsmith@gmail.com> Sun, 05 November 2023 04:20 UTC

Return-Path: <markzzzsmith@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 7279BC151062 for <ipv6@ietfa.amsl.com>; Sat, 4 Nov 2023 21:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.603
X-Spam-Level:
X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKA9raK_jXjQ for <ipv6@ietfa.amsl.com>; Sat, 4 Nov 2023 21:20:57 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D04AC15152B for <ipv6@ietf.org>; Sat, 4 Nov 2023 21:20:57 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-9db6cf8309cso468622866b.0 for <ipv6@ietf.org>; Sat, 04 Nov 2023 21:20:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699158056; x=1699762856; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Lyn43EGM7+Xp1y6MlHEk3WF+sRfTNeiffjj0mBE7Qhg=; b=h+Y4N3wUmCIKIMKQdaKiF6hqkSLamAc4PAijGhwDjxOxPu9MoppQv2SOPduWIFv1FF qdcTVzZna3cQFD7asQRSyRuKF9nicL9TFAUw2EmJDWOwdtAmO5bbCqlHGzOnoq4cFANA B3dETYPL8Yn/9qDM3luZwjiS1VXyzte007FN0Ht4mr/VZGit7Xcai6FmFjmBHT5kQIqv 8XvzD3Rbj0ieKdCBfHBPLa5nm9yb+CtBcKVKvubHHHJIpphkn2xRWMzeGfkxkTKeURTx cFcZiiLm/+/E3zm6UBOqFkShKsNPwgmTfbQn12OcBGcd2TYEuUL5R34t1da7jdfcnamW 0HRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699158056; x=1699762856; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Lyn43EGM7+Xp1y6MlHEk3WF+sRfTNeiffjj0mBE7Qhg=; b=LWJ6YbCvp17K280Ly8LJOU7Ptvy5ASNZXH4yQEoyAXft5E/s/CaYINbBxroyrFsr/F oBB7c/yC21eC16DTq9JXSm2Hc+Z4iKM5A4Y0C3Td4I0iviqYnv0IaVJDij7r35qeL+lI y5UB0GENCyYd8mcMuzrJC5z7s7I2z7KrATqVyXWi3XeF4vjL2bEZ03HoeypljzuwN0c8 VkfjL+kjoM+x9O1icEaX4CfmOjixwdLEioxGnSM8TpXkSfcb64fSIlkNCDjXlJYY0ONA OqfVqfp/2EKBWMmPUE3AqwKyI7sCBQbLtYxr8n6ZCgbW/SCUo/WDNGntvxOf49JMd+H3 jPQw==
X-Gm-Message-State: AOJu0YzLkCLOOuKav7KH+74mzHA6nMYiQeIW5t7a1e7bCYIm0FiNvMxF HKGBXi++tkMhsUri0oeEgJfhEIjUrhfVbZqG+tDZnH10
X-Google-Smtp-Source: AGHT+IFHH+cNABLfKdepCUSHmdV+WMQ4vPHREhPz2D5i1adGp3Cc3sIE+JnP6sbrmDo/p5XtFqN2T0S4YfBM7HBOr2s=
X-Received: by 2002:a17:907:7f89:b0:9ae:73ca:bbad with SMTP id qk9-20020a1709077f8900b009ae73cabbadmr11361111ejc.43.1699158055805; Sat, 04 Nov 2023 21:20:55 -0700 (PDT)
MIME-Version: 1.0
References: <d935987f-7550-855a-c57f-7f8c2fc6e5cf@gmail.com>
In-Reply-To: <d935987f-7550-855a-c57f-7f8c2fc6e5cf@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 05 Nov 2023 15:20:44 +1100
Message-ID: <CAO42Z2wny-UVBrzNyraxmcHAy_pczmx5hY=AinxXpNH1vZTsFg@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000556543060960102e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_LBJJPky8JrEW1QiuHLOyJZqoaI>
Subject: Re: [IPv6] Variable IIDs
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 05 Nov 2023 04:20:58 -0000

Hi,

What problem is this trying to solve? Is the IPv6 address space running out?


IPv4's original address format was nice and simple - N.H.H.H - see RFC 760.

Network numbers were running out, so IPv4 address classes were introduced
in RFC 791.

Then classes weren't efficient enough (for some people Class C was too
small yet Class B was too big) so subnets were introduced in RFC 950.

Then VLSM, and then CIDR.

When you've had to teach IPv4 addressing enough times, and all of the above
complexity, the struggle to explain it, and the struggle for people to get
it right, you eventually ask the question, "Why is this so complex?" and
"Why would anybody design something so complex on purpose?"

Well they didn't, as can be seen from RFC 760 and its ancestors. Classes,
subnets, VLSM and CIDR are all work arounds to the original RFC 760 N.H.H.H
format not being big enough.


So if variable length subnets/IIDs are now required in IPv6, is that saying
we're at a similar point of IPv6 address space exhaustion that occurred
between RFC 760 and RFC 791 for IPv4, and we now have to introduce similar
addressing complexity into IPv6 addresses to conserve them?

Regards,
Mark.


On Sat, 4 Nov 2023, 13:06 Brian E Carpenter, <brian.e.carpenter@gmail.com>
wrote:

> If anyone wants to turn this into an I-D, please feel free.
>
> title: Variable Length Interface Identifiers
> abbrev: Variable IIDs
> docname: draft-tbd-6man-variable-iids-00
>
> # Introduction
>
> The lowest common denominator method of configuration for IPv6 nodes is
> SLAAC {{!RFC4862}}, which is carefully designed to allow any prefix length
> and any interface identifier (IID) length, provided that they do not total
> more than 128 bits. Until now, specifications of "IPv6 over foo" mappings,
> starting with {{!RFC2464}}, have specified an IID length of 64 bits,
> consistent with the value specified by {{!RFC4291}}.
>
> This document allows a router to announce an IID length other than 64 on a
> given link, and updates RFC 4291, RFC 2464 (and numerous other "IPv6 over
> foo" documents TBD), and RFC 4862 accordingly. It extends {{!RFC4861}} by
> defining a new "IID length" mechanism in RA messages.
>
> Terminology: a "modified" host or router supports this spec. An
> "unmodified" host or router supports RFC 4861 and 4862 precisely.
>
> # Modified procedures
>
> The predefined IID length specified by RFC 4291, RFC 2464, etc. is used to
> configure the link-local IPv6 address of a node exactly as described in RFC
> 4862.
>
> On a link where variable IID length is not supported, the predefined IID
> length will continue to be used to configure all other addresses using
> SLAAC.
>
> On a link where variable IID length is supported, each modified router
> will include an "IID length" indication in every RA/PIO message with the A
> bit set. This will override the value defined in RFC 2464 (etc.) and in RFC
> 4291, for the prefix concerned.
>
> Suggestion: put the IID length in 6 bits of the Reserved2 field of the
> PIO. 0b000000 would mean 64, i.e. no change and backwards compatible. Any
> other value would define an IID length in bits. Values less than 48
> (0b110000) are NOT RECOMMENDED. Values greater than 64 are impossible.
>
> (Note: Reserved1 is not available - see {{?RFC8425}}.)
>
> When a modified node receives an "IID length" less than 64, it will use
> that value instead of the default for all unicast address autoconfiguration
> under that prefix, except link-local.
>
> # Deployment issues
>
>   - Unmodified hosts and unmodified routers: no change, all use 64-bit
> IIDs.
>
>   - Modified hosts and unmodified routers: no change, all use 64-bit IIDs.
>
>   - Modified hosts and modified routers: configure to use longer prefixes
> and shorter IIDs if desired.
>
>   - Modified routers and mixture of modified and unmodified hosts on a
> link:
>
>     - The modified hosts will use a shorter IID and longer prefix if that
> is announced.
>
>     - The unmodified hosts, according to RFC 4861, MUST ignore the
> Reserved1 field. So, according to section 5.5.3 clause d) of RFC 4862, they
> will ignore any PIO advertising a shorter IID. Therefore, the operator has
> two choices:
>
>       1. Decide that unmodified hosts will not be supported (i.e. will not
> be able to configure an address using SLAAC).
>
>       2. Announce (at least) two prefixes on the link - a /64 and a longer
> one, with a shorter IID. For that to make sense, we need an extra rule for
> modified hosts: if a host receives several PIOs from the same router, it
> prefers all those with the shortest IID and ignores the others.
>
>   - Mixture of modified and unmodified routers on a link: don't do that!
>
> # IANA Considerations
>
> Maybe a registry for the Reserved2 field, like RFC 8425?
>
> # Security Considerations
>
> Nothing new?
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>