Re: ULA and RIR cost-recovery
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 signature.asc Description: This is a digitally signed message part
Re: ULA and RIR cost-recovery
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
Re: ULA and RIR cost-recovery
Date: Wed, 1 Dec 2004 09:06:59 -0500 From: Nils Ketelsen [EMAIL PROTECTED] Subject: Re: ULA and RIR cost-recovery [ ... ] 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. [ ... ] Nils Kind regards, JP Velders
Re: ULA and RIR cost-recovery
[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. Local policy can move the subnet boundary beyond the /64 point with some effort. Further, every proposal I have made included the concept that an organization with provider independent space smaller than /32 (longer prefix), could only receive at most 1 additional prefix before they surrender their old prefix, and, then, they would only get to keep the old one for a maximum of 24 months to renumber. I believe this removes the fragmentation concern. 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. No, we don't. That's why I've included language in my proposal to specifically prevent this occurrence. 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. In any case, the ones that do already have specific language allowing them to obtain larger prefixes based on the number of end sites they are assigning /48s to, so, I'm not sure why you see that as an issue. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpreDOhbj35d.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
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. 1. I think you seriously overestimate the number of DSL subscribers. In order for there to be 1,000 such ISPs, by definition, there would need to be at least 65,536,999 DSL customers of those 1,000 ISPs, and they would have to be very evenly divided amongst said providers. 2. Such providers will have no difficulty whatsoever getting a /30 today (which covers them for 256k customers). 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. To paraphrase Randy again: I encourage my competitors to try this. Owen pgp0kHJKrzQBC.pgp Description: PGP signature
RE: ULA and RIR cost-recovery
--On onsdag 24 november 2004 11.40 -0800 Tony Hain [EMAIL PROTECTED] 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 ;-) -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE pgp8Zh7NoCaFG.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
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: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: ULA and RIR cost-recovery
In a message written on Wed, Nov 24, 2004 at 11:40:50AM -0800, Tony Hain 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. 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). 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. 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. You need look no further than than those elected for proof. The ARIN Advisory Council is elected by the membership. The members are at http://www.arin.net/about_us/ab_org_ac.html. If you look close you'll see that of the 15 members only 3 work for large ISP's. If you look closely at recent events, you'll see a number of proposals all for small ISP's or for end users. The members passed 2003-15, a relaxation of the rules in Africa to help small ISP's in Africa. The members passed the six months rule, to insure growing ISP's would always have plenty of addresses on hand. The members passed a policy to allow end users to always get a /24 from their upstream if they are multi-homed. The members moved the minimum allocation size from a /20 to a /22 for multi-homed sites. Did we experience some growing pains in the past? Sure. There were technological and political issues in the past that caused some people some pain. However, the process that came out of all of that is fair and open. Almost all the IP Allocation issues in the past 2-3 years have been issues that the small guy faces, and have generally been passed to help them grow. 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. Note, there is also talk of ARIN extending this boundary to a /24. This will be tackled in upcoming meetings. The membership decided we would go to a /22, collect data, and evaluate the impact of moving to a /24. While we only have 6 months of data so far, the current trend does not indicate a land rush, which makes it much more likely the boundary will go to a /24 within the next 12-18 months. 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. To bring us full circle back to IPv6, if we don't do stupid things like create a swamp (which in my mind includes ULA), the table should not be any bigger (by number of routes) than with IPv4, and in fact should be smaller. Many companies today have several IPv4 prefixes in the swamp, non-aggregateable, and all of the proposed IPv6 schemes would prevent that from ever happening. I firmly expect the IPv6 table would be around half the size of the IPv4 table were similar allocation rules to be applied. That's something we can manage, and it gives all the end sites a shot at PI space as well. If we cut the table size in half, even with addresses that are 4x the size, we only double memory requirements. Given where routers are going with memory that doesn't seem like a big issue in the timeframe that we are talking about. There was a time when people were running AGS+'s that needed to filter routes to get them to stay up. There was a time when people ran 7513's with 128M of RAM and they were falling over due to too many routes. There are important lessons to learn from those experiences. Operators and vendors took away a lot of knowledge from those incidents, and started to produce boxes that didn't have those limits. While we need to learn from those mistakes and not repeat them they do not lead to such draconian moves such as NO PI SPACE!, such as those in the IPv6 working group want to push. So, in summary, you state end sites have no alternative but to use their upstreams addresses. Nothing could be further from the truth with IPv4, with the RIR's currently bending over backwards to make it easier for small sites to be provider independent. At the same time you want to push an IPv6 proposal that specifically excludes all PI space. Hipocracy at its best. The IPv6 working
Re: ULA and RIR cost-recovery
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. pgpDS56xVphOD.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
In a message written on Mon, Nov 29, 2004 at 09:09:08AM -0800, Owen DeLong wrote: 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. I think Owen is well aware of the differences, but for the list's archive... I think a major difference is that the current policy requires you to be multihomed. Another difference is that you have to pay a maintenance fee. There are a lot of blocks in the swamp where end sites received space because they could, and the lack of fees was a motivator. There are also a lot of blocks given out to entities that were then, and are now single homed. It's also the case that the industry as a whole has progressed. With ISP's having good processes to give the customers the space they need, and with technologies like DHCP and the like it is much easier for many end users to live with IP's from their upstream, even if they change once in a while. Couple that with a (very small) amount of paperwork and fees and you do cut out many of the frivolous uses. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpEox03tePp9.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: ULA and RIR cost-recovery
--On Monday, November 29, 2004 21:35 +0200 Pekka Savola [EMAIL PROTECTED] 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. # 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. # 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. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgp0TDYA197uE.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: ULA and RIR cost-recovery
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... 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. 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. 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. This doesn't mean that everybody at the peering point gets geographic addresses but it does mean that organizations who have hierarchical networks with geographically delineated subdivisions can get geographically aggregatable space. For example, let's assume that one of the geographical divisions is the Romance countries. Outside of these countries the geographical address space for this region would consume exactly one routing table slot, no more. Everyone would route the traffic to the nearest network (using non-geographical addresses) which peers at one of the peering points in Paris, Madrid, Lisbon, Milan, Toulouse, etc. The global routing table would be smaller because networks which do not need detailed global visibility will not be using normal PI addresses. Geographic addressing will only work if non-geographic addressing also exists and if the geographic divisions are neither to small nor too large. RIR boundaries are too large. Most national boundaries are too small. With IPv6, routing table size grows 4 times due to the 128 bit addresses. With IPv6 routing table size shrinks because most ASes only need one /32 route. With IPv6 routing table size explodes because most businesses want to multihome. With IPv6 and geographical addressing, routing table size shrinks because most multihomed businesses only need global visibility of their routes within a larger geographical aggregate. --Michael Dillon
Re: ULA and RIR cost-recovery
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
Re: geography to get PI in v6 (was: ULA and RIR cost-recovery)
On 25-nov-04, at 13:46, [EMAIL PROTECTED] 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.
MTU (was Re: ULA and RIR cost-recovery)
--On 25 November 2004 13:16 + [EMAIL PROTECTED] wrote: In today's network, is there anyone left who uses 1500 byte MTUs in their core? I expect there are quite a few networks who will give you workable end-to-end MTU's 1500 bytes, either because of the above or because of peering links. 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 am guessing also that a recent netflow sample from a commercial core (not Internet2), even with jumbo frames enabled, will show 0.01% of packets will not fit in 1500 byte MTU. Anyone have data? Alex
Re: MTU (was Re: ULA and RIR cost-recovery)
On Thu, Nov 25, 2004 at 02:05:25PM +, 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 RE world, and 4470 to Qwest. Bill.
Re: ULA and RIR cost-recovery
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 pgpE4odzFkNDA.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
At 04:46 PM 11/25/2004, [EMAIL PROTECTED] 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.
Re: ULA and RIR cost-recovery
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 [EMAIL PROTECTED] wrote: Thus spake Daniel Senie [EMAIL PROTECTED] 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 SprunkStupid 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. pgpPws21g6SH5.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
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. Market forces aren't driving a desire for ULA. They are driving a desire for cost effective globally unique addresses. A good part of the market does not care about routability or not of those addresses. A meaningful part of the market does. ULA will meet the needs of the former, but, not the latter. Globally unique address assignments to end users with a rational policy (the v6 equivalent of 2002-3 at say the /48 or /56 level) would meet the needs being addressed by ULA and needs not being met by the ULA proposal. 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. Contract terms are a negotiation. As soon as dollars are available for the sake of abandoning an entirely artificial limitation on the use of addresses, guess which way that negotiation will go. We'd all love to see that, but, regardless of the capabilities of the router, the reality is that when a customer dangles enough dollars in front of an ISP for advertising their non-routable space that will do no harm by being advertised to the rest of the internet, they're going to do the following: 1. Warn the customer this may not work out so well for them. 2. Do everything they can to get the route accepted. (If you think this will actually be hard, think again) 3. Take the money. As to why 2 won't be hard: Think of it this way... Each provider is going to be faced with such customers fairly quickly. They're not going to come to the techies and ask why not and go gently into that good night. The sales people are going to see $$ for doing this at each and every ISP and they're going to drive negotiations between management at the providers to trade these harmless routes. This decision will not be made by the operational community, but, inflicted on it by management seeing $$ for doing so. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpoasPz5s6W3.pgp Description: PGP signature
RE: ULA and RIR cost-recovery
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
Re: ULA and RIR cost-recovery
In message [EMAIL PROTECTED], Tony Hain writes: 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. 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? --Steve Bellovin, http://www.research.att.com/~smb
RE: ULA and RIR cost-recovery
--On Wednesday, November 24, 2004 11:40 -0800 Tony Hain [EMAIL PROTECTED] 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. 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. Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. 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). This is absolutely not true. RIPE allocates /24s and smaller. I don't know APNICs current MAU. ARIN will allocate /22s and will probably consider smaller allocations either at the next meeting or the one after that. 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. Agreed. I'd like to see a real solution that allows any organization that wants to multihome to get PI space or have us solve the underlying problems so that address portability becomes irrelevant (better, I think, in the long term). As I see it, IP Addresses are currently used for the following purposes: Destination Endpoint Identifier (resolvable by requiring a solid directory service) Source Endpoint Identifier (mostly doesn't matter when this changes) Source Endpoint Authentication (this is bad and we should be using something better that actually identifies the host (or better yet in most cases, user) in a meaningful way) Host authorization (Same issue(s) as previous statement) Portion of Service authorizatoin decisions (again, same issues as previous two) In the early days of the ipng working group, there was hope that v6 would solve these issues. Sadly, after rejecting TUBA because it didn't solve these things, v6 has devolved into a similar failure. Owen pgpKpQUOzhiLz.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
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? 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. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
RE: ULA and RIR cost-recovery
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
RE: ULA and RIR cost-recovery
Owen DeLong wrote: --On Wednesday, November 24, 2004 11:40 -0800 Tony Hain alh- [EMAIL PROTECTED] 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. 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. Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. ULAs are clearly routable over whatever scope people decide to. This was also true of the SiteLocal prefix that ULAs are replacing. The only difference is that ULAs have explicit text to avoid routing ambiguity where SL didn't. I argued against deprecating SL partly on the basis that it had the potential for ambiguity which would be a disincentive for grey-market PI use. I understand and agree with your point about them being a potential problem, but that potential is easily mitigated by providing an economically viable alternative. 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). This is absolutely not true. RIPE allocates /24s and smaller. I don't know APNICs current MAU. ARIN will allocate /22s and will probably consider smaller allocations either at the next meeting or the one after that. None of the organizations that are getting long IPv4 allocations will qualify for an IPv6 prefix. There is an implicit concession that it is too late to close the barn door for IPv4, but for IPv6 it is currently locked tight by those that want to maintain control. 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. Agreed. I'd like to see a real solution that allows any organization that wants to multihome to get PI space or have us solve the underlying problems so that address portability becomes irrelevant (better, I think, in the long term). Multi-homing is only one reason for PI space, and people get so hung up on that one that they forget that the simple ability to change providers without massive effort is just as important. As I see it, IP Addresses are currently used for the following purposes: Destination Endpoint Identifier (resolvable by requiring a solid directory service) Source Endpoint Identifier (mostly doesn't matter when this changes) Source Endpoint Authentication (this is bad and we should be using something better that actually identifies the host (or better yet in most cases, user) in a meaningful way) Host authorization (Same issue(s) as previous statement) Portion of Service authorizatoin decisions (again, same issues as previous two) In the early days of the ipng working group, there was hope that v6 would solve these issues. Sadly, after rejecting
Re: ULA and RIR cost-recovery
--On Wednesday, November 24, 2004 12:52 -0800 Crist Clark [EMAIL PROTECTED] 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 pgp2tXfIpfdBx.pgp Description: PGP signature
RE: ULA and RIR cost-recovery
Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. ULAs are clearly routable over whatever scope people decide to. This was also true of the SiteLocal prefix that ULAs are replacing. The only difference is that ULAs have explicit text to avoid routing ambiguity where SL didn't. I argued against deprecating SL partly on the basis that it had the potential for ambiguity which would be a disincentive for grey-market PI use. I understand and agree with your point about them being a potential problem, but that potential is easily mitigated by providing an economically viable alternative. I was also opposed to deprecating SL on the same basis. However, just because SL was deprecated doesn't make me think ULA is a good idea. If we're going to have PI space, we should have PI space. Dividing it up into multiple classes based on how much you paid to register it doesn't make sense to me. None of the organizations that are getting long IPv4 allocations will qualify for an IPv6 prefix. There is an implicit concession that it is too late to close the barn door for IPv4, but for IPv6 it is currently locked tight by those that want to maintain control. I don't believe that to be true. I think that a reasonable allocation policy for PI space in v6 would move forward in ARIN. I think that the recent adoption of 2002-3 and 2003-15 is evidence that the makeup and participation in ARIN has shifted. I also think that you underestimate the number of people who believe that PI space should be the norm, not the exception, and, that failure of v6 WG to address this in a meaningful way is not a good thing for v6 future. Multi-homing is only one reason for PI space, and people get so hung up on that one that they forget that the simple ability to change providers without massive effort is just as important. Changing providers without massive effort can be accomplished through a number of other methods. Multihoming is the more generic case. Failure is too strong a term, but it is true that work is not complete. The issue is many assumptions have been made at all layers of the system about the alignment of all those characteristics, so just ripping them out doesn't really solve anything more than the routing problem. Even if the multi6 follow-on groups come up with a technical approach that splits the functions, all the rest of the infrastructure will need to adapt and that will take much longer than rolling out IPv6. I do not believe that the v6 protocol will ever actually address those issues. Most of the necessary foundation for addressing them has been removed (A6, DNAME, mandatory autoconf). Agreed on the latter half, that's why I think that IPv6 should have addressed these early on and built those capabilities into the migration process. Adding them as hacks later has most of the disadvantages and reasons that they haven't been added to v4. That is why I chose the term failure. Making a change that intentionally breaks fundamental assumptions will meet much greater deployment resistance than something that intentionally minimized such changes. Call the intentional minimization a failure if you must, but from my perspective the only real failure will be to let the Internet collapse into something less capable of delivering end user services than X.25 was. Here, we probably end up agreeing to disagree. I think that we could have built v6 to break the fundamental assumptions in such a way that the impact of those breaks was minimized. Yes, there would be deployment resistance, but, I don't think significantly more than exists for current v6. Owen pgpdz1Q6Lbuar.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
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 ;) 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? More correctly, the same people who do proper bogon filtering for IPv4 will quite likely do it for IPv6, and the same people who botch it for IPv4 will almost certainly botch it worse for IPv6. Note that this has *quite* different operational semantics than everyone.. 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. One has to wonder if the first attempt to multihome a ULA will be accidental or intentional, or has it already happened? pgpRMPRZNnfCe.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
At 07:32 PM 11/24/2004, [EMAIL PROTECTED] 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.
Re: ULA and RIR cost-recovery
At 07:11 PM 11/24/2004, Owen DeLong wrote: *** PGP SIGNATURE VERIFICATION *** *** Status: Good Signature from Invalid Key *** Alert:Please verify signer's key before trusting signature. *** Signer: Owen DeLong (General Purpose Personal Key) [EMAIL PROTECTED] (0x0FE2AA3D) *** Signed: 11/24/2004 7:12:03 PM *** Verified: 11/24/2004 9:57:11 PM *** BEGIN PGP VERIFIED MESSAGE *** --On Wednesday, November 24, 2004 12:52 -0800 Crist Clark [EMAIL PROTECTED] 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. 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. 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 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. Hey, it's your network, you set your policies. 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. The slippery slope will continue until market economics have blurred or completely erased the line between PI and ULA. Well, giving in and letting companies have PI space would be nice, but unique ULA space would be extremely valuable, even to folks who REALLY do not need PI space.
RE: ULA and RIR cost-recovery
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
RE: ULA and RIR cost-recovery
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. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgpV3NS92AH0n.pgp Description: PGP signature
ULA and RIR cost-recovery
I've actually tried to avoid commenting on this thread, but that's obviously not going work... Disclaimer: I am the Chairman of ARIN, but these comments herein are my own musings on this topic and nothing more. At 2:26 PM -0600 11/19/04, Stephen Sprunk wrote: 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. The cost and paperwork associated with current RIR activities is the consequences of the particular guidelines (think RFC2050) that the community adopted for IPv4 address space. This model includes such parameters as previous assignment history, network deployment plans, expected utilization rate, Internet connectivity, etc. As it turns out, collecting and validating that information takes real people and often a bit of paperwork. (In the case of ARIN, the remainder of costs cover the travel and meetings which are necessary for the open and public policy formation process, and support for ICANN, emerging registries, and the RFC editor function curious folks can find both the budget and detailed auditor's reports online at www.arin.net) The IPv4 guidelines are the root cause here, and it's only going to get more interesting as things get tighter and we begin to look at issues such as address reclamation... 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. The particular merits of ULA's aside, there is no reason why the cost to administer such cannot be very low, but does not appear to be zero due to the requirements relating to anti-hoarding which will quite likely require human involvement. Again, in the IPv6 WG there were folks who offerred to operate the ULA registry _for free_, You'll get what you pay for -- I recently attended a US Senate committee hearing which dealt with registries and the domain name system. There was an enormous amount of questioning about the reliability of these infrastructure services, and actually not one question about why wasn't it all free... The quality (integrity, availability, and survivability) of your assignment records and inverse DNS services will reflect the investment made. If you so much as have a single offsite escrow of the assignments made to date, you've added an ongoing cost that needs to be recovered. 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. I'm sorry; ARIN operates today under a cost-recovery basis... What is the basis of your statement that The RIRs do not appear to be (willing to operate it under the initial-cost-only terms in the draft)? 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. /John
