who gets a /32 [Re: IPV6 renumbering painless?]

In article <cistron.1100794375.3557.3.camel@firenze.zurich.ibm.com>,

> For *THAT* matter, I've heard a lot of people over on the main IETF list
> in the last week or so stating that SMTP is only 1-2% of many places' total
> bandwidth usage. So why don't we all just cut *THAT* off because there's
> no business case to support *THAT* either? :slight_smile:

let's be clear about the remaining roadblocks. just because some of you don't
like tony li or don't like what he said, doesn't make what he said less true.

We all *hate* Mr.Li (is there any reason to? :slight_smile:

<SNIP> but for enterprises large or medium who build their own networks and
buy service from more than one provider and/or who peer directly, they'll
either have to have their own /32 or they'll use NAT.

They should use NAP, NAT is the IPv4 thing, NAP is for IPv6 :wink:
Larger enterprises probably consist of 200 'sites' already, eg seperate
offices, locations etc. Thus they can, after becoming a LIR and getting
an ASN, which most of the time they already have, easily get a /32.

Actually, I would even go so far that the really large corps should be
able to get a /32 from every RIR when they globally have offices, this
could allow them to keep the traffic at least on the same continent, not
having to send it to another place of the world themselves.

That would really put the constraint on ASN's of course and thus: 65k*3
= maximum of ~180k prefixes when every ASN owner did this (and they
won't in most if not all cases).

[--ot--]

This is flawed in a number of points:

  1. 32 bit ASNs are coming at least as quickly as IPv6.
    (/me ducks under table now as both camps probably take
    offense)
  2. There are currently 4 and will soon be 5 RIRs.
  3. There are plenty of large organizations that are multihomed
    that don't have 200 locations.

Owen

This is flawed in a number of points:

  1. 32 bit ASNs are coming at least as quickly as IPv6.
    (/me ducks under table now as both camps probably take
    offense)

Offense! Sue! and other nice woman names :wink:
When that happens, it happens, just like that four letter word.
32 bit ASN would still mean routing IPv6 with IPv4, sort of :wink:

  2. There are currently 4 and will soon be 5 RIRs.

I didn't count LACNIC as I am not aware of a large organisation having
200+ offices in that area and if one has an allocation from ARIN, one
could better use that (65k /48's from a /32). Then again, oil-rigs could
reach that number that easily.

  3. There are plenty of large organizations that are multihomed
    that don't have 200 locations.

That is too bad for those organizations (under current policy)
Do these organizations all have their own ASN? If so, there are still at
the moment <30k of these, so should not be a large issue to give them a
alloc, ARIN has these special micro-allocs, not that that helps the
routing table size but still.

Greets,
Jeroen

[snip]

Re LACNIC, I don't know what kind of organizations are or aren't headquartered
within the LACNIC region, so, I"m not willing to make assumptions. I'm betting
that there are plenty of commercial organizations in Columbia that have at
least 200 manufacturing and distribution centers, but, the number of actual
sites is really irrelevant to the discussion... See my rebuttal to 3 below.

  3. There are plenty of large organizations that are multihomed
    that don't have 200 locations.

That is too bad for those organizations (under current policy)
Do these organizations all have their own ASN? If so, there are still at
the moment <30k of these, so should not be a large issue to give them a
alloc, ARIN has these special micro-allocs, not that that helps the
routing table size but still.

OK.. I tried to make my point a bit left-handedly, and apparently, it got
missed. The number of sites is irrelevant to the discussion. In order
for an org. to qualify for v6 space, said org needs to have a plan for
allocating at least 200 /48s to other orgs. within some period of time.
(I forget the exact clock). Anyway, while it would be easy for a company
to define each site as a separate org., there are lots of other ways to
define orgs. too. For example, business units. A school could, theoretically,
divide each grade level up into separate orgs. if they wanted. Separate
administrative control boundaries could be treated as separate orgs.
Subsidiaries, spin-offs, joint ventures, each employee, etc. LOTS of ways
to create orgs if one really wants to. If I ran a company that employed
200 people and I decided I was going to put together a plan to provide
household IP service to each of my employees to enable telecommuting, that
would be 200 orgs right there.

Anyway, I hope that makes the point a little more clear. It is really not
hard to qualify for a /32 under the current policy. Especially since there
is absolutely no requirement to make good on your plan, you just have to have
a plan.

Owen

Larger enterprises probably consist of 200 'sites' already, eg seperate
offices, locations etc. Thus they can, after becoming a LIR and getting
an ASN, which most of the time they already have, easily get a /32.

Jeroen, this is nonsense and you know it.

We've been discussing the big enterprise problem in multi6 (multihoming in ipv6) circles very extensively. At some point, I realized that the "I'm so huge I need private space" claim is false in 99% of all cases, as these organizations tend to have multiple sites (as you indicate above) but they generally do not have real connectivity between those sites. This means a single large prefix won't do them much good, and basically they're no different than a bunch of smaller single-site organizations.

Now I hate to be the bearer of bad news, but having unaggregatable globally routable address space just doesn't scale and there are no routing tricks that can make it scale, whatever you put in the IP version bits, so learn to love renumbering. And again, IPv6+NAT makes no sense as NAT works much better with IPv4 and with NAT you don't really need the larger address space.

Actually, I would even go so far that the really large corps should be
able to get a /32 from every RIR when they globally have offices, this
could allow them to keep the traffic at least on the same continent, not
having to send it to another place of the world themselves.

If you want to introduce geography into routing, do it right. The above "solution" is the worst of several worlds.

> Larger enterprises probably consist of 200 'sites' already, eg seperate
> offices, locations etc. Thus they can, after becoming a LIR and getting
> an ASN, which most of the time they already have, easily get a /32.

Jeroen, this is nonsense and you know it.

It is not nonsense as long as 'multi6' doesn't have a solution to the
problem, but as politics go above getting solutions...

<SNIP>

Now I hate to be the bearer of bad news, but having unaggregatable
globally routable address space just doesn't scale and there are no
routing tricks that can make it scale, whatever you put in the IP
version bits, so learn to love renumbering. And again, IPv6+NAT makes
no sense as NAT works much better with IPv4 and with NAT you don't
really need the larger address space.

Absolutely. Which is why one will always here from me:
"Want to NAT? Then stay at IPv4"

> Actually, I would even go so far that the really large corps should be
> able to get a /32 from every RIR when they globally have offices, this
> could allow them to keep the traffic at least on the same continent,
> not
> having to send it to another place of the world themselves.

If you want to introduce geography into routing, do it right. The above
"solution" is the worst of several worlds.

Not my idea at all, several big ISP's already do this.
Check http://www.sixxs.net/tools/grh/tla/all/ and look which
organizations have multiple RIR allocations :wink:
Just for the reason you mentioned above: they are actually separate
organizations under one big umbrella. But they did fill the policy thus
got their allocation.

Greets,
Jeroen

Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>

Larger enterprises probably consist of 200 'sites' already, eg seperate
offices, locations etc. Thus they can, after becoming a LIR and getting
an ASN, which most of the time they already have, easily get a /32.

Jeroen, this is nonsense and you know it.

We've been discussing the big enterprise problem in multi6 (multihoming in ipv6) circles very extensively. At some point, I realized that the "I'm so huge I need private space" claim is false in 99% of all cases, as these organizations tend to have multiple sites (as you indicate above) but they generally do not have real connectivity between those sites. This means a single large prefix won't do them much good, and basically they're no different than a bunch of smaller single-site organizations.

Don't have "real connectivity"? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf AT&T, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks "real" because each site may only have a 16k PVC to talk to corporate?

However, since the _vast_ majority of communication is internal and all but a dozen hosts are hidden behind a NAT, nobody on the public Internet has any clue these networks exist. Even 10/8 is barely big enough to hold the largest of these, and in one case we had to use multiple instances of 10/8 with separate servers in each instance to allow for growth in the number of hosts at each site (or sites themselves) and handle protocols which were not compatible with NAT.

ULAs are one way to solve these sorts of problems (and many others), and PI space is another. Guess which one companies would prefer, given the cost and paperwork levels involved with each and the lack of any need for external communication?

Now I hate to be the bearer of bad news, but having unaggregatable globally routable address space just doesn't scale and there are no routing tricks that can make it scale, whatever you put in the IP version bits, so learn to love renumbering. And again, IPv6+NAT makes no sense as NAT works much better with IPv4 and with NAT you don't really need the larger address space.

If I have a disconnected network, why would I use NATs or be forced to renumber periodically? Why should disconnected networks use global addresses (and pay rent to the RIRs) in the first place?

ULAs are not about enabling NAT in IPv6.

S

Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Now I hate to be the bearer of bad news, but having unaggregatable
globally routable address space just doesn't scale and there are no
routing tricks that can make it scale, whatever you put in the IP version
bits, so learn to love renumbering.

This is patently false. If it were true, then I would have to renumber
every time I changed telephone companies. I don't, so, obviously, there
is some solution to this problem. Now I'm not saying that I necessarily
want to accept the overhead and risks of SS7 to solve this, but, there
are, obviously, routing tricks that can be used.

Owen

these organizations tend to have multiple sites (as you indicate above) but they generally do not have real connectivity between those sites. This means a single large prefix won't do them much good, and basically they're no different than a bunch of smaller single-site organizations.

Don't have "real connectivity"? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf AT&T, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks "real" because each site may only have a 16k PVC to talk to corporate?

That's right. If you need internet access, you need it to be faster than 16 kbps. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity.

So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place.

learn to love renumbering. And again, IPv6+NAT makes no sense as NAT works much better with IPv4 and with NAT you don't really need the larger address space.

If I have a disconnected network, why would I use NATs or be forced to renumber periodically?

I have no idea. Use unique local addresses instead.

Why should disconnected networks use global addresses (and pay rent to the RIRs) in the first place?

There aren't many networks around that are truly disconnected. Even "disconnected" networks connect to stuff that connects to other stuff that connects to the internet at some point. This means that "disconnected" address space must not overlap with addresses used on the internet. We have that in RFC 1918. However, "disconnected" networks tend to interconnect with other "disconnected" networks from time to time, which means trouble if they both use the same address space. This is where ULAs come to the rescue.

Well, the old saying is that there is no problem in computer science that can't be solved by adding a layer of indirection. Apparently this applies to telephone networks as well, because your phone number is no longer an address these days: it's more like a domain name. When you dial a number it's looked up in a big database to see where the call should go to.

And don't forget that you still have to change your phone number when you move a great enough distance. In IP we somehow feel it's important that there are no geographical constraint on address use at all. That's a shame, because even if we aggregate by contintent that would save up to four times in the number of entries in the routing table of any router.

But I'm not sure you'd like it applied to the internet. Firstly, in
essence, PSTN uses static routes for interprovider routing (not quite true,
but nearly - if you add a new prefix everyone else has to build it into
their table on all switches). Secondly, IIRC porting works in the UK
something like - call delivered to switch of operator who owns the block,
marked as ported number, lookup in central porting database (one for all
operators), operator port prefix put on dialed number, call sent back out
all the way to interconnect, enters new operator network, goes to switch
managing ports, further signalling info added to make call go to the
correct local switch, call goes to correct local switch, dross removed,
call terminated.

Roughly speaking this is the internet equivalent of:
* Configure all interprovider routes by a static routing config loaded
  every week or so.
* Handle porting by getting ICANN to run a box with a primative gated
  BGP feed connected to all your distribution routers. Where a packet
  is delivered to a distribution router and the IP address has changed
  providers, change the next hop received from the ICANN BGP feed
  to a GRE tunnel to the appropriate provider's tunnel termination box.
* At that tunnel termination box, static route all ported-in IP addresses
  to the correct distribution router.

Yum yum.

Sometimes we don't have lessons to learn from the PSTN world, and instead
the reverse is true.

Alex

Sounds like DNS.

We also get semi-annual drive-by proposals to stick the routing info into
DNS, of course.

>Don't have "real connectivity"? I've personally worked with dozens of
>Fortune 500 companies that have internal FR/ATM networks that dwarf
>AT&T, UUnet, etc. in the number of sites connected. Thousands of
>sites is common, and tens of thousands of sites in some cases. Do you
>not consider these networks "real" because each site may only have a
>16k PVC to talk to corporate?

As far as I can tell, it's pretty rare for an
organization of this size to have their own IP network that they use to
connect all their sites to the global internet, for the simple reason
that leased lines, framerelay or ATM capacity is generally more
expensive than IP connectivity.

  it is not rare at all, in my experience. my personal
  dealings with 50+ multinational corporations show that
  they -ALL- have their own corporate networks that are
  isolated from the Internet and nearly all run IP over these
  internal corporate networks. the trival cost of dedicated
  lines, or FR/ATM cloud, or VPN overlay is much cheaper
  than a dependance on upstream providers (since no single provider
  can support their needs) or exposing corporate/trade secrets
  to the broader internet.

So a single large address block is of little use to such an
organization, unless they get to announce more specifics all over the
place.

  that does not follow, except from your faulty presumption
  above.

-- bill

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>

Don't have "real connectivity"? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf AT&T, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks "real" because each site may only have a 16k PVC to talk to corporate?

That's right. If you need internet access, you need it to be faster than 16 kbps.

Who said the only purpose of IP was to connect to the Internet? 16kbps is the lowest I've seen only because that's the smallest you can buy in the FR world (Sprint's 0kbps PVCs aside). Many businesses were fine (and still would be) using 2400 baud leased lines and upgraded to FR only because it cost slightly less. A couple cashiers typing text into a green-screen app don't need blazingly-fast IP service, nor would their employer be interested in paying them to surf the web while customers are waiting.

As far as I can tell, it's pretty rare for an organization of this size to have
their own IP network that they use to connect all their sites to the global
internet, for the simple reason that leased lines, framerelay or ATM
capacity is generally more expensive than IP connectivity.

At higher bw levels, that might be true, but at sub-T1 rates FR/ATM are often cheaper to build your own network and certainly offer lower latency and higher reliability; ditto for outside major cities, where FR/ATM typically offers a zero-mile loop whereas IP connections may need to be backhauled a hundred miles or more. If T1 Internet pipes are cheaper at a particular location, some people may choose to tunnel their corporate network over it, but that is typically _all_ traffic, not just internal traffic.

There's also a security motivation as well: it's much simpler to maintain a couple firewalls at central sites (with technical staff present) than to manage thousands out at every site with a handful or even zero human users which may not even be allowed Internet access in the first place.

Even Cisco, last I checked, only connected to the Internet in four places worldwide, though they have hundreds of offices (and full private internal connectivity). Presumably they know what they're doing, or at least have a better clue than enterprises in other industries. Consider that a best case.

So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place.

In my experience, they will announce the aggregate from all hub sites plus more-specifics for that hub and the sites directly connected to it. Traffic that comes into the wrong hub due to prefix length filters (or Internet outages) is back-hauled inside the corporate backbone.

learn to love renumbering. And again, IPv6+NAT makes no sense as NAT works much better with IPv4 and with NAT you don't really need the larger address space.

If I have a disconnected network, why would I use NATs or be forced to renumber periodically?

I have no idea. Use unique local addresses instead.

Exactly.

Why should disconnected networks use global addresses (and pay rent to the RIRs) in the first place?

There aren't many networks around that are truly disconnected. Even "disconnected" networks connect to stuff that connects to other stuff that connects to the internet at some point. This means that "disconnected" address space must not overlap with addresses used on the internet. We have that in RFC 1918. However, "disconnected" networks tend to interconnect with other "disconnected" networks from time to time, which means trouble if they both use the same address space. This is where ULAs come to the rescue.

...and that's why ULAs were proposed by the IPv6 WG. Even networks that have no connectivity to the Internet are often connected to each other, and a subset of those networks will eventually have connectivity to the Internet or another network that does. But there are some truly disconnected networks as well, and ULAs are still a better choice than randomly picking a prefix out of 0::0.

S

Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

And don't forget that you still have to change your phone number when you
move a great enough distance. In IP we somehow feel it's important that
there are no geographical constraint on address use at all. That's a
shame, because even if we aggregate by contintent that would save up to
four times in the number of entries in the routing table of any router.

Not necessarily true. I live in California. However, 703-842-5527 is a
valid phone number for me. It even worked for me while I was in Puerto
Vallarta, Mexico. I can take that number pretty much any where in the
world, whether temporarily, or, even if I move there. Some exceptions
would be the few countries that are attempting to block or make VOIP
illegal, but, otherwise, I can pretty much take a VOIP phone number
anywhere I like.

Additionally, through FXP, you can take other numbers different places
as well.

However, I agree these are exceptions, not the general case. Nonetheless,
the problem can be solved. I bet companies would be more willing to
renumber when switching physical locations than they are to renumber
when switching carriers at the same physical location.

Owen

Alex,

I am aware of how telcos work in general, and, in some detail in the united
States. I also agree with most of what you said. However, consider
that somehow, they have scaled this to many many more customers than
the total number of internet subscribers. There must be something for
us to learn there, even if we are missing what it is right now.

Owen

I think this is important point that needs to be called out explicitly.

these organizations tend to have multiple sites (as you indicate above) but they generally do not have real connectivity between those sites. This means a single large prefix won't do them much good, and basically they're no different than a bunch of smaller single-site organizations.

Don't have "real connectivity"? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf AT&T, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks "real" because each site may only have a 16k PVC to talk to corporate?

That's right. If you need internet access, you need it to be faster than 16 kbps. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity.

So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place.

If we reword the last sentence to include the use of ULA addresses, to be like:

   So a single, globally routable large address block is of little use
   to such an organization, unless they get to announce more specifics
   all over the place.

This seems to imply several things:
  - when having lots of sites, you typically want to obtain local
    Internet connectivity, because transporting all the traffic over
    links or VPNs is a pretty heavy business
    * though at least the smallest sites are also likely to be solely
      obtain their connectivity using VPNs through centralized
      firewalls etc.
  - you don't want to backhaul all the traffic in the internal network
    / VPNs, so you'll either need to announce a lot of more specifics
    or use IP addresses from local internet providers
  - giving those big enterprises globally routable PI will make it much
    more lucrative for them to request allowing the more specifics from
    their upstreams, etc., thus getting us to the more specific mess.

Therefore, if we'd like to to prevent the more specific multihoming/traffic engineering mess we have with v4, most of those big enterprises don't really seem to need globally routable PI space, provided that they can already use ULAs if they want.

Don't have "real connectivity"?

That's right. If you need internet access, you need it to be faster than 16 kbps.

Who said the only purpose of IP was to connect to the Internet?

Not me. But if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :slight_smile:

The point is, that these days applications such as mail and web are sufficiently heavy that you can't even run them cost effectively over dial up (wasting your employee's time costs more than the fatter line) let alone less.

So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place.

In my experience, they will announce the aggregate from all hub sites plus more-specifics for that hub and the sites directly connected to it. Traffic that comes into the wrong hub due to prefix length filters (or Internet outages) is back-hauled inside the corporate backbone.

It would be interested to see some good statistics on this stuff. However many enterprises any of us has seen from the inside, it's still unlikly to be a statistically relevant sample.