“DHCPv6, SLAAC, Static Day X - 17 year interoperability issue” 2nd issue

Gyan Mishra <hayabusagsm@gmail.com> Tue, 10 November 2020 00:35 UTC

Return-Path: <hayabusagsm@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 3FBB53A1536; Mon, 9 Nov 2020 16:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 GLcvcJQwHJGA; Mon, 9 Nov 2020 16:35:49 -0800 (PST)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 D584B3A1535; Mon, 9 Nov 2020 16:35:48 -0800 (PST)
Received: by mail-qv1-xf34.google.com with SMTP id ec16so5075880qvb.0; Mon, 09 Nov 2020 16:35:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=hO4OvBJgQ5YoWIEmrNwCdnpbvt2sIae0Y5t0I8IBnZw=; b=C0CFlna84CY6PaaBXXMW9mWYR5T5B/r3Prngt2JJWYDdxfiGkvmzxwrfhBaG02xoYY KZnMNyZtfQu1X1yyxjZR69jvOSsNPAv9Igex9p7BTUMogtch4fyaUQc37vkaQDBvCExt kodcH4CSCBs1KJBYJXYNKL1L+BHqF95Y8t7+HQXNH+wqRDzQsC/9E3PysnfGY2wQ+MHL M+U/U0QeSJha3/2hFlvBvHdDaK6IwJJS+4uoO9Qm/GkM3aWcSExBLW5r3HaHqB5eyNJC iylIASRQkhWjOu6B+Fupe428UvJ6ZHWLNUPsAl012Xf15JZUFV+vGooQQfyctLzvTAuq DtNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=hO4OvBJgQ5YoWIEmrNwCdnpbvt2sIae0Y5t0I8IBnZw=; b=E0KfXYfLfH5khl3PwGVxel7QVlWmIKZRznY+9ydZutwY8ymoKp8sjfbJLM1jXAz8uS KIser96S4s7InCk/suRlAVXbvsoe3jeym8pNkuby6Re8d9amVPIsFDk0pRWpsJIv+gTS a+YkbCLOzzL2zCgCAf6MWnenGlkg4kw2BMcJepwD/x30ViHIDWaGRijkvb9sy/E8tS6a XwrpHzIfJmL3vEl9KFhxg5+KiMwyLA5CQobWsgjp5vVVUffbVrQABxjuxE/ZqEtNNLfv v7+Zj5oH+VjrPkRyianCb2liPzBuOHdr+X5f920WI0aYmhB64/6qQW+Cb6XRKJaUwA8v gCrQ==
X-Gm-Message-State: AOAM531LHDn3fWhCFK6v0IpvvgC2HEJsRbVvvEhnhDYCwp5uYSQjfyM4 1YjKsdEie/ZhQyOWv/hpGMA=
X-Google-Smtp-Source: ABdhPJyYtk5L+VNjeNqxQE11aK+4TDmCdyegVP4FD+T21AoggSY9MPJekVgInpgaA6HLJCUsXGU/BA==
X-Received: by 2002:a0c:90e6:: with SMTP id p93mr17363422qvp.47.1604968547524; Mon, 09 Nov 2020 16:35:47 -0800 (PST)
Received: from [192.168.1.241] (pool-173-79-173-141.washdc.fios.verizon.net. [173.79.173.141]) by smtp.gmail.com with ESMTPSA id j21sm2284880qtp.10.2020.11.09.16.35.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Nov 2020 16:35:46 -0800 (PST)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-CDD625B6-0E35-4384-BA52-5ADCD05D2574"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 09 Nov 2020 19:35:46 -0500
Subject: “DHCPv6, SLAAC, Static Day X - 17 year interoperability issue” 2nd issue
Message-Id: <3A94E3B6-EA5A-453A-8CB1-C11BBDF88B53@gmail.com>
To: draft-mishra-6man-variable-slaac@ietf.org, 6man WG <ipv6@ietf.org>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Dusan Mudric <dmudric@avaya.com>, Naveen Kottapalli <naveen.sarma@gmail.com>, Dmytro Shytyi <dmytro@shytyi.net>, Ole Troan <otroan@employees.org>, Bob Hinden <bob.hinden@gmail.com>
X-Mailer: iPhone Mail (18A8395)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-sC1GDbbNpoMcYtPO58Dib6yak0>
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: Tue, 10 Nov 2020 00:35:51 -0000

This may have gotten lost in all the threads so starting a new thread.  The issue is interoperability related issue between the 3 IPv6 addressing options that had been broken for 17 years.

Problem Statement:

The main point I am trying to make is that static address configuration and DHCPV6 stateful RFC 8415, you can have any prefix length prefix.   SLAAC with A flag set requires a  64 bit IID and that stems from RFC 4291 modified EUI64 mac based IID generation.  However, now with random IID generation schemes with RFC 4941 privacy extension and RFC 7217 stable IID you can generate any length IID.

The operational issue with SLAAC not supporting any prefix length in PIO and requirement for the 64 bit boundary is that in a deployment scenario where you would like to deploy longer prefix length subnets with a mix of server hosts with static address and mix of client hosts with managed address M=1 that get their 128 bit address from the DHCPv6 server pool, the fear has always been that if a device came up on the subnet that only supports SLAAC it would not work due to the SLAAC A flag set and 64 bit IID requirement.  In that case the SLAAC host would not be able to communicate with any of the devices with a longer prefix including the router.

So that fear of interoperability of SLAAC hosts not being able to support longer prefix lengths has prevented operators from being able to deploy subnets with longer prefix lengths, as it’s hard to predict that all hosts will be able to support static or stateful and so you may end up in a situation where a device type may only support SLAAC so then you are in trouble deploying longer prefix lengths.

Due to the SLAAC 64 bit IID restrictions it has prevented operators from deploying “host” subnets with >64 bit prefix lengths.

f you go to the “root” of the problem the root is the original IPv6 specification RFC 1884 dated 1995, RFC 2373 dated 1998, RFC 3513 dated 2003 and now the present RFC 4291 dated 2006.  As soon EUI64 mac based IID become not recommendedR and obsolete the standard should have immediately updated RFC 4291 as the dependency on fixed IID is no longer as now random IID generation schema starting with RFC 4941 privacy extension dated 2007 soon became standard for all OS vendors and later RFC 7217 stable IID became an alternative option to provide a “random” IID.  

Once random IID became mainstream in all Host Operating Systems it was at that moment that the standard should have changed to update RFC 4291 to permanently remove in all RFCs any mention of 64 bit boundary.  

So this change if I do the math is now 13 years past due.  Even if you gave a few years for host operating systems to adopt the new standard which I believe back then was fairly quickly the standard should have changed eliminating the 64 bit boundary.

Think of all the problems “Day 17 years” this has caused and even now all of these threads.

This is clearly an IETF standards issue and needs to be fixed.

We can’t pass the blame to operators to dole out shorter prefixes or support PD.  The IETF really needs to take onus end fix the broken standard.

Not going to happen for PDP as their are technical issue related to the Mobile Network Gateway to support PD.   I will try to dig up the exact reason but the network element is very different then a BNG broadband gateway which supports most all L3 features.

As far as 3GPP operators they are following the well documented RIPE-690 which only requires allocation of /64.  The main reason mobile operators are not making shorter prefix a standard is that is overkill from their perspective as you may have many mobile handsets in a household and there  is no reason for everyone at a single location to have shorter prefixes per PDP.  When you are at honme you use your wired broadband and when are away from home on the road on 3GPP on PDP is when the segmentation comes into play to subdivide the /64 prefix to downstream devices but in a household is only needed to be provided by one of the devices.
Bottom line is from a 3GPP provider standpoint it does not make sense to provide a shorter prefix and I don’t think that will ever change even with 5G PDP.

Fixed 5G broadband which is a wired broadband replacement will follow RIPE-690 guidelines and will allocation much shorter prefixes as with network slicing and other capabilities with 5G offers the requirements exist for shorter prefixes.  Not so much for PDP.  




https://www.ripe.net/publications/docs/ripe-690#4-2-4--considerations-for-cellular-operators

4.2.4. Considerations for Cellular Operators

There is a clear exception to the rule described above when assigning prefixes in a cellular network. In this case, a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers, i.e. in the case of broadband by means of cellular access, it will still be necessary to choose a /48 or /56 in accordance with the aforementioned considerations.



RFC 3177 for a default /48 allocation which is obsoleted by 6177 which takes a step back and is now not making any recommendations and is putting the onus on operators to figure it out and do what they feel is best which would definitely not be one size fits all approach.

Please read the summary section in RFC 6177 below

5.  Summary

   The exact choice of how much address space to assign end sites is an
   issue for the operational community.  The recommendation in RFC 3177
   [RFC3177] to assign /48s as a default is not a requirement of the
   IPv6 architecture; anything of length /64 or shorter works from a
   standards perspective.  However, there are important operational
   considerations as well, some of which are important if users are to
   share in the key benefit of IPv6: expanding the usable address space
   of the Internet.  The IETF recommends that any policy on IPv6 address
   assignment policy to end sites take into consideration the following:

Thanks 

Gyan


Sent from my iPhone