Re: [v6ops] "Getting IPv6 Private Addressing Right" AusNOG presentation

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 18 September 2019 08:34 UTC

Return-Path: <alexandre.petrescu@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 E3F471201DC for <v6ops@ietfa.amsl.com>; Wed, 18 Sep 2019 01:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham 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 HxmdDuvQNWIU for <v6ops@ietfa.amsl.com>; Wed, 18 Sep 2019 01:34:39 -0700 (PDT)
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 D13E612001A for <v6ops@ietf.org>; Wed, 18 Sep 2019 01:34:38 -0700 (PDT)
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 x8I8YanB142000; Wed, 18 Sep 2019 10:34:36 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 10C562030E6; Wed, 18 Sep 2019 10:34:36 +0200 (CEST)
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 055DF200B3B; Wed, 18 Sep 2019 10:34:36 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x8I8YZYN030154; Wed, 18 Sep 2019 10:34:35 +0200
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Gert Doering <gert@space.net>, v6ops list <v6ops@ietf.org>
References: <CAO42Z2yJWgswT6+RYqunqYX70tg4BY3s3rsBGscvNfi-+uFqcQ@mail.gmail.com> <1a8cd6c2-7c5a-3260-7027-fd84a89945bd@gmail.com> <20190917115032.GM55186@Space.Net> <30fe8da2-bd72-1be4-fbb6-5ebdeb451771@gmail.com> <20190917125542.GQ55186@Space.Net> <6ba597e9-b622-6c22-7e3b-40d11f4270a4@gmail.com> <20190917133033.GR55186@Space.Net> <1f5b2b0e-ca2b-7883-5967-2b32eb94ae10@gmail.com> <CAO42Z2w2eH3jk9k_Yb2FfuC15gfKZo8op8Mgk9OunT=3ayH0sA@mail.gmail.com> <e7315c76-dc3c-7d6d-cda7-24697c9e32b4@gmail.com> <CAO42Z2xwvgjWTFwE7i=RJAeq-jFpdvcsNj7-Zn1SDBfBgdF-3Q@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <ebbe7c01-207b-d002-84be-06c66b9a0485@gmail.com>
Date: Wed, 18 Sep 2019 10:34:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAO42Z2xwvgjWTFwE7i=RJAeq-jFpdvcsNj7-Zn1SDBfBgdF-3Q@mail.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/v6ops/THNBqZJS6o7lvNmrSqqCE9cmP8U>
Subject: Re: [v6ops] "Getting IPv6 Private Addressing Right" AusNOG presentation
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: Wed, 18 Sep 2019 08:34:41 -0000


Le 18/09/2019 à 10:23, Mark Smith a écrit :
> On Wed, 18 Sep 2019 at 17:35, Alexandre Petrescu
> <alexandre.petrescu@gmail.com> wrote:
>>
>>
>>
> 
> <snip>
> 
>>>
>>> I contributed to 64share because I thought it was good to have some of
>>> these options written down.
>>>
>>> The trouble with it is that it's trying to be half way between full
>>> routing between interfaces and bridging between interfaces. That doesn't
>>> really fit with our models and protocols, which is why it has issues.
>>>
>>> It's no more than a workaround.
>>
>> I think we can write down like that in the draft, if you do not mind.
>>
> 
> 
> Well that could be written a bit less informally.
> 
> The Intro text from the 64share RFC could probably be quoted exactly,
> as that sums up why 64share (share64) was developed instead of using
> existing DHCPv6-PD.
> 
>>>
>>> DHCPv6-PD is the proper solution, however the real issue is caused by
>>> how 3GPP do entire device version number snapshots.
>>
>> I did not know 3GPP specs were oriented more towards device, whereas I
>> agree IETF specs are more protocol oriented, with ends of protocols.
>>
>>>   From the RFC Intro:
>>>
>>> "3GPP mobile cellular networks such as Global System for Mobile
>>>      Communications (GSM), Universal Mobile Telecommunications System
>>>      (UMTS), and Long Term Evolution (LTE) have architectural support for
>>>      IPv6 [RFC6459], but only 3GPP Release-10 and onwards of the 3GPP
>>>      specification [TS.23401] supports DHCPv6 Prefix Delegation [RFC3633]
>>>      for delegating IPv6 prefixes to a single LAN link."
>>
>> I agree.  This TS23401 spec from June 2019 says "The UE uses DHCPv6 to
>> request additional IPv6 prefixes (i.e. prefixes in addition to the
>> default prefix)".
>>
>> It is not yet the best way to do it (why two prefixes?), but it is a way
>> forward.
>>
>> Our implementation requests a /56 and makes several /64s.  One of those
>> /64s could be used on the egress interface, but I do not see the
>> necessity for a whole /64 on the egress.  The computer just needs one
>> address on that interface.
>>
> 
> It should support more than one address, because that supports IPv6's
> interface multiple addressing capability, which is needed for things
> like RFC 4941, privacy addresses.

Ah right, that is it, the privacy aspect.  So indeed an IoT Router may 
need a /64 for its egress interface.

Even so, a /56 could cover all the /64s needed by an IoT Router.  I do 
not understand why 3GPP tells there is a /56 and a /64 'default' 
allocated to an UE.  It says: "The UE uses DHCPv6 to request additional 
IPv6 prefixes (i.e. prefixes in addition to the default prefix)".

> These are the sorts of areas where there seems to be a much more
> prescriptive approach of 3GPP over both the link and the device
> behaviour. These specifications can then create IPv6 constraints and
> limitations, such as the one that 64share needs to exist to overcome.

I think I agree.

> The IETF way to support a 3G would have been to write a IPv6 over 3G
> link support RFC, limited to 3G specific link characteristics only,
> with no more than a fairly small number of pages that provided enough
> specification to get IPv6 boot strapped over the link. See RFC 2464
> (IPv6 over Ethernet) and RFC 5072 (IPv6 over PPP) for examples.

I agree.

There is no IPv6-over-3G spec in the same vein as RFC2464 or RFC5072 at 
IETF, and there should be one.

Alex

> 
> Once that basic capability of sending IPv6 packet over a link type
> exists, then other IPv6 protocols take over that work regardless of
> the specific link type e.g. RS/RAs, ND NS/NA, DHCPv6 etc. At those
> layers above the link-layer, there is no device type specific
> behaviour. It's just another link the device can send IPv6 unicast or
> multicast packets over.
> 
> Regards,
> Mark.
> 
> 
>>> On a normal computer, if you want DHCPv6-PD support, you just install it
>>> and try to use it. It generally works or it doesn't.
>>>
>>> On a 3GPP "Smartphone", which is actually just a computer too with a
>>> specific type of link-layer interface, you can't install new software to
>>> give it a new network capability, because then it doesn't comply with
>>> the 3GPP spec. it is supposed to.
>>>
>>> The versioning model of 3GPP is whole of device, where as the IETF model
>>> is per protocol. That means having to come up with non-IETF spec
>>> compliant work arounds like 64share when there is a conflict in these
>>> models.
>>>
>>> It would be better if 3GPP started to think of smartphones as portable
>>> personal computers that happen to be able to make phone calls, and
>>> allowed them to follow the more discrete and incremental protocol
>>> version model.
>>
>> I agree.
>>
>> Alex
>>
>>>
>>> As that industry has more than a century of think of devices in
>>> end-users hands as voice devices first, and anything else as an add on
>>> (like running non-voice apps), I'm not sure we'll ever see them change
>>> from this versioning model.
>>>
>>> Regards,
>>> Mark.
>>>
>>>
>>>      Alex
>>>
>>>      _______________________________________________
>>>      v6ops mailing list
>>>      v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>      https://www.ietf.org/mailman/listinfo/v6ops
>>>
>