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

From: Mark Smith <[email-masked]>
Date: Tue, 17 Sep 2019 19:17:19 +1000

Hi,

I've noticed on a number of occasions now over a number of years that
some people are treating the ULA address space as though it is an
exact duplicate of RFC 1918, and not including a unique Global ID -
typically using all zeros for that part.

So I recently prepared and presented at the AusNOG conference on
"Getting IPv6 Private Addressing" right. My goal wasn't just to
present there, but to also have a slide deck available that describes
exactly why we went away from Site-Locals and why globally unique ULA
prefixes are required.

Feel free to share as widely as possible!

On Slideshare:

https://www.slideshare.net/MarkSmith214/ausnog-2019-getting-ipv6-private-addressing-right

PDF:

http://www.users.on.net/~markachy/AusNOG%202019%20-%20Getting%20IPv6%20Private%20Addressing%20Right.pdf

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Sep 2019 12:28:42 +0200

on slide 66 it shows smartphones each assigned a /64.

This is not the right thing to do, unless one agrees SLAAC should work 
with a /65 as well, for a CPE for example.

One should make one's mind either one of those:
- /64 per smartphone and /65 possible in SLAAC.
- /64 in SLAAC and /63 per smartphone.

Alex

Le 17/09/2019 à 11:17, Mark Smith a écrit :
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 17 Sep 2019 13:50:32 +0200

Hi,

> - /64 in SLAAC and /63 per smartphone.

Or just get over it and use 6share.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Sep 2019 13:56:29 +0200

> Or just get over it and use 6share.

64share can not share a /64 to more than one ingress interfaces, as an 
IoT Router, or a CPE, needs.

Alex

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Sep 2019 22:50:00 +1000

> - /64 in SLAAC and /63 per smartphone.

My goal wasn't to go into detail about that scenario, it was just to
"expand" people's minds beyond the idea of a single IP address per host.

The last section was a bit off topic regarding getting ULAs right, however
as I'd just given an overview of IPv6 multi-addressing, I figured I'd give
people some examples of innovations beyond what they would consider normal.

There's also the limitation that you can't downstream tether via Wifi if
the upstream is also via Wifi, which is the case in this scenario. You'd
need two Wifi radios.

Finally, there's nothing on my diagram to say that there isn't DHCPv6-PD
available via the router, or that the end-user devices aren't running
DHCPv6-PD to acquire a delegated prefix, should you somehow overcome the
Wifi radios problem.

For a bit more context, I did that presentation in about 24 minutes
(limit/goal is 25, leaving 5 minutes for questions), and I budget 10
seconds per slide. So slides 65 and 66 are no more than 20 seconds - just a
very brief overview of the idea.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Tue, 17 Sep 2019 14:55:42 +0200

Hi,

> IoT Router, or a CPE, needs.

You can share the /64 to as many interfaces as you want.

Is "having a larger prefix that you can segment and route" *nicer*?  Yes,
certainly, but that doesn't preclude other approaches from working.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Sep 2019 15:22:13 +0200

> You can share the /64 to as many interfaces as you want.

One can share a /64 to several interfaces as long as they are of same 
technology, so they could be bridged.

One could share a /64 from upstream to an Ethernet and a WiFi downstream 
because these two latter are both using same LLC and can be bridged.

One cant share such a /64 to a downstream WiFi and a downstream 
802.11-OCB because they are not precisely the same LLC, and they cant be 
bridged.  (same problem with downstream Ethernet and Bluetooth, Ethernet 
and USB, and many others).

My IoT Router I deployed in a traffic lights controller has this problem.

> certainly, but that doesn't preclude other approaches from working.

It is indeed an aspect of being nicer.

But there are also places where simply 64share cant work:
- an IoT Router with unbridgeable downstream interfaces.
- an IoT Router with other routers further downstream.  My IoT Router I 
deployed in several cars has this problem.

Alex

---

From: Gert Doering <[email-masked]>
Date: Tue, 17 Sep 2019 15:30:33 +0200

Hi,

> and USB, and many others).

Sure you can... ND proxy, etc.

I didn't say "bridge" on purpose

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Sep 2019 15:36:03 +0200

> Sure you can... ND proxy, etc.

ND proxy, or lack of it on IoT Router, has other inconvenients and 
advantages that we could discuss.

> I didn't say "bridge" on purpose

I see, I agree that word was missing from what you said, so I should 
have assumed you thought rather ND proxy or other non L2 bridging.

Remark neither 64share nor ND proxy are Standards.

Alex

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Sep 2019 10:38:15 +1000

> Remark neither 64share nor ND proxy are Standards.

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.

DHCPv6-PD is the proper solution, however the real issue is caused by how
3GPP do entire device version number snapshots.

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

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.

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.

---

From: Ca By <[email-masked]>
Date: Tue, 17 Sep 2019 18:23:59 -0700

I

On Tue, Sep 17, 2019 at 5:38 PM Mark Smith <[email-masked]> wrote:

>
>
> On Tue, 17 Sep 2019, 23:36 Alexandre Petrescu, <
> [email-masked]> wrote:
>
>>
>>
> 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.
>

The models may be wrong.  Or, as some smart person said, “all models are
wrong, some are models are useful”

> It's no more than a workaround.

Eh. It may be time to update that perspective as 64share is simply how
tethering is done on millions of Android and Apple devices.  I think it is
now fair to say, for mobile, DHCPv6 a solution to a problem users /
providers /  the market does not have ha e

> 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

Apple and the other OEMs do what they want and do not follow 3gpp blindly.
64share and 464xlat never appeared in a 3gpp doc, yet both are deployed in
many 3gpp networks n

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Sep 2019 09:35:20 +0200

Le 18/09/2019 à 02:38, Mark Smith a écrit :
> 
> 
> On Tue, 17 Sep 2019, 23:36 Alexandre Petrescu, 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 

I think we can write down like that in the draft, if you do not mind.

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

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

> give it a new network capability, because then it doesn't comply with 
> the 3GPP spec. it is supposed to.
> 
> 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.
> 
> 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
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Sep 2019 09:39:42 +0200

Le 18/09/2019 à 03:23, Ca By a écrit :
[...]
> tethering is done on millions of Android and Apple devices.  I think it 
> is now fair to say, for mobile, DHCPv6 a solution to a problem users / 

I will not argue, even though it is a topic important to me.

We will write down in the draft a perspective in which 64share is 
deployed on many smartphones; we will write down that some opinions 
consider DHCPv6 to be a solution to a problem users/providers/markets 
does not have.

I let you know here that I do have the problem of running 64share and 
464xlat in cars.

Thank you for the comments.

Alex

> 
> 
>     DHCPv6-PD is the proper solution, however the real issue is caused
>     by how 3GPP do entire device version number snapshots.
> 
>      From the RFC Intro:
> 
>     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.
> 
> 
>     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.
> 
>     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.
> 
> 
> Apple and the other OEMs do what they want and do not follow 3gpp 
> blindly. 64share and 464xlat never appeared in a 3gpp doc, yet both are 
> deployed in many 3gpp networks n
> 
> 
>     Regards,
>     Mark.
> 
> 
>         Alex
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Sep 2019 18:23:47 +1000

On Wed, 18 Sep 2019 at 17:35, Alexandre Petrescu
<[email-masked]> wrote:

<snip>

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

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Sep 2019 10:34:35 +0200

> 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)".

> limitations, such as the one that 64share needs to exist to overcome.

I think I agree.

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