Re: [v6ops] Fwd: [E] New Version Notification for draft-mishra-6man-variable-slaac-01.txt

On Mon, 2 Nov 2020 at 19:16, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
> Dear 6MAN,
>
> This draft addresses a solution to change SLAAC's historical fixed 64 bit boundary to variable PIO so that VLSM masking is supported just as it is today with static & DHCPv6 & DHCPv6 PD.
>
> This ensures that parity is maintained between the three address deployment mechanisms that exist today with IPv6.  This draft as well addresses the MAJOR gap that exists today with lack of parity and the historical framework of the impact of this lack of partify that has existed since the IPv6 specification was published 20+ years ago.
>
> We have a problem statement draft below that is referenced in this draft that goes over in detail the problem that exists today with the SLAAC fixed 64 bit boundary and ramifications and reasons for the necessary change to SLAAC to eliminate the historical 64 bit fixed boundary.

RFC1925,

"   (12) In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away."

For many years, IPv4 had a simple 8 bit network, 24 bit host
addressing scheme. See RFC760 from January 1980.

In September of 1981, RFC791 introduced classes to greatly increase
the number of network numbers without having to increase the 32 bit
IPv4 address size. The reason for this can be seen in RFC776, from
January 1981, where the assigned IPv4 network numbers are listed, and
40 of the total 256 are in use.

40 networks out of 256 isn't many, except when you want to use the
'128' bit and other high order bits in the first address octet to
encode address format information. RFC791 introduced address Classes
A, B, C, D and E.

Subsequent subnets (RFC960, August 1985, motivation in RFC940, August
1985), VLSM and then CIDR were complex measures to avoid and delay
increasing the addressing size beyond 32 bits.

IPv6 addresses are 128 bits. 2^64 networks is plenty. We don't need
the complexity of IPv4 addressing in IPv6 because we don't have the
problem they had with IPv4 - not enough network numbers and not enough
addressing bits.

>
>
> As far as the solution goes one of our authors Dmytryo has been able to successfully test on Linux kernel signaling PIO flag and maintaining backwards compatibility that with the flag set the prefix length can be increased to 127 bits and the station-id generated via either RFC 4941 or RFC 7217.  Modified EUI64 is not an available option for variable slaac as due to MAC dependency the IID is increased to 64bit.
>
> ! SLAAC Problem Statement
> https://tools.ietf.org/html/draft-mishra-v6ops-variable-slaac-problem-stmt-01
>
> Bob & Ole,
>
> Please review.  Based on the feedback received from 6MAN, I would to request a time slot on IETF 109.
>
> Kind Regards
>
> Gyan
>
> ---------- Forwarded message ---------
> From: Mishra, Gyan S <gyan.s.mishra@verizon.com>
> Date: Fri, Oct 30, 2020 at 6:50 PM
> Subject: Fwd: [E] New Version Notification for draft-mishra-6man-variable-slaac-01.txt
> To: Hayabusanew <hayabusagsm@gmail.com>
>
>
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Fri, Oct 30, 2020 at 6:36 PM
> Subject: [E] New Version Notification for draft-mishra-6man-variable-slaac-01.txt
> To: Dmytro Shytyi <dmytro.shytyi@sfr.com>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Naveen Kottapalli <nkottapalli@benu.net>, Gyan Mishra <gyan.s.mishra@verizon.com>, Dusan Mudric <dmudric@ciena.com>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>
>
>
>
> A new version of I-D, draft-mishra-6man-variable-slaac-01.txt
> has been successfully submitted by Gyan Mishra and posted to the
> IETF repository.
>
> Name:           draft-mishra-6man-variable-slaac
> Revision:       01
> Title:          SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC)
> Document date:  2020-10-30
> Group:          Individual Submission
> Pages:          33
> URL:            https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2D6man-2Dvariable-2Dslaac-2D01.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=wnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=tM5EVDjoyI9tNSKrsyLcrBNPCR0ZSrdGMQbB1ma8FwY&e=
> Status:         https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmishra-2D6man-2Dvariable-2Dslaac_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=wnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=igBIeoMkz1AGxGrUPJreLee5t2-3B4dzdHgYb7Gv2LI&e=
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2D6man-2Dvariable-2Dslaac&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=wnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=wKpc7lhDGYVktyD-CF5EtH1aqYAYHFwTV3sjoBE9pcU&e=
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2D6man-2Dvariable-2Dslaac-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=wnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=UWiqt_BgJ6xpv0JVlvJf53yAMQ1XzVuNb7wK-TIvJQA&e=
> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2D6man-2Dvariable-2Dslaac-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=wnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=6fGNxKPLE-TIAgDExR1Tdu-3mQCqTTF1JfNmnsGWE6o&e=
>
> Abstract:
>    This draft proposes the use of arbitrary length prefixes in PIO for
>    SLAAC.  A prefix of length 65 in PIO, for example, would be permitted
>    to form an addresses whose interface identifier length is length 63,
>    which allows several benefits.
>
>    In the past, various IPv6 addressing models have been proposed based
>    on a subnet hierarchy embedding a 64-bit prefix.  The last remnant of
>    IPv6 classful addressing is a inflexible interface identifier
>    boundary at /64.  This document proposes flexibility to the fixed
>    position of that boundary for interface addressing.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> --
>
>
> Gyan Mishra
>
> Network Solutions Architect & SME
>
> Data Center Planning | Common Core | Development & Engineering Lab Services
> Global Technology Services | ITNUC
>
> O 240 970-6287
> M 301 502-1347
> 13101 Columbia Pike Rm 304-D
> Silver Spring, MD 20904
>
>
> IETF  & ISOC Member since 2015
>
> https://www.ietf.org/
>
> https://www.internetsociety.org/
>
>
>
>
> --
>
>
> Gyan Mishra
>
> Network Solutions Architect
>
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops