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

From: Gyan Mishra <[email-masked]>
Date: Mon, 2 Nov 2020 03:10:12 -0500

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.

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 <[email-masked]>
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 <[email-masked]>

---------- Forwarded message ---------
From: <[email-masked]>
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 <[email-masked]>, Alexandre Petrescu <
[email-masked]>, Naveen Kottapalli <[email-masked]>, Gyan
Mishra <[email-masked]>, Dusan Mudric <[email-masked]>,
Alexandre Petrescu <[email-masked]>

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

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect & SME*

*Data Center Planning | Common Core | Development & Engineering Lab
ServicesGlobal Technology Services | ITNUC*

*O 240 970-6287M 301 502-134713101 Columbia Pike Rm 304-D*Silver Spring, MD
20904

*IETF  & ISOC Member since 2015*

https://www.ietf.org/

https://www.internetsociety.org/

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Mark Smith <[email-masked]>
Date: Tue, 3 Nov 2020 15:08:01 +1100

On Mon, 2 Nov 2020 at 19:16, Gyan Mishra <[email-masked]> 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.
>
> Please review.  Based on the feedback received from 6MAN, I would to request a time slot on IETF 109.
>
> Kind Regards
>
> Gyan
>
> Subject: Fwd: [E] New Version Notification for draft-mishra-6man-variable-slaac-01.txt
> Subject: [E] New Version Notification for draft-mishra-6man-variable-slaac-01.txt
> To: Dmytro Shytyi <[email-masked]>, Alexandre Petrescu <[email-masked]>, Naveen Kottapalli <[email-masked]>, Gyan Mishra <[email-masked]>, Dusan Mudric <[email-masked]>, Alexandre Petrescu <[email-masked]>
>
>
>
> Title:          SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC)
> 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:
> 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/
>
> Gyan Mishra
> Network Solutions Architect
>
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops