[143410] in North American Network Operators' Group
Re: IPv6 end user addressing
daemon@ATHENA.MIT.EDU (Joel Jaeggli)
Tue Aug 9 02:55:51 2011
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <4E8F95EB-4568-49CB-BADB-5365FBAE8D15@delong.com>
Date: Mon, 8 Aug 2011 23:54:50 -0700
To: Owen DeLong <owen@delong.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote:
> I'm sure there will be platforms that end up on both sides of this =
question.
I know of no asic in a switch that claims to support ipv6 that does it =
this way... That would tend to place you at a competitive disadvantage =
to broadcom/marvell/fulcrum/juniper/cisco if you implemented it that =
way... it's easier I imagine to simply reduce the size of the fib...
given that switches routinely have to forward to neighbors on /126 or =
/127 prefix links I think that would be something of a mistake.
> 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.
>=20
> I'm sure the market will chose products from both sides of the line =
for the same reasons.
>=20
> Owen
>=20
> On Aug 8, 2011, at 4:34 PM, Randy Carpenter wrote:
>=20
>>=20
>> 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?
>>=20
>> If true, it would make /64s even more attractive.
>>=20
>> -Randy
>>=20
>>=20
>> ----- Original Message -----
>>> we assign /112 per "end user vlan (or server)" at this moment...
>>> works
>>> perfectly fine (and thats even "a bit too big").
>>>=20
>>> - nobody wants to use dynamic ips on -servers- or -router links-
>>> anyway
>>>=20
>>> i -really- can't see why people don't just use subnets with just the
>>> required number of addresses.
>>>=20
>>> 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)
>>>=20
>>> etc.
>>>=20
>>> 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 ;)
>>>=20
>>> we don't use /24's for -everything- on ipv4 now do we :P
>>>=20
>>> (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 ;)
>>>=20
>>> --
>>> Greetings,
>>>=20
>>> Sven Olaf Kamphuis,
>>> CB3ROB Ltd. & Co. KG
>>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> 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@cb3rob.net
>>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> <penpen> C3P0, der elektrische Westerwelle
>>> http://www.facebook.com/cb3rob
>>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>> 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.
>>>=20
>>>=20
>>> On Mon, 8 Aug 2011, Owen DeLong wrote:
>>>=20
>>>>=20
>>>> On Aug 7, 2011, at 4:26 PM, Jeff Wheeler wrote:
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Do I think the position he advocates will cause the eventual
>>>>> exhaustion of IPv6? Well, let's do an exercise:
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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) =3D=3D a /8 subnet for themselves.
>>>>>=20
>>>> Right up until you read:
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>>> 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.
>>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> Owen
>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>=20
