Subject: Re: Comments on draft-lemon-stub-networks-ps-00

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Nov 2020 17:44:33 +0100

Le 05/08/2020 à 16:20, Ted Lemon a écrit :
> On Aug 5, 2020, at 10:04 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>> Other than HNCP, or more generally, the problem is simply in 
>> allocating a /64 to a stub router.  A stub router that gets 
>> allocated a /64 from the infrastructure will need to form one or 
>> several /65s for its links in the stub network.  Assuming that the 
>> stub router will use SLAAC as known for address auto-configuration 
>> on the links in the stub network, then there is a problem for the 
>> linux Hosts in these links.  The linux Hosts can not self-form 
>> Interface IDs of length 63 (only of length 64 can they form).  In 
>> this way, SLAAC can not be used in the stub networks when the stub 
>> router is allocated a /64.
> 
> Can you expand on this?

YEs.  I reply now because the draft was under work at that time, and now
it went public.  In the Variable SLAAC Problem Statement draft we
describe problems that arise when, for example, 3GPP allocates a /64 to
a vehicle.  In section "3GPP V2I and V2V networking" we describe a
problem of connecting a vehicle to a 4G network.  The vehicle uses a
router that is called a Mobile Router.  It is in essence that same that
one might call a 'stub router'.

> I don’t understand why this would be necessary or desirable. If you 
> mean that the stub router could serve multiple stub networks, that’s 
> not really a new use case—it’s no different than having several stub 
> routers each serving a single stub network, and can be addressed the 
> same way.  I have no interest in opening up the >/64 prefix can of 
> worms, and don’t see it as necessary.

I am not interested in cans of worms either, but I do not understand how
one might think that one could connect a stub network to a 3GPP network.
  All other proposed solutions (other than 64share, Variable SLAAC
proposed in our draft, and NAT) are not possible.

For example, it is not possible to use DHCPv6-PD to connect a stub
network to a 3GPP network.

> 
>> Yes, an ULA prefix makes sense.  But it could also be a globally 
>> unique prefix, provided the infrastructure is disconnected from
>> the Internet.
> 
> Why would that be beneficial? That is, (a) why do we even care about 
> this use case, since it’s addressed by a ULA and doesn’t require a 
> GUA, and

I think one might have an entirely disconnected 5G network.  I mean
disconnected from the Internet.  It is relatively simple and cheap to
make such a network with 5G off-the-shelf equipment.  In it, one might
use ULAs exclusively.

One might care about such a use case without caring to make it
interoperable with the Internet at large, now.  Maybe later.

> (b) what advantage would there be in using a GUA instead of a ULA?

The advantage of using GUAs instead of ULAs in the early stages of
network design is that it will ease the work of connecting it to the
Internet when time comes.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Nov 2020 11:47:33 -0500

> network to a 3GPP network.

Is this for any reason other than that the 3GPP network doesn’t support DHCPv6-PD?

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Nov 2020 18:00:47 +0100

Le 05/11/2020 à 17:47, Ted Lemon a écrit :
> On Nov 5, 2020, at 11:44 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:

Some 3GPP networks do support DHCPv6-PD but there is no terminal 
connecting to it that might take advantage of DHCPv6-PD.

The terminals use chipsets.

The chipsets are made by a few manufacturers.  BAsically all imitate 
just one, the key manufacturer.  It is very important what believes that 
key manufacturer.

The terminals dont support DHCPv6-PD because their chipsets dont support 
multicast, and they also explicitely block UDP port numbers of DHCPv6-PD.
Their chipsets dont support multicast because they dont need DHCPv6-PD.
They dont need DHCPv6-PD because they dont need the variable prefix.
They dont need variable prefixes because, 'by design', prefixes cant be 
anything else than 64bit length.
The prefixes cant be anything else than 64bit length because the IIDs 
cant be anything else than 64bit length, by RFC IPv6 Addr Arch.

That explanation is resumed by the chip designer as 'that is the IPv6 
design'.  That mindset includes arguments that explain that in IPv6 
there is no DHCP and SLAAC took its place.

There is no way to even dream of trying to persuade the key chip 
manufacturer to improve their position to do DHCPv6-PD.

But there is a way to do variable length prefixes in SLAAC _behind_ the 
stub router.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Thu, 05 Nov 2020 18:14:03 +0100

> The terminals dont support DHCPv6-PD because their chipsets dont
> support multicast, and they also explicitely block UDP port numbers
> of DHCPv6-PD.  Their chipsets dont support multicast because they
> dont need DHCPv6-PD.  They dont need DHCPv6-PD because they dont
> need the variable prefix.  They dont need variable prefixes because,
> 'by design', prefixes cant be anything else than 64bit length.
> The prefixes cant be anything else than 64bit length because the
> IIDs cant be anything else than 64bit length, by RFC IPv6 Addr
> Arch.

Maybe somebody can point those vendors to RFC 6177 (which is 9 years old),
which copied from RFC 3177 (19 years old):

"A key principle for address management is that end sites always be
"able to obtain a reasonable amount of address space for their
"actual and planned usage, and over time ranges specified in years
"rather than just months.  In practice, that means at least one
"/64, and in most cases significantly more.  One particular
"situation that must be avoided is having an end site feel
"compelled to use IPv6-to-IPv6 Network Address Translation or other
"burdensome address conservation techniques because it could not
"get sufficient address space.

And later says:

"Although a /64 can (in theory) address an almost unlimited
"number of devices, sites should be given sufficient address
"space to be able to lay out subnets as appropriate, and not be
"forced to use address conservation techniques such as using
"bridging.  Whether or not bridging is an appropriate choice is
"an end site matter.

I.e. the mobile world completely violates those RFCs. If a 9 year old BCP is
violated, then there is no reason to assume that other standards will have
any effect.

One possible way out is to just tunnel traffic to a place that does provide 
enough address space.

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Nov 2020 06:49:42 +1100

> "get sufficient address space.

It could be worth changing that "In practice that means at least one /64"
to "In practice that means a number of /64s".

If people are in a rush they tend to skip the things to think about, and
just go with the recommended minimum, assuming it is a reasonable fit for a
number of common situations.

> One possible way out is to just tunnel traffic to a place that does

I have recently seen a small portable router that establishes an IPv6 VPN
connection than provides the user with a /48, with an annual fee something
like 50 Euros if I recall correctly.

Artificial IPv6 address and subnet scarcity is easily defeated, a provider
is better off being generous and look after their paying customers.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>