Re: Extending a /64

Cameron,

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

Right, although quite a bit of work would be required to make b2 a robust solution.
Not unlikely the end result would be not too dissmilar to DHCP PD. ;-)

I think we all agree that we want to avoid link-specific behaviour. E.g. that an RA and its contents have a different meaning on 3GPP mandated links versus all other datalink types.

Cheers,
Ole

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