On Sun, Nov 14, 2004 at 07:55:56PM -0800, Randy Bush wrote:

...

in august 2002 there were no v6 isp's.

you're kidding, right? let's not be too americocentric. i assure you there were.

ACK, just look at the "Allocated" column at: http://www.sixxs.net/tools/grh/tla/ripe/ http://www.sixxs.net/tools/grh/tla/arin/ Better disregard the "First seen" column, it seems to be incomplete in many cases. Agreed, this doesn't tell much how usable those were for any serious transit (probably almost none). Unfortunate, even today there are not many option of transit ISPs who have a real native dual-stack deployment (I consider 6PE to be native)... most have just tunnels inside. Currently I cannot think of more than... hm... 3-4 ISPs who can deliver real amounts of native US-EU bandwidth.

i think even c&w might have been deploying in the states then.

No, they weren't, but they are now. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Mon, Nov 15, 2004 at 09:29:25AM -0500, Christian Kuhtz wrote:

On 11/15/04 12:18 AM, "Daniel Roesen" <dr@cluenet.de> wrote:

...

Unfortunate, even today there are not many option of transit ISPs who have a real native dual-stack deployment (I consider 6PE to be native)... most have just tunnels inside. Currently I cannot think of more than... hm... 3-4 ISPs who can deliver real amounts of native US-EU bandwidth.

What sort of customers do these v6 SP's have for IPv6? What demands are there for real amounts of IPv6 bandwidth?

I've historically found that there are a number of FTP sites that get congested on IPv4 but are accessable via IPv6 (only). I have a /48 at home, but am only using about 4 /64's on my various subnets (servers, wireless, office lan, etc..) I'd say that about 1-5% of my home bandwidth usage (on average) is IPv6 only. I'm sure it's going up with the number of sites doing v4+v6 (eg: roots) increasing. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Mon, 2004-11-15 at 11:03 -0500, Jared Mauch wrote:

On Mon, Nov 15, 2004 at 09:29:25AM -0500, Christian Kuhtz wrote:

...

On 11/15/04 12:18 AM, "Daniel Roesen" <dr@cluenet.de> wrote:

...

Unfortunate, even today there are not many option of transit ISPs who have a real native dual-stack deployment (I consider 6PE to be native)... most have just tunnels inside. Currently I cannot think of more than... hm... 3-4 ISPs who can deliver real amounts of native US-EU bandwidth.

What sort of customers do these v6 SP's have for IPv6? What demands are there for real amounts of IPv6 bandwidth?

http://www.sixxs.net/misc/traffic/

I've historically found that there are a number of FTP sites that get congested on IPv4 but are accessable via IPv6 (only).

There are, as demonstrated from above graphs, quite a number of people who also found out that some news server has this feature ;)

I have a /48 at home, but am only using about 4 /64's on my various subnets (servers, wireless, office lan, etc..)

I guess most people, who are a bit into computers, at least have 2 LAN's: wired and wireless. Some, like Jared apparently, even make seperate subnets per room. Though 2 is quite common. With the future in mind though (read: toys toys toys), I see it very likely that the amount of subnets will grow at a large rate.

I'd say that about 1-5% of my home bandwidth usage (on average) is IPv6 only. I'm sure it's going up with the number of sites doing v4+v6 (eg: roots) increasing.

I guess my usage is somewhat the same when I was still really actively using that network. The only solution to getting more IPv6 content: crontab that request message and spam Google and others to provide IPv6 capable servers (and crawlers). Doom3 doesn't do IPv6 either yet unfortunately (afaik)... I still wonder, it is even easier to use getaddrinfo()* to write socket related code, thus what is the problem of doing IPv6 in software? (Except for the lame excuse of having 'latency' when the stuff is not configured correctly and you have to time out before connecting) Greets, Jeroen * = http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html http://www.kame.net/newsletter/19980604/

On 11/18/04 5:44 AM, "Mike Leber" <mleber@he.net> wrote:

On Sun, 14 Nov 2004, Randy Bush wrote:

...

...

in august 2002 there were no v6 isp's.

you're kidding, right? let's not be too americocentric. i assure you there were. i think even c&w might have been deploying in the states then.

Heh, when I saw his assertion I figured a statement as wrong as that wasn't worth correcting. (my bad)

Since you chimed up I thought I'd go and check our press releases for when we got around to announcing we were selling IPv6 connections and I found something dated May 9th, 2001. At that time we already were offering native (as opposed to our free IPv6 tunnel service) IPv6 connections at several locations in the US.

So, again, somebody says they're selling it.. And without wanting to sound like a flame.. what volume of native, non-tunnel IPv6 traffic do you see and what applications is it? Could you throw those of us a bone who are still scratching our heads as to what business cases support this? ;) Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 117

On Thu, 2004-11-18 at 10:29 -0500, Valdis.Kletnieks@vt.edu wrote:

On Thu, 18 Nov 2004 09:18:22 EST, Christian Kuhtz said:

...

So, again, somebody says they're selling it.. And without wanting to sound like a flame.. what volume of native, non-tunnel IPv6 traffic do you see and what applications is it? Could you throw those of us a bone who are still scratching our heads as to what business cases support this? ;)

The point is that Randy was wrong when he said there weren't any v6 ISPs in 2002, because at least some were doing it a year before that.

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

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. In short.... when those porn providers join the boat with the warez providers IPv6 will have a lot more traffic for sure. Operational part: most (all?) of the IETF servers don't support IPv6, guess where they are located ;) Greets, Jeroen

The point is that Randy was wrong when he said there weren't any v6 ISPs in 2002, because at least some were doing it a year before that.

actually that was me. i had no idea anybody was offering ipv6 transit service when isc first brought up ipv6; while he.net and verio both offered us transit, that was later on (and, thank you both!) in any case it would only have changed one thing: we would not have deployed ipv6 at all if we'd had to use provider assigned addresses. we're multihomed and we peer directly in a lot of places and if PA was the only thing available we would have put up a /64 bastion network with each provider who assigned us address space, and either not used ipv6 internally at all, or used "sitelocal" space, in other words, NAT.

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. ipv6 is "too little, too soon". as long as we're making routing follow addressing (by requiring endsites to use PA space), bastion nets and NAT will rule the enterprise. ipv6 will work fine for the vast majority of smaller dsl-connected or cable-connected (or ppp-connected if there still are any) users, and for mobile data applications, and even the internet-datacenter market. 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. perhaps this size and style of networking has been marginalized, and ipv6 will take off even without them. i'm not sold on that proposition. and this isn't just me still being bitter about the destruction of matt crawford's A6/DNAME architecture by the ietf secret handshake society. i really think that the ipv6 architecture is fundamentally flawed in that it doesn't address ipv4's "routing follows addressing" problem. we're still facing a choice between a routing table that's too large and flaps too much, or universal NAT by anyone who fears a renumbering penalty when they tell their ISP to pound sand.

Thus spake "Owen DeLong" <owen@delong.com>

...

It appears Iljitsch would have been correct to say "there is no _new_ PI in IPv6 unless you're an internet exchange or a root server." As long as this remains true, there are nearly a dozen identified reasons why people would want/need ULAs, which was the original point of this subthread.

The point of the thread, in my opinion, is that changing the RIR policy to support the needs met by ULA makes more sense than creating a separate registry system and defining multiple address classes which are theoretically routable and unroutable. Especially when we consider that the definition of unroutable is very fuzzy at best.

Having every BGP peer require manual configuration to allow propogation each ULA prefix makes global routability darn near impossible. Unfortunately the wording on preventing global use was weakened significantly when "restraint of trade" fears came up. I do think, at a high level, that having a registry for non-routable addresses makes sense iff those addresses could be kept that way. There is no reason for RIRs to allocate addresses which would never be used on public networks.

...

The RIRs, of course, are free to make IPv6 PI space available, and most of the justification for ULAs would disappear if that were to occur. However, there is no indication that this is coming, so absent any other ways to meet those needs, ULAs have a purpose.

Yes... Undermining the policy process of the RIRs. Other than that, they have no purpose.

As an argument against centrally-assigned ULAs, they certainly do undermine the RIRs. If the various RIRs provided a viable PI allocation model, then that half of the proposal would largely be moot. However, undermining the RIRs was not the purpose, just the most expedient method of meeting the stated needs. Locally-generated ULAs meet a need, like RFC 1918, that the RIRs will never (and probably should never) meet -- cost-free and paperwork-free addresses. Local ULAs also have the benefit that it's easy to explain to customers why ISPs won't route them, which has been cited as a problem with central ULAs. Are there objections to local ULAs as proposed, or is all this debate focused only on central ULAs?

ARINs members do _NOT_ approve policy. The BOT approves policy. The BOT only approves policy after it is recommended by the AC. The AC is not made up of ARIN members, and, is not elected by ARIN members. They are elected by the ARIN community at large. Basically, ANYONE can vote. The AC recommends policy to the BOT based on consensus and discussion on the PPML and at the ARIN Public Policy meetings (twice a year). While it is true that a majority of the people who show up are ISPs, there is no price of admission for joining and participating in the PPML, and, the registration fee for the meetings is quite nominal.

Thanks for the reminder on how ARIN works; since I'm not a member, I haven't looked at the process details since ARIN was first formed.

Decisions are made by those who participate. If you want input into the ARIN policies, then, participate in the policy process. If you thing it's someone elses job to make ARIN policy, then, accept the job they are doing, or, contribute.

Or simply route around the failure via the IETF/IANA, which is what the drafts' authors did. That method has the advantage of not needing to be redone for each of the RIRs, but obviously has other disadvantages. At the personal request of an AC member, I will be requesting suggestions on PPML for IPv6 PI space requirements and then submitting a policy proposal. We will see what happens after that. 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

...

Locally-generated ULAs meet a need, like RFC 1918, that the RIRs will never (and probably should never) meet -- cost-free and paperwork-free addresses. Local ULAs also have the benefit that it's easy to explain to customers why ISPs won't route them, which has been cited as a problem with central ULAs.

But locally-generated ULAs aren't ULAs, they're NLAs, so, what's the point of creating this giant address space for people to allocate from willy-nilly. If you want to define an RFC-1918 style /32 everyone can play in, go for it. You'll have all the same problems and solutions of RFC-1918. If you want to avoid such collisions as have been the problem with RFC-1918, then, you need an address registry, and, let's just accept that this isn't a bad thing any more in IPv6 and get the RIRs allocating such space in a reasonable fashion. I'm perfectly willing to have the RIRs delegate this space from a separate IPv6 block for that purpose, and, the RIRs are capable of doing this. They're already doing it for IPv4 based on 2002-3 and 2003-15.

There are a few issues with a registry for ULA address space: Cost: I find it hard to believe anybody will run a registry for ULA address space at no cost to the registrant. Elgibility: If the purpose of a registry is to keep ULAs globally unique what criteria need to be met to obtain ULA space. That cames back to my issue (with my clueful end-user hat on) of how an enduser with a small (or not so small) local network can statically assign ipv6 addresses to local devices. The requirement for that local ipv6 space is that it does not ovelap with any current or future globally routable ipv6 space. After all, some of the device on that local network will need global access and would be able to reach a global site that has the same address as the local site. Obviously, since this is non-routable, only locally significant, space I am not willing to pay for this space. Adi

The RIRs' current business models (charging rent for WHOIS and DNS entries) are not compatible with the needs that the IPv6 WG defined, particularly in the cost and paperwork areas. The odds of success appear to favor a new entity for a new function instead of leeching off an old entity that was designed for a different purpose.

Then there is a disconnect between the world of the working group and the operational reality of running a network in my opinion. I just don't see $100/year regardless of size as being a financial barrier to end-sites. When you consider that the average organization these days appears to have at least half a dozen domains, and, domains are usually ~$15/year each, there's just not a big price difference between the domain space and the IP space.

...

Why set up a separate registry system for these addresses instead of making minor changes to the existing one to accommodate this need? There is no reason to invent the square wheel manufacturing plant when we have a perfectly good round-wheel plant which can be easily retooled for a fraction of the cost.

If ARIN, RIPE, APNIC, LACNIC, or AfriNIC wish to provide the service specified in the draft, they're welcome to volunteer for that function. That some folks have considered ULAs a "threat to ARIN's viability" is an indication that it isn't likely.

Mandating that registration be performed as a free service in perpituity is not a sustainable model. It is a fictitious concept. However, a service temporarily provided poorly for free can still undercut the same service provided professionally for a reasonable fee to the point of putting the professional organization out of business. This is rarely good for the consumers who later discover that noone is providing the service at any price because the professionals got out of the business unable to compete with the freebies, and, the freebies discovered that it cost money to provide the service and walked away too.

Again, in the IPv6 WG there were folks who offerred to operate the ULA registry _for free_, and I'm sure many others would be willing to operate it under the initial-cost-only terms in the draft. The RIRs do not appear to be.

Did they accept any contractual obligation to do it for any particular length of time? Are they identified such that there is accountability to the community and standards for this process that they must follow? There are a lot of things involved in running a registry that are simply not factored into this draft, and, I believe the WG has it's head in the sand when it comes to what it costs to properly run a registry.

...

But locally-generated ULAs aren't ULAs, they're NLAs, so, what's the point of creating this giant address space for people to allocate from willy-nilly.

The odds of collision in a 2^40 space are low enough to consider even locally-generated prefixes unique. For any practical purposes, both ranges are ULAs.

Only if there is some mechanism to guarantee good hashing and everyone uses the same or at least similarly good mechanisms for that hashing.

...

If you want to avoid such collisions as have been the problem with RFC-1918, then, you need an address registry,

That was why a central registry was added to the ULA draft (and later split off into a separate draft): some folks, e.g. you, are apparently not willing to tolerate the 2^-20 chance of collision with a partner. I'll take that over the 100% chance of collision under RFC1918 or Site Locals.

Sure, but, why not just go to unique addresses and be done with it.

...

and, let's just accept that this isn't a bad thing any more in IPv6 and get the RIRs allocating such space in a reasonable fashion. I'm perfectly willing to have the RIRs delegate this space from a separate IPv6 block for that purpose, and, the RIRs are capable of doing this. They're already doing it for IPv4 based on 2002-3 and 2003-15.

I'll support unrestricted PI allocations in place of central ULAs, but there is still an identifiable need for local ULAs.

Why? Why do you need local ULAs instead of UGAs? What does a ULA do for you that a UGA doesn't?

2002-3 only applies to multihomed entities and 2003-15 only applies to Africa. ARIN's existing IPv4 policies explicitly tell organizations to use private address space and not apply for PI space, though 2004-3 may add an exception to allocate PI space if further use of RFC1918 is _impossible_. This is far from the direction you imply.

My point was that the pricing structure isn't a barrier and that ARIN policy does and can be changed in response to community need and input. I think the chances of getting something more flexible with IPv6 than currently available with IPv4 should be pretty good. Especially if the membership is asked "Would you prefer a competing registry for ULAs or to implement a v6 assignment policy that allows organizations to get UGAs to meet that need?"

And then, of course, there's the issue with paying rent for the rest of eternity.

It's not rent, it's a registration fee, and, you pay that for your domains as well. You pay that for your telephone directory listings. It's a very small fee, and, I just don't see that as a meaningful argument. Heck, I'd be happy if I paid as little to register my car as I do to register my IP space each year. I get quite a bit more use out of my IP space then out of having a unique identifier on my car.

...

Hmmm... Then perhaps I should solicit the other people I know who don't like the recent actions of our government and we should route around the damage of the united States Congress? Yes, I'd say it has other rather obvious disadvantages.

Congress has final legal jurisdiction; the only way to route around them is via the Supreme Court. The RIRs are more similar to states, which are bypassed all the time by federal preemption (IETF/IANA do this less often, but it happens).

No... This is not true. There are a number of ways to route around congress, some legal, some not. + civil disobedience (questionable legality) + Article 5: The Congress, whenever two thirds of both Houses shall deem it necessary, shall propose Amendments to this Constitution, or, on the Application of the Legislatures of two thirds of the several States, shall call a Convention for proposing Amendments, which, in either Case, shall be valid to all Intents and Purposes, as Part of this Constitution, when ratified by the Legislatures of three fourths of the several States, or by Conventions in three fourths thereof, as the one or the other Mode of Ratification may be proposed by the Congress; Provided that no Amendment which may be made prior to the Year One thousand eight hundred and eight shall in any Manner affect the first and fourth Clauses in the Ninth Section of the first Article; and that no State, without its Consent, shall be deprived of its equal Suffrage in the Senate. + Armed Insurrection (definitely illegal) + Terrorist Act (also illegal) + Use of pre-existing State Law for pre-emption + Renouncement of Citizenship (in some cases) + Recall Petitions + Franked Mail Protests

The disadvantages I see here are (a) people think ULAs, of either variety, will end up being routed, and (b) the RIRs don't want to miss out on rental income. Both presume that ULAs will be used for the same purposes that PI space would be used for and that the two are direct substitutes; I assert that neither is true.

If you think (a) is not true, then, you really need to put down the crack pipe and look at the fact that most of the world operates on the basis of a capitalist economy, consider the economic factors at work, and, then, consider what ISP is going to refuse to route them when one of those big companies your so fond of dangles dollars in exchange for doing so. (b) is not the case. The RIRs recognize that running a registry costs money. There are operational costs with any entity, and, a global IP registry (or even a regional or local one) is no exception. They also know from experience that there are lots of ways to run a registry badly. That running a registry carries with it a stewardship role and certain other obligations and that all of these cost money to implement and/or scale. They recognize that it's easy to run a registry for a little while without it costing very much, but, that as issues arise and scaling becomes more important, costs go up and solutions that were easy when it's small end up requiring significantly more labor to scale. As a result, the RIRs don't believe that the free ULA business model is sustainable, but, it will undercut their ability to maintain what, so far, is a proven and sustainable model for doing such registrations.

...

...

At the personal request of an AC member, I will be requesting suggestions on PPML for IPv6 PI space requirements and then submitting a policy proposal. We will see what happens after that. ... FWIW, I will strongly support any proposal to make it easier for organizations to get rational IPv6 allocations of PI space.

Glad to hear it.

I still think there's sufficient demand for locally-generated ULAs even if changes in PI policy make centrally-assigned ULAs mostly moot.

And I still wonder why. Owen

John Curran wrote:

... If ARIN's members direct it to provide such a service, and provide guidance that the fees should based initial-only and on a cost recovery, I have a lot of faith that it would occur...

That does, of course, presume that the operator community actually agrees with the need for ULA's and draft's philosophy on pricing.

And that is the basic problem. The primary value of ULAs is with the end site, not the operator community. The IPv6 public prefix allocation policy that only operators get them ensures that the ARIN membership will be heavily weighted against the target audience for the technology. I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Tony

Owen DeLong wrote:

...

I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them.

Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result.

This argument is basically saying that the RIR membership knows it is forcing allocation policies that are counter to the market demand. The only way ULAs could be considered for grey market PI use is due to lack of any alternative mechanism to meet the real customer requirement for independence. The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Everyone acknowledges that the demand for PI space is real while simultaneously refusing to seriously deal with it (and the re-architecting of fundamental assumptions about the Internet effort of multi6, while serious, is not a short term solution). My to-do list for the next couple of weeks has an item to ask for a BoF at the next IETF on an interim moderately aggregatible PI approach. I cc'd the Internet ADs since this is as good a time as any to start the process. I have a proposal on the table, but I care more about a real solution than I do about that specific approach. At the same time I continue to get comments like: 'Your geographic addressing proposal (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty much ideal, really)', so it probably makes a good starting point for discussion. Tony

Steven M. Bellovin wrote:

... The problem with this scheme is that it's only aggregatable if there's some POP that lots of carriers connect to in the proper geographic areas. What is the carriers' incentive to show up -- peer? -- at such points, rather than following today's practices?

It doesn't require POPs per se, but that might be the simplest implementation. It does require some form of peering agreement for a service region which could be implemented with traditional transit arrangements. The incentive question is still open though. One incentive would be the trade-off against a routing swamp, but by itself that is probably not enough. Another incentive might be to stave off the recurring threat that the ITU/Governments could impose worse approaches. If I had an answer to the incentive question it would probably be easier to make progress. Tony

On 25-nov-04, at 13:46, Michael.Dillon@radianz.com wrote:

...

The problem with this scheme is that it's only aggregatable if there's some POP that lots of carriers connect to in the proper geographic areas. What is the carriers' incentive to show up -- peer? -- at such points, rather than following today's practices?

Leaving aside the specifics of any particular geopgraphic addressing scheme for the moment...

Right. There are several ways to do this.

If we adopt a geographic addressing scheme for a part of the IPv6 space we are really saying that we expect a part of the IPv6 network topology to be geographically based.

This is what it seems like on first glance. However, if we take a different approach we arrive at the same result but with a very different mindset. The idea is that we need to aggregate, because if we let anyone and everyone have a PI block without aggregation in IPv6 bad things will happen to the global routing table. The obvious thing to aggregate on is the ISP used. This is what we do every day. Unfortunately, you don't get provider independence this way. With provider aggragation out the window, it turns out that it doesn't really matter much on what you aggregate. For instance, we can aggregate on the first byte of the IPv4 address. So all destinations that have 192 as the first number in their address are aggregated together, just like 193, 194 and so on. Suppose we have three routers: Router A contains all more specifics for 192/8 and the 193 and 194 aggregates Router B contains all more specifics for 193/8 and the 192 and 194 aggregates Router C contains all more specifics for 194/8 and the 192 and 193 aggregates So all traffic towards any destination within 192/8 will have to flow through router A, and so on. This works very well if router A is close to the destinations in question, but it gets problematic when there aren't any routers covering the aggregate for a certain destination close to that destination. So if destination X with address 192.0.0.1 is in Paris, and router A is also in Paris, this works out great. If router A is in London or Frankfurt, this isn't quite optimal but the scenic routing isn't too bad. But if router A happens to be in Auckland, this is not so great. There are two ways to solve this: 1. Have router A instances everywhere. This basically means multiplying the number of routers by the number of aggregates used. Not so great. 2. Rather than aggregate arbitrarily, do it based on geography so there only need to be a few router A instances.

While it is convenient to think og geographical divisions in terms of boundaries, in real world networks the geographical divisions are defined by peering points which the real world refers to as "major cities". So if we do adopt a geographic addressing scheme it makes no sense at all for the RIRs to allocate these addresses to entities that happen to be inside a specific geographic boundary.

No. You are assuming a single aggregation level. But there can be many: city, state/province, country, continent. If I have traffic for Amazon, all I need to know is that it should make its way across the Atlantic. At the US East Coast, there are probably aggregates for all the US states, and finally in or close to Seattle all more specifics must be present. Should there not be an interconnect with other networks in Seattle, then the more specifics must be present in a wider area. So peering within the target area isn't required, although it makes for better aggregation of course.

However, it makes perfect sense to allocate these geographic addresses to an entity who is peering at one or more of the peering points within a geographic boundary.

Peering can change. Geography can't. (Unless you live in an earthquake-prone region.) The advantage of doing geographic aggregation like this (i.e., the aggregates are only used within ISP networks and not announced to other ISPs) is that everyone can implement the aggregation as desired without global coordination, but the PI benefits start as soon as end-users get the geographically aggregatable address space. So it makes no sense to adopt unaggregatable PI space, geographically aggregatable provider independent (GAPI) address space is always better.

On Sat, Nov 27, 2004 at 02:42:55PM +0100, Måns Nilsson wrote:

...

The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space.

Do note that, IIRC, RIPE had this up for discussion some time ago and opted in-session for an "one AS -- one global prefix" solution which was then overridden because APNIC and ARIN weren't as impressed by that solution.

Don't blame Europe ;-)

This is interesting, didn't know about that. Can you provide any reference (WG minutes, mailing list archive URL or so)? That'd be a good starting point to re-visit this. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

I don't think this statement is true on its face. Regardless, if it is true the end users have no one to blame but themselves.

Agreed... Although I think ARIN could do better outreach to the broader community. I think there are perceptions out there that differ from reality, and, blaming people for their perceptions is never effective at bringing them into the process. What is needed is outreach and education.

The policy process (at least for the past several years) has been an open, public process. You don't have to be a member to show up and make policy. The big ISP's do not dominate the discussions.

This is absolutely true. I can vouch for it from the meetings I have attended in the last two years, and, I will say that I have watched ARIN become progressively LESS ISP centric.

So, I don't know where your statement comes from. When end sites can get a /22 directly from ARIN so they can multi-home, I wonder how we are locking end-sites into their providers address space. Since you can get a /22 with a 50% justification you only have to show a need for 512 IP's to be provider independent. I would love to know how that is an unreasonable barrier.

Perhaps it is because they can't get any v6 allocation from ARIN unless they claim they want to go into the LIR business and not be an end site and propose a plan to assign addresses to 200 additional organizations.

So, it seems like in IPv4 land we're making it quite easy for end-sites to get PI space. It also seems like, even with end sites getting PI space, and everyone announcing cutouts of provider blocks we don't have a global routing table that's too large. We're at ~140,000 routes now, and that's with the mess of the swamp and other poor past decisions floating around.

I will point out, however, that if the boundary moves to /24, there's not much difference between the allocation policy of the past that created the swamp and current allocation policy. I'm not saying I think this is a bad thing (I don't). I think that CIDR was important in its day, and, I think it is important today. However, I think that now, CIDR is only important in so far as it promotes aggregation where it makes sense. Deaggregating where it matters is a valid and necessary thing.

# 3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it.

They have ahold of it now. Owen -- If it wasn't crypto-signed, it probably didn't come from me.

On Mon, 29 Nov 2004, Leo Bicknell wrote:

#1 Set aside a block for "local" use a-la RFC1918. This set aside should make no recommendations about how the space is subdivided for used for these local purposes.

FWIW, site-locals were dropped (among others) due to concerns about sufficient guarantee of uniqueness. ULA started by having only a local generation mechanism, no central allocation at all. Would that allay your concerns?

#3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it.

I think we all know there's going to be _some_ form of PI space. Whether that's realized by making the policies weaker, by end-sites lying in their address applications, or end-sites providing interesting interpretation for "other organizations", or a number of different mechanisms, the fact is that some form of PI addressing is going to be there. The question just is, what kind, how much of it, and to whom it's available.

#4 Drop the absolutely stupid notion that "one size fits all". A /32 for everyone makes no sense. VLSM was a good idea.

Below.

#5 Stay out of the allocation details. The RIR's have been allocating addresses for years. The RIR's have people, from small to large ISP's and everything inbetween solving real world allocation problems every day. The history tells us is the policy will change over time. History also tells us being too liberal early on can never be "fixed". The RIR's will change policy as time goes on to fit the changing IPv6 world. Let them deal with the policy on a going forward basis.

The history also tells us that being too stingy when there is no need to be stingy will result in useless fragmentation of the addressing, and therefore results in the fragmentation of routing advertisements. A minimum of /32 per ISP IMHO makes very much sense, because that's so small amount that we aren't going to run out. On the other hand, I agree that one size does not fit all, and larger blocks will also need to be provided. Oops, they already have! -- 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:

...

On Mon, 29 Nov 2004, Leo Bicknell wrote:

...

# 1 Set aside a block for "local" use a-la RFC1918. This set aside should make no recommendations about how the space is subdivided for used for these local purposes.

FWIW, site-locals were dropped (among others) due to concerns about sufficient guarantee of uniqueness. ULA started by having only a local generation mechanism, no central allocation at all. Would that allay your concerns?

No. In that case, it makes things even worse because it creates the promise and illusion of uniqueness without actually delivering uniqueness. Worst of both worlds... Bigger address-waste (not that it really matters), non-uniqueness, and the expectation of uniqueness. To some small extent, this might (_MIGHT_) reduce the pressure on ISPs to route these prefixes, but, that is the only improvement over a central registry.

OK, I understand with this sentiment. It's easier for the ISPs to fend off ("there's no uniqueness, we can't route this stuff!").

...

...

# 3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it.

I think we all know there's going to be _some_ form of PI space. Whether that's realized by making the policies weaker, by end-sites lying in their address applications, or end-sites providing interesting interpretation for "other organizations", or a number of different mechanisms, the fact is that some form of PI addressing is going to be there. The question just is, what kind, how much of it, and to whom it's available.

Ideally, I'd like to see us address this up front in a clear and open manner instead of using nudge-nudge and wink-wink encouragement to make creative applications for space. The former can be done fairly. The latter insures that the only organizations that have any sort of advantage are the ones willing to lie to get it. This tends to happen by accident often enough. Creating the situation deliberately is, IMHO, absurd.

Sure, I invite discussion on this in the open. The best place would probably be the global-v6 list at: http://www.apnic.net/mailing-lists/global-v6/

...

...

# 5 Stay out of the allocation details. The RIR's have been allocating addresses for years. The RIR's have people, from small to large ISP's and everything inbetween solving real world allocation problems every day. The history tells us is the policy will change over time. History also tells us being too liberal early on can never be "fixed". The RIR's will change policy as time goes on to fit the changing IPv6 world. Let them deal with the policy on a going forward basis.

The history also tells us that being too stingy when there is no need to be stingy will result in useless fragmentation of the addressing, and therefore results in the fragmentation of routing advertisements.

Actually, that fragmentation was primarily the result of being insufficiently stingy early on.

There are many kinds of fragmentation. When you only get (e.g.,) a v4 /24 for a start, and when you need more, you'll have to get a new non-adjacent /24, there's going to be fragmentation. For v6, you can just look at below to see what is the result of unnecessary stinginess causing fragmentation of allocations (though luckily not advertisements): http://www.iana.org/assignments/ipv6-tla-assignments We _don't_ want to get to a point where each IPv6 ISP or end-site will have to have dozens of IPv6 prefixes, just because they outgrew the previous ones. There are enough bits to play around. It's not as we are carving out v4 /8's (1/256 of space) for early adopters. Or even /16's. More like the equivalent space of a host address. That's hardly too much. In fact, it's way too little for those ISPs which have home customers like DSL, and it's going to be a a pain because they either must get a new prefix or give their customers a /64 instead of /48. -- 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 Tue, 30 Nov 2004, Owen DeLong wrote:

[snip a bunch of stuff where we finally appear to basically agree or at least understand each other]

...

...

Actually, that fragmentation was primarily the result of being insufficiently stingy early on.

There are many kinds of fragmentation. When you only get (e.g.,) a v4 /24 for a start, and when you need more, you'll have to get a new non-adjacent /24, there's going to be fragmentation.

I don't think you can equate v4 /24 allocation to v6 /48 allocation. A /48 gives an organization 65,536 unique subnets, each of which can accomodate enough hosts that _EVERY_ IPv4 possible host can have 4+billion addresses.

I was not referring to /48's -- that's sufficient for end-sites. I was referring to giving less than /32 or the like for ISPs, and _that_ causing fragmentation of advertisements because the _ISPs_ would have multiple prefixes. There is no need to be unusually stingy about the prefix lengths given to the ISPs.

...

It's not as we are carving out v4 /8's (1/256 of space) for early adopters. Or even /16's. More like the equivalent space of a host address. That's hardly too much. In fact, it's way too little for those ISPs which have home customers like DSL, and it's going to be a a pain because they either must get a new prefix or give their customers a /64 instead of /48.

I think that if an ISP can show that they have more than 65536 home DSL customers, they will not have a problem getting a /31 or larger as needed. However, I think that today, the bulk of DSL ISPs doe not have that many customers and aren't likely to in the near future.

Uhh, I'd say there are a thousand or two such ISPs in the world. That's not insignificant. It isn't useful to be stingy when allocating prefixes to ISPs which _might_ end up needing more than a /32 for their customer /48 assignments. And if such ISPs decide that rather than going through the process of justifying more space, they end up giving the customers /64's instead.. well, the result might not be pretty. -- 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 Wed, Dec 01, 2004 at 08:41:37AM +0200, Pekka Savola wrote:

Uhh, I'd say there are a thousand or two such ISPs in the world. That's not insignificant. It isn't useful to be stingy when allocating prefixes to ISPs which _might_ end up needing more than a /32 for their customer /48 assignments.

And if such ISPs decide that rather than going through the process of justifying more space, they end up giving the customers /64's instead.. well, the result might not be pretty.

I think the risk of ISPs handing out /64s is very small. Actually I expect most of the consumer ISPs (and they are the ones with the large number of customers) to hand out /128s. If they started giving networks (and not just single Addresses) to their customers their complete set of "business products" would no longer exist. I doubt the techies are strong enough to fight this through against product management. Nils

On Wed, 2004-12-01 at 21:30 +0100, JP Velders wrote:

...

[ ... ] I think the risk of ISPs handing out /64s is very small. Actually I expect most of the consumer ISPs (and they are the ones with the large number of customers) to hand out /128s.

Uhm, one of my private (as in I'm the consumer) ISP's over here in Holland gives me a /48... Granted it's done through a tunnelserver and labeled experimental, but they handed out /60's when it was based on sixbone space... http://www.xs4all.nl/uk/allediensten/experimenteel/ipv6.php

I do believe XS4All is one of the larger consumer ISP's over here.

XS4ALL is around 160k DSL lines last time I heard. Due note that they are a clued ISP unlike many others. The tunnelserver is only for people not using the PPP sessions. Folks with DSL and PPP can also get 'native' IPv6 by doing a PPP6 session next to the normal PPP session. Afaik most of the usage of the IPv6 there has moved away from 6bone and migrated to their RIR prefix already, though users can pick between them. Erik, comments and more details? :) Greets, Jeroen

--On Wednesday, November 24, 2004 12:52 -0800 Crist Clark <crist.clark@globalstar.com> wrote:

Owen DeLong wrote:

...

...

I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them.

Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result.

Do customers demand that their ISPs route RFC1918 addresses now? (And that's an honest question. I am not being sarcastic.) Wouldn't the IPv6 ULA answer be the same as the IPv4 RFC1918 answer, "I could announce those networks for you, but no one else would accept the routes. (And I would be ridiculed straight off of NANOG.)" I presume everyone will be filtering the ULA prefix(es), link local, loopback, and other obvious bogons from their tables. How does this enterprise demand that other providers route the ULA prefixes too?

Yes, they do. However, today, with RFC-1918, we can at least give them a good technology reason why not. With ULA, we have no such defense... There's simply no reason a unique prefix can't be routed.

If we're talking about routing ULAs within a providers network, I'd think providers would love them. Right now, an enterprise can buy a "corporate VPN" or layer two network to route "private" addresses. Wouldn't providers be happy to offer the same service, for the same extra $$$, in IPv6? Especially when you consider that you can just drop the routes for the ULAs in your interior routing tables since ULAs are well, unique, and you're done. No tunnelling or other levels of indirection required. Charge the same or more for the "business-level service" that you offer now, but there is less work for you to do it.

Right, but, the problem comes when the customers expect you to also announce the ULAs at your borders. Believe me, this will occur. It will probably start with "Well, we've got this connection to you and this connection to ISP B, and, you guys peer, so, can you pass our ULA prefixes along to each other?" The slippery slope will continue until market economics have blurred or completely erased the line between PI and ULA. Owen

...

Believe me, this will occur. It will probably start with "Well, we've got this connection to you and this connection to ISP B, and, you guys peer, so, can you pass our ULA prefixes along to each other?"

Talk to the other ISP, work out pricing, and sell an IP over IP solution, MPLS solution or some such. Look at this as an opportunity, instead of a

problem, and there's money to be made without leaking the prefixes into the backbone. Embrace progress and conceive of creative solutions to customer needs.

In today's network, is there anyone left who uses 1500 byte MTUs in their core? Surely even the people with Ethernet switches in their PoPs are now using jumbo frames. In yesterday's Internet, encapsulation was a problem because of the fragmentation required, but it should be a routine thing in today's Internet where fragmentation is avoided. If ULAs, i.e. site local addresses, need to be visible at two disjoint locations in the network, we have the technical means to do this without using up global routing table slots. The same thing applies to geographical addresses which may sometimes need to be made visible in another region. We *CAN* do things at the edges of the network without burdening the core. --Michael Dillon

On Thu, Nov 25, 2004 at 02:05:25PM +0000, Alex Bligh wrote:

Given how pMTUd works, this speculation should be relatively easy to test (take end point on >1500 byte MTU, run traceroute with appropriate MTU to various points and see where fragmentation required comes back). Of course I'd have tried this myself before posting, except, urm, I can't find a single machine I have root on that I can get more than a hop or two from without running into 1500 byte (or less) MTU.

I happen to have such a machine and an application that specifically tests hop-by-hop MTUs, if there are any specific destinations you'd like checked. It has 9k to the R&E world, and 4470 to Qwest. Bill.

IANAL, but, I'm suspecting that the restraint of trade specter would be raised by the router vendors if you start incorporating demands that they not implement features their customers (these same tier 1s) would be asking for. Of course, the IETF doesn't have any real power to prevent router vendors from implementing features like this or require them to prevent such things. RFCs in the end, are already treated as general suggestions by many vendors rather than any sort of forceful rule. So, yes, you seem to somewhat understand our fear, but, you also seem to, IMHO, overestimate the potential success of any theoretical solution to the problem. As I see it, the only effective way to prevent the issue is to change the general allocation policy to meet all needs and recognize that globally unique space is globally unique space from a technology perspective. From a social engineering perspective, any such distinctions are purely artificial, and, will be recognized as such and removed by market economics. (Or, to put it in terms IETF may better understand: In the long run, such limitations will be viewed as damage and simply routed around.) Owen --On Thursday, November 25, 2004 6:39 PM -0600 Stephen Sprunk <stephen@sprunk.org> wrote:

Thus spake "Daniel Senie" <dts@senie.com>

...

At 07:11 PM 11/24/2004, Owen DeLong wrote:

...

Yes, they do. However, today, with RFC-1918, we can at least give them a good technology reason why not. With ULA, we have no such defense... There's simply no reason a unique prefix can't be routed.

So with unique address blocks, blocks that should not appear in the GLOBAL routing table, companies could use those prefixes for private peering all over the place. This sounds like a great idea for companies cooperating in commerce operations. Of course all that private traffic might traverse a network that bypasses the ISPs and NSPs, or perhaps runs over private virtual circuits (MPLS, Frame, ATM or whatever the popular choice is for such circuits that month).

While from a network operator's perspective, this might be a disaster, it's an enabler for corporate networks, and there's no reason to discourage it.

I don't see much argument against the idea of ULAs iff they actually remained local.

...

If you are a network provider, then filter the entire prefix block and any longer prefixes announced. Please, though, stay out of the way of private interconnectors who've been asking for years to have unique space so they can reliably talk with one another.

If I understand the fear of Owen, Leo, and others, presumably if a couple tier 1s decided (intentionally or not) to route ULAs, then other ISPs would be forced by market conditions (i.e their customers) to route them as well... For instance, what would happen if Google were only reachable by ULAs?

I think the WG would welcome any input that would help prevent this from happening. One thought would be to require router vendors to make it so each ULA prefix to be allowed over BGP must be configured individually instead of a single flag to allow all of them.

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.

At 07:32 PM 11/24/2004, Valdis.Kletnieks@vt.edu wrote:

On Wed, 24 Nov 2004 12:52:21 PST, Crist Clark said:

...

Do customers demand that their ISPs route RFC1918 addresses now? (And that's an honest question. I am not being sarcastic.) Wouldn't the IPv6

No, they just emit the traffic anyhow. Often it travels an amazing distance before hitting a router that doesn't have a default route - and if it's one of those providers that internally routes 1918 addresses of their own it might go even further ;)

Seems to me we wrote a document some years ago about how to address this. If the upstream ISP isn't willing to filter at their edges, then write contract language that the client is required to filter such traffic in THEIR border routers. The typical customer with a few T-1 lines and some small routers could easily afford the CPU power in their routers to implement a few lines of ACL filtering. This sure seems like a weak reason to scuttle an otherwise useful and desired capability.

At 04:46 PM 11/25/2004, Valdis.Kletnieks@vt.edu wrote:

On Wed, 24 Nov 2004 22:09:02 EST, Daniel Senie said:

...

Seems to me we wrote a document some years ago about how to address this. If the upstream ISP isn't willing to filter at their edges, then write contract language that the client is required to filter such traffic in THEIR border routers. The typical customer with a few T-1 lines and some small routers could easily afford the CPU power in their routers to implement a few lines of ACL filtering.

This sure seems like a weak reason to scuttle an otherwise useful and desired capability.

Exactly. And how many places *still* botch it in the IPv4 world?

And there's no reason I've seen that we should expect *any* different in the IPv6 world....

We may not. However, without ULA, I question whether people will bother adopting IPv6 at all. If that's what the community desires, then so be it. However, I expect market forces will drive the requirement for ULA. If it's missing, I expect a repeat of another happening with IPv4, that being people picking random address blocks to use. As for the ingress filtering issue, education and contract terms are two good answers. I'd like to see network operators considering ingress as part of their aggregation router buying decisions, of course.

On 19-nov-04, at 19:23, Owen DeLong wrote:

...

There is no reason for RIRs to allocate addresses which would never be used on public networks.

If the addresses are suppose to be unique, then, what is the reason NOT to have the RIRs allocate them?

The reason is that the RIRs don't talk to end-users. (At least, they don't talk to 99.99% of all end-users.) Having to go through a LIR (ISP) to obtain addresses that may remain in use after a customer leaves also seems strange.

Why set up a separate registry system for these addresses instead of making minor changes to the existing one to accommodate this need?

This is a good point. But rather than reuse the RIRs for this, we should reuse the domain registry system for this. Domain sellers already know how to deal with millions of customers (collectively) and make a business based on very small yearly fees, they already deal with the majority of the prospective users of this address space and there is healthy competition.

Thus spake "Paul Vixie" <paul@vix.com>

...

if arin's allocation policy for ipv6 does not take account of multihomed non-allocating enterprises then either that policy will change, or the internet exchange point business model will be dead.

* stephen@sprunk.org (Stephen Sprunk) [Fri 19 Nov 2004, 05:44 CET]:

I don't understand why exchanges would suffer; the real threat is that enterprises simply won't use IPv6 until IPv4 space is completely exhausted -- and perhaps even after it is.

Making it hard to multihome by not providing assignments to companies that used to be able to get such will decrease the usefulness of exchange points for those. Of course, nothing stops them from announcing their /48's PA assignments but the risk of those getting filtered by "real" ISPs is very real. It seems the lack of PI increases the amount of "have-nots" in an IPv6 world compared to IPv4. -- Niels.

On 11/19/04 6:33 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:

On 19-nov-04, at 5:38, Stephen Sprunk wrote:

...

According to multi6, you will get PA space from each of your ISPs and overlay a prefix from each on every subnet. I'll save y'all another rant on the workability of that model...

...

Some fear that you would more likely just generate a ULA, use that internally, and NAT at the borders.

It isn't contrary to multi6 gospel to have the address swapping be done by boxes somewhere in the middle rather than have all hosts do it for themselves.

While that may or may not be gospel, why would the enterprise care to switch to IPv6 in the first place? The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113

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

On 19-nov-04, at 5:38, Stephen Sprunk wrote:

...

According to multi6, you will get PA space from each of your ISPs and overlay a prefix from each on every subnet. I'll save y'all another rant on the workability of that model...

...

Some fear that you would more likely just generate a ULA, use that internally, and NAT at the borders.

It isn't contrary to multi6 gospel to have the address swapping be done by boxes somewhere in the middle rather than have all hosts do it for themselves.

Isn't "address swapping ... by boxes somewhere in the middle" called NAT?

Note that at this time the main focus of the IETF multi6 working group is taking regular communication (such as a TCP session between PA addresses at both ends) and then repair outages using additional PA addresses.

That's interesting, but how long until we see it in Windows (the most ubiquitous host OS on the planet)? It took nearly ten years for MS to implement IPv6 as it is; will it take another decade for multi6 to have a solution that works and is _deployed_?

Another way to do this is to use non-routable addresses (such as unique site locals) as the addresses that transport protocols such as TCP and applications see, and start remapping those to/from PA addresses from the start. However, this isn't backward compatible and it's more complex so we're not focussing on this approach at this time. I'm pretty confident that we can add this as an additional option later, though.

I'm confident you could add it, but I'm not confident that (a) it'll end up implemented by vendors or (b) it won't have the same disadvantages of NAT. 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

Stephen Sprunk wrote:

According to multi6, you will get PA space from each of your ISPs and overlay a prefix from each on every subnet. I'll save y'all another rant on the workability of that model...

FWIW, I have submitted an I-D for a method that does not require overlay prefixes, extra routing table entries or globally unique AS's: http://www.ietf.org/internet-drafts/draft-loch-multi6-alternate-path-encodin... Note: bit order notation is apparently reversed from I-D standards and will be fixed in the -02 version. Any comments or suggestions would be appreciated (off-list). -- Kevin Loch

Paul Vixie wrote:

either of these limitations...

o A maximum of two alternate networks (for a total of three networks) can be encoded on a single unicast address. o Renumbering when changing networks is not eliminated and is actually made worse because changing any of the networks requires renumbering. Worse yet, even changing the routing preference between the the networks requires renumbering.

...is fatal to this approach.

Fatal in that it does not address the needs of "major" multihomers like ISC. Certainly not fatal to the millions of small to mid sized networks that could benefit from multihoming to two or three providers. For those networks this method would be at least as good and easy as it is today with IPv4, plus the benefits of not polluting the global routing table, consuming unique AS numbers or requiring convoluted application or protocol tricks. In fact anyone could do simple multihoming. Just get a second connection and set your interface addresses accdordingly. Networks that need to multihome to more than three networks would likely qualify for IPv6 PI space anyway (as ISC did and still does). There is a range of large purely end site networks that would not qualify for PI space and would need more multihoming support than this method provides. In those cases it would be necessary to use more advanced (read: complicated) technology. As we have seen, the advanced methods come with their share of limitations too. I don't think we are going to find a "one size fits all" solution to IPv6 multihoming. As for renumbering, we all know that will be solved by some form of address translation (like it or not). -- Kevin Loch

Thus spake "Paul Vixie" <vixie@vix.com>

stephen@sprunk.org ("Stephen Sprunk") writes:

...

...

isc is multihomed, so it's difficult to imagine what isp we could have taken address space from then, or now. ... Some fear that you would more likely just generate a ULA, use that internally, and NAT at the borders. Or maybe you'd stick with IPv4 RFC1918 space internally and NAT to IPv6 PA space at your borders.

the internet endpoint type trend is toward SOHO and dsl/cable, and the provider trend is toward gigantic multinational. companies who build their own networks tend to find that the cheapest interoffice backhaul is IP-in-IP VPN's. thus is the old model of a 1000-person company buying a T1 transit connection moving toward the margins.

I'm not experienced with the 1000-person companies; the work I've done is for companies 20 to 100 times that size, so maybe my perception is skewed. SoHo and residential users are definitely a growing percentage of the Internet connection count, but I think they're still a minority of _hosts_ which have Internet connectivity. Enterprises can have tens or hundreds of thousands of hosts behind a single T1 or T3, and may expose only a handful of PA addresses due to NAT. Large universities are similar, except legacy allocations mean they usually don't need NAT. I've also seen a strong tendency in enterprises to backhaul even external traffic on IP VPNs, so that even users with a "local" Internet pipe have to go through the corporate firewalls to reach the outside world (if that's even allowed).

as i continue to research my own premises, i find that the style of internetworking practiced at isc, which precludes PA space due to multihoming and due to possible renumbering penalties,

So are you saying that if ISC had not gotten a legacy PI allocation, you wouldn't be using IPv6? Or that you wouldn't be able to design your network the way you'd want to, but would still use IPv6 anyways?

is becoming quite rare as a percentage of the total number of network owners and the total number of endpoints thus interconnected. it's sad but it's true and it gives cause to ponder the future of enabling technologies like internet exchange points.

I've run into very few enterprises that know they'd even be allowed to join an IX, much less actually interested in doing so. They'd rather pay one or two companies to drop big, fat pipes into their datacenter and collect on SLAs when something goes wrong. Very few, even in the Fortune 100, have the staff to handle their own BGP configs and keep things running smoothly. Humans cost more money than they'd probably save on transit, and the money often comes out of different pockets anyways. I see IXes (IXen?) as a solution for providers, not end-sites. With the relatively lax IPv6 PI policies for providers, the threat to IXes is minimal.

this may yet lead to a mechanism for qualifying multihomed network builders to get PI space, since they'll be rare enough to have a low impact on the global routing table.

We'll see what the reaction is on PPML. Based on the number of origin-only ASes in yesterday's Routing Table Report, we should expect to see about 16k prefixes from multihomed end-sites if adoption in IPv6 matches that in IPv4.

on the other hand, transit-provider lock-in is not officially recognized as having any bearing on any RIR policy in any region; if that continues to be the case, the rare kind of network i'm most familiar with will continue to use ipv4 or will only use ipv6 via something like ULA's. what this may mean is that approving ULA's will make the situation better, since network owners will otherwise just pirate unused space at random. with ULA's we'll at least have a chance to trace leaks and try to make BCP38 happen in more places.

Agreed. 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 08:45:34PM +0000, Paul Vixie wrote:

the second. we'd have built a v6 bastion network and put our public services there and done some kind of overlay thing. for things like my desktop, we'd've stuck with ipv4, or we'd've pirated some "site local" ipv6 space. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. no, no, no, and again i say, "no, that will not be done on my watch."

Perhaps it is time to replace TCP with SCTP, where multihoming is not incompatible with PA addressing. If done as a socket shim, so applications don't have to be aware of it unless they want to be, it would appear to solve all of these problems. How much would it add to the pain of the v4-v6 transition, to just bite the bullet and do tcp-sctp at the same time? I'd sure rather be a network troubleshooter going through that than living with NAT forever. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.

It seems easier to try to back-port SCTP's multihoming features to TCP somehow than to deploy an entirely new transport protocol. It's unfortunate this wasn't addressed at the time IPng was being designed.

this was tried. there was almost going to be a "TCP6" which was capable of signalling an endpoint-renumber event using in-band control messages. alas, this approach was deemed overly complex, so TCP went unchanged. -- Paul Vixie

...

... all oldtimers are skewed. ...

Here is a possible multi level solution for end sites and non /32 qualifiers: ... - Sites that multihome 4 ways or more get a PI /40 - Large sites with more than X devices get a PI /40 if at least (dual|triple)homed to avoid massive renumbering/provider lock-in.

This would set the bar high enough to limit routing table growth while allocating PI space to those who need it the most.

there are problems with this approach, having to do with the definition of multihoming, and with the possibility of someone claiming to qualify for PI space even though their "providers" are actually "related parties". there is room for huge graft and corruption unless the definition is very careful and there's a budget for both initial and recurring audits. then there's the problem of falling out of qualification some time after a large network has been built. so while i don't disagree that multihoming appears to be a justification for PI space, i'm not sure all the wrinkles can be ironed out. more importantly though is your /40 example. ipv6 has enough address space in it to be able to give a /32 to every household on the planet, including a reserve for the ones without electric power or phones. giving out /40's makes no sense. what the world is short of is routing table slots, each of which adds universal cost to the internet for the sole benefit of the owner of the network thus made reachable. there's ram, cpu, churn... the works. when or if an endsystem PI policy is defined, it should not call for shorter prefixes, but rather, for making it really quite rare in a global sense for anyone to actually qualify for it. if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. -- Paul Vixie

if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. --

Paul Vixie "Nut-uh!" *WHEN* the ipv6 routing table gets as large as the ipv4 routing table is today (late 2004, when you quote me later) it won't be a problem. As a matter of fact, I would bet that Cisco , Juniper, and any other edge/core router manufacturer are banking on this happening. Today's routing table can be carried on older edge routers very effectively (There are many 7500, 7200 series routers out there), and I predict that this will continue to be the case for quite some time (at least a few more years) This is not conducive to the business model of Cisco Systems. *WHEN* the IPv6 routing table is the same size that it is today, I seriously doubt that there will be any problem with finding a CPU fast enough, RAM with a memory rate high enough, or CPU to memory bandwidth wide enough to handle it. And when that time comes: I promise that any Cisco sales person will have at least more than a handful of routers to sell you that'll handle the load just fine. I'm Jerry Pasker, and I approved this message.

Somebody said:

...

...

if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo.

*WHEN* the ipv6 routing table gets as large as the ipv4 routing table is today (late 2004, when you quote me later) it won't be a problem.

Agreed. When the IPv6 table has as many routes as today's IPv4 table, we'll need four times the storage; Moore's Law says, as long as that doesn't happen within 36 months, it's not a problem. I haven't seen anyone (recently) predict IPv6 adoption will be anywhere near that fast, much less faster. Thus spake "Paul Vixie" <vixie@vix.com>

but it's not just the routers, it's churn. "it's always noon somewhere." the stability of the distributed system called "the global routing table" is directly proportional to its size. the number of participants in that system, each of whom must build their own model of the system using only the messages they get from direct neighbors, cannot usefully exceed *some* maximum for any given total number of discrete destinations. ... first, the current distance-vector approach used by BGP just won't scale to O(1e12),

Probably not, even if router vendors start using reasonably modern processors.

and second, i don't think that you think that there are enough participants who want to own routers to make such a table size necessary.

As a point of reference, today in IPv4 there are 16k origin-only ASes. Assuming reasonably sane RIR policies, we can expect -- even with the issue of one PI prefix per AS -- that there would be 16k end-site PI routes today, with linear growth similar to the current allocation rate of ASNs. This is not even remotely a problem until well after we have to switch to 32-bit ASNs; in fact, the situation will be far better than what we will likely have with IPv4 at that point.

mr. doran argued for many years that routing table slots should be auctioned or leased. i never did and still do not agree with him, but his starting assumptions weren't and aren't my point of disagreement.

The idea has obvious appeal, but it seems like a clear case of the cure being worse than the illness once you consider the logistical and technical requirements. 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 21 Nov 2004, Paul Vixie wrote:

if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo.

s/if/when/ There some hope though that by that time routers will have slightly more memory and slightly better CPUs ... But I do think its clear that with IPv6 a solution needs to be found for the average joe-business-user who wants to have benefits of connectivity with several providers without necessity of doing BGP. IETF Multi6 seems to be the best effort we have in this area and its quite clear now from both that and from HIP and MIP that new "host" layer will have to be added to TCP/IP between IP and TCP and then connection will not be between one ip and another but between one host and another and simplified routing protocol will decide which of the ips (and each host may have multiple ones) are actually used for source and destination of data packets. -- William Leibzon Elan Networks william@elan.net

--On 21 November 2004 11:59 +0200 Petri Helenius <pete@he.iki.fi> wrote:

If we ever make contact to some other civilization out there, do they have to run NAT?

Nah. Jim Fleming tells me they're running IPv8 (ducks) Alex