Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, 2004-11-29 at 18:02 -0800, Owen DeLong wrote: Instead of hacking the nice and working TCP we have now you should move on to greener grass and use SCTP instead. It does what you want, at least in the specification. I don't know how many implementors have managed to code it properly. Please point me to where I can get a version of SSH that uses SCTP instead of TCP and talks to the existing SSHD services using TCP with flow survivability. If the TCP library changes underneath SSH and provides this capability, it will get deployed. If we need to completely rewrite all the applications to support TCP and SCTP in some sort of split-brained idea of how the world should work, then, adoption is less likely. It is called *OPEN*ssh in most cases, use the code ;) But as most people do not care about the openess of source there is an easier method (yup I also asked about this before ;): http://www.spinics.net/lists/linux-net/msg09933.html Quoting Sridhar Samudrala: 8--- I don't see any need to hijack listen() or connect() calls to make an existing TCP application to use SCTP. This can be done by trapping the socket() call and replacing the protocol with IPPROTO_SCTP. The lksctp-tools package does include a utility called 'withsctp' that can used with most of the existing TCP applications to make them use SCTP. You can find it as part of the lksctp-tools-1.0.0-1.i386.rpm at http://sourceforge.net/project/showfiles.php?group_id=26529 --8 Oh and it works just fine, props to the SCTP implementors! Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 23-nov-04, at 11:09, Elmar K. Bins wrote: Well, suppose we know 212/8 is used in Europe. A network that is present in say, North America and Europe then has the routers in Europe that talk to the routers in America filter out all 212/8 more specifics and only announce the aggregate instead. In the simple version this only works if there is full interconnection for all 212/8 destination in Europe. And if everyone gives transit to anyone. Ideal world. Actually everyone giving everyone transit is far from ideal. We've seen this happen in IPv6, with poor performance as a result. The trouble is that the destination of the traffic can do very little to improve this even if good connectivity is also present. But that's not what I'm saying anyway. If aggregates are only used within ASes and not communicated to other ASes, the macro view will stay the same. We just remove information in places where it has no added value. For example, someone in Los Angeles really doesn't care whether a packet goes to Darmstadt or Hannover. All they care about is that the packets move to the east. The correlation between network topology and geography doesn't have to be perfect. The number of routing table entries saved corresponds to the level of topology/geo correlation. Anything from 50% and up would be worthwhile, IMO.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, Nov 29, 2004 at 01:28:40PM -0500, Joe Abley wrote: On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface? #ifconfig lo0 down #ifconfig lo0 ::2 #ifconfig lo0 up is one way... --bill
Re: who gets a /32 [Re: IPV6 renumbering painless?]
the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. This makes some sense, however, how does the client system know which address it should use? what lets the client know that the path from client-server-address-ATT is better/worse/same as the path from client-server-address-MFN or client-server-address-uu ? I would think that the 'best' solution for all parties would be 'one' address for an end system, or one path to the end system. Because when it matters, the administrator of the zone has the option of removing the DNAME records for the provider that is sucking at the moment. Not a panacea, but, at least help. Single address may or may not be the best solution. One path to end system is definitely NOT the right answer for everyone. More paths is less failure. Perhaps this is just 'normal' technology acceptance process, and perhaps I'm missing a great many things in 'the v6-way', but if the multihoming can't be worked out in a sane manner I can't see rollout and acceptance of v6 coming any time soon. Apparently, you are, because, the whole DNAME/A6 thing was deprecated and we were lamenting that it's existence would have made this somewhat simpler to administer. there are, and will be in the future, folks that WANT NAT, regardless of the perceived 'badness' of it... Why? You still have yet to justify this position. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpenVqEaJqQC.pgp Description: PGP signature
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
I suspect that it is now time to agree to disagree. I have said before and will say again: 1. IPv4 is fundamentally flawed in that we are using a single resource as both an end-point identifier and a routing identifier. The phone companies figured out that these must be separate years ago. 2. IPv6 took some steps to solve this by making this division somewhat artificially through the use of A6/DNAME, but, later backed off from this practice. 3. IPv6 then completely failed to address issue 1 in any other way, and, so, we have, as near as I can tell, essentially come full circle to TUBA which we initially rejected largely because of issues like number 1 above. To further paraphrase Randy: 'Swamp: do not drink.' Owen --On Monday, November 29, 2004 8:53 AM +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Sun, 28 Nov 2004, Owen DeLong wrote: Except that A6/DNAME also supported your upstream being able to initiate prefix renumbering without having to involve the end customer... [...] Sure. But draft-ietf-v6ops-renumbering-procedure-03.txt says it IMHO well: 6. Acknowledgments [...] Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer. The main thrust of A6/DNAME is adding hooks for handling so-called 'rapid renumbering' and 'not-user-initiated-renumbering' scenarios. That seems unfeasible and unreasonable. Renumbering cannot be prevented. And we should take all the reasonable actions to make sure it's manageable, because otherwise we'll end up with PI/ULAs and NATs. But AFAICS, obtaining a level of 'manageability' should be sufficient. We don't necessarily want or need to solve the most tricky renumbering problems here (e.g., rapid renumbering, automatic renumbering or large sites without any actions from the administrators, etc.). To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.' -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- If it wasn't crypto-signed, it probably didn't come from me. pgpGcHC3BDRKF.pgp Description: PGP signature
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
--On Sunday, November 28, 2004 11:35 PM -0800 william(at)elan.net [EMAIL PROTECTED] wrote: On Mon, 29 Nov 2004, Pekka Savola wrote: 6. Acknowledgments [...] Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. [Note: check spell error - draft not daft] No, I think daft is the word intended in this case. It is a synonym for incompetent or stupid. I don't happen to agree with it, but, I think that is what was intended. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpZC65kjIC5I.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: (catching up) (you missed some stuff.) On 2004-11-22, at 18.52, Paul Vixie wrote: (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) I am not convinced A6/DNAME would have solved all problems, not even all of the ones you pointed out. the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). naturally this presumed that you could add and delete ipv6 supernets from a LAN, which appeared to be the case at that time, though now with dhcp6 and static addressing making a comeback that's no longer clear. in any case there was a need for a TCP option for endpoint-renumber, which was killed in a committee somewhere (i don't know which one, or where or when.) As someone actively working on maintaining an TCP stack (FreeBSD 5.x and 6.x) I can tell you this is a blessing. Throwing more stuff into TCP is only making matter worse and leads to lots of really buggy and non-working implementations. TCP is pretty complex already and only a few people are really up to it. given that ipv6 is now somewhat deployed without rapid renumbering, and that rapid renumbering could have required logic in both endpoints of every flow, but that there are now a lot of other endpoints without any such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. (show me.) If you want that, then go for SCTP. And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. -- Andre
Re: who gets a /32 [Re: IPV6 renumbering painless?]
And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. Unfortunately this sounds like a good target for people to mess up implementations and introduce huge security issues into TCP stacks. (along the theme of the one which started the recent MD5 discussion) But obviously, implemeted properly that would be very useful. The problem then becomes, how an ISP can signal a renumber. Pete
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. This is a layering violation and has endless security implications. You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. Try to get your TCP automatic renumbering stuff implemented from spec by five different people in five different codebases in a compatible way within two month time... No way. KISS KISS KISS KISS !!! Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the most stupid person on earth capable of correctly reading digits is able to punch in a number. As simple as it gets. Have you ever worked in luser techsupport? I did for the fun of it. It's not pretty. And that's why IPv6 is not going to fly. It's broken by design in so many places that it's impossible to explain it by phone to Joe Average (with IQ100, I'm not even talking about the average US high school dropout flipping burger in your favorite fast food chain). -- Andre
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, 2004-11-29 at 16:58 +0100, Andre Oppermann wrote: Paul Vixie wrote: And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. This is a layering violation and has endless security implications. Full Ack. IMHO SCTP and HIP are the way to go at the moment. Both support both IPv4 and IPv6 btw. New technologies are required to solve old problems, which is not that odd now is it ? :) SNIP Have you ever worked in luser techsupport? I did for the fun of it. Most people would refuse it :) It's not pretty. And that's why IPv6 is not going to fly. It's broken by design in so many places that it's impossible to explain it by phone to Joe Average (with IQ100, I'm not even talking about the average US high school dropout flipping burger in your favorite fast food chain). I am not flipping burgers, but did once work in a cheese factory (Gouda cheese anyone? :), I am wondering how you could keep this piggie from flying though. Could you elaborate or point me to a doc where you most likely already did? Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: who gets a /32 [Re: IPV6 renumbering painless?]
i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. Unfortunately this sounds like a good target for people to mess up implementations and introduce huge security issues into TCP stacks. (along the theme of the one which started the recent MD5 discussion) of course. and if endpoint-renumber were possible, it would also be used in load-balancing handoffs (similar to the thing that goes under the trade name 3TCP), clustering, failover... plus things we havn't even thought of yet. of course there would be security problems, and just knowing the current sequence numbers wouldn't be enough proof, and there's an interesting question of whether both directions would have to renumber at the same time. this is a nec'y enabling technology for so many things that calling it a layering violation is outrageous. But obviously, implemeted properly that would be very useful. The problem then becomes, how an ISP can signal a renumber. as it turns out, there is no silver bullet -- no single thing that if we could just to that then we'd be done, roll credits. same thing for spam, as it turns out. it's going to take a lot of little things, which amounts to a lot of hard work by a lot of people, some of whom won't even know eachother or about eachother's work, to get ipng done. real time tcp session renumberability is on the list, but it's a big list. what i DON'T like is having the future of ipng decided in star chambers where things like A6/DNAME can be killed without transparency or accountability.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. This is a layering violation and has endless security implications. as i told someone in private e-mail earlier this morning, tcp's notion of a flow-identifying tuple includes network addresses, and so, the ability to change these on the fly will absolutely affect tcp. when you bind a session to an address, as tcp currently does, you cause the community to waste ipv4 /32's or ipv6 /128's as loopback aliases just to have something they can virtualize, manage, move around, play with. let me put that another way, in case it's not clear enough as stated: tcp's existing reference to network addresses are a layering violation, and so anything we do to improve the situation will also be a layering violation, but what of it? deciding against making tcp less pure is not going to meet the needs and demands of the community -- and those needs and demands WILL be met, and probably in even less pure ways. google for a product or feature called 3TCP to see what i mean. You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. see above. we do that now. however, it limits the scope of mobility to same autonomous system and often same campus so it's not useful for any wide area purpose. the internet's target area is very wide indeed. Try to get your TCP automatic renumbering stuff implemented from spec by five different people in five different codebases in a compatible way within two month time... No way. where i come from that's called the fallacy of the straw man and is not a well respected technique for debate or discussion. the process i'm thinking of would take years to reach deployability, and more years to reach wide scale deployment. KISS KISS KISS KISS !!! Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the most stupid person on earth capable of correctly reading digits is able to punch in a number. As simple as it gets. i guess i was expecting smart people to write kernels and lusers to just run working code. this seems to work for apple and suse and redhat and sun and microsoft. or is this another straw man thing? certainly my kids think their mac/os/x machine is as easy to use as a telephone, and if you asked them how the routing table worked they wouldn't care. -- Paul Vixie
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface?
Re: who gets a /32 [Re: IPV6 renumbering painless?]
ifconfig le0:1 newaddr netmask newmask YMMV depending on your operating system. Owen --On Monday, November 29, 2004 1:28 PM -0500 Joe Abley [EMAIL PROTECTED] wrote: On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface? -- If it wasn't crypto-signed, it probably didn't come from me. pgpb0oDVdCiSH.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 29 Nov 2004, at 13:36, Owen DeLong wrote: ifconfig le0:1 newaddr netmask newmask YMMV depending on your operating system. If the old address is removed, then TCP sessions established with the old address as an endpoint will break; hence plumbing TCP sessions to loopback addresses is not a solution to TCP survival over renumbering attempts. That was my point. --On Monday, November 29, 2004 1:28 PM -0500 Joe Abley [EMAIL PROTECTED] wrote: On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface?
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Right... Well... The point of the loopback thingy was that you don't renumber the loopback. The address assigned to the loopback is used as the session endpoint identifier, while, the address assigned to the network interface is used as the routing endpoint identifier. So, BGP takes care of deailing with the consequences of renumbering the routing endpoint identifier, and, lo0 remains a consistent session endpoint identifier. This will not scale, but, it does work (e.g. anycast). Owen --On Monday, November 29, 2004 1:39 PM -0500 Joe Abley [EMAIL PROTECTED] wrote: On 29 Nov 2004, at 13:36, Owen DeLong wrote: ifconfig le0:1 newaddr netmask newmask YMMV depending on your operating system. If the old address is removed, then TCP sessions established with the old address as an endpoint will break; hence plumbing TCP sessions to loopback addresses is not a solution to TCP survival over renumbering attempts. That was my point. --On Monday, November 29, 2004 1:28 PM -0500 Joe Abley [EMAIL PROTECTED] wrote: On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface? -- If it wasn't crypto-signed, it probably didn't come from me. pgpTF6njmCshK.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: let me put that another way, in case it's not clear enough as stated: tcp's existing reference to network addresses are a layering violation, and so anything we do to improve the situation will also be a layering violation, but what of it? deciding against making tcp less pure is not going to meet the needs and demands of the community -- and those needs and demands WILL be met, and probably in even less pure ways. google for a product or feature called 3TCP to see what i mean. But doesn't HIP fix that in a way that is already specified and it just needs to be pushed forward if the community feels it fixes the next generation TCP issue? Pete
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 29 Nov 2004, at 13:50, Owen DeLong wrote: Right... Well... The point of the loopback thingy was that you don't renumber the loopback. This is not any kind of answer to the problem of TCP session survivability across renumbering events; it's an answer to the non-problem of TCP session survivability when there are no renumbering events. [how to suck eggs] Joe
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. This is a layering violation and has endless security implications. as i told someone in private e-mail earlier this morning, tcp's notion of a flow-identifying tuple includes network addresses, and so, the ability to change these on the fly will absolutely affect tcp. when you bind a session to an address, as tcp currently does, you cause the community to waste ipv4 /32's or ipv6 /128's as loopback aliases just to have something they can virtualize, manage, move around, play with. So? let me put that another way, in case it's not clear enough as stated: tcp's existing reference to network addresses are a layering violation, and so anything we do to improve the situation will also be a layering violation, but what of it? deciding against making tcp less pure is not going to meet the needs and demands of the community -- and those needs and demands WILL be met, and probably in even less pure ways. google for a product or feature called 3TCP to see what i mean. Instead of hacking the nice and working TCP we have now you should move on to greener grass and use SCTP instead. It does what you want, at least in the specification. I don't know how many implementors have managed to code it properly. You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. see above. we do that now. however, it limits the scope of mobility to same autonomous system and often same campus so it's not useful for any wide area purpose. the internet's target area is very wide indeed. Yea, but what is a surviving TCP good if you put your laptop to sleep and wake it up somewhere else? It can't pre-announce the next IP address it will use. Instead at the new location it will have to convince somehow the remote host that he is he indeed. No way without cryptography. IPSEC will break too. Oops, the remote end switched IP addresses too and you are lost. The question is whether renumbering while moving active TCP sessions to the new IP address is a problem at all other than a nice-to-have dream of 'propellerhead' Paul? ;) And the other, more serious, question is whether IP addresses are something that you only use temporarily or permanently? Try to get your TCP automatic renumbering stuff implemented from spec by five different people in five different codebases in a compatible way within two month time... No way. where i come from that's called the fallacy of the straw man and is not a well respected technique for debate or discussion. the process i'm thinking of would take years to reach deployability, and more years to reach wide scale deployment. Nonetheless having a simple and easily implementable spec is key to success and compatibility. I know you can write, hmm, interesting and complex code... KISS KISS KISS KISS !!! Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the most stupid person on earth capable of correctly reading digits is able to punch in a number. As simple as it gets. i guess i was expecting smart people to write kernels and lusers to just run working code. this seems to work for apple and suse and redhat and sun and microsoft. or is this another straw man thing? certainly my kids think their mac/os/x machine is as easy to use as a telephone, and if you asked them how the routing table worked they wouldn't care. No, they don't mind just using the computer because you set up the internet connection. Have them call your favorite ADSL provider and order an ADSL line and then have them set up some DSLWLAN thingie plus a printer connected via ethernet. And using the Apple offerings is cheating, take the average cheap windooze stuff. Because all this worked so well they want to run their own webserver on their computer and others from the internet should be able to connect... You see? -- Andre
Re: who gets a /32 [Re: IPV6 renumbering painless?]
It would have been nice to make sctp be the standard stream protocol for ipv6. yup. or at any rate, SOME kind of improvement in this area. For most nanog customers, there's still time. nope. Those places that have already seen significant ipv6 adoption may need to upgrade again. If we wait much longer, of course, the opportunity will be lost. that opportunity was lost when the preponderance of the iab and iesg was refilled by folks who didn't know or care why TUBA hadn't been selected. To argue that it's already too late, when ipv6 is a small fraction of all traffic and an infinitesmal fraction of future traffic is, imho, foolish. and yet it is. to declare that ipv6 will can have more than one flag day is to declare that there could be more flag days which would have what the law people call a chilling effect. that can't be allowed to happen. this is why the decision to kill a6/dname was so evil. not that it was wrong, or made in a star chamber without consensus or transparency, but that it was so perfectly timed to be irreversable. it's review-proof.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-22, at 19.29, william(at)elan.net wrote: What is bad however is that IETF instead of pursuing it as one effort has several of them including MULTI6, HIP, etc. I don't see this as really true. MUTLI is tasked with solving the problem of scalable site-multihoming for IPv6. HIP is tasked with defining the experimental protocol HIP. They are not mutually exclusive. I would actually like to argue that they are more complimentary. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQancq6arNKXTPFCVEQKD8wCfV11jFyqW1swUJyP6h0ToB8OR4N8An2NM mxR7AmAf8qKnp/E3967ge1HO =pJet -END PGP SIGNATURE-
Re: who gets a /32 [Re: IPV6 renumbering painless?]
(catching up) (you missed some stuff.) On 2004-11-22, at 18.52, Paul Vixie wrote: (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) I am not convinced A6/DNAME would have solved all problems, not even all of the ones you pointed out. the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). naturally this presumed that you could add and delete ipv6 supernets from a LAN, which appeared to be the case at that time, though now with dhcp6 and static addressing making a comeback that's no longer clear. in any case there was a need for a TCP option for endpoint-renumber, which was killed in a committee somewhere (i don't know which one, or where or when.) given that ipv6 is now somewhat deployed without rapid renumbering, and that rapid renumbering could have required logic in both endpoints of every flow, but that there are now a lot of other endpoints without any such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. (show me.)
A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Sun, 28 Nov 2004, Paul Vixie wrote: the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). [...] Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind ;) with a lot less protocol complexity? As you note, A6/DNAME wasn't a panacea. A lot additional stuff is needed to achieve the goal. It seems to me that actually the A6/DNAME part is a relatively simple one to achieve using current mechanisms. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
[...] Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind ;) with a lot less protocol complexity? only if you can tolerate short TTL's on all your 's. in the A6/DNAME model, your A6's could have long TTL's whereas your DNAME's could have short(er) ones. As you note, A6/DNAME wasn't a panacea. A lot additional stuff is needed to achieve the goal. It seems to me that actually the A6/DNAME part is a relatively simple one to achieve using current mechanisms. the other issue is multihoming. someone who got done traversing the maze of A6 and DNAME RRs that it took to find your addresses would pretty much know that you were supernetting at the LAN level and that they should use a very short timeout when connecting to each address. when someone gets back multiple 's for you, then you might be multihomed, and folks will do just what they do with multiple A's, which doesn't support rapid renumbering.
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
Except that A6/DNAME also supported your upstream being able to initiate prefix renumbering without having to involve the end customer... As I understand it: foo.blah.org. IN A6 MYISP1 ::4321:53ef MYSIP1 IN DNAME 10 prefix1.isp1.net. ::dead:beef:: Then, in ISP1's isp1.net zone file prefix1 IN DNAME 100 feed:beef:: This way, if ISP1 needed to renumber for some reason (turning in old /32 in trade for /30, for example), they could go through the following steps: prefix1 IN DNAME 200 feed:beef:: prefix1 IN DNAME 100 2314:5124:: Wait a few days for everyone to catch on to the new DNAME, then, prefix1 IN DNAME 100 2314:5124:: Voila, painless ISP renumber without substantial end-user headache. Sure, there are other issues (like bone-headed ACLs that accept/deny host based on 128 bit address), but, this at least solved part of that problem. Owen --On Sunday, November 28, 2004 8:51 PM +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Sun, 28 Nov 2004, Paul Vixie wrote: the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). [...] Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind ;) with a lot less protocol complexity? As you note, A6/DNAME wasn't a panacea. A lot additional stuff is needed to achieve the goal. It seems to me that actually the A6/DNAME part is a relatively simple one to achieve using current mechanisms. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- If it wasn't crypto-signed, it probably didn't come from me. pgp9NI4V4aRpS.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sun, 28 Nov 2004, Paul Vixie wrote: (catching up) (you missed some stuff.) eh, so must I have, atleast about multi-homing :) I'll ask below. (and yes, I'm still behind on the ipv6 reading I was supposed to do) On 2004-11-22, at 18.52, Paul Vixie wrote: (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) I am not convinced A6/DNAME would have solved all problems, not even all of the ones you pointed out. the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. This makes some sense, however, how does the client system know which address it should use? what lets the client know that the path from client-server-address-ATT is better/worse/same as the path from client-server-address-MFN or client-server-address-uu ? I would think that the 'best' solution for all parties would be 'one' address for an end system, or one path to the end system. There are all sorts of reasons, from a client side, why ipv6 seems like a huge mess, this is but one of them. It seems to me that other things like outage detection toward the provider specific addresses (uu is down and att is up, too bad I tried to get to the uu address) might also be a problem. From the server side things also seem extra-messy in v6: 1) forcing N DNS updates for each system address change (uu-forward, mfn-forward, att-forward... and reverses if you care about that as well) 2) 'extra' server resources to serve extra zones with the same information. 3) forcing urpf-like routing of traffic: uu out uu, att out att and mfn out mfn off diverse routers upstream from the local LAN. The world has been pushed toward multihoming of critical resources (critical at multiple levels) over the last 10 years, forcing extra complexity into v6 such that multihoming is now 'very difficult' (maybe not for Paul or Mr. Rosen, but for many folks still) will delay the rollout of v6 and it's acceptance. Perhaps this is just 'normal' technology acceptance process, and perhaps I'm missing a great many things in 'the v6-way', but if the multihoming can't be worked out in a sane manner I can't see rollout and acceptance of v6 coming any time soon. such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. (show me.) there are, and will be in the future, folks that WANT NAT, regardless of the perceived 'badness' of it... -Chris
Re: who gets a /32 [Re: IPV6 renumbering painless?]
..., it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. ... there are, and will be in the future, folks that WANT NAT, regardless of the perceived 'badness' of it... i know. i've met some. i've been one. please join me in trying to get some of them onto the IAB so that, like prometheus, they can carry the secret of fire to those in need.
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Sun, 28 Nov 2004, Owen DeLong wrote: Except that A6/DNAME also supported your upstream being able to initiate prefix renumbering without having to involve the end customer... [...] Sure. But draft-ietf-v6ops-renumbering-procedure-03.txt says it IMHO well: 6. Acknowledgments [...] Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer. The main thrust of A6/DNAME is adding hooks for handling so-called 'rapid renumbering' and 'not-user-initiated-renumbering' scenarios. That seems unfeasible and unreasonable. Renumbering cannot be prevented. And we should take all the reasonable actions to make sure it's manageable, because otherwise we'll end up with PI/ULAs and NATs. But AFAICS, obtaining a level of 'manageability' should be sufficient. We don't necessarily want or need to solve the most tricky renumbering problems here (e.g., rapid renumbering, automatic renumbering or large sites without any actions from the administrators, etc.). To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.' -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Mon, 29 Nov 2004, Pekka Savola wrote: 6. Acknowledgments [...] Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. [Note: check spell error - draft not daft] Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer. sarcasm Oh? Is that Acknolidgement the only contribution IETF has to offer in regards to renumbering? How pathetic! To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.' Is that the same as Ocean: do not cross? I guess we're lucky Columbus did not have same attitude to life as Randy... /sarcasm -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: who gets a /32 [Re: IPV6 renumbering painless?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul, On 2004-11-28, at 17.47, Paul Vixie wrote: (catching up) (you missed some stuff.) Yes, I have had lot's of fun reading through almost a week of Nanog... the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. Somehow I must be confused. AFAIK DANME/A6 is/would be/could have been of great help with the name to number mapping when renumbering. But the main problem is the actual renumbering of the HOSTs. And I fail to see how A6/DNAME would help. As a matter of fact the problems that was brought to multi6 are a lot more than what you have listed A6/DNAME to address. See RFC3582 and draft-lear-multi6-things-to-think-about-03.txt for an overview. given that ipv6 is now somewhat deployed without rapid renumbering, and that rapid renumbering could have required logic in both endpoints of every flow, but that there are now a lot of other endpoints without any such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. (show me.) ULAs are not a product of multi6. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQarLg6arNKXTPFCVEQJUzgCfSgII26+xcvM8BQAb2P68UQjiR8gAnjfk xkw0hLIVRrz4RDJcxAzKksRC =z9eO -END PGP SIGNATURE-
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 25-nov-04, at 21:16, Stephen Sprunk wrote: if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-) There is an issue of uniqueness. Those hosts that can't reach the Internet typically can talk to other hosts that can, and even multiple private networks often link to each other. At a minimum, statistical uniqueness is necessary to avoid collisions between business partners even on a totally disconnected network. Yes, this is why we need ULAs. ULAs do not contribute to the global routing table unless ISPs allow them to in violation of the draft's wording and intent. Well, seeing how difficult it is to get legitimate address space routed (see bogon thread) I don't see how all ISPs in the world are going to route this space unless some significant blackmail is involved (such as the likes of Google using this address space exclusively). And don't forget that this is IPv6. Today, and for the forseeable future, you can filter out all IPv6 routes that you don't like without breaking any connectivity as everything is reachable over IPv4 anyway. So people who don't want to see the ULAs in their routing table can just filter them out. (Although it works both ways: people can choose to do IPv6 using ULAs only without having to suffer unreachability.) The WG welcomes input on how to prevent this from occurring without invoking restraint of trade concerns. How about this: we all start announcing a few hundred random ULAs. This will make the v6 table too large to carry without filtering ULAs. I don't expect ISPs who aren't opposed to carrying ULAs for other ISP's customers to be willing to create filters that only let these specific ones through but not the background noise. It would probably also help if the ICANN directs all registries that glue records towards ULA space aren't allowed.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
It would probably also help if the ICANN directs all registries that glue records towards ULA space aren't allowed. Or cause people to start providing copies of the v6 equivalent of .in-addr.arpa that contain RIR pointers and glue for ULA. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgp5w1uy09dr9.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake [EMAIL PROTECTED] No connectivity to the internet? - use ULA, quick, easy, cheap. ULA leaves a bad taste for a number of reasons, some of which have seen some discussion. What has not occured, and seems to be a major tenent of the ULA zelots, is how conflict resolution is to be done. if ULA is sufficent, in and of itself, then why do we need to have all the rest of the 128bits of space? You need some bits at the top to denote the ULA portion of the address space, you need bits at the bottom for the host address, and you need bits in the middle for internal network structure. Consensus was that 40 bits was enough for the unique portion of the prefix. ULAs were not intended to solve all problems, just like neither link-local, PA, or PI addresses do not solve all problems by themselves. if ULA users ever have a conflict (and yes, they will) how will the conflict be resolved? There is negligible chance of conflict between any two parties thanks to the 40-bit prefix space, and the odds of collision are still neglibigble even when hundreds of networks are interconnected. Sure, sooner or later two networks will happen to generate the same prefix. When that happens -- and assuming those networks want to talk to each other, one of them simply generates a new prefix and renumbers. This is a significantly better situation than with RFC1918 (or SLAs) where a collision is _guaranteed_. and then there is the nasty delusion of Internet... protestations to the contrary, the VSNL view of the Internet is vastly different than the US DOD view of the Internet, is vastly different than the GE view, is different than the AS 701 view, is different than the Chinese RE Network (CERN) view which one(s) count? Policy routing dictates that there is no such thing as a global routing table... There are clearly many parts of the Internet that are private and one large part in the middle that is clearly public. ULAs are intended to only be used within the private parts or even totally disconnected IP networks. For me, as long as I have IP reachability to those folks whom I want or need to talk to, I could care less about the rest of the folks using IP to move datagrams about ... Exactly. However, the scope of who you want/need to talk to dictates what sort of addresses you need (with the current routing architecture) and where you get them. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 21-nov-04, at 20:12, Stephen Sprunk wrote: The point is, that these days applications such as mail and web are sufficiently heavy that you can't even run them cost effectively over dial up (wasting your employee's time costs more than the fatter line) let alone less. That assumes the company wants their employees using web or email, or that there are even humans at a site to begin with. No it doesn't, but if this is not the case, then this clause kicks in: if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-) There is an issue of uniqueness. Those hosts that can't reach the Internet typically can talk to other hosts that can, and even multiple private networks often link to each other. At a minimum, statistical uniqueness is necessary to avoid collisions between business partners even on a totally disconnected network. ULAs do not contribute to the global routing table unless ISPs allow them to in violation of the draft's wording and intent. The WG welcomes input on how to prevent this from occurring without invoking restraint of trade concerns. No, that's not what I'm interested in. What I'd like to know is how many big organizations backhaul their internet traffic to one or a few central sites, and how many connect to one or more ISPs locally at different sites. I personally know of several dozen, and based on information I can't disclose, I'd say that at least half if not two thirds of the Fortune 1000 backhaul their Internet traffic -- many of them via IPsec VPNs over the Internet. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Sure, sooner or later two networks will happen to generate the same prefix. When that happens -- and assuming those networks want to talk to each other, one of them simply generates a new prefix and renumbers. This is a significantly better situation than with RFC1918 (or SLAs) where a collision is _guaranteed_. unmanaged delegations _will_ create collisions. and the problem is not when these sites want to talk w/ each other, its when your packets go to (one) of the other places using the identical prefix. and then there is the nasty delusion of Internet... protestations to the contrary, the VSNL view of the Internet is vastly different than the US DOD view of the Internet, is vastly different than the GE view, is different than the AS 701 view, is different than the Chinese RE Network (CERN) view which one(s) count? Policy routing dictates that there is no such thing as a global routing table... There are clearly many parts of the Internet that are private and one large part in the middle that is clearly public. ULAs are intended to only be used within the private parts or even totally disconnected IP networks. that model -might- have been accurate once, but has not been an accurate representation for several years. there is no middle, For me, as long as I have IP reachability to those folks whom I want or need to talk to, I could care less about the rest of the folks using IP to move datagrams about ... Exactly. However, the scope of who you want/need to talk to dictates what sort of addresses you need (with the current routing architecture) and where you get them. the scope of who I want to talk to varies over time. just because the list of folks I want to talk to does not intersect w/ yours does not give you the right to tell me that I must use private or ULA or site-local addresses. we should each be able to be delegated address space which has -zero- chance of collison w/o a means to arbitrate. ULAs have no defined arbitration technique defined, other than through the legal system. RIR managed space has the arbitration technique as an intergral component of the delegation process. roughly - ULA == the lawless west RIR == civilized society -IF- ula space is ever approved, my advice to all transit providers is to never filter it. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: who gets a /32 [Re: IPV6 renumbering painless?]
ULAs do not contribute to the global routing table unless ISPs allow them to in violation of the draft's wording and intent. The WG welcomes input on how to prevent this from occurring without invoking restraint of trade concerns. just like RFC 1918 space hum... --bill
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
Re: who gets a /32 [Re: IPV6 renumbering painless?]
[EMAIL PROTECTED] (Iljitsch van Beijnum) wrote: For instance, 212.x.y.z is known to be on one continent, and so on - but how do you leverage that into a 212/8 routing entry? Well, suppose we know 212/8 is used in Europe. A network that is present in say, North America and Europe then has the routers in Europe that talk to the routers in America filter out all 212/8 more specifics and only announce the aggregate instead. In the simple version this only works if there is full interconnection for all 212/8 destination in Europe. And if everyone gives transit to anyone. Ideal world. Elmi. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: who gets a /32 [Re: IPV6 renumbering painless?]
[EMAIL PROTECTED] (Jeroen Massar) wrote: The current solution I see for this is still IPv6. Except that one moves the complete 'Independence' problem a layer higher. Enter: HIP: Host Identity Protocol: http://www.ietf.org/html.charters/hip-charter.html this level of complexity seems a little high for anything to be universal. It depends all on what one wants, either one gets a lot of routes and thus what we currently have in IPv4 or it is done completely different, like that. That's the point of view of an Internet technician (ok, who's on this list, after all...). It is not the point of a user, a manager or a corporation. HIP is too complicated, it relies on too many parts. It will never be used widely, unless someone find a way to _entirely_ hide it from the end-user. I cannot see a way to do that, starting with the certificates and for a long time not ending with server and client implementations. It is nice in theory, it streamlines protocol interaction, adds security, makes you mobile, but it uses too many parts in complex interconnection. I consider it impractical on the large, although it may fit the bill for small, technically-oriented user groups. Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On 23-nov-04, at 6:49, Patrick W Gilmore wrote: If all active ASes did this we'd have a 400k routing table. So please no PI in IPv6, not even for large enterprises. Why is an ISP more worthy or PI space than a large enterprise. In fact, ISPs are responsible for far, far more table pollution than enterprises. Pot-Kettle-Black? Besides that, please remember the Internet is a business, not a research tool or a toy for those with enable. Business have business needs. If the Internet cannot satisfy them, then the Internet will not be paid for its services. This ain't 1999 no more, you need your customers. I'm going to try to make this my last message on this subject... It's very simple. If the routing tables get too big too fast, very bad things start to happen. The Apple example (along with some ISPs who announce dozens or hundreds of aggregatable blocks unaggregated) shows that we can't rely on good internet citizenship to manage the problem. Just to make sure everyone understands: according to the latest CIDR report there are 149080 prefixes in the global routing table, sourced by 18398 ASes. That's 8.1 prefixes per AS. If we subtract the 7506 one-prefix ASes from both figures we're at 13 prefixes per AS. Apple sources 22 prefixes from their AS. That's 70% more than the average, with the average including the largest ISPs in the world. So why is it reasonable to give even quite small ISPs a portable block but not the largest enterprises? Two reasons. First of all, the number of ISPs world wide is low enough that with the allocation policies in IPv6 ISPs alone aren't going to blow up the global routing table. The second is, that if an ISP needs to renumber, all their customers have to renumber as well. This makes renumbering much harder for ISPs than for end-user organizations. In addition to portable address space being harmful, I also believe it's not really necessary. Renumbering client-only systems is NOT a problem with DHCP or IPv6 stateless autoconfiguration. (With the latter, it's even completely transparent to the user. I've tried it.) With some tools managing the DNS during renumbering also isn't a real issue. Reconfiguring routers and other network infrastructure isn't entirely trivial at this point, but this is being worked on. I don't see why this shouldn't be solved to a satisfactory degree in the future. This leaves address-based access restrictions. There are two aspects to this: internal addresses and external addresses. Trusting packets that come from some address X on the internet makes no sense, as it's fairly trivial to hijack address space on the internet. Trusting packets because they come from an internal address is doable to a certain degree, because you get to reject packets that falsely claim to be from the inside on the borders. However, unique local addresses are just fine for this. (This means hosts that need both internal and external connectivity must have different addresses for both, but this isn't a problem in IPv6. Default address selection rules specify that when connecting to ULAs a host should use its own ULA address and when connecting to the rest of the world it should use its regular address, but this isn't fully implemented in OSes yet.) With all the above in effect, renumbering would only really impact VPN tunnels. Even if this must be done by hand I don't think it's reasonable to give out PI space just to avoid this. And I'm sure the VPN vendors can come up with mechanisms that allow the secure creation/renumbering of those tunnels, if they feel their customers need it. If organizations with PA space want to peer, this shouldn't be a problem: they just announce their /48 to their peers. Obviously if people are interested in peering, they'll be willing to carry the more specifics in their routing tables. The difference with PI is that if they filter the route out, there is no loss of connectivity. Remember that IPv4 still has a few good years in it so there is time to fix problems with IPv6 so we get to do it right from the start rather than have the same mess we have now with larger addresses.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Tue, 2004-11-23 at 11:32 +0100, Elmar K. Bins wrote: [EMAIL PROTECTED] (Jeroen Massar) wrote: The current solution I see for this is still IPv6. Except that one moves the complete 'Independence' problem a layer higher. Enter: HIP: Host Identity Protocol: http://www.ietf.org/html.charters/hip-charter.html this level of complexity seems a little high for anything to be universal. It depends all on what one wants, either one gets a lot of routes and thus what we currently have in IPv4 or it is done completely different, like that. That's the point of view of an Internet technician (ok, who's on this list, after all...). It is not the point of a user, a manager or a corporation. I am actually a user, though I tend to try to solve the problems I come across when wanting to do something from a variety of perspectives, all of which you mentioned above and probably a lot more. HIP is too complicated, it relies on too many parts. It will never be used widely, unless someone find a way to _entirely_ hide it from the end-user. I cannot see a way to do that, starting with the certificates and for a long time not ending with server and client implementations. Does Jane Doe even know that DNS exists? No, they go to wall-mart or so, get themselves a computer (expensive toy with a lo of buttons), because that, just like a phone, is used to communicate to other people, or a tv to look at pretty things (Tell Sell made interactive!), they plug it into that cable coming out of the wall, or most of the time let some 'engineer' (that creepy fellow that came only after I called them a lot of times when they finally came around) 'install' it. Then Jane can press that round button and using that thing they call a mouse (I have to press the eyes and the tail is on the wrong side). MSN or whatever that came pre-installed pops up and gives them some default links. Most of them don't even know they can *type* url's let alone that they are called url's or that they form a hierarchy... they really don't care about DNS and they also do not want to know. As for your 'certificates' part, never used http://www.bank.com ? :) They come pre-installed. 25 years ago you didn't get a computer with a pre-installed browser (they didn't exist), that might take time, but it will come hopefully. That something at this moment doesn't look viable or far in the future doesn't mean one must simply throw it away... Btw... the funniest part about most people who say they 'multihome' is always that they have quite a number of SPOF's in their 'network' ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
[EMAIL PROTECTED] (Iljitsch van Beijnum) writes: I'm going to try to make this my last message on this subject... ok. In addition to portable address space being harmful, I also believe it's not really necessary. Renumbering client-only systems is NOT a problem with DHCP or IPv6 stateless autoconfiguration. (With the latter, it's even completely transparent to the user. I've tried it.) as long as you don't have any long running tcp sessions open at the time, or the ones you're running will gracefully restart, you'll get transparency. With some tools managing the DNS during renumbering also isn't a real issue. Reconfiguring routers and other network infrastructure isn't entirely trivial at this point, but this is being worked on. I don't see why this shouldn't be solved to a satisfactory degree in the future. i do. see, that is. because rapid renumbering wasn't a bilateral protocol requirement from day 1, renumbering will always be a crock of swill in ipv6 just as it is in ipv4. If organizations with PA space want to peer, this shouldn't be a problem: they just announce their /48 to their peers. Obviously if people are interested in peering, they'll be willing to carry the more specifics in their routing tables. The difference with PI is that if they filter the route out, there is no loss of connectivity. this assumes that the provider who assigned the /48 allows cutouts. (hint.) Remember that IPv4 still has a few good years in it so there is time to fix problems with IPv6 so we get to do it right from the start rather than have the same mess we have now with larger addresses. in the spirit of making lemonade, sure, let's treat the connectionless ip networking model as not having been stateless enough, and with ipv6 where we have a lot more addresses, let's just do away with ever having any one address used by any one endpoint for very long. i guess i understand that, even though it makes no sense. sort of a catch-22 thing, right? -- Paul Vixie
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 21-nov-04, at 20:05, Paul Vixie wrote: (note that i'm not speaking for arin, nor as a member-elect of arin's board of trustees, i'm just another bozo on this bus.) You're bascially saying that you and people like you are so important that you deserve to receive benefits that go against the public good. actually, i'm just trying to keep my role as member-elect of arin's BoT separate from my role as an internet citizen. as it turns out, arin's BoT does not have a policy formation role. when this issue comes up in PPML or the AC, i'll speak up, but i'll be explicitly hatless when i do. I've never been a great believer in hat switching. Even if it is possible to fully separate different roles internally, things get blurry in the perception of others. In your case we made him a member of the ARIN board of trustees so it would be stupid not to listen to him. you are drastically misunderstanding my hopes, my goals, and my role. Please explain them then. It also shows contempt for the IETF, as you reject all possible alternatives to PI out of hand. i never rejected all possibilities, just the ones i've personally studied so far. Well, then the question is: how up to date are you with regard to the IETF multi6 wg and the discussions about locator/identifier separation in general? i'm also on record as saying that the easiest time to have fixed this was before the current IPng approach was annointed; now we're playing catchup. even you in your multi6 role ought to be wishing that more had been done before IPv6 was cast in stone. I'm not sure what part of IPv6 you would like to have seen different. Sure, there were some mistakes such as the whole ip6.int / ip6.arpa debacle, the site local thing that got this discussion started and last but not least the DNS resolver discovery issue, but what exactly should have been done differently in the area of routing? However, if the RIRs decide to open up PI in IPv6, people will take the quick fix and there won't be any push to get the (admittedly) more complex but more scalable solutions to these problems off the ground. somehow i don't think that's going to sway wal-mart's thinking at all, but i do look forward to a lively debate next time this comes up on PPML. It's wrong if these issues that have global impact are decided regionally. the codification of the current approach as IPng in spite of objections raised at that time amounted to a recommendation of let them eat NAT. I'd rather eat cake than NAT. :-)
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 21-nov-04, at 20:12, Stephen Sprunk wrote: The point is, that these days applications such as mail and web are sufficiently heavy that you can't even run them cost effectively over dial up (wasting your employee's time costs more than the fatter line) let alone less. That assumes the company wants their employees using web or email, or that there are even humans at a site to begin with. No it doesn't, but if this is not the case, then this clause kicks in: if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-) It would be interested to see some good statistics on this stuff. However many enterprises any of us has seen from the inside, it's still unlikly to be a statistically relevant sample. An unfiltered BGP feed should give you stats on what's quoted immediately above. If you want numbers of publicly-invisible hosts, even if you knew who to ask most would refuse to answer for security reasons or require an NDA. No, that's not what I'm interested in. What I'd like to know is how many big organizations backhaul their internet traffic to one or a few central sites, and how many connect to one or more ISPs locally at different sites.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Not necessarily true. I live in California. However, 703-842-5527 is a valid phone number for me. It even worked for me while I was in Puerto Vallarta, Mexico. I can take that number pretty much any where in the world, whether temporarily, or, even if I move there. This isn't just a US phenomenon. Companies like http://www.telphin.com/numbers.php are selling this kind of number portability in other countries. And I remember some Australians were routing US phone numbers to their mobiles back in 1997. Clearly, telephone numbers are now being treated as names rather than addresses. The technical issues we should be concerned with are down at the address level. Could continental aggregation be a way of reducing the size of the so-called global routing table so that the table can accomodate a larger number of specifics within the continent? Alex Bligh raised the spectre of GRE tunnels to redirect traffic to the right location. Could this be done by simply readdressing the packets? Is this even relevant in a world that runs IPv4 and IPv6 over MPLS? After all MPLS is designed to swap and pop destination labels to route and reroute packets through the network. In a real-world network perhaps we should accept that some problems will be solved outside of IPv6. --Michael Dillon
Re: who gets a /32 [Re: IPV6 renumbering painless?]
No, that's not what I'm interested in. What I'd like to know is how many big organizations backhaul their internet traffic to one or a few central sites, and how many connect to one or more ISPs locally at different sites. I believe there are enough examples of each that neither can be ignored. I also believe that the former is growing vs. the latter. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpR5up31s2x3.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
you are drastically misunderstanding my hopes, my goals, and my role. Please explain them then. briefly, because i consider myself off-topic and sue probably does also. the problem statement answered by the ipngwg was wrong. they thought they were supposed to solve the shortage of address space problem, but that wasn't the most serious problem then (and is not now). the right problem statement would be to solve the shortage of PORTABLE address space problem. note the insertion of the word portable before address space. the big problem in 1992 and the big problem now is that a wal-mart corporate desktop will either have an ambigious address (behind a NAT), or a hard-to-renumber isp-price-locked address (provider assigned), or a takes-a-slot-in-the-global routing-table address (provider independent). three strikes and you're out! none of those three things is acceptable, not even as a compromise. i have not looked in on the multi6 wg this year. my bad. perhaps you've come up with a fourth alternative, or a way of softening one of the three existing alternatives to the point where its benefits outweigh its costs. but everything i've actually looked at either resolves the cost/benefit in favour of some minority of which neither isc nor wal-mart is a part, or which would have been equally applicable to ipv4 such that all we needed was the gimmick itself, not 128-bit addresses, if only we'd been willing to pay this much pain back before ipngwg's work was complete. ipng needed rapid renumbering, including renumbering tcp endpoints realtime and including multihoming where you can add and delete PA interface addresses whe way commercial RAID vendors add and delete disk drives. the people in putative charge of this said either (a) they didn't agree, (b) they didn't understand, or (c) they didn't have time to add more requirements. now it's 2004 and lo and behold, the problems of 1992 are still with us, but now we have better terminology to describe them. you can be locked into a provider's pricing and service quality; or you can run NAT; or you can find a way to get your own slot in the global routing table. we have the same shortage of portable addresses now that we had in 1992, even though we have increased the overall supply of address space by a factor of 2**96. if multi6 offers a fourth alternative, it would probably also have worked with ipv4, in which case why did we spend years working on 128-bit addressing? i strongly believe that the isp community who pays ARIN's bills will decide that the best way to grow the industry is to let folks like ford and wal-mart have their own /32's, and that there will be a spectrum of r e n u m b e r i n gd i f f i c u l t y easy--moderateimpossible with PA+NAT on the left (home dsl, cable); wal-mart and ford on the right with endsystem PI, and folks like isc in the middle, doing some kind of multi6 thing, whose costs while high will be lower than the renumbering penalty. since the arin BoT has no policy formation role, i'm expecting to be able to voice an opinion that weighs exactly as much as everybody else's, and to vote ultimately on whatever the policy formation function comes up with. so there. those are my views. aren't you glad you asked? It's wrong if these issues that have global impact are decided regionally. yes. i understand that the acid rain people, the ozone layer people, the ice cap people, the whale people, and the ocean oxygen level people, all have that same complaint. human nature on a grand scale isn't always pretty.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, 2004-11-22 at 16:53 +, Paul Vixie wrote: you are drastically misunderstanding my hopes, my goals, and my role. Please explain them then. briefly, because i consider myself off-topic and sue probably does also. The off-topicness is most likely only as this is an enduser/site problem. the problem statement answered by the ipngwg was wrong. they thought they were supposed to solve the shortage of address space problem, but that wasn't the most serious problem then (and is not now). the right problem statement would be to solve the shortage of PORTABLE address space problem. note the insertion of the word portable before address space. the big problem in 1992 and the big problem now is that a wal-mart corporate desktop will either have an ambigious address (behind a NAT), or a hard-to-renumber isp-price-locked address (provider assigned), or a takes-a-slot-in-the-global routing-table address (provider independent). three strikes and you're out! none of those three things is acceptable, not even as a compromise. The current solution I see for this is still IPv6. Except that one moves the complete 'Independence' problem a layer higher. Enter: HIP: Host Identity Protocol: http://www.ietf.org/html.charters/hip-charter.html I've looked quite a bit at the various 'solutions' that got offered by folks and came to the conclusion that HIP, and don't mind any related protocols, are one of the very plausible solutions. Say we have 50k ISP's worldwide, they get a /32 or so from the RIR's and announce it. ISP is here 'a network not used by users' aka 'only routers', the ISP could of course take a /48 out of their /32 and be a client of themselves. Any organization can then use one or more /48's from one or more (upstream) ISP's in combination with HIP. Problem solved. There is one issue though that comes forth: a large organization, say Shell, will get quite a number of /48's. An /48 per site as allocated from the ISP that is serving them at that moment. If one wants to do firewalling or make other assumptions based on the prefix you will have quite a hell of a time updating them, certainly in such a large organization. Then again, what are those folks doing who are being called managers ? :) No connectivity to the internet? - use ULA, quick, easy, cheap. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: who gets a /32 [Re: IPV6 renumbering painless?]
none of those three things is acceptable, not even as a compromise. The current solution I see for this is still IPv6. Except that one moves the complete 'Independence' problem a layer higher. Enter: HIP: Host Identity Protocol: http://www.ietf.org/html.charters/hip-charter.html this level of complexity seems a little high for anything to be universal. (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.)
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, 22 Nov 2004, Paul Vixie wrote: HIP: Host Identity Protocol: http://www.ietf.org/html.charters/hip-charter.html this level of complexity seems a little high for anything to be universal. (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) 1. A6/DNAME were great idea, I'm really disappointed they are not going forward... 2. Level of complexity is a very relative thing. To me the important is not to overwhelm any single protocol and allow clear separation between different levels.. In that sense if we actually are able to create new host identity layer we can solve the problem with not only dynamicly changing ip addresses but with simplified multihoming for end-user sites. What is bad however is that IETF instead of pursuing it as one effort has several of them including MULTI6, HIP, etc. BTW - regarding why these effots while being ip-independet would not work for Ipv6, the reason is addressing. We need new kind of addresses and they all require id that TCP can use for establishing connection and that ID can not be limited to 32 bit so we end up considering reusing part of IPv6 space for this new kind of non-ip addresses. I think given large amount of available IPv6 space that is acceptable - if we cut the pool to 1/4 we'd still have enough. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, 2004-11-22 at 17:52 +, Paul Vixie wrote: none of those three things is acceptable, not even as a compromise. The current solution I see for this is still IPv6. Except that one moves the complete 'Independence' problem a layer higher. Enter: HIP: Host Identity Protocol: http://www.ietf.org/html.charters/hip-charter.html this level of complexity seems a little high for anything to be universal. It depends all on what one wants, either one gets a lot of routes and thus what we currently have in IPv4 or it is done completely different, like that. As for it not being universal, there are quite a number of working implementation already that seem to be proven to work quite reliable. One of the alternatives of course is something similar as MIPv6 etc. (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) Wasn't it more because a single A6 lookup could cause one (the resolver that is ;) to have to follow a overly long chain of A6/DNAME chains, which thus could cause maybe somewhat infinite lookups? I rather like DNAME btw: ip6.int DNAME ip6.arpa, which works quite fine. A6 is fortunately not supported any more by BIND. On Mon, 2004-11-22 at 10:29 -0800, william(at)elan.net wrote: 1. A6/DNAME were great idea, I'm really disappointed they are not going forward... It is, except maybe for the above noted 'problem'. Most of the time though a site will have only a limited number of DNS servers, thus A6/DNAME would be on the same server and the administrator could IMHO quite easily do the simple replace trick on the configuration. 2. Level of complexity is a very relative thing. To me the important is not to overwhelm any single protocol and allow clear separation between different levels.. In that sense if we actually are able to create new host identity layer we can solve the problem with not only dynamicly changing ip addresses but with simplified multihoming for end-user sites. For most people on this globe the concept of 'IP' or even the phone system is already magic :) Depends on bit who looks at it. What is bad however is that IETF instead of pursuing it as one effort has several of them including MULTI6, HIP, etc. The fun of politics ;) BTW - regarding why these effots while being ip-independet would not work for Ipv6, the reason is addressing. We need new kind of addresses and they all require id that TCP can use for establishing connection and that ID can not be limited to 32 bit so we end up considering reusing part of IPv6 space for this new kind of non-ip addresses. I think given large amount of available IPv6 space that is acceptable - if we cut the pool to 1/4 we'd still have enough. No issue there then now is there ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: who gets a /32 [Re: IPV6 renumbering painless?]
BTW - regarding why these effots while being ip-independet would not work for Ipv6, the reason is addressing. We need new kind of addresses and they all require id that TCP can use for establishing connection and that ID can not be limited to 32 bit so we end up considering reusing part of IPv6 space for this new kind of non-ip addresses. I think given large amount of available IPv6 space that is acceptable - if we cut the pool to 1/4 we'd still have enough. Correcting myself... Its not that you can not use multi6 with IPv4 - you can but your ip stack will need to be IPv6 capable in order to do it and programs and service should be prepared to deal with 128bit addresses for TCP/UDP connections. So upgrade to support IPv6 will still be necessary, but its not a requirement to actually run ipv6 network. Of course to support something like HIP or Multi6 you will need yet another upgrade to your ip stack and we really should have been pushing these upgrades together with IPv6 itself. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Sun, 21 Nov 2004 [EMAIL PROTECTED] wrote: This seems to imply several things: - when having lots of sites, you typically want to obtain local Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business this is an assertion which many have claimed is false. based on empericial evidence. - you don't want to backhaul all the traffic in the internal network / VPNs, so you'll either need to announce a lot of more specifics or use IP addresses from local internet providers this is also an assertion based on false premise. Care to offer a couple of examples of this empirical evidence ? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: who gets a /32 [Re: IPV6 renumbering painless?]
No connectivity to the internet? - use ULA, quick, easy, cheap. ULA leaves a bad taste for a number of reasons, some of which have seen some discussion. What has not occured, and seems to be a major tenent of the ULA zelots, is how conflict resolution is to be done. if ULA is sufficent, in and of itself, then why do we need to have all the rest of the 128bits of space? if ULA users ever have a conflict (and yes, they will) how will the conflict be resolved? and then there is the nasty delusion of Internet... protestations to the contrary, the VSNL view of the Internet is vastly different than the US DOD view of the Internet, is vastly different than the GE view, is different than the AS 701 view, is different than the Chinese RE Network (CERN) view which one(s) count? Policy routing dictates that there is no such thing as a global routing table... For me, as long as I have IP reachability to those folks whom I want or need to talk to, I could care less about the rest of the folks using IP to move datagrams about ... Greets, Jeroen
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business this is an assertion which many have claimed is false. based on empericial evidence. Care to offer a couple of examples of this empirical evidence ? attached. care to provide counter examples? -- Pekka Savola You each name yourselves king, yet the well... postings to the list indicate cisco only has four egress points, from my experience, Texas Instruments, Dupont, EDS, and several others for which the NDA holds. all these enterprises have substantial corporate networks and few egress points into the commodity Internet. you might look at Apple, HP, Sony, LG, BrownRoot, Citi, Microsoft, BAE, Airbus, ING, etc... and consider why these folks would use the commodity internet to move around their corporate data. or perhaps you are modeling a different enterprise? --bill
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
I have worked for multiple enterprises where both of the statements below were false. There are many enterprises which run their own backbones, have internet access at some subset of their sites, and, backhaul all traffic on their own backbone to enforce policy at the internet borders. Some of them use internet based VPNs as part of their backbone, but, in those cases, most have forced ALL traffic leaving the site through the VPN, so, users at the site have no direct or independent internet access. The VPN terminators are, in those cases, usually on PA space. The office network is usually either RFC-1918 or PI space depending on the enterprise. All of the enterprises with which I am familiar would prefer PI space to RFC-1918, but, because of IPv4 limitations, some accepted 1918. Most will not accept a 1918-like solution in v6. I cannot name the enterprises because of NDA issues, but, there are at least 10 that I know of that expect to go to PI space in v6. Owen --On Monday, November 22, 2004 8:24 PM +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Sun, 21 Nov 2004 [EMAIL PROTECTED] wrote: This seems to imply several things: - when having lots of sites, you typically want to obtain local Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business this is an assertion which many have claimed is false. based on empericial evidence. - you don't want to backhaul all the traffic in the internal network / VPNs, so you'll either need to announce a lot of more specifics or use IP addresses from local internet providers this is also an assertion based on false premise. Care to offer a couple of examples of this empirical evidence ? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- If it wasn't crypto-signed, it probably didn't come from me. pgpjM5BFpB1MY.pgp Description: PGP signature
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Mon, 22 Nov 2004 20:24:15 +0200 (EET), Pekka Savola [EMAIL PROTECTED] wrote: On Sun, 21 Nov 2004 [EMAIL PROTECTED] wrote: This seems to imply several things: - when having lots of sites, you typically want to obtain local Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business this is an assertion which many have claimed is false. based on empericial evidence. ... Care to offer a couple of examples of this empirical evidence ? Well you'll have to get some kind of link unless you don't want to move packets. Leave it up to the business case to dictate your connection type. At least on the topic of backhauling traffic over the vpn, it's really no worse than having all your offices connect back to the central site in plaintext. Crypto is cheap these days. When my 133MHz home firewall can push 50Mbps down the vpn with a $70 crypto board, there's no way a simple VPN can be considered pretty heavy business. Look at all the CPU vendors squawking about on-die crypto (to say nothing of the vendors of crypto cards). There are a number of decent vendors of VIA C3 based systems without any need for moving parts that'll give you full duplex crypto on 3 100mbit links with processor time and bus cycles to spare. /me waits for Henning to say something about openbsd and C3's... -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
While I would never argue there are companies who do not push internal data over the Internet, I am surprised you think that proves no company pushes internal data over the Internet. i don't. my assertion is that there are significant networks that don't ever touch what we think of as the internet but still use IP to push datagrams around... and attempting to marginalize them as fringe networks that must use non-global addresses is, imho, arrogent at best. As for counter examples, I know of a few, but confidentiality does not allow me to discuss corporate network topology on a public mailing list. Does this mean it never happens (i.e. I am lying)? If you believe that, so be it. However, the facts are still the facts, no matter what your belief is. i know quite a few as well, the NDA still holds. -- TTFN, patrick
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Nov 22, 2004, at 2:00 PM, [EMAIL PROTECTED] wrote: While I would never argue there are companies who do not push internal data over the Internet, I am surprised you think that proves no company pushes internal data over the Internet. i don't. my assertion is that there are significant networks that don't ever touch what we think of as the internet but still use IP to push datagrams around... and attempting to marginalize them as fringe networks that must use non-global addresses is, imho, arrogent at best. A, my apologies. We are in agreement, and I thought otherwise. I'll try to read more carefully next time. :-) -- TTFN, patrick
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Mon, 22 Nov 2004 [EMAIL PROTECTED] wrote: While I would never argue there are companies who do not push internal data over the Internet, I am surprised you think that proves no company pushes internal data over the Internet. i don't. my assertion is that there are significant networks that don't ever touch what we think of as the internet but still use IP to push datagrams around... and attempting to marginalize them as fringe networks that must use non-global addresses is, imho, arrogent at best. I'm not sure anyone is marginalizing them. The point just is that are those very big, international networks advertising the same aggregate in all the places they (publicly) connect to the net, and no more specifics anywhere? I.e., what I'd like to see is a couple of example of international big enterprises which would not need to advertise the more specifics to Internet anywhere. How rare is this? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: who gets a /32 [Re: IPV6 renumbering painless?]
the tyres on this this thread are getting threadbare. let's finish soon. (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) Wasn't it more because a single A6 lookup could cause one (the resolver that is ;) to have to follow a overly long chain of A6/DNAME chains, which thus could cause maybe somewhat infinite lookups? no. I rather like DNAME btw: ip6.int DNAME ip6.arpa, which works quite fine. see http://www.isc.org/pubs/tn/ for a way to do your own block while you wait for the toplevel ip6.int administrator to see things your way. A6 is fortunately not supported any more by BIND. server-side support of A6 doesn't matter since no modern ipv6 client looks for it. just as client-side support of DNAME doesn't matter since the server will synthesize a CNAME whenever it emits a DNAME. 1. A6/DNAME were great idea, I'm really disappointed they are not going forward... It is, except maybe for the above noted 'problem'. that never was the problem. but the current problem is, got loose in the client population, so other than by server side A6- synthesis (which is either very difficult or impossible to do, depending on whom you ask), A6 is just plain dead. What is bad however is that IETF instead of pursuing it as one effort has several of them including MULTI6, HIP, etc. The fun of politics ;) this fun is by design, though. ietf does not speak with a single voice; even the periodic pronouncements from that era's IAB are at best advisory in nature. the reason you see several working groups working on unrelated solutions to the same problem is that several groups of people each wanted to work together on unrelated solutions to the same problem. there's no real facility in ietf for saying no, we've already picked a different solution to this, don't try.
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
Pekka, All of the examples I referenced (which I unfortunately cannot name due to NDA) fit exactly the model you are referring to. They advertise a small number of prefixes from a small number of sites to cover a very large and diverse number of sites. They advertise the same set of prefixes from the same ASN in each of those sites. In cases where they are using VPN for backbone, they use PA space for the VPN terminators and do not advertise more specifics to accommodate this. Hope that helps. Owen --On Monday, November 22, 2004 9:11 PM +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Mon, 22 Nov 2004 [EMAIL PROTECTED] wrote: While I would never argue there are companies who do not push internal data over the Internet, I am surprised you think that proves no company pushes internal data over the Internet. i don't. my assertion is that there are significant networks that don't ever touch what we think of as the internet but still use IP to push datagrams around... and attempting to marginalize them as fringe networks that must use non-global addresses is, imho, arrogent at best. I'm not sure anyone is marginalizing them. The point just is that are those very big, international networks advertising the same aggregate in all the places they (publicly) connect to the net, and no more specifics anywhere? I.e., what I'd like to see is a couple of example of international big enterprises which would not need to advertise the more specifics to Internet anywhere. How rare is this? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- If it wasn't crypto-signed, it probably didn't come from me. pgpfIhvXlaRD6.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 22-nov-04, at 17:53, Mohacsi Janos wrote: And don't forget that you still have to change your phone number when you move a great enough distance. In IP we somehow feel it's important that there are no geographical constraint on address use at all. That's a shame, because even if we aggregate by contintent that would save up to four times in the number of entries in the routing table of any router. Then why geographic based aggregated IPv6 addresses disposed? Geographic based addresses can solve the agregation quite nicely. The general objection (apart from incorrect assumptions based on old incomplete work) is that network topology and geography don't correlate. My counter-objection is that the correlation doesn't have to be 1 to be able to take advantage of it when it's present. Unfortunately the uniqueness can be problematic How do you mean?
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, 22 Nov 2004 21:28:06 +0100, Iljitsch van Beijnum said: The general objection (apart from incorrect assumptions based on old incomplete work) is that network topology and geography don't correlate. My counter-objection is that the correlation doesn't have to be 1 to be able to take advantage of it when it's present. On the other hand, unless you have some way to *enforce* a higher correlation than we already have, how do you propose to get a better result than we currently (mostly accidentally) get via CIDR aggregation? For instance, 212.x.y.z is known to be on one continent, and so on - but how do you leverage that into a 212/8 routing entry? pgpup3w0a8RDG.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sat, Nov 20, 2004 at 11:34:07AM -0600, Stephen Sprunk wrote: That's right. If you need internet access, you need it to be faster than 16 kbps. Who said the only purpose of IP was to connect to the Internet? 16kbps is the lowest I've seen only because that's the smallest you can buy in the FR world (Sprint's 0kbps PVCs aside). Many businesses were fine (and still 4k and 8k PVCs are available (and in use) in some regions. I have seen them in Africa and southern Asia mainly. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM It is quite possible to use these links to connect sites to the internet. Not for surfing mp3-sites maybe, but having a terminal session to some other business partners machine. The corporate mainframe world allows for many things on small bandwidth, even if some providers don't like it. ;-) capacity is generally more expensive than IP connectivity. At higher bw levels, that might be true, but at sub-T1 rates FR/ATM are often cheaper to build your own network and certainly offer lower latency and higher reliability; ditto for outside major cities, where FR/ATM typically offers a zero-mile loop whereas IP connections may need to be backhauled a hundred miles or more. If T1 Internet pipes are cheaper at a Servicelevels on the Internet suck. Thats the main reason not to use it for anything important. If my frame-connection fails I open my hand and my provider pays a lot until it works again. If the Internet fails, I have no one I can squeeze the money out of. That massively increases a FR-Providers motivation to have their network running. Penalties can never make up for a lost connection (no provider has enough cash at hand) but it is a nice PART (P=Provider). particular location, some people may choose to tunnel their corporate network over it, but that is typically _all_ traffic, not just internal traffic. Centralized Internetgateways are common practice. Everything has to go through these (and their filters, Virus Scanners, whatnot). There's also a security motivation as well: it's much simpler to maintain a couple firewalls at central sites (with technical staff present) than to manage thousands out at every site with a handful or even zero human users which may not even be allowed Internet access in the first place. Especially with users having physical access to the firewalls. Securitywise you do not want that, but if you have internetaccess in each location users can just bypass the firewall too easily. With a framerelay network they can plug in something else to the wall but won't get anywhere else then with their normal equipment, so they do not do it due to the lack of advantage. Nils
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sun, Nov 21, 2004 at 07:40:52PM +0100, Iljitsch van Beijnum wrote: Who said the only purpose of IP was to connect to the Internet? Not me. But if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-) The point is, that these days applications such as mail and web are sufficiently heavy that you can't even run them cost effectively over dial up (wasting your employee's time costs more than the fatter line) let alone less. The Fork Lift driver in some random warehouse does not need email. All he needs is his Barcode scanner to send an 8Digit-Number over the line every 1 or two minutes and get an equal length reply telling him where to Haul the box whose barcode he just scanned. Nils
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 22-nov-04, at 21:42, [EMAIL PROTECTED] wrote: that network topology and geography don't correlate. My counter-objection is that the correlation doesn't have to be 1 to be able to take advantage of it when it's present. On the other hand, unless you have some way to *enforce* a higher correlation than we already have, how do you propose to get a better result than we currently (mostly accidentally) get via CIDR aggregation? There is no enforcing as such. All the gory details are in http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr -01.txt For instance, 212.x.y.z is known to be on one continent, and so on - but how do you leverage that into a 212/8 routing entry? Well, suppose we know 212/8 is used in Europe. A network that is present in say, North America and Europe then has the routers in Europe that talk to the routers in America filter out all 212/8 more specifics and only announce the aggregate instead. In the simple version this only works if there is full interconnection for all 212/8 destination in Europe. In the more complex version there is selective deaggregation for some destinations to overcome lack of local peering.
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On 22-nov-04, at 19:48, [EMAIL PROTECTED] wrote: you might look at Apple, To pick just one example, here is what AS714 is sourcing: Network Next HopMetric LocPrf Weight Path * i17.0.0.0/9 8.21.82.8580110 0 65453 2914 12182 714 i * i17.0.0.0 8.21.82.8580110 0 65453 2914 12182 714 i * i17.64.0.0/12 15.69.14.160 4294967294120 0 65466 714 i * i17.72.0.0/16 15.69.44.160 4294967294120 0 65466 714 i * i17.81.0.0/16 8.21.82.8580110 0 65453 3320 4628 714 i * i17.82.0.0/16 8.21.82.8580110 0 65453 3320 4628 714 i * i17.83.0.0/16 8.21.82.8580110 0 65453 3356 3356 3356 3356 3356 2915 714 i * i17.84.0.0/16 8.21.82.8580110 0 65453 3320 4628 714 i * i17.86.0.0/16 8.21.82.8580110 0 65453 1239 4648 2764 714 i * i17.87.0.0/16 8.21.82.8580110 0 65453 3320 4628 714 i * i17.106.0.0/158.21.82.8580110 0 65453 7018 714 i * i17.112.0.0/168.21.82.8580110 0 65453 7018 714 i * i17.128.0.0/9 8.21.82.8580110 0 65453 2914 12182 714 i * i17.251.0.0/168.21.82.8580110 0 65453 2914 12182 714 i * i17.252.65.0/24 8.21.82.8580110 0 65453 7018 714 i * i17.254.0.0/228.21.82.8580110 0 65453 2914 12182 714 i * i192.35.50.0 8.21.82.8580110 0 65453 2914 12182 714 i * i198.183.16.0 8.21.82.8580110 0 65453 2914 12182 714 i * i198.183.17.0 8.21.82.8580110 0 65453 2914 12182 714 i * i203.14.177.0 8.21.82.8580110 0 65453 1239 4648 2764 714 i * i203.24.95.0 8.21.82.8580110 0 65453 1239 4648 2764 714 i * i205.180.175.08.21.82.8580110 0 65453 2914 12182 714 i If all active ASes did this we'd have a 400k routing table. So please no PI in IPv6, not even for large enterprises.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 22-nov-04, at 17:53, Paul Vixie wrote: so there. those are my views. aren't you glad you asked? Sure. It seems to me though, that if renumbering is such a problem, maybe we should deal with it directly rather than dump the fallout in the three most critical parts of the internet machinery. It's wrong if these issues that have global impact are decided regionally. yes. i understand that the acid rain people, the ozone layer people, the ice cap people, the whale people, and the ocean oxygen level people, all have that same complaint. human nature on a grand scale isn't always pretty. Well if you feel you need to take your cues from environmental semi-criminals, obviously there isn't much that I can say to stop you. I'm thoroughly unhappy with the way this is handled at RIPE (regardless of the outcome) and I'm not about to go sponsor the airline industry some more in order to experience the same frustration in APNIC, LACNIC and ARIN meetings. If we're going to make stupid decisions we might as well streamline the process to make them as efficiently as possible...
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
If all active ASes did this we'd have a 400k routing table. So please no PI in IPv6, not even for large enterprises. er... we'd have no such thing. -you- might, you get to have total control over what prefixes are instanciated in -your- router. you seem to have the unmitigated gaul to presume to tell me what i may or may not place in -my- routing table. neither you nor the IETF has that right. --bill
Re: who gets a /32 [Re: IPV6 renumbering painless?]
It's wrong if these issues that have global impact are decided regionally. yes. i understand that the acid rain people, the ozone layer people, the ice cap people, the whale people, and the ocean oxygen level people, all have that same complaint. human nature on a grand scale isn't always pretty. Well if you feel you need to take your cues from environmental semi-criminals, obviously there isn't much that I can say to stop you. i seem to be pretty much done defending myself against your bizarre misinterpretations of my positions. or at any rate, done for today, except to remind you that on the internet, everyone always acts globally, and most people nearly always thinks locally.
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Nov 22, 2004, at 7:01 PM, Iljitsch van Beijnum wrote: If all active ASes did this we'd have a 400k routing table. So please no PI in IPv6, not even for large enterprises. Why is an ISP more worthy or PI space than a large enterprise. In fact, ISPs are responsible for far, far more table pollution than enterprises. Pot-Kettle-Black? Besides that, please remember the Internet is a business, not a research tool or a toy for those with enable. Business have business needs. If the Internet cannot satisfy them, then the Internet will not be paid for its services. This ain't 1999 no more, you need your customers. -- TTFN, patrick
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
ok, i'll bite. [EMAIL PROTECTED] (Patrick W Gilmore) writes: Why is an ISP more worthy or PI space than a large enterprise. In fact, ISPs are responsible for far, far more table pollution than enterprises. Pot-Kettle-Black? to ask about worthiness is to presuppose a valuer. worthy in whose eyes? that's not as simple as it might sound. it's not the public. it's the great collective of people and companies who own and who pay for the routers in whose routing tables you're asking for a slot. once you figure out the value-perspective, figuring out worthiness is easy. you're worthy of a slot if their customers/endusers want to exchange packets with the destinations covered by the prefix occupying a slot. sadly, this doesn't map to local economics. the great collective of which i speak will gladly spend a slot on an isp who brings lots of eyeballs or lots of content to the table. they aren't so willing to spend a slot on helping wal-mart or ford avoid a renumbering penalty. fortunately or unfortunately, the great collective of which i speak has no voice (or actually it has too many voices, which comes to the same thing). -- Paul Vixie
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: more importantly though is your /40 example. ipv6 has enough address space in it to be able to give a /32 to every household on the planet, including a reserve for the ones without electric power or phones. giving out /40's If we ever make contact to some other civilization out there, do they have to run NAT? Pete
Re: who gets a /32 [Re: IPV6 renumbering painless?]
--On 21 November 2004 11:59 +0200 Petri Helenius [EMAIL PROTECTED] wrote: If we ever make contact to some other civilization out there, do they have to run NAT? Nah. Jim Fleming tells me they're running IPv8 (ducks) Alex
large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
I think this is important point that needs to be called out explicitly. On Sat, 20 Nov 2004, Iljitsch van Beijnum wrote: On 19-nov-04, at 17:58, Stephen Sprunk wrote: these organizations tend to have multiple sites (as you indicate above) but they generally do not have real connectivity between those sites. This means a single large prefix won't do them much good, and basically they're no different than a bunch of smaller single-site organizations. Don't have real connectivity? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf ATT, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks real because each site may only have a 16k PVC to talk to corporate? That's right. If you need internet access, you need it to be faster than 16 kbps. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. If we reword the last sentence to include the use of ULA addresses, to be like: So a single, globally routable large address block is of little use to such an organization, unless they get to announce more specifics all over the place. This seems to imply several things: - when having lots of sites, you typically want to obtain local Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business * though at least the smallest sites are also likely to be solely obtain their connectivity using VPNs through centralized firewalls etc. - you don't want to backhaul all the traffic in the internal network / VPNs, so you'll either need to announce a lot of more specifics or use IP addresses from local internet providers - giving those big enterprises globally routable PI will make it much more lucrative for them to request allowing the more specifics from their upstreams, etc., thus getting us to the more specific mess. Therefore, if we'd like to to prevent the more specific multihoming/traffic engineering mess we have with v4, most of those big enterprises don't really seem to need globally routable PI space, provided that they can already use ULAs if they want. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: who gets a /32 [Re: IPV6 renumbering painless?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-19, at 12.46, Jeroen Massar wrote: On Fri, 2004-11-19 at 12:15 +0100, Iljitsch van Beijnum wrote: On 18-nov-04, at 18:02, Jeroen Massar wrote: Larger enterprises probably consist of 200 'sites' already, eg seperate offices, locations etc. Thus they can, after becoming a LIR and getting an ASN, which most of the time they already have, easily get a /32. Jeroen, this is nonsense and you know it. It is not nonsense as long as 'multi6' doesn't have a solution to the problem, but as politics go above getting solutions... I am not sure I follow you here? Multi6 in D.C decided to spin of the protocol work in a new WG under the Internet Area. I think that for the last few years, multi6 has moved forward as fast as anyone could ask. - - kurtis - / Co-chair multi6 -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQZ9b8qarNKXTPFCVEQLV2wCg+XtQqEH/oo0QjoT4a3LHag8YHlwAoP2I L/o/iD6ydT1aXpIz5xYR3MLO =s/g5 -END PGP SIGNATURE-
Re: who gets a /32 [Re: IPV6 renumbering painless?]
if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. *WHEN* the ipv6 routing table gets as large as the ipv4 routing table is today (late 2004, when you quote me later) it won't be a problem. As a matter of fact, I would bet that Cisco , Juniper, and any other edge/core router manufacturer are banking on this happening. if it were just the routers, then you're apparently expecting the same owners to need better ones, and i agree that a router vendor would probably look very favourably on such a development. however, i'm counting on new owners needing their first routers, and an O(1e6) sized routing table doesn't make any difference there -- a router vendor might be even happier, in fact. but it's not just the routers, it's churn. it's always noon somewhere. the stability of the distributed system called the global routing table is directly proportional to its size. the number of participants in that system, each of whom must build their own model of the system using only the messages they get from direct neighbors, cannot usefully exceed *some* maximum for any given total number of discrete destinations. if you think that the number of available participants leads to a maximum stable table containing O(1e6) destinations, then you should be arguing for a /20 minimum allocation size. If you think the table in question has O(1e10) destinations then you'd be arguing for a /30 minimum allocation size. But to consider a /40 minimum allocation size, you'd be saying that you thought a table containing O(1e12) discrete destinations, and i think that's false in two ways -- first, the current distance-vector approach used by BGP just won't scale to O(1e12), and second, i don't think that you think that there are enough participants who want to own routers to make such a table size necessary. someone asked about my sole benefit comment, so i'll amend it. it's not a global cost and sole benefit, but it is a global cost to the other ends with the preponderance of benefit (for a prefix) falling on the owner of the prefix. so it's not one-sided but it is certainly an assymetric benefit with a symmetric cost. mr. doran argued for many years that routing table slots should be auctioned or leased. i never did and still do not agree with him, but his starting assumptions weren't and aren't my point of disagreement. -- Paul Vixie
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 20-nov-04, at 18:34, Stephen Sprunk wrote: Don't have real connectivity? That's right. If you need internet access, you need it to be faster than 16 kbps. Who said the only purpose of IP was to connect to the Internet? Not me. But if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-) The point is, that these days applications such as mail and web are sufficiently heavy that you can't even run them cost effectively over dial up (wasting your employee's time costs more than the fatter line) let alone less. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. In my experience, they will announce the aggregate from all hub sites plus more-specifics for that hub and the sites directly connected to it. Traffic that comes into the wrong hub due to prefix length filters (or Internet outages) is back-hauled inside the corporate backbone. It would be interested to see some good statistics on this stuff. However many enterprises any of us has seen from the inside, it's still unlikly to be a statistically relevant sample.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 20-nov-04, at 21:45, Paul Vixie wrote: for all these reasons, large or multihoming endsystems will need V6 PI allocations and at some point the RIRs are going to have to define/allow this. I find your attitude in this regard disturbing, especially as: (note that i'm not speaking for arin, nor as a member-elect of arin's board of trustees, i'm just another bozo on this bus.) You're bascially saying that you and people like you are so important that you deserve to receive benefits that go against the public good. While you're high and dry, the hoi polloi can renumber while at the same time suffering increased ISP costs because of the unnecessarily high hardware costs created by all those PI prefixes. In other words, today's equivalent of let them eat cake. It also shows contempt for the IETF, as you reject all possible alternatives to PI out of hand. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. Work is underway to remedy this. However, if the RIRs decide to open up PI in IPv6, people will take the quick fix and there won't be any push to get the (admittedly) more complex but more scalable solutions to these problems off the ground.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
for all these reasons, large or multihoming endsystems will need V6 PI allocations and at some point the RIRs are going to have to define/allow this. I find your attitude in this regard disturbing, especially as: (note that i'm not speaking for arin, nor as a member-elect of arin's board of trustees, i'm just another bozo on this bus.) You're bascially saying that you and people like you are so important that you deserve to receive benefits that go against the public good. actually, i'm just trying to keep my role as member-elect of arin's BoT separate from my role as an internet citizen. as it turns out, arin's BoT does not have a policy formation role. when this issue comes up in PPML or the AC, i'll speak up, but i'll be explicitly hatless when i do. While you're high and dry, the hoi polloi can renumber while at the same time suffering increased ISP costs because of the unnecessarily high hardware costs created by all those PI prefixes. In other words, today's equivalent of let them eat cake. you are drastically misunderstanding my hopes, my goals, and my role. It also shows contempt for the IETF, as you reject all possible alternatives to PI out of hand. i never rejected all possibilities, just the ones i've personally studied so far. i'm also on record as saying that the easiest time to have fixed this was before the current IPng approach was annointed; now we're playing catchup. even you in your multi6 role ought to be wishing that more had been done before IPv6 was cast in stone. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. Work is underway to remedy this. However, if the RIRs decide to open up PI in IPv6, people will take the quick fix and there won't be any push to get the (admittedly) more complex but more scalable solutions to these problems off the ground. somehow i don't think that's going to sway wal-mart's thinking at all, but i do look forward to a lively debate next time this comes up on PPML. the codification of the current approach as IPng in spite of objections raised at that time amounted to a recommendation of let them eat NAT.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 20-nov-04, at 18:34, Stephen Sprunk wrote: Don't have real connectivity? That's right. If you need internet access, you need it to be faster than 16 kbps. Who said the only purpose of IP was to connect to the Internet? Not me. But if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-) The point is, that these days applications such as mail and web are sufficiently heavy that you can't even run them cost effectively over dial up (wasting your employee's time costs more than the fatter line) let alone less. That assumes the company wants their employees using web or email, or that there are even humans at a site to begin with. Pipeline control systems, weather stations, cash registers, credit card machines and ATMs, warehouse inventory scanners, stock exchanges, etc. have no need to _directly_ talk to the outside world. People in customer-facing roles, like those at banks or airports, are not supposed to be surfing the web or even doing email at work. Many companies are still using green-screen apps or graphical applications that have a measured per-terminal average of under 1kbps; I ran into one company tunneling 9600bps serial over X.25 over IP -- ugly, but it worked for thousands of terminals. However, all of these low-bandwidth hosts in far-off lands talk to a corporate datacenter somewhere, perhaps their own or a vendor's or customer's, and those hosts often talk to several other hosts who might also need (or at least have) access to the Internet. The options are NAT, ULAs, or PI space; total cost of implementation seems lowest for ULAs. In my experience, they will announce the aggregate from all hub sites plus more-specifics for that hub and the sites directly connected to it. Traffic that comes into the wrong hub due to prefix length filters (or Internet outages) is back-hauled inside the corporate backbone. It would be interested to see some good statistics on this stuff. However many enterprises any of us has seen from the inside, it's still unlikly to be a statistically relevant sample. An unfiltered BGP feed should give you stats on what's quoted immediately above. If you want numbers of publicly-invisible hosts, even if you knew who to ask most would refuse to answer for security reasons or require an NDA. My best guess, having been on the inside at a few dozen enterprises, is that they number in the high millions to low tens of millions today. In five years, it'll be in the mid tens of millions as more and more new hardware comes with IP connectivity built-in and legacy apps are gradually updated. 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
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Somebody said: if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. *WHEN* the ipv6 routing table gets as large as the ipv4 routing table is today (late 2004, when you quote me later) it won't be a problem. Agreed. When the IPv6 table has as many routes as today's IPv4 table, we'll need four times the storage; Moore's Law says, as long as that doesn't happen within 36 months, it's not a problem. I haven't seen anyone (recently) predict IPv6 adoption will be anywhere near that fast, much less faster. Thus spake Paul Vixie [EMAIL PROTECTED] but it's not just the routers, it's churn. it's always noon somewhere. the stability of the distributed system called the global routing table is directly proportional to its size. the number of participants in that system, each of whom must build their own model of the system using only the messages they get from direct neighbors, cannot usefully exceed *some* maximum for any given total number of discrete destinations. ... first, the current distance-vector approach used by BGP just won't scale to O(1e12), Probably not, even if router vendors start using reasonably modern processors. and second, i don't think that you think that there are enough participants who want to own routers to make such a table size necessary. As a point of reference, today in IPv4 there are 16k origin-only ASes. Assuming reasonably sane RIR policies, we can expect -- even with the issue of one PI prefix per AS -- that there would be 16k end-site PI routes today, with linear growth similar to the current allocation rate of ASNs. This is not even remotely a problem until well after we have to switch to 32-bit ASNs; in fact, the situation will be far better than what we will likely have with IPv4 at that point. mr. doran argued for many years that routing table slots should be auctioned or leased. i never did and still do not agree with him, but his starting assumptions weren't and aren't my point of disagreement. The idea has obvious appeal, but it seems like a clear case of the cure being worse than the illness once you consider the logistical and technical requirements. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: But to consider a /40 minimum allocation size, you'd be saying that you thought a table containing O(1e12) discrete destinations Except that we are talking about allocations out of 2001::/16 which yeilds a about 1e7 prefixes, not subtracting the huge chunks taken by /32 allocations. The idea with using a /16 for initial allocations is that we don't screw up the entire /0 before we know what we are doing. In the scope of a /16, I think /32 and /40 allocations are sized appropriately. The real question is why exchange points and root servers are allocated /48's. It would make sense to use a different prefix length to reduce the temptation for other /48's to pollute the table.
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. This seems to imply several things: - when having lots of sites, you typically want to obtain local Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business this is an assertion which many have claimed is false. based on empericial evidence. - you don't want to backhaul all the traffic in the internal network / VPNs, so you'll either need to announce a lot of more specifics or use IP addresses from local internet providers this is also an assertion based on false premise. Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 19-nov-04, at 17:58, Stephen Sprunk wrote: these organizations tend to have multiple sites (as you indicate above) but they generally do not have real connectivity between those sites. This means a single large prefix won't do them much good, and basically they're no different than a bunch of smaller single-site organizations. Don't have real connectivity? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf ATT, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks real because each site may only have a 16k PVC to talk to corporate? That's right. If you need internet access, you need it to be faster than 16 kbps. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. learn to love renumbering. And again, IPv6+NAT makes no sense as NAT works much better with IPv4 and with NAT you don't really need the larger address space. If I have a disconnected network, why would I use NATs or be forced to renumber periodically? I have no idea. Use unique local addresses instead. Why should disconnected networks use global addresses (and pay rent to the RIRs) in the first place? There aren't many networks around that are truly disconnected. Even disconnected networks connect to stuff that connects to other stuff that connects to the internet at some point. This means that disconnected address space must not overlap with addresses used on the internet. We have that in RFC 1918. However, disconnected networks tend to interconnect with other disconnected networks from time to time, which means trouble if they both use the same address space. This is where ULAs come to the rescue.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 19-nov-04, at 18:50, Christian Kuhtz wrote: why would the enterprise care to switch to IPv6 in the first place? Because it's easier to build a big IPv6 network than to build a big IPv4 network. I think over the next few years we'll see people building IPv6 networks and then tunneling IPv4 over them as it's easier to have the infrastructure parts run IPv6, especially (but not exclusively) if IPv4 address space is less than abundant. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged Yes; I don't care. I'm assuming it is not possible to leave this out, but could you please have some kind of separator between your actual message and the lawyerese so it's easier to ignore the latter?
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 19-nov-04, at 19:23, Owen DeLong wrote: There is no reason for RIRs to allocate addresses which would never be used on public networks. If the addresses are suppose to be unique, then, what is the reason NOT to have the RIRs allocate them? The reason is that the RIRs don't talk to end-users. (At least, they don't talk to 99.99% of all end-users.) Having to go through a LIR (ISP) to obtain addresses that may remain in use after a customer leaves also seems strange. Why set up a separate registry system for these addresses instead of making minor changes to the existing one to accommodate this need? This is a good point. But rather than reuse the RIRs for this, we should reuse the domain registry system for this. Domain sellers already know how to deal with millions of customers (collectively) and make a business based on very small yearly fees, they already deal with the majority of the prospective users of this address space and there is healthy competition.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 19-nov-04, at 18:40, Owen DeLong wrote: Now I hate to be the bearer of bad news, but having unaggregatable globally routable address space just doesn't scale and there are no routing tricks that can make it scale, whatever you put in the IP version bits, so learn to love renumbering. This is patently false. If it were true, then I would have to renumber every time I changed telephone companies. I don't, so, obviously, there is some solution to this problem. Well, the old saying is that there is no problem in computer science that can't be solved by adding a layer of indirection. Apparently this applies to telephone networks as well, because your phone number is no longer an address these days: it's more like a domain name. When you dial a number it's looked up in a big database to see where the call should go to. And don't forget that you still have to change your phone number when you move a great enough distance. In IP we somehow feel it's important that there are no geographical constraint on address use at all. That's a shame, because even if we aggregate by contintent that would save up to four times in the number of entries in the routing table of any router.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
--On 19 November 2004 09:40 -0800 Owen DeLong [EMAIL PROTECTED] wrote: If it were true, then I would have to renumber every time I changed telephone companies. I don't, so, obviously, there is some solution to this problem. But I'm not sure you'd like it applied to the internet. Firstly, in essence, PSTN uses static routes for interprovider routing (not quite true, but nearly - if you add a new prefix everyone else has to build it into their table on all switches). Secondly, IIRC porting works in the UK something like - call delivered to switch of operator who owns the block, marked as ported number, lookup in central porting database (one for all operators), operator port prefix put on dialed number, call sent back out all the way to interconnect, enters new operator network, goes to switch managing ports, further signalling info added to make call go to the correct local switch, call goes to correct local switch, dross removed, call terminated. Roughly speaking this is the internet equivalent of: * Configure all interprovider routes by a static routing config loaded every week or so. * Handle porting by getting ICANN to run a box with a primative gated BGP feed connected to all your distribution routers. Where a packet is delivered to a distribution router and the IP address has changed providers, change the next hop received from the ICANN BGP feed to a GRE tunnel to the appropriate provider's tunnel termination box. * At that tunnel termination box, static route all ported-in IP addresses to the correct distribution router. Yum yum. Sometimes we don't have lessons to learn from the PSTN world, and instead the reverse is true. Alex
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 11/20/2004 8:18 AM, Alex Bligh wrote: But I'm not sure you'd like it applied to the internet. Firstly, in essence, PSTN uses static routes for interprovider routing (not quite true, but nearly - if you add a new prefix everyone else has to build it into their table on all switches). Secondly, IIRC porting works in the UK something like - call delivered to switch of operator who owns the block, marked as ported number, lookup in central porting database (one for all operators), operator port prefix put on dialed number, call sent back out all the way to interconnect, enters new operator network, goes to switch managing ports, further signalling info added to make call go to the correct local switch, call goes to correct local switch, dross removed, call terminated. Sounds like DNS. We also get semi-annual drive-by proposals to stick the routing info into DNS, of course. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sat, Nov 20, 2004 at 12:58:17PM +0100, Iljitsch van Beijnum wrote: On 19-nov-04, at 17:58, Stephen Sprunk wrote: Don't have real connectivity? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf ATT, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks real because each site may only have a 16k PVC to talk to corporate? As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity. it is not rare at all, in my experience. my personal dealings with 50+ multinational corporations show that they -ALL- have their own corporate networks that are isolated from the Internet and nearly all run IP over these internal corporate networks. the trival cost of dedicated lines, or FR/ATM cloud, or VPN overlay is much cheaper than a dependance on upstream providers (since no single provider can support their needs) or exposing corporate/trade secrets to the broader internet. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. that does not follow, except from your faulty presumption above. -- bill
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 19-nov-04, at 17:58, Stephen Sprunk wrote: Don't have real connectivity? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf ATT, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks real because each site may only have a 16k PVC to talk to corporate? That's right. If you need internet access, you need it to be faster than 16 kbps. Who said the only purpose of IP was to connect to the Internet? 16kbps is the lowest I've seen only because that's the smallest you can buy in the FR world (Sprint's 0kbps PVCs aside). Many businesses were fine (and still would be) using 2400 baud leased lines and upgraded to FR only because it cost slightly less. A couple cashiers typing text into a green-screen app don't need blazingly-fast IP service, nor would their employer be interested in paying them to surf the web while customers are waiting. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity. At higher bw levels, that might be true, but at sub-T1 rates FR/ATM are often cheaper to build your own network and certainly offer lower latency and higher reliability; ditto for outside major cities, where FR/ATM typically offers a zero-mile loop whereas IP connections may need to be backhauled a hundred miles or more. If T1 Internet pipes are cheaper at a particular location, some people may choose to tunnel their corporate network over it, but that is typically _all_ traffic, not just internal traffic. There's also a security motivation as well: it's much simpler to maintain a couple firewalls at central sites (with technical staff present) than to manage thousands out at every site with a handful or even zero human users which may not even be allowed Internet access in the first place. Even Cisco, last I checked, only connected to the Internet in four places worldwide, though they have hundreds of offices (and full private internal connectivity). Presumably they know what they're doing, or at least have a better clue than enterprises in other industries. Consider that a best case. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. In my experience, they will announce the aggregate from all hub sites plus more-specifics for that hub and the sites directly connected to it. Traffic that comes into the wrong hub due to prefix length filters (or Internet outages) is back-hauled inside the corporate backbone. learn to love renumbering. And again, IPv6+NAT makes no sense as NAT works much better with IPv4 and with NAT you don't really need the larger address space. If I have a disconnected network, why would I use NATs or be forced to renumber periodically? I have no idea. Use unique local addresses instead. Exactly. Why should disconnected networks use global addresses (and pay rent to the RIRs) in the first place? There aren't many networks around that are truly disconnected. Even disconnected networks connect to stuff that connects to other stuff that connects to the internet at some point. This means that disconnected address space must not overlap with addresses used on the internet. We have that in RFC 1918. However, disconnected networks tend to interconnect with other disconnected networks from time to time, which means trouble if they both use the same address space. This is where ULAs come to the rescue. ...and that's why ULAs were proposed by the IPv6 WG. Even networks that have no connectivity to the Internet are often connected to each other, and a subset of those networks will eventually have connectivity to the Internet or another network that does. But there are some truly disconnected networks as well, and ULAs are still a better choice than randomly picking a prefix out of 0::0. 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
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Paul Vixie [EMAIL PROTECTED] [EMAIL PROTECTED] (Stephen Sprunk) writes: isc is multihomed, so it's difficult to imagine what isp we could have taken address space from then, or now. ... Some fear that you would more likely just generate a ULA, use that internally, and NAT at the borders. Or maybe you'd stick with IPv4 RFC1918 space internally and NAT to IPv6 PA space at your borders. the internet endpoint type trend is toward SOHO and dsl/cable, and the provider trend is toward gigantic multinational. companies who build their own networks tend to find that the cheapest interoffice backhaul is IP-in-IP VPN's. thus is the old model of a 1000-person company buying a T1 transit connection moving toward the margins. I'm not experienced with the 1000-person companies; the work I've done is for companies 20 to 100 times that size, so maybe my perception is skewed. SoHo and residential users are definitely a growing percentage of the Internet connection count, but I think they're still a minority of _hosts_ which have Internet connectivity. Enterprises can have tens or hundreds of thousands of hosts behind a single T1 or T3, and may expose only a handful of PA addresses due to NAT. Large universities are similar, except legacy allocations mean they usually don't need NAT. I've also seen a strong tendency in enterprises to backhaul even external traffic on IP VPNs, so that even users with a local Internet pipe have to go through the corporate firewalls to reach the outside world (if that's even allowed). as i continue to research my own premises, i find that the style of internetworking practiced at isc, which precludes PA space due to multihoming and due to possible renumbering penalties, So are you saying that if ISC had not gotten a legacy PI allocation, you wouldn't be using IPv6? Or that you wouldn't be able to design your network the way you'd want to, but would still use IPv6 anyways? is becoming quite rare as a percentage of the total number of network owners and the total number of endpoints thus interconnected. it's sad but it's true and it gives cause to ponder the future of enabling technologies like internet exchange points. I've run into very few enterprises that know they'd even be allowed to join an IX, much less actually interested in doing so. They'd rather pay one or two companies to drop big, fat pipes into their datacenter and collect on SLAs when something goes wrong. Very few, even in the Fortune 100, have the staff to handle their own BGP configs and keep things running smoothly. Humans cost more money than they'd probably save on transit, and the money often comes out of different pockets anyways. I see IXes (IXen?) as a solution for providers, not end-sites. With the relatively lax IPv6 PI policies for providers, the threat to IXes is minimal. this may yet lead to a mechanism for qualifying multihomed network builders to get PI space, since they'll be rare enough to have a low impact on the global routing table. We'll see what the reaction is on PPML. Based on the number of origin-only ASes in yesterday's Routing Table Report, we should expect to see about 16k prefixes from multihomed end-sites if adoption in IPv6 matches that in IPv4. on the other hand, transit-provider lock-in is not officially recognized as having any bearing on any RIR policy in any region; if that continues to be the case, the rare kind of network i'm most familiar with will continue to use ipv4 or will only use ipv6 via something like ULA's. what this may mean is that approving ULA's will make the situation better, since network owners will otherwise just pirate unused space at random. with ULA's we'll at least have a chance to trace leaks and try to make BCP38 happen in more places. Agreed. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] Why set up a separate registry system for these addresses instead of making minor changes to the existing one to accommodate this need? This is a good point. But rather than reuse the RIRs for this, we should reuse the domain registry system for this. Domain sellers already know how to deal with millions of customers (collectively) and make a business based on very small yearly fees, they already deal with the majority of the prospective users of this address space and there is healthy competition. This makes perfect sense. After all, RIRs are just renting domains out of in-addr.arpa. and ip6.arpa. whereas domain registrars are renting domains out of other TLDs. Any competent accountant can turn $15/yr domain rent into an up-front purchase fee to cover registration in perpetuity. 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
Re: who gets a /32 [Re: IPV6 renumbering painless?]
the internet endpoint type trend is toward SOHO and dsl/cable, and the provider trend is toward gigantic multinational. companies who build their own networks tend to find that the cheapest interoffice backhaul is IP-in-IP VPN's. thus is the old model of a 1000-person company buying a T1 transit connection moving toward the margins. I'm not experienced with the 1000-person companies; the work I've done is for companies 20 to 100 times that size, so maybe my perception is skewed. i think all oldtimers are skewed. growth in number of enterprises will be of the small kind where renumbering isn't so painful. exceptions where there is enough size to make renumbering painful won't overflow the routing table the way the ipv4 swamp threatened to do back in the days of 64MB RP cards. ... Enterprises can have tens or hundreds of thousands of hosts behind a single T1 or T3, and may expose only a handful of PA addresses due to NAT. Large universities are similar, except legacy allocations mean they usually don't need NAT. right. for all these reasons, large or multihoming endsystems will need V6 PI allocations and at some point the RIRs are going to have to define/allow this. (note that i'm not speaking for arin, nor as a member-elect of arin's board of trustees, i'm just another bozo on this bus.) as i continue to research my own premises, i find that the style of internetworking practiced at isc, which precludes PA space due to multihoming and due to possible renumbering penalties, So are you saying that if ISC had not gotten a legacy PI allocation, you wouldn't be using IPv6? Or that you wouldn't be able to design your network the way you'd want to, but would still use IPv6 anyways? the second. we'd have built a v6 bastion network and put our public services there and done some kind of overlay thing. for things like my desktop, we'd've stuck with ipv4, or we'd've pirated some site local ipv6 space. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. no, no, no, and again i say, no, that will not be done on my watch. ... it's sad but it's true and it gives cause to ponder the future of enabling technologies like internet exchange points. I've run into very few enterprises that know they'd even be allowed to join an IX, much less actually interested in doing so. They'd rather pay one or two companies to drop big, fat pipes into their datacenter and collect on SLAs when something goes wrong. Very few, even in the Fortune 100, have the staff to handle their own BGP configs and keep things running smoothly. Humans cost more money than they'd probably save on transit, and the money often comes out of different pockets anyways. during my time as president of paix, microsoft and yahoo and google all decided to try their hand at BGP, and all of them found that they could manage both risks and costs better by doing it in-house than by buying transit. if i were still at paix i'd no doubt have sold a few big banks and insurance companies on the concept by this time, as equinix is now doing quite successfully. i thought this was, and still think this is, the best possible direction for the ip connectivity community to grow in. it increases diversity, price pressure, and overall competitiveness. but without endsystem PI's for these large multihomers, it's only going to be the public servers and not the desktops who benefit from this. treating enterprise desktops as being just like the DSL market is a big mistake, and if it's not corrected, then equinix and paix/sd and others like them are going to see a flattening of their growth. I see IXes (IXen?) as a solution for providers, not end-sites. With the relatively lax IPv6 PI policies for providers, the threat to IXes is minimal. i used to love it when people would say that, because it meant i could walk right past them and take their customers simply by offering an alternative that the incumbants couldn't even see. -- Paul Vixie
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sat, Nov 20, 2004 at 08:45:34PM +, Paul Vixie wrote: the second. we'd have built a v6 bastion network and put our public services there and done some kind of overlay thing. for things like my desktop, we'd've stuck with ipv4, or we'd've pirated some site local ipv6 space. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. no, no, no, and again i say, no, that will not be done on my watch. Perhaps it is time to replace TCP with SCTP, where multihoming is not incompatible with PA addressing. If done as a socket shim, so applications don't have to be aware of it unless they want to be, it would appear to solve all of these problems. How much would it add to the pain of the v4-v6 transition, to just bite the bullet and do tcp-sctp at the same time? I'd sure rather be a network troubleshooter going through that than living with NAT forever. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
I've run into very few enterprises that know they'd even be allowed to join an IX, much less actually interested in doing so. Subject: Exchange Update - New Participant Date: Fri, 19 Nov 2004 15:49:59 -0800 Equinix would like to introduce the following peers to the GigE Exchange peering fabrics: - ASH: Walmart.com connected to the Ashburn GigE Exchange You may not have met them but they're out there They'd rather pay one or two companies to drop big, fat pipes into their datacenter and collect on SLAs when something goes wrong. We used to do that, we learned. Very few, even in the Fortune 100, have the staff to handle their own BGP configs and keep things running smoothly. Humans cost more money than they'd probably save on transit, and the money often comes out of different pockets anyways. Many CCIE(paper) end up in enterprises as they still have money and networks large enough to need engineers. I'm sure plenty of them are looking to keep the ISP section of their CV up to date by running the enterprises BGP. We also have enterprises doing BGP between each other on internal, non internet, networks Assumptions about what people should/will want to do are clouding engineering judgment and making things like IPV6 unworkable brandon
Re: who gets a /32 [Re: IPV6 renumbering painless?]
How much would it add to the pain of the v4-v6 transition, to just bite the bullet and do tcp-sctp at the same time? I'd sure rather be a network troubleshooter going through that than living with NAT forever. it's the delta between the finite and the infinite. sctp requires a flag day whereas nat can be deployed incrementally. sctp isn't going to happen, at least not on the scale that nat has happened or that ipv6 will happen.
