Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 09 November 2020 21:57 UTC

Return-Path: <brian.e.carpenter@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 77E0A3A1332; Mon, 9 Nov 2020 13:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=gmail.com
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 A4nU0bJKvusx; Mon, 9 Nov 2020 13:57:50 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5503A1326; Mon, 9 Nov 2020 13:57:49 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id i13so3523490pgm.9; Mon, 09 Nov 2020 13:57:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uLVEMrQ5jkwP3T6J6yn2j2+H2dOomMbceorYZPnpKbQ=; b=TozrJYjFDu7npBv3umONR5efcYIIXXetkn9X3hEhpoI/MyCfkIwEFB4hxnuWdescgB 7Bh+T4t3XdDi8QO0FS7NhJxwp+ewDqkyzQp8F3GqIgoMDzS6QsrJFC6oYYglpJQJ/0Fg a40hHfMMNi7PpykidgTXbRtr8SlUzAmA9DaliTu9fahANgE/hq2LtYLGO3OtnNKcIHlL 51ZBfsJmAGSwHuuV67qadx29I/bUmdz4c/AwZvdvuX/R9G7EzsJtA4MeNVlJ6IsFtlbd QEDhiYHhvTljCR8reQ5BwnMEDZjGbRfyFwQU8nOkI1IsFz5AUJoOLBDOim6VMXKVRjhc lNFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uLVEMrQ5jkwP3T6J6yn2j2+H2dOomMbceorYZPnpKbQ=; b=RpZvidBCei3jLl+PTEtJ09JCmiDlMD1P1hZfzRTQUDpzX9Mm4ANGvgRWRFK1XfVIpG EnlYK6USuufL2RUnacGUfK1wQ2qUuDIimQpLLWElCnCOh0oYn4WNev+Wrvb7CvEji3gC QsQDsMK1vnr/i22yIkQ9KaCWMCYhte4jdY7IVtzUSh5+sHlqkv7aLOIJBSzagu1ZaXWZ i+BcmqFRMVonsBPJH0GX+Tb+/+skjFvfbjV7+MmGw/NuJ8IRqWJXxxSgZrh32RPg63eY N7qLlrEt2jcHwuwY+wb7fxeUvEIYeLziHd99k0faLTg8vfmUYbDdAmGvT8VkQdIuWcS0 Gbmg==
X-Gm-Message-State: AOAM532OkiILQdRwh4z/lRUreXxaa4B33dIcPyeB4B5UQInxCiO12Lm8 NUbMucxC/TrlNGIKihbaKYJ/xjCjH6b9qg==
X-Google-Smtp-Source: ABdhPJw0Cpc8HU7pDICYf9eLu+++8voJYF3c0FQ9cy911x7oC+4uNkRFvtUceP3WbzNNZs+3u3aqHA==
X-Received: by 2002:a17:90b:2343:: with SMTP id ms3mr1318306pjb.130.1604959069133; Mon, 09 Nov 2020 13:57:49 -0800 (PST)
Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id b5sm7172881pfr.193.2020.11.09.13.57.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 13:57:48 -0800 (PST)
Subject: Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Dmytro Shytyi <dmytro@shytyi.net>, Dusan Mudric <dusan.mudric@gmail.com>, IPv6 IPv6 List <ipv6@ietf.org>, Naveen Kottapalli <naveen.sarma@gmail.com>, "draft-mishra-6man-variable-slaac@ietf.org" <draft-mishra-6man-variable-slaac@ietf.org>
References: <CABNhwV1D7ng8JHJVUBrMhVmbQEQrhECBN_XUUcS5ZSV0WF=Lnw@mail.gmail.com> <4658abe3-909e-af0a-ddad-85db06e161ff@gmail.com> <CABNhwV1rBhWF6e7Tuk6L-R=gTmWgfXvFkWkCQyvbmEA06W3t0A@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <4088150e-1289-5c4f-184d-30df3e66f354@gmail.com>
Date: Tue, 10 Nov 2020 10:57:42 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CABNhwV1rBhWF6e7Tuk6L-R=gTmWgfXvFkWkCQyvbmEA06W3t0A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-1_j20M8rW5aK19hgU7kVSlZ1b8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 09 Nov 2020 21:57:52 -0000

In line...

On 10-Nov-20 04:35, Gyan Mishra wrote:
> Brian 
> 
> In-line
> 
> On Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> 
>     Gyan,
> 
>     I don't think you were around for the original discussions, so there is an aspect that is missing from your logic below.
> 
>     The inclusion of a separate interface identifier field in IP addresses was an entirely intentional feature of IPng. If all we had wanted to do was IPv4 with bigger addresses, that's what we would have done and the address length would have undoubtedly been 64 bits. In fact there were various proposals to do exactly that, with a variety of associated transition and coexistence mechanisms.
> 
>     But the rough consensus was to do more than that, and to allow *extra* space in the address for an interface identifier that was not part of the subnetting mechanism. Originally it was going to be 48 bits, so the longest subnet prefix would have been 80; on second thoughts it was set to 64, which gave *exactly* the same extension to the subnettable space as we would have got from IPv4 with bigger addresses.
> 
>     That isn't inconsistent with what we now call BCP198, which says that on links where an interface identifier & SLAAC isn't needed, subnetting can extend out to /127.
> 
>     All that was despite the fact that we hadn't even realised the potential privacy benefits of a host-defined interface identifier at the time; that is much more recent.
> 
>     As far "day 1" goes, please remember that DHCPv6 is a retro-fit:
> 
>     RFC1971 IPv6 Stateless Address Autoconfiguration. August 1996
>     RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). July 2003.
> 
> 
>     Gyan> Makes sense then that as DHCPv6 was a retrofit “add on” to the base architecture that this issue came about afterwards.
> 
> 
> 
>     (In fairness, draft-ietf-addrconf-ipv6-auto-00 was dated January 1995 and draft-ietf-dhc-dhcpv6-00 was dated February 1995, but it advanced very slowly compared to SLAAC.)
> 
> 
>     Gyan> From a problem statement perspective do you agree with the title of this thread “Day 1 interoperability issue”? 

No. From the dates of the RFCs, it's a "Year 7 interoperability issue".
 
> Do you agree that one way to solve is to allow SLAAC to support longer prefix lengths?

That's one way, but it's the wrong way. The right way is for all operators, including mobile operators, to assign /48 or /56 to all end users.

> Do you agree that this is a major operational issue that needs to be solved?

Yes, but as Barbara says, that needs some collaboration with the SDOs and operator fora to get rid of /64 assignments.

   Brian