[143411] in North American Network Operators' Group
Re: IPv6 end user addressing
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Aug 9 03:31:09 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <AE8A7D75-5704-4634-8DF0-7799F3AA02B9@bogus.com>
Date: Tue, 9 Aug 2011 00:25:52 -0700
To: Joel Jaeggli <joelja@bogus.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_4570B906-2B7E-4B2D-A86E-131C68AAF6D9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
It's at least true of how some of the Cisco platforms cope with IPv6 =
access lists.
Owen
On Aug 8, 2011, at 11:54 PM, Joel Jaeggli wrote:
>=20
> On Aug 8, 2011, at 5:14 PM, Owen DeLong wrote:
>=20
>> I'm sure there will be platforms that end up on both sides of this =
question.
>=20
> 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...
>=20
> given that switches routinely have to forward to neighbors on /126 or =
/127 prefix links I think that would be something of a mistake.
>=20
>> YES: We made a less expensive box by cutting the width of the TCAM =
required in half
>=20
>> 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
--Apple-Mail=_4570B906-2B7E-4B2D-A86E-131C68AAF6D9
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw
ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER
MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE
ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ
KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow
fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP
MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl
bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY
0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1
V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb
Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G
QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu
EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8
UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA
MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH
K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL
/euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX
zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT
CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl
cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ
ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDkwNzI1NTNaMCMGCSqGSIb3DQEJBDEWBBQruugz3gSh
u6ifHfoQhI2p7AwkxjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG
A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv
bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU
MA0GCSqGSIb3DQEBAQUABIIBACYS8C/cByjnAVcDz/cWLBxn1EnJFKViAwlsBJBGcFxqWBsDRmyR
nTEARA3jnZj2MD5lubXpFwNFCuE+NIfxG7/ENdCaL1a5HyCXW2jvHVmlD1Hytbfqut+h0QeIGqdP
xNJXluSW5Io3L1Ea/Oru7BeTw4//gCw+0ohzR7b5begoJS4c/gspKMznOpRGs2jkTRWl5ZwexEKb
88SVKl0gO2BIq/vhjty4N4PUV5sJ5A5NFEeIPdeVxi/6KByN6B3RxTA/SGYTByGkZ5TboJD9Y7lG
1kvOdRj719zoJB4GQGhUz1VzJP4TgcA1dH6whChpE5tutpCe4Jwg2VEPBWsM8IIAAAAAAAA=
--Apple-Mail=_4570B906-2B7E-4B2D-A86E-131C68AAF6D9--
