IPv6 end user addressing

Owen DeLong owen at delong.com
Tue Aug 9 00:14:35 UTC 2011


I'm sure there will be platforms that end up on both sides of this question.

YES: We made a less expensive box by cutting the width of the TCAM required in half.

NO: We spared no expense and passed the costs (and a nice profit margin) on to you so
	that you can do whatever you like in IPv6 at wire speed.

I'm sure the market will chose products from both sides of the line for the same reasons.

Owen

On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote:

> 
> I heard at one time that hardware manufacturers were likely to route in hardware only down to a /64, and that any smaller subnets would be subject to the "slow path" as ASICs were being designed with 64-bit address tables. I have no idea of the validity of that claim. Does anyone have any concrete evidence for or against this argument?
> 
> If true, it would make /64s even more attractive.
> 
> -Randy
> 
> 
> ----- Original Message -----
>> we assign /112 per "end user vlan (or server)" at this moment...
>> works
>> perfectly fine (and thats even "a bit too big").
>> 
>> - nobody wants to use dynamic ips on -servers- or -router links-
>> anyway
>> 
>> i -really- can't see why people don't just use subnets with just the
>> required number of addresses.
>> 
>> 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)
>> 
>> etc.
>> 
>> 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 ;)
>> 
>> we don't use /24's for -everything- on ipv4 now do we :P
>> 
>> (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 ;)
>> 
>> --
>> Greetings,
>> 
>> Sven Olaf Kamphuis,
>> CB3ROB Ltd. & Co. KG
>> =========================================================================
>> Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
>>          D-13359                   Registration:    HRA 42834 B
>>          BERLIN                    Phone:
>>                    +31/(0)87-8747479
>>          Germany                   GSM:
>>                      +49/(0)152-26410799
>> RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
>> =========================================================================
>> <penpen> C3P0, der elektrische Westerwelle
>> http://www.facebook.com/cb3rob
>> =========================================================================
>> 
>> 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.
>> 
>> 
>> 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 at 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
>>>> networks:
>>>> * 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.
>>> 
>>> Owen
>>> 
>>> 
>> 
>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110808/3f51e6b0/attachment.bin>


More information about the NANOG mailing list