[143342] in North American Network Operators' Group
Re: IPv6 end user addressing
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Aug 6 19:32:05 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPWAtb+2+a1P_e-K1wm3cJGbCxAbkF+K-rv--CkEeQ-ZF_7FJA@mail.gmail.com>
Date: Sat, 6 Aug 2011 16:26:48 -0700
To: Jeff Wheeler <jsw@inconcepts.biz>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_29080937-5DDA-44F8-9511-1B3CB7FEEC5C
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=iso-8859-1
On Aug 6, 2011, at 1:14 PM, Jeff Wheeler wrote:
> On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong <owen@delong.com> wrote:
>> On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:
>>> Note that in this thread, you advocate three things that are a little
>>> tough to make work together:
>>> * hierarchical addressing plan / routing
>>> * nibble-aligned addressing plan
>>> * minimum /48 per customer
>>>
>> Hasn't been hard so far.
>
> Well, you aren't actually doing this on your network today. If you
> practiced what you are preaching, you would not be carrying aggregate
> routes to your tunnel broker gateways across your whole backbone.
Yes we would.
> Perhaps you also wouldn't use one allocation on the tunnel broker
> gateway for /64s and another, a /37 in the case of Ashburn for
> example, for users who self-provision a /48 from it. Also, of course,
> your default assignment plan is /64, not /48, even though there are
> typically around, what, 10k tunnels active network-wide?
>
Those are artifacts of a small allocation (/32) from a prior RIR policy.
The fact that those things haven't worked out so well for us was one of
the motivations behind developing policy 2011-3.
> To be clear, you don't do any of the three things you advocate above
> where Hurricane Electric's tunnel broker service is concerned.
>
Yes we do.
We give a minimum /48 per customer with the small exception that
customers who only want one subnet get a /64.
We will be implementing a nibble-aligned addressing plan as soon as
we can get enough space from the RIR. That's pending implementation
of 2011-3.
We do have a hierarchical addressing plan. I said nothing about routing,
but, we certainly could implement hierarchical routing if we arrived at a
point where it was advantageous because we have designed for it.
>> I think we were talking about access customers. I don't see giving /48s
>> to individual dedicated servers as I don't see them having hierarchy
>> behind them. I would think that a /48 per TOR switch would be
>> reasonable in that case.
>
> I wish there was more discussion about IPv6 addressing plans in
> hosting environments on this list. I think that, rarely, customers
> will decide to tunnel from their home or office to their "dedicated
> server," co-lo rack, etc. My addressing policies provide for this
> type of customer to receive a /56 upon request without breaking my
> hierarchical addressing scheme. If they need more than that, the
> layer-3 aggregator has to inject an additional route into the POP
> area. If a whole bunch of customers on one aggregator ask for /56,
> then the aggregator needs an extra /48 (which might really mean
> growing its existing /48 to a shorter route.)
>
Sounds like a mess. We'll stick with /48s for people that need more
than a /64.
>> However, requesting more than a /32 is perfectly reasonable. In
>> the ARIN region, policy 2011-3.
>
> My read of that policy, and please correct me if I misunderstand, is
> that it recognizes only a two-level hierarchy. This would mean that
> an ISP could use some bits to represent a geographic region, a POP, or
> an aggregation router / address pool, but it does not grant them
> justification to reserve bits for all these purposes.
>
While that's theoretically true, the combination of 25% minfree ,
nibble boundaries, and equal sized allocations for all POPs based
on your largest one allows for that in practical terms in most
circumstances.
>> density, even in 20 years. I realize that customer density in
>> urban areas does tend to increase, but, assuming a maximum
>> 50% market penetration, serving a city the size of Philadelphia
>> out of a single POP still seems unlikely to me.
>
> AT&T serves some entire states out of a single POP, as far as layer-3
> termination is concerned.
>
Are any of the states with populations larger than Philadelphia among
them?
Owen
--Apple-Mail=_29080937-5DDA-44F8-9511-1B3CB7FEEC5C
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
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDYyMzI2NDlaMCMGCSqGSIb3DQEJBDEWBBQBOrhJEg+m
YvYwFy6cOXCfN6B5QzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG
A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv
bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU
MA0GCSqGSIb3DQEBAQUABIIBAFqYR2mLsPfg4FenT8BxnjFXwlMcsMuqkG71Hx2pyL3tvu5DiXai
wwc09Dm2Ub1qRv4NDzvPGDfcg+K1Nf7LWx+r08DE8vryAdFW+nyzBjU8QcXSa3xPaPR96zXTKP19
JhLcJ82NSqBhEzhCiJIy/2EqNlt59OyXzbMwXZS6VTTqwptZpnSnV0UymgHrTBLqk3tDetqHqQcc
VxBv8u6wtBniYIVL02RBF+Wm7WfXAAu/6CsUkx+aadpHnW5m1wM83m+Ig6QDGcm3y9BO5B3N6fSe
blo2OFOrf9TxBma4LYi5G6y6gtl4A9HF2Zfk+F/3MMOrLqLwMBmRWHaR799OYQ8AAAAAAAA=
--Apple-Mail=_29080937-5DDA-44F8-9511-1B3CB7FEEC5C--
