Re: ISP customer assignments

[Owen DeLong <owen () delong com>]

On Oct 5, 2009, at 11:34 AM, Wayne E. Bouchard wrote:

> On Mon, Oct 05, 2009 at 08:18:23PM +0200, Jens Link wrote:
> > "Brian Johnson" <bjohnson () drtel com> writes:
> >
> > > So a customer with a single PC hooked up to their broad-band  
> > > connection
> > > would be given 2^64 addresses?
> > >
> > > I realize that this is future proofing, but OMG! That?s the IPv4
> > > Internet^2 for a single device!
> >
> > Most people will have more than one device. And there is no NAT as  
> > you
> > know it from IPv4 (and hopefully there never will be. I had to
> > troubleshoot a NAT related problem today and it wasn't fun.[1])
> >
> > And I want more than one network I want to have a firewall between my
> > fridge and my file server.
> >
> > > Am I still seeing/reading/understanding this correctly?
> >
> > RFC 3177 suggest a /48.
> >
> > Forget about IPv4 when assigning IPv6 Networks to customers. Think  
> > big an
> > take a one size fits all(most) customers approach. Assign a /48 or / 
> > 56 to
> > your customers and they will never ask you about additional IPs
> > again. This make Documentation relay easy. ;-)
> >
> > cheers
> >
> > Jens
>
> Am I the only one that finds this problematic? I mean, the whole point
> of moving to a 128 bit address was to ensure that we would never again
> have a problem of address depletion. Now I'm not saying that this puts
> us anywhere in that boat (yet) but isn't saying "oh, lets just put a
> /64 on every interface" pretty well ignoring the lessons of the last
> 20 years? Surely a /96 or even a /112 would have been just as good.
Nope.... It really isn't.

If we wanted to do that, then, IPv6 would probably have 64-bit  
addressing,
instead of 128-bit, and, you'd have 32 bits of carrier, 16 bits of end- 
site,
8 bits of subnet and 8 bits of host (or something approximating that).

Part of the reason that 128 bits was chosen (64 bits is FAR more than
enough) was that it allowed for 64 bits of stateless auto-configuration
(IEEE was already pushing EUI-64) within each network and still
provided more than enough network numbers.

> Lets think longer term... IPv4 is several decades old now and still in
> use. If IPv6 lasts another 50 years before someone decides that it
> needs a redo, with current practices, what will things look like?

OK.


> Consider the population at that point and consider the number of
> interfaces as more and more devices become IP enabled. "wireless"
> devices have their own issues to content with (spectrum being perhaps
> the biggest limiter) so wired devices will always be around. That

The planet's sustainable population is not likely to exceed 10 billion.
(However, current growth is approximately 80 million per year, so,
our current 6 billion + 80 million * 50 = 4 billion still puts us at
around 10 billion, so, it should be a safe number even if we throw
sustainability out the window).

IPv6 offers us 32 bits of provider units == 4 billion providers.
Each provider can serve 65,536 customer units which gives
us the ability to support 281,474,976,710,656, or, about
281 trillion customers.  Each customer unit gets 65,536
subnets to do with as they like and they still have 64 bits
on each subnet.

> means physical interfaces and probably multiple LANs in each
> residence. I can see where each device may want its own LAN and will
> talk to components of itself using IP internally, perhaps even having
> a valid reason for having these individual components publically
> addressable.
It's OK.  We can do it.  We will still have addresses to spare even in
50 years, even with that.

> Like I said, I'm not necessarily saying we're going to find ourselves
> in that boat again but it does seem as though more thought is
> required. (And yes, I fully realize the magnitude of 2^64. I also
> fully realize how quickly inexhaustable resources become rationable.)

Well... There is a safety valve.  We are only issuing from 1/8th of the
current address space at this time.  If we run that out before we
expect to and it becomes clear that there is a need to allocate
differently, we can begin doing that from the next 1/8th without any
real changes to the protocol or router software.

Really, it's OK.

Owen