Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
In your previous mail you wrote: Has anyone present on this list ever experienced a problem in getting a new chunk of IP addresses from a RIR or from an ISP? = the administrative procedures used by RENATER, the French NREN, are so heavy than nobody wants to follow them to get some address space... Obviously the purpose is to discourage us to ask for chunk of IPv4 addresses. For IPv6 the procedure is painful but usable. What is the average delay you experiment? = infinite for IPv4, two months for IPv6. Regards [EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
On 7 Dec 2004, at 10:33, JFC (Jefsey) Morfin wrote: At 13:38 07/12/2004, Francis Dupont wrote: In your previous mail you wrote: Has anyone present on this list ever experienced a problem in getting a new chunk of IP addresses from a RIR or from an ISP? = the administrative procedures used by RENATER, the French NREN, are so heavy than nobody wants to follow them to get some address space... Obviously the purpose is to discourage us to ask for chunk of IPv4 addresses. For IPv6 the procedure is painful but usable. What is the average delay you experiment? = infinite for IPv4, two months for IPv6. Thank you for this very valuable/key piece of information. What is the particular thing that you find so useful, here? That some LIRs are not as easy to deal with as others? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
At 17:29 07/12/2004, Joe Abley wrote: On 7 Dec 2004, at 10:33, JFC (Jefsey) Morfin wrote: At 13:38 07/12/2004, Francis Dupont wrote: In your previous mail you wrote: Has anyone present on this list ever experienced a problem in getting a new chunk of IP addresses from a RIR or from an ISP? = the administrative procedures used by RENATER, the French NREN, are so heavy than nobody wants to follow them to get some address space... Obviously the purpose is to discourage us to ask for chunk of IPv4 addresses. For IPv6 the procedure is painful but usable. What is the average delay you experiment? = infinite for IPv4, two months for IPv6. Thank you for this very valuable/key piece of information. What is the particular thing that you find so useful, here? That some LIRs are not as easy to deal with as others? That the affirmation that no RIR has ever refused an IPv4 chunk is wrong, and that its documented here while when it was made no one objected. You see, a user only cares about what he realy gets. A partner of mine was unable to get an IPv4 address in 2 years. Same for chunks. I do not think there is any other need to document why there are NATs and no IPv6. NAT is seen as an alternative to IPv6. While IPv6 should be an alternative to IPv4. In blocking IPv4 XIRs block IPv6. Basic marketing. I only helped a few more responses like Francis' one would help to understand there is a problem now, not in a few years. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
Thus spake JFC (Jefsey) Morfin [EMAIL PROTECTED] That the affirmation that no RIR has ever refused an IPv4 chunk is wrong, and that its documented here while when it was made no one objected. You see, a user only cares about what he realy gets. A partner of mine was unable to get an IPv4 address in 2 years. Same for chunks. I do not think there is any other need to document why there are NATs and no IPv6. NAT is seen as an alternative to IPv6. While IPv6 should be an alternative to IPv4. In blocking IPv4 XIRs block IPv6. Basic marketing. We do not know why M. Dupont's request was denied by RENATER, nor is the latter an RIR. LIRs may have their own policies which do not match those of their corresponding RIR, and applicants are free to pick another LIR (or become their own) if necessary. There have been no clearly documented cases, AFAIK, where an RIR has denied a request that met with their policy requirements. One may argue that the policies have unreasonable requirements, but those policies were approved by open process involving the community they serve and (for IPv4) based on the global consensus supporting RFC 2050. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
At 18:27 07/12/2004, Joe Abley wrote: On 7 Dec 2004, at 12:18, JFC (Jefsey) Morfin wrote: What is the particular thing that you find so useful, here? That some LIRs are not as easy to deal with as others? That the affirmation that no RIR has ever refused an IPv4 chunk is wrong, and that its documented here while when it was made no one objected. RENATER is not an RIR. Please let us not try to make a point: we want to _understand_ why NATs develop more than IPv6. RENATER is an acknowledged leader in promoting IPv6: they are certainly not concerned. What is interesting is the way users may perceive the culture deduced from the RIR policy or strategy (which may very well work for others). The interest is not to know who is right (no one is right or wrong) but why there are more NATs than IPv6 and to be able to change that. What works in some/most today cases may not work in every case. I feel, and I try to document, it may be because we want to discuss about a single kind of users (ourselves and operators), rather than to listen to them all (the small networks, home networks). The customer is always right ... all the customers if we want them all. What counts is not the way the network is built, but the way the users understand it. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
On 7 Dec 2004, at 15:46, JFC (Jefsey) Morfin wrote: At 18:27 07/12/2004, Joe Abley wrote: On 7 Dec 2004, at 12:18, JFC (Jefsey) Morfin wrote: What is the particular thing that you find so useful, here? That some LIRs are not as easy to deal with as others? That the affirmation that no RIR has ever refused an IPv4 chunk is wrong, and that its documented here while when it was made no one objected. RENATER is not an RIR. Please let us not try to make a point There seems to be no danger of that. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
On Tue, 7 Dec 2004, JFC (Jefsey) Morfin wrote: At 18:27 07/12/2004, Joe Abley wrote: On 7 Dec 2004, at 12:18, JFC (Jefsey) Morfin wrote: What is the particular thing that you find so useful, here? That some LIRs are not as easy to deal with as others? That the affirmation that no RIR has ever refused an IPv4 chunk is wrong, and that its documented here while when it was made no one objected. RENATER is not an RIR. Please let us not try to make a point: we want to _understand_ why NATs develop more than IPv6. because NAT's have been around in the public eye for a while, are generally understood or at least accepted by the consumer public, and you can go buy one off the shelf. ipv6, on the other hand, outside of the ietf community is an unknown. my best recommendation would be some manner of public awareness propaganda stint promoting v6, combined with rollout at the backbones, followed closely by rollout at the ISP's fed by the backbone to the end users. this does not mean that NAT and ipv6 are mutually exclusive. far from it. from my research, which i have shared with you previously, an already constructed NAT needs only v6 capablility added to the NAT'ed hosts and a v6 native or tunnel support and v6 routing added to it, such that the v6 internet overlays the existing internat. RENATER is an acknowledged leader in promoting IPv6: they are certainly not concerned. What is interesting is the way users may perceive the culture deduced from the RIR policy or strategy (which may very well work for others). The interest is not to know who is right (no one is right or wrong) but why there are more NATs than IPv6 and to be able to change that. What works in some/most today cases may not work in every case. I feel, and I try to document, it may be because we want to discuss about a single kind of users (ourselves and operators), rather than to listen to them all (the small networks, home networks). The customer is always right ... all the customers if we want them all. What counts is not the way the network is built, but the way the users understand it. both count. if they do not understand it to the level of acceptance at least, then how its built does not matter. if its not built correctly, large percentages of migrators will drop anchor and turn around to v4 NAT again. scott jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
At 04:46 08/12/2004, shogunx wrote: both count. if they do not understand it to the level of acceptance at least, then how its built does not matter. if its not built correctly, large percentages of migrators will drop anchor and turn around to v4 NAT again. True. Obviously the techology is of the essence. What I mean is that IPv6 will only take off the day the reason why IPv6 was designed is permitted to be used (to be an IPv4 with larger addresses). This means that users will be permitted to freely innovate in the way they use the Internet in _not_ carring about the type of address they use. And that we do not block this innovative usage in not permitting what this innovation may need, and in not stabilizing the standards. Today I think these needs include legal protection, regalian services, permanent addressing, independence from ISP, plug-and-play, ... Obviously as you say. The internat is the future, with NATs adding functions over functions. But we will then talk more of corebox than NATs. They started as NATs, but once they are under IPv6 - and not a NAT anymore - they will continue to be here, and to provide an increasing pile of services (starting with OPES, and their network overlay and all the possible new architectural non-end-to-end systems .. and all the debates this will rise). So, let talk of interbox. Exciting future. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
On Wed, 8 Dec 2004, JFC (Jefsey) Morfin wrote: At 04:46 08/12/2004, shogunx wrote: both count. if they do not understand it to the level of acceptance at least, then how its built does not matter. if its not built correctly, large percentages of migrators will drop anchor and turn around to v4 NAT again. True. Obviously the techology is of the essence. What I mean is that IPv6 will only take off the day the reason why IPv6 was designed is permitted to be used (to be an IPv4 with larger addresses). what is standing in the way at the isp level are the following: a) support applications. we all know good network operators are usually anal about security. anyone have a packet sniffer for v6? b) revenue streams for isp's. currently, v4 addresses are a commodity item. they cost the end users, no matter who you go to. are the isp's willing to give up these revenue streams for better technology? perhaps the independents, but asking a telco to give up a way to make money once they have already found out how to extract it from the public is like trying to get a sperm sample from your grandmother. good luck. This means that users will be permitted to freely innovate in the way they use the Internet in _not_ carring about the type of address they use. And that we do not block this innovative usage in not permitting what this innovation may need, and in not stabilizing the standards. Today I think these needs include legal protection, why and from whom? regalian services, please define? permanent addressing, solved. my tunnels provide with them my allocations, for all practical purposes. i have had the same v6 addresses on my hosts since i implemented v6 quite some time ago, with 's pointing to the hosts i wished to make public. of course, i have added many more hosts since i implemented v6. people in the know are asking to colo in my home office simply because i have v6. independence from ISP, solved. a tunnel is portable. plug-and-play, ... if you mean stateless autoconfig, then that is solved too. if it is not wit you, then i suggest that you contact your OS vendor, or better yet, move to a better OS;) Obviously as you say. The internat is the future, with NATs adding functions over functions. i'm just saying that since we have NATs, we already have layer 1 of the v6 network in place at the end user premises. But we will then talk more of corebox than NATs. having built one of those and implemented it on the atlanta backbone some months ago (remotely no less) there is a need for real large scale routing hardware to handle v6 expansion at the backbone and isp level. They started as NATs, but once they are under IPv6 - and not a NAT anymore - they will continue to be here, and to provide an increasing pile of services (starting with OPES, and their network overlay and all the possible new architectural non-end-to-end systems IMHO it is the end to end possibilities that are the most exciting. .. and all the debates this will rise). So, let talk of interbox. Exciting future. Indeed. scott jfc sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On 2-dec-04, at 9:54, Simon Leinen wrote: But all of this is only delaying the inevitable (not that that can't be useful sometimes): at some point, we need to move away from the premise that all default-free routers must know about all reachable prefixes. But isn't this the *definition* of a default-free router? That's my point. We need to find some middle ground between using a default and having every single prefix in the world in the table. Maybe you mean we need to move away from the premise that you have to run default-free (full BGP table!) to be taken seriously. Who cares about being taken seriously? :-) No, that's not it. A default doesn't do any good because the only thing it does is move the packets to a place where full routing information is known. Obviously today some people run defaultless because they can and not because they must, but there are also lots of routers that run defaultless because there is no smarter router they can dump the traffic on. With this ball and chain removed we can start looking at new interdomain routing paradigms, such as an idr link state protocol that can function in a never fully converged state. (Which would make for some nice PhD work...) There's lots of exciting new work about loop prevention in link-state internal routing protocols right here in the IETF - check out http://rtg.ietf.org/wg/rtgwg/ I don't see anything except web design with broken assumptions... But correct me if I'm wrong, current link state routing protocols already know how to get rid of loops...? Maybe some of this could be leveraged for a new external routing protocol. (Not that I think that it will be likely that we move from BGP to an entirely new protocol without replacing all current IDR players... but that doesn't mean you shouldn't try :-). A new EGP needs to be able to work with BGP so there is no need for everyone to upgrade at the same time. But even then it won't be easy as network operators are a conservative bunch (much more so than they think they are). Most of all, a new EGP needs to bring compelling benefits to the table. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
Iljitsch van Beijnum writes: But all of this is only delaying the inevitable (not that that can't be useful sometimes): at some point, we need to move away from the premise that all default-free routers must know about all reachable prefixes. But isn't this the *definition* of a default-free router? Maybe you mean we need to move away from the premise that you have to run default-free (full BGP table!) to be taken seriously. (Maybe I'm just bitter because our network runs with only 26783 IPv4 BGP routes (and two defaults), so I cannot play with the big guys. :-) With this ball and chain removed we can start looking at new interdomain routing paradigms, such as an idr link state protocol that can function in a never fully converged state. (Which would make for some nice PhD work...) There's lots of exciting new work about loop prevention in link-state internal routing protocols right here in the IETF - check out http://rtg.ietf.org/wg/rtgwg/ . Maybe some of this could be leveraged for a new external routing protocol. (Not that I think that it will be likely that we move from BGP to an entirely new protocol without replacing all current IDR players... but that doesn't mean you shouldn't try :-). -- Simon. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On Mon, 29 Nov 2004 14:04:05 +0100, Lars-Erik Jonsson (LU/EAB) [EMAIL PROTECTED] wrote: The average Internet user (home user or enterprise administrator) does not care about the end-to-end principle or the architectural purity of the Internet. Maybe not the average user, but a pretty large subset *does* care - because t makes it extremely hard to do what they want... Yes! I think it we should not underestimate the potential demands from and desires of average users. An average user is not my mom, and maybe not even those of our generation. I think an average user, of those who really wants any kind of Internet access, actually can be found among the younger generations, who consider the Internet and all today's technologies natural parts of daily life. Even if they do not care about the e2e principle, they do care about the potential for doing any kinds of peer2peer communication, as they want to play their networking games, they want to share information, they want to try things, experiment, and be independent of what outsiders provide or want to allow (like access providers). Not all home users are demanding, some just want to surf the web, but in most households there is at least one more demanding user, and that user will be the one setting the access requirements of the household. /L-E ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf Using BitTorrent and the growing popularity of VoIP comes to mind. (A shame that Asterisk does not currently support IPv6 though.) -- Mark A. Miller [EMAIL PROTECTED] US +1 512 796 3592 http://mirell.org Vice President and CFO of Linucon http://linucon.org ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On Dec 02, 2004, at 11:11, Mark Miller wrote: Using BitTorrent and the growing popularity of VoIP comes to mind. (A shame that Asterisk does not currently support IPv6 though.) Asterisk community is seeing some effort (particularly from someone quite familiar to the IETF: Marc Blanchet), and folk on the EU 6NET project are keen to get some testing done once progress is made. It will come... and yes, Voice without NAT traversal solutions and true p2p filesharing will be grateful for v6's design. There's also that little thing called the Web that is threatening to crawl out of the server-client pit. We're expecting to see much more on peer-based semantic services using Web application-layer protocols being reliant on ubiquitous Mobile IPv6 and end-to-end addressability. Mark/ -- Electronics and Computer Science a school of the University of Southampton, UK ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: The gaps that NAT is filling
Stephen Sprunk wrote: Clearly, if IPv6 PI space spirals out of control like many operators think will happen, we need to find a way to make BGP (and possibly forwarding) performance not dependent on the number of prefixes in the table. I agree 100%, but this is easier said than done: if we had a silver bullet it would have shown up already; the main issue with the routing table appears to be stability (not memory) to me. If vendors had found the magic potion to handle million prefixes it would be a heck of a good sales pitch in order to get us to buy one more time brand stinking new gear. and maybe it's time we start looking at that in parallel to the work on multi6 and HIP. Realistically it would take more than 10 years to get anything done in this domain. Replacing BGP might not be as hard as replacing IP, but it is a formidable task nevertheless. Michel. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On 1-dec-04, at 1:17, Stephen Sprunk wrote: So _if_ IPv6 PI space is going to be a reality, we should do what we can to limit the damage. The only way to do this is to make it possible to filter out the PI prefixes at least in certain parts of the network without getting in the way of reachability. That's not the only solution -- just the most obvious one. Clearly, if IPv6 PI space spirals out of control like many operators think will happen, we need to find a way to make BGP (and possibly forwarding) performance not dependent on the number of prefixes in the table. There's many ways to skin that cat, and maybe it's time we start looking at that in parallel to the work on multi6 and HIP. One obvious way to improve BGP would be to work per-AS rather than per-prefix. We could even go so far as to remove the entire prefix-to-AS mapping from BGP and do this out of band, as this mapping is fairly static, and it's much easier to secure it this way. Unfortunately, this mostly helps with ASes that source many prefixes, but it doesn't help much when the number of prefixes per AS is small (which is what we expect in IPv6). Another interesting improvement would be bitmap routing where a bunch of PI blocks are grouped together into a large aggregate and an accompanying bitmap that indicates whether a specific prefix within that aggregate is reachable or not. This would save a lot of memory and allow for vector based BGP processing. :-) But all of this is only delaying the inevitable (not that that can't be useful sometimes): at some point, we need to move away from the premise that all default-free routers must know about all reachable prefixes. With this ball and chain removed we can start looking at new interdomain routing paradigms, such as an idr link state protocol that can function in a never fully converged state. (Which would make for some nice PhD work...) Worst case is we'll end up eliminating IP addresses as locators and build another layer beneath IP (and thus transparent to TCP) that actually handles routing, at least in the DFZ. In some sense we already have a foundation for that with MPLS, but we'd need to hack/replace BGP to make the new layer scale across ASes. Or perhaps we'll find a way to route based on ASNs in the DFZ, and the mapping from destination IP to ASN will be made only at the edge of the DFZ. MPLS can save you a bunch of router hops, but it doesn't really change anything because you still need a router at both ends of the MPLS cloud. Currently, the most efficient way to move packets to/from random systems across organizations et al is IPv6. Moving to a new internetworking layer is going to take A LOT of time. Even tunneling is non-trivial because of the destination to tunnel endpoint mapping that's required. In essence, doing something like this would be starting multi6 from scratch. The whole point of my message (and one of the points of Margaret's message that started the thread) was that operators don't want to wait for multi6 and/or want provider independence anyway. So we're back at: how do we limit the fallout from PI in IPv6, and without significant protocol work at that? I understand that Tony Hain has asked / will ask for a BoF in this area at the next IETF meeting. Hopefully this will lead to something. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: The gaps that NAT is filling
The average Internet user (home user or enterprise administrator) does not care about the end-to-end principle or the architectural purity of the Internet. Maybe not the average user, but a pretty large subset *does* care - because t makes it extremely hard to do what they want... Yes! I think it we should not underestimate the potential demands from and desires of average users. An average user is not my mom, and maybe not even those of our generation. I think an average user, of those who really wants any kind of Internet access, actually can be found among the younger generations, who consider the Internet and all today's technologies natural parts of daily life. Even if they do not care about the e2e principle, they do care about the potential for doing any kinds of peer2peer communication, as they want to play their networking games, they want to share information, they want to try things, experiment, and be independent of what outsiders provide or want to allow (like access providers). Not all home users are demanding, some just want to surf the web, but in most households there is at least one more demanding user, and that user will be the one setting the access requirements of the household. /L-E ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On Fri, 2004-11-26 at 21:47 +, Greg Skinner wrote: On Tue, 23 Nov 2004 14:11:19 +0100, Jeroen Massar wrote: On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote: Without solutions to these four problems on the horizon, I can't voice any enthusiasm that the larger address space in IPv6 will eliminate NAT in home or enterprise networks. This really isn't a problem of the IETF. The problems is at the ISP's who should charge for bandwidth usage and not for IP's. It is all a financial problem, people earn money this way, and there is not an easy way you can let them not make money. Actually, can you blame them? I can't unfortunately... Arguably, if the ISPs handed out a (static) IP to every customer, soon they'd be out of IPs, and thus unable to grow their businesses from that perspective. That is such a odd argument. When an ISP runs out of IP space, they go to their RIR and say Hey! You! I am running out of IP space gimme a new chunk! And then they get one, usually even 3 months in advance of running out. As long as an ISP can show demand for address space they can get it. You do need to have your network documentation in order of course and fit some other rules, but you will get the space. There is *no* address shortage in IPv4 (nor IPv6), see the various very nice presentations by Geoff Huston which he gave at the RIR meetings and other places. On Sat, 2004-11-27 at 11:48 +0100, Leif Johansson wrote: Jeroen Massar wrote: On Fri, 2004-11-26 at 10:11 +0100, Leif Johansson wrote: For somebody administering a network of 100 machines, the hassle cost of IP renumbering would be twenty times larger. Given this, how could anyone wonder why NAT is popular? Wrong. If you administer 100's or 1000s of machines you build or buy a system for doing address management. Renumbering is only difficult if your system is called vi :-) Wrong ;) Well at least, up to 1000 is probably doable. But what if you are talking about 100s or 1000s of organizations with each a 100 or 1000 machines. My site is 10k+ addresses. Seems easy enough to manage to me :-) And how many organizational bits and how many countries are covered using in that address space? I guess, that for most organizations, especially that started early, one is plain lucky when you can even find the administrator of a certain box, let alone the admin or carekeeper of a certain prefix when the organization goes above around that number. If you _can_ manage it, then you did a very good job ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
The IETF is supposed to gather everyone concerned and there is here a controversy on this real life and key/vital point. So the best is to ask in here. If no one says yes, it will mean either there is no felt shortage yes, or that those suffering from shortage do not share in the IETF (why would then be another question). If some says yes, this kind of universal affirmation will be closed. At 11:07 28/11/2004, Jeroen Massar wrote: Arguably, if the ISPs handed out a (static) IP to every customer, soon they'd be out of IPs, and thus unable to grow their businesses from that perspective. That is such a odd argument. When an ISP runs out of IP space, they go to their RIR and say Hey! You! I am running out of IP space gimme a new chunk! There is *no* address shortage in IPv4 (nor IPv6), see the various very nice presentations by Geoff Huston which he gave at the RIR meetings and other places. Has anyone present on this list ever experienced a problem in getting a new chunk of IP addresses from a RIR or from an ISP? What is the average delay you experiment? Thank you. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
[EMAIL PROTECTED] (Jeroen Massar) wrote on 23.11.04 in [EMAIL PROTECTED]: This really isn't a problem of the IETF. The problems is at the ISP's who should charge for bandwidth usage and not for IP's. Actually, they do - with some qualifications - at least over here, in Germany. That is, if you still use dialin over the phone network, I believe at least some still charge by time as that is what they are charged by other phone companies for transport. That's what non-packet networks are like. Then, private end users - or others who behave like them - can opt for flat rates. Pretty much everything else is by bandwidth. The unfortunate problem here is that you usually only get static or multiple IPs with bandwidth accounting, and full use of a flat rate is typically vastly cheaper than the same amount of bandwidth via bandwidth accounting. Which means there's a premium to *enter* the static IP market. Once you're there, additional IP space is often free of any cost. (Well, you need to fill out the RIPE forms so your ISP has something to point at if they get audited.) MfG Kai ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
[EMAIL PROTECTED] (Margaret Wasserman) wrote on 23.11.04 in [EMAIL PROTECTED]: The average Internet user (home user or enterprise administrator) does not care about the end-to-end principle or the architectural purity of the Internet. Maybe not the average usr, but a pretty large subset *does* care - because it makes it extremely hard to do what they want: to make a connection to their small business network (behind a dynamic IP) from somewhere else (also behind a dynamic IP). It's possible (using one of a large number of dynamic DNS providers), but it is neither obvious nor trivial - in fact, it is hard for them to understand even what the problem is. I just yesterday talked someone through this - a (small) business net admin wanting to access that net from home. This was someone who does database programming and at least sometimes creates networks for customers. And he *still* had a hard time with the consequences of dynamic IP and NAT. No, it's not the majority - but yes, it *is* a pretty significant subset. You don't need to be all that far apart from average to bloody your nose on this. (2) One-way connectivity could be provided via stateful firewalls instead of via NAT. You don't need all that much state for most of the protection. Just looking at TCP SYN does cover about 75% of the problem, I'd say, and that's completely stateless. (Not to say that the other 25% aren't important.) MfG Kai ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On Tue, 23 Nov 2004 14:11:19 +0100, Jeroen Massar wrote: On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote: Without solutions to these four problems on the horizon, I can't voice any enthusiasm that the larger address space in IPv6 will eliminate NAT in home or enterprise networks. This really isn't a problem of the IETF. The problems is at the ISP's who should charge for bandwidth usage and not for IP's. It is all a financial problem, people earn money this way, and there is not an easy way you can let them not make money. Actually, can you blame them? I can't unfortunately... Arguably, if the ISPs handed out a (static) IP to every customer, soon they'd be out of IPs, and thus unable to grow their businesses from that perspective. --gregbo ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
Title: Converted from Rich Text Margaret, These users care about ease of deployment, cost and avoiding unscheduled outages (whether due to security issues or ISP changes) Don't know about you, but if ever I have connectivity problems, the fiirst thing my provider wants me to do is power cycle the home gateway / router / NAT. All of that NAT state doesn't get cleared. Tihngs are only getting worse. Long live the e2e principle. John ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
Hi All, It will probably come as no surprise to many of you that I have spent quite a bit of time over the last few years trying to understand why people use NATs and how they could be replaced with more architecturally harmonious mechanisms. I have been completely convinced for several years that IPv6 will not eliminate the (real or perceived) need for NATs, at least not without significant follow-on work from the IETF. We won't be able to eliminate or substantially reduce the use of NAT in the Internet architecture unless we come up with better ways to address the problems that NAT is being used to solve, where better is defined from the user's perspective not from an architectural perspective. The average Internet user (home user or enterprise administrator) does not care about the end-to-end principle or the architectural purity of the Internet. These users care about ease of deployment, cost and avoiding unscheduled outages (whether due to security issues or ISP changes). Home users primarily care about client access to the Web, and enterprise administrators primarily care about keeping internal network connectivity as stable as possible. IMO, Internet users are primarily using NATs to solve four problems that the IETF has not reasonably addressed: (1) free IP address space for use on VPNs or other private networks, (2) stable, provider-independent IP addressing, (3) one-way connectivity to provide protection for client-only nodes, and (4) zero-configuration home and small office networking. Let me consider each of these problems separately: (1) Current ISP business models are tied to IP address allocation, and that will need to change to remove the economic/business incentives for enterprises to limit their use of IP addresses. There might be similar changes needed to registry policies and business models. Given that there are some rather large political and financial forces involved, I don't have any idea how/if these changes will come about. In the meantime, the only alternative for the IETF is define portions of the address space that can be used for private addressing on VPNs and other private networks. (2) One-way connectivity could be provided via stateful firewalls instead of via NAT. Since these firewalls wouldn't involve translation, they would avoid some (but not all) of the problems with NAT. However, they would still involve storing per-connection state in the middle of the network, so they will have some of the brittleness and reachability problems associated with NATs. AFAIK, the IETF doesn't need to do anything to make these stateful firewalls possible, and they may replace this aspect of NAT in home/small office gateways if ISPs actually do offer /48 prefixes to subscribers. Is there a better way to replace the security properties of NAT? Is there work that the IETF should be doing in this area? There does seem to be some fundamental disconnect between the idea of a selectively reachable Internet and the DNS system. In an enterprise situation, this is typically resolved using split DNS or an independent enterprise-level naming system, and in home networks this is typically avoided by not assigning DNS names to home nodes. Is there a better way for an Internet with multiple levels of reachability to be reflected in the DNS? (3) There is work ongoing in the multi6 and hip WGs to address one of the reasons why enterprises want provider-independent address space -- enterprise-level multihoming. However, the solutions being considered there will not eliminate the other primary reason why enterprises want provider-independence -- avoiding dependence on a particular ISP, which can lead to lock-in, higher prices and/or unplanned renumbering events due to provider network changes, failures, mergers, etc. To offer true provider-independence, we would need to offer long-term, renewable assignments of IP address prefixes directly to enterprises, similar to the swamp space in IPv4, but perhaps with an annual fee required to allow recapturing unused prefixes. Although this appears ont he surface to be a policy issue, the reason that we don't do this today is that it would cause unchecked growth of the global routing tables and the eventual collapse of the Internet. To avoid this technical problem, we would need to find a way to individually route a very large number of prefixes. At the moment, though, we don't have a generally accepted solution to this problem. So, enterprises are forced to use NAT to gain provider independence -- a trait that they obviously (based on the wide-spread deployment of NAT for this purpose) value above end-to-end connectivity for their internal nodes. (4) NATs are also currently used as an element of zero-configuration home networking solutions. While it is probably possible to build a low-cost, zero configuration home gateway without using NATs or scoped addressing (which I
Re: The gaps that NAT is filling
Margaret, I agree completely with your analysis -- it turns out that the two of us have been saying much the same thing for some time now. But I suggest that the situation with one of your four points is even a bit worse, IMO, than the way you describe it... --On Tuesday, 23 November, 2004 07:03 -0500 Margaret Wasserman [EMAIL PROTECTED] wrote: ... (3) There is work ongoing in the multi6 and hip WGs to address one of the reasons why enterprises want provider-independent address space -- enterprise-level multihoming. However, the solutions being considered there will not eliminate the other primary reason why enterprises want provider-independence -- avoiding dependence on a particular ISP, which can lead to lock-in, higher prices and/or unplanned renumbering events due to provider network changes, failures, mergers, etc. ... I think we are going to see (and have already started to see in the more technical part of the community) demand for multihoming at the SOHO and even home level, not just the enterprise level. The reason for this is that, if a small office or home user views the Internet as a critical resource, and providers to that scale of operation offer only a best efforts service level in which time-to-repair measured in days is not atypical, the most efficient choices involve two (or more) providers, rather than the business service those providers are willing to sell (with more addresses, but, typically, the same lack of credible guarantees). The thing that makes this problem different from the enterprise ones is that it imposes the essentially the same constraints on the knowledge and effort required for configuration (i.e., just about zero) that we now see for home networks (as you point out). It is not clear to me that the multi6 and hip efforts are effectively addressing that point, even if solutions could be built on top of them. And, of course, if such a requirement originates from the home and SOHO markets, and the solution requires public address space, the demand for long-term, renewable, direct-allocation prefixes will be much greater than one would predict from assuming enterprise use only. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote: Hi All, It will probably come as no surprise to many of you that I have spent quite a bit of time over the last few years trying to understand why people use NATs and how they could be replaced with more architecturally harmonious mechanisms. I have been completely convinced for several years that IPv6 will not eliminate the (real or perceived) need for NATs, at least not without significant follow-on work from the IETF. Did you ever think of the fact that many participants in the IETF earned a lot of money selling: - NAT solutions - VPN solutions to overcome the NAT problem - Consulting in many ways - Services to 'merge multiple enterprise networks' - ... Maybe some people do not want to solve the problem... Remember that people still need to have food on the plate the next day. We won't be able to eliminate or substantially reduce the use of NAT in the Internet architecture unless we come up with better ways to address the problems that NAT is being used to solve, where better is defined from the user's perspective not from an architectural perspective. For IPv4 you can totally forget the removal/elimination of NAT. For IPv6 there is still a chance that people are educated properly to not even think about it. The average Internet user (home user or enterprise administrator) does not care about the end-to-end principle or the architectural purity of the Internet. Never heard that gamer complaining that his friends could not join that game server she setup on her computer behind that NAT box? Also any P2P application loves end-2-end because then you don't have to use a 3rd party host to relay the traffic. They care but they don't realize what the problem is especially with the plethora of hacks that allow a NAT to somewhat work like a real end to end address. The problem though is that you have to hack around the NAT every single time. Which IMHO is more costly than getting some extra IP's. These users care about ease of deployment, cost and avoiding unscheduled outages (whether due to security issues or ISP changes). They only want three things: - that it works without problems - with low latency so they can aim correctly in that 3d shoot-em-up. - with high download speeds to get their newest movies and other warez. Home users primarily care about client access to the Web, and enterprise administrators primarily care about keeping internal network connectivity as stable as possible. Web? That is only a _fraction_ of the traffic they are generating. Also web is due to the simplicity of the protocol one of the few generally used protocols that doesn't have any problems with NAT's. Peer-2-Peer (read: end-to-end) is what they are using it for. MSN (and many other similar setups) for instance has this cam addon so that you can view the others person face and chat with the other person. Doesn't work when behind a NAT when you want to broadcast, unless you use the many tricks (eg uPNP) to avoid the NAT. IMO, Internet users are primarily using NATs to solve four problems that the IETF has not reasonably addressed: (1) free IP address space for use on VPNs or other private networks, The world relies on money, nothing is free. RFC1918 came nicely with the problems that we see today with it's usage in combination with NAT's. RFC1918 isn't bad actually, but the thing called NAT is. For IPv6 ULA's should solve this spot quite well. (2) stable provider-independent IP addressing For global or local connectivity? Local see ULA/RFC1918. For Global this cannot be done unless you want 128bit ASN's and 2^128 routing entries. See HIP for instance for one of the solutions to this problem. IP is a routing protocol, not an addressing protocol (DNS is the current addressing protocol in that respect). (3) one-way connectivity to provide protection for client-only nodes You mean firewalls? Could somebody at Cisco wake up and _release_ a working version of Cisco PIX's that support IPv6 please!? They said they had one 3 years ago by now, currently it is 'next release'... (4) zero-configuration home and small office networking. I guess you forgot DHCP for both IPv4 and IPv6 and Router Advertisement for IPv6. Did you read the excellent NAP draft? (Currently draft-vandevelde-v6ops-nap-00 soon, I understood a -01) Let me consider each of these problems separately: (1) Current ISP business models are tied to IP address allocation, and that will need to change to remove the economic/business incentives for enterprises to limit their use of IP addresses. There might be similar changes needed to registry policies and business models. Given that there are some rather large political and financial forces involved, I don't have any idea how/if these changes will come about. In the meantime, the only alternative for the IETF is define portions of the address space that
The gaps that NAT is filling
Eliot Lear [EMAIL PROTECTED]: You wouldn't care about touch points if even a large number were reliable and secure, and that is the key. I'm not sure I understand that sentence. What's a touch point? And what does security have to do with any of this? My issue is with how much administrative overhead my network interface imposes on me over its entire lifecycle, potentially including multiple changes iof ISP. At the consumer level I think it's VERY important that most people not care about the IP address they are assigned. In fact it's important that they not have to know anything about what they're addressed! And you're right: it doesn't matter whether it's v4 or v6. So. Where are the gaps? Well. Ideally, when I plug my router into the ISP's cable, it should invisibly negotiate an IP address range with the ISP as DHCP does now. Thereafter, whenever a machine initializes its network access, it should (1) grab an IP address from the range Ideally, the address allocations should be stable even as machines are inserted and deleted onm my local net, so other peoples' DNS caches don't become invalid every time I have to reboot a server. Perhaps base them on a hash of the requesting machine's MAC address, with backoff in the (rare) collision cases? (2) propagate updates to my DNS servers so lookup-by-name works. This is important. As long as this isn't true, DHCP is useless for servers. I should be able to declare my firewall and redirection rules by local host name and have everything work, -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
i've lost track of this conversation, but i want to add some raw data. (2) propagate updates to my DNS servers so lookup-by-name works. This is important. As long as this isn't true, DHCP is useless for servers. isc dhcpd and isc bind cooperate in the way you're describing, and as far as i know there's an RFC that describes this cooperation. in any case it's in general use in enterprise networks, but less so in isp's and soho's. -- Paul Vixie ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
