[143330] in North American Network Operators' Group
Re: IPv6 end user addressing
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Aug 6 12:42:10 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPWAtbJbG4SnUY3Hv3VhJs8Wna3BTjzPkMgBSZ1WY2qRpo77bg@mail.gmail.com>
Date: Sat, 6 Aug 2011 09:36:33 -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=_2FC46B18-FD3F-4885-B348-CE498840750F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote:
> On Sat, Aug 6, 2011 at 5:21 AM, Owen DeLong <owen@delong.com> wrote:
>>> At least don't make your life miserable by experimenting with too =
many different assignment sizes,
>>> or advocate /64s or something, that's considered a design fault =
which will come back to you some day.
>>> Read the RfCs and RIR policy discussions in the archives some years =
ago.
>=20
> 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
>=20
Hasn't been hard so far.
> If I were, for example, a hosting company with IPv6 terminated at the
> layer-3 ToR switch, I would then use a /40 per rack of typical
> "dedicated servers." If you then want some bits to be a POP-locator
> field for your hierarchical routing scheme, you are already forced to
> request more than a /32. The number of customers per layer-3 device
> for typical end-user access networks was around the same into the
> late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever
> box of choice for terminating dial-up.
>=20
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.
However, requesting more than a /32 is perfectly reasonable. In
the ARIN region, policy 2011-3.
> Densities have changed, but this doesn't necessarily win you an
> advantage when combining those three properties. This is especially
> true if you consider that density may change in a difficult-to-predict
> manner in the future -- a BRAS box with a couple thousand customers
> today might have three times as many in a couple of years (IPv6 is
> supposed to help us avoid renumbering or injecting additional routes
> into our network, right?) As an access provider, if I shared your
> view, I would be reserving a /36 or /32 per BRAS box. If I then want
> some additional bits for hierarchical routing ... I'm going to need a
> pretty large address block for perhaps a pretty small number of
> customers. After all, my scheme, applying your logic, dictates that I
> should use a /32 or perhaps a /28 per each POP or city (I need to plan
> for several BRAS each), even if I don't have a lot of customers today!
>=20
Correct=85 I think a /36 per BRAS seems about right, but if you want
to put more than 3072 customers on a single BRAS and expect
technology to eventually support that, sure, go for a /32 per BRAS.
If you want to isolate your routing down to per BRAS (most providers
I'm aware of that have multiple BRAS have it set up so any customer
in a given POP may connect to any BRAS and they carry the
customer prefixes within the POP's routing table), then, I think a
/36 per BRAS is probably OK (up to 3072 customers at 75%
utilization, 4096 max), but, if you really think you will have 6,000
customer BRAS units, then, yes, a /32 would be correct.
However, I would be more likely to assign hierarchy per POP
instead. Figure out how many customers are likely in my
largest POP and allocate based on /48 per customer+growth
in that POP. For example, if my largest POP would serve 2,000
customer end-sites, I'd be looking at a /36 per POP. If the largest
POP served 3,073 customer end-sites or even 49,000 customer
end-sites, I'd plan on a /32 per POP.
Basically take the number of customer end-sites in your largest
POP, divide by 0.75 (keep 25% headroom minimum) and then
round up to the nearest nibble.
If you really think you will have more than 786,432 customer
sites served from your largest POP, then, I suppose a /28 per
POP is a reasonable request. That seems like pretty unlikely
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.
> I think /56 is more sensible than /48, given the above, for most
> end-users. Either way, the users will be gaining a lot more
> flexibility than they have with IPv4 today, where they probably get
> just one IP address and have to pay a fee for any extras. Giving the
> typical end-user 8 fewer bits worth of address space allows the ISP
> network more flexibility for hierarchical routing before they have to
> go to their RIR and figure out how to justify an out-sized allocation.
>=20
Why? You point out that giving out /48s would require larger IPv6
allocations than /32, but, you don't give any reason to think this is
bad.
Let's look at the math. Let's assume a moderately large provider
expects to serve 45,000 customer end-sites out of their largest
POP (does anyone actually expect numbers this large in a
single POP)?
Now, let's say you have 50 POPs across your service region
and expect to triple in size over the next 5 years. That's 150
total POPs planned.
45,000 customer end sites with 25% minfree is 60,000
which, when rounded up to a nibble is 16 bits for 65,536.
150 POPs with 25% minfree is 200 which, when rounded
up to a nibble is 8 bits for 256 total POPs possible.
16+8 =3D 24, so, such a provider would need a /24 for their
access network.
There are 512 /24s in each of the /12s (what the IANA issues
to RIRs).
> Also, if folks would stop thinking that every subnet should be a /64,
> they will see that end-users, makers of set-top-gateways, or whatever,
> can certainly address a whole lot of devices in a whole lot of subnets
> even if the user is only given a /64. Do we think DHCPv6 won't be the
> most common way of assigning addresses on SOHO LANs, and that SLAAC
> will be essential? I, for one, think that some ISPs will be sick and
Yes.
> twisted enough to hand out /128s so they can continue charging for
> more IP addresses; but certainly the makers of IPv6-enabled devices
> will foresee that end-user LANs might not be /64 and include the
> necessary functionality to work correctly with smaller subnets.
>=20
I think natural selection in the market will solve that problem =
relatively
quickly.
> Before you beat me to it, yes, we seem to have completely opposing
> views on this subject. I will change my mind when I can go to the RIR
> and get a IPv6 /24 for a small ISP with a few POPs and a few tens of
> thousands of customers. Should RIR policy permit that sort of thing?
>=20
OK=85 Start changing your mind=85 Read 2011-3. It's been adopted
in the ARIN region. I'd also like to suggest you consider supporting
APNIC proposal 98 which is essentially the same policy and will be
discussed at the Busan meeting.
Owen
--Apple-Mail=_2FC46B18-FD3F-4885-B348-CE498840750F
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
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDYxNjM2MzRaMCMGCSqGSIb3DQEJBDEWBBQLME5YKEIZ
F3zDA/XlYcLmZ4mk9TCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG
A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv
bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU
MA0GCSqGSIb3DQEBAQUABIIBAHt2chqnAsGvz+DV4TLSS17/kPW+stjucsML0Qg7gZhbHdDN06V0
vE9Evii1xz8q/XLMvc3YcJ+qNsa/gEfN4KCKYTLn38N+9fK8FWJNGs5aTQaoEjIH9TFTekLnA4gE
FYLsBKkd1ork3k0aYY8Zy2gNz2PqN6vgwzi5EEuprqFji8nbuQT1xY4V6dO/Lts2ajlOhT229gXz
Aum4lo9l8k/7OjKZlxSKbtVSa21UqlVER9ZDVVXYkzK3MLgO0DnATWjdz5hQyZTc0Uc/uye7oySI
EqW01TnnBn5Bj3aFXOoMOoRhAz7a3903lMqYNLF1tekUva7RMRQcUkJSrSM40mMAAAAAAAA=
--Apple-Mail=_2FC46B18-FD3F-4885-B348-CE498840750F--
