Re: Extending a /64

On Sun, Nov 8, 2020 at 5: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.

    Gyan> Agreed.  This problem is not restricted to mobile and really
exists for any address allocation use case that involves SLAAC where you
want to segment a /64.  Enterprises have been wanting to do this for
decades to extend their allocation schemes but have been shackled by the 64
bit boundary.

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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD