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 --On Thursday, November 18, 2004 6:02 PM +0100 Jeroen Massar <jeroen@unfix.org> wrote:

On Thu, 2004-11-18 at 16:50 +0000, Paul Vixie wrote:

...

...

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? :)

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? :)

...

<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 ;) Larger enterprises probably consist of 200 'sites' already, eg separate 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--]

On Thu, 2004-11-18 at 16:40 +0000, Miquel van Smoorenburg wrote:

...

In article <cistron.1100794375.3557.3.camel@firenze.zurich.ibm.com>, Jeroen Massar <jeroen@unfix.org> wrote:

...

The business case of about 80% of the ISP's is Pr0n & W4R3z (or what spelling is 'in' this year?)

But.... it is not illegal to make adverts for say "Downloading the newest movies over a cool 8mbit DSL line". But downloading it itself is of course. Might be analogous to providing a busservice to the crack dealers mansion.

[OT]

That depends on the jurisdiction. In many parts of the world, downloading is NOT illegal. But making copyrighted files available for download is illegal (without the proper autorization, ofcourse).

Thus... say a newsserver full of illegal stuff is quite illegal? Or that other nice example 'proxy servers', they store the data and then relay it. A router could be said to 'store' the data also (in registers for like a zillionth microsecond ;) and

Greets, Jeroen

-- If it wasn't crypto-signed, it probably didn't come from me.

[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

Greets, Jeroen

On Fri, 2004-11-19 at 12:15 +0100, Iljitsch van Beijnum wrote:

On 18-nov-04, at 18:02, Jeroen Massar wrote:

...

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 ;) 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>

On 18-nov-04, at 18:02, Jeroen Massar wrote:

...

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

On Sat, Nov 20, 2004 at 12:58:17PM +0100, Iljitsch van Beijnum wrote:

...

On 19-nov-04, at 17:58, Stephen Sprunk wrote: 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

On 20-nov-04, at 18:34, Stephen Sprunk wrote:

...

...

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. :-) 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.

On 21-nov-04, at 20:12, Stephen Sprunk wrote:

...

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.

That assumes the company wants their employees using web or email, or that there are even humans at a site to begin with.

No it doesn't, but if this is not the case, then this clause kicks in:

...

if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-)

...

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.

An unfiltered BGP feed should give you stats on what's quoted immediately above. If you want numbers of publicly-invisible hosts, even if you knew who to ask most would refuse to answer for "security reasons" or require an NDA.

No, that's not what I'm interested in. What I'd like to know is how many big organizations backhaul their internet traffic to one or a few central sites, and how many connect to one or more ISPs locally at different sites.

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

On 21-nov-04, at 20:12, Stephen Sprunk wrote:

...

...

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.

...

That assumes the company wants their employees using web or email, or that there are even humans at a site to begin with.

No it doesn't, but if this is not the case, then this clause kicks in:

...

...

if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-)

There is an issue of uniqueness. Those hosts that can't reach the Internet typically can talk to other hosts that can, and even multiple private networks often link to each other. At a minimum, statistical uniqueness is necessary to avoid collisions between business partners even on a totally disconnected network. ULAs do not contribute to the global routing table unless ISPs allow them to in violation of the draft's wording and intent. The WG welcomes input on how to prevent this from occurring without invoking restraint of trade concerns.

No, that's not what I'm interested in. What I'd like to know is how many big organizations backhaul their internet traffic to one or a few central sites, and how many connect to one or more ISPs locally at different sites.

I personally know of several dozen, and based on information I can't disclose, I'd say that at least half if not two thirds of the Fortune 1000 backhaul their Internet traffic -- many of them via IPsec VPNs over the Internet. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin

On 25-nov-04, at 21:16, Stephen Sprunk wrote:

...

...

...

if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-)

There is an issue of uniqueness. Those hosts that can't reach the Internet typically can talk to other hosts that can, and even multiple private networks often link to each other. At a minimum, statistical uniqueness is necessary to avoid collisions between business partners even on a totally disconnected network.

Yes, this is why we need ULAs.

ULAs do not contribute to the global routing table unless ISPs allow them to in violation of the draft's wording and intent.

Well, seeing how difficult it is to get legitimate address space routed (see bogon thread) I don't see how all ISPs in the world are going to route this space unless some significant blackmail is involved (such as the likes of Google using this address space exclusively). And don't forget that this is IPv6. Today, and for the forseeable future, you can filter out all IPv6 routes that you don't like without breaking any connectivity as everything is reachable over IPv4 anyway. So people who don't want to see the ULAs in their routing table can just filter them out. (Although it works both ways: people can choose to do IPv6 using ULAs only without having to suffer unreachability.)

The WG welcomes input on how to prevent this from occurring without invoking restraint of trade concerns.

How about this: we all start announcing a few hundred random ULAs. This will make the v6 table too large to carry without filtering ULAs. I don't expect ISPs who aren't opposed to carrying ULAs for other ISP's customers to be willing to create filters that only let these specific ones through but not the background noise. It would probably also help if the ICANN directs all registries that glue records towards ULA space aren't allowed.

On Sun, Nov 21, 2004 at 07:40:52PM +0100, Iljitsch van Beijnum wrote:

...

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. :-)

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.

The Fork Lift driver in some random warehouse does not need email. All he needs is his Barcode scanner to send an 8Digit-Number over the line every 1 or two minutes and get an equal length reply telling him where to Haul the box whose barcode he just scanned. Nils

On Mon, 22 Nov 2004, Nils Ketelsen wrote:

Servicelevels on the Internet suck. Thats the main reason not to use it for anything important. If my frame-connection fails I open my hand and my provider pays a lot until it works again. If "the Internet fails", I have no one I can squeeze the money out of.

That massively increases a FR-Providers motivation to have their network running. Penalties can never make up for a lost connection (no provider has enough cash at hand) but it is a nice PART (P=Provider).

Yeah right. That's why Worldcom's frame-relay network was "unusable" for about 10 days and took out part of the Chicago Board of Trade elecronic trading system. What's interesting is most major providers' Internet service SLA is often better than their SLA for other services, including TDM. If your Internet service has problems (not just down) you may get from 0% to 100% or more credit. But if your circuit is down, it doesn't really matter. Of course, your SLA probably depends a lot on how much you normally pay the provider. If you are buying an oc48c, you'll probably pay for a different SLA than the modem dialup account.

I think this is important point that needs to be called out explicitly. On Sat, 20 Nov 2004, Iljitsch van Beijnum wrote:

On 19-nov-04, at 17:58, Stephen Sprunk wrote:

...

...

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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Sun, 21 Nov 2004 bmanning@vacation.karoshi.com wrote:

...

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

this is an assertion which many have claimed is false. based on empericial evidence.

...

- 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

this is also an assertion based on false premise.

Care to offer a couple of examples of this empirical evidence ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Nov 22, 2004, at 1:48 PM, bmanning@vacation.karoshi.com wrote:

...

...

...

Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business

this is an assertion which many have claimed is false. based on empericial evidence.

Care to offer a couple of examples of this empirical evidence ?

attached. care to provide counter examples?

While I would never argue there are companies who do not push internal data over the Internet, I am surprised you think that proves no company pushes internal data over the Internet. As for counter examples, I know of a few, but confidentiality does not allow me to discuss corporate network topology on a public mailing list. Does this mean it never happens (i.e. I am lying)? If you believe that, so be it. However, the facts are still the facts, no matter what your belief is. -- TTFN, patrick

On Nov 22, 2004, at 2:00 PM, bmanning@vacation.karoshi.com wrote:

...

While I would never argue there are companies who do not push internal data over the Internet, I am surprised you think that proves no company pushes internal data over the Internet.

i don't. my assertion is that there are significant networks that don't ever touch what we think of as the "internet" but still use IP to push datagrams around... and attempting to marginalize them as "fringe" networks that must use non-global addresses is, imho, arrogent at best.

Ahhhh, my apologies. We are in agreement, and I thought otherwise. I'll try to read more carefully next time. :-) -- TTFN, patrick

Pekka, All of the examples I referenced (which I unfortunately cannot name due to NDA) fit exactly the model you are referring to. They advertise a small number of prefixes from a small number of sites to cover a very large and diverse number of sites. They advertise the same set of prefixes from the same ASN in each of those sites. In cases where they are using VPN for backbone, they use PA space for the VPN terminators and do not advertise more specifics to accommodate this. Hope that helps. Owen --On Monday, November 22, 2004 9:11 PM +0200 Pekka Savola <pekkas@netcore.fi> wrote:

On Mon, 22 Nov 2004 bmanning@vacation.karoshi.com wrote:

...

...

While I would never argue there are companies who do not push internal data over the Internet, I am surprised you think that proves no company pushes internal data over the Internet.

i don't. my assertion is that there are significant networks that don't ever touch what we think of as the "internet" but still use IP to push datagrams around... and attempting to marginalize them as "fringe" networks that must use non-global addresses is, imho, arrogent at best.

I'm not sure anyone is marginalizing them.

The point just is that are those very big, international networks advertising the same aggregate in all the places they (publicly) connect to the net, and no more specifics anywhere?

I.e., what I'd like to see is a couple of example of international big enterprises which would not need to advertise the more specifics to Internet anywhere. How rare is this?

-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

-- If it wasn't crypto-signed, it probably didn't come from me.

If all active ASes did this we'd have a 400k routing table. So please no PI in IPv6, not even for large enterprises.

er... we'd have no such thing. -you- might, you get to have total control over what prefixes are instanciated in -your- router. you seem to have the unmitigated gaul to presume to tell me what i may or may not place in -my- routing table. neither you nor the IETF has that right. --bill

On Nov 22, 2004, at 7:01 PM, Iljitsch van Beijnum wrote:

If all active ASes did this we'd have a 400k routing table. So please no PI in IPv6, not even for large enterprises.

Why is an ISP more "worthy" or PI space than a large enterprise. In fact, ISPs are responsible for far, far more table pollution than enterprises. Pot-Kettle-Black? Besides that, please remember the Internet is a business, not a research tool or a toy for those with enable. Business have business needs. If the Internet cannot satisfy them, then the Internet will not be paid for its services. This ain't 1999 no more, you need your customers. -- TTFN, patrick

On 23-nov-04, at 6:49, Patrick W Gilmore wrote:

...

If all active ASes did this we'd have a 400k routing table. So please no PI in IPv6, not even for large enterprises.

Why is an ISP more "worthy" or PI space than a large enterprise. In fact, ISPs are responsible for far, far more table pollution than enterprises. Pot-Kettle-Black?

Besides that, please remember the Internet is a business, not a research tool or a toy for those with enable. Business have business needs. If the Internet cannot satisfy them, then the Internet will not be paid for its services. This ain't 1999 no more, you need your customers.

I'm going to try to make this my last message on this subject... It's very simple. If the routing tables get too big too fast, very bad things start to happen. The Apple example (along with some ISPs who announce dozens or hundreds of aggregatable blocks unaggregated) shows that we can't rely on good internet citizenship to manage the problem. Just to make sure everyone understands: according to the latest CIDR report there are 149080 prefixes in the global routing table, sourced by 18398 ASes. That's 8.1 prefixes per AS. If we subtract the 7506 one-prefix ASes from both figures we're at 13 prefixes per AS. Apple sources 22 prefixes from their AS. That's 70% more than the average, with the average including the largest ISPs in the world. So why is it reasonable to give even quite small ISPs a portable block but not the largest enterprises? Two reasons. First of all, the number of ISPs world wide is low enough that with the allocation policies in IPv6 ISPs alone aren't going to blow up the global routing table. The second is, that if an ISP needs to renumber, all their customers have to renumber as well. This makes renumbering much harder for ISPs than for end-user organizations. In addition to portable address space being harmful, I also believe it's not really necessary. Renumbering client-only systems is NOT a problem with DHCP or IPv6 stateless autoconfiguration. (With the latter, it's even completely transparent to the user. I've tried it.) With some tools managing the DNS during renumbering also isn't a real issue. Reconfiguring routers and other network infrastructure isn't entirely trivial at this point, but this is being worked on. I don't see why this shouldn't be solved to a satisfactory degree in the future. This leaves address-based access restrictions. There are two aspects to this: internal addresses and external addresses. Trusting packets that come from some address X on the internet makes no sense, as it's fairly trivial to hijack address space on the internet. Trusting packets because they come from an internal address is doable to a certain degree, because you get to reject packets that falsely claim to be from the inside on the borders. However, unique local addresses are just fine for this. (This means hosts that need both internal and external connectivity must have different addresses for both, but this isn't a problem in IPv6. Default address selection rules specify that when connecting to ULAs a host should use its own ULA address and when connecting to the rest of the world it should use its regular address, but this isn't fully implemented in OSes yet.) With all the above in effect, renumbering would only really impact VPN tunnels. Even if this must be done by hand I don't think it's reasonable to give out PI space just to avoid this. And I'm sure the VPN vendors can come up with mechanisms that allow the secure creation/renumbering of those tunnels, if they feel their customers need it. If organizations with PA space want to peer, this shouldn't be a problem: they just announce their /48 to their peers. Obviously if people are interested in peering, they'll be willing to carry the more specifics in their routing tables. The difference with PI is that if they filter the route out, there is no loss of connectivity. Remember that IPv4 still has a few good years in it so there is time to fix problems with IPv6 so we get to do it right from the start rather than have the same mess we have now with larger addresses.

On 23/11/2004 9:19 AM Majid Farid wrote:

Any one from LEVEL3 on the list please contact me off the list or if someone has their NOC information I would greatly appreciate if you can share it.

Did you try the contact information listed at: http://puck.nether.net/netops/nocs.cgi Todd

iljitsch@muada.com (Iljitsch van Beijnum) writes:

I'm going to try to make this my last message on this subject...

ok.

In addition to portable address space being harmful, I also believe it's not really necessary. Renumbering client-only systems is NOT a problem with DHCP or IPv6 stateless autoconfiguration. (With the latter, it's even completely transparent to the user. I've tried it.)

as long as you don't have any long running tcp sessions open at the time, or the ones you're running will gracefully restart, you'll get transparency.

With some tools managing the DNS during renumbering also isn't a real issue. Reconfiguring routers and other network infrastructure isn't entirely trivial at this point, but this is being worked on. I don't see why this shouldn't be solved to a satisfactory degree in the future.

i do. see, that is. because rapid renumbering wasn't a bilateral protocol requirement from day 1, renumbering will always be a crock of swill in ipv6 just as it is in ipv4.

If organizations with PA space want to peer, this shouldn't be a problem: they just announce their /48 to their peers. Obviously if people are interested in peering, they'll be willing to carry the more specifics in their routing tables. The difference with PI is that if they filter the route out, there is no loss of connectivity.

this assumes that the provider who assigned the /48 allows cutouts. (hint.)

Remember that IPv4 still has a few good years in it so there is time to fix problems with IPv6 so we get to do it right from the start rather than have the same mess we have now with larger addresses.

in the spirit of making lemonade, sure, let's treat the connectionless ip networking model as not having been stateless enough, and with ipv6 where we have a lot more addresses, let's just do away with ever having any one address used by any one endpoint for very long. i guess i understand that, even though it makes no sense. sort of a catch-22 thing, right? -- Paul Vixie

wsimpson@greendragon.com (William Allen Simpson) writes:

Have we learned anything in 10+ years?

yes. "the best way to do something is to DO it." -- Paul Vixie

Hi, The following just popped up in the IPv6 Global Routing tables*: 8<------------------------------------------------- inet6num: 2001:41c0::/32 netname: UK-BBC-20041108 descr: British Broadcasting Corporation country: GB ------------------------------------------------->8 It is sourced from AS31459, which is the BBC R&D AS, thus might be that it is still sort of experimental, but it is there. This also proves one big thing to all the people complaining about getting a TLA. If the BBC can get it, any large organization can get one. If you can't you simply do not network well enough. Props to the BBC for going ahead and not staying behind! (Btw, any hints on what the BBC is going to do with it?) Greets, Jeroen * = http://www.sixxs.net/tools/grh/ PS: If you are running an IPv6 capable ASN, please signup...

On 25/11/2004 08:07, Jeroen Massar wrote:

It is sourced from AS31459, which is the BBC R&D AS, thus might be that it is still sort of experimental, but it is there.

This also proves one big thing to all the people complaining about getting a TLA. If the BBC can get it, any large organization can get one. If you can't you simply do not network well enough.

The BBC are probably a bad example in this case, they're more of an ISP/Content Provider than a typical Enterprise. They're also considerably larger than the typical SME requiring multihoming, which is I think where the sticking point will be with IPv6.

The BBC has lots and lots of small regional (and sub-regional) offices to provide local radio and TV, not to mention their larger operations like TV center, broadcasting house, Pebble Mill and other production studios for programs like EastEnders. 200 locations doesn't seem that off to me.. Alot of the staf where 'outsourced' to Siemens aa couple of months, I think that was around 2000 for just the technical side (IT, comms, broadcast tech etc). Then there's presenters, journalists, researchers etc etc.. -- Martin Hepworth Snr Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 Jeroen Massar wrote:

On Thu, 2004-11-25 at 08:49 +0000, Ryan O'Connell wrote:

...

On 25/11/2004 08:07, Jeroen Massar wrote:

...

It is sourced from AS31459, which is the BBC R&D AS, thus might be that it is still sort of experimental, but it is there.

This also proves one big thing to all the people complaining about getting a TLA. If the BBC can get it, any large organization can get one. If you can't you simply do not network well enough.

The BBC are probably a bad example in this case, they're more of an ISP/Content Provider than a typical Enterprise.

Thus do they reach the currently only 'problem rule' that is set to get a /32? -> to have 200 sites in the future?

The BBC is for sure one organization, with likely a couple of sites though, but 200 would seem a bit on the high side.

Nevertheless, if they can get it why can't you as an 'enterprise', or are you just a few persons sitting in a shack with a 'company'?

...

They're also considerably larger than the typical SME requiring multihoming, which is I think where the sticking point will be with IPv6.

Small-Medium-Enterprise? <2000 employees? I call that a company not an enterprise ;)

What I am wondering actually, if any of the people who mention they have problems with getting an IPv6 TLA, if they even tried getting one... and if they did why did it fail? Otherwise one would not complain ;)

Greets, Jeroen

********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote confirms that this email message has been swept for the presence of computer viruses and is believed to be clean. **********************************************************************

On 25-nov-04, at 10:27, Jeroen Massar wrote:

...

200 locations doesn't seem that off to me..

That is exactly the right way to count ;)

Which kind of makes the point, that they deserve the /32

Well, apparently RIPE thinks they do, so there must be some piece of information that I'm not privvy to. However, in the absense of that particular piece of information, I have a hard time seeing how the BBC qualifies for a /32. Last time I checked, they weren't an ISP. 200 sites doesn't qualify you for a /32: it qualifies you for a /48 (jusst like one site does). That's 65536 subnets = ~300 subnets per site. If that's not enough, perhaps a /47 or /46 is in order, or maybe, just maybe a /40 = a /48 per site. But a /32 is ridiculous: this allows for 4 billion subnets (20 million per site). Here is a quote from the "IPv6 Address Allocation and Assignment Policy" (http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02 ): 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a) be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organizations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organizations within two years.

On 25/11/2004 12:50, Iljitsch van Beijnum wrote:

However, in the absense of that particular piece of information, I have a hard time seeing how the BBC qualifies for a /32. Last time I checked, they weren't an ISP. 200 sites doesn't qualify you for a /32: it qualifies you for a /48 (jusst like one site does). That's 65536 subnets = ~300 subnets per site. If that's not enough, perhaps a /47 or /46 is in order, or maybe, just maybe a /40 = a /48 per site. But a /32 is ridiculous: this allows for 4 billion subnets (20 million per site).

The BBC are an ISP, check out cidr-report for AS2818: 420 AS2818 BBC BBC Internet Services, UK Adjacency: 11 Upstream: 2 Downstream: 9 Upstream Adjacent AS list AS1257 TELE2 AB AS4637 REACH Reach Network Border AS Downstream Adjacent AS list AS21396 NETCONNEX NetConnex Broadband Ltd. - London, UK AS9156 BBC-US BBC Internet Services, America network AS15928 HAVENCO-AS HavenCo global AS; announced in US, London, Canada AS8401 MAILBOX Mailbox Internet UK Network AS8676 PRTSYSTEMS PRT Systems Ltd AS8910 NETALIA Netalia Internet Ltd. AS8838 ALICE Alice Networks AS8943 JUMP Jump Networks Ltd. AS8421 ALTOHIWAY altohiway Ltd

On Thu, 2004-11-25 at 09:49 -0500, Nils Ketelsen wrote:

On Thu, Nov 25, 2004 at 10:27:45AM +0100, Jeroen Massar wrote:

...

Which kind of makes the point, that they deserve the /32 and any organization that has at least quite a number of employees can thus get one. If you are too small, then you are simply: too small.

Compare it too the following: Ask a telco for 10 million phone numbers... a large company will actually use them, a small company won't ever do that in it's lifetime. Of course, when you have grown larger one can always get a large chunk, but then you really need it.

But even I as a private person, though only getting one phone number, I can keep it when I change my long distance provider.

Because a phone number is not an address but a locator. At the moment unfortunately most people use IP's also as locators, while DNS is the best fit locator, and you can keep a hostname if you also own that domain that is ;) Greets, Jeroen

On 25/11/2004 08:59, Jeroen Massar wrote:

On Thu, 2004-11-25 at 08:49 +0000, Ryan O'Connell wrote:

...

The BBC are probably a bad example in this case, they're more of an ISP/Content Provider than a typical Enterprise.

Thus do they reach the currently only 'problem rule' that is set to get a /32? -> to have 200 sites in the future?

Almost certainly. They're a very large organisation - as well as the international and internet news services you get in the US there is also all the domestic broadcasting, worldwide radio, production, merchandising etc.

The BBC is for sure one organization, with likely a couple of sites though, but 200 would seem a bit on the high side.

Well, there will probably be at least one office for every county in the UK, (For regional TV and radio) several large buildings in London, all the international offices, the various data centres...

Nevertheless, if they can get it why can't you as an 'enterprise', or are you just a few persons sitting in a shack with a 'company'?

I've worked for quite a few smaller companies where Internet access for one reason or another is business-critical. Examples would be: (I've not worked for all of the companies listed, but I know about their networks at least) - Any of a large variety of companies doing financial transactions online - (e.g. www.olf.co.uk, they do car finance via brokers over the internet) - On-line gambling companies (www.betfair.com being the largest in the UK I think, the sums of money involved are huge) - Content providers (E.g. www.digex.com, before they were bought out by MCI. I doubt google have 200 sites either.) - Small and Medium sized telecoms providers - (e.g. www.mblox.com - SMS connectivity is provided over VPNs to various European/US carriers. Also pretty much any VoIP operator.) - Aviation companies (The ones I've worked for have long since gone bust) None of these companies typically has more than four or five sites - an office or two and a couple of data centres. The largest of those I've listed is probably about 10-15 sites. As long as we have the current "200 sites for an IPv6 assignment" rule, they can't get a redundantly routable IPv6 block and there will be a significant resistance to finally phasing out IPv4. At least in Europe, when it does come to crunch time I can see the RIRs being hit *very* hard with a series of lawsuits for monopolistic/anti-competitive behaviour from some of these people - bear in mind the financial companies will have laywers on staff and simply can not afford to lose redundancy.

On 25/11/2004 12:42, Jeroen Massar wrote:

On Thu, 2004-11-25 at 10:55 +0000, Ryan O'Connell wrote:

...

- Any of a large variety of companies doing financial transactions online - (e.g. www.olf.co.uk, they do car finance via brokers over the internet)

[snip stuff about various companies]

You're looking at where the web pages are hosted. That's not the same as where mission-critical operations run from. (In fact, there is very good reason to keep your public web pages seperate as they are more likely to be subject to a DoS attack) mBlox for instance use AS30894 for actual operations - the web page is elsewhere for mostly historical reasons in that case.

...

- Content providers (E.g. www.digex.com, before they were bought out by MCI. I doubt google have 200 sites either.)

But Digex does have more than 200 customers...

That's not the requirement - the requirement is 200 sites/allocations. (I'm talking about digex.com the hosting company here - not digex.net, the internet access portion that became Intermedia)

Also Google is Akamaized and doesn't thus do their own hosting. Most likely the crawlers are in their 'own' space though.

www.google.com CNAME www.google.akadns.net www.google.akadns.net A 216.239.59.99 www.google.akadns.net A 216.239.59.104

Google just use akamaized DNS. They don't akamaize the actual content - whois on the IPs above will show that.

But most of the above need multi-homing, not address independence. None of the above neither have a need for 2^(128-32) IP addresses. They would need 1-<sites> /48's, but not 65535 of those.

Indeed. However, at the moment to get any allocation at all you need 200 sites or suballocations.

Notez bien, that even if you get a /32 or so, if you have multiple sites around the globe, are you going to announce this /32 in one chunk and are they going to do the traffic between them theirselves?

Depends, at the moment some people do announce /24s for individual locations. Some also announce a covering /19 or /20 to make sure even if their announcements are being filtered that they're still reachable, and route the packets between locations using whatever methods they might have available. (Fixed links, ISDN dial backup or even VPN) Of course, if you're anycasting or similar it doesn't actually matter which data centre the packets get to, as long as they get to one of them.

...

At least in Europe, when it does come to crunch time I can see the RIRs being hit *very* hard with a series of lawsuits for monopolistic/anti-competitive behaviour from some of these people - bear in mind the financial companies will have laywers on staff and simply can not afford to lose redundancy.

Yeah, sue time! Especially funny as you want to sue an organization that has made up the rules through it's membership ;)

This does happen and any procedure locking out smaller companies will be viewed as a highly monopolistic by the appropriate authorities. I can't say who as I don't know if the details are supposed to be confidential or not, but at least one large internet organisation (Not a number-allocation one) was put under pressure by the local equivalent to the department of commerce when it refused membership/services to someone.

Now I repeat my question (again): did any of the above companies even try to get an IPv6 allocation?

Or for that matter did any of the above do any IPv6 trails at all?

No, because they can't. Who do you suggest they approach for such an allocation? Such a project is doomed to failure before it's even started.

Why do people keep talking about 200 sites? This is a fallacy. The policy actually says: 6.5.  Policies for allocations and assignments 6.5.1.     Initial allocation 6.5.1.1.  Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a) be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organizations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organizations within two years. That's 200 other organizations, not 200 sites. Note also the requirements for LIR and not an end site. I don't know if this is in line with the RIPE policies (which is probably what BBC had to deal with, but, this is the ARIN policy, and, since this is NAnog, I think ARIN is the relevant policy). Owen

On Thu, Nov 25, 2004 at 08:20:01PM +0000, Ryan O'Connell wrote:

On 25/11/2004 17:47, Owen DeLong wrote:

...

Why do people keep talking about 200 sites? This is a fallacy.

If you're not assigning IP addresses to other users, (I.e. you're an Enterprise rather than an ISP) you need 200 sites. (As you're "allowed" one /48 per site, and need 200 /48s to get an assignment.)

Wrong. 200 "other organizations". There is one /48 per site per organization allowed without justification. So if you have one building with let's say 10 different departments (== organizations!), you can assign 10 /48 to this building, no problem. As this word "organization" is not defined, just be creative in what you call an organization. And as this makes this whole 200-orgs constraint pathetic, there is an effort underway (or even already agreed upon?) at least in RIPE region, to just scratch it completely. So it boils down to: - you're a LIR (== you pay) - you will assign to other "organizations". Definition of "organization" is up to you. So to be honest, it boils down to "be a LIR" for any mid/large company. "Only" the small ones will have real problem, but we're used to that, eh?

RIPE policy is pretty much identical to ARIN.

Jep. See: http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html chapter 3.1 Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Generally, I don't like to cross-post, but, this is definitely an ARIN policy issue, so, I'm sending it to the ARIN Public Policy Mailing List as well (ppml@arin.net). While I think it is useful to discuss such issues on NANOG, the reality is that it is more useful to discuss them on PPML and I would like to encourage everyone participating in the discussion on NANOG to continue the discussion on the ARIN PPML. According to the ARIN policy document: 6.2.9.     End site An end site is defined as an end user (subscriber) who has a business relationship with a service provider that involves: 1. that service provider assigning address space to the end user 2. that service provider providing transit service for the end user to other sites 3. that service provider carrying the end user's traffic. 4. that service provider advertising an aggregate prefix route that contains the end user's assignment As such, it appears to be a catch 22. If your organization has transit and PA space, apparently, as I read the policy, that would preclude you from qualifying as an LIR without spinning off a separate ORG to do so, then becoming a customer of that ORG. I suspect that the ARIN staff will be more reasonable about the application of this rule, but, that is just a suspicion. I think we definitely need to review v6 allocation policy and improve its consistency and ability to meet the needs of the community if v6 is to make real progress towards broad adoption. Owen --On Thursday, November 25, 2004 6:23 PM -0600 Stephen Sprunk <stephen@sprunk.org> wrote:

Thus spake "Daniel Roesen" <dr@cluenet.de>

...

And as this makes this whole 200-orgs constraint pathetic, there is an effort underway (or even already agreed upon?) at least in RIPE region, to just scratch it completely.

So it boils down to:

- you're a LIR (== you pay) - you will assign to other "organizations". Definition of "organization" is up to you.

And you cannot be an "end site", which I would expect ARIN staffers to interpret as any organization which doesn't sell transit to the public.

S

Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin

-- If it wasn't crypto-signed, it probably didn't come from me.

What you really want is PI assignments in IPv6, and you shouldn't be changing the PA allocation rules or interpretation of these rules so you can get this under the radar.

I'm not trying to get anything under the RADAR. Yes, I want to see us modify the policy to cover allocations and assignments, much as the current IPv4 policy does. However, I'm not suggesting it under the RADAR, I've been quite up front about it. ULA is an attempt to slide something under the radar, and, that is one of the reasons I have opposed it.

Tony Hain said he's going to ask for a BoF at the next IETF meeting on somewhat aggregatable PI space in IPv6, I suggest the RIRs don't take any action in this area until then.

Even if the RIRs started working on a draft now (which I think is a good idea), it would be at least a year before anything real happened on it. As such, I think there will be no difficulty incorporating the output of Tony's BOF into such policy well before it was adopted. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

Actually, as I read the policy, if you're not assigning /48s to other organizations, your an END SITE, not an LIR. Please show me where in the policy it says different. Sure, I can easily pretend to be the "internal" LIR for the "200 sub- organizations" which may conveniently map to sites, but, there's nothing in the policy (at least in my reading of it) that says anything like what you have said below. I think the policy _SHOULD_ make provisions for end sites and circumstances like this, but, currently, I believe it _DOES NOT_ make such a provision. Owen --On Thursday, November 25, 2004 8:20 PM +0000 Ryan O'Connell <ryan-nanog@complicity.co.uk> wrote:

On 25/11/2004 17:47, Owen DeLong wrote:

...

Why do people keep talking about 200 sites? This is a fallacy.

If you're not assigning IP addresses to other users, (I.e. you're an Enterprise rather than an ISP) you need 200 sites. (As you're "allowed" one /48 per site, and need 200 /48s to get an assignment.) RIPE policy is pretty much identical to ARIN.

-- If it wasn't crypto-signed, it probably didn't come from me.

At 10:09 PM 11/26/04 -0800, Fred Baker wrote:

IMHO, the rules that qualify someone for an AS number should qualify them for a prefix. It need not be a truly long prefix, but larger than a /48.

Reading my own email - that isn't clear. I think the length of the prefix given to a PI edge network should be permitted to be larger than a /48 (perhaps a /40 or a /35), but need not be as large as is given to an ISP (/30). Willing enough to take the /30, but I think the statistics likely don't support it. My reasoning: well, I work for an outfit that has an AS number, meaning that it has a certain number of ISPs. It is also an edge network. It has ~35K employees and VPNs a subnet to each employee's home. It also has lots of office space, labs, and so on. It has DMZs to the Internet in Australia, the Netherlands, and a couple of places in the US (at least, might be more). Provider-dependent addressing is a nightmare for such. Now imagine a truly large company, like GE or IBM. Hence, I will argue that more than 65K subnet prefixes should be allowable to such an edge network. How many more - well, I'll leave that to someone else to argue. The thing that brings me out here is the "one size fits all" reasoning that seems to soll around this community so regularly. "Multihoming should always use provider-independent addressing" and "Multihoming should always use provider-dependent addressing" are the statements in this debate. Well, you know what? The argument relating to someone's home while he is switching from DSL to Cable Modem access service isn't the same as the argument for a multinational corporation. I don't see any reason that the solution has to be the same either. So here's my proposal. If you qualify for an AS number (have a reasonable business plan, clueful IT staff, and a certain number of ISPs one connects with), you should also be able to be a PI prefix. And if you don't qualify for that, you should probably go provider-dependent.

On Fri, Nov 26, 2004 10:29:15PM -0800, Fred Baker allegedly wrote:

The thing that brings me out here is the "one size fits all" reasoning that seems to soll around this community so regularly. "Multihoming should always use provider-independent addressing" and "Multihoming should always use provider-dependent addressing" are the statements in this debate. Well, you know what? The argument relating to someone's home while he is switching from DSL to Cable Modem access service isn't the same as the argument for a multinational corporation. I don't see any reason that the solution has to be the same either.

This is good. The simple, elegant rules of thumb we've been trying to use for so long haven't resolved the PI argument. Adding a couple parameters is a good idea.

So here's my proposal. If you qualify for an AS number (have a reasonable business plan, clueful IT staff, and a certain number of ISPs one connects with), you should also be able to be a PI prefix.

Except that this still tries to create a simple, elegant rule of thumb, by indirection -- by dependency on how requirements are defined for something else. The requirements are similar right now but the motivation is different. People get ASNs for administrative autonomy and because of how routing works. I think we need to spell out the requirements for PI address space separately because motivations may (will!) change in the future. Reduction in overall complexity, etc. Scott

fred@cisco.com (Fred Baker) writes:

My reasoning: well, I work for an outfit that has an AS number, meaning that it has a certain number of ISPs. It is also an edge network. It has ~35K employees and VPNs a subnet to each employee's home. ...

Hence, I will argue that more than 65K subnet prefixes should be allowable to such an edge network. ...

those of us who prefer static assignment + dhcp6 over EUI64 find a /64 to be an obscene waste of address space on a per-lan (or per-vlan) basis, but sadly there are already some cool wireless gadgets whose idea of ipv6 does not include either static or dhcp6 addressing, so there's some tension. my house has four vlans (core, family, guest colo, and wireless) -- so in the cisco home networking model i'd need a /62 for fewer than 50 hosts? i mention this not just because it's a weekend but because fred also said:

The thing that brings me out here is the "one size fits all" reasoning that seems to soll around this community so regularly. "Multihoming should always use provider-independent addressing" and "Multihoming should always use provider-dependent addressing" are the statements in this debate. ...

and the unifying principle here is that people who do resource planning for both themselves and others, will tend to make certain assumptions about what the "others" actually need. could be they'll make the mistake of assuming that a multinational's needs are the same as an isp's (or that they aren't and can't be similar), as fred points out. or it could be that they'll legislate /64's per-lan or per-household. "same error." in arin-land we've seen the minimum allocation shift around over the years in a sort of "hunt and peck" attempt to discover the equilibrium between "too small for global routeability" and "too large for people who need it to be able to qualify for". in ipv6 there's been a pre-emptive strike against this kind of thing -- the minimum size is so large that almost nobody who needs it will ever qualify for it. coming as it did after all architectural design-level attempts to enable rapid renumbering were killed in their bassinets, it's enough to make one wonder either "why did we expect ipv6 deployment under these conditions?" or "who wants it dead?" i life fred's reasoning. companies with size and qualifications like cisco's should qualify for an ASN and for PI space. all the world's not a home-DSL or home-cable or isp-colo network. routing shouldn't always follow addressing. we'll need to discover a workable equilibrium unless we want to encourage NAT in IPv6 the same way we (passively) encouraged it in IPv4. -- Paul Vixie

All I hear is how this company or that enterprise "should qualify" for PI space. What I don't hear is what's going to happen when the routing tables grow too large, or how to prevent this. I think just about anyone "should qualify", but ONLY if there is some form of aggregation possible. PI in IPv6 without aggregation would be a bigger mistake than all other IPv6 mistakes so far.

And v6 without PI for will not get widespread adoption. Further, ULA will become de facto PI without aggregation. Hence my believe that ULA is a bad idea, and, my recommendation that we face the reality that PI is an important thing (unless we want to replicate the v4 NAT mess). As such, I'd much rather see us develop sane PI policy than continue down the present road. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

...

And v6 without PI for will not get widespread adoption.

...

Further, ULA will become de facto PI without aggregation. Hence my believe that ULA is a bad idea, and, my recommendation that we face the reality that PI is an important thing (unless we want to replicate the v4 NAT mess). As such, I'd much rather see us develop sane PI policy than continue down the present road.

So what would be a sane PI policy? Apparently you don't want ULAs becoming de facto PI without aggregation, so do you agree that we need aggregation for PI?

I agree that under current technology, if we are to use those addresses as both the endpoint identifier _AND_ the routing destination, there is some need for aggregation as a basic practicality of router memory and ASIC limitations. I think the mistake was in not recognizing (and doing something about) the need to address the need to separate end-point identifier from routing information early on in the IPNG process. I don't have a solid answer on how to cope with providing what is needed in terms of portable end-point identifiers. I think at least having some way of assigning/allocating them on a renewable (and, thus, reclaimable) basis is important. I think considering geographic allocation and hoping that line up well enough with topological aggregation may be desirable. Unfortunately, in today's cooperative/competitive internet, we can't expect are even really ask that provider A and provider B both accept packets for each other across certain links and forward them. Perhaps some form of mandatory settlement transit is what is needed to make this feasible (much like the current telephone system). I don't pretend to have all the answers. However, that does not change the fact that I think the IETF lost sight of the problem in this instance. ULA is an end-run on v6 registration by the RIRs and creates virtually uncontrolled PI space. I agree that PI space is needed by a variety of organizations for a variety of reasons and should not be limited to ISPs and very large organizations. Again, I think the key to being able to really implement this is that what is needed is portable end-point identifiers which can be used at least as reliably as current IP addresses for ACLs, Tunnel End-Point identifiers, etc. I think there needs to be a separation between the End-Point identifier and the routing so that routing can be aggregated. I think v6 has no provision to address this. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

In a message written on Sat, Nov 27, 2004 at 06:25:52PM +0100, Iljitsch van Beijnum wrote:

All I hear is how this company or that enterprise "should qualify" for PI space. What I don't hear is what's going to happen when the routing tables grow too large, or how to prevent this. I think just about anyone "should qualify", but ONLY if there is some form of aggregation possible. PI in IPv6 without aggregation would be a bigger mistake than all other IPv6 mistakes so far.

I find it interesting that no operators are screaming that there will be too many routes, but that all the IPv6 researchers are bringing forth this view. 8 years too late guys. We've figured out table management. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

On Sat, Nov 27, 2004 at 10:04:08PM -0500, Leo Bicknell wrote:

I find it interesting that no operators are screaming that there will be too many routes, but that all the IPv6 researchers are bringing forth this view.

ACK. All the "oh our IPv4 DFZ table explodes today" is similarily unfounded as far as I'm aware. I have not heard of anybody being able to crystal-ball the scaling limits of BGP4 yet, and currently used BGP implementations seem to cope quite well with 150k routes (set aside the notorious vendor C artificial RAM limits in older gear to make you buy new gear when table gets bigger).

8 years too late guys. We've figured out table management.

ACK, looks like that. And even if all active ASses would immediately adopt IPv6, we would land at about 18k IPv6 routes. "big deal". And I don't see multihoming adoption in IPv6 being anywhere quicker than in IPv4, so: where is the problem, please? We'll have about 1 route per ASN... so even when exhausting the 16bit ASN space, this will be only <65k routes. And when will this be, extrapolating active ASN growth? 2010? 2015? Call me a retarded idiot, but I have a really hard time seeing any _practicle_ problem with "1 ASN == 1 IPv6 prefix" at all. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Sun, Nov 28, 2004 at 09:07:47AM +0200, Pekka Savola wrote:

...

And even if all active ASses would immediately adopt IPv6, we would land at about 18k IPv6 routes. "big deal".

And I don't see multihoming adoption in IPv6 being anywhere quicker than in IPv4, so: where is the problem, please? We'll have about 1 route per ASN... so even when exhausting the 16bit ASN space, this will be only <65k routes. And when will this be, extrapolating active ASN growth? 2010? 2015?

Call me a retarded idiot, but I have a really hard time seeing any _practicle_ problem with "1 ASN == 1 IPv6 prefix" at all.

We'll run out of 16-bit ASN space much faster, and have to transition to 32-bit ASNs.

Otherwise, by making the policies a bit stricter, we might make do with 16 bit ASNs, or at least make do with them much longer.

My preference lies in making the policies a lot stricter, and actively verifying current delegations. I see a lot of ASN's requested just for fun with no real motive behind it. Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix. -- Cliff Albert <cliff@oisec.net>

On Sun, Nov 28, 2004 at 01:21:05PM +0100, Henning Brauer wrote:

* Cliff Albert <cliff@oisec.net> [2004-11-28 13:13]:

...

Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix.

unless I miss something in that proposal that means that we'll see a dramatic increase in ASNs - I mean, it is not like only organizations with an ASN assigned have v4 space now. If they have their portable address space now, why should they suddenly accept that they had to renumber when changing providers?

Because they would have to _qualify_ for an ASN first. And the rules for that are sufficiently strict - you have to prove a distinct routing policy. That means either multihoming two at least two upstreams, or upstream plus peering. The shops who have only legacy PI space announced by their single static routed upstream won't qualify. Plain simple. I say: there won't be any landrush effect, as getting ASN+PI in IPv4 is today already as easy as possible, given technical justification that you need it. The convenience factor _is_ already outlawed. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Sun, Nov 28, 2004 at 02:13:17PM +0100, Henning Brauer wrote:

there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they?

Agreed, but currently we are at "no PI for anybody but ISPs". How about first solving the PI-denial problem for those who technically need it? "Convenience PI holders" are a different problem space as you don't have to account for routing in solving it.

on the other hand, 1 ASN -> 1 v6 prefix does not necessarily mean 1 v6 prefix -> 1 ASN. might work out.

Exactly. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

* Owen DeLong <owen@delong.com> [2004-11-28 19:51]:

...

there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they? They shouldn't unless they need features that are available in v6 that are not available in v4. Where's the harm in this? The v6 stack provides for encapsulating v4 addresses in v6 easily enough and the v6 specs already make allowance for this. I don't see any reason we need to get such a site over to v6.

ehm the v4-in-v6 mapping is a gigantic security issue. this is nothing but establishing tunnels automagically and extremely dangerous. v4-in-v6 is not supported on purpose or at least disabled by default on many OSes, and that is a good thing. so you say they should just keep v4 - that does not really help in getting v6 deployed.

...

on the other hand, 1 ASN -> 1 v6 prefix does not necessarily mean 1 v6 prefix -> 1 ASN. might work out While I think a policy of "If you qualify for an ASN, you qualify for a prefix" makes sense, I do not think that the reverse makes any sense whatsoever.

ack.

...

...

The convenience factor _is_ already outlawed. true for new allocations, but there is a gigantic installed base, and making their situation worse isn't exactly helping in getting v6 deployed. As near as I can tell, there's very little reason for such a site to ever adopt v6 and very little reason for the world to care that they didn't.

i think there's many many many more of those sites than you think. and we really don't want to run in two parallel universes for longer than it has to be...

As such, I'm not sure I understand why this is a significant issue. Is there some reason it's important for these sites to go to v6 instead of using 4-to-6 address encapsulation at their border?

4-to-6 is a horrible mess. -- Henning Brauer, BS Web Services, http://bsws.de hb@bsws.de - henning@openbsd.org Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)

On Mon, 2004-11-29 at 01:11 -0800, Owen DeLong wrote: <SNIP>

How is this any more of a security hole than address-based trust in the first place. As near as I can tell, the 6-to-4 mapping is simply a legitimate form of address spoofing more than what I would call dynamic tunnels. As I understand it, there's some magic IPv6 prefix which since I don't remember what it is, I'll call <pfx> and your V4 address simply gets mapped to <pfx>::<v4addr> and away it goes.

::ffff:<a.b.c.d.>, eg ::ffff:192.0.2.42, but that is mostly (or entirely?) deprecated. The IPv4 mapped addresses give a range of nice security problems where people forget to close down their IPv6 firewall for this and thus allow IPv4 addresses into the IPv6 world and there where some other reasons. 2002:<AB>:<CD>::/48, eg, 192.0.2.42 becomes 2002:c000:22a::/48, 6to4, quite in use and works fine when the 6to4 relays are close-by for both ends. The "Instant IPv6 solution for anyone" (Reading Material: RFC3068 & RFC3056) Say, you currently have 192.0.2.0/24 (IPv4 doc prefix, can't use ;) then you thus also have 2002:c000:22a::/48 or larger of course, depending on your IPv4 space, though a /48 should be enough for most folks. Tada, because you have one single IPv4 address, that is most likely already PI in IPv4, you also have a IPv6 prefix that is PI. Now can everybody stop complaining that the installed IPv4 base already has PI and needs it too for IPv6, use above solution and get it over with. Also if you are multihomed by multiple IPv4 prefixes you can do that with the above too, just RA multiple prefixes on your network. There is one catch-22 though, according to RFC3056 Section 2.2: 8<------------------- On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on that interface. Routing policy within the native IPv6 routing domain determines the scope of that advertisement, thereby limiting the visibility of the relay router in that domain. ------------------->8 Because it would introduce a lot of IPv4 routes into the IPv6 routing tables... As at the moment most ISP's don't filter >/48 this should not be much of a problem. And folks, don't forget to setup your _own_ 6to4 relay otherwise your connectivity will be terrible. Note also that Windows XP SP1 etc support the above per default after one has typed 'netsh interface ipv6 install', though when behind a NAT it will try Teredo where possible to get out of that bubble. Thus while everybody is waiting for multi6 to solve it, see above ;) Greets, Jeroen

On Mon, 2004-11-29 at 01:59 -0800, Owen DeLong wrote:

...

2002:<AB>:<CD>::/48, eg, 192.0.2.42 becomes 2002:c000:22a::/48, 6to4, quite in use and works fine when the 6to4 relays are close-by for both ends.

OK... Seems a bit messier, and more wasteful of address space, but, if we want to blow away 4 billion /48s to accomodate v4 connectivity, it's not like we'll miss them.

2002::/16 is used as a transition mechanism as such it should go away at one point, also it would only reach maybe the ~160k IPv4 routes that already exist in IPv4 space _if_ people would use it and ignore the RFC.

...

Say, you currently have 192.0.2.0/24 (IPv4 doc prefix, can't use ;) then you thus also have 2002:c000:22a::/48 or larger of course, depending on your IPv4 space, though a /48 should be enough for most folks.

Actually, I think that would be 2002:c000:0200::, but, that's not a /48, it's a /40 (2002:c000:0200:: to 2002:c000:02ff::). One of us must be confused.

Cut and pasto from the above, forgetting to strip the .42 and making it a /40 indeed.

...

Tada, because you have one single IPv4 address, that is most likely already PI in IPv4, you also have a IPv6 prefix that is PI.

Agreed... That's pretty much what I've been saying (sort of).

...

Now can everybody stop complaining that the installed IPv4 base already has PI and needs it too for IPv6, use above solution and get it over with. Also if you are multihomed by multiple IPv4 prefixes you can do that with the above too, just RA multiple prefixes on your network.

I'm perfectly willing to live with that, but, a bunch of people are saying that that's "Not deployment of v6", "an ugly hack", and, "we don't want to keep that alive any longer than we have to." As such, there needs to be some other solution. Also, eventually, there will need to be a solution for organizations that don't have and can't get v4 space but still have the same requirements and meet the same criteria as orgs that can get v4 space today.

It is not real IPv6, only sort of, it is transition, but it can be abused for some setup like this too ;) There are quite a number of organizations who simply are using 6to4 addresses because this way they don't have to go to the RIR's and the prefixes also work behind a NAT. For that matter, next to ULA, one could use the IPv6 doc prefix internally, but you will get clashes when joining organizations, it really is not allowed in the global routing table and effectively you are stealing address space. Then again, anyone could setup his/her own registry, it would be totally not Internet related then though ;) If they can meet the v4 requirement, get some v4 space and use it for IPv6 too, two flies in one go. Note that many resources (read: google, cnn, ebay, itunes, kazaa and all your favorite nature sites) are not available in IPv6 unless using some proxy method anyway, thus you will need IPv4 at the moment for one reason or another.

...

There is one catch-22 though, according to RFC3056 Section 2.2: 8<------------------- On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on that interface. Routing policy within the native IPv6 routing domain determines the scope of that advertisement, thereby limiting the visibility of the relay router in that domain. ------------------->8 Because it would introduce a lot of IPv4 routes into the IPv6 routing tables...

Then that isn't really a solution.

One can ignore it, it has been done and people keep doing it. There is also a "one should not announce a prefix longer than the allocation" rule, but there are ISP's announcing /64's etc also.

...

As at the moment most ISP's don't filter >/48 this should not be much of a problem. And folks, don't forget to setup your _own_ 6to4 relay otherwise your connectivity will be terrible.

So I don't understand how this ends up actually working. How does the rest of the world know which 6to4 relay to send which IPv4 prefixes to?

See the RFC3056 and more relevant RFC3058. In short: * 2001:db8:300:42a:202:55ff:fe2a:580c ('real' ipv6, doc prefix) wants to send a packet to 2002:c000:22a:202:55ff:fe74:c924 Packet find a route to the router that announces 2002::/16 or longer. This box knows the 6to4 trick and deducts: 2002:c000:22a::/48 -> 192.0.2.42 and send the packet using proto-41 to that IPv4 address. That machine receives it and forwards it to the real endhost. * 2002:c000:22a:202:55ff:fe74:c924 replies packet to 2001:db8:300:42a:202:55ff:fe2a:580c Sends packet to default router, which has a default route to IPv6 prefixes and forwards it. Greets, Jeroen

On Sun, Nov 28, 2004 at 01:21:05PM +0100, Henning Brauer wrote:

* Cliff Albert <cliff@oisec.net> [2004-11-28 13:13]:

...

Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix.

unless I miss something in that proposal that means that we'll see a dramatic increase in ASNs - I mean, it is not like only organizations with an ASN assigned have v4 space now. If they have their portable address space now, why should they suddenly accept that they had to renumber when changing providers?

Hummzz, I guess that was the discussion PI vs PA that went on here ? The issue was that not only ASN delegation should be more policed but that also PI delegation should be more policed. Atleast that's my point of view. As I also stated in my last post (which you snipped out, and is pretty relevant) is that the handing out of ASN's should be harder. Currently ASN's are given to every silly dude that says 'i want multihoming'. However I understand your statement, but the IPv4 policy's are mostly there because you still have to support the old way. In IPv6 we can do things the new way, so why shouldn't we decide on new policies that get us to stop all issues we had with IPv4. -- Cliff Albert <cliff@oisec.net>

Hummzz, I guess that was the discussion PI vs PA that went on here ? The issue was that not only ASN delegation should be more policed but that also PI delegation should be more policed. Atleast that's my point of view.

I think that in the current v4 policies, ASN assignment is sufficiently policed. I think that v4 ip assignment and allocation are sufficiently policed, and, at least in the ARIN RIR case, there is reason to look at reducing (slightly) the MAU for the policing of v4 prefixes.

As I also stated in my last post (which you snipped out, and is pretty relevant) is that the handing out of ASN's should be harder. Currently ASN's are given to every silly dude that says 'i want multihoming'.

This simply isn't true. It was true several years ago, but, is not true now. (At least for ARIN. I don't know what the policies are elsewhere).

However I understand your statement, but the IPv4 policy's are mostly there because you still have to support the old way. In IPv6 we can do things the new way, so why shouldn't we decide on new policies that get us to stop all issues we had with IPv4.

That would be nice, but, eliminating PI space for organizations that are able to get it or have it today will NOT lead to IPv6 adoption and will not stop the issues. It will stop some issues from some perspectives, but, as far as a significant portion of the IP using world is concerned, a major issue is not being able to switch providers without incurring significant costs associated with renumbering. Another issue is not being able to attach to multiple providers and have transparent session-continuing failover between them. Today, we solve those issues in IPv4 with ASNs and PI space that is multihomed. Many of the current v6 proposals eliminate that solution. Please tell me how, under the current v6 policies, you propose to solve the above issues in v6? Thanks, Owen

-- Cliff Albert <cliff@oisec.net>

-- If it wasn't crypto-signed, it probably didn't come from me.

Then I think that needs to be addressed at the RIPE level. ARIN certainly made me prove that I had a unique routing policy and multiple peering connections. They wanted letters from the ISPs involved stating that yes, I had a peering (or transit) relationship with them. Owen --On Sunday, November 28, 2004 8:14 PM +0100 Cliff Albert <cliff@oisec.net> wrote:

On Sun, Nov 28, 2004 at 10:56:31AM -0800, Owen DeLong wrote:

...

...

As I also stated in my last post (which you snipped out, and is pretty relevant) is that the handing out of ASN's should be harder. Currently ASN's are given to every silly dude that says 'i want multihoming'.

This simply isn't true. It was true several years ago, but, is not true now. (At least for ARIN. I don't know what the policies are elsewhere).

I am looking from a RIPE point of view. Lately I see ISPs popping out of the ground requesting ASNs and having actually only 1 upstream (there are 2 upstreams in the routing database, but in the real world there is only 1 upstream).

-- Cliff Albert <cliff@oisec.net>

-- If it wasn't crypto-signed, it probably didn't come from me.

On Sun, Nov 28, 2004 at 08:48:43PM +0100, Daniel Roesen wrote:

...

I am looking from a RIPE point of view. Lately I see ISPs popping out of the ground requesting ASNs and having actually only 1 upstream (there are 2 upstreams in the routing database, but in the real world there is only 1 upstream).

RIPE checks new ASN assignments after 6 months for evidence of adherence to the rules. I've personally seen this happen for a customer ASN.

This is good, but it should also happen for ASN's that are already active. An check for active use of the ASN and conforming to the current rules every 6 months should be a nice thing. This way old unused ASN's can be recycled easilier. Probably RIPE will implement such a thing when there routing registry consistency check software is complete. -- Cliff Albert <cliff@oisec.net>

On Sun, Nov 28, 2004 at 09:27:40PM +0100, Iljitsch van Beijnum wrote:

...

This is good, but it should also happen for ASN's that are already active. An check for active use of the ASN and conforming to the current rules every 6 months should be a nice thing.

Good luck trying to get those AS numbers back when they are ok by the rules as per the assignment, just not the current ones. This kind of stuff is why parents want their kids to go to law school.

If such a check rules an ASN as 'not-ok' the owner of the ASN ofcourse always should substantiate his right for an ASN. If the owner can't provide evidence that he uses this ASN rightfully it should be revoked.

Reclaiming AS numbers is a waste of time. We need to move beyond 16 bits at some point anyway.

I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place.

Oh, and just for fun: tell me if you see AS12945 in your routing table. I can assure you that this AS number was assigned and is still used in full compliance with RIPE policies.

* 195.193.163.0/24 195.69.144.125 12945 I As you can see there is evidence to substantiate your claim. That you have no route: object and are advertising UUNet space under another ASN to specific peers is something else. -- Cliff Albert <cliff@oisec.net>

On Sun, Nov 28, 2004 at 11:40:59PM +0100, Iljitsch van Beijnum wrote:

...

I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place.

Well, how many AS numbers would you like to give out? 30000 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively.

First one should investigate how many ASN's can be recovered. If this is substantial one could probably last current ASN span till 2030.

...

...

Oh, and just for fun: tell me if you see AS12945 in your routing table. I can assure you that this AS number was assigned and is still used in full compliance with RIPE policies.

...

* 195.193.163.0/24 195.69.144.125 12945 I

...

As you can see there is evidence to substantiate your claim. That you have no route: object and are advertising UUNet space under another ASN to specific peers is something else.

This AS is only visible to around 20 peers. :-) Apparently you're one of them although I have no idea which one. The other peculiarities are to avoid taking up space in the global routing table, which would be more work but provide no benefits.

This has been taken from the BIT looking glass, as this is one of the peers present in the aut-num. As I said before an ASN doesn't have to appear in the global routing table, but there has to be viable evidence of the use of the ASN. -- Cliff Albert <cliff@oisec.net>

On 29-nov-04, at 7:45, Pekka Savola wrote:

...

...

I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place.

...

Well, how many AS numbers would you like to give out? 30000 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively.

Well, as I have said... having to go to 32 bit AS numbers shows that we've failed at ASN policy-making and failed at creating a scalable multihoming solution.

I can see where you're coming from, but I have to disagree. We are now more than halfway through the AS number space. If we extrapolate current consumption we'll be flat out in 5 to 10 years. That is current consumption, which presumably doesn't include any IPv6 multihomers. It also doesn't include a significant amount of latent demand, as there are lots of PI or PI-like block in the routing table without an AS number to go with them. Now reclaiming may put off the inevitable for a few years, but what good does this do? We only need one or two years to implement 32 bit AS numbers, so spending all this effort and time to gain extra time that we don't need (if we start implementing 32 bit AS numbers in the not too distant future) is just a waste of resources.

We don't _want_ to have to give out thousands of AS numbers per month or even a year. We'd (well, I at least :) would rather that that the endsites had other means to do multihoming which wouldn't require such global resources.

A few thousand AS numbers per year can easily be consumed by new ISPs, and new multihoming mechanisms are probably not going to work with IPv4 or require too many additional addresses to be practical in IPv4, so we'll still see AS numbers be consumed by IPv4 multihomers.

ASN exhaustion is IMHO just a symptom of the real problem. Enlarging the ASN space does not cure the disease, just makes it worse.

The symptom of the real problem would be _excessive_ AS number consumption. My argument is that _normal_ AS number consumption in itself warrants the upgrade. And there is nothing wrong with treating symptoms, by the way. We really don't want to arrive at a situation where it becomes increasingly difficult to obtain an AS number for those who legitimately need one.

On Mon, Nov 29, 2004 at 08:45:17AM +0200, Pekka Savola wrote:

...

Well, how many AS numbers would you like to give out? 30000 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively.

ASN exhaustion is IMHO just a symptom of the real problem. Enlarging the ASN space does not cure the disease, just makes it worse.

And this is exactly my point. -- Cliff Albert <cliff@oisec.net>

Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes.

Only if EVERY ASN were allocated and active. You and I both know this doesn't begin to approach reality. Slightly more than half of current ASNs are actually in the routing table. The ASN issuance rate is not likely to go up simply because we go to 32 bit ASNs. Probably we are really talking about a need for 20 bit ASNs or so, generally, but, 32 bits is a much more convenient boundary for lots of code implementations and lots of hardware, so, 32 bits is the chosen number for the sake of simplicity.

32bits ASN would thus just mean the end of BGP...

ULA will do much more damage than 32 bit ASNs. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

--On Monday, November 29, 2004 5:41 PM +0100 Jeroen Massar <jeroen@unfix.org> wrote:

On Mon, 2004-11-29 at 08:35 -0800, Owen DeLong wrote:

...

...

Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes.

Only if EVERY ASN were allocated and active.

*BUZZZ* ASN's are a globally unique resource, you not seeing it does not mean that it is not in use. For that matter anything from a prefix to a ASN that any of the RIR's hands out does not have to show up on the public internet, it could even be used by a single company internally, just like RFC1918 prefixes, or on a VPN etc.

<SNIP>

Duh... You're making my point for me. There won't be 2^32 routes from 1 route per ASN unless ALL 2^32 ASNs are assigned. Further, lots of ASNs get used for things that don't put routes in the global table. (If I can't see it, it's not in the global table).

Which damage might that be? The prefixes are not supposed to be put in the global routing table and even if people did, with 16bit ASN you only allow 65536 routes, which is less than current IPv4... oops let's disable repeat mode... also see my nice comment on 6to4, that is more useful if you want a globally unique /48 for sure, that is if you really 'own' the IPv4 space of that prefix.

But, that "should" becomes a purely artificial barrier which will be eliminated by market economics. Finally, with the limitations of 16 bit ASNs (which we will surpass regardless of reclamation), we won't likely end up with 1 prefix per ASN. The prefixes will be out there regardless of the number of ASNs that end up originating them.

For that matter Ford and some other /8's are only 2002:13::/24, which is the same size as the 6bone space that was handed out early on. Do also realize that if this all becomes a peep-up and the RIR's (or actually IANA) runs out of space that they can try all over 7 more times, *that* is how much IPv6 space is available.

And? Owen -- If it wasn't crypto-signed, it probably didn't come from me.

On Mon, 29 Nov 2004, Owen DeLong wrote:

...

Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes.

Only if EVERY ASN were allocated and active. You and I both know this doesn't begin to approach reality. Slightly more than half of current ASNs are actually in the routing table. The ASN issuance rate is not likely to go up simply because we go to 32 bit ASNs. Probably we are really talking about a need for 20 bit ASNs or so, generally, but, 32 bits is a much more convenient boundary for lots of code implementations and lots of hardware, so, 32 bits is the chosen number for the sake of simplicity.

Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be "no need" (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table. Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god. It's better to try to stick to 16 bit ASNs for now, and make stricter policies and reclaim the space if needed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Mon, 29 Nov 2004, Owen DeLong wrote:

...

Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be "no need" (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table.

People might argue it, but, I am not convinced they would succeed in that argument. If you want an ASN for something other than connecting to the internet for multihoming or other unique routing policy, then, make one up. Doesn't matter whether it's 16 or 32 bits. Also, there are a whole slew of private ASNs reserved for just such a purpose if you want to retain compatibility with existing ASN numbering.

Multihoming can be such a reason. Get DSL and cable to your home, request an AS number, request PI space, run BGP to multihome, etc.

OTOH, I have a SOHO with a legitimate ASN and protable IPv4 space. Who are you to tell me that it isn't legitimate for me to use it in this manner? Why do you get to decide that my SOHO is less worthy of PI space and the ability to reliably multihome just because my organization is small?

Because I have a similar organization myself, and I'm unselfish enough to realize that the organization is not sufficiently relevant in the global scale to be using such a mechanism.

...

Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god.

So we return to the need to separate the end-point identifier from the routing identifier and come up with a routing scheme that allows routing assignments to be dynamic and flexible independent of the layer 3/4 endpoint identifier.

Yes. You seem to be arguing that because we don't have such identifier split _today_, we must open the doors to give _everyone_ PI and ASN and to pollute the global routing table. I say we must close the doors even more, so that those who would need multihoming solution would pick the one based on identifier split, instead of getting the one which pollutes the global resource. If we make getting PI/ASN too "cheap" (using various metrics for "cheap"), nobody wants to get an identifier split solution.

Obviuosly, you don't subscribe to the premise that regardless of reclamation, we will run out of 16 bit ASNs soon enough. That's fine, you may be right. However, from where I'm sitting, I think we will. I also think that the $500 up front cost and $100 annual renewal associated with an ASN are decent incentive for people not to get them unless they have a legitimate use for them. Private ASNs are too easy and cost nothing.

if the prices were one or two orders of magnitude higher, that might be true. That's way too cheap as it is. 10000$ upfront, 5000$/yr for renewal might scare away who _really_ don't need them. Have the RIRs donate the markup to ISOC or whoever and we're done. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be "no need" (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table.

Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god.

This is where a sensible geographical addressing hierarchy comes in. Start by allocating a very big chunk of the v6 address space to geographical addresses. This chunk should be approximately the same size as the chunk that we expect to use with the current allocation system. We can easily afford to block off this much space in v6. Now, subdivide this chunk into 6 geographic blocks. 5 of those blocks will go to the 5 existing RIRs including Afrinic. The 6th will go in reserve to be subdivided in smaller pieces to places that don't fit the RIR system. Antarctica, ships at sea, airplanes, space stations. There is no guarantee that we would need any of this 6th block, but better safe than sorry. Now, within its geographic block, each RIR would need to develop some plan for subdividing its region into geographic areas that roughly follow the trade and fiber flows of the region. The subdivision is rough because it is not the boundaries that matter, it is the exchange points. Geographic addresses will not work without exchange points. The allocation scheme will be to give addresses to echange point areas in such a way that all addresses within an area can be aggregated outside the area. This way, the global routing tables see only 5 or 6 routes for the entire geographic space. Of course some larger providers with lots of intercontinental connectivity will see a larger number of routes to the different areas within a region. But only local providers and exchange points need to see the full detail of any particular area. This provides a way for smaller organizations to get provider independent blocks of IPv6 addresses so that they can change providers within their geographic area without renumbering. It doesn't solve every problem of renumbering, but it does provide a way for a very large number of smaller organizations to enjoy the same advantages of the larger companies without dirtying the pool in which the larger companies play. This is scalable. It introduces hierarchy in two ways. One, the geographic addresses form a separate routing topology from the flat mesh that most on this list seem to want. This makes the flat mesh more scalable. Secondly, the geographic addresses form a topological hierarchy internally which allows that topology to scale much bigger than the flat mesh. This is fundamentally an operational solution. No protocol changes are needed, the IETF doesn't need to do a thing. This plan would not work unless the RIRs plan and enforce the geographical hierarchy. On the other hand, this is well within the capabilities of the RIRs (and the NRO) to implement. --Michael Dillon

This is broken by design. What would have happend if this had be done before the fiber glut in the late 90's? As far as I am aware a couple of new fiber routes have been build and a few more cities have become nodes.

I am not suggesting time machines. I am proposing that this be done now, after the fiber glut has largely been built out and when we are in a much better position to understand how the global network will evolve. That's why I suggest that the planning for the aggregation hierarchy should be done in the regions. They know more about the topology of their region and the pressures (economic, political, social) that will drive the evolution of the network in their region.

Anything that takes geography into the routing is plain and simple broken.

Then why do major American providers require peers to be in 16 or more geographic locations? Why do people aggregate addresses geographically in their networks? It can't all be broken.

Today you hop on a plane and fly directly and non-stop from Geneva Airport to Chicago O'Hare. And it takes only 12 hours instead of one to two weeks.

Good example of geographical routing. Anyone near Chicago who wants to travel to Territet or Fribourg or Dijon doesn't need to know anything more than it is near Geneva. The national border between Switzerland and France is irrelevant since it is easier to get to Dijon France via Geneva than via Paris. However, if you make a mistake and go to Paris instead, it's not so bad, just a few extra hours. That's an example of best effort routing.

Not that this is unimportant but it's no longer where people go or come by.

Technically speaking, I don't care about where people go or where containers go. It's the fiber routes that I care about and these usually lead to interconnect points or exchanges in the major cities. I worked for GTS at the time they were building Flag Atlantic. Even though we knew that the cables landed at Crab Meadow and Long Beach, we still referred to that end as the New York end because we were only planning to connect customers to the link in the city of New York. On a trans-oceanic hop it doesn't make a lot of difference if the traffic lands in a Sprint Pop and then has to go crosstown to MCI's PoP before being routed to its destination in Rochester. Why do the Europeans need to see the topology of New York State in order to efficiently route traffic? 10 years ago we didn't have the RIR system in place to help us with geographic addressing. Today we do. Now you might be able to convince me that we could achieve similar goals by putting together route registries, RIRs and some magic pixie dust. As far as I'm concerned, geographical route aggregation is necessary for the v6 network to scale. It will happen, the only question is how we solve the problem. We won't solve it by badmouthing ULAs or SCTP or Multi6 or 32 bit ASes. The problems are real and the demand for workable solutions is real. Note the plural on the word "solutions". --Michael Dillon

David Barak <thegameiam@yahoo.com> wrote: [...]

What exactly would be so bad about taking a page from the PSTN and using a country-code-like system? There are under 200 countries on the whole planet, so that's not a huge number of bits...

Not that this avoids renumbering, as countries do occasionally split or merge. Sometimes there's also address space exhaustion within a country and renumbering is required. (I am reminded of a Londoner whining about "loads" of number changes since 1990. In fact, there have been just three: 01 -> 071/081 -> 0171/0181 -> 020.) -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key

3 bits as a prefix would work perfectly fine IMHO. This gives us an entire 32-bit space PER CONTINENT. As I noted before I don't think the penguins really need that many Ips in Antartica, but that could always be set aside. In addition, there's an extra set (only 7 continents at last count) for extra-terrestrial expansion or other needs. And, that gives the ability to filter entire continents out if necessary. The country code (ITU) isn't really a bad idea either, but I'm just thinking less overall binary bits. Scott -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David Barak Sent: Tuesday, November 30, 2004 9:58 AM To: nanog@merit.edu Subject: Re: Sensible geographical addressing --- Michael.Dillon@radianz.com wrote:

10 years ago we didn't have the RIR system in place to help us with geographic addressing. Today we do. Now you might be able to convince me that we could achieve similar goals by putting together route registries, RIRs and some magic pixie dust. As far as I'm concerned, geographical route aggregation is necessary for the v6 network to scale. It will happen, the only question is how we solve the problem.

What exactly would be so bad about taking a page from the PSTN and using a country-code-like system? There are under 200 countries on the whole planet, so that's not a huge number of bits... ===== David Barak -fully RFC 1925 compliant- __________________________________ Do you Yahoo!? All your favorites on one personal page  Try My Yahoo! http://my.yahoo.com

In the interconnected world, geography is very much irrelevant to best path routing. It's all about speeds and feeds where a local-access T-1 is obviously not preferable to a cross-country OC-3. Sounds nice on paper, but isn't really where things are at these days. Now on the other hand if bandwidth were unlimited and we all had great super-duper links between every ISP regardless of tier, THEN geographical routing would make sense. Whether you have 16 or more geographical locations doesn't necessarily equate to geographic routing. It's still longest prefix match which may be interrupted by misconfigured filters, or other circumstances. This is what happens when we try to borrow ideas from the 40-50-year-old telecom world and how basic call-routing worked in a TDM environment. Scott -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Michael.Dillon@radianz.com Sent: Tuesday, November 30, 2004 9:28 AM To: nanog@merit.edu Subject: Sensible geographical addressing [Was: 16 vs 32 bit ASNs yadda, yadda]

Anything that takes geography into the routing is plain and simple broken.

Then why do major American providers require peers to be in 16 or more geographic locations? Why do people aggregate addresses geographically in their networks? It can't all be broken.

I'm well aware that BGP is link speed agnostic. That makes it even more important (or less "not important"?) when looking at moving towards a geographical routing concept. If everything were equal, as I noted, then geographical would make perfect sense. But it isn't, so it doesn't. :) At large NAP points (the higher order ISP's) this may make some sense because of the ubiquity of larger scale lines. Throughout the entire bgp structure though, this doesn't make as much sense. The flip side, of course, is that you rely on the higher-level ISPs to do some serious policy upkeep. This hasn't seemed to help much so far, and of course, as the lower-tier ISPs or large-scale enterprises become multihomed, we still lose out on what is being bantered. Scott -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Iljitsch van Beijnum Sent: Tuesday, November 30, 2004 2:55 PM To: NANOG list Subject: Re: Sensible geographical addressing [Was: 16 vs 32 bit ASNs yadda, yadda] On 30-nov-04, at 16:29, Scott Morris wrote:

In the interconnected world, geography is very much irrelevant to best path routing. It's all about speeds and feeds where a local-access T-1 is obviously not preferable to a cross-country OC-3.

I have a very hard time seeing this as a realistic example in interdomain routing. BGP has no idea about link speeds. I've seen many occasions where BGP selects a path that is inferior because all the paths cross the same number of ASes and that's the extent of BGP's knowledge. When looking at a small scale, you're right that network topology and geography are very different. For instance, I live in The Hague, which is in a very small country very close to a major international fiber hub (Amsterdam). This means that it's almost impossible for me to reach someone else in The Hague (or the world, for that matter) without going through Amsterdam. If you look at Holland as a whole, the picture is very different: the vast majority of traffic between any two points within the country stays within the country. If you look at a Western-European scale, there is almost no traffic that leaves the region. And in 10 years, I've never seen any traffic between two points in Holland go through Africa, Asia or South America. This means that with geographic aggregation in effect, 90% of Dutch more specific routing information can be aggregated away elsewhere in Europe, 98% in North America and (possibly) 100% elsewhere in the world. Yes, there will always be exceptions. When you have a million entries in the routing table, you don't worry about the 30000 special cases as long as you can get the 970000 simple cases right. Another misconception: the aggregation doesn't have to line up with the fiber. If London needs two aggregates because one half is in the western hemnisphere and the other half is in the eastern hemnisphere, who cares? And it gets even better when you consider that an ISP will carry all of its customer routes everywhere anyway: there is no need for two peers to agree where the routing information for a certain geographic area is exchanged: peer A simply listens for the information in the location that it finds most suitable, and so does peer B. There is no requirement for this to happen in the same location, or in the "target area" itself.

Because then the specificity of the routes would become less relevant. If you have two highways available to you, then it's 6 of one and half dozen of another. You could care less which way you go. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Iljitsch van Beijnum Sent: Tuesday, November 30, 2004 7:01 PM To: swm@emanon.com Cc: 'NANOG list' Subject: Re: Sensible geographical addressing [Was: 16 vs 32 bit ASNs yadda, yadda] On 30-nov-04, at 23:32, Scott Morris wrote:

At large NAP points (the higher order ISP's) this may make some sense because of the ubiquity of larger scale lines.

Why would geographical aggregation need bigger lines?

...

Reclaiming AS numbers is a waste of time. We need to move beyond 16 bits at some point anyway.

I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place.

I think that so much will change before we exhaust 4 billion ASNs that reclaiming them between now and then is really a waste of time. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

On Sun, 28 Nov 2004, Henning Brauer wrote:

* Cliff Albert <cliff@oisec.net> [2004-11-28 13:13]:

...

Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix.

unless I miss something in that proposal that means that we'll see a dramatic increase in ASNs - I mean, it is not like only organizations with an ASN assigned have v4 space now. If they have their portable address space now, why should they suddenly accept that they had to renumber when changing providers?

additionally not all portable space is use by asn carrying orgs...

On 28-nov-04, at 5:20, Daniel Roesen wrote:

...

I find it interesting that no operators are screaming that there will be too many routes, but that all the IPv6 researchers are bringing forth this view.

ACK. All the "oh our IPv4 DFZ table explodes today" is similarily unfounded as far as I'm aware. I have not heard of anybody being able to crystal-ball the scaling limits of BGP4 yet, and currently used BGP implementations seem to cope quite well with 150k routes (set aside the notorious vendor C artificial RAM limits in older gear to make you buy new gear when table gets bigger).

Ok, I'll do this one more time. There are basically two issues: the forwarding table and BGP processing. Information in the forwarding table needs to be found *really* fast. Fortunately, it's possible to create datastructures where this is possible, to all intends and purposes, regardless of the size of the table. However, memory is a concern here, as you only have a few hundred nanoseconds to look up something in the routing table at 10 Gbps speeds. When the forwarding table gets too large and the packets rates too high, you may run into memory bandwidth problems and/or have to use much more expensive memory. On any line card, but especially on a fast one, a bigger fdb simply costs more money. For the BGP routing information base this isn't much of a problem, as you can use much cheaper and slower memory. Unfortunately, there is also the processing. Because of stuff like the longest match first rule and the presence of multiple BGP routes towards the same destination, it's much harder to use very efficient data structures for this. And to add insult to injury, the contents of the BGP table changes all the time. Now this appears to be a linear problem, but it isn't: when the routing table gets twice as big, generally this means twice as many updates (probably more, as deaggregated routes tend to flap more) but you also need to search through twice as many routes in the routing table to process each update. So the work doesn't increase as O(n) but either O(n*n) or O(n*log(n)). Now all of this doesn't mean we can't have any growth in the global routing table, but it does mean that such growth must be considerably below the Moore's Law rate (a factor 2 in 18 months or about a factor 10 in 5 years). Over the past few years the routing table growth has been very modest, but it looks like it's picking up speed again. This isn't good, although we're certainly not at dangerous levels yet.

...

8 years too late guys. We've figured out table management.

ACK, looks like that.

Yes, it's surprising how effective hoping for the best can be sometimes.

And even if all active ASses would immediately adopt IPv6, we would land at about 18k IPv6 routes. "big deal".

I have a slightly bigger deal for you. Unfortunately, I can't find the current number right now, but the number of individual /24s in the BGP table was always something like half the table when I looked. Now for an ISP, a /24 is small change, so it's likely that most of those /24s are real or defacto PI blocks that are often announced under the AS of the ISP of the week rather than under the AS of the holder of the block. If you take this number you're at around 50k. I'm not sure about how this works out in actual implementations, but it's likely a 50 to 75 k IPv6 table takes the same amount of memory as a 150k IPv4 table. Next step. In IPv4, there is downward pressure on multihoming because you can't get a route advertised that's longer than a /24. And yes, even a /24 is somewhat hard to get for most people. In IPv6, _everyone_ can get a /48. So if we allow /48 PI blocks in the routing table, how do we make sure we only allow "legitimate" PI users and not ISPs deaggregating a /32 into 64k /48s or people announcing PA /48s? This deal is getting bigger by the minute. In IPv4 it took a while before we managed to get it right, resulting in the 192.x.x.x swamp and lots of address space and AS numbers that are as good as unreclaimable. And this was all before 1993, before pretty much anyone had even heard of the internet. If we get it wrong to the same degree in IPv6 it will be much worse because the potential influx of new IPv6 users in a week is larger than the influx of new IPv4 users in any year before 1993. (For instance, if there is a land rush on AS numbers because they are a free ticket towards an IPv6 PI prefix.) Now I'm not saying that all kinds of bad things are going to happen. I'm just saying we should be very conservative in allowing unreversible changes in unscalable aspects of IPv6.

Daniel Senie wrote:

...

There are basically two issues: the forwarding table and BGP processing. Information in the forwarding table needs to be found *really* fast. Fortunately, it's possible to create datastructures where this is possible, to all intends and purposes, regardless of the size of the table. However, memory is a concern here, as you only have a few hundred nanoseconds to look up something in the routing table at 10 Gbps speeds.

This is a solvable problem. Hardware lookups are quite sufficient. Forwarding bases stored in line cards can be aggregated to the extent the data permits. Any router with 10GigE interfaces that's going to care about actually filling such pipes will have advanced hardware forwarding technology and a price tag to support the development of same.

The bottom line in this discussion is all about cost. Technology can be had to do many things that are physically possible, but as you get closer to the limits of the physics, the costs go up. Further, the marginal costs (i.e., $/packet per second) go up quite rapidly. If the size of the FIB exceeds Moore's law (and BTW, for memory it's more like 2x every 3 years), then the costs go nuts as you have to scale up from hardware parts that can't keep up. That also adds complexity. All of these costs end up factored into the cost of routers, which the ISPs must in turn factor into the costs of providing service if they are to stay in business. The problem is that the decisions to advertise a global prefix must be paid by users around the globe. If there was a way that these costs were reallocated to the site that decided to be multihomed, then the economics of the situation would balance. Imagine paying US $10K/yr to advertise a single prefix and you would get to a point where people would make some more rational decisions that didn't pollute the global table.

Even 10 years ago it was evident the routing table structures chosen by different manufacturers had significantly different performance characteristics. As there is no single data structure to define the storage of this information, it may follow that there is no singular formula for the impact of scaling.

In fact, almost all implementations now use some form of radix trie.

Over the past several years, the CPUs in routers have been considerably below the speediest on the market. I suspect there's a fair bit of headroom at present between the route processing engines in core routers and the fastest CPUs presently offered for sale. As such, I have to wonder just how much growth we could handle instantaneously, and still stay within the CPU capabilities of today's available processors. Also consider that CPU power is far from the only issue. Higher speed memory continues to be developed along with higher speed bus architectures. System performance is made up of many factors.

Do you really want to keep all routers in the world on the CPU growth curve? Do you really want the cost of replacing all of that hardware every time Intel comes out with a new processor? Again, yes, this is technically possible, but it comes with a cost. In an ideal world, the cost of running the routing subsystem would be linear only in the amount of transit bandwidth at each hop. Unfortunately, the reality is that table growth and prefix flap drive costs up faster than that and ISPs are being squeezed between costs and prices. In the long run, these costs will be passed on to the end user, or all of the ISPs will end up out of business.

Lookout above! The sky is falling.

Not at all. It will be propped up by router prices. ;-)

...

I'm just saying we should be very conservative in allowing unreversible changes in unscalable aspects of IPv6.

I'd sure like to see a lot more thorough analysis than what you provided above before reaching that conclusion. History has certainly not sided with you. Back in the mid-1990s, we were told routers wouldn't scale, so we needed MPLS. While MPLS has found useful roles in the network, it wasn't needed as a replacement for IPv4 routing in the core. Several companies, including some startups, figured out ways to route packets quite quickly.

In the long run, I'd rather provide the ability to offer the services needed. This permits the companies looking for those services to flourish and help the economies of the world. While there are challenges to be addressed, I belive those challenges will be well met by the equipment marketplace, and that innovation also will help the economies of the world. Artificial restraint does not result in expanded services or product innovations. If I had a way to vore on this, I'd vote to let the markets work.

Letting the markets work is a fine thought, but there are a few issues that will not be addressed. The global DFZ routing table is a common resource, shared and polluted equally by everyone around the world. In a purely free market world, Adam Smith suggests that everyone will act in their own best interests and pollute until the environment is no longer useful. This is frequenly known as the "tragedy of the commons". In such situations, we normally install other mechanisms to ensure that pollution is constrained, either economically or through regulation. If you take a look at the way that the phone network works, for example, adding a new area code to the NANP is painful because it means that all of the phone switches have to be updated and so the phone network routing table is a regulated entity. In the decentralized world of the Internet, we have a bigger problem in that we do not have a clear entity that impose the necessary regulatory pressures and there is no commercial pressure. All we can do is to ask people to be good Internet citizens and to act locally for the global good. The challenge, of course, is that this is in almost no one's immediate best interest. My preferred solution at this point is for the UN to take over management of the entire Internet and for them to issue a policy of one prefix per country. This will have all sorts of nasty downsides for national providers and folks that care about optimal routing, but it's the only way that I can see that will allow the Internet to continue to operate over the long term. Tony

You make it sound like the politics involved in a regulatory/governed setting are different than those involved in a commercial setting. In the end, it's all about economics. I think the UN has enough trouble managing the things it attempts to manage right now. Don't let them try to be technical too! We should have looked at IPv4 and simply added three bits as a prefix to denote continent. Giving lots of Ips in lots of different areas. Of course, then we'd argue about how the Ips for Antartica would get allocated. And then there would be the one leftover set, presumably for outer space. Just in case the United Federation of Planets ever needed to worry about IP address allocation. Gotta plan ahead, right? Same basic problems we've always had, just changing the scale to reflect the times. Technology isn't much different than any other economic/social history in that matter. :) Scott -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Tony Li Sent: Monday, November 29, 2004 11:14 PM In the decentralized world of the Internet, we have a bigger problem in that we do not have a clear entity that impose the necessary regulatory pressures and there is no commercial pressure. All we can do is to ask people to be good Internet citizens and to act locally for the global good. The challenge, of course, is that this is in almost no one's immediate best interest. My preferred solution at this point is for the UN to take over management of the entire Internet and for them to issue a policy of one prefix per country. This will have all sorts of nasty downsides for national providers and folks that care about optimal routing, but it's the only way that I can see that will allow the Internet to continue to operate over the long term. Tony

At 12:00 AM 11/30/2004, Jeff Kell wrote:

Tony Li wrote:

...

If there was a way that these costs were reallocated to the site that decided to be multihomed, then the economics of the situation would balance. Imagine paying US $10K/yr to advertise a single prefix and you would get to a point where people would make some more rational decisions that didn't pollute the global table.

Now there's a thought, and a pretty darned good one. But, where would the money go? Upstream(s)? It would certainly encourage more forethought into advertisements and aggregation. But it leaves a lot of room for the economics to click.

If we're going to entertain a settlement-based approach, why stop there? We should add settlements to traffic, so the ISPs of end users pay content providers for the content, rather than the present system where content providers and end users all pay the folks in the middle (who still seem unable to make any money). As Tony noted elsewhere in his note, the Internet doesn't have a central authority to impose the fees. It's a cooperative environment. We all advertise routes that we need, and hope others will take them. Just like we all filter traffic entering our networks at our borders so everyone else won't have to deal with spoofed traffic injected elsewhere (what? do something that helps the community as a whole?). Keeping the Internet functional is a community, cooperative effort. The fee Tony proposes likely will just result in only the larger companies being able to connect to the Internet, and would put a lot of smaller companies out of business. But that'd be best for the Internet, perhaps?

At 08:14 PM 29-11-04 -0800, Tony Li wrote:

In the decentralized world of the Internet, we have a bigger problem in that we do not have a clear entity that impose the necessary regulatory pressures and there is no commercial pressure. All we can do is to ask people to be good Internet citizens and to act locally for the global good. The challenge, of course, is that this is in almost no one's immediate best interest.

My preferred solution at this point is for the UN to take over management of the entire Internet and for them to issue a policy of one prefix per country. This will have all sorts of nasty downsides for national providers and folks that care about optimal routing, but it's the only way that I can see that will allow the Internet to continue to operate over the long term.

Before going to the UN (and I assume you mean the ITU), I would prefer to see ICANN+IANA+RIRs do the necessary work involved. That means that in addition to allocating IP blocks to ISPs and end customers, to also police said resources. It is always mentioned that IP blocks are not "bought" or "owned" but "leased" out by the RIRs. If an ISP is polluting the commons, then the RIR that allocated the IP resource should first contact the customer. If the customer doesn't mend their ways, then the RIR should be free to start announcing that IP block and static route it to some RIR blackhole. That would definitely get the attention of the wayward ISP/customer. Of course all this would have to be backed up by IAB+IETF as well, but I think we should learn to police ourselves before we ask for the UN/ITU to do it for us. -Hank

On Sat, 27 Nov 2004 18:25:52 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:

All I hear is how this company or that enterprise "should qualify" for PI space. What I don't hear is what's going to happen when the routing tables grow too large, or how to prevent this. I think just about anyone "should qualify", but ONLY if there is some form of aggregation possible. PI in IPv6 without aggregation would be a bigger mistake than all other IPv6 mistakes so far.

The entire Internet routing table doesn't have to be centralized in the core and it doesn't even have to be done by what are now called routers. While most will instantly pronounce it as unworkable without even trying, source routing or routing at another layer is an alternative way at dealing with this problem. Excuse me while I quote out of order, you say:

While IPv6 is still IP, it's not just IPv4 with bigger addresses. We have 128 bits, so we should make good use of them. One way to do this

Should IPv6 routing just be IPv4 routing with bigger addresses? John

--On Friday, November 26, 2004 10:09 PM -0800 Fred Baker <fred@cisco.com> wrote:

At 11:31 PM 11/25/04 -0800, Owen DeLong wrote:

...

I think the policy _SHOULD_ make provisions for end sites and circumstances like this, but, currently, I believe it _DOES NOT_ make such a provision.

I understand the policy in the same way. That said, I believe that the policy is wrong.

Agreed.

IMHO, the rules that qualify someone for an AS number should qualify them for a prefix. It need not be a truly long prefix, but larger than a /48.

I agree with the first part, but, a /48 is 65,536 64 bit subnets. Do you really think most organizations need more than that? Or, by larger than a /48 did you mean a longer prefix (smaller allocation/assignment)?

My logic is this. We grant someone an AS number not because we think they are an ISP, but because we believe that they are sufficiently well connected that using BGP to advertise their routing is necessary, and running BGP to a number of neighbors implies an AS number. Well, if you are sufficiently well-connected to need to advertise your routing in BGP, ingress policing is going to materially hurt you in your use of said multiple ISPs. You want an address that you can safely originate from, and you want to be able to use routing to multihome in the other direction.

Agreed. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

--On Thursday, November 25, 2004 9:59 AM +0100 Jeroen Massar <jeroen@unfix.org> wrote:

On Thu, 2004-11-25 at 08:49 +0000, Ryan O'Connell wrote:

...

On 25/11/2004 08:07, Jeroen Massar wrote:

...

It is sourced from AS31459, which is the BBC R&D AS, thus might be that it is still sort of experimental, but it is there.

This also proves one big thing to all the people complaining about getting a TLA. If the BBC can get it, any large organization can get one. If you can't you simply do not network well enough.

The BBC are probably a bad example in this case, they're more of an ISP/Content Provider than a typical Enterprise.

Thus do they reach the currently only 'problem rule' that is set to get a /32? -> to have 200 sites in the future?

The rule does not require you to have 200 sites in the future. The rule requires you to have a plan to assign addresses to 200 other organizations.

The BBC is for sure one organization, with likely a couple of sites though, but 200 would seem a bit on the high side.

If they are reselling IP services, then, likely they can find 200 customers to assign address space to (or at least have a plan to do so).

What I am wondering actually, if any of the people who mention they have problems with getting an IPv6 TLA, if they even tried getting one... and if they did why did it fail? Otherwise one would not complain ;)

If I wanted one, I could probably get one. However, that doesn't mean I have to agree with the current allocation/assignment policy. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

I have worked for multiple enterprises where both of the statements below were false. There are many enterprises which run their own backbones, have internet access at some subset of their sites, and, backhaul all traffic on their own backbone to enforce policy at the internet borders. Some of them use internet based VPNs as part of their backbone, but, in those cases, most have forced ALL traffic leaving the site through the VPN, so, users at the site have no direct or independent internet access. The VPN terminators are, in those cases, usually on PA space. The office network is usually either RFC-1918 or PI space depending on the enterprise. All of the enterprises with which I am familiar would prefer PI space to RFC-1918, but, because of IPv4 limitations, some accepted 1918. Most will not accept a 1918-like solution in v6. I cannot name the enterprises because of NDA issues, but, there are at least 10 that I know of that expect to go to PI space in v6. Owen --On Monday, November 22, 2004 8:24 PM +0200 Pekka Savola <pekkas@netcore.fi> wrote:

On Sun, 21 Nov 2004 bmanning@vacation.karoshi.com wrote:

...

...

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

this is an assertion which many have claimed is false. based on empericial evidence.

...

- 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

this is also an assertion based on false premise.

Care to offer a couple of examples of this empirical evidence ?

-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

-- If it wasn't crypto-signed, it probably didn't come from me.

On 19-nov-04, at 18:40, Owen DeLong wrote:

...

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.

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.

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.

This isn't just a US phenomenon. Companies like http://www.telphin.com/numbers.php are selling this kind of number portability in other countries. And I remember some Australians were routing US phone numbers to their mobiles back in 1997. Clearly, telephone numbers are now being treated as names rather than addresses. The technical issues we should be concerned with are down at the address level. Could continental aggregation be a way of reducing the size of the so-called global routing table so that the table can accomodate a larger number of specifics within the continent? Alex Bligh raised the spectre of GRE tunnels to redirect traffic to the right location. Could this be done by simply readdressing the packets? Is this even relevant in a world that runs IPv4 and IPv6 over MPLS? After all MPLS is designed to swap and pop destination labels to route and reroute packets through the network. In a real-world network perhaps we should accept that some problems will be solved outside of IPv6. --Michael Dillon