Re: Extending a /64

Ole,

Le 08/11/2020 à 11:25, otroan@employees.org a écrit :
> 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
> 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)

I suggest to add:
h) Variable SLAAC (openbsd and linux implementations)
i) Mobile IP with NEMO extensions.
j) IP encapsulation and a VPN gateway

> 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

I would like to suggest a requirement R-5: do not use encapsulation and 
do not use VPN gateways or Home Agent services.  The reason is twofold: 
these rdv points represent additional single points of failure. The 
second reason comes from an observation of current work situation: very 
often in these electronic virtual meetings the involvement of VPN 
gateways induces latencies and breaks audio, or reduces its quality.

Alex

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