Re: 64share v2

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 11 November 2020 09:03 UTC

Return-Path: <alexandre.petrescu@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 25DCD3A0D91 for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 01:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.67
X-Spam-Level: *
X-Spam-Status: No, score=1.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 3oz378ACvoJU for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 01:03:42 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245643A0D89 for <ipv6@ietf.org>; Wed, 11 Nov 2020 01:03:41 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AB93dVd032617 for <ipv6@ietf.org>; Wed, 11 Nov 2020 10:03:39 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07690201B2D for <ipv6@ietf.org>; Wed, 11 Nov 2020 10:03:39 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F1043200C30 for <ipv6@ietf.org>; Wed, 11 Nov 2020 10:03:38 +0100 (CET)
Received: from [10.11.240.33] ([10.11.240.33]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AB93cvs030518 for <ipv6@ietf.org>; Wed, 11 Nov 2020 10:03:38 +0100
Subject: Re: 64share v2
To: ipv6@ietf.org
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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <2febae80-9b65-703c-8210-0cc39bbeab98@gmail.com>
Date: Wed, 11 Nov 2020 10:03:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2
MIME-Version: 1.0
In-Reply-To: <9dd54921-372f-f029-41ec-8eb00c12158f@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wuLEUMxC_o3Q5Wd-bLpqhdJPIsU>
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: Wed, 11 Nov 2020 09:03:44 -0000


Brian,
I mainly agree with the potential direction, but still.

Le 11/11/2020 à 01:00, Brian E Carpenter a écrit :
> Thanks for the capture. So, a friendly amendment to your draft:
> 
> OLD:
>     As described in [RFC 6459], the 3GPP network may only assign a single
>     off-link /64 per bearer attachment.  This assignment is passed from
>     the gateway to the UE using a router advertisement (RA)[RFC 4861].
>     This memo requests the 3GPP to change this requirement to allow any
>     prefix size less than or equal to 64 be advertised by the 3GPP
>     gateway RA.
> 
> NEW:
>     As described in [RFC 6459], the 3GPP network may only assign a single
>     off-link /64 per bearer attachment.  This assignment is passed from
>     the gateway to the UE using a router advertisement (RA)[RFC 4861].
>     This usage of RA to effectively signal prefix delegation is
>     applicable in the 3GPP context but not on traditional LANs.
> 
>     This memo requests the 3GPP to change this requirement to allow any
>     prefix size less than or equal to 64 be advertised by the 3GPP
>     gateway RA. It also, for this purpose only, overrides the implication
>     of [RFC 4291] and [RFC 4861] that subnet prefixes in RAs are
>     always /64.

And, should the UE negotiate an IID of length different than 64?  The UE 
negotiation of an IID happens below IP, it happens between UE and GGSN, 
and is specified by 3GPP.  Sometimes IPv6CP of PPP protocol can also 
negotiate an IID.

Should that IID be of which length?

Or should the UE extract a /64 out of that /56, create an RA, send it to 
itself, to form an address for itself?

Or should the UE use the received prefix and pad with 0s between /56 and 
/64 to form an IID and then an address?

Alex

> 
> Regards
>     Brian
> 
> On 11-Nov-20 12:37, Ca By wrote:
>>
>>
>> On Tue, Nov 10, 2020 at 3:06 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>
>>      On 11-Nov-20 11:03, Ca By wrote:
>>      >
>>      >
>>      > On Tue, Nov 10, 2020 at 1:49 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com> <mailto:brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>> wrote:
>>      >
>>      >     On 10-Nov-20 21:10, Ca By wrote:
>>      >     > Folks,
>>      >     >
>>      >     > In an effort to progress the conversation, i created a simple and rough pre-00 i-d (as ietf is not accepting submissions now) for your review and comment
>>      >     >
>>      >     > https://pastebin.com/duyYRkzG
>>      >
>>      >     I'm having difficulty reconciling that with what I read at:
>>      >     https://mailarchive.ietf.org/arch/msg/v6ops/0d7lSiP_78td3vWBlMnVvmp7UAo/
>>      >
>>      >
>>      >     If that email is correct, the 3GPP model is tightly bound to
>>      >     the /64 boundary and to the notion of giving a single address
>>      >     and predefined Interface ID to the UE.
>>      >
>>      >
>>      >
>>      > This is not a correct summary. I believe rfc6459 describes it clearly. The ue receives an off-link  /64, the iid is simply a hint and typically not used. This is why rfc7278 works.
>>
>>      Thanks for the clarification.
>>
>>      >
>>      >     Also, since /64
>>      >     is still fixed by the addressing architecture, and RA PIOs
>>      >     are constrained by that architecture, I don't understand how
>>      >     a UE can be "given a prefix such as a /56 using RA".
>>      >
>>      >
>>      > The i-d is to requests the 3gpp to make a change to allow < 64 via RA
>>
>>      RFC 6459 says "The 3GPP network allocates each default bearer a
>>      unique /64 prefix" but doesn't seem to explain how that prefix is
>>      conveyed to the UE. It does say that the suggested IID is conveyed
>>      by "layer-2 signaling". If the allocated prefix is only conveyed
>>      by an RA/PIO there is something unconventional going on, i.e. the
>>      UE is allowed to deduce *from the RA* that it owns the entire /64,
>>      which is not all what applies on a conventional LAN. (Yes, I do see
>>      how that enables RFC 7278, but this unconventional semantic is
>>      not all obvious from RFC 6459.)
>>
>>
>> Yes, it is conveyed only using RA
>>
>> On the wire(less), it looks like this (image of pcap)
>>
>> https://imgur.com/a/p6dBy3d
>>
>>
>>      So if that's right, I think we do have a problem. If we (=IETF+3GPP)
>>      decide to allow <64 prefixes in RA/PIO during the establishment of
>>      a PDP context, that seems to be not only an unconventional use
>>      of RA but also one that directly contravenes the /64 rule in the
>>      addressing architecture.
>>
>>      I'm not against either of those things, but I think some very
>>      explicit wording is needed to explain what's going on and how it
>>      is different from a conventional LAN.
>>
>>         Brian
>>
>>      >
>>      >
>>      >
>>      >     Perhaps someone familiar with 3GPP internals, e.g. the authors
>>      >     of RFC6459, can comment?
>>      >
>>      >     Regards
>>      >         Brian
>>      >
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>