Dunn, Jeffrey H. wrote:
> My basic question is: What basic engineering problem is solved by
> proscribing non-64 bit prefixes?
>
There's one definite engineering/operational problem, for which non-64
bit prefixes are needed to solve:
Managing combined (dual-stack) IPv4 and IPv6 server infrastructure,
where the IPv4 prefixes are necessarily constrained in size and
proximity, due to CIDR rules.
Here, "management" involves more than just assigning addresses to
machines - it means configuring routers, load balancers, firewalls,
back-office systems, billing systems,
monitoring systems, DNS, you name it.
Here's why it is non-trivial...
In a given IPv4 assignment, utilization needs to be extremely dense in
order to meet RIR assignment criteria.
This leads to variable-length subnet mask (VLSM) arrangements, of the sort:
/24 - broken into prefixes all the way down to /29's or even /32's, e.g.
.0/24 ->
.0/27
.32/28
.48/29
.56/29
.64/26
.128/28
.144/28
.160/28
.168/29
.176/29
.184/29
.192/27
.224/28
.240/29
.248/29
Repeat this with a plethora of prefixes subnetted in similar fashion,
the total quantity of which are not generally known apriori, as this is
a moving target.
Possibly involving blocks ranging from /24, to /19, to /16, to /14 or
bigger.
When managing such a scheme alongside an IPv6 prefix which needs to be
assigned to the same set of servers, which are all dual-stack, the
*number* of prefixes,
their *relative* numbering, and the host *addresses* within the
prefixes, it is quickly apparent that use of only /64 prefixes makes for
a management nightmare,
particularly if renumbering of prefixes and/or servers occurs, e.g.
re-balancing the VLSM arrangement itself in IPv4-land.
Using parallel VLSM prefix schemes in IPv6, on the other hand, trivially
permits management of dual-stack infrastructure, without any significant
down-side,
and without the wasteful assignment of /64 prefixes that would otherwise
need to occur.
Keep in mind that the scalability of the IPv6 DFZ, pretty much depends
on avoiding individual sites getting multiple IPv6 assignments directly
from RIRs on an ongoing basis.
Assignments to end sites from LIRs, however, is not as big an issue --
IFF they are given appropriately-sized blocks, avoiding triggering of
new RIR-to-LIR assignments.
The existence of even a single use case, such as this, I would hope is
sufficient to justify non-64 bit address considerations in IETF RFCs/BCPs.
Brian Dickson
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
