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

Hi Bob

In-line

On Mon, Nov 2, 2020 at 2:10 PM Bob Hinden <bob.hinden@gmail.com> wrote:

> 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.
>
>    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
>
>
> > On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti <lorenzo=
> 40google.com@dmarc.ietf.org> 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.
> >
> > 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 <fredbaker.ietf@gmail.com>
> 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?
> >
> > > On Nov 2, 2020, at 12:14 AM, Gyan Mishra <hayabusagsm@gmail.com>
> 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
> > > 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 <gyan.s.mishra@verizon.com>
> > > 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 <hayabusagsm@gmail.com>
> > >
> > >
> > >
> > >
> > > ---------- Forwarded message ---------
> > > From: <internet-drafts@ietf.org>
> > > 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 <nkottapalli@benu.net>, Alexandre Petrescu <
> alexandre.petrescu@cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>,
> Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Dusan Mudric <
> dmudric@ciena.com>, Dmytro Shytyi <dmytro.shytyi@sfr.com>
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > > 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
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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