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 >>> >
- [v6ops] "Getting IPv6 Private Addressing Right" A… Mark Smith
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Alexandre Petrescu
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Gert Doering
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Alexandre Petrescu
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Mark Smith
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Gert Doering
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Alexandre Petrescu
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Gert Doering
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Alexandre Petrescu
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Mark Smith
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Ca By
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Alexandre Petrescu
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Alexandre Petrescu
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Mark Smith
- Re: [v6ops] "Getting IPv6 Private Addressing Righ… Alexandre Petrescu