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

Fred Baker <fredbaker.ietf@gmail.com> Mon, 02 November 2020 13:25 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88713A0810 for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2020 05:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 Y-oWRl1XXu_T for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2020 05:25:28 -0800 (PST)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 E41F33A0FBB for <v6ops@ietf.org>; Mon, 2 Nov 2020 05:25:28 -0800 (PST)
Received: by mail-pf1-x431.google.com with SMTP id 133so11103843pfx.11 for <v6ops@ietf.org>; Mon, 02 Nov 2020 05:25:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7/CCxnEYNQ0R1rQb+uMB0LsQwwvE841Qn0h4c8YxR/o=; b=FkGsdTXKBb8MVIolGosQIJI0eseg4urEUACTtRmma9ht6ajv4EIG8x2Lk7zol4jJUC 3J7y0hjHQ6Eo8xA78mQJKiay4fpeutTBUDerNYBdBB3NjfGgMBN5y5llMvGjk/jFmeSz YEinlHsat/seQptDLoLlHryF6+OgoNGbla/e2HnizHjFoLrPGCdo/MG94ns95E4lTvbY oYe8Rp0AYIQ+nA5X3kRfsZNkBI9266+odIKibvLgMVn+Dtm73arip2iiqnMXQ3f1/Gwk 4upNCAPcHUPsv8eZkiOMXe4dxQq7LpMFlNO4jxw+/zOdAMDgrCoLcAyDN3pY1hryEmY5 tJqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7/CCxnEYNQ0R1rQb+uMB0LsQwwvE841Qn0h4c8YxR/o=; b=FS8GS76IZCjNYmxE000ZS0VtqCsHQVnN0uFA+cWjbAHR2VAEh0mN1Ha/64AuoOofxL xQ5VpziYqzSB9wQZl399ZwyiFUpt1XMzM4M/aia3rkASlJnkZtUAcItzdtT7B/AyD7vh fyDsRYxh/6z7qf13vmMkSMRIdFPb+3r9Jrf/dj7IBPEH2QhJdUL4+jQArctUveGwmI9q EKerDZZ5sxfnnPdbXOTy0WRdh3E0b2j09VqED9f5bbWX2Suf/WeSJyg5QQTjHMIgj7CD Mghmx+3/NcCtdiE8tNpMqqB1KTsXW4KHxjLPNul1i2ypPev0UoII64ICgsz5CgrR6Ii6 PLAQ==
X-Gm-Message-State: AOAM531vqXPV5CMJOP0jYgAitvrIJTsNWlfQYHcuI5sXmzUTS3UPwGNy wIBiA321YX+jB9/TT4ixtlNCxemERW+1iw==
X-Google-Smtp-Source: ABdhPJzBK9a63FVmz1u4Yp5DUZikVxOietQfllBvj9tLHfL8e6bGAeiMCnQfBAA8BUE9TRsWSbbiPQ==
X-Received: by 2002:a63:f445:: with SMTP id p5mr13149180pgk.293.1604323526500; Mon, 02 Nov 2020 05:25:26 -0800 (PST)
Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id x15sm1338793pjh.21.2020.11.02.05.25.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 05:25:25 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\))
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <CABNhwV1LTcVKobDpiEjnxqKbX9drz1od+RNg7EdX_WO04JQgUw@mail.gmail.com>
Date: Mon, 02 Nov 2020 05:25:23 -0800
Cc: Naveen Kottapalli <nkottapalli@benu.net>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>, Dusan Mudric <dmudric@ciena.com>, Dmytro Shytyi <dmytro.shytyi@sfr.com>, Ole Troan <otroan@employees.org>, Bob Hinden <bob.hinden@gmail.com>, Gyan Mishra <hayabusagsm@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com>
References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <CAJhXr98mPsopQrUiKfXGuN+wxSEtNiP00LBEGrYObz62FHSa_Q@mail.gmail.com> <CABNhwV1LTcVKobDpiEjnxqKbX9drz1od+RNg7EdX_WO04JQgUw@mail.gmail.com>
To: IPv6 Operations <v6ops@ietf.org>
X-Mailer: Apple Mail (2.3654.20.0.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/CZgLqzGAodB2A5U_Yw3r-bhQe0E>
Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 13:25:31 -0000

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