Re: Re: “DHCPv6, SLAAC, Static Day X - 17 year interoperability issue” 2nd issue

[Gyan Mishra <[e-mail]>]

In-line

On Mon, Nov 9, 2020 at 9:55 PM Michael Richardson <[e-mail]>
wrote:

>
> Gyan Mishra <[e-mail]> wrote:
>     > This issue exists with any deployments where the operator would like
> to
>     > deploy >64 prefix length host subnets at data center or access layer
> and
>     > this could be an enterprise or service provider use case where the
> router
>     > infrastructure is statically configured so no PD here.
>
> I would claim that the next useful prefix length after 64, is 128.
>
> In DC situations, there are really no LANs (i.e. no big yellow cables with
> vampire taps), just p2p TX or FX ethernet all over the place.
>
> It would be great to understand your DC use case better.


   Gyan> For operators worldwide from my experience the last 20+ years
working with IPv6 of what has been deployed and proliferated around the
globe as far as prefix lengths is as follows:

Defacto standard for operators both enterprises and service providers.

/128 for loopbacks
/127 per RFC 6164 for P2P
/126 for P2P prior to 6164

Infrastructure subnet sizing based on number of hosts on the subnet.

/64 - /125

-Firewall VLAN - This could be a shared firewall trusted or untrusted VLAN.
- Router to Router shared backbone
- Load Balancer VIP vlan
- Content engines
-VPNs clusters
- Proxies

The main best practice guidelines used by operators is to make the subnet
sizing manageable with hard limit on the number of allowed hosts on the
subnet, thereby creating a hard ND cache size limit, and not rely on
software soft knobs to manage the ND cache.  Also operators requirement as
part of ND cache management is to be able to easily scan critical
infrastructure subnets.

So this concept of hard limiting can be applied to Data Center subnets
creating ND cache hard limits on the subnet sizing using >64 prefix lengths.
>From a security and management perspective for operators having the
critical infrastructure secure and easily scannable as well as the hard ND
cache limit for operators provides the much needed and necessary data
center stability.  So this is all accomplished today by static
configuration on the servers as static allows any prefix length.

For access infrastructure same concept applies for hard limit on ND cache
management, and subnet scanning capabilities for stability by deployment of
>64 prefix length DHCPv6 scopes RFC 8415 which supports any prefix length.

So now the proliferation of >64 prefix lengths is out there deployed by
Verizon as well as other operators I have worked with worldwide.

My guess is when the original IPV6 addressing specification was written if
the founders did not want anyone to use >64 prefix lengths they should have
extended the 64 bit IID boundary restriction to static and DHCPv6 stateful.

The net-net end result of this predicament for operators worldwide that
would like to use >64 prefix, as long as the subnet is deployed to network
infrastructure and they can guarantee in their deployments that there will
never be slaac hosts that has the 64 bit IID boundary then the impact is
reduced to only those scenario where slaac devices are in the mix.

So network infrastructure can and does use without impact to routing as any
prefix length 1 to 128 is routable, so from an impact perspective,
infrastructure is fine and can continue to go crazy with vlsm as it has
been doing for 20+ years and design the IPv6 addressing schema with >64
prefix length however they desire.   No issues.

For Data Centers as long as static is the guaranteed only means of
addressing on data center subnets no impact to operators here as well using
>64 prefix lengths.

Data Centers may also have dedicated mix subnets that have servers with
slaac, as well as dhcpv6 stateful and static, but in these cases now have
to keep the subnet mask at 64.   So in this particular case for operators
hard ND cache rule and security scanning requirement is where if slaac
supported >64 prefix lengths comes into play, and  that would allow mix of
the 3 addressing types on the same subnet if RFC 4291 was updated
eliminating the 64 bit IID boundary.

Same goes for access layer where you have a mix of the three addressing
types static DHCPv6 and slaac and have to use /64 due to slaac fixed 64 bit
IID restriction.  So here also is the gap of not being able to support >64
prefix lengths.

I know there are surveys of the IPv6 deployments related to vlsm usage,
however as surveys go,  they are a random sampling and an extrapolation so
you have to take it with a grain of salt is my take.

I think talking to operators like myself and others on list is really the
best way to get a true feeling  and idea of what had been deployed and a
more realistic picture.


Gyan



>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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