[143393] in North American Network Operators' Group
Re: IPv6 end user addressing
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Aug 8 20:11:52 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <Pine.LNX.4.64.1108082243330.376@a84-22-97-10.cb3rob.net>
Date: Mon, 8 Aug 2011 17:07:46 -0700
To: Sven Olaf Kamphuis <sven@cb3rob.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_931697F7-0D26-425D-85E6-72407E1E4C55
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Aug 8, 2011, at 3:52 PM, Sven Olaf Kamphuis wrote:
> we assign /112 per "end user vlan (or server)" at this moment... works =
perfectly fine (and thats even "a bit too big").
>=20
Sigh=85 Too big for what?
> - nobody wants to use dynamic ips on -servers- or -router links- =
anyway
>=20
True=85 Guess what=85 Static addresses work in /64s as well.
Better yet, your /64 will support adding troubleshooting equipment =
rapidly without having to hunt
for an available address.
> i -really- can't see why people don't just use subnets with just the =
required number of addresses.
>=20
Because we see real advantages to sparse addressing?
Because it would make our lives unnecessarily more complicated?
Because it will lead to additional human factors issues in most =
environments with more than a
single administrator and likely even in cases where it is a single =
administrator?
Because it reduces the potential for better automation?
I'm sure there are more reasons, but, these are just a few that come to =
mind off the top
of my head.
> 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
The point of this being? What do you gain by doing this? I've shown you =
at least a few things you lose.
> 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
The /64 was chosen because it fits EUI-64 addresses. Ethernet MAC =
addresses are EUI-48.
Examples of network technologies that use EUI-64 include Firewire, =
Zigbee, 6lowpan, etc.
So this argument is rather specious and orthogonal to your supposed =
point.
> we don't use /24's for -everything- on ipv4 now do we :P
>=20
Right.. We ran out of IPv4 and stopped doing that in order to =
artificially extend its life.
> (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
The issuance of /24s was _NOT_ driven by RIP. Rather, the architecture =
of RIP was driven
by glassful addressing assumptions. There were many other reasons for =
classful addressing
and it still retains some of those advantages.
Owen
>=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
Guess you shouldn't have published it to a public list then.
>=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
--Apple-Mail=_931697F7-0D26-425D-85E6-72407E1E4C55
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
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDkwMDA3NDZaMCMGCSqGSIb3DQEJBDEWBBRI8tCxP7+P
bF85bbB2kPC7R6otSDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG
A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv
bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU
MA0GCSqGSIb3DQEBAQUABIIBAKdpXjK3r7Wnpbu6anU7wMR6jmX/RnqFWGwMbJaNDdmuR/wpA3ot
8bIdYfVZMzF0wrP8r6UtbxzOyDVAcbZuV8fR0uaiufQXO97Us+HtA2yntIqgVMOxqWhM46GJmjKi
NvtT5QXVgK4Wvp9VifBJ9VAOQLX3/MSPmzL//nWr3Q4/FxyzMxaDWjq+Gn7FcPLzvqPTsLkkAftj
gnaqYJOWdHNDmZgjTTMKDp7bYJPpE7ZUCsdvRE6gAcRBOn2UeodV7ZFZQBirvMLlyFKcxkkxNUoD
TuQ2uZWhYGxFCkgS3giAaVxJjZ00Bg7MGpLRQGvWDNN3f0jkqYInqlxG2UXNKucAAAAAAAA=
--Apple-Mail=_931697F7-0D26-425D-85E6-72407E1E4C55--
