Re: 64share v2

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 11 November 2020 00:00 UTC

Return-Path: <brian.e.carpenter@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 00E463A1216 for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 16:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-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 1vQZ_sszgSE6 for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 16:00:54 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 729B33A1215 for <ipv6@ietf.org>; Tue, 10 Nov 2020 16:00:54 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id g7so388339pfc.2 for <ipv6@ietf.org>; Tue, 10 Nov 2020 16:00:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0r5wX9YnzkWQplp3vA2krzfPx0R6dE/jZjO0A0PoX0c=; b=Bnjb4gLcBINH7jOH/PbcR8WkbAlwJnGMzeFTb/0sH9f+KiQ7VmbUOyuWex1id7o87l XeH9ppqCDO+vuoZYgIbjTiOQsS6oP69UpjhKf/FgHo8C9EhLTHb8/pCpB+XLY5it4aGs ZM6Py9/R4Gpp+5nOj7U2U8adM7iw8iuJGQLW/Aq0KWy9aG3h7kAySK1evwY6Q7e/Bpqt vKJy27GsitvdiUZyf1HhWJxXm7/NnyU9zI2/J1hX7P8YJ+VsC3+M080KPr2UhOcgBBm4 DW6xmsN8EZ1Yrsfq4ikhqjT/Cexb/IjcYhECeg3YPBAwroWfQAqcMt1b3Y2sZ/3GyFt6 Bm4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0r5wX9YnzkWQplp3vA2krzfPx0R6dE/jZjO0A0PoX0c=; b=hA0Z01hxt0sUlWJItBgeegrc5Nv7P5VI4Li0LYgihJXy+vwb3Ll5Fqg+oJr41UhRCP aeHGe7lEJ2dSvjKV2arjlM+DcwaEQyvTJ9qaWWVqEYmOGG0ZgtkQJIYfkn4w71hmNY90 dZxo18C2Dxvahb4/CTk9ad5GoKV+porepr5EbvxlEVHDcyBtiw7KhueQW7mI4cc+fRLT 34U191AtbKUnQY1GHHsjuvh2ZXard5mSiLbv4vElN7614U9yjE65+60ONZu2kdjgN3Xp BvPJdW13HeyHeKy/rrve2GOipdqCX5C6yMa4KEsSXzJh+ah9izIHbbM4YLkymYkTmoFW N61A==
X-Gm-Message-State: AOAM532zPJ3OxEKMnvl+1U8ryj6GRsPMpVwhomuKNlWnzJPT7pVl1YW4 OV4/haTAdNE8OgditYxQIVIywbDeONQB8A==
X-Google-Smtp-Source: ABdhPJxKf/SpBtXLN6ftfD9f5EvwyQjzacoRUpgKtIWyY59/a14e06Tr1TKgQqwyWeGEjn+ltQ2YUw==
X-Received: by 2002:a63:f14:: with SMTP id e20mr19983007pgl.52.1605052853354; Tue, 10 Nov 2020 16:00:53 -0800 (PST)
Received: from [130.216.38.121] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.121]) by smtp.gmail.com with ESMTPSA id p11sm106701pgb.67.2020.11.10.16.00.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Nov 2020 16:00:52 -0800 (PST)
Subject: Re: 64share v2
To: Ca By <cb.list6@gmail.com>
Cc: 6man <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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <9dd54921-372f-f029-41ec-8eb00c12158f@gmail.com>
Date: Wed, 11 Nov 2020 13:00:49 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAD6AjGQaMCS+T-6pV=c7M_DL=qCYSdqrsemE8vUYYyqm5Rv32A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/alO4yjNB-2eAS-gTskaEwnw-75g>
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 00:00:56 -0000

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 <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
>     >
>