Re: Extending a /64

On Sun, Nov 8, 2020 at 2:25 AM <otroan@employees.org> wrote:

> Starting a new thread.
>
> A problem described in variable-slaac is:
>
> "It should be possible to extend an end-user network that is only assigned
> a /64"
>
> I believe that is a problem worth looking at.
> This problem is not only restricted to the mobile access case, think
> connecting a host with VMs to a link.
>
> The address delegation to a site problem is intertwined with the
> autonomous networking problem of the site itself. The IETF solution is
> DHCPv6 PD + HNCP. The expectation of addressing of a network is that the
> addresses are long-lived.
>
> There are many potentional solutions:
>
> a1) ask the network operator for more address space.
> a2) change provider
> a3) introduce government regulation
> b1) steal the uplink /64 (64share)
> b2) steal multiple /64s from uplink

As discussed on the other thread with Joel, b2 appears to solve the problem
in mobile.

RA sending a < 64 off-link prefix allows the UE to have a number of 64s
effectively delegated to it, for which the UE can assign to down stream
connected interfaces or even further delegate via dhcp-pd

This way, my provider gateway can give /60 via RA to the 5G UE, the UE
acting as a dhcpv6-pd server can pass a /61 to the google wifi PD client.

> c) overlay. use e.g. LISP to tunnel across the access ISP to connect to an
> ISP that support multi-homing and larger address space.
> d) MultiLink Subnet Routing. I.e. let a single /64 span multiple links.
> draft-thubert-6man-ipv6-over-wireless, draft-ietf-ipv6-multilink-subnets
> e) NAT
> f) P2P Ethernet. Hosts are not on the same physical link, so let's stop
> pretending they are. A consequence of that is that links don't need
> subnets. Only assign addresses to hosts. draft-troan-6man-p2p-ethernet-00
> g) extend the /64 bit boundary. HNCP implementations do /80s I think
> (forces DHCP for address assignment)
>
>
> Requirements:
> R-1: Permissionless. Not require an action on the network operator
> R-2: Arbitrary topology
> R-3: Long-lived address assignments
> R-4: Support bad operational practice: flash renumbering / ephemeral
> addressing
>
>
> Is there interest to work on this problem?
> If so, suggestions for next steps?
>
> Best regards,
> Ole (without any particular hat on)
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>