Home
Vendor
Project
  Phase I
Press
  Phase I
About
You Are Using IPv4 To Access This Site
Your IP Address is: 38.103.63.61

RE: [moonv6] /120 prefix length at UNH

New Message Reply Date view Thread view Subject view Attachment view

From: Tony Hain (ahain@cisco.com)
Date: 10/15/03


moonv6 post from "Tony Hain" <ahain@cisco.com> schultz@io.iol.unh.edu wrote:
> ...
> Didn't we learn anything from being conservative about address allocation
> from IPv4? People are always claiming in technology that we "have enough
> to last forever". That is definitely never the case. I would make the
> argument here that being conservative is always better. Just think of all
> the subnet space we will save in service provider networks by using /120
> or /124.

In the grand scheme of things, it is not that many subnets. Since the long prefix plan does not aggregate across providers, they will each be taking space for their set of subnets.

>
> Do we want people in the technology field referencing the Moonv6 network
> design as a reason that all the IPv6 addresses are depleated? Was there a
> valid reason for /64? I currently fail to understand the logic behind
> that design in core networks with point-to-point links.
>

The long prefix plan says to take them all from a single /64, but that /64 is going to come from a /48 that the provider has to allocate for internal use, and not share with customers. Since they are allocating a /48 anyway, they could just as easily have put a /64 on all the internal links.

> I completely understand RFC 3513, but I think that the above arguments
> may support what we are doing.
>
> I fully encourage discussion around this topic, because I do understand
> there will be many opinions here. This IS setting a precedent, and I
> would like this project to set the correct one.

The real point is to minimize confusion at the daily operations level. Even as we approach 10 years of the CIDR definition, not very many people understand variable length subnetting. Since longer than /64 prefixes doesn't really save any useful space, what is the point in perpetuating confusion? Yes we save a little resource space, but at what ongoing operating cost? The balance we need to be establishing here is that there is substantially more raw resource, so the overly complex processes introduced during the IPv4 conservative mode are both unnecessary, and excessively costly.

Tony

New Message Reply Date view Thread view Subject view Attachment view

This archive was generated by hypermail 2.1.7 : 12/01/06 EST