Re: what problem is solved by proscribing non-64 bit prefixes?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: what problem is solved by proscribing non-64 bit prefixes?



Pekka Savola wrote:
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.

I don't understand why *relative* numbering (i.e: overlapping subnet masks) is important in IPv6, and I'm not sure if I see the case even for v4.  Could you enlighten me?

I assume you refer to a scenario where on the same broadcast domain there are hosts which are configured with say A.B.C.0/24 length, and some others are configured with, say, A.B.C.D/28 prefix length.

Actually, that isn't the scenario. I should have gone into more detail in the example(s).

The issue isn't an "in IPv6" issue, it is a "while doing dual-stack on a whole lot of infrastructure which is statically numbered".

Example - unique broadcast domains per subnet, with statically assigned IPs only, and dual-stack configurations on routers and hosts.

Consider an example pair of prefixes:
  • a globally announced IPv4 route: 192.168.42.0/24
  • a corresponding IPv6 route: FEC0:192:168:42::0/64
  • (for this example we use rfc 1918 addresses and site-local IPv6 addresses)
If we have subnets 192.168.42.80/29 and 192.168.42.128/25 connected on an edge router, on two different Ethernet ports of some flavor,
we would ideally also have corresponding IPv6 subnets that are algorithmically derived from the IPv4 subnets.

For one example mapping:
  • The subnets are numbered identically, after converting to hexadecimal
  • The prefix lengths are 128 - (32 - n), i.e. 96+n, when the original IPv4 prefix length was /n
  • FEC0:192:168:42::50/125 and FEC0:192:168:42::70/121.
  • Individual hosts have the same last octet (albeit in hex rather than decimal).

For a different example mapping:
  • the prefix portion gets shifted left 4 nibbles (16 bits)
  • the prefix size is a fixed value (/112)
  • the hosts are numbered in hex-coded decimal
  • FEC0:192:168:42::80:0/112 and FEC0:192:168:42::128:0/112.
  • Host addresses would be, for example, FEC0:192:168:42::80:81 (through *:87), and FEC0:192:168:42::128:129 (through *:255), all with mask of /112.
  • This would handle IPv4 prefixes up to /16 in size, and if there were a need to go bigger,
  • e.g. if the IPv4 prefix was /8 in size, make everything mask /104 or /96 (96 is a bit easier to comprehend)

There is no overlap within IPv6 or within IPv4.

There is, however, an intended 1:1 match-up between each IPv4 address & prefix, with a suitable IPv6 address and prefix.

The algorithmic nature of the match-up is to facilitate simpler designs for management systems and/or human operator stuff.

This is especially important considering the number of different *kinds* of things were multiple addresses/prefixes need to be managed - routers, hosts (various O/S's), firewalls, databases, etc.

I hope this is a little more clear than my earlier brief description... :-)

Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.