Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 08 November 2020 20:15 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 3531D3A0A4A; Sun, 8 Nov 2020 12:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, URIBL_BLOCKED=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 N6sdcYpzA-gR; Sun, 8 Nov 2020 12:14:58 -0800 (PST)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 C8B9F3A0A47; Sun, 8 Nov 2020 12:14:55 -0800 (PST)
Received: by mail-pf1-x430.google.com with SMTP id c20so5849692pfr.8; Sun, 08 Nov 2020 12:14:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=O/lZVddVYivqd09CFy7HbbIa8ZlQrzwQElGiCpNdAiM=; b=k3kZEOgobX+357YSxl+pppwwuaNjqoh2ORmDaM39RKkHv7YgTV1kIDemmfNNLi3D4c kobYSF3srmu6sUIaYE9ZMNLXezP5amauDGlwb5t/U31gkBE2GSgGCON1p223+4dvb1Pz 9Qy8CHgmL1Dnfmw8Qzcb6G+TfZ+9HV/SiBEISWjqPte/U0UpjHcOBXLWPTUvCkw2PQYx YQ/3iNGI9INHAJ4FHDg2YSBaqyf8sOyJO9iK0UJLCy8nGstQ29iXXnYrUhD/edIOvGch +TXNHNBPakkCbCMJLs1gIhSqAybKAgsclVUO9tDm5gell7ukAOvJUgljI3P2z/XmGM+E WgEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=O/lZVddVYivqd09CFy7HbbIa8ZlQrzwQElGiCpNdAiM=; b=LZBsyomtMrv59TqTgOICwqLDqg1flF6M4x39E4yXe/AiiBeRob2+moaX3rIRwAMusi agg16OElEME4XdlqgM+7zToboFsoJaZnfx+CUUbGktbLWlawiEKNpJf5CMU10oPjHb+H iv4T82nSwm4kWJEthWRm/0fjdQPXkACnv1M2rc1E9NPuHhhsSWLLyl7UlR6pRnszL5S/ 1YEi9mY+q9adRggzQgMdCorXgAzUcxBr9JnU+4ewspVheKWf4z+xGvzZ6ZhFnUnNGAOK qlM3DGyvDllL5kiZBTCgq5ipMkuacrbMBmbkmERHMDvaLN9ek9pk3YC10lpYMARU0YTs Tozw==
X-Gm-Message-State: AOAM532jGxkby3RL6Idj++MD/eTk5ap/a1eNaYrzYOTB6kGr8g2/jIoL eq368cO9f1BtnEyi/a0JvAO8CvH0nq/0PQ==
X-Google-Smtp-Source: ABdhPJzlK615+yE3b34YoIFHml2pvLPxs1QFdl7cDSOZ5XN0N44krL/t0onTBUesYPl5swD98kr9JA==
X-Received: by 2002:a17:90a:f206:: with SMTP id bs6mr9129872pjb.219.1604866494788; Sun, 08 Nov 2020 12:14:54 -0800 (PST)
Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id mv5sm30591pjb.42.2020.11.08.12.14.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Nov 2020 12:14:54 -0800 (PST)
Subject: Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
To: Gyan Mishra <hayabusagsm@gmail.com>, 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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <4658abe3-909e-af0a-ddad-85db06e161ff@gmail.com>
Date: Mon, 09 Nov 2020 09:14:49 +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: <CABNhwV1D7ng8JHJVUBrMhVmbQEQrhECBN_XUUcS5ZSV0WF=Lnw@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/N9_tixbfnzPd7xVjMQv0ZZN0xto>
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: Sun, 08 Nov 2020 20:15:00 -0000

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.

(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.)

Regards
   Brian Carpenter

On 08-Nov-20 19:34, Gyan Mishra wrote:
> 
> A day 1 issue that has existed with SLAAC and another critical operational reason as to why longer prefix should be supported by SLAAC.
> 
> Since SLAAC only supports /64 plen due to the fixed 64 bit IID, that issue ends up shackling IPv6 from using longer  prefix length when other devices using static or DHCPV6 are configured on the same subnet.  
> 
> The major issue that exists is that their maybe devices that do not support DHCPV6 or static and have to use SLAAC and you have a subnet configured on the router with longer then /64 prefix length like a /96 for example.  
> 
> So now with those devices running SLAAC you end up with interoperability issue with remaining devices on the subnet that support longer prefix length via static or DHCPV6.
> 
> The workaround has always been to not use longer prefix lengths for DHCPV6 and static and only use the /64 prefix length as that is only supported by SLAAC.
> 
> So that hinders any and  all operators both enterprises and service providers from using longer prefix lengths, so you are now back to being stuck with the 64 bit IID boundary for all host subnets till the end of time using any of the three IPv6 addressing schemes.
> 
> Gyan
> 
> 
> 
> 
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike 
> /Silver Spring, MD
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>