Home page logo

nanog logo nanog mailing list archives

Re: IPv6 end user addressing
From: Owen DeLong <owen () delong com>
Date: Mon, 8 Aug 2011 17:07:46 -0700

On Aug 8, 2011, at 3:52 PM, Sven Olaf Kamphuis wrote:

we assign /112 per "end user vlan (or server)" at this moment... works perfectly fine (and thats even "a bit too 

Sigh… Too big for what?

- nobody wants to use dynamic ips on -servers- or -router links- anyway

True… Guess what… Static addresses work in /64s as well.

Better yet, your /64 will support adding troubleshooting equipment rapidly without having to hunt
for an available address.

i -really- can't see why people don't just use subnets with just the required number of addresses.

Because we see real advantages to sparse addressing?

Because it would make our lives unnecessarily more complicated?

Because it will lead to additional human factors issues in most environments with more than a
single administrator and likely even in cases where it is a single administrator?

Because it reduces the potential for better automation?

I'm sure there are more reasons, but, these are just a few that come to mind off the top
of my head.

take one /64 (for /64's sake ;), split it up into subnets which each have the required number of addresses (lets say 
you have 2-4 addresses for each bgp/router link, so you simply split it up into subnets that size)

The point of this being? What do you gain by doing this? I've shown you at least a few things you lose.


no need to use /64 for -everything- at all, just because it fits (ethernet) mac addresses (as if ethernet will be 
around longer than ipv6 ha-ha, someone will come up with something faster tomorrow and then its bye bye ethernet, the 
10ge variant is getting slow, and the 100ge variant is not even standardized yet, and trunking is a bottleneck ;)

The /64 was chosen because it fits EUI-64 addresses. Ethernet MAC addresses are EUI-48.

Examples of network technologies that use EUI-64 include Firewire, Zigbee, 6lowpan, etc.

So this argument is rather specious and orthogonal to your supposed point.

we don't use /24's for -everything- on ipv4 now do we :P

Right.. We ran out of IPv4 and stopped doing that in order to artificially extend its life.

(oh wait, there once was a time where we did.. due to another retarded semi-automatic configuration thingy, called 
RIP , which also only seemed to understand /24 or bigger ;)

The issuance of /24s was _NOT_ driven by RIP. Rather, the architecture of RIP was driven
by glassful addressing assumptions. There were many other reasons for classful addressing
and it still retains some of those advantages.


Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.

Guess you shouldn't have published it to a public list then.

On Mon, 8 Aug 2011, Owen DeLong wrote:

On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:

On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews <marka () isc org> wrote:
So you want HE to force all their clients to renumber.

No.  I am simply pointing out that Owen exaggerated when he stated
that he implements the following three practices together on his own
* hierarchical addressing
* nibble-aligned addressing
* /48 per access customer

You can simply read the last few messages in this thread to learn that
his recommendations on this list are not even practical for his
network today, because as Owen himself says, they are not yet able to
obtain additional RIR allocations.  HE certainly operates a useful,
high-profile tunnel-broker service which is IMO a very great asset to
the Internet at-large; but if you spend a few minutes looking at the
publicly available statistics on this service, they average only
around 10,000 active tunnels across all their tunnel termination boxes
combined.  They have not implemented the policies recommended by Owen
because, as he states, a /32 is not enough.

Do I think the position he advocates will cause the eventual
exhaustion of IPv6?  Well, let's do an exercise:

There has been some rather simplistic arithmetic posted today, 300m
new subnets per year, etc. with zero consideration of address/subnet
utilization efficiency within ISP networks and individual aggregation
router pools.  That is foolish.  We can all pull out a calculator and
figure that 2000::/3 has space for 35 trillion /48 networks.  That
isn't how they will be assigned or routed.

The effect of 2011-3 is that an out-sized ISP like AT&T has every
justification for deciding to allocate 24 bits worth of subnet ID for
their "largest POP," say, one that happens to terminate layer-3
services for all customers in an entire state.  They then have policy
support for allocating the same sized subnet for every other POP, no
matter how small.  After all, the RIR policy permits them to obtain
additional allocations as soon as one POP subnet has become full.

So now you have a huge ISP with a few huge POPs, and a lot of small
ones, justified in assigning the same size aggregate prefix, suitable
for 2^24 subnets, to all those small POPs as well.  How many layer-3
POPs might this huge ISP have?  Any number.  It could be every central
office with some kind of layer-3 customer aggregation router.  It
could even be every road-side hut for FTTH services.  Perhaps they
will decide to address ten thousand POPs this way.

Now the nibble-aligned language in the policy permits them to round up
from 10,000 POPs to 16 bits worth of address space for "POP ID."  So
AT&T is quite justified in requesting:
  48 (customer subnet length) - 24 (largest POP subnet ID size) - 16
(POP ID) == a /8 subnet for themselves.

Right up until you read:

6.5.3 (d):
If an LIR has already reached a /12 or more, ARIN will
allocate a single additional /12 rather than continue
expanding nibble boundaries.
As you can see, there is a safety valve in the policy at /12 for just
this reason.

Now you can see how this policy, and addressing scheme, is utterly
brain-dead.  It really does put you (and me, and everyone else) in
real danger of exhausting the IPv6 address space.  All it takes is a
few out-sized ISPs, with one large POP each and a bunch of smaller
ones, applying for the maximum amount of address space permitted them
under 2011-3.

Even by your calculations, it would take 256 such outsized ISPs without
a safety valve. With the safety valve that is built into the policy at /12,
it would take 4,096 such ISPs. I do not believe that there are more than
about 20 such ISPs world wide at this time and would put the foreseeable
likely maximum at less than 100 due to the need for customers to support
such outsized ISPs and the limited base that would have to be divided
among them.


Attachment: smime.p7s

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]