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

Mark Smith <markzzzsmith@gmail.com> Wed, 18 September 2019 08:24 UTC

Return-Path: <markzzzsmith@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 1C11312093B for <v6ops@ietfa.amsl.com>; Wed, 18 Sep 2019 01:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 pXMewexI23i8 for <v6ops@ietfa.amsl.com>; Wed, 18 Sep 2019 01:24:14 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 64E871201DC for <v6ops@ietf.org>; Wed, 18 Sep 2019 01:24:14 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id c10so5560525otd.9 for <v6ops@ietf.org>; Wed, 18 Sep 2019 01:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NSwgw08GxLaflfCDiHT0IY5JiweMzQB3r2ZnziedV1U=; b=E/PDw64kSyeV8GR+snD78YJsy0VghIj+3qGvKCRG30rMzEI2CeWoUjWM5CmYeZbruP TuplrLndZB4jm2ccTtl44WxSI25jfnosj4FwVSGI9qhCahB5F/IX75odBwqWo96hfAKr 2GaWLZgxPc95RmR6Xg5WMZcBgSlZEY58kdEs65aLrueklB3tv0M4wu01DBpT+jBuEfMs +rd1JKH69IVW8FC5QgaVTAVpUObJQeU03pSvEaVWmPmGCw63xMVAoK+0OLfZND0MdO0l JQQVreJbGpO0/0A6ywKYzSCUxkDoAZda3a28RVNn3FTDLNTPIXrbODTXMAR1fBrygBnT RiDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NSwgw08GxLaflfCDiHT0IY5JiweMzQB3r2ZnziedV1U=; b=NzyZmAYucOftv+N+ybPTHO6/LCerkqigZJdgyTcZl28GUXCUeAjzjyydtZk/DTlUve gZDssuJMOWm0PyjtquSHBwqTuicTVjlERipMtk1+NrNAIvSZiLpFsUXOk3lqM7AGkhhT sUN8uUUB0rGPgD6/6EZ+K8g2d+Qwai3pWe3H0iQVwEEDqQJITZsHtmo/G1bzdlpyeELv aNcypwfirQNnh7qSqQNA5x0h2MrxYxziJM53fVkblfS91Qzhg5xfrF5o7UmlT+qJdhpI T1wFJsI1xx2IYDSwctki4cbLZi0YnrhLQDbXfcSRhMa9/fssKUw17GKTuUgKzXG3LAYk RJyA==
X-Gm-Message-State: APjAAAVkpr1TxJbAKVcri/69wC/YTPQd+yV7nlA5TWqU5rn28lS7sSPm hils2hSd/maHrp4UzNU9G+tb5KIPaqmCHG7Pck8=
X-Google-Smtp-Source: APXvYqw9bUuqVO5tDPO6B2mV1JWSXfHfLuTer732pNigfTxciqxOO5qbLpZfXJQtdECm5NfMk2dwxkKCK97slW6q4jk=
X-Received: by 2002:a05:6830:1403:: with SMTP id v3mr107397otp.348.1568795053529; Wed, 18 Sep 2019 01:24:13 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <e7315c76-dc3c-7d6d-cda7-24697c9e32b4@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 18 Sep 2019 18:23:47 +1000
Message-ID: <CAO42Z2xwvgjWTFwE7i=RJAeq-jFpdvcsNj7-Zn1SDBfBgdF-3Q@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Gert Doering <gert@space.net>, v6ops list <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/5rxYU5eKR-ZhBm5IZDA6tGbfcz8>
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:24:16 -0000

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.

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.

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.

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