[143382] in North American Network Operators' Group
Re: IPv6 end user addressing
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Aug 8 16:41:42 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPWAtbKtHL3eFn4a=R6u03=T_TLO=AnsFwRcEZqHDVF-+Ys1CQ@mail.gmail.com>
Date: Mon, 8 Aug 2011 13:37:25 -0700
To: Jeff Wheeler <jsw@inconcepts.biz>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_8583B7D8-A8D8-4684-8921-4D8A3EC29319
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=iso-8859-1
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
> 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
--Apple-Mail=_8583B7D8-A8D8-4684-8921-4D8A3EC29319
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
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDgyMDM3MjZaMCMGCSqGSIb3DQEJBDEWBBS8xWVamUVD
dUi89fcCq4hzqVtgGzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG
A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv
bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU
MA0GCSqGSIb3DQEBAQUABIIBADGHDklF4OfELhRNPSDEaFOQhHm433WQgLviSYXGPdqMFinnAgTm
+AP+ZOGOeO6Wztj5eClllIFU+5G6oXfCSF9PmrWVtlHbMUU3yxtXDVRji/lYYCVIReFOx/Xb7wBn
6Xo9hPU5CB49NL/HpjEJkXuf9tp2Kf82y9XcriA4EkqTTPeV4+qYjipyRi4/25Vu0y+e0DocTmue
iAaAALJhp7OxfqKxLw4kT3Nk2z92GAWHo6wGlb4dce7D8OV+Wp19LBPxcllZiorrkYG2B04Lkf0H
cnydab6/XPs2PrkOTRY3XbFl3Xkjj7bwCbJ2T+a6RowNXCwEb1FcIT9r/WVV5LoAAAAAAAA=
--Apple-Mail=_8583B7D8-A8D8-4684-8921-4D8A3EC29319--
