Subject: [v6ops] Fwd: [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt

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

Dear v6OPS,

This draft addresses the problem statement 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 change to SLAAC to variable, 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 solutions draft below that is referenced in this draft that goes
over in detail the solution on 6MAN.

! Variable SLAAC
https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/

Bob & Ole,

Please review.  Based on the feedback received from 6MAN, I would like 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-v6ops-variable-slaac-problem-stmt-01.txt
To: Hayabusanew <[email-masked]>

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Oct 30, 2020 at 6:46 PM
Subject: [E] New Version Notification for
draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
To: Naveen Kottapalli <[email-masked]>, Alexandre Petrescu <
[email-masked]>, Gyan Mishra <[email-masked]>,
Alexandre Petrescu <[email-masked]>, Dusan Mudric <
[email-masked]>, Dmytro Shytyi <[email-masked]>

A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
has been successfully submitted by Gyan Mishra and posted to the
IETF repository.

Name:           draft-mishra-v6ops-variable-slaac-problem-stmt
Revision:       01
Title:          SLAAC with prefixes of arbitrary length in PIO (Variable
SLAAC) - A Problem Statement
Document date:  2020-10-30
Group:          Individual Submission
Pages:          12
URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=dtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=
Status:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=r_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=
Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=eKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=
Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=
Diff:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=ZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=

Abstract:
   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 details the 64-bit boundary problem
   statement.

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: Fred Baker <[email-masked]>
Date: Mon, 2 Nov 2020 05:25:23 -0800

Let me ask a question of the operators. This draft, as of today, is in discussion in 6man and will probably be discussed in the 6man meeting. I have not offered the authors a slot in v6ops, as it is not being discussed here. That said, it is presumably a solution to an operational problem, in that the prefix that SLAAC is being used to generate an address in is not exactly 64 bits.

Soliciting opinions on the problem: is this something that needs a solution? On the solution: what do you think of it? Does it have holes?

> On Nov 2, 2020, at 12:14 AM, Gyan Mishra <[email-masked]> wrote:
> 
>   Dear v6OPS,
> 
> This draft addresses the problem statement 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 change to SLAAC to variable, 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 solutions draft below that is referenced in this draft that goes over in detail the solution on 6MAN.
> 
> ! Variable SLAAC
> Please review.  Based on the feedback received from 6MAN, I would like to request a time slot on IETF 109.
> 
> Kind Regards
> 
> Gyan
> 
> 
> 
> Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
> Subject: [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
> To: Naveen Kottapalli <[email-masked]>, Alexandre Petrescu <[email-masked]>, Gyan Mishra <[email-masked]>, Alexandre Petrescu <[email-masked]>, Dusan Mudric <[email-masked]>, Dmytro Shytyi <[email-masked]>
> 
> 
> 
> Title:          SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A Problem Statement
> URL:            https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=dtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e= 
> Status:         https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=r_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e= 
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=eKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e= 
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e= 
> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=ZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&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

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 2 Nov 2020 22:32:56 +0900

AFAICS this is a straight violation of the text in RFC 4291 which says that
interface IDs are 64 bits long. As such, I don't see the point in
discussing it unless there is reason to believe that that text will change.

There was a very long and very heated discussion about that text a few
years ago when the 6man tried to take 4291 to full standard. That consumed
a lot of WG time and ultimately resulted in no changes. I expect there are
still going to be very strong opinions on both sides. If we are to reopen
that discussion now, it should happen in 6man, not v6ops. That way those
discussions will at least only happen in one place.

On Mon, Nov 2, 2020 at 10:25 PM Fred Baker <[email-masked]> wrote:

> Let me ask a question of the operators. This draft, as of today, is in
> discussion in 6man and will probably be discussed in the 6man meeting. I
> have not offered the authors a slot in v6ops, as it is not being discussed
> here. That said, it is presumably a solution to an operational problem, in
> that the prefix that SLAAC is being used to generate an address in is not
> exactly 64 bits.
>
> Soliciting opinions on the problem: is this something that needs a
> solution? On the solution: what do you think of it? Does it have holes?
>
> > This change to SLAAC to variable, 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 solutions draft below that is referenced in this draft that
> goes over in detail the solution on 6MAN.
> >
> > ! Variable SLAAC
> > A new version of I-D,

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Nov 2020 05:43:50 -0800

> On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> AFAICS this is a straight violation of the text in RFC 4291 which says that interface IDs are 64 bits long. As such, I don't see the point in discussing it unless there is reason to believe that that text will change.

I'm not disputing the point. My question is a little different, though. If we preclude discussion on the basis that one of the tablets brought down the mountain has different words chiseled into it, we preclude operational input to it - and if it solves an operational problem, we kill that solution. My question is: do we see a problem that might argue for 4291's specification to change?

Absent a problem, we don't need a solution, and that might be an important data point to 6man.

---

From: [email-masked]
Date: Mon, 2 Nov 2020 14:49:59 +0100

> Absent a problem, we don't need a solution, and that might be an important data point to 6man.

Changing the 64 bit boundary is a solution.
Permissionless extension of the network is a problem (one mentioned in the draft).

While the draft has a particular solution in mind, I wouldn't mind discussing the problems the draft enumerates.

Cheers,
Ole

---

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

On Mon, Nov 2, 2020 at 8:50 AM <[email-masked]> wrote:

> >> AFAICS this is a straight violation of the text in RFC 4291 which says
> that interface IDs are 64 bits long. As such, I don't see the point in
> > I'm not disputing the point. My question is a little different, though.
> If we preclude discussion on the basis that one of the tablets brought down
> the mountain has different words chiseled into it, we preclude operational
> input to it - and if it solves an operational problem, we kill that
> solution. My question is: do we see a problem that might argue for 4291's
> specification to change?
> >
> While the draft has a particular solution in mind, I wouldn't mind
> discussing the problems the draft enumerates.

   Gyan> Yes, please discuss

-- 

*Gyan Mishra*

---

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

> that the prefix that SLAAC is being used to generate an address in is not

    Gyan> Agreed on 6MAN slot.  Yes, solution to operational problem.  We
would discuss both problem and solution during the time slot so I think
6MAN would be the right spot.  Correct.

> solution? On the solution: what do you think of it? Does it have holes?

    Gyan> Yes soliciting opinions on the problem is the first step and
poking holes on v6ops before we get to solution - so v6ops ML is perfect
spot for that.

*Gyan Mishra*

---

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

> discussing it unless there is reason to believe that that text will change.

    Gyan> Yes this is a violation as this draft updates RFC 4861 removing
the 64 bit boundary and providing a solution that is backwards compatible
so that there is not any impact to any existing deployments which is a must
for this solution to be even viable in the least.

> discussions will at least only happen in one place.

   Gyan> Yes I remember being on some of those heated debates.  This
development was spawned from those debates but it took quite some time to
build a concrete problem statement to move the ball forward.  So my
thoughts are to kickoff the initial discuss on v6ops on the problem what is
broke, and then at some point shift over to 6MAN on the discussion of the
problem and road to the solution.

>> <https://www.google.com/maps/search/13101+Columbia+Pike+Rm+304-D+%0D%0A+Silver+Spring,+MD+20904?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+Rm+304-D+%0D%0A+Silver+Spring,+MD+20904?entry=gmail&source=g>>
>> Silver Spring, MD 20904
>> <https://www.google.com/maps/search/13101+Columbia+Pike+Rm+304-D+%0D%0A+Silver+Spring,+MD+20904?entry=gmail&source=g>
>> >
>> <https://www.google.com/maps/search/13101+Columbia+Pike++%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike++%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>>
>> Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike++%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>> >
-- 

*Gyan Mishra*

---

From: Bob Hinden <[email-masked]>
Date: Mon, 2 Nov 2020 11:09:57 -0800

Hi,

What Lorenzo said.

Further, I did quick read and see some immediate issues.

First off SLACC works just fine with any size prefix/interface ID.    The protocol supports different sized prefixes/IIDs.   The purported issue relates to interface ID sizes.   These drafts appear to be confused about that.

The v6ops draft goes beyond a problem, it it has an IANA section requesting a new RA flag.

Bob

> On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> There was a very long and very heated discussion about that text a few years ago when the 6man tried to take 4291 to full standard. That consumed a lot of WG time and ultimately resulted in no changes. I expect there are still going to be very strong opinions on both sides. If we are to reopen that discussion now, it should happen in 6man, not v6ops. That way those discussions will at least only happen in one place.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2020 09:08:30 +1300

On 03-Nov-20 06:13, Gyan Mishra wrote:
> 
> 
> On Mon, Nov 2, 2020 at 8:25 AM Fred Baker <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Gyan> Agreed on 6MAN slot.  Yes, solution to operational problem.  We would discuss both problem and solution during the time slot so I think 6MAN would be the right spot.  Correct.

Why would 6man spend time on solving a problem before the operational community agreees that there is a problem?

My understanding is that the principal operational requirement is already stated in BCP198 (RFC7608). There was a previous attempt to change the status quo in https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6 but that didn't advance.

So let's have a discussion whether there is a new operational problem here first:

  "The main problem is that SLAAC RA or PD allocates a /64 by the
   wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, however
   segmentation of the /64 via SLAAC is required so that downstream
   interfaces can be further sub-netted."

Why isn't that in v6ops scope?

>     Soliciting opinions on the problem: is this something that needs a solution?

Is there any reason why the mobile devices can't be given a /56 or /48, which solves the problem immediately?

    Brian

On the solution: what do you think of it? Does it have holes?
> 
>     
>     Gyan> Yes soliciting opinions on the problem is the first step and poking holes on v6ops before we get to solution - so v6ops ML is perfect spot for that.
> 
> 
> 
>     > On Nov 2, 2020, at 12:14 AM, Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >   Dear v6OPS,
>     >
>     > From: Mishra, Gyan S <[email-masked] <mailto:[email-masked]>>
>     > To: Hayabusanew <[email-masked] <mailto:[email-masked]>>
>     >
>     >
>     >
>     >
>     > From: <[email-masked] <mailto:[email-masked]>>
>     > To: Naveen Kottapalli <[email-masked] <mailto:[email-masked]>>, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>, Gyan Mishra <[email-masked] <mailto:[email-masked]>>, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>, Dusan Mudric <[email-masked] <mailto:[email-masked]>>, Dmytro Shytyi <[email-masked] <mailto:[email-masked]>>
>     >
>     >
>     >
>     > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>     >
>     > The IETF Secretariat
>     >
>     >
>     >
>     >
>     > --
>     >
>     >
>     > Gyan Mishra
>     > [email-masked] <mailto:[email-masked]>
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike 
> /Silver Spring, MD
> 
> 
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 2 Nov 2020 15:19:17 -0800

At Mon, 2 Nov 2020 11:09:57 -0800,
Bob Hinden <[email-masked]> wrote:

> First off SLACC works just fine with any size prefix/interface ID.
> The protocol supports different sized prefixes/IIDs.   The purported
> issue relates to interface ID sizes.   These drafts appear to be
> confused about that.

+1.  Even the draft title has the confusion: "SLAAC with prefixes of
arbitrary length in PIO (Variable SLAAC) - A Problem Statement".
The SLAAC protocol itself as defined in RFC4862 already works with an
arbitrary prefix length.

Today's limitation, i.e., the interface identifier (and therefore the
prefix also) length used in SLAAC is always 64 bits in practice, just
comes from the addressing architecture (RFC4291) and IPv6-over-foo
standards (that are supposed to be consistent with the addressing
architecture).  If the "problem(s)" the authors see are this
limitation, the draft should target at the addressing architecture
and/or IPv6-over-foo specs, not SLAAC.  So, for example, the title
would have to be: "IPv6 subnet prefixes of arbitrary length - A
Problem Statement" or "Arbitrary Length Interface Identifiers - A
Problem Statement" (both "subnet prefix" and "interface identifier"
are a concept defined in the address architecture).

--
JINMEI, Tatuya

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 2 Nov 2020 21:55:39 -0500

On Mon, Nov 2, 2020 at 2:10 PM Bob Hinden <[email-masked]> wrote:

> First off SLACC works just fine with any size prefix/interface ID.    The
> protocol supports different sized prefixes/IIDs.   The purported issue
> relates to interface ID sizes.   These drafts appear to be confused about
> that.
>

   Gyan> The v6ops draft is about defining the problem statement not
solution so no IANA requests in that draft - that was in error - fixed in
next revision

> > > This draft addresses the problem statement 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.
> > >

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 3 Nov 2020 01:12:05 -0500

On Mon, Nov 2, 2020 at 3:08 PM Brian E Carpenter <
[email-masked]> wrote:

> > On Mon, Nov 2, 2020 at 8:25 AM Fred Baker <[email-masked]
> <mailto:[email-masked]>> wrote:
> >
> >     Let me ask a question of the operators. This draft, as of today, is
> in discussion in 6man and will probably be discussed in the 6man meeting. I
> >     Gyan> Agreed on 6MAN slot.  Yes, solution to operational problem.
> We would discuss both problem and solution during the time slot so I think
> Why would 6man spend time on solving a problem before the operational
> community agreees that there is a problem?
>
> My understanding is that the principal operational requirement is already
> stated in BCP198 (RFC7608). There was a previous attempt to change the
> status quo in
> https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6 but that
> didn't advance.
>

      Gyan> Correct.  That is the issue.

> Why isn't that in v6ops scope?

    I think the problem would be I would think in scope to v6ops however as
Fred & Lorenzo pointed out that it maybe better to keep the entire
discussion in 6MAN as it pertains to operations problem but then also
solutions to the problem that updates slaac which is in a separate 6man
draft.  So having the entire discussion in 6man makes sense.  I see you
already started the thread there so I will join in.

> solution?

  4G & 5G carrier standard is /64 per handset for both IPv6 only and dual
stack deployments.  Even though there is a way tremendous amount of space
in IPv6 I believe last count worldwide is 14 billion handsets.
  This issue with /64 segmentation does become more pronounced with 5G  as
it competes with broadband use case and in many cases SOHO customers may
eliminate their broadband and rely solely on 5G and need the segmentation.

> >     > This change to SLAAC to variable, 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 solutions draft below that is referenced in this draft
> that goes over in detail the solution on 6MAN.
> >     >
> >     > ! Variable SLAAC
> >     > To: Naveen Kottapalli <[email-masked] <mailto:
> [email-masked]>>, Alexandre Petrescu <[email-masked]
> <mailto:[email-masked]>>, Gyan Mishra <
> [email-masked] <mailto:[email-masked]>>, Alexandre
> Petrescu <[email-masked] <mailto:[email-masked]>>,
> Dusan Mudric <[email-masked] <mailto:[email-masked]>>, Dmytro
> Shytyi <[email-masked] <mailto:[email-masked]>>
> >     >
> >     >
> >     >
> >     > A new version of I-D,

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 3 Nov 2020 01:28:10 -0500

Hi Bob

In-line

On Mon, Nov 2, 2020 at 2:10 PM Bob Hinden <[email-masked]> wrote:

>    Gyan> Understood that SLAAC in itself does not create the restriction
as the 64 bit boundary restriction is due to 64 bit IID fixed length when A
flag is set.

   The 6man draft below identifies the solution and references the last
time this topic came up about a year or so ago with this draft "
https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05"
   This draft submitted on 6man discusses the history behind the slaac 64
bit fixed iid and refrences the v6ops draft problem statement and defines
the RA flag solution for slaac to support vlsm & eliminating the IID fixed
64 bit boundary.

https://tools.ietf.org/html/draft-mishra-6man-variable-slaac-01

> The v6ops draft goes beyond a problem, it it has an IANA section
> requesting a new RA flag.  Gyan> This was a typo -wll update when draft
> submissions opens back up
>
> Bob
>
>

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 3 Nov 2020 01:41:02 -0500

Hi Jinmei

In-line

> The SLAAC protocol itself as defined in RFC4862 already works with an

    Gyan> I will fix the title to make it clear.

>    Gyan> Many Thanks for your feedback on the title description to make it
clearer.  I agree that RFC 4862 does not state anywhere that SLAAC itself
does not support variable prefix length.
   RFC 4291 IPv6 Addressing architecture states the 64 bit IID
requirement.  Agreed.   I will clarify that in the draft.

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

-- 

*Gyan Mishra*

---

From: Philip Homburg <[email-masked]>
Date: Tue, 03 Nov 2020 13:02:31 +0100

>the problems the draft enumerates.

I'm curious why existing mechanisms for distributing prefixes are not enough.

On landlines we have a very successful deployment of DHCPv6 IA_PD. We have
homenet for distributing prefixes within a site (and for simple cases, nested
DHCPv6 IUA_PD works as well).

We have RIR policies that allow sites to get a /48, also for individual
consumers.

So why then have people problems giving each subnet its own /64?

- Is this a protocol issue?
- Is a technical issue? (equipment that doesn't support prefix delegation)
- Is it economical and if so where? RIR fees, cost of equipment, support, etc.

For example, if customers of 5G mobile need to have multiple subnets behind
the mobile link, why do the mobile telcos only provide a /64?

Why does the draft list a home network as a problem (Section 4.4)? Is this
for the rare case that the upstream ISP doesn't support DHCPv6 IA_PD?

Somehow the draft completely fails to mention DHCP prefix delegation. Which
is weird because it is the main mechanism for provides sites with enough
space to number the sites' subnets.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Nov 2020 11:08:03 -0800

Gyan,

> On Nov 2, 2020, at 10:12 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 
>   4G & 5G carrier standard is /64 per handset for both IPv6 only and dual stack deployments.  Even though there is a way tremendous amount of space in IPv6 I believe last count worldwide is 14 billion handsets.
>   This issue with /64 segmentation does become more pronounced with 5G  as it competes with broadband use case and in many cases SOHO customers may eliminate their broadband and rely solely on 5G and need the segmentation.
> 

Like Brian if multiple subnets are needed, it appears to me that this can be solved by giving the handset or fixed 5G a shorter prefix.  Why is anything else needed?

Bob

---

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Nov 2020 11:14:40 -0800

Gyan,

> On Nov 2, 2020, at 10:28 PM, Gyan Mishra <[email-masked]> wrote:
> 
> Hi Bob
> 
> In-line
> 
>    Gyan> Understood that SLAAC in itself does not create the restriction as the 64 bit boundary restriction is due to 64 bit IID fixed length when A flag is set.

Good, then I suggest you stop calling it a SLAAC problem.

>    The 6man draft below identifies the solution and references the last time this topic came up about a year or so ago with this draft "https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05"
>    This draft submitted on 6man discusses the history behind the slaac 64 bit fixed iid and refrences the v6ops draft problem statement and defines the RA flag solution for slaac to support vlsm & eliminating the IID fixed 64 bit boundary.

I, and I suspect most of the working group, are very aware of the history and background on this topic.

Bob

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 3 Nov 2020 20:56:31 +0100

Le 03/11/2020 à 20:14, Bob Hinden a écrit :
> Good, then I suggest you stop calling it a SLAAC problem.*

We struggled during internal discussions about what to call it so that 
it gets better through.

Indeed, the SLAAC spec is independent of the prefix length.

However, SLAAC spec needs IP-over-foo specs to give an IID.  And these 
latter are all 64bit len.  Indirectly, this makes that SLAAC forms GUAs 
with only a 64bit plen.

Maybe one would be ok to call it and _indirect_ SLAAC-GUA problem?

(I formulated yesterday a longer email explaining this in more detail 
but I hold it in my Drafts folder, and I restrain)

Alex

---

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Nov 2020 17:36:05 -0800

Alexandre,

> On Nov 3, 2020, at 11:56 AM, Alexandre Petrescu <[email-masked]> wrote:
>>> 
>>> What Lorenzo said.
>>> 
> We struggled during internal discussions about what to call it so that it gets better through.
> 

Correct.

> 
> However, SLAAC spec needs IP-over-foo specs to give an IID.  And these latter are all 64bit len.  Indirectly, this makes that SLAAC forms GUAs with only a 64bit plen.
> 

Again, ND and SLAAC works fine with any combination of prefix and IID length (as long as they add up to 128 bits, and the IID isn’t too small to avoid collisions on the link).

It’s not a SLAAC-GUA problem.  RFC4291 defines how long IIDs are:

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long...

Bob

> 
> (I formulated yesterday a longer email explaining this in more detail butd I hold it in my Drafts folder, and I restrain)
> 
> Alex
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Nov 2020 18:20:19 +0900

> Why isn't that in v6ops scope?

I'd say that is not in scope anywhere because there already exists a
protocol that solves this problem. It's called DHCPv6 PD.

If there is an operational problem with DHCPv6 PD, then that might indeed
be in scope for v6ops. That's not what the draft is about though. As far as
I can see it doesn't mention DHCPv6 PD at all. The draft is about proposing
a change to SLAAC, and as such is a protocol change that is not in scope
for v6ops.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Nov 2020 11:28:53 +1300

On 04-Nov-20 22:20, Lorenzo Colitti wrote:
> On Tue, Nov 3, 2020 at 5:09 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I'd say that is not in scope anywhere because there already exists a protocol that solves this problem. It's called DHCPv6 PD.

I meant that if 5G doesn't already define how to support an IPv6 "hotspot" solution, then there is an operational gap that could usefully be documented. The current draft doesn't do that, because it assumes a class of solution (SLAAC-based instead of PD-based) rather than stating the underlying problem.

Assuming that PD is the preferred solution, a description of how to do that in a 5G (or any 3GPP) deployment would be very desirable. If such a document already exists outside the IETF, that would be fine too.
 
> If there is an operational problem with DHCPv6 PD, then that might indeed be in scope for v6ops. That's not what the draft is about though. As far as I can see it doesn't mention DHCPv6 PD at all. The draft is about proposing a change to SLAAC, and as such is a protocol change that is not in scope for v6ops.

I agree that the draft as it stands is out of scope. I had to find the text quoted above to understand what the underlying problem migh be.

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 4 Nov 2020 21:09:59 -0500

On Wed, Nov 4, 2020 at 5:29 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> I meant that if 5G doesn't already define how to support an IPv6 "hotspot"
> solution, then there is an operational gap that could usefully be
> documented. The current draft doesn't do that, because it assumes a class
> of solution (SLAAC-based instead of PD-based) rather than stating the
> underlying problem.
>
> Assuming that PD is the preferred solution, a description of how to do
> that in a 5G (or any 3GPP) deployment would be very desirable. If such a
> document already exists outside the IETF, that would be fine too.
>
> > If there is an operational problem with DHCPv6 PD, then that might
> indeed be in scope for v6ops. That's not what the draft is about though. As
> far as I can see it doesn't mention DHCPv6 PD at all. The draft is about
> proposing a change to SLAAC, and as such is a protocol change that is not
> in scope for v6ops.
>
> I agree that the draft as it stands is out of scope. I had to find the
> text quoted above to understand what the underlying problem migh be.

    Gyan> Agreed.  As pointed out the problem statement draft states the
problem with slaac and proposed change to slaac and does not mention
anything about dhcpv6  PD.

There are two drafts below that complement each other.

! v6ops slaac issue —> so this should move to 6man

https://tools.ietf.org/html/draft-mishra-v6ops-variable-slaac-problem-stmt-01

! 6MAN Proposes slaac change

*Gyan Mishra*

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Nov 2020 19:15:54 +0100

Tatuya,

Le 03/11/2020 à 00:19, 神明達哉 a écrit :
> At Mon, 2 Nov 2020 11:09:57 -0800, Bob Hinden <[email-masked]>
> wrote:
> 
>> The protocol supports different sized prefixes/IIDs.   The
>> purported issue relates to interface ID sizes.   These drafts
>> appear to be confused about that.
> 
> arbitrary length in PIO (Variable SLAAC) - A Problem Statement". The
> SLAAC protocol itself as defined in RFC4862 already works with an 
> arbitrary prefix length.

I think it is an indirect SLAAC-GUA problem.  The IID len problem taints
SLAAC.

Yes, SLAAC spec works with 65bit plens.

No, IIDs defined in IPv6-over-foo are not used anywhere else than in
SLAAC.  SLAAC is the only protocol that uses the IIDs defined in
IPv6-over-foo.

Because of that, if we formulate a problem that is only about IID, then
nobody will want to solve that problem, because nobody uses the IIDs
defined by IPv6-over-foo.

> Today's limitation, i.e., the interface identifier (and therefore
> the prefix also) length used in SLAAC is always 64 bits in practice,
> just comes from the addressing architecture (RFC4291) and
> IPv6-over-foo standards (that are supposed to be consistent with the
> addressing architecture).  If the "problem(s)" the authors see are
> this limitation, the draft should target at the addressing
> architecture and/or IPv6-over-foo specs, not SLAAC.

If we target the problem at the IPv6 Addr Archi, then that RFC might
(lets say) get improved and define IIDs that could be of different
length than 64.  But, at that point, shall we also update _all_
IPv6-over-foo documents to refer to the new IPv6 Address Archi document?

Or maybe should we just write an implementation of variable len SLAAC-GUA?

> So, for example, the title would have to be: "IPv6 subnet prefixes of
> arbitrary length - A Problem Statement"

But subnet prefixes like 65bit length do work ok with ND nowadays.

> or "Arbitrary Length
> Interface Identifiers - A Problem Statement" (both "subnet prefix"
> and "interface identifier" are a concept defined in the address
> architecture).

But who uses Interface Identifiers?  Only SLAAC, I think.

Alex
> 
> -- JINMEI, Tatuya
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 5 Nov 2020 20:54:40 +0100

Hi,

> But subnet prefixes like 65bit length do work ok with ND nowadays.

Subnet prefixes of any length work perfectly fine with ND nowadays.

Just "SLAAC" doesn't, on most platforms.

I've heard that OpenBSD can do SLAAC with non-/64 prefix lengths
just fine these days, though I have not tried it.

> But who uses Interface Identifiers?  Only SLAAC, I think.

Using MAC-based EUI-64 for IIDs seems to be a relic from the past anyway.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Nov 2020 09:43:19 +1300

>> But who uses Interface Identifiers?  Only SLAAC, I think.

Since SLAAC is mandatory to implement on IPv6 nodes [BCP220, RFC8504], that means that all IPv6 nodes use IIDs (and most of them have /64 baked in [RFC4291]).

> Using MAC-based EUI-64 for IIDs seems to be a relic from the past anyway.

True; that aspect is a complete distraction.

    Brian

---

From: 神明達哉 <[email-masked]>
Date: Thu, 5 Nov 2020 13:06:04 -0800

At Thu, 5 Nov 2020 19:15:54 +0100,

> SLAAC.  SLAAC is the only protocol that uses the IIDs defined in

For IPv6-over-foo, that's correct.  For example, RFC2464 Section 4
specifically states it's for SLAAC.  But that's only a part of the
whole picture; IPv6-over-foo and addr arch (RFC4291) must be
consistent, and the latter is not specific to SLAAC.  In fact, if the
spec for IID length in the addr arch were also only about SLAAC, I
suspect the Bourbaki author(s) wouldn't care too much about it.

The authors of draft-mishra-v6ops-variable-slaac-problem-stmt might
only be interested in SLAAC related use cases, but we can't pretend
it's an SLAAC specific problem (and provide a tweak to SLAAC as a
"solution") without resolving the implication on the addr arch (and
on manually configured addresses, etc).

That's what I tried to point out.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Nov 2020 08:49:04 +1100

> on manually configured addresses, etc).

There's also privacy and security implications, as if prefix lengths become
arbitrary, then at a certain length, privacy addreses become ineffective,
and measures to prevent discovery by unsolicited packet probing become
ineffective.

There's also implications to BCP204, host addressing recommendations,
because I expect people will choose prefix lengths to only give each host a
single address, as that is what they're familiar with from IPv4.

64 bits itself isn't magic, it is that it is a default, "plug-and-play"
size that very effectively accommodates all of these other things that
couldn't exist in IPv4.

A provider giving out a single /64, when the provider has at least 4
billion /64s (i.e., min RIR allocation of a /32) is implicitly and strongly
saying they don't want the receiver to be running a routed network.

The IETF shouldn't come up with technical work arounds to operator
policies, when there are already solutions for operators that don't have
those policies (in this specific case, if customers are allowed to run
routed networks, the operator can provide multiple /64s via PD).

Regards,
Mark.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 Nov 2020 13:49:33 -0800

Alexandre,

> On Nov 5, 2020, at 10:15 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
>> or "Arbitrary Length

That is not correct.   All IPv6 unicast addresses have Interface IDs.  For example from RFC4291:

   2.5.4.  Global Unicast Addresses

   The general format for IPv6 Global Unicast addresses is as follows:

   |         n bits         |   m bits  |       128-n-m bits         |
   +------------------------+-----------+----------------------------+
   | global routing prefix  | subnet ID |       interface ID         |
   +------------------------+-----------+----------------------------+

This is independent of how they are allocated (SLAAC, DHCP, manual).

Please reread RFC4291.

Bob

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Nov 2020 10:54:14 +0100

Le 05/11/2020 à 22:49, Mark Smith a écrit :
> 
> 
> On Fri, 6 Nov 2020, 08:06 神明達哉, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Alexandre Petrescu <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
> There's also privacy and security implications, as if prefix lengths 
> become arbitrary, then at a certain length, privacy addreses become 
> ineffective, and measures to prevent discovery by unsolicited packet 
> probing become ineffective.
> 
> because I expect people will choose prefix lengths to only give each 
> host a single address, as that is what they're familiar with from IPv4.
> 
> billion /64s (i.e., min RIR allocation of a /32) is implicitly and 
> strongly saying they don't want the receiver to be running a routed network.
> 

MArk,

There are operators and operators.  And, within operators, we use a 
generic term 'operator' to mean many things.  But there are humans and 
computers at our each mention of 'operator'.  We should not 
misunderstand each other at IETF.

Operators depend on hardware manufacturers.

At this time, the conclusion of all these dependencies, is that it's not 
possible to do a /56 for a smartphone.

Some people and some computers and some policies at some operators do 
not mind if an IETF solution does 65+63 on the Ethernet or WiFi 
interface.  They dont mind that any more than doing 64share or NAT for 
IPv4.  Doing 65+63 on the WiFi interface of a smartphone might even be 
seen as an advantage, by certain people on some computers at some 
operators with some policies.

This 65+63 is not a workaround operators interests.

Alex

>     <https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Nov 2020 13:01:10 +0100

Le 05/11/2020 à 22:49, Bob Hinden a écrit :
>>> or "Arbitrary Length Interface Identifiers - A Problem Statement"
>>> (both "subnet prefix" and "interface identifier" are a concept
>>> defined in the address architecture).
>> 
> That is not correct.   All IPv6 unicast addresses have Interface
> IDs.

Maybe I can try to say that an 64bit IID is made of a sub-IID1 and a
sub-IID2?

In this way, an IID would still be 64bit length, but the Variable SLAAC
would form an address in a different way: it would use a super-prefix
constructed of the prefix received in RA to which the sub-IID1 would be
appended.  This Variable SLAAC would finally append the sub-IID1 to the
super-prefix to form a 128bit IPv6 address.

This be in agreement with IID 64bit of RFC4291, I think?

Alex

   For example from RFC4291:
> +------------------------+-----------+----------------------------+ |
> global routing prefix  | subnet ID |       interface ID         |