[143394] in North American Network Operators' Group
Re: IPv6 end user addressing
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Aug 8 20:16:38 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <8e0d3354-6d6e-4ed4-84dc-f0d9723c7a74@zimbra.network1.net>
Date: Mon, 8 Aug 2011 17:14:35 -0700
To: Randy Carpenter <rcarpen@network1.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_EBFE0AC3-ABDD-4E6F-9B00-BFAC0B180458
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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:
>=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
--Apple-Mail=_EBFE0AC3-ABDD-4E6F-9B00-BFAC0B180458
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
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDkwMDE0MzVaMCMGCSqGSIb3DQEJBDEWBBTm/ZQYaMjv
GKJXnPzwI1cwaFlfqzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG
A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv
bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU
MA0GCSqGSIb3DQEBAQUABIIBAJB1Vc6e8ad3GfLGWjQrZmAU2qW2EplbisTknJRkdwcUjTRYTIV1
HVD7FdzMNbAjd37xsR6dS3/d2gfaeF95jS0UJjcewkNoiuNS1kl5jTtp5tCgngyyHD/DWxgmiLWP
T3ndU7kYJaJvKAaykUgJg0kO14UQ4loxMVjPggPKMzVBVf6h+6uu1niMfmlDgs3B5QGEHCtT2D0b
Ar2O+Dh8K5QlduEihuAL6WHXVVtce5w8ZcfXEBrIH0y1uSc3M8tgEZtYdsBZdop3OCU5MdPPeeqc
tZKBuupke/bNZ4vT82ey+zdZJdGco0U1fRV3R+qTiWjPW4zn5/Utefo2a2tgxtcAAAAAAAA=
--Apple-Mail=_EBFE0AC3-ABDD-4E6F-9B00-BFAC0B180458--
