Re: IPv6 will never fly: ARIN continues to kill it
We have more than enough IPv4 addresses for China. no way. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
From: Keith Moore [EMAIL PROTECTED] any relief for the Internet before IPv4 space is exhausted. I am so tired of this when IPv4 space runs out, civilization will fall vibe. I'm almost ready to suggest that we just hand out all the remaining IPv4 address space today, now, just to get it over with - and to show that life will continue, people will adapt. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Noel Chiappa wrote: From: Keith Moore [EMAIL PROTECTED] any relief for the Internet before IPv4 space is exhausted. I am so tired of this when IPv4 space runs out, civilization will fall vibe. I'm almost ready to suggest that we just hand out all the remaining IPv4 address space today, now, just to get it over with - and to show that life will continue, people will adapt. Noel Just in case - IPX will survive. IPX has just as many networks as IPv4 has hosts plus IPX has 64 K as many hosts as IPv4 has. IPX has proved to be a woking protocol, it can route, it exists and every major operating system can use it. IPX over IPv4 is existing as well as IPv4 over IPX. So they can coexist and internetwork. I dont know what happened to ISO? ISODE 8 is still hidden somewhere in the wild internet. It is still working although knowbody nows how to configure. It reminds me of SNA. SNA is plug and play! Just plug in your applications and links and play until it is working. The internet as we have it was never meant to be. Every gouvernement is happy it comes to an end. That is why nowbody wants IPv6. We have more than enough IPv4 addresses for the USA. We have more than enough IPv4 addresses for China. Neither the USA nor China want to share a common internet with the rest of the world. If there was not that silly old telephone! We could still live with telephone and modems if telephone had not moved to IPv4 VoIP. I guess it is internal mostly. So we can NAT the phone and everything else. Lets move Google and CNN to rfc 1918 address space and give the rest to national end-users. Have a nice weekend Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 20-sep-2007, at 21:10, Stephen Sprunk wrote: First of all, litigation isn't the only way to get something done, and second, do don't know that until you try. If you try to revoke someone's /8 or /16, you can bet that they're going to sue you. So? The RIRs and ICANN have deep pockets. But there are other approaches than simply revoking the address space. For instance, setting up a policy that governs who gets to keep legacy space that takes into consideration various types of use and cost of renumbering makes sense. I'm sure some legacy space is used in a way that's fairly reasonable, while other space isn't used at all. Obviously the elephant in the room is the US government that has about 5% of all address space, which seems excessive even for legacy holders. And, for the record, there are over 50,000 of them, not less than 50. Clarification: 31,386 in ARIN's region. I haven't seen stats for the other RIRs. 5 organizations holding nearly 0.5% of the IPv4 space each? I'm impressed! With that kind of address compression technology we don't need IPv6 after all. I'm sure you're aware that different size assignments were made to different organizations. I was specifically talking about the /8s, where you get a decent bang for your reclaiming effort buck. But even that isn't enough anymore to bother at this point... Even if true, that point is past. Based on current projections, it is unlikely we'd be able to recover _any_ /8s before exhaustion hits due to the protracted litigation that would ensue, and even if we did manage to get some of them back (which isn't guaranteed, and would cost millions of dollars in any case), What would that be, $0.25 per address? Big deal. IPv6 still won't be deployed and usable in any meaningful way unless we make more progress in the next two years than we have in the last ten. Progress in various aspects of IPv6 has been slow because it didn't need to be faster. I see no solvable issues with IPv6 deployment that can't be solved in those 2 years. (No, we still won't have routing that will take us to the next century by then, but I suggest we don't wait for that.) Same thing for repurposing 240/4, by the way. Decade problem. Come back and discuss that when Windows recognizes that block as normal unicast addresses by default. If we had done this two years ago it could have been in Vista and in an XP update, so the space would have been usable by 2010 or so when the older Windows versions and other implementations that don't accept these addresses would have had the time to be updated manually or replaced. Maybe the RIRs have contracts with all new PI holders, but that doesn't automatically give ARIN the authority to reclaim address space after a policy change. Again, I don't know about all RIRs, but that is _explicitly called out_ in ARIN's Registration Services Agreement RIRs would still have to show that it's a reasonable thing to do. I'm still not a lawyer, but I could easily come up with several arguments why I should be able to keep my addresses despite any contracts. and AFAIK has been since day one. I have never heard of a case where an otherwise legitimate organization (i.e., not a front for a spam outfit or some such) used address space in a way that wasn't abusive or criminal, but didn't comply with RIR policies and got those revoked. As a non-lawyer, I would judge the chances in court for reclaiming IPv4 /8s higher than those for reclaiming IPv6 PI space: in the first case, it's the benefit the continued operation of the IPv4 internet, in the latter case, it's going to look highly arbitrary. I'd suggest you review the comments by ARIN's counsel at the last meeting WRT revoking legacy assignments. It's more complicated than it appears at first glance, particularly to someone not used to our legal system. Isn't everything? The opinions of one lawyer aren't worth much. As a profession, they lose 50% of all their cases, so obviously they must be wrong 50% of the time. (Not sure if engineers do better, though.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 20-sep-2007, at 21:10, Stephen Sprunk wrote: First of all, litigation isn't the only way to get something done, and second, do don't know that until you try. If you try to revoke someone's /8 or /16, you can bet that they're going to sue you. So? The RIRs and ICANN have deep pockets. SCO had deep pockets too. IBM, Novell, etc. had much, much deeper pockets. Do you really think ARIN or ICANN could take on titans such as GE, IBM, ATT, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly, Prudential, and Merck? Even _one_ of them? ARIN would be squashed like a bug. Not to mention the entire weight of the USG if ARIN tries to mess with _their_ 13 /8s. I'm confident that the RIRs' membership would oust any leaders that knowingly got them engaged in significant litigation of this sort. But there are other approaches than simply revoking the address space. For instance, setting up a policy that governs who gets to keep legacy space that takes into consideration various types of use and cost of renumbering makes sense. I'm sure some legacy space is used in a way that's fairly reasonable, while other space isn't used at all. I have proposed policy for ARIN to head in that direction. We'll see if it passes next month. Obviously the elephant in the room is the US government that has about 5% of all address space, which seems excessive even for legacy holders. We don't know what the US DoD is doing with their addresses since that's classified; besides, it was their network to begin with so they do have some special priviledges. The remainder of the USG's address space appears reasonable given the number of hosts/employees/etc. I'm sure you're aware that different size assignments were made to different organizations. I was specifically talking about the /8s, where you get a decent bang for your reclaiming effort buck. But even that isn't enough anymore to bother at this point... Those /8s are held by orgs with significant financial resources and are all at least partially still in use. There are thousands of /16s and tens of thousands of /24s that can be reclaimed with less effort, time, and cost than a single /8 could be, because those smaller blocks aren't in use anymore. There's also a fair amount of squatting on LIR-issued blocks that were justified at the time but aren't anymore. Even if true, that point is past. Based on current projections, it is unlikely we'd be able to recover _any_ /8s before exhaustion hits due to the protracted litigation that would ensue, and even if we did manage to get some of them back (which isn't guaranteed, and would cost millions of dollars in any case), What would that be, $0.25 per address? Big deal. ARIN gets a _maximum_ of $0.034 per address from the Xtra Large ISPs that are consuming 80% of ARIN's address space. In reality, they would get $0 per address because those ISPs have already topped out on the fees they pay; once you pass a /14, you pay _nothing_ for additional addresses. My pleas to correct the fee schedule's indirect encouragement of massive waste have apparently fallen on deaf ears. IPv6 still won't be deployed and usable in any meaningful way unless we make more progress in the next two years than we have in the last ten. Progress in various aspects of IPv6 has been slow because it didn't need to be faster. I see no solvable issues with IPv6 deployment that can't be solved in those 2 years. The single biggest thing we need now are consumer CPE boxes that understand v6 and have 6to4 on by default. The host issue will take care of itself over the next couple of years as non-Vista machines wear out and are replaced. We also need specialty boxes like load balancers, firewalls, NMS, etc. to gain v6 support, but that problem is a few orders of magnitude smaller in scope and could be solved within 2 years by operators beating on their respective sales droids _today_. (No, we still won't have routing that will take us to the next century by then, but I suggest we don't wait for that.) No offense to the ISPs, but fixing the DFZ is a relatively small problem _to deploy_ compared to upgrading a billion end-user sites. It's a much harder problem to come up with a solution for, though -- and the sort of problem the IRTF and IETF seem to be best at. Same thing for repurposing 240/4, by the way. Decade problem. Come back and discuss that when Windows recognizes that block as normal unicast addresses by default. If we had done this two years ago it could have been in Vista and in an XP update, so the space would have been usable by 2010 or so when the older Windows versions and other implementations that don't accept these addresses would have had the time to be updated manually or replaced. v6 _could_ have been in NT4, Win98, WinMe, Win2k, WinXP, or Win2k3. It wasn't; it was first implemented and on by default
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Seems to me that what you are saying amounts to the statement that PI space cannot exist by definition. If there is address space that is routable on an Internet-wide basis it is by definition routable Internet space and no PI space. If someone needs such space they need to obtain an IP address space allocation and persuade their ISPs to route it. The question of whether this is possible is a policy issue, not a technical issue. Whatever the policy status (people disagree as to what the situation is) it is clearly not going to be solved by a technical hack that does not address the underlying political constraints. -Original Message- From: Fred Baker [mailto:[EMAIL PROTECTED] Sent: Thursday, September 20, 2007 4:35 AM To: IETF-Discussion Subject: Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it) owners of those services will simply go to ISPs and say route this, or I'll find someone else who will. I'm actually not as convinced of this. Yes, they can get routing from their ISP, and the ISP will be happy to sell it to them. Can they get it from their ISP's upstream, and from that ISP's downstreams? To make it into PI space in the usual sense of the word, I think they wind up writing a contract with every ISP in the world that they care about. I think ULAs will exceed the bounds of a single administration, but they will do so on the basis of bilateral contract, not general routing. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Stephen Sprunk wrote: SCO had deep pockets too. IBM, Novell, etc. had much, much deeper pockets. Do you really think ARIN or ICANN could take on titans such as GE, IBM, ATT, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly, Prudential, and Merck? Even _one_ of them? ARIN would be squashed like a bug. Not to mention the entire weight of the USG if ARIN tries to mess with _their_ 13 /8s. I'm confident that the RIRs' membership would oust any leaders that knowingly got them engaged in significant litigation of this sort. I would largely agree with what you wrote, but put it another way: deep pockets are an incentive and not a deterrent. Someone who has no money is said to be judgment proof (heh - sort of like SCO right now ;-). Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Stephen Sprunk wrote: So? The RIRs and ICANN have deep pockets. SCO had deep pockets too. IBM, Novell, etc. had much, much deeper pockets. Do you really think ARIN or ICANN could take on titans such as GE, IBM, ATT, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly, Prudential, and Merck? Even _one_ of them? ARIN would be squashed like a bug. Not to mention the entire weight of the USG if ARIN tries to mess with _their_ 13 /8s. All of which is moot. The amount of money it would cost to litigate this is irrelevant, because there's no way that taking this to courts could result in any relief for the Internet before IPv4 space is exhausted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Hallam-Baker, Phillip wrote: Seems to me that what you are saying amounts to the statement that PI space cannot exist by definition. If there is address space that is routable on an Internet-wide basis it is by definition routable Internet space and no PI space. There can be such a thing as PI space that is treated differently than PA space. But anyone who thinks that having a PI prefix means that his prefix advertisements will be accepted in perpetuity by every IPv6 network is deluded. Sooner or later, you're going to have to pay _somebody_ to get that prefix routed. And the amount may well increase over time, perhaps drastically. And if you don't keep making those payments you're not going to be reachable anymore. So you can pay your ISP for PA space (along with connectivity) or you can pay somebody else (maybe many somebodys) for PI space in everyone's routing table. In either case you should design your network to be able to renumber in case you want to change who you're doing business with, or are forced to change your prefix. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
owners of those services will simply go to ISPs and say route this, or I'll find someone else who will. I'm actually not as convinced of this. Yes, they can get routing from their ISP, and the ISP will be happy to sell it to them. Can they get it from their ISP's upstream, and from that ISP's downstreams? To make it into PI space in the usual sense of the word, I think they wind up writing a contract with every ISP in the world that they care about. I think ULAs will exceed the bounds of a single administration, but they will do so on the basis of bilateral contract, not general routing. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On 19-sep-2007, at 21:06, Tony Hain wrote: It is clear that people on this list have never really run a network as they appear to be completely missing the point, but there is no reason to respond to each individually... [why ULA-C is not a problem] I agree 100% ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 19-sep-2007, at 16:40, Stephen Sprunk wrote: [provider independent addresses] However, it is the only solution available today that the operational folks consider viable. The IETF promised something different and has yet to deliver, so PI was passed and deployed. If the IETF does eventually deliver something viable, the RIRs will consider deprecating PI. And that would be the same kind of consideration that has gone towards deprecating the holding of nearly 0.5% of the total IPv4 address space by a single organization? Despite the fact that we're quickly running out of available IPv4 space and the number of organizations involved is less than 50, visible efforts have yet to materialize. So I doubt anything is going to happen once a few tens of thousands of organizations have cast their IPv6 PI addresses in stone. Those prefixes will be around for a _long_ time. Those who propose shim6 or similar solutions need to expect it'll take another decade after the ink is dry for their solutions to be considered viable Curious how so many people know exactly that so many transitions will take a decade or more, without ANY precedents to base this on. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On 19-sep-2007, at 22:51, Thomas Narten wrote: And owners of those services will simply go to ISPs and say route this, or I'll find someone else who will. And the sales and marketing departments of many ISPs will fall over each other to be the first to say why certainly we'd love your business. I used to work at a large ISP with exactly these kinds of sales people. They have a hard time taking no for an answer from the engineers, but when the engineers say sure we can do it but it isn't going to work and then, lo and behold, it doesn't work, they tend to catch on. I.e., you can pay YOUR ISP to route your ULAs, but that doesn't mean the next ISP is going to accept those advertisements. Obviously unbelievable amounts of money will make a difference here, but how does it make sense to go visit all the largest ISPs handing out money if you can get a PI or PA block much cheaper and easier? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
And owners of those services will simply go to ISPs and say route this, or I'll find someone else who will. And the sales and marketing departments of many ISPs will fall over each other to be the first to say why certainly we'd love your business. I used to work at a large ISP with exactly these kinds of sales people. They have a hard time taking no for an answer from the engineers, but when the engineers say sure we can do it but it isn't going to work and then, lo and behold, it doesn't work, they tend to catch on. I.e., you can pay YOUR ISP to route your ULAs, but that doesn't mean the next ISP is going to accept those advertisements. my experience is that users do get smarter over time. it just takes a long time. the problem is that they're being conditioned to accept that something will work by early behavior of ISPs, when it won't work in the long term. here's the deal: if you get a PA block, it will fail to work if you change ISPs or if the ISP is forced to renumber. if you get a PI block or ULA block, it will fail to work when the ISPs routing complexity gets too great and you can't afford to pay them to route your prefix anymore. so absent some kind of indirection between what hosts see and what ISPs route on, neither arrangement is permanent and neither avoids the need to renumber. Obviously unbelievable amounts of money will make a difference here, but how does it make sense to go visit all the largest ISPs handing out money if you can get a PI or PA block much cheaper and easier? when push comes to shove, I'm not convinced that it will be cheaper to get ISPs to route PI blocks than to route ULA blocks. unless they're somehow aggregatable. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
owners of those services will simply go to ISPs and say route this, or I'll find someone else who will. I'm actually not as convinced of this. Yes, they can get routing from their ISP, and the ISP will be happy to sell it to them. Can they get it from their ISP's upstream, and from that ISP's downstreams? To make it into PI space in the usual sense of the word, I think they wind up writing a contract with every ISP in the world that they care about. Paul Wilson and Geoff Huston wrote an article a while back entitled Competitive Addressing (http://www.potaroo.net/ispcol/2005-04/compete.html) that talked about competion on policy resulting in policy dilution. While the thrust of the proposal they were responding to was different, there are some parallels. I.e., that when you get people entities on policy, and the incentives favor increase revenue rather than Good of the Internet the bottom line, lowest common denominator tends to win - even to the detriment of common sense. A key point here is that when it comes to sales and marketing, it's problematic when your competitor says we offer X, if you yourself don't. Given the commodity nature of ISP service, it doesn't take long before everyone is offering similar terms, even if there are technically bad implications (they won't kick in until next quarter anyway). There is often a rather large disconnect between what the operators in the trenches think is a Good Idea and what the Sales Marketing side of an organization think is necessary to remain profitable (or increase market share, etc.). And please note, I'm channeling what I have heard, from both speakers and from hallway chatter at RIR meetings, and this is from people that have been around a long time and have been (or still are) in the trenches operating networks, so to speak. So this is more than just a theoretical concern. The concern is that pretty soon, everyone will route ULAs because they feel like they are at a competitive disadvantage if others are doing so and they are not. And that would a huge mess. And what if only _some_ of the ISPs routed them? We'd still have a mess, because now we'd have a Balkanized Internet, where univeral connectivity wasn't the norm anymore. I think ULAs will exceed the bounds of a single administration, but they will do so on the basis of bilateral contract, not general routing. I've made that argument in the past too, but there are others who just don't think it is that simple or will end there. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Keith Moore [EMAIL PROTECTED] writes: Thomas Narten wrote: Keith Moore [EMAIL PROTECTED] writes: Sooner or later, routing scalability will be a problem in IPv6. When that happens, each network will pick some means to decide which prefixes get advertised within its network and which get filtered. It's not rocket science to guess that networks will favor their own customers, the networks with which they have explicit agreements, and the networks from which their customers derive the most value. That probably puts most ULAs and PIs fairly far down in the preference list. Actually, my read of arguments coming from those opposed to ULAs is that a good number of folk are worried that the some, if not many, ULAs would be pretty high up on the preference list. I.e., those hosting content that has become popular. And owners of those services will simply go to ISPs and say route this, or I'll find someone else who will. And the sales and marketing departments of many ISPs will fall over each other to be the first to say why certainly we'd love your business. And then the simple notion of filtering all ULA space goes out the window and we have huge mess, that involves even more pressures to accept more routes (despite the limitations on technology), etc. You may disagree with that scenario, but it is one that does concern people in the operational community and is one reason why the proposal is currently wedged. Actually I don't disagree with the scenario at all; in fact I think it's exactly what I envision. I just don't see why it's such a horrible thing. Does Balkanization of the Internet mean anything to you? What I see as happening when the owners of those services go to ISPs and say we'd like to have these ULAs be routed is this: The ISPs say Great, and we'd love to route them for you. However, as we are sure you know, routing table space is scarce, and routing updates are expensive, and ULAs aren't aggregatable. So it costs a lot to route them, not just for us but for other ISPs also. There are brokers who lease routing table space in ISPs all over the world, and they'll sublease a routing table slot for your ULA prefix - for a price. But you'll be competing with lots of services for a small number of routing table entries, and they go to the highest bidders. With all due respect, what ivory tower are you living in? I really think you need to go to an RIR meeting sometime and actually _listen_ to what is said and have a _dialog_ with some of those operators you have been so quick to dismiss in previous postings. You might find that some of them are actually trying to keep the Internet working and believe as much as you do in an open Internet for all... They whole idea that we can have a market of routing slots and that people will pay for routability is a nice idea, except that after 10+ years of talking about it, no one has even the remotest idea of how to make it happen in practice. Well, not unless we have a new world order, ISPs (and the entire DFZ) become subject to significant regulation where policies about routing slots can be set, etc. Is that where you think we need to go? There are certainly parties that would be thrilled to have the Internet move in that direction... But be careful what you wish for... Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Sooner or later, routing scalability will be a problem in IPv6. When that happens, each network will pick some means to decide which prefixes get advertised within its network and which get filtered. It's not rocket science to guess that networks will favor their own customers, the networks with which they have explicit agreements, and the networks from which their customers derive the most value. That probably puts most ULAs and PIs fairly far down in the preference list. Actually, my read of arguments coming from those opposed to ULAs is that a good number of folk are worried that the some, if not many, ULAs would be pretty high up on the preference list. I.e., those hosting content that has become popular. And owners of those services will simply go to ISPs and say route this, or I'll find someone else who will. And the sales and marketing departments of many ISPs will fall over each other to be the first to say why certainly we'd love your business. And then the simple notion of filtering all ULA space goes out the window and we have huge mess, that involves even more pressures to accept more routes (despite the limitations on technology), etc. You may disagree with that scenario, but it is one that does concern people in the operational community and is one reason why the proposal is currently wedged. Actually I don't disagree with the scenario at all; in fact I think it's exactly what I envision. I just don't see why it's such a horrible thing. Does Balkanization of the Internet mean anything to you? Yes. But that's in nobody's interest. People will work to make their sites reachable by as wide an audience as they think is interested, and they'll use the best mechanisms they can find to do so. And I'm not convinced that some ULAs or PIs being routed through the core will result in Balkanization of the Internet. What I see as happening when the owners of those services go to ISPs and say we'd like to have these ULAs be routed is this: The ISPs say Great, and we'd love to route them for you. However, as we are sure you know, routing table space is scarce, and routing updates are expensive, and ULAs aren't aggregatable. So it costs a lot to route them, not just for us but for other ISPs also. There are brokers who lease routing table space in ISPs all over the world, and they'll sublease a routing table slot for your ULA prefix - for a price. But you'll be competing with lots of services for a small number of routing table entries, and they go to the highest bidders. With all due respect, what ivory tower are you living in? We're all standing in the dark feeling different parts of an elephant, trying to make sense of the whole thing by talking to one another. I really think you need to go to an RIR meeting sometime and actually _listen_ to what is said and have a _dialog_ with some of those operators you have been so quick to dismiss in previous postings. You might find that some of them are actually trying to keep the Internet working and believe as much as you do in an open Internet for all... Of course they are. From their own points-of-view about what works well. The elephant analogy applies to them also. They whole idea that we can have a market of routing slots and that people will pay for routability is a nice idea, except that after 10+ years of talking about it, no one has even the remotest idea of how to make it happen in practice. Well, not unless we have a new world order, ISPs (and the entire DFZ) become subject to significant regulation where policies about routing slots can be set, etc. Is that where you think we need to go? There are certainly parties that would be thrilled to have the Internet move in that direction... But be careful what you wish for... No, it's not where I think I need to go. The point is only that sooner or later there will be pushback associated with routing pain, and when that pushback happens people will look to solve their problems in other ways. Of course, we would like to avoid getting into a dead end where there's no good way to solve the problem from where we've ended up. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On 20-sep-2007, at 14:42, Thomas Narten wrote: A key point here is that when it comes to sales and marketing, it's problematic when your competitor says we offer X, if you yourself don't. Given the commodity nature of ISP service, it doesn't take long before everyone is offering similar terms, even if there are technically bad implications [...] The concern is that pretty soon, everyone will route ULAs because they feel like they are at a competitive disadvantage if others are doing so and they are not. And that would a huge mess. The point you're missing is that one ISP can't provide global reachability for a prefix, you only get this if everyone cooperates. That just isn't going to happen unless someone with a huge amount of clout is going to force the issue. If Google wants to be reachable over ULA space then people may open up their filters. If it's IBM or Boeing, nobody is going to care. And to people who can get PI or PA space, there is no point in forcing the issue, because even if they're successful in the end, it's going to be painful and expensive for them, too. But even if it happens: who cares? And what if only _some_ of the ISPs routed them? We'd still have a mess, because now we'd have a Balkanized Internet, where univeral connectivity wasn't the norm anymore. That sounds like an apt description of the current IPv6 internet. It works well in Europe and Asia, but North America is a wasteland: $ ftp ftp.ietf.org Trying 2610:a0:c779:1a::9c9a:1095... ftp: connect to address 2610:a0:c779:1a::9c9a:1095: Operation timed out Trying 156.154.16.149... Connected to ftp.ietf.org. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Does Balkanization of the Internet mean anything to you? Yes. NAT, BGP route filtering, bogon lists, firewalls, Community of Interest extranets such as SITA, Automotive Network Exchange, RadianzNet. And let's not forget the IP VPN services that companies like Verizon sell as a flagship product. It is probable that there are more hosts today in the Balkanized portions of the Internet than on the public portions. --Michael Dillon P.S. Not to mention sites that are more than 30 hops away from each other. I've seen traceroutes that go up to 27 hops so I imagine that the hopcount diameter is once again becoming an issue as it was prior to 1995. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On Sep 20, 2007, at 6:44 AM, [EMAIL PROTECTED] wrote: Not to mention sites that are more than 30 hops away from each other. I've seen traceroutes that go up to 27 hops so I imagine that the hopcount diameter is once again becoming an issue as it was prior to 1995. That was in many respects a host problem - hosts initialized TTLS to 32, and in so doing limited themselves to that diameter. I believe most hosts now set the magic number to 64. Do we believe that we are pushing that boundary? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 19-sep-2007, at 16:40, Stephen Sprunk wrote: [provider independent addresses] However, it is the only solution available today that the operational folks consider viable. The IETF promised something different and has yet to deliver, so PI was passed and deployed. If the IETF does eventually deliver something viable, the RIRs will consider deprecating PI. And that would be the same kind of consideration that has gone towards deprecating the holding of nearly 0.5% of the total IPv4 address space by a single organization? Despite the fact that we're quickly running out of available IPv4 space and the number of organizations involved is less than 50, visible efforts have yet to materialize. ARIN's counsel has told ARIN that it is unclear if they have legal standing to revoke legacy assignments. And, for the record, there are over 50,000 of them, not less than 50. Also, projections show that even if we reclaimed _every_ legacy assignment (many of which are still in use and even justified under current policy), it would only delay exhaustion six months to a year; it is felt that doing so is not generally worth the effort and would certainly cost an absurd amount in legal fees, and the litigation is likely to last beyond the exhaustion date anyways (with no solid guess as to who would win in the end). So I doubt anything is going to happen once a few tens of thousands of organizations have cast their IPv6 PI addresses in stone. Those prefixes will be around for a _long_ time. The situation is different with v6 because all PI assignments are subject to a contract that allows ARIN to revoke them at any time with a policy change. If a viable alternative emerged, ARIN could stop making new PI assignments, deprecate the existing ones, and drop them after a few years' transition period. OTOH, the alternative that appears may be some novel idea that allows widespread use of PI without injecting routes into the DFZ, in which case it won't be necessary to deprecate it but rather to make it easier to get. Those who propose shim6 or similar solutions need to expect it'll take another decade after the ink is dry for their solutions to be considered viable Curious how so many people know exactly that so many transitions will take a decade or more, without ANY precedents to base this on. Any transition that requires a change to the _host protocol stack_ can be expected to take that long, based on how long it took to get core v6 support implemented and enabled by default in Windows. It's still unusable for the vast majority of consumers because they're behind CPE NAT devices without 6to4 support. Kudos to Apple for being the first to ship a usable v6 CPE box; hopefully other vendors will follow within a few years. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Ted Hardie wrote: The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. I am totally against ULA-C, and I am not against PI, so please re-examine that statement. Your second statement: From my point of view, ULA-C differs from 4193 because I presume a ULA-C will give me whois and reverse DNS. I've been told that sixxs.net is doing whois, but I have to know to ask whois.sixxs.net for the information. Delegating c.f.ip6.arpa to sixxs.net would also be required for me to take 4193 seriously. (And d.f.ip6.arpa..) I am very happy to use a ULA for my needs, and a PA for the part of my network that needs to talk to outside my AS. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 20-sep-2007, at 18:33, Stephen Sprunk wrote: ARIN's counsel has told ARIN that it is unclear if they have legal standing to revoke legacy assignments. First of all, litigation isn't the only way to get something done, and second, do don't know that until you try. If you try to revoke someone's /8 or /16, you can bet that they're going to sue you. We did see 46/8 come back earlier this year, but unless I'm mistaken, that was the first legacy /8 to be returned this century. Return is different than revocation. ARIN is working on policy changes that would encourage/incent voluntary return, as well as community outreach. And, for the record, there are over 50,000 of them, not less than 50. Clarification: 31,386 in ARIN's region. I haven't seen stats for the other RIRs. 5 organizations holding nearly 0.5% of the IPv4 space each? I'm impressed! With that kind of address compression technology we don't need IPv6 after all. I'm sure you're aware that different size assignments were made to different organizations. Also, projections show that even if we reclaimed _every_ legacy assignment (many of which are still in use and even justified under current policy), it would only delay exhaustion six months to a year; it is felt that doing so is not generally worth the effort and would certainly cost an absurd amount in legal fees, and the litigation is likely to last beyond the exhaustion date anyways (with no solid guess as to who would win in the end). I mostly agree with that, but a few years ago it looked like reclaiming, say, half of the legacy /8s would buy us 2 - 5 extra years of IPv4 lifetime and there was enough time to do it at that point. Even if true, that point is past. Based on current projections, it is unlikely we'd be able to recover _any_ /8s before exhaustion hits due to the protracted litigation that would ensue, and even if we did manage to get some of them back (which isn't guaranteed, and would cost millions of dollars in any case), it wouldn't have a material effect. We're going to run out in a few years no matter what we do, the DFZ is going to explode because big ISPs will be getting e.g. hundreds of /20s instead of a single /12 for each request, and IPv6 still won't be deployed and usable in any meaningful way unless we make more progress in the next two years than we have in the last ten. Same thing for repurposing 240/4, by the way. Decade problem. Come back and discuss that when Windows recognizes that block as normal unicast addresses by default. The situation is different with v6 because all PI assignments are subject to a contract that allows ARIN to revoke them at any time with a policy change. If a viable alternative emerged, ARIN could stop making new PI assignments, deprecate the existing ones, and drop them after a few years' transition period. I don't believe that for one second. Maybe the RIRs have contracts with all new PI holders, but that doesn't automatically give ARIN the authority to reclaim address space after a policy change. Again, I don't know about all RIRs, but that is _explicitly called out_ in ARIN's Registration Services Agreement and AFAIK has been since day one. That, in fact, is one of the many reasons that the legacy holders do not want to join the RIRs: they believe that their addresses can't be revoked as-is but they could be if they signed an RSA. I don't know of a precedent of any RIR EVER reclaiming ANY address space without the cooperation of the holder, despite the holder not complying with policies. ARIN does so today on a regular basis for certain reasons. There is a proposal that would grant them more policy authority to do so in more cases. The language enabling such policy is in the RSA. As a non-lawyer, I would judge the chances in court for reclaiming IPv4 /8s higher than those for reclaiming IPv6 PI space: in the first case, it's the benefit the continued operation of the IPv4 internet, in the latter case, it's going to look highly arbitrary. I'd suggest you review the comments by ARIN's counsel at the last meeting WRT revoking legacy assignments. It's more complicated than it appears at first glance, particularly to someone not used to our legal system. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
the concern i heard wrt ULA-G (and therefore wrt ULA-C upon with -G is based) is that the filtering recommendations in RFC 4193 were as unlikely to work as the filtering recommendations in RFC 1597 and RFC 1918. Given the overwhelming success of RFC 1918 it only requires a very small percentage of sites leaking routes to make it seem like a big problem. This is normal. When you scale up anything, small nits happen frequently enough to become significant issues. But that is not a reason to get rid of RFC 1918. The fact that the filtering recommendations of ULA-C and ULA-G have the same flaws as RFC 1918 is a not sufficient reason to reject them wholesale. i realized in that moment, that ULA-G (and therefore ULA-C) is not an end run around PI space, it's an end run around the DFZ. some day, the people who are then responsible for global address policy and global internet operations, will end the tyranny of the core by which we cripple all network owners in their available choices of address space, based solely on the tempermental fragility of the internet's core routing system. but we appear not to be the generation who will make that leap. I think that even today, if you analyze Internet traffic on a global scale, you will see that there is a considerable percentage of it which bypasses the core. Let the core use filters to protect the DFZ because the DFZ is no longer necessary for a workable Internet. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On Tue, 18 Sep 2007, Tony Hain wrote: snip If you don't label it there is no clearly agreed way to filter these out if you don't want them. The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. PI and ULA-C are for completly different purpose. and both will be leaked no mather what we do, you can't force someone to never route it... what you can do is to make it less desirable to do so. -- -- Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID [EMAIL PROTECTED] | - IPv6 is The Key! --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On Tue, 18 Sep 2007, Paul Vixie wrote: snip someone on ARIN PPML accused ULA-C (and therefore ULA-G) of being an end run around PA/PI by which they meant a way to get the benefits of PI without qualifying for the costs imposed by PI on everyone else in the DFZ. i realized in that moment, that ULA-G (and therefore ULA-C) is not an end run around PI space, it's an end run around the DFZ. some day, the people who are then responsible for global address policy and global internet operations, will end the tyranny of the core by which we cripple all network owners in their available choices of address space, based solely on the tempermental fragility of the internet's core routing system. but we appear not to be the generation who will make that leap. I wouldn't be giving up that easy... still have time until march 2008 :p (old ipv6-wg, now v6man-wg timeframe for deciding upton ula-c/g) :) -- -- Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID [EMAIL PROTECTED] | - IPv6 is The Key! --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On Tue, 18 Sep 2007, Noel Chiappa wrote: From: Paul Vixie [EMAIL PROTECTED] ULA-G (and therefore ULA-C) is not an end run around PI space, it's an end run around the DFZ. some day, the people who are then responsible for global address policy and global internet operations, will end the tyranny of the core by which we cripple all network owners in their available choices of address space, based solely on the tempermental fragility of the internet's core routing system. snip What I hear you saying, in your references to the DFZ/core, is that you aren't happy with the notion that there's a large part of the internetwork in which more or less all destinations are reachable? If so, in effect, you're visualizing a system in which reachability is less ubiquitous? I.e. for a given destination address X, there will be significant parts of the internetwork from which a packet sent to X will not reach X - and not because of access controls which explicitly prevent it, but simply because that part of the internetwork doesn't care to carry routing information for that destination. Is that right? what I read into it is... the future internet might not be structured as it is today, we might get a internet on the side which don't touch the DFZ at all. Mostly regionbased traffic... -- -- Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID [EMAIL PROTECTED] | - IPv6 is The Key! --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
From: Stephen Sprunk [EMAIL PROTECTED] That comment shows how completely out of touch you are with the enterprise operational world. Unfortunately, that is rather common with the ivory-tower vendor folks commenting in this thread. Having spent the best part of a decade in the commercial world, I could make some nasty ad hominem comments about how some people tend to focus on the short term, and their particular interests, but why don't we just move on past all that? _understand_ why PI is necessary, however much they dislike and/or fear it. Most (all?) of us understand and accept that multi-homing, vendor independence, etc are very desirable *capability* goals. However, whether PI is the right *particular engineering mechanism* to reach those goals remains questionable. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
what I read into it is... the future internet might not be structured as it is today, we might get a internet on the side which don't touch the DFZ at all. Mostly regionbased traffic... WRONG! The future Internet will be structured the SAME as it is today, mostly region-based traffic. The main exception to that rule is when a there are countries in different regions which share the same language. For instance there will always be lots of interregional traffic between France and Canada, or between Portugal and Brazil. People who are in the IETF have a warped view of reality because we all speak English, and since there are English speaking countries in North America, Europe, southern Africa, and the Asia-Pacific region, it seems like everything is centralised. In addition, English is the 21st century lingua-franca so it will always drive a certain level of international traffic to any country, but moreso to countries like Norway where the people often learn to speak English better than native English-speaking people. Go to a country like Russia and it's a different story. Few people learn English or any other language well enough to use it. There are no vaste hordes of English-speaking tourists like in Spain or Italy. But there is still a vast Internet deployment for the most part separate from the English-speaking Internet. There the major search engines are Rambler and Yandeks. Internet exchanges are located in Moskva, Sankt Peterburg, Nizhniy Novgorod, Samara, Perm', Ekaterinburg, and Novosibirsk. It's a basic fact of economics that the majority of transactions in any point on the globe will always be with nearby points. That's why the USA buys more goods from Canada than from any other country, in spite of the fact that Canada is 1/10th the population. Communications volume follows transaction volume, and therefore, the only reason that the Internet was not more regional a long time ago, is that the process of shifting communications from legacy networks to the Internet is a slow process. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake Michael Richardson [EMAIL PROTECTED] I have an application where I will have approximately 2000 hosts (many of them virtualized) in a cabinet, and I will eventually have hundreds of such cabinets spread around the world. ... Site-local addresses could be used, but they are distasteful to me for all the reasons that they were deprecated, and all the reasons in rfc1627. (ARIN has suggested that I might consider site-local addresses) I hope you misunderstood; ARIN should have been referring to ULAs, RFC 4193. ARIN has asked told me: (2) In order to receive an initial IPv6 assignment, you must qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. That is correct. Well, the answer would be, for this use would be use 10.x network for IPv4. That's why I asked for IPv6. (none of the other rfc1918 spaces are big enough for my use, btw) That is not. ARIN policy is that private addresses are preferred, but public addresses can be assigned for private use if there's a decent justification. Also note that actually _requesting_ PIv4 space is not required to get PIv6 space; only _qualifying_ is required. You appear to qualify based on the limited information provided. I am very disappointed. I don't expect anyone to go and fix ARIN. I am simply posting to express myself. You appear to qualify for a PI /48 (or more than one) under existing policy. If you are unhappy with the policy or need a better explanation, please join [EMAIL PROTECTED] and ask for help. If you do not believe ARIN is following the existing policy, please contact [EMAIL PROTECTED] S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake Noel Chiappa [EMAIL PROTECTED] From: Stephen Sprunk [EMAIL PROTECTED] _understand_ why PI is necessary, however much they dislike and/or fear it. Most (all?) of us understand and accept that multi-homing, vendor independence, etc are very desirable *capability* goals. However, whether PI is the right *particular engineering mechanism* to reach those goals remains questionable. You can question it, of course. I question it as well. However, it is the only solution available today that the operational folks consider viable. The IETF promised something different and has yet to deliver, so PI was passed and deployed. If the IETF does eventually deliver something viable, the RIRs will consider deprecating PI. Keep in mind that, for any solution that requires host changes, deliver includes being implemented and on by default in Windows. The IPv6 core protocol has only recently achieved this after a decade of waiting, and many other pieces still aren't available (firewalls, load balancers, consumer CPE boxes, management apps, etc). Those who propose shim6 or similar solutions need to expect it'll take another decade after the ink is dry for their solutions to be considered viable -- if ever. Those running networks have to do _something_ in the meantime, however, and the fact that what is available offends someone's sense of architectural purity is completely irrelevant. See also: NAT. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Wed, Sep 19, 2007 at 09:40:31AM -0500, Stephen Sprunk: Thus spake Noel Chiappa [EMAIL PROTECTED] From: Stephen Sprunk [EMAIL PROTECTED] _understand_ why PI is necessary, however much they dislike and/or fear it. Most (all?) of us understand and accept that multi-homing, vendor independence, etc are very desirable *capability* goals. However, whether PI is the right *particular engineering mechanism* to reach those goals remains questionable. You can question it, of course. I question it as well. However, it is the only solution available today that the operational folks consider viable. The IETF promised something different and has yet to deliver, so PI was passed and deployed. If the IETF does eventually deliver something viable, the RIRs will consider deprecating PI. Keep in mind that, for any solution that requires host changes, deliver includes being implemented and on by default in Windows. The IPv6 core protocol has only recently achieved this after a decade of waiting, and many other pieces still aren't available (firewalls, load balancers, consumer CPE boxes, management apps, etc). Those who propose shim6 or similar solutions need to expect it'll take another decade after the ink is dry for their solutions to be considered viable -- if ever. echo. A multi-homing solution that is simple and free of host requirements is imperitive. shim6 isn't it, sorry. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
From: Stephen Sprunk [EMAIL PROTECTED] .. ULA-C/G leaks will not collide with each other. This means that, unlike RFC1918 which is _impossible_ for ISPs to route for multiple customers, ULA-C/G routes _can_ be routed publicly. Any prohibition on doing so by the IETF or RIRs can (and IMHO, will) be overridden by customers paying for those routes to be accepted. Which would argue that the only realistic way to make *absolutely certain* that IPv6 private addresses truly *cannot* be used out in the 'main' internetwork is to allocate the same ranges of addresses to multiple parties. Anything else is just PI with a few speedbumps, and a different label. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Noel Chiappa wrote: From: Stephen Sprunk [EMAIL PROTECTED] .. ULA-C/G leaks will not collide with each other. This means that, unlike RFC1918 which is _impossible_ for ISPs to route for multiple customers, ULA-C/G routes _can_ be routed publicly. Any prohibition on doing so by the IETF or RIRs can (and IMHO, will) be overridden by customers paying for those routes to be accepted. Which would argue that the only realistic way to make *absolutely certain* that IPv6 private addresses truly *cannot* be used out in the 'main' internetwork is to allocate the same ranges of addresses to multiple parties. Perhaps, but then we end up with all of the problems associated with ambiguous addresses, and we lose all of the advantage of IPv6. Anything else is just PI with a few speedbumps, and a different label. Maybe, maybe not. In practice, today, not every IPv4 address prefix is PI. Today, the length of your IPv4 prefix has some influence on whether your prefix gets advertised. There may not be an absolute boundary, but there is a barrier nonetheless. So I can certainly imagine that it would be harder to get ULA prefixes as widely advertised as PA prefixes. How much harder, I cannot say. So the speedbumps might be useful. But people wanting to absolutely forbid any ISP from advertising a ULA prefix will probably be disappointed. That doesn't bother me, because I don't think it's necessary to have that absolute prohibition in order for networks to push back on routing table size and routing complexity. Sooner or later, routing scalability will be a problem in IPv6. When that happens, each network will pick some means to decide which prefixes get advertised within its network and which get filtered. It's not rocket science to guess that networks will favor their own customers, the networks with which they have explicit agreements, and the networks from which their customers derive the most value. That probably puts most ULAs and PIs fairly far down in the preference list. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Ted Hardie wrote: The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. I am totally against ULA-C, and I am not against PI, so please re- examine that statement. Your second statement: f you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. Also doesn't seem to me to make a lot of sense. There is a set prefix of ULAs now. Filtering it on is already possible (and I heartily encourage same!). Adding ULA-C doesn't make that easier or harder, and it does nothing else that would enforce keeping private space private. None of the ULA-C proposals I have seen came with a police force or standing army of clue-bat wielding networking engineers. It is clear that people on this list have never really run a network as they appear to be completely missing the point, but there is no reason to respond to each individually... Yes any one clueless ISP may announce ULA-C space from a customer, but there is no need for any of their peers to accept it. If the only choice is PI, there is no way for the peer ISP to know what should have been filtered out and the entire system has to deal with the leakage. Claims about cutting off long prefixes are unrealistic because there will be people in there that received PI expecting it to be routed so the RIRs would then have to hand out even larger blocks for routed PI, forcing the cost for renumbering onto people that had nothing to do with creating the problem. People want unique private space. If you force them to get it from PI blocks there is no way to sort out what should be globally routed from what should be private, or localized to just the customer's ISP. Putting a well-known label on it allows anyone that does not want the excess to easily identify it and kill it off. Using ULA-C puts the burden of getting space routed globally back onto the originating network, because they will either run both ULA-C PI, or renumber. Either way people who just want PI are not impacted by people that start with ULA-C and change their minds later, and the DFZ does not have to deal with leaked crap because it is easy to identify. This should not even be a debated issue, because ULA-C is just a way to group end site assignments into a block that is easy to filter out of the global routing system. As I said, those that oppose this are effectively forcing an unnecessary burden on the DFZ, which will result in the anti-PI camp saying 'I told you so' when the inevitable leakage happens. Yes 1918 leakage happens, but that is a self-inflicted wound and easy to correct, as ULA-C leakage would be. Leakage of PI that should have been kept local is impossible to detect or fix by the recipient. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Thomas Narten wrote: Keith Moore [EMAIL PROTECTED] writes: Sooner or later, routing scalability will be a problem in IPv6. When that happens, each network will pick some means to decide which prefixes get advertised within its network and which get filtered. It's not rocket science to guess that networks will favor their own customers, the networks with which they have explicit agreements, and the networks from which their customers derive the most value. That probably puts most ULAs and PIs fairly far down in the preference list. Actually, my read of arguments coming from those opposed to ULAs is that a good number of folk are worried that the some, if not many, ULAs would be pretty high up on the preference list. I.e., those hosting content that has become popular. And owners of those services will simply go to ISPs and say route this, or I'll find someone else who will. And the sales and marketing departments of many ISPs will fall over each other to be the first to say why certainly we'd love your business. And then the simple notion of filtering all ULA space goes out the window and we have huge mess, that involves even more pressures to accept more routes (despite the limitations on technology), etc. You may disagree with that scenario, but it is one that does concern people in the operational community and is one reason why the proposal is currently wedged. Actually I don't disagree with the scenario at all; in fact I think it's exactly what I envision. I just don't see why it's such a horrible thing. What I see as happening when the owners of those services go to ISPs and say we'd like to have these ULAs be routed is this: The ISPs say Great, and we'd love to route them for you. However, as we are sure you know, routing table space is scarce, and routing updates are expensive, and ULAs aren't aggregatable. So it costs a lot to route them, not just for us but for other ISPs also. There are brokers who lease routing table space in ISPs all over the world, and they'll sublease a routing table slot for your ULA prefix - for a price. But you'll be competing with lots of services for a small number of routing table entries, and they go to the highest bidders. On the other hand, it appears the particular services that you are offering to the general public would work just fine with PA address space. Furthermore, we'll be happy to offer you our graceful transition (tm) service in our contract with you, so that when the term of our contract comes to an end, we'll continue to accept traffic at your old PA addresses and tunnel that traffic to your new addresses for a specified period of overlap - basically the length of your DNS TTLs for those addresses. You can still use ULAs for your internal traffic and - via bilateral agreement - for traffic with other sites. We'd be happy to arrange tunnels to those other sites for routing traffic to and from your ULAs. Or if those destinations are our customers, we'll route those ULAs natively - we just won't advertise them to other networks that we know will filter them. But a lot of sites prefer that their ULAs not be advertised on the public Internet because that lessens the exposure of their non-public services to miscreants. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Jari Arkko wrote: Lixia, I'm just catching up with this thread today: If I summarize my understanding from the above in one sentence: there seems a perceived difference between PI and ULA-C prefixes, which, as far as I can see, does not exist. Whether a unique prefix is/not globally routable is determined by whether it gets injected into the routing system, no matter how it is labeled. Right. Or we can try to label it, but that labeling may not correspond to what is actually done with it. If you don't label it there is no clearly agreed way to filter these out if you don't want them. The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. I am totally against ULA-C, and I am not against PI, so please re-examine that statement. Your second statement: f you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. Also doesn't seem to me to make a lot of sense. There is a set prefix of ULAs now. Filtering it on is already possible (and I heartily encourage same!). Adding ULA-C doesn't make that easier or harder, and it does nothing else that would enforce keeping private space private. None of the ULA-C proposals I have seen came with a police force or standing army of clue-bat wielding networking engineers. Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Tony Hain wrote: [..] The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. I don't think ULA-C makes sense. We have a RIR system in place. These RIRs are supposed to provide address space for people/organizations who can justify a need for that address space. Clearly everybody does want this address space to be unique and a lot of people for various reasons (statistics, contact info, who it belongs to, which country, etc) want to have at least an entry somewhere in a database that is publicly available. As at least ARIN, APNIC and AfriNIC have policies in place now, which break the global policy that once existed, to provide /48's and upward to individual sites. These sites might or might not be (completely) connected to the Internet, there is no requirement anywhere to do so. As such, there is already a perfect method of getting globally unique and registered address space. As such, there is no need for ULA-C. Which is good, as any address space that gets marked as 'special' will be unusable because some people won't ever update filters, which is their problem of course, but it will hurt others. As history has shown that one day or another you will want to connect to the Internet, having those blocks simply come from the RIRs is the perfect way to do it. As for the routing system problem, simple Economics will resolve that. Either Transit Providers will stop accepting certain sized prefixes or they will nicely start charging serious amounts of cash for the routing slots they occupy. In the mean time the great people working on the [EMAIL PROTECTED] list will find a great method of avoiding that problem. We are at 900 prefixes in IPv6 and I really don't see it hitting 100k of them any time soon. When it does, then we know that we might need to hurry up a bit. But as the IPv4 tables are already at 230k and are doing fine, I think we can have quite a couple of quiet years before that will become a serious issue, especially when ISPs can always filter if they want. Checking the Looking Glass of GRH (http://www.sixxs.net/tools/grh/) it shows also that quite some ISP's are already attempting de-aggregation of their /32's and even the /20's they have received. Still the basic premise is that they should only be announcing that single prefix and most likely they only connect to you at one/two common points anyway and you won't need their more specifics. As such you can filter on those borders to avoid those few routes. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On Sep 18, 2007, at 8:09 AM, Tony Hain wrote: Jari Arkko wrote: Lixia, I'm just catching up with this thread today: If I summarize my understanding from the above in one sentence: there seems a perceived difference between PI and ULA-C prefixes, which, as far as I can see, does not exist. Whether a unique prefix is/not globally routable is determined by whether it gets injected into the routing system, no matter how it is labeled. Right. Or we can try to label it, but that labeling may not correspond to what is actually done with it. If you don't label it there is no clearly agreed way to filter these out if you don't want them. I'd agree that, ideally speaking, one would prefer using simple filtering rules. However as Jari already pointed out, whatever label one puts on a prefix may not correspond to what is done with it, *especially* as time goes. (a motto I heard from my high school son, the only thing that does change in life is change :-) and I would not attempt to bundle opinions regarding UCL-C and PI (I saw Ted already showed an example). Furthermore, we are all in this continuing process of understanding their implications in this complex, exciting, and constantly changing Internet. The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
if you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. Also doesn't seem to me to make a lot of sense. There is a set prefix of ULAs now. Filtering it on is already possible (and I heartily encourage same!). Adding ULA-C doesn't make that easier or harder, and it does nothing else that would enforce keeping private space private. None of the ULA-C proposals I have seen came with a police force or standing army of clue-bat wielding networking engineers. the concern i heard wrt ULA-G (and therefore wrt ULA-C upon with -G is based) is that the filtering recommendations in RFC 4193 were as unlikely to work as the filtering recommendations in RFC 1597 and RFC 1918. and that with a global registry of whois and in-addr, ULA-G (and therefore ULA-C) prefixes and packets would have considerably greater utility when leaked than RFC 1597/1918 prefixes and packets. so with demonstrable ease of leakage and demonstrably higher utility of leakage, nobody anywhere believes that ULA-G (and ULA-G) won't be leaked. on that basis, ULA-G (and ULA-C) are said to be functional equivilents to PI space. i don't like or agree with this reasoning. i'm just saying what i've heard. someone on ARIN PPML accused ULA-C (and therefore ULA-G) of being an end run around PA/PI by which they meant a way to get the benefits of PI without qualifying for the costs imposed by PI on everyone else in the DFZ. i realized in that moment, that ULA-G (and therefore ULA-C) is not an end run around PI space, it's an end run around the DFZ. some day, the people who are then responsible for global address policy and global internet operations, will end the tyranny of the core by which we cripple all network owners in their available choices of address space, based solely on the tempermental fragility of the internet's core routing system. but we appear not to be the generation who will make that leap. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On 18-sep-2007, at 17:50, Jeroen Massar wrote: I don't think ULA-C makes sense. We have a RIR system in place. These RIRs are supposed to provide address space for people/organizations who can justify a need for that address space. That's like selling train tickets at the airport. Except for the fraction of a promille of all IP users that have their own portable address space, RIRs don't even talk to IP users who are _connected_ to the internet, let alone those who aren't! It just doesn't make sense to involve the RIRs here. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On 18-sep-2007, at 18:10, Ted Hardie wrote: The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. I am totally against ULA-C, and I am not against PI, so please re- examine that statement. I'm in favor of ULA-C and against the current IPv6 PI policies, so it seems the statement indeed doesn't universally apply... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
From: Paul Vixie [EMAIL PROTECTED] ULA-G (and therefore ULA-C) is not an end run around PI space, it's an end run around the DFZ. some day, the people who are then responsible for global address policy and global internet operations, will end the tyranny of the core by which we cripple all network owners in their available choices of address space, based solely on the tempermental fragility of the internet's core routing system. This comment interested me, but I want to make sure I understand what you're getting at. Fully appreciating your comments seems to require reading between the lines somewhat, so if I make a mistake (below) in understanding you, please correct it. What I hear you saying, in your references to the DFZ/core, is that you aren't happy with the notion that there's a large part of the internetwork in which more or less all destinations are reachable? If so, in effect, you're visualizing a system in which reachability is less ubiquitous? I.e. for a given destination address X, there will be significant parts of the internetwork from which a packet sent to X will not reach X - and not because of access controls which explicitly prevent it, but simply because that part of the internetwork doesn't care to carry routing information for that destination. Is that right? Your comment about available choices of address space is more opaque. Are you saying that you'd like parts of the address space to be explicitly given over to such 'not globally routed' functionality? (I assume that you are happy with uniqueness, i.e. you're not proposing allocating the same chunk of address space to two different entities, right?) Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
From: Roger Jorgensen [EMAIL PROTECTED] a system in which reachability is less ubiquitous? I.e. for a given destination address X, there will be significant parts of the internetwork from which a packet sent to X will not reach X - and not because of access controls which explicitly prevent it, but simply because that part of the internetwork doesn't care to carry routing information for that destination. what I read into it is... the future internet might not be structured as it is today, we might get a internet on the side which don't touch the DFZ at all. Mostly regionbased traffic... Well, that's certainly one structure you could build if you have a system in which there are significant parts of the internetwork from which a packet sent to X will not reach X. Another possibile structure is the kind of thing that Keith mentioned, with industry-specific sections. From a policy standpoint, I don't have any particular feeling about such designs, pro or con. I mean, if people think it's useful to have them, that's not my call to make (and in the past I have produced systems which provided the tools to do exactly that). From a technical point of view, I do wonder if it's really worth the effort required in terms of extra configuration (which is a different point, of course). Instead of simply flooding information about all destinations everywhere, now, for each destination which is no longer visible over a global scope, you basically have to define, via configuration, a boundary which sets the scope outside which that destination is not 'visible' in the routing. That's a non-trivial amount of configuration - especially with today's routing architecture, which has no tools to easy describe/configure such boundaries. So if it's simply being done for efficiency reasons, I wonder whether the complexity/efficiency tradeoff there is worth it. If one has a policy reason to do it, that changes the equation, of course, and those goals may make it worthwhile. (This is all assuming I've correctly understood what he was proposing; the original message was a little short on technical detail.) Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Stephen Sprunk wrote: Thus spake Eliot Lear [EMAIL PROTECTED] Providing PI to enterprises who move now is a nice bonus, not not necessary in the long run. That comment shows how completely out of touch you are with the enterprise operational world. Or it perhaps shows how completely out of touch you are from the economics that are about to hit enterprises. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake Jun-ichiro itojun Hagino [EMAIL PROTECTED] Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. At a former employer, we had POPs in various sites around the globe, each with three to seven ISP connections. We'd typically change out one or two of those ISPs at each POP each year, based on pricing changes, traffic shares, service levels, and general arm-twisting of salespeople. I've seen similar elsewhere with folks I've consulted for: they want at least three providers, and they swap out one per year as the typical three-year contracts expire. In fact, it's been alleged in other fora that multihoming in this manner (i.e. with PI) has become mandatory in the US for public corporations, though I've never seen a citation. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 18-sep-2007, at 17:50, Jeroen Massar wrote: I don't think ULA-C makes sense. We have a RIR system in place. These RIRs are supposed to provide address space for people/organizations who can justify a need for that address space. That's like selling train tickets at the airport. Except for the fraction of a promille of all IP users that have their own portable address space, RIRs don't even talk to IP users who are _connected_ to the internet, let alone those who aren't! It just doesn't make sense to involve the RIRs here. The RIRs talk to anyone who submits the appropriate forms. They'll even help you fill out the forms if you can give them enough information to do so. You could even do it by phone or snail mail if you've been living under a rock and still don't have Internet service. ARIN policy, at least, explicitly allows for direct assignments to end sites even if they're not connected -- just like IANA assigned Class A/B/C blocks to disconnected orgs back in the good ol' days. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Thus spake Tony Hain [EMAIL PROTECTED] Jari Arkko wrote: Right. Or we can try to label it, but that labeling may not correspond to what is actually done with it. If you don't label it there is no clearly agreed way to filter these out if you don't want them. If they're truly local prefixes, they won't need to be filtered in the first place because they won't be advertised. If they're getting advertised, they're not local prefixes and presumably you don't want to filter them because there's someone at the other end who wants you to talk to them. If you don't like PI routes at all, the RIRs have made it easy to filter them by assigning PI out of specific blocks and in much smaller sizes than LIR blocks. To channel Randy for a moment, I encourage my competitors to do this. The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. I am a vocal supporter of PI and vocal detractor of ULA-C/G. In fact, the first time that ULA-C was proposed, I saw it for what it was (an end-run around the RIRs) and became a PI proponent; before that, I didn't really care either way. Do not stuff words into people's mouths, particularly when they're watching. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. I believe there will be a routing system problem at some point, and it pains me that I was still forced to support PI anyways because the IETF has utterly failed to produce an alternative that is viable _in the views of the operational community_. However, I do not believe the problem will be due to local routes at all; it will be due to the massive numbers of legitimate routes that having PI causes. However, without PI, there would be no routes at all because IPv6 would be ignored. PI is, unfortunately, the lesser of two evils. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake Eliot Lear [EMAIL PROTECTED] Providing PI to enterprises who move now is a nice bonus, not not necessary in the long run. That comment shows how completely out of touch you are with the enterprise operational world. Unfortunately, that is rather common with the ivory-tower vendor folks commenting in this thread. Even the ISPs in the operational community could _understand_ why PI is necessary, however much they dislike and/or fear it. I should also note that you're commenting from an enterprise that side-stepped the RIR rules somehow and got PI space by pretending to be an LIR. The world must look a little different when the rules you're a proponent of magically don't apply to _you_. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
[elaborating] Stephen Sprunk wrote: Thus spake Eliot Lear [EMAIL PROTECTED] Providing PI to enterprises who move now is a nice bonus, not not necessary in the long run. That comment shows how completely out of touch you are with the enterprise operational world. Unfortunately, that is rather common with the ivory-tower vendor folks commenting in this thread. Even the ISPs in the operational community could _understand_ why PI is necessary, however much they dislike and/or fear it. I should also note that you're commenting from an enterprise that side-stepped the RIR rules somehow and got PI space by pretending to be an LIR. The world must look a little different when the rules you're a proponent of magically don't apply to _you_. You've misunderstood my comment, and you don't know my history. I would like for enterprises to be able to have PI addresses. What I am saying is that the economics of IPv4 about to radically shift such that the cost of staying on IPv4 is going to inflate over time. As that happens the costs of moving to IPv6 begin to look attractive. It's like drilling for oil in America, to mangle an analogy of a colleague. Nobody needs to do it when the cost of oil is $18 a barrel, but the matter is considerably different at $80. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sun, Sep 16, 2007 at 12:17:21PM +1000, Mark Andrews wrote: On Sun, Sep 16, 2007 at 12:08:30AM +1000, Mark Andrews wrote: interestingly, some software vendors ship w/ license keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. I've always thought that practice to be STUPID. It was stupid 15 years ago and it is still stupid today. Yes I've had to renumber sites with keys tied to IP addresses. stupid or not, it exists and is not ammenable to automation. Why isn't it? It's just one more message for the management station to push out. notifcation sure... getting the other side to re-issue the license with the new IP's (which the MS has to figure out what they are on its own, wiht the kewl AI-based smarts that it has) - and then getting the new code installed/configured ... all under the automated hands of master control is a different set of considerations. Actually if they want to tie the licence to a address, a ULA would provide exactly the same level of assurance they get today and make it independent of PA renumber events. David is correct, scale does have its own set of renumbering problems. While i believe you, i think your confidence is based on some naieve assumptions. I'm not saying scale doesn't have problems. Automation however is the solution to those problems. That's why management stations were invented. automation can augment renumbering events, but until we have a fundamental change in architecture, renumbering will require human intervention and will always be disruptive. It doesn't take a change in architecture. We have the technology today to remove the need to tie anything to specific IP addresses. It just requires the willingness to use it. simple assertion does not make it so. perhaps we should make a checkli st and see which things meet your criteria. (my assertion that location/I D overload is built in to both IPv4 and IPv6 seems to be born out by the specs, documentation, and commentary over the past 25 years ... and tha t until one can cleanly seperate the two, that renumbering will be diffic ult should also be tested) I have provided TWO cases where renumbering is is difficult to automate - i'm sure i can find others. I beleive your claim (oblique as it may be) is that the DNS name is the long-term pers istant identifier... I tried to make that claim a decade ago and was persuade d (eventually) otherwise. Time to dig through the archives to see if tha t logic still holds true. Mark --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
On Sep 13, 2007, at 3:16 AM, Jari Arkko wrote: Roger, On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it ... The question on the table (and also part of 6man charter) is whether we need an additional type of ULAs, one that is centrally allocated. Such addresses might be useful for a couple of reasons. One reason is that we could guarantee uniqueness, which might be important, e.g., for a company that is running a lot of small company networks as a business, and wants to ensure the address spaces do not collide. But another, more important stated reason was that we should have a way give people address space that is different from PI in the sense that those addresses are not recommended to be placed in the global routing table. Arguments against such address space relate to the following issues: - The costs for any centrally allocated space are likely going to be the same, so what is the incentive for the customers to allocate ULA-C instead of PI? - There is no routing economy that would push back on advertising more than the necessary prefixes, so what is the incentive that keeps the ULA-C out of the global routing table as years go by? (When the companies that allocated ULA-C grow, merge, need to talk with other companies, etc.) The end result of our discussions was that we clearly do not have agreement on the way forward, and we settled for writing a draft about the issues instead. That is still in the works. I'm just catching up with this thread today: If I summarize my understanding from the above in one sentence: there seems a perceived difference between PI and ULA-C prefixes, which, as far as I can see, does not exist. Whether a unique prefix is/not globally routable is determined by whether it gets injected into the routing system, no matter how it is labeled. Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Lixia, I'm just catching up with this thread today: If I summarize my understanding from the above in one sentence: there seems a perceived difference between PI and ULA-C prefixes, which, as far as I can see, does not exist. Whether a unique prefix is/not globally routable is determined by whether it gets injected into the routing system, no matter how it is labeled. Right. Or we can try to label it, but that labeling may not correspond to what is actually done with it. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sat, Sep 15, 2007 at 12:06:26PM +1000, Mark Andrews wrote: Mark, I get renumbered in IPv4 today. I suspect there is probably a question of scale here. I wouldn't be surprised that a small home network with a limited number of subnets and systems could be automatically renumbered. I would be surprised if a network of any appreciable size could be. Particularly one that has non-trivial relationships with other networks. How many subnets and devices are there on the network you automatically renumber? Regards, -drc The point was to demonstrate that it can be done. It just requires people to be willing to do this. On a home network you do most of the things by hand. In a enterprise you use a network management station to do the work for you. Having that management station send out notifications to third parties is really not a big ask. Mark interestingly, some software vendors ship w/ license keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. then there is the thorny DNS problem of updating the root hints file. If DNS is so automated, why is this still a big problem? (noting that the legacy address for B is still getting 300qps, nearly three YEARS after it was turned down) David is correct, scale does have its own set of renumbering problems. While i believe you, i think your confidence is based on some naieve assumptions. --bill -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
interestingly, some software vendors ship w/ license keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. I've always thought that practice to be STUPID. It was stupid 15 years ago and it is still stupid today. Yes I've had to renumber sites with keys tied to IP addresses. then there is the thorny DNS problem of updating the root hints file. If DNS is so automated, why is this still a big problem? (noting that the legacy address for B is still getting 300qps, nearly three YEARS after it was turned down) Once we get the root, net and root-server.net signed, writing out new hints is can be done with a high degree of assurance that the contents reflect reality. Sure there will still be old boxes that continue to try to talk to B but the new boxes won't and eventually all the old boxes will go, due to component failure if nothing else. David is correct, scale does have its own set of renumbering problems. While i believe you, i think your confidence is based on some naieve assumptions. I'm not saying scale doesn't have problems. Automation however is the solution to those problems. That's why management stations were invented. Mark --bill -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
At 12:08 AM +1000 9/16/07, Mark Andrews wrote: interestingly, some software vendors ship w/ license keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. I've always thought that practice to be STUPID. It was stupid 15 years ago and it is still stupid today. The fact that you as an individual thing it is stupid (in uppercase or lowercase) is irrelevant. Several large vendors disagree with you. Their customers have gotten used to dealing with this and do not consider it so onerous as to change to the other large vendors who use a different licensing scheme. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 15-sep-2007, at 16:51, Paul Hoffman wrote: keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. I've always thought that practice to be STUPID. It was stupid 15 years ago and it is still stupid today. The fact that you as an individual thing it is stupid (in uppercase or lowercase) is irrelevant. Several large vendors disagree with you. Their customers have gotten used to dealing with this and do not consider it so onerous as to change to the other large vendors who use a different licensing scheme. If we can't agree that this practice is stupid, can we at least agree that we can't let this impose restrictions on what we can and can't do within the IETF? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
At 5:08 PM +0200 9/15/07, Iljitsch van Beijnum wrote: On 15-sep-2007, at 16:51, Paul Hoffman wrote: keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. I've always thought that practice to be STUPID. It was stupid 15 years ago and it is still stupid today. The fact that you as an individual thing it is stupid (in uppercase or lowercase) is irrelevant. Several large vendors disagree with you. Their customers have gotten used to dealing with this and do not consider it so onerous as to change to the other large vendors who use a different licensing scheme. If we can't agree that this practice is stupid, can we at least agree that we can't let this impose restrictions on what we can and can't do within the IETF? Certainly. Every vendor who ties a license to an IP address has already had to deal with customers who change IP addresses. I doubt that Bill's mentioning of this practice was meant to say therefore we can never do anything that would cause renumbering. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sat, 15 Sep 2007, Paul Hoffman wrote: Certainly. Every vendor who ties a license to an IP address has already had to deal with customers who change IP addresses. I doubt that Bill's mentioning of this practice was meant to say therefore we can never do anything that would cause renumbering. On the other hand, if you develop a system that forces enterprises to renumber, then you GUARANTEE that a large set of them will find a way to avoid (or at least take control of their own) renumbering, e.g. NAT --for many reasons that have already been cited in this thread, and some that have not been. Example: Fred mentioned that it would be nice to just use some form of host names, instead of addresses, but in the world I live in, MANY groups are geographically dispersed and want Traffic Disruption Appliances on each of their subnets to allow unrestricted flow among their *blocks* of addresses --they certainly would not want to either a) manage large lists of explicit host addresses *or* names, or b) change their complex firewall rules whenever someone sez let's do the Renumber Drill! (Is that perimeter protection model fundamentally flawed? Of course it is, just like NAT is. Both observations will not change the reality of their continued use. The question should be: what will? Note also, for fans of homogeneous networks and single network management stations, that a single AS may have hundreds of autonomous management domains within it. As others have said, this is not entirely a technology problem. -teg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 15-sep-2007, at 18:42, Terry Gray wrote: Example: Fred mentioned that it would be nice to just use some form of host names, instead of addresses, but in the world I live in, MANY groups are geographically dispersed and want Traffic Disruption Appliances on each of their subnets to allow unrestricted flow among their *blocks* of addresses --they certainly would not want to either a) manage large lists of explicit host addresses *or* names, or b) change their complex firewall rules whenever someone sez let's do the Renumber Drill! [...] As others have said, this is not entirely a technology problem. Usually the reason for that is that the technology isn't good enough to solve the problem fully, which may or may not be a fundamental, unsolvable issue. As far as making IP addresses less visible than they are today, I think there is a lot we can do. My day job involves creating router configurations (in networks that aren't large enough to have sophisticated management systems). I have to put addresses rather than names in router configurations because when there is trouble with the network, it may not be possible to ask the DNS to translate a name into an address. (And there's the security issues.) The way the DNS works today is that you ask it for a mapping, and it returns you that mapping along with a time to live value. After that, you need to forget the mapping and consult the DNS again. A system that would work much better in router/firewall/etc configurations is a system where you may ask the name resolving system for a mapping to get you started, but once you have your mapping, you get to keep it until the name resolving system contacts YOU and tells you something has changed. Such a name resolving system would have to be under explicit administrative control, so that when my vendor that needs access to something deep inside the firewalled core of my network changes his/ her address I as an administrator get to see that and execute a policy (verify certificates, make a phone call, change vendors). The issue of unreachable root servers etc becomes moot because in that case you just keep running with the existing mapping information. Working with names is much easier than with addresses because you can easily allow *.example.com rather than all the individual addresses/ prefixes that Example, Inc uses around the world. blah.vendors.example.com could also point to mothership.blah.com so you only need to allow *.vendors.example.com rather than a long list of vendors. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sun, Sep 16, 2007 at 12:08:30AM +1000, Mark Andrews wrote: interestingly, some software vendors ship w/ license keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. I've always thought that practice to be STUPID. It was stupid 15 years ago and it is still stupid today. Yes I've had to renumber sites with keys tied to IP addresses. stupid or not, it exists and is not ammenable to automation. David is correct, scale does have its own set of renumbering problems. While i believe you, i think your confidence is based on some naieve assumptions. I'm not saying scale doesn't have problems. Automation however is the solution to those problems. That's why management stations were invented. automation can augment renumbering events, but until we have a fundamental change in architecture, renumbering will require human intervention and will always be disruptive. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sun, Sep 16, 2007 at 12:08:30AM +1000, Mark Andrews wrote: interestingly, some software vendors ship w/ license keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. I've always thought that practice to be STUPID. It was stupid 15 years ago and it is still stupid today. Yes I've had to renumber sites with keys tied to IP addresses. stupid or not, it exists and is not ammenable to automation. Why isn't it? It's just one more message for the management station to push out. David is correct, scale does have its own set of renumbering problems. While i believe you, i think your confidence is based on some naieve assumptions. I'm not saying scale doesn't have problems. Automation however is the solution to those problems. That's why management stations were invented. automation can augment renumbering events, but until we have a fundamental change in architecture, renumbering will require human intervention and will always be disruptive. It doesn't take a change in architecture. We have the technology today to remove the need to tie anything to specific IP addresses. It just requires the willingness to use it. Mark --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sun, Sep 16, 2007 at 12:17:21PM +1000, Mark Andrews wrote: On Sun, Sep 16, 2007 at 12:08:30AM +1000, Mark Andrews wrote: interestingly, some software vendors ship w/ license keys tied to IP addresses... particularly for enterprise level stuff. not so easy to update in my experience. I've always thought that practice to be STUPID. It was stupid 15 years ago and it is still stupid today. Yes I've had to renumber sites with keys tied to IP addresses. stupid or not, it exists and is not ammenable to automation. Why isn't it? It's just one more message for the management station to push out. notifcation sure... getting the other side to re-issue the license with the new IP's (which the MS has to figure out what they are on its own, wiht the kewl AI-based smarts that it has) - and then getting the new code installed/configured ... all under the automated hands of master control is a different set of considerations. David is correct, scale does have its own set of renumbering problems. While i believe you, i think your confidence is based on some naieve assumptions. I'm not saying scale doesn't have problems. Automation however is the solution to those problems. That's why management stations were invented. automation can augment renumbering events, but until we have a fundamental change in architecture, renumbering will require human intervention and will always be disruptive. It doesn't take a change in architecture. We have the technology today to remove the need to tie anything to specific IP addresses. It just requires the willingness to use it. simple assertion does not make it so. perhaps we should make a checklist and see which things meet your criteria. (my assertion that location/ID overload is built in to both IPv4 and IPv6 seems to be born out by the specs, documentation, and commentary over the past 25 years ... and that until one can cleanly seperate the two, that renumbering will be difficult should also be tested) I have provided TWO cases where renumbering is is difficult to automate - i'm sure i can find others. I beleive your claim (oblique as it may be) is that the DNS name is the long-term persistant identifier... I tried to make that claim a decade ago and was persuaded (eventually) otherwise. Time to dig through the archives to see if that logic still holds true. Mark --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
From: Tony Li [EMAIL PROTECTED] As a practical matter, these things are quite doable. Tony, my sense is that the hard part is not places *within one's own organization* where one's addresses are stored, but rather in *other organizations*; e.g. entries in *their* firewalls. Can those with experience confirm/deny this? In fact, in one of the global IPv4 networks that we operate, ACLs are managed just as Tony describes. However, when we need to add/change ACLs, it takes roughly 90 days to roll it out for two reasons. One is that we cannot risk changing all routers at one time, so we spread the work over two or more weekends. But the major piece of work is getting the change in customer firewalls. This requires notification, planning on their side, scheduling of their own change windows, etc. All of the human effort involved in doing this has real costs. At the same time, we and our customers will instantly make changes to routing in our networks without any notification or planning or scheduling of change windows. The difference is that routing is handled by BGP (and OSPF) which everybody trusts to do the right thing. A lot of smart people have put a lot of work into building routing protocols that are reliable. The same amount of brainpower and work has not been applied to ACL management in routers or firewalls. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
* Mark Andrews: Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. It's not possible to automatically renumber firewall configurations in different administration domains (quite deliberately so), and you can't take your mail reputation with you (at least not completely). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Jari Arkko wrote: Sure. But I understood Michael has nothing now, so from his point of view its a question of getting either PI from ARIN or PA from his provider. No, it's PI from ARIN, or PA from *some* provider. My immediate need is for space which is unique, and has whois and reverse map. I don't need it to be routeable today. But, sh*t happens, and we notice that eventually, everything needs some reachability to places you didn't expect. I expect to need tunnels in some places to get routeable IPv6 into places where there is none. I can get address space from existing IPv6 tunnel brokers, but in the long term, this may be unsustainable, since I expect to push some significant traffic. In any case, I expect to put equipment in places where there is presently no IPv6, so a tunnel will become necessary anyway. A /48 is pretty damn big, but if I have to get another /48 (in PA space), and break aggregation to announce it wherever I can, I may do that. I could also use many /64s in data centres that are IPv6 ready, however, this may complicate things. The tunnels between data centres *may* be layer-2 tunnels to permit the (virtual) hosts to migrate. There are scaling issues with this, and MIPv6 might be a better solution. This is more than a year away. I have presently acquired enough address space from another place to permit me to continue work. I thought that asking ARIN first made more sense. marshall I fully agree here. In fact, I would say that IPv6 will have truly marshall succeeded when business requests start coming in marshall that do _not_ want IPv4 space. This should be encouraged, not marshall discouraged. I'm here. I'm bit more clueful about ARIN process than average. Most businesses would have no idea what to do once ARIN said no. Or, they'd just lie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Jun-ichiro itojun Hagino wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? Each of my Sandelman/Xelerance locations switch ISPs about every 3-4 years. There are presently 5 such locations, so there is a renumber about every year. I am about to renumber my SOHO, which is an IPv4/25 in in PA space. Ironically, my IPv6, which comes through a tunnel, won't need to be renumbered. (One of the reasons I liked Tony Hain's geographical assignment. Tunnels don't bother me) In IPv6, we would be quite happy to always have two IPs on every host (even though Linux does source address selection poorly, Itojun's code in BSD does very well). One PI-ish address which never has to change, which is kinda-site-local, but might not get ultra-high-bandwidth, and one PA-ish address which is much faster. PI addresses don't have to imply centralized NAT to get out. We can do it in the hosts instead... That's nicely what shim6 is doing, hmm. Renumbering is not fun. IPv6 doesn't make it easier, since the DNS dynamic update stuff never really got fully implemented. (specified, yes, I think) Wearing my XDS hat, the company survives entirely using rfc1918 internally, with a dozen IPv4 NATs + VPNs. We use all of 192.168.0.0/16 for enterprise production. Testing occurs in 10.x. This leaves 172.16/20 for my customer facing networks. Not enough, so I will have to re-use addresses. Thus my interest in IPv6. Using a single prefix massively simplifies the VPNs. That's why enterprises want a single PI-ish prefix. The shim6 multiple address possibilities is one reason why I'm vague about whether or not I need to multi-home my address space. I suspect that I *won't* need to in the end -- I'll be able to use shim6. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
* Mark Andrews: Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. It's not possible to automatically renumber firewall configurations in different administration domains (quite deliberately so), and you can't take your mail reputation with you (at least not completely). Actually it is. You just are not willing to do it. It is 100% possible to do this automatically. It just requires the chains of trust to be setup. If you live in a dynamic world, you setup those chains. Just don't say that renumbering can't be automated because it can. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. It's not possible to automatically renumber firewall configurations in different administration domains (quite deliberately so), and you can't take your mail reputation with you (at least not completely). Actually it is. You just are not willing to do it. It is 100% possible to do this automatically. It just requires the chains of trust to be setup. you seem to be thinking that this is a purely technical problem. it's not. and there are valid reasons for keeping humans in the loop, and slowing things down, when trust is involved. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Well... you seem to be thinking that this is a purely technical problem. it's not. I can go there, on this point ... and there are valid reasons for keeping humans in the loop, and slowing things down, when trust is involved. ... and i can go that direction, on this point, but not all the way there. It is possible to keep a human in the loop without doing so in real time. As Michael pointed out, we trust BGP4 with a lot (see the many NANOG presentations on why this can be exciting, but we do), for many networks, including the largest networks. BGP4 does involve humans, because you can't do policy-based routing and policy-based traffic engineering without a human telling BGP4 yes, that WOULD be the shortest path, but don't use it for THIS traffic because of economic reason X. But once humans tell BGP4 what the policy is, we pretty much trust the protocol to do the right thing in selecting paths out of an AS, reflecting current connectivity, without human involvement, until something goes breathtakingly wrong. At least, that's the way it seems to me. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
Actually it is. You just are not willing to do it. It is 100% possible to do this automatically. It just requires the chains of trust to be setup. If you live in a dynamic world, you setup those chains. Just don't say that renumbering can't be automated because it can. You repeatedly wave your hands and say that it can be done but you refuse to provide a single reference to a protocol or implementation which makes this possible. The reason people are arguing against you is because we do not know of a case study where this is successfully being done. We don't know of any software which is successfully being used to renumber firewalls. Please point us to specific references, conferences, case studies, RFCs, etc. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
* Mark Andrews: It's not possible to automatically renumber firewall configurations in different administration domains (quite deliberately so), and you can't take your mail reputation with you (at least not completely). Actually it is. You just are not willing to do it. Our customers and business partners aren't willing to do this. Even ICANN doesn't allow it as an execuse would be essentially correct. It is 100% possible to do this automatically. It just requires the chains of trust to be setup. Yeah, and this chain of trust is simply not there, otherwise there wouldn't be firewalls in the first place, just VPNs. Just don't say that renumbering can't be automated because it can. Sure, using proprietary protocols and whatnot. Rather Utopian if each customer buys from a different vendor. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. It's not possible to automatically renumber firewall configurations in different administration domains (quite deliberately so), and you can't take your mail reputation with you (at least not completely). Actually it is. You just are not willing to do it. It is 100% possible to do this automatically. It just requires the chains of trust to be setup. you seem to be thinking that this is a purely technical problem. it's not. and there are valid reasons for keeping humans in the loop, and slowing things down, when trust is involved. Actually I doubt that there really are valid reasons other than to initiate the change. You can send the notification of change automatically. It can be acknowledge automatically. Whether it is approved at the other site automatically doesn't matter. You can even send reminders automatically only escalating to humans when there is a failure to respond after a period of time. We automate similarly trust relationships all the time. I've added/removed prefix value. Please update your firewall to reflect this. This is not a hard message to send automatically. To process automatically. To acknowledge that the change has been performed automatically. It's a update to a existing relationship. Mark Keith -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Actually it is. You just are not willing to do it. It is 100% possible to do this automatically. It just requires the chains of trust to be setup. =20 If you live in a dynamic world, you setup those chains. =20 Just don't say that renumbering can't be automated because it can. You repeatedly wave your hands and say that it can be done but you refuse to provide a single reference to a protocol or implementation which makes this possible. The reason people are arguing against you is because we do not know of a case study where this is successfully being done. We don't know of any software which is successfully being used to renumber firewalls. Please point us to specific references, conferences, case studies, RFCs, etc. I get renumbered in IPv4 today. I have my dhcp client fire off a reconfig script. That script * reconfigures the IPv6 tunnel to use the new address. It does *both* ends. * It notifies all the remote parties that need to know thar the remote address has changed as they need to change configuration details. Thise includes getting firewalls updated and DNS servers updated. Yes it is ad-hoc but it also proves that it can be done. I'm lazy. I have better things to do that type email notices whenever my IP address changes. Historically that is every 3-6 months. Mark --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark, I get renumbered in IPv4 today. I suspect there is probably a question of scale here. I wouldn't be surprised that a small home network with a limited number of subnets and systems could be automatically renumbered. I would be surprised if a network of any appreciable size could be. Particularly one that has non-trivial relationships with other networks. How many subnets and devices are there on the network you automatically renumber? Regards, -drc The point was to demonstrate that it can be done. It just requires people to be willing to do this. On a home network you do most of the things by hand. In a enterprise you use a network management station to do the work for you. Having that management station send out notifications to third parties is really not a big ask. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. I prefer losing some bytes in all my packets between locations using different ULA-D prefixes to get an underlying VPN / tunneling infrastructure. This allows me to keep things flat, i.e. pure routing. itojun, let's just stop using the 3 letters word. It does not exist anymore. is it ULA, NAT, VPN or all of them :-) itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
Paul Vixie wrote: http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it from all getting routed anyway. while that's not an unreasonable fear, i'm alone in considering it a manageable risk. I'm afraid I'll have to leave you alone there. [RIR-PI] makes [ULA-GLOBAL-00] somehow palatable, but not enough. In a nutshell, your argument is that since [RIR-PI] has been adopted, there is little risk that [ULA-GLOBAL-00] degenerates into free-for-all PI. That's a valid point, but IMHO the problem is that [RIR-PI] is not good enough in too many eyes; in other words there still are many remaining temptations to abuse [ULA-GLOBAL-00]. so while i harken to your concern that IPv6 will never fly, i think that the reasons for it are much larger than whatever part you think ARIN could do differently. Agree. Michel Py wrote: The real world would probably go for IPv6 NAT instead, but the IETF is deadlocked; instead of choosing between the lesser of two evils and sacrifice one of the features, they want to have the cake and eat it too. Paul Vixie wrote: ietf said don't do nat in v4. the market said screw you. The market won, and ietf ended up having to add nat support into various protocols, and started having nat oriented working groups, and so on. i expect the same with nat v6. I agree, but my point was that the market might prefer double-v4NAT to IPv6 NAT. The situation is quite different: IPv4 NAT solved most of the renumbering issue. IPv6 NAT does not bring anything to the table that IPv4 NAT does not already have. In other words: if you want NAT, no point upgrading to IPv6. i have more confidence in the ability of router vendors to bend moore's law and in backbone architects and routing protocol architects to bend graph theory, than i have for example in diesel-from-algae as a way to solve the world's carbon problem. so i'm not nec'ily hopeful, but i'm more hopeless about other things than i am about a 2M-route DFZ. Agree too, but as you said above the reasons are much larger. In other words, even if vendors promised a 10M DFZ capable routers and the RIRs gave PI to anybody who asks for it, we would still be nowhere near take off. Roger Jørgensen wrote: are they still refusing to put it into the queue or do anything? Even after several month? Well let really hope that will change now when/if IPv6-wg change the name to 6man and we can start working again! A few months are very little time in IETF time! Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 9/13/07, Jun-ichiro itojun Hagino [EMAIL PROTECTED] wrote: http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. did you read the thread some months ago? There was mention ID and LOC splitting. ULA fits that idea almost perfect. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. did you read the thread some months ago? There was mention ID and LOC splitting. ULA fits that idea almost perfect. IP address, or part of it, can never be an ID. so i'm against of all of the ID/LOC separation stuff. IP address can never be an identifier because: - you can switch from one IP version to another - once you have private address/ULA of some sort, you have conflicts it is a crazy thought that you have a unique ID in the lower 64 bit in an IPv6 address. MAC address is indeed not unique - some vendors do not keep the rules. go down to hongkong/akihabara and buy cheap NE2000 ethernet cards, and you'll know. if you need to identify some node/whatever, use ssh secret key, X509 certs, and alike. IP address is just to specify communication endpoint, nothing else. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 12, 2007, at 10:57 PM, Noel Chiappa wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. This perspective is soluble, but it's not the perspective that we seem to approach the problem from. We also don't have the solution in hand today, but work towards it would be greatly accelerated by backing away from our long-standing positions, terminologies and arguments and truly focusing on the problem at hand. Regards, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
Roger Jørgensen wrote: did you read the thread some months ago? There was mention ID and LOC splitting. ULA fits that idea almost perfect. ID/LOC has been discussed for 11 years and canned several times. http://arneill-py.sacramento.ca.us/ipv6mh/draft-odell-8+8-00.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. One of the best ways to get these things fixed would be for the router/firewall/... companies to actually switch between prefixes on a regular (monthly initially) basis. This of course assumes that they are using their own products. Can my firewall be reconfigured just by adding/deleting a prefix? Can my router be reconfigured just by adding/deleting a prefix? Can my ... Similarly multi-home some sites out of PA space and regularly break connectivity on to one or more providors. Nothing like doing to work out the bugs is the system. Mark Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Michael, Here's a decision table for you: 1. Do you need addresses that are routable from the global Internet, from anywhere? (Its not clear to me that you do, because you only need to do that within your own network and a couple of well known external sites perhaps.) a. If not, maybe you should look at ULAs. RFC 4193 allows you to get these addresses randomly, and you do not need to ask permission from anyone to do it. You could have your addresses today if you wanted to. b. Proposals have been floated about non-random ULAs as well. Right now we do not have one, but I'm not sure you need this for your particular case. 2. If you do need addresses that are routable, is it sufficient for you to work with provider-aggregated addresses that you get from your ISP (not from ARIN)? If yes, get the addresses and use them! 3. If you do need addresses that are routable AND you have multiple ISP connections and want to stay away from an address renumbering if you need to change ISPs, then you need PI. You are starting to get PI space, but as numerous PI items in the global routing table cause pain for routers, this will likely be available only for larger enterprises. There is ongoing work to try to design a better routing system that would be capable of keeping tens of millions of prefixes or more, in the IRTF. If and when that work succeeds, it would be possible to allocate everyone their own PI prefix. We are not there yet. In any case, FWIW, I think it would make sense for RIR address allocation rules to allow IPv6-only operations and not just those that need both IPv4 and IPv6 address space. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark, Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. You must have access to technology that at least I'm not aware of. We can automate some parts of the process, like hosts can get new addresses via RA, DHCP, and we have some tools for renumbering routers. But what about addresses embedded in firewall configs, applications, DNS, etc? Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. if the management needs to be convinced by the cost, i would suggest ISPs to price PI advertisement like hell ($$$), so that we can make the worldwide routing table smaller. it will help ISPs use smaller peering routers in the end. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Thu, Sep 13, 2007 at 04:05:09PM +0900, Jun-ichiro itojun Hagino wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. OK, I'll bite. Never, and never (in nearly 20 years). Although we in effect have IPv4 PI as being an older university we came online when getting an old Class B was easy, before IP allocations were made from the NREN space. We have renumbered our IPv6 networking as part of experimental/research work (and would from that experience certainly say fully automated renumbering is not possible today), but that was just an academic (and very interesting) exercise. If IPv6 PI were available to us we'd use it because it costs us no extra to do so. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Roger, On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it are they still refusing to put it into the queue or do anything? Even after several month? Well let really hope that will change now when/if IPv6-wg change the name to 6man and we can start working again! For the record, we had a series of discussions among authors, Paul, experts, etc on the ULA topic right after IETF-69 to try to see if we can sort out what the problems are and move forward. For background, we already have ULAs than can be allocated by the sites themselves. These are defined in RFC 4193. The question on the table (and also part of 6man charter) is whether we need an additional type of ULAs, one that is centrally allocated. Such addresses might be useful for a couple of reasons. One reason is that we could guarantee uniqueness, which might be important, e.g., for a company that is running a lot of small company networks as a business, and wants to ensure the address spaces do not collide. But another, more important stated reason was that we should have a way give people address space that is different from PI in the sense that those addresses are not recommended to be placed in the global routing table. Arguments against such address space relate to the following issues: - The costs for any centrally allocated space are likely going to be the same, so what is the incentive for the customers to allocate ULA-C instead of PI? - There is no routing economy that would push back on advertising more than the necessary prefixes, so what is the incentive that keeps the ULA-C out of the global routing table as years go by? (When the companies that allocated ULA-C grow, merge, need to talk with other companies, etc.) The end result of our discussions was that we clearly do not have agreement on the way forward, and we settled for writing a draft about the issues instead. That is still in the works. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. I don't believe that for a millisecond. There are way too many places that IP addresses creep into the configuration of components from layer 3 all the way to layer 7 (and beyond). The idea that people shouldn't do that is just religion, and not a widely-held religion. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Hear, hear. We're making binary claims in a grey-scale world of economics. Put the costs on the table and let the enterprises and ISPs fight out PI/PA. - Ralph On Sep 13, 2007, at Sep 13, 2007,5:27 AM, Jun-ichiro itojun Hagino wrote: my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. if the management needs to be convinced by the cost, i would suggest ISPs to price PI advertisement like hell ($$$), so that we can make the worldwide routing table smaller. it will help ISPs use smaller peering routers in the end. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. if the management needs to be convinced by the cost, i would suggest ISPs to price PI advertisement like hell ($$$), so that we can make the worldwide routing table smaller. it will help ISPs use smaller peering routers in the end. itojun Hear, hear. We're making binary claims in a grey-scale world of economics. Put the costs on the table and let the enterprises and ISPs fight out PI/PA. - Ralph The only problem I have with that is that the market tends to not be very foresighted - it will happily lead itself into a corner from which escape is quite difficult. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark Andrews wrote: On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. Oh man, that's rich. Do you actually believe that? I think you forgot to set your alarm clock and are living in that dream world that I mentioned previously. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. OK, I'll bite. Never, and never (in nearly 20 years). Although we in effect have IPv4 PI as being an older university we came online when getting an old Class B was easy, before IP allocations were made from the NREN space. i would like to hear more opinion from organizations that have connected to the internet more recently. the problem i'm seeing in the ietf is (of course there are exceptions): - vocal people have class B/C for their own use so they are not really feeling the pain of NAT (and they are contributing to the bigger size of the routing table) - vocal people are not using IPv6 daily itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Noel Chiappa wrote: In the enterprise world, where I live now, IPv6 is just flat out a non-starter without PI space. Its just not even a discussion that's even useful to have, because the answer to IPv6 without PI is just No. Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. Just out of curiousity, how do the enterprises expect to exhange bits without ISP's? They will find ones that will, or they will start ones that will, or ones will start independently that will. And, yes, the entrenched ISP interests really should perceive that to be a business threat, because it is one. (I just realized that I mentioned nanog in my previous message...I'm so used to this discussion happening over there that I just assumed that was there this message was coming from. Regardless, the sentiments against PI space in IPv6 are very ISP-centric and just as ill-fated whether they're on ietf or nanog.) -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark, Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. You must have access to technology that at least I'm not aware of. We can automate some parts of the process, like hosts can get new addresses via RA, DHCP, and we have some tools for renumbering routers. But what about addresses embedded in firewall configs, applications, DNS, etc? For the DNS use UPDATE to update the address records. For firewall configs. See your firewall vendor. Very very applications need raw addresses. Use the DNS. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 3:05 AM, Jun-ichiro itojun Hagino wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. Based on the high volume, fairly small enterprises I deal with, roughly every 2 - 3 years. If the Internet and its costs are truly critical to an enterprise, then either cost of service or quality of service perturbations mean that switching is fairly likely with time (or, at least, this has been the case in the past). The biggest barrier to switching is typically legal, not technical. (Switching may require breaking contracts paying penalties.) I don't claim a representative sample, but it's a data point. Regards Marshall itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark Andrews wrote: On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: I believe that a more constructive assessment is that enterprises ar= e unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing= subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, =20 enterprises are not willing to buy into vendor lock. Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. Oh man, that's rich. Do you actually believe that? If you design the network for IPv6 and not just copy the IPv4 model. If you use the technology that has been developed over the last 20 years, rather than disabling it, yes it is possible. I think you forgot to set your alarm clock and are living in that dream world that I mentioned previously. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Hello, Jun-ichiro itojun Hagino [EMAIL PROTECTED] writes: because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. I prefer losing some bytes in all my packets between locations using different ULA-D prefixes to get an underlying VPN / tunneling infrastructure. This allows me to keep things flat, i.e. pure routing. itojun, let's just stop using the 3 letters word. It does not exist anymore. Cheers, a+ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
