Re: 64share v2

Gyan Mishra <hayabusagsm@gmail.com> Thu, 12 November 2020 03:01 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207AA3A1364 for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 19:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level:
X-Spam-Status: No, score=-1.087 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 eB0HEq7n5f64 for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 19:01:11 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 611DD3A1362 for <ipv6@ietf.org>; Wed, 11 Nov 2020 19:01:11 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id k7so2044851plk.3 for <ipv6@ietf.org>; Wed, 11 Nov 2020 19:01:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e7GWn1jfAyxupvDCQrZdcvU7AbRk7JKx+Pr8i0nr7q0=; b=O/cjZr3s8FG+ZEUlBdsa9Kx39GhHdqWhIGXe39pe6rEb2wNuH971skIopDKHxJA3Lb CO5cU+/7/qnTA4SibLNNT3+krAWnhymNvHTBT85vsl4DGKNjQTk44hdsjnQAS8vTFPgx xpPTt998Tih+avC/cOoq36kdtHJDPVQvxdMiYfk3WeRP91dRUOBqWKkCWJWPG9X2sVWV 6M0EH+cyFn9y/zXfH8kMvdn6EnNIBAUw0yN++RpCJ6O40XtB4JDsG4d10HS25zskQgB2 NyqaKWHEKhcf9ouUAcWxHKth4gkdvrVTyTBaoHSSTQOTw2UosPN7fFYvdJMeV7jc4zoz 8Bxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e7GWn1jfAyxupvDCQrZdcvU7AbRk7JKx+Pr8i0nr7q0=; b=KeWDTDZ+bxxnQdJO8YMEZK287UEFaKao2sPfn6JOOkUrJtrfMI2n4x5qseZO+ewI+U V+sm2F0gxQVd2gAJpg9nwrxVJh7uYSBFeoaAaiU7eIHuQmuqb6u1nX6L97EGFiY+ge5N PxIhZ4HoHrLs6li+JJaGdJIcfszlVC/xJTBuuJf/Di/W47ETsqsvwtF9O6yRMlN6rB3f 0rba+9vNZ6W9AbG2et0ENTjXCNFo16/9PVq+WTPrBDX/PhlU8VCfrPLgUY3AUscISNLG b33wIhygmmYWP3G+ttRmQRB6SZIgyiQ9FVSOHzCcUXlEx6K55w8dVawysWw7F8oXk3I4 2Tgg==
X-Gm-Message-State: AOAM533+p2g6fVuEg9cxjeUasgPR0AHOPxdjgOAVcs6TA4x5WPjM9pge P8tgpCZ9JRTUPEcXWLpVjwH1MwmczjyMEVxtKbw=
X-Google-Smtp-Source: ABdhPJwI5UPnh2fFonXPAIx2QdLy0R2vh6OiIMnMMO+JhhcW5RC4oXvb2GHfWi1/xNfiKtoCTa5RcvrLuBMrq0hsGEE=
X-Received: by 2002:a17:902:6a84:b029:d8:c8a9:e04d with SMTP id n4-20020a1709026a84b02900d8c8a9e04dmr1143639plk.74.1605150070721; Wed, 11 Nov 2020 19:01:10 -0800 (PST)
MIME-Version: 1.0
References: <CAD6AjGR-NE_sJ_jp7nAT6OvNkcdE9qoWuGEiiVW7r9YtsQvbbw@mail.gmail.com> <43ebd660-3df6-bc9c-2ef3-bbfd72a64229@gmail.com> <CAD6AjGQRyDDhVtunyCrWDBABG576oi=5xd1Lmz5=QicOJ6YsNA@mail.gmail.com> <d591a034-b629-cf6a-8211-b9243528db79@gmail.com> <CAD6AjGQaMCS+T-6pV=c7M_DL=qCYSdqrsemE8vUYYyqm5Rv32A@mail.gmail.com> <9dd54921-372f-f029-41ec-8eb00c12158f@gmail.com> <CAKD1Yr05C_rbzigG8H3TbF3NkGg6oj7L4+LVtASdVmpdZ2Aaeg@mail.gmail.com> <15d69b19-9e6f-ff4e-70d7-025af8d33590@gmail.com> <CAKD1Yr2ReWf5SHKWJL6=zx8kKb92yq0YbUcBiu_kJ-t=e8BDhg@mail.gmail.com> <a0196c54-cd33-2cc8-45e3-ead6e14ef9da@gmail.com>
In-Reply-To: <a0196c54-cd33-2cc8-45e3-ead6e14ef9da@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 11 Nov 2020 22:00:59 -0500
Message-ID: <CABNhwV3SU5PYr+uG3jW_-HdgYsXRKR0Cr0_WVq6U3JR5BKuApw@mail.gmail.com>
Subject: Re: 64share v2
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man <ipv6@ietf.org>, Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary="000000000000c6d0d605b3e01ffa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Pn5bEY7_Ie5PBO5OWc4De5C2xEc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 03:01:13 -0000

On Wed, Nov 11, 2020 at 9:36 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 12-Nov-20 14:33, Lorenzo Colitti wrote:
> > On Thu, Nov 12, 2020 at 5:21 AM Brian E Carpenter <
> brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> >
> >     I disagree. The reality is that 3GPP has already overridden the
> intention
> >     of RFC4861 by misusing an RA/PIO as a prefix delegation mechanism.
> That's
> >     a clever trick, but it is a trick, and Cameron's proposal simply
> extends
> >     that trick a bit.
> >
> >
> > That's incorrect. 3GPP used RFC4861 as the IETF asked it to use it - to
> assign a /64 to the phone because a single /128 was not enough. The phone
> is free to use as many interface IDs within that /64 as it wants.
>
> I can't find any words in RFC 4861 that describe an RA/PIO as assigning or
> delegating a prefix. A PIO announces that a prefix is in use on the link,
> as far as I understand it, and that is very different from assigning or
> delegating it.
>
> Note, I'm not saying that this usage is harmful within a PDP context, but
> it is definitely not described by RFC 4861. It is described by RFC6459, but
> that's Informational.
>
> > If you're referring to RFC 7278 (which is an IETF document, not a 3GPP
> one), then I don't see how that conflicts with the intention of RFC 4861.
> All interface IDs are still 64 bits. It's conceptually the same as saying
> that the /64 is actually on the phone's downlink interface, and the phone's
> uplink interface is unnumbered.
>
> Sure, the sidestep occurs in Cameron's draft that extends the usage to
> prefixes shorter than /64. Again, I'm not saying that's harmful. But let's
> not pretend that it's normal usage of RFC 4861 that would work on an
> Ethernet.


    Are you saying that with 64share v2 any prefix length could be sent via
slaac RA.  The A flag would is set for slaac so that side step won’t work
as far as I can tell without updating RFC 4861.  Current 64share 7278 with
64 bit prefix but anything shorter would not work without updating the IETF
standards.

The side step occurring in 7278 is a RA delegation of the radio /64 prefix.

Am I missing something?

>
>
>     Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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