Re: 64share v2

[Brian E Carpenter <[e-mail]>]

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.

Regards
   Brian

On 11-Nov-20 12:37, Ca By wrote:
> 
> 
> On Tue, Nov 10, 2020 at 3:06 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 11-Nov-20 11:03, Ca By wrote:
>     >
>     >
>     > On Tue, Nov 10, 2020 at 1:49 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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
>     >
>