Re: Addressing plan exercise for our IPv6 course

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

On Fri, 23 Jul 2010 14:48:47 -0400
Joe Maimon <jmaimon () ttec com> wrote:

> Owen DeLong wrote:
> > On Jul 22, 2010, at 9:51 PM, Joe Maimon wrote:
> >
> > >
>
> > > Funny how so much concern is given to eliminating the possibility of end users returning for more space, yet for 
> > > ISP's we have no real concern with what will happen when they near depletion of their /32 what with /48s to some 
> > > thousands customers, aggregation, churn, what have you.
> > There's no need to give it a lot of concern because that process is pretty well understood and not particularly 
> > different from the current process in IPv4.
>
> There are a whole lot of organizations who do not view getting IPv4 from 
> ARIN as particularly easy or well understood. Whether IPv6 requests will 
> be better or worse for more or less of the population is completely 
> unpredictable at this time.
>
> My point is that very little concern is being given to them and all of 
> it to the end user, who all understand how to contact their service 
> provider to request more service.
>
>
> > When an ISP runs out, they apply for more from either their upstream, or, their RIR. Just that simple.
>
> When an end user runs out, they apply for more from either their 
> upstream, or, their RIR. Just that simple.

Well my point isn't about how simple it is. It is how much that
each request costs to handle. You could give each of residential your
customers a single /64, and have some percentage of them come back
every year for more subnets. Or you could give them all /56s, and
likely have none of them come back at all for additional address space
while they continue to be your customer. Up to a point (/56 seeming to
be the common view at the moment) IPv6 address space is so plentiful
that handling a request for more costs both or either the ISP or the
customer more than if the customers were initially given enough to
exceed their common and foreseeable requirements.

There would be better things for an ISP to spend it's staff time on
than dealing with low end customer IPv6 address space requests, when
the ISP has the choice of giving all customers more than they'll
likely need, resulting in additional address space requests to being a
rare and exceptional occasion.



> > > The effort and cost of that on the organization is hard to predict, especially as how it may vary from size to 
> > > size, organization to organization. Furthermore, everyone else pays with a DFZ slot.
> > Yeah, but, the number of DFZ slots consumed by this in IPv6 will be so much smaller than IPv4 that I really find it 
> > hard to take this argument seriously.
>
> Early days yet. And each IPv6 is worth four of IPv4. We are already 
> proposing doubling the allocation rate for transitional mechanisms.
>
> > Additionally, it's not necessarily true due to allocation by bisection.
> >
> > > /48 per customer gives the customer as many potential subnets as you have potential customers.
> > You say that like it is a bad thing.
>
> I say it as if it is a curious thing worthy of real consideration 
> whether we are indeed following the wisest course of action.
>
> > > > With more address space than we need, the value we get is addressing
> > > > convenience (just like we've had in Ethernet addressing since 1982).
> > > > There is no need to make IPv6 addressing artificially precious and as
> > > > costly as IPv4 addressing is.
> > >
> > > A balance should be struck and for that to happen, weight must be given to both sides.
> > And it has. /32 is merely the default minimum allocation to an ISP. Larger blocks
> > can be given,
> > and, now that the RIRs are allocating by bisection, it should even
> > be possible in most cases for that additional space to be an expansion of the
> > existing allocation without changing the number of prefixes.
> >
> > e.g. 2001:db8::/32 could be expanded to 2001:db8::/28
> >
> > 16 times as much address space, same number of DFZ slots.
> >
> > Owen
>
>
> Yes, the one saving grace of this system.
>
> Joe