Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
Paul Vixie wrote: i do. see, that is. because rapid renumbering wasn't a bilateral protocol requirement from day 1, renumbering will always be a crock of swill in ipv6 just as it is in ipv4. Ahem. On Day 1 -- that is SIP, for (Steve's) Simpler IP and my PIPE Practical IP Extentions [later BIP for (Bill's) Better IP] -- rapid renumbering *was* a protocol requirement! As was IP Mobility for those long-lived TCP connections. However, prefixes were always explicitly PI (provider independent). And multi-site enterprises had multiple prefixes within them. We talked about competition where providers could be switched on time of day with massive competition. Providers hated it (massive competition) and got another model adopted some years later. That model is a crock of swill 10 or so years after IPv4 deployment we started IPng. It's been another decade, past time for IPngng, although IPv6 sure hasn't had the deployment success of IPv4, has it ;-) Have we learned anything in 10+ years? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Consortium sheds light on dark fiber's potential
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.eetimes.com/showArticle.jhtml?articleID=53700951 regards, /vicky -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBpMpOpbZvCIJx1bcRAqFmAJ96505uhm2Ipg//JLYktUm59adqsQCgi1Hh mnOxyvTt188SnRmHtU5sBo8= =cdob -END PGP SIGNATURE-
Looking for ATT abuse_rbl contact
Can anyone who is or has a good contact at the abuse_rbl desk at att.net please contact me offlist? (This is regarding their email blacklists). [EMAIL PROTECTED], [EMAIL PROTECTED], and [EMAIL PROTECTED] are all known and have proved ineffective. Thank you in advance. --Campbell
RADB question
Just a quick question regarding RADB - how are you guys dealing with abuse complaints sent to the radb-notify or radb-maint e-mail addresses. I have some ideas but wanted to get a concensus from the commmunity ... Thoughts anyone ? Regards, Paul
Public Interest Networks (was: Re: Consortium sheds light on dark fiber's potential)
Vicky, I apologize if I am hijacking your thread. Is it just me or does all this talk of Research (and other Public Interest) Networks and logical separation by layer 1/2 leave [everyone] nonplussed? How is logical separation of a network [say via MPLS] much different than using a lambda to do the same thing? It seems kind of dumb to me that a network that is spending the money to buy capacity is selling a 2.5G or 10G wave to universities as any kind of improvement... I'm not even sure they could do it at a better price than a desperate telco that is selling the underlying fiber in the first place. Engineering idea: All the constituent folks do the same network, but build it as a single logical network, with say all 40x10G Lambdas on it. Everyone is given a 2.5G or 10G MPLS tunnel with the ability to use all unused bandwidth that is available on the network at that time... That would at least have some legs and create some value for having more membership. This smacks me as similar to Philadelphia wanting to deploy universal WiFi and charging $20-$25/month for it -- a free network to the city makes sense, afterall they pay taxes -- a psuedo-commercial service, what's the point? Do these government (and other so-called Public Interest) networks really make sense in the U.S. or is everyone still stuck in a timewarp when/where the NSFnet made sense because no one (commercially) could/would step up to perform the same function. Hopefully there is some operational content in there... If you don't see an on-list response from me, you probably know why. Deepak Jain AiNET Vicky wrote: http://www.eetimes.com/showArticle.jhtml?articleID=53700951
Re: Public Interest Networks (was: Re: Consortium sheds light on dark fiber's potential)
In message [EMAIL PROTECTED], Deepak Jain writes: Vicky, I apologize if I am hijacking your thread. Is it just me or does all this talk of Research (and other Public Interest) Networks and logical separation by layer 1/2 leave [everyone] nonplussed? How is logical separation of a network [say via MPLS] much different than using a lambda to do the same thing? Wearing my researcher hat, the answer depends on what sort of research you're trying to conduct. There are more things to do with a fiber than just running IPv4 over it. --Steve Bellovin, http://www.research.att.com/~smb
RE: ULA and RIR cost-recovery
Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. This argument is basically saying that the RIR membership knows it is forcing allocation policies that are counter to the market demand. The only way ULAs could be considered for grey market PI use is due to lack of any alternative mechanism to meet the real customer requirement for independence. The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Everyone acknowledges that the demand for PI space is real while simultaneously refusing to seriously deal with it (and the re-architecting of fundamental assumptions about the Internet effort of multi6, while serious, is not a short term solution). My to-do list for the next couple of weeks has an item to ask for a BoF at the next IETF on an interim moderately aggregatible PI approach. I cc'd the Internet ADs since this is as good a time as any to start the process. I have a proposal on the table, but I care more about a real solution than I do about that specific approach. At the same time I continue to get comments like: 'Your geographic addressing proposal (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty much ideal, really)', so it probably makes a good starting point for discussion. Tony
Re: RADB question
On Wednesday 24 November 2004 14:21, Paul Ryan wrote: Just a quick question regarding RADB - how are you guys dealing with abuse complaints sent to the radb-notify or radb-maint e-mail addresses. I have some ideas but wanted to get a concensus from the commmunity ... Thoughts anyone ? Regards, Paul Actually, we've been considering adding a privacy feature to mangle/hide these email addresses. We already do something similar with the CRYPT-PW password hashes to prevent password cracking. If folks feel this is important, we could up it on the priority list. -Larry Blunk Merit
Re: Public Interest Networks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Deepak! you raise some interesting points from bw standpoint. what really got me scratching my head is the fact that throwing bw to conserve computing power. in this cat and mouse game, mouse always wins :-) The OptiPuter project aims at learning how to 'waste' bandwidth and storage in order to conserve 'scarce' computing in this new world of inverted values, said Smarr. i'm not even sure why even implement mpls where latency/congestion is not an issue specially in this case or even talking about I2 for that matter. regards, /vicky Deepak Jain wrote: | Vicky, I apologize if I am hijacking your thread. | | Is it just me or does all this talk of Research (and other Public | Interest) Networks and logical separation by layer 1/2 leave [everyone] | nonplussed? | | How is logical separation of a network [say via MPLS] much different | than using a lambda to do the same thing? It seems kind of dumb to me | that a network that is spending the money to buy capacity is selling a | 2.5G or 10G wave to universities as any kind of improvement... I'm not | even sure they could do it at a better price than a desperate telco that | is selling the underlying fiber in the first place. | | Engineering idea: All the constituent folks do the same network, but | build it as a single logical network, with say all 40x10G Lambdas on it. | Everyone is given a 2.5G or 10G MPLS tunnel with the ability to use all | unused bandwidth that is available on the network at that time... That | would at least have some legs and create some value for having more | membership. | | This smacks me as similar to Philadelphia wanting to deploy universal | WiFi and charging $20-$25/month for it -- a free network to the city | makes sense, afterall they pay taxes -- a psuedo-commercial service, | what's the point? Do these government (and other so-called Public | Interest) networks really make sense in the U.S. or is everyone still | stuck in a timewarp when/where the NSFnet made sense because no one | (commercially) could/would step up to perform the same function. | | Hopefully there is some operational content in there... If you don't see | an on-list response from me, you probably know why. | | Deepak Jain | AiNET | | Vicky wrote: | | |http://www.eetimes.com/showArticle.jhtml?articleID=53700951 | | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBpOqspbZvCIJx1bcRAtonAJsH2dJLmQo+OpB5q/bcl/iOsCQt1wCeM+rQ sM0+tPS3yN+nCrl5y0iA7KM= =R/vP -END PGP SIGNATURE-
Re: ULA and RIR cost-recovery
In message [EMAIL PROTECTED], Tony Hain writes: My to-do list for the next couple of weeks has an item to ask for a BoF at the next IETF on an interim moderately aggregatible PI approach. I cc'd the Internet ADs since this is as good a time as any to start the process. I have a proposal on the table, but I care more about a real solution than I do about that specific approach. At the same time I continue to get comments like: 'Your geographic addressing proposal (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty much ideal, really)', so it probably makes a good starting point for discussion. The problem with this scheme is that it's only aggregatable if there's some POP that lots of carriers connect to in the proper geographic areas. What is the carriers' incentive to show up -- peer? -- at such points, rather than following today's practices? --Steve Bellovin, http://www.research.att.com/~smb
RE: ULA and RIR cost-recovery
--On Wednesday, November 24, 2004 11:40 -0800 Tony Hain [EMAIL PROTECTED] wrote: Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. This argument is basically saying that the RIR membership knows it is forcing allocation policies that are counter to the market demand. The only way ULAs could be considered for grey market PI use is due to lack of any alternative mechanism to meet the real customer requirement for independence. Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Everyone acknowledges that the demand for PI space is real while simultaneously refusing to seriously deal with it (and the re-architecting of fundamental assumptions about the Internet effort of multi6, while serious, is not a short term solution). This is absolutely not true. RIPE allocates /24s and smaller. I don't know APNICs current MAU. ARIN will allocate /22s and will probably consider smaller allocations either at the next meeting or the one after that. My to-do list for the next couple of weeks has an item to ask for a BoF at the next IETF on an interim moderately aggregatible PI approach. I cc'd the Internet ADs since this is as good a time as any to start the process. I have a proposal on the table, but I care more about a real solution than I do about that specific approach. At the same time I continue to get comments like: 'Your geographic addressing proposal (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty much ideal, really)', so it probably makes a good starting point for discussion. Agreed. I'd like to see a real solution that allows any organization that wants to multihome to get PI space or have us solve the underlying problems so that address portability becomes irrelevant (better, I think, in the long term). As I see it, IP Addresses are currently used for the following purposes: Destination Endpoint Identifier (resolvable by requiring a solid directory service) Source Endpoint Identifier (mostly doesn't matter when this changes) Source Endpoint Authentication (this is bad and we should be using something better that actually identifies the host (or better yet in most cases, user) in a meaningful way) Host authorization (Same issue(s) as previous statement) Portion of Service authorizatoin decisions (again, same issues as previous two) In the early days of the ipng working group, there was hope that v6 would solve these issues. Sadly, after rejecting TUBA because it didn't solve these things, v6 has devolved into a similar failure. Owen pgpKpQUOzhiLz.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. Do customers demand that their ISPs route RFC1918 addresses now? (And that's an honest question. I am not being sarcastic.) Wouldn't the IPv6 ULA answer be the same as the IPv4 RFC1918 answer, I could announce those networks for you, but no one else would accept the routes. (And I would be ridiculed straight off of NANOG.) I presume everyone will be filtering the ULA prefix(es), link local, loopback, and other obvious bogons from their tables. How does this enterprise demand that other providers route the ULA prefixes too? If we're talking about routing ULAs within a providers network, I'd think providers would love them. Right now, an enterprise can buy a corporate VPN or layer two network to route private addresses. Wouldn't providers be happy to offer the same service, for the same extra $$$, in IPv6? Especially when you consider that you can just drop the routes for the ULAs in your interior routing tables since ULAs are well, unique, and you're done. No tunnelling or other levels of indirection required. Charge the same or more for the business-level service that you offer now, but there is less work for you to do it. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
RE: ULA and RIR cost-recovery
Steven M. Bellovin wrote: ... The problem with this scheme is that it's only aggregatable if there's some POP that lots of carriers connect to in the proper geographic areas. What is the carriers' incentive to show up -- peer? -- at such points, rather than following today's practices? It doesn't require POPs per se, but that might be the simplest implementation. It does require some form of peering agreement for a service region which could be implemented with traditional transit arrangements. The incentive question is still open though. One incentive would be the trade-off against a routing swamp, but by itself that is probably not enough. Another incentive might be to stave off the recurring threat that the ITU/Governments could impose worse approaches. If I had an answer to the incentive question it would probably be easier to make progress. Tony
Re: Public Interest Networks (was: Re: Consortium sheds light on dark fiber's potential)
On Wed, 24 Nov 2004, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Deepak Jain writes: Vicky, I apologize if I am hijacking your thread. Is it just me or does all this talk of Research (and other Public Interest) Networks and logical separation by layer 1/2 leave [everyone] nonplussed? How is logical separation of a network [say via MPLS] much different than using a lambda to do the same thing? Wearing my researcher hat, the answer depends on what sort of research you're trying to conduct. There are more things to do with a fiber than just running IPv4 over it. yes, ipv6! :) Actually, some of the research networks seem to be places to test/eval new hardware, software, techniques and/or pass large datasets from lab to lab in larger collaborative projects. Often the faster/newer/sexier gear had been tested on these 'test' networks prior to deployments in the field. Steve is right though, it's not all ipv4 on the links...
RE: ULA and RIR cost-recovery
Owen DeLong wrote: --On Wednesday, November 24, 2004 11:40 -0800 Tony Hain alh- [EMAIL PROTECTED] wrote: Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. This argument is basically saying that the RIR membership knows it is forcing allocation policies that are counter to the market demand. The only way ULAs could be considered for grey market PI use is due to lack of any alternative mechanism to meet the real customer requirement for independence. Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. ULAs are clearly routable over whatever scope people decide to. This was also true of the SiteLocal prefix that ULAs are replacing. The only difference is that ULAs have explicit text to avoid routing ambiguity where SL didn't. I argued against deprecating SL partly on the basis that it had the potential for ambiguity which would be a disincentive for grey-market PI use. I understand and agree with your point about them being a potential problem, but that potential is easily mitigated by providing an economically viable alternative. The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Everyone acknowledges that the demand for PI space is real while simultaneously refusing to seriously deal with it (and the re-architecting of fundamental assumptions about the Internet effort of multi6, while serious, is not a short term solution). This is absolutely not true. RIPE allocates /24s and smaller. I don't know APNICs current MAU. ARIN will allocate /22s and will probably consider smaller allocations either at the next meeting or the one after that. None of the organizations that are getting long IPv4 allocations will qualify for an IPv6 prefix. There is an implicit concession that it is too late to close the barn door for IPv4, but for IPv6 it is currently locked tight by those that want to maintain control. My to-do list for the next couple of weeks has an item to ask for a BoF at the next IETF on an interim moderately aggregatible PI approach. I cc'd the Internet ADs since this is as good a time as any to start the process. I have a proposal on the table, but I care more about a real solution than I do about that specific approach. At the same time I continue to get comments like: 'Your geographic addressing proposal (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty much ideal, really)', so it probably makes a good starting point for discussion. Agreed. I'd like to see a real solution that allows any organization that wants to multihome to get PI space or have us solve the underlying problems so that address portability becomes irrelevant (better, I think, in the long term). Multi-homing is only one reason for PI space, and people get so hung up on that one that they forget that the simple ability to change providers without massive effort is just as important. As I see it, IP Addresses are currently used for the following purposes: Destination Endpoint Identifier (resolvable by requiring a solid directory service) Source Endpoint Identifier (mostly doesn't matter when this changes) Source Endpoint Authentication (this is bad and we should be using something better that actually identifies the host (or better yet in most cases, user) in a meaningful way) Host authorization (Same issue(s) as previous statement) Portion of Service authorizatoin decisions (again, same issues as previous two) In the early days of the ipng working group, there was hope that v6 would solve these issues. Sadly, after rejecting
Re: Public Interest Networks
you raise some interesting points from bw standpoint. what really got me scratching my head is the fact that throwing bw to conserve computing power. in this cat and mouse game, mouse always wins :-) The OptiPuter project aims at learning how to 'waste' bandwidth and storage in order to conserve 'scarce' computing in this new world of inverted values, said Smarr. i'm not even sure why even implement mpls where latency/congestion is not an issue specially in this case or even talking about I2 for that matter. Hmmm. Maybe I need to be a little more explicit in my concerns I am not concerned with the applications of the bandwidth that research folks are doing. Of course, research for research's sake has a value. I guess I meant... what is this interest in building a new network from scratch when all they are doing is using commercially available equipment provided by Cisco, and perhaps other vendors, etc? Regen is probably handled by the fiber vendors too... so where is the research in running a network?? Its trying to use the network as a service, of which, I am not sure there are many research interests that have more experience than the commercial folks. By mentioning MPLS or another tunneling technology, I didn't mean to imply IPV4. Indeed, I meant that you can encapsulate whatever you want on an underlying network, or if you need raw access to the optics, you can always order wavelengths... The idea of building a network like this seemed like reinventing a dirt road next to an existing superhighway. Likewise, with the Internet2 stuff, the underlying network is provided by commercial carriers... End equipment may be different, and that's the way it is with all commercial circuits today for standards-based communications/protocols.. So what is the value in dedicated research networks when the same facility can be provided by existing lit capacities by commercial networks? Is it a price delta? Or is it belief that the commercial folks don't meet the needs of the underlying applications? (if its the latter, I'd love to know what is being done). To hash this out even more In regards to regional academic networks, I completely understand that there are significant economies by operating as a single entity. The complexity of running dark fiber in a regional network isn't really bad at all, and capacity can be added in pretty dynamic increments. However, once you start expanding to connect regional networks to each, it seems that the complexity increases far faster than the benefits -- and where universal/commercial carriers seem to have the greatest value offering. What am I missing? (P.S. have a nice holiday). DJ
Re: ULA and RIR cost-recovery
--On Wednesday, November 24, 2004 12:52 -0800 Crist Clark [EMAIL PROTECTED] wrote: Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. Do customers demand that their ISPs route RFC1918 addresses now? (And that's an honest question. I am not being sarcastic.) Wouldn't the IPv6 ULA answer be the same as the IPv4 RFC1918 answer, I could announce those networks for you, but no one else would accept the routes. (And I would be ridiculed straight off of NANOG.) I presume everyone will be filtering the ULA prefix(es), link local, loopback, and other obvious bogons from their tables. How does this enterprise demand that other providers route the ULA prefixes too? Yes, they do. However, today, with RFC-1918, we can at least give them a good technology reason why not. With ULA, we have no such defense... There's simply no reason a unique prefix can't be routed. If we're talking about routing ULAs within a providers network, I'd think providers would love them. Right now, an enterprise can buy a corporate VPN or layer two network to route private addresses. Wouldn't providers be happy to offer the same service, for the same extra $$$, in IPv6? Especially when you consider that you can just drop the routes for the ULAs in your interior routing tables since ULAs are well, unique, and you're done. No tunnelling or other levels of indirection required. Charge the same or more for the business-level service that you offer now, but there is less work for you to do it. Right, but, the problem comes when the customers expect you to also announce the ULAs at your borders. Believe me, this will occur. It will probably start with Well, we've got this connection to you and this connection to ISP B, and, you guys peer, so, can you pass our ULA prefixes along to each other? The slippery slope will continue until market economics have blurred or completely erased the line between PI and ULA. Owen pgp2tXfIpfdBx.pgp Description: PGP signature
RE: ULA and RIR cost-recovery
Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. ULAs are clearly routable over whatever scope people decide to. This was also true of the SiteLocal prefix that ULAs are replacing. The only difference is that ULAs have explicit text to avoid routing ambiguity where SL didn't. I argued against deprecating SL partly on the basis that it had the potential for ambiguity which would be a disincentive for grey-market PI use. I understand and agree with your point about them being a potential problem, but that potential is easily mitigated by providing an economically viable alternative. I was also opposed to deprecating SL on the same basis. However, just because SL was deprecated doesn't make me think ULA is a good idea. If we're going to have PI space, we should have PI space. Dividing it up into multiple classes based on how much you paid to register it doesn't make sense to me. None of the organizations that are getting long IPv4 allocations will qualify for an IPv6 prefix. There is an implicit concession that it is too late to close the barn door for IPv4, but for IPv6 it is currently locked tight by those that want to maintain control. I don't believe that to be true. I think that a reasonable allocation policy for PI space in v6 would move forward in ARIN. I think that the recent adoption of 2002-3 and 2003-15 is evidence that the makeup and participation in ARIN has shifted. I also think that you underestimate the number of people who believe that PI space should be the norm, not the exception, and, that failure of v6 WG to address this in a meaningful way is not a good thing for v6 future. Multi-homing is only one reason for PI space, and people get so hung up on that one that they forget that the simple ability to change providers without massive effort is just as important. Changing providers without massive effort can be accomplished through a number of other methods. Multihoming is the more generic case. Failure is too strong a term, but it is true that work is not complete. The issue is many assumptions have been made at all layers of the system about the alignment of all those characteristics, so just ripping them out doesn't really solve anything more than the routing problem. Even if the multi6 follow-on groups come up with a technical approach that splits the functions, all the rest of the infrastructure will need to adapt and that will take much longer than rolling out IPv6. I do not believe that the v6 protocol will ever actually address those issues. Most of the necessary foundation for addressing them has been removed (A6, DNAME, mandatory autoconf). Agreed on the latter half, that's why I think that IPv6 should have addressed these early on and built those capabilities into the migration process. Adding them as hacks later has most of the disadvantages and reasons that they haven't been added to v4. That is why I chose the term failure. Making a change that intentionally breaks fundamental assumptions will meet much greater deployment resistance than something that intentionally minimized such changes. Call the intentional minimization a failure if you must, but from my perspective the only real failure will be to let the Internet collapse into something less capable of delivering end user services than X.25 was. Here, we probably end up agreeing to disagree. I think that we could have built v6 to break the fundamental assumptions in such a way that the impact of those breaks was minimized. Yes, there would be deployment resistance, but, I don't think significantly more than exists for current v6. Owen pgpdz1Q6Lbuar.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
On Wed, 24 Nov 2004 12:52:21 PST, Crist Clark said: Do customers demand that their ISPs route RFC1918 addresses now? (And that's an honest question. I am not being sarcastic.) Wouldn't the IPv6 No, they just emit the traffic anyhow. Often it travels an amazing distance before hitting a router that doesn't have a default route - and if it's one of those providers that internally routes 1918 addresses of their own it might go even further ;) ULA answer be the same as the IPv4 RFC1918 answer, I could announce those networks for you, but no one else would accept the routes. (And I would be ridiculed straight off of NANOG.) I presume everyone will be filtering the ULA prefix(es), link local, loopback, and other obvious bogons from their tables. How does this enterprise demand that other providers route the ULA prefixes too? More correctly, the same people who do proper bogon filtering for IPv4 will quite likely do it for IPv6, and the same people who botch it for IPv4 will almost certainly botch it worse for IPv6. Note that this has *quite* different operational semantics than everyone.. If we're talking about routing ULAs within a providers network, I'd think providers would love them. Right now, an enterprise can buy a corporate VPN or layer two network to route private addresses. One has to wonder if the first attempt to multihome a ULA will be accidental or intentional, or has it already happened? pgpRMPRZNnfCe.pgp Description: PGP signature
Re: large multi-site enterprises and PI prefix [Re: who gets a /32
[EMAIL PROTECTED] (William Allen Simpson) writes: Have we learned anything in 10+ years? yes. the best way to do something is to DO it. -- Paul Vixie
Re: Public Interest Networks (try UCLP)
Hi Deepak and Vicky, I can't resist comment even though at this point the additional questions that i can answer are very limited. For the past month I have been talking privately and more recently on a private mail list with folk at the heart of this. Canarie under Bill St Arnaud has been the global leader for more than the past five years. Tom Defanti and Joe Mambretti in chicago with the start tap and star light exchanges have been before National lambda rail (NRL) the main players in the US. NRL is perceived as quite important in that it will permit american universities to experiment with their own fiber and wavelength as the canadians have been with CA*Net4 for years. In Europe Kees neggers with Surfnet6 is doing the same thing. As I understand it Internet 2 and Dante/Geant in europe are primarily carrier dependent and therefore for the most part onlookers. NLR, Surfnet6, Ca*Net4 are or will be experimenting with User controlled light paths (UCLP). For more put UCLP in google. I interviewed Bill St Arnaud 2 weeks ago on UCLP. Here one of the purposes is to enable users at the edge to make connection oriented links between each other WITHOUT A CARRIER IN THE MIDDLE by partitioning a segment of a switch or switches between them. The concept is peer to peer and ad hoc. the goal is enabling customer owned and operated networks. As one of the players said on November 15th: UCLP is simply a layer 1 provisioning and configuration tool. Although we use lightpaths it is not restricted to optical networks. Although it seems paradoxical I am not a big believer in AON, ASON or optical networking in general. I think the big benefit of DWDM networks will be to increase the richness of meshing of IP networks and to allow new business models of IP networking to evolve e.g customer owned and managed IP networks. Web services is being used to set up the lightpaths. If there is sonet underneath the folk with access to webservices can groom the light path from a ds3 on up and with further software development can groom less than a ds3. This stuff is not yet well understood outside these research network circles. I believe that it is hugely important and I will be devoting most of my time in december and january to explaining to a broader audience what these folk are doing. to the world of the best effort public internet it is utterly ALIEN. but my understanding is that it works. NOW. That it is a walled garden and that a big unknown is how long it will remain a walled garden. Hmmm. Maybe I need to be a little more explicit in my concerns I am not concerned with the applications of the bandwidth that research folks are doing. Of course, research for research's sake has a value. I guess I meant... what is this interest in building a new network from scratch when all they are doing is using commercially available equipment provided by Cisco, and perhaps other vendors, etc? Regen is probably handled by the fiber vendors too... so where is the research in running a network?? Its trying to use the network as a service, of which, I am not sure there are many research interests that have more experience than the commercial folks. By mentioning MPLS or another tunneling technology, I didn't mean to imply IPV4. Indeed, I meant that you can encapsulate whatever you want on an underlying network, or if you need raw access to the optics, you can always order wavelengths... The idea of building a network like this seemed like reinventing a dirt road next to an existing superhighway. Likewise, with the Internet2 stuff, the underlying network is provided by commercial carriers... End equipment may be different, and that's the way it is with all commercial circuits today for standards-based communications/protocols.. So what is the value in dedicated research networks when the same facility can be provided by existing lit capacities by commercial networks? Is it a price delta? Or is it belief that the commercial folks don't meet the needs of the underlying applications? (if its the latter, I'd love to know what is being done). To hash this out even more In regards to regional academic networks, I completely understand that there are significant economies by operating as a single entity. The complexity of running dark fiber in a regional network isn't really bad at all, and capacity can be added in pretty dynamic increments. However, once you start expanding to connect regional networks to each, it seems that the complexity increases far faster than the benefits -- and where universal/commercial carriers seem to have the greatest value offering. What am I missing? (P.S. have a nice holiday). DJ -- = The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 415 651-4147 (Lingo) [EMAIL PROTECTED] Subscription info:
Re: ULA and RIR cost-recovery
At 07:32 PM 11/24/2004, [EMAIL PROTECTED] wrote: On Wed, 24 Nov 2004 12:52:21 PST, Crist Clark said: Do customers demand that their ISPs route RFC1918 addresses now? (And that's an honest question. I am not being sarcastic.) Wouldn't the IPv6 No, they just emit the traffic anyhow. Often it travels an amazing distance before hitting a router that doesn't have a default route - and if it's one of those providers that internally routes 1918 addresses of their own it might go even further ;) Seems to me we wrote a document some years ago about how to address this. If the upstream ISP isn't willing to filter at their edges, then write contract language that the client is required to filter such traffic in THEIR border routers. The typical customer with a few T-1 lines and some small routers could easily afford the CPU power in their routers to implement a few lines of ACL filtering. This sure seems like a weak reason to scuttle an otherwise useful and desired capability.
Re: ULA and RIR cost-recovery
At 07:11 PM 11/24/2004, Owen DeLong wrote: *** PGP SIGNATURE VERIFICATION *** *** Status: Good Signature from Invalid Key *** Alert:Please verify signer's key before trusting signature. *** Signer: Owen DeLong (General Purpose Personal Key) [EMAIL PROTECTED] (0x0FE2AA3D) *** Signed: 11/24/2004 7:12:03 PM *** Verified: 11/24/2004 9:57:11 PM *** BEGIN PGP VERIFIED MESSAGE *** --On Wednesday, November 24, 2004 12:52 -0800 Crist Clark [EMAIL PROTECTED] wrote: Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. Do customers demand that their ISPs route RFC1918 addresses now? (And that's an honest question. I am not being sarcastic.) Wouldn't the IPv6 ULA answer be the same as the IPv4 RFC1918 answer, I could announce those networks for you, but no one else would accept the routes. (And I would be ridiculed straight off of NANOG.) I presume everyone will be filtering the ULA prefix(es), link local, loopback, and other obvious bogons from their tables. How does this enterprise demand that other providers route the ULA prefixes too? Yes, they do. However, today, with RFC-1918, we can at least give them a good technology reason why not. With ULA, we have no such defense... There's simply no reason a unique prefix can't be routed. So with unique address blocks, blocks that should not appear in the GLOBAL routing table, companies could use those prefixes for private peering all over the place. This sounds like a great idea for companies cooperating in commerce operations. Of course all that private traffic might traverse a network that bypasses the ISPs and NSPs, or perhaps runs over private virtual circuits (MPLS, Frame, ATM or whatever the popular choice is for such circuits that month). While from a network operator's perspective, this might be a disaster, it's an enabler for corporate networks, and there's no reason to discourage it. If you are a network provider, then filter the entire prefix block and any longer prefixes announced. Please, though, stay out of the way of private interconnectors who've been asking for years to have unique space so they can reliably talk with one another. If we're talking about routing ULAs within a providers network, I'd think providers would love them. Right now, an enterprise can buy a corporate VPN or layer two network to route private addresses. Wouldn't providers be happy to offer the same service, for the same extra $$$, in IPv6? Especially when you consider that you can just drop the routes for the ULAs in your interior routing tables since ULAs are well, unique, and you're done. No tunnelling or other levels of indirection required. Charge the same or more for the business-level service that you offer now, but there is less work for you to do it. Right, but, the problem comes when the customers expect you to also announce the ULAs at your borders. Hey, it's your network, you set your policies. Believe me, this will occur. It will probably start with Well, we've got this connection to you and this connection to ISP B, and, you guys peer, so, can you pass our ULA prefixes along to each other? Talk to the other ISP, work out pricing, and sell an IP over IP solution, MPLS solution or some such. Look at this as an opportunity, instead of a problem, and there's money to be made without leaking the prefixes into the backbone. Embrace progress and conceive of creative solutions to customer needs. The slippery slope will continue until market economics have blurred or completely erased the line between PI and ULA. Well, giving in and letting companies have PI space would be nice, but unique ULA space would be extremely valuable, even to folks who REALLY do not need PI space.
Re: large multi-site enterprises and PI prefix [Re: who gets a /32
On Thu, 2004-11-25 at 01:48 +, Paul Vixie wrote: [EMAIL PROTECTED] (William Allen Simpson) writes: Have we learned anything in 10+ years? yes. the best way to do something is to DO it. According to Nike it is to Just do it, but that is probably not the correct way and might lead to problems later on ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
