RE: IPv4 to IPv6 transition
Michel Py wrote:
The unanswered question is: are all these tricks going to be
enough to keep operating IPv4. Nobody knows, but almost
everyone who already has a v4 address can wait.
Iljitsch van Beijnum wrote:
Well, if in the forseeable future (3 years is a bit short,
though) 50% of all hosts has IPv6 connectivity, I would call
that a resounding success.
Me too, that's why I used even if. I am glad you have come to
admitting this publicly. Given some private email I have received
yesterday, it appears that some of the most active participants in the
IETF (and/or this mailing list) have been shocked to hear that, as of
yesterday night, less than 50% of all hosts did not have IPv6
connectivity yet.
Well, M$ will eventually fix Vista and it will eventually become
popular; nothing to worry about :-D
(I'll even take 25 or even 10 % or whatever is enough to make most
ISPs deploy IPv6 in their networks.)
That percentage is a heck of an interesting speculation, and I would not
dare no bet anything more than a beer on it. More on this below.
That the other 50/75/90% is still IPv6-only wouldn't be a problem:
presumably, IPv4 works for them so there is no need to add IPv6.
I presume you meant the other 50/75/90% is still IPv4-only
^
That's the real deal: if 90% of hosts don't need IPv6, it never takes
off. This is hardly a new notion, but there is such thing as a critical
mass.
The tricky part is what happens to people that run into
limitations that exist in IPv4 but not in IPv6. (NAT, hard
to get enough addresses, that kind of stuff.) So far, deploying
IPv6 to work around these problems has rarely been a workable
option. But hopefully, it will become one in the next few years.
Iljitsch, I like your eternal optimism but please face reality: despite
being evil, NAT is a feature that IPv6 does not have (yet?), and for
anyone who can read this today, hard to get enough addresses is a red
herring.
I just [forklift] upgraded one of my old small customers; they are 100%
IPv6 capable and 90% IPv6 configured (Vista on every desktop, Server
2003 SP1 x64, Exchange 2007, IOS 12.4). They have a /28 from {major ISP,
name withheld to protect the guilty and accessorily save my @55} which I
did not ask for; all I use is a single IP. The next thing I foresee
coming from {major ISP} is to change that /28 into a single static IP.
For the next 5 years I still don't have a single reason to upgrade.
flame bait
While you're at it, explain me something else: I'm a fat ignorant dumb
lazy American imperialist. Why should I bother if, in 5 years, someone
in a country that I have not heard the name yet has to sub their
Internet connectivity to an American company {which I, ahem, happen to
own shares of} instead of getting their own PI?
/flame bait
Michel.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On 6-okt-2007, at 7:00, Michel Py wrote: Think about the following: even if in 3 years 50% of hosts were IPv6-only capable, it would not diminish the need for IPv4. All the double-NAT tricks, unused address reclaim, config cleanup etc are going to happen now no matter what. I'm not saying it's going to be easy or cheap, but as long as there is a need for v4 it will happen. The unanswered question is: are all these tricks going to be enough to keep operating IPv4. Nobody knows, but almost everyone who already has a v4 address can wait. Well, if in the forseeable future (3 years is a bit short, though) 50% of all hosts has IPv6 connectivity, I would call that a resounding success. (I'll even take 25 or even 10 % or whatever is enough to make most ISPs deploy IPv6 in their networks.) That the other 50/75/90% is still IPv6-only wouldn't be a problem: presumably, IPv4 works for them so there is no need to add IPv6. The tricky part is what happens to people that run into limitations that exist in IPv4 but not in IPv6. (NAT, hard to get enough addresses, that kind of stuff.) So far, deploying IPv6 to work around these problems has rarely been a workable option. But hopefully, it will become one in the next few years. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On 5-okt-2007, at 6:38, Michel Py wrote: Nothing is going to happen the day the last v4 block is allocated. Nothing is going to happen for days. Nothing is going to happen for weeks. Sure. Nothing is going to happen for months. Not so sure. The big ISPs that work in blocks of a million or so addresses will be the first ones to see their requests turned down because addresses are out of stock. Presumably, they'll need those addresses to connect new customers. If you happen to request a new connection around that time you'll see an effect. Does anybody have any established and sustained opinion on that and could provide verifiable if not objective data? How many critical bugs were really found in typical systems? We will never know that. There were scores of people who billed tons of money to take care of it; you don't expect that they will admit to spending all this time finding nothing, would you? I think some pretty much have. I'm sure that if the Y2K issue had been ignored there'd been lots of problems with individual systems. The part that was unlikely (but not impossible) from the beginning were all the domino effects. A router won't stop routing if it is set to the wrong time of day. I'm pretty sure a plane won't stop flying, either. But in that particular case, pretty sure is not exactly good enough... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On 5-okt-2007, at 6:38, Michel Py wrote: Nothing is going to happen the day the last v4 block is allocated. Nothing is going to happen for days. Nothing is going to happen for weeks. Sure. Nothing is going to happen for months. Not so sure. The big ISPs that work in blocks of a million or so addresses will be the first ones to see their requests turned down because addresses are out of stock. Presumably, they'll need those addresses to connect new customers. If you happen to request a new connection around that time you'll see an effect. Does anybody have any established and sustained opinion on that and could provide verifiable if not objective data? How many critical bugs were really found in typical systems? We will never know that. There were scores of people who billed tons of money to take care of it; you don't expect that they will admit to spending all this time finding nothing, would you? I think some pretty much have. I'm sure that if the Y2K issue had been ignored there'd been lots of problems with individual systems. The part that was unlikely (but not impossible) from the beginning were all the domino effects. A router won't stop routing if it is set to the wrong time of day. I'm pretty sure a plane won't stop flying, either. But in that particular case, pretty sure is not exactly good enough... There have been fighter jets that couldn't cross the date line as the navigation computers crashes/gave wrong readings. The pilots that discovered this had to be escorted back by other aircraft with working navigation. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Michel Py wrote: Nothing is going to happen for months. Iljitsch van Beijnum wrote: Not so sure. The big ISPs that work in blocks of a million or so addresses will be the first ones to see their requests turned down because addresses are out of stock. Presumably, they'll need those addresses to connect new customers. If you happen to request a new connection around that time you'll see an effect. Then they can begin to reclaim the waste in their own backyard. I know first hand scores of customers who: - Have been allocated a block of addresses and NAT out of the /30 of the T1 link. The blocks can be reclaimed easily. - Have been allocated a /28 without asking for it and all they use is a single IP. During the good old ipv6mh days, we could have hoped that IPv6 would be deployed in time; this is no longer the case. Think about the following: even if in 3 years 50% of hosts were IPv6-only capable, it would not diminish the need for IPv4. All the double-NAT tricks, unused address reclaim, config cleanup etc are going to happen now no matter what. I'm not saying it's going to be easy or cheap, but as long as there is a need for v4 it will happen. The unanswered question is: are all these tricks going to be enough to keep operating IPv4. Nobody knows, but almost everyone who already has a v4 address can wait. I am sad so read Y2K-like FUD and counters. The name of the game is: wait, see how much it hurts, and do something about it when the pain becomes unbearable. Most people will try vicodin before opting for the surgery, especially when dealing with a disease that has not killed anyone yet. You can't change that. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.h tml Each time I see one of these days remaining before Armaggedon counters, I can't help but remember what happened on January 1, 2000: nothing. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.h tml Each time I see one of these days remaining before Armaggedon counters, I can't help but remember what happened on January 1, 2000: nothing. yes, but that's because people heeded the warnings, and prepared. if the same thing happens wrt IPv4 exhaustion, that will be fabulous. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Hi On 4 Oct 2007, at 19:50, Keith Moore wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.h tml Each time I see one of these days remaining before Armaggedon counters, I can't help but remember what happened on January 1, 2000: nothing. yes, but that's because people heeded the warnings, and prepared. if the same thing happens wrt IPv4 exhaustion, that will be fabulous. No doubt - that nicely paid off our profession so we should not complain :-) However, that's an intriguing discussion because I almost as often hear quite the contrary argument: indeed, given billions of USD and EUR spent on that issue, one could reasonably argue that the issue was overblown and ask to which degree this statement is true and what would have actually happened without all the pressure. So far, I could not find anything really useful on that (proofs?) but keep on hearing very opposite positions, but it's maybe just me? Does anybody have any established and sustained opinion on that and could provide verifiable if not objective data? How many critical bugs were really found in typical systems? What would have been the real impact? What could have happenned in terms of impact (meaning: it would definitely have happened, not the what-if analysis)? Was the cost higher than the estimated risk? thanks for any pointers artur ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Each time I see one of these days remaining before Armaggedon counters, I can't help but remember what happened on January 1, 2000: nothing. yes, but that's because people heeded the warnings, and prepared. if the same thing happens wrt IPv4 exhaustion, that will be fabulous. No doubt - that nicely paid off our profession so we should not complain :-) However, that's an intriguing discussion because I almost as often hear quite the contrary argument: indeed, given billions of USD and EUR spent on that issue, one could reasonably argue that the issue was overblown and ask to which degree this statement is true and what would have actually happened without all the pressure. So far, I could not find anything really useful on that (proofs?) but keep on hearing very opposite positions, but it's maybe just me? Does anybody have any established and sustained opinion on that and could provide verifiable if not objective data? How many critical bugs were really found in typical systems? What would have been the real impact? What could have happenned in terms of impact (meaning: it would definitely have happened, not the what-if analysis)? Was the cost higher than the estimated risk? Well, presumably most of that money was spent on detailed analysis rather than on bug fixes. But I haven't heard of any significant effort to collect data on how many bugs were found or what there impact would have been had they not been fixed prior to y2k. And it's not clear how much value there would be in such an effort, because we're not going to run into another y2k like situation for at least 93 more years. (Okay, maybe in 2038 when the number of seconds after the UNIX epoch rolls past a 32-bit number). It would be hard to apply any lessons learned from y2k to the exhaustion of IPv4, because they're similar only in a very superficial way. Keith p.s. also, my impression is that a lot of businesses used the y2k as an excuse to replace old, crufty software with newer software (presumably with newer cruft), which might have produced benefits other than y2k resilience. so a cost-vs-benefit analysis would need to consider this. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
In the 1980s I worked on a chemical plant manufacturing chlorine and CFCs. In the corner of the site there was a plant that had been constructed but never put into production. The plant had been built to make a CFC substitute product when the Ozone layer issue had first been raised but never went into production as it was subsequently proved that the ozone layer fears had been greatly exagerated and that it would be centuries or more before the significant depletion would take effect. Today of course we have a massive hole in the ozone layer and the role of CFCs is beyond serious dispute. More than half the CFCs that are circulating in the upper atmosphere today were manufactured after we had the technology to avoid the problem. So yes, Homo Sapiens is entirely capable of turning avoidable disaster into disaster through inaction. -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Thursday, October 04, 2007 1:50 PM To: Michel Py Cc: IETF Discussion Subject: Re: IPv4 to IPv6 transition http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420 .h tml Each time I see one of these days remaining before Armaggedon counters, I can't help but remember what happened on January 1, 2000: nothing. yes, but that's because people heeded the warnings, and prepared. if the same thing happens wrt IPv4 exhaustion, that will be fabulous. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
The Y2K issue was almost certainly overblown, but it is important to understand the reasons as they do not apply in the IPv4 case. The reason Y2K gained so much attention was that there was almost perfect alignment between the party able to fix the problem and the party able to cause the fix to be implemented. The issue began as many companies recognised that if they did not spend money to avert the Y2K problem that they would be the ones to suffer the loss. If this was the only dynamic Y2K would have received more or less the attention it deserved. Instead the problem was compounded by a couple of additional factors. The first was the Y2K vampire who consultant-like turned every victim into a new source of infection. The first thing a Y2K vampire would do on claiming a new victim was to send out letters to every supplier demanding to know if their systems have passed a Y2K audit. Thus the poison spread at exponential speed. Knowing that your company stands to lose $1 million if there is a Y2k issue might cause you to spend $750k to avoid it. Having your hundred or so customers demand to know if you are Y2K compliant puts your entire company revenues at risk. The second part to the dynamic was that all contrarian voices (including my own) were suppressed. The only Y2K stories that could be printed in advance described the impending catastrophe. Folk like myself who were skeptical were not going to be covered - even when we were pointing out blatantly obvious points such as the fact that we should not be overly concerned about the threat of Y2k in third world countries where the power, telephone etc infrastructure are unreliable in any case and one particular outage is not an issue. The only Y2K issue I am aware of is one that was paradoxically caused by a Y2K concern. One of the oldest X.509 roots expired on Dec 31 1999. The date had been chosen precisely because of Y2K concerns, the fix to the specification had not yet been ratified as a standard. At the time the root was created nobody had anticipated that the level of Y2K paranoia would make that date a bad choice of day for a cert to expire. So how does this all relate to IPv4/6? It does not. The problem with the IPv6 transition is that the cost and benefit are completely out of phase. The cost falls on those who have IPv4 addresses, the benefits acrue only to those who do not. If you have an IPv4 address the fact that others do not is not going to make a huge difference to the benefit you get from the network. Metcalf's law is overstated, the value of a network to an individual user is at best proportional to its size. In practice the Blockbuster effect means that there are diminishing returns. A network of four billion plus one users is worth more or less the same to me as a user as a network of four billion. The fact that there could be one more user is not something that would greatly encourage me to upgrade my kit. At best the value of the network to existing users is going to be the log of the number of users. Looking back at my personal use of networks I can certainly agree that the number of users increases the value. I have seen the Web grow from 100 users to a billion. The value has not increased at anything like the same rate. The Web is certainly more useful today than in 2000 or 1995 or 1992 but the increase in value has been linear, not exponential. The Web does not help me to find ten million times more useful information today than it did in 1992. So the idea that we can rely on the Internet haves to invest money to benefit the Internet have-nots on the scale necessary is unfortunately misguided. I do think that we can make the IPv6 transition work. I do not think that we can just expect it to happen and for everything to turn out just right. Or that merely convincing people that there is going to be a problem will result in a solution. We have to think like marketting people. -Original Message- From: Artur Hecker [mailto:[EMAIL PROTECTED] Sent: Thursday, October 04, 2007 2:20 PM To: IETF Discussion Subject: Re: IPv4 to IPv6 transition Hi On 4 Oct 2007, at 19:50, Keith Moore wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.h tml Each time I see one of these days remaining before Armaggedon counters, I can't help but remember what happened on January 1, 2000: nothing. yes, but that's because people heeded the warnings, and prepared. if the same thing happens wrt IPv4 exhaustion, that will be fabulous. No doubt - that nicely paid off our profession so we should not complain :-) However, that's an intriguing discussion because I almost as often hear quite the contrary argument: indeed, given billions of USD and EUR spent on that issue, one could reasonably argue that the issue was overblown and ask to which degree this statement is true and what would have actually happened
RE: IPv4 to IPv6 transition
Michel Py wrote: Each time I see one of these days remaining before Armageddon counters, I can't help but remember what happened on January 1, 2000: nothing. Keith Moore wrote: yes, but that's because people heeded the warnings, and prepared. if the same thing happens wrt IPv4 exhaustion, that will be fabulous. FUD. Nothing is going to happen the day the last v4 block is allocated. Nothing is going to happen for days. Nothing is going to happen for weeks. Nothing is going to happen for months. Contrary to Y2K, when it was conceivable (and did happen, at a very small scale) that something would crash because a counter rolled to 00 because the software written 20 years before did not plan for it, what will happen the day IPv4 is exhausted is zip, nada, nothing. Some obscure player will not get addresses, the business will go instead to an established player who has feasted on IPv4 for years and has built both fat and a respectable stockpile in their cellar, and the world will continue to spin. Artur Hecker wrote: No doubt - that nicely paid off our profession so we should not complain :-) :-D indeed, given billions of USD and EUR spent on that issue, one could reasonably argue that the issue was overblown and ask to which degree this statement is true and what would have actually happened without all the pressure. Indeed. I mostly agree with the Phillip Hallam-Baker's post later on. Does anybody have any established and sustained opinion on that and could provide verifiable if not objective data? How many critical bugs were really found in typical systems? We will never know that. There were scores of people who billed tons of money to take care of it; you don't expect that they will admit to spending all this time finding nothing, would you? But on the other end, most of the Y2K audit teams were internal so they kept their dirty laundry in the family. In the end, it does not matter. Y2K was about compliance, and compliance is about making sure it fits the requirements checklist, which means it's defendable in court, and does not mean it actually works. What would have been the real impact? What could have happened in terms of impact (meaning: it would definitely have happened, not the what-if analysis)? Nobody will ever know that either. What could have happened if the dinosaurs were not extinct? What could have happened if we did not drop a nuke on Japan to end the war? What could have happened if the Germans got a nuke before we did? What could have happened if the soviets beat us to the moon? What could have happened if John Kennedy was not assassinated? What could have happened if the telephone was not invented? Was the cost higher than the estimated risk? Nobody will ever know that either, but one thing is sure: it would have been a lot cheaper without the legal liability buffalo dung that was associated with it. Phillip Hallam-Baker wrote: The first was the Y2K vampire who consultant-like turned every victim into a new source of infection. The first thing a Y2K vampire would do on claiming a new victim was to send out letters to every supplier demanding to know if their systems have passed a Y2K audit. Thus the poison spread at exponential speed. This is no different than a pyramid scheme or a virus: the only way out is full speed ahead and hope that you will not be part of the casualties. We have to think like marketting people. Phillip, although I agree with the rest of your post, I am not sure about this part. One of the IPv6 problems is that it was sold by marketing before engineers could actually make it work. Remember all these miraculous features: small DFZ, easy renumbering, etc? Tell me where these features are today besides the imagination of marketing-minded people who sold them before making sure that they could actually be delivered. Two things happened along the road: First, as you have explained, people realized that the Y2K FUD was overblown and are not willing to spend the same money on IPv6. Second, the dot-com bubble burst, and the IPv6 forklift upgrade that could have been financed by all this capital money pouring from the sky did not take off. IPv6: sold by marketing before the concept was even proven. Designed by protocol purity zealots who can't make it cheap enough to be economically deployable. It reminds me of the Concorde supersonic aircraft: it could have been a success if the supersonic boom could be suppressed and if the price of oil did not skyrocket. A few were built and were operated with much hype on a confidential scale for many years. Where can you see one today? In a museum. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Brian, My comment was regarding a head in the sand approach when it comes to the recurring themes that the developing world can't IP address space, whether it is v4 or v6. The fact is that they can get it from the RIR like those in the developed regions can get it from their RIRs. The real problem, in other words, putting head in sand, is to substitute this address space access issue for the real one of what can the recipients of the address space do with it when they get, particularly if they have no hardware to run it on, no electricity to power it, and no upstream willing to route it. It is those issues that need to be hit head on if the Internet is to really grow in the developing regions of the globe. Ray -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 4:39 PM To: Ray Plzak Cc: Tim Chown; ietf@ietf.org Subject: Re: IPv4 to IPv6 transition Ray, I don't think it's quite fair to refer to ostriches when ARIN is already on record: http://www.arin.net/v6/v6-resolution.html Also, for those who like to see things in real time, there's always http://penrose.uk6x.com/ Regards Brian Carpenter University of Auckland On 2007-10-03 02:47, Ray Plzak wrote: Head in the sand is substituting the statement shortage of IP addresses for the condition of the inability to use the addresses (take your pick when it comes to infrastructure deficiencies). Ray -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 9:32 AM To: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
correction, http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.html let me know what do you think about it :-) Regards, On 2007/10/03, at 11:24, Ruri Hiromi wrote: dedicate to ostriches... http://www.apple.com/en/downloads/dashboard/networking_security/ ipv420.html On 2007/10/02, at 22:32, Tim Chown wrote: On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --- Ruri Hiromi [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --- Ruri Hiromi [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.html hi Ruri , well, i could imagine what its good for , but an english version would be appreciated ;) cheers Marc -- Marc Manthey - LET - research + deployment D- 50672 Cologne Hildeboldplatz 1a web: http://www.let.de my xing profile https://www.xing.com/profile/Marc_Manthey phone mobile: 0049.221.355.80.32 0049.177.341.54.81 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Wed, Oct 03, 2007 at 07:55:40PM +0900, Ruri Hiromi [EMAIL PROTECTED] wrote a message of 64 lines which said: http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html ^^ Many webmasters still have not read RFC 4646 :-( let me know what do you think about it :-) Any translation in my own language? For english, Google suggests: IPv4 depletion clock 2.0 Empty circumstance of the IPv4 address space which IANA has managed and remaining days to depletion expectation day, it can look through the IPv4 address (presumption) and the like at present time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
courtesy of google translation: http://translate.google.com/translate?u=http%3A%2F%2Fwww.apple.com%2Fjp%2Fdownloads%2Fdashboard%2Fnetworking_security%2Fipv420.html+langpair=ja%7Cenhl=ensafe=offie=UTF-8oe=UTF-8prev=%2Flanguage_tools Tony Hansen [EMAIL PROTECTED] Marc Manthey wrote: On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html well, i could imagine what its good for , but an english version would be appreciated ;) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
It actually IS English, try installing, it localizes. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Wed, 3 Oct 2007, Marc Manthey wrote: On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html hi Ruri , well, i could imagine what its good for , but an english version would be appreciated ;) cheers Marc -- Marc Manthey - LET - research + deployment D- 50672 Cologne Hildeboldplatz 1a web: http://www.let.de my xing profile https://www.xing.com/profile/Marc_Manthey phone mobile: 0049.221.355.80.32 0049.177.341.54.81 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
If IANA had any resolve there are at least 25 -30 Class A blocks that should be reclaimed and are not or should not be part of the public Internet address space. At 6:56 -0400 2007/10/03, Ray Plzak wrote: Brian, My comment was regarding a head in the sand approach when it comes to the recurring themes that the developing world can't IP address space, whether it is v4 or v6. The fact is that they can get it from the RIR like those in the developed regions can get it from their RIRs. The real problem, in other words, putting head in sand, is to substitute this address space access issue for the real one of what can the recipients of the address space do with it when they get, particularly if they have no hardware to run it on, no electricity to power it, and no upstream willing to route it. It is those issues that need to be hit head on if the Internet is to really grow in the developing regions of the globe. Ray -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 4:39 PM To: Ray Plzak Cc: Tim Chown; ietf@ietf.org Subject: Re: IPv4 to IPv6 transition Ray, I don't think it's quite fair to refer to ostriches when ARIN is already on record: http://www.arin.net/v6/v6-resolution.html Also, for those who like to see things in real time, there's always http://penrose.uk6x.com/ Regards Brian Carpenter University of Auckland On 2007-10-03 02:47, Ray Plzak wrote: Head in the sand is substituting the statement shortage of IP addresses for the condition of the inability to use the addresses (take your pick when it comes to infrastructure deficiencies). Ray -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 9:32 AM To: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.html well, i could imagine what its good for , but an english version would be appreciated ;) the widget itself is bilingual (english/japanese). itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Hi All Just an input about the NAT issue handled here. The 'war' against NAT is senseless before succeeding the one against IPv4. I mean, as far as the v4 protocol runs on our networks, NAT will remain as a useful tool for those who need it, of course for specific applications. In developing countries for example where IPv6 entry is very slow -add to a scarcity of IPv4 addresses- we are always using NAT, and are happy to do so as: 1- No enough IPv4 addresses 2-No need for the specific applications for those networks 3-No alternative solution currently 'in the hands'. Thanks Philemon - Original Message - From: Hannes Tschofenig [EMAIL PROTECTED] To: Keith Moore [EMAIL PROTECTED] Cc: Stephen Sprunk [EMAIL PROTECTED]; ietf@ietf.org; Paul Hoffman [EMAIL PROTECTED] Sent: Friday, July 13, 2007 9:11 PM Subject: Re: IPv4 to IPv6 transition Hi Keith, Keith Moore wrote: Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. there are a couple of problems with this analysis: one is that it considers only application protocols that are in widespread use. there are lots of applications that are used by limited communities that are nevertheless important. Namely? and of course, since NATs are so pervasive, most of the applications that are in widespread use have been made to work with NAT (often at tremendous expense, and reduced reliability). Could you explain the tremendous expense a bit more? another problem is that it only considers current applications. a big part of the problem with NAT is that it inhibits the development/deployment of useful new applications. As Phillip stated, I don't see the problem with future applications. Compare this with the security aspects that are taken care of much more than before when developing new applications NAT traversal is just another thing to think about as a protocol designer. Ciao Hannes Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
The shortage of IPv4 addresses in developing countries in a red herring. All one has to do is apply for them from the RIR. Getting a service provider to route them is a different problem, especially when they profit from running your traffic through their NAT. Ray -Original Message- From: philemon [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 6:40 AM To: Hannes Tschofenig; Keith Moore Cc: Stephen Sprunk; ietf@ietf.org; Paul Hoffman Subject: Re: IPv4 to IPv6 transition Hi All Just an input about the NAT issue handled here. The 'war' against NAT is senseless before succeeding the one against IPv4. I mean, as far as the v4 protocol runs on our networks, NAT will remain as a useful tool for those who need it, of course for specific applications. In developing countries for example where IPv6 entry is very slow -add to a scarcity of IPv4 addresses- we are always using NAT, and are happy to do so as: 1- No enough IPv4 addresses 2-No need for the specific applications for those networks 3-No alternative solution currently 'in the hands'. Thanks Philemon - Original Message - From: Hannes Tschofenig [EMAIL PROTECTED] To: Keith Moore [EMAIL PROTECTED] Cc: Stephen Sprunk [EMAIL PROTECTED]; ietf@ietf.org; Paul Hoffman [EMAIL PROTECTED] Sent: Friday, July 13, 2007 9:11 PM Subject: Re: IPv4 to IPv6 transition Hi Keith, Keith Moore wrote: Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. there are a couple of problems with this analysis: one is that it considers only application protocols that are in widespread use. there are lots of applications that are used by limited communities that are nevertheless important. Namely? and of course, since NATs are so pervasive, most of the applications that are in widespread use have been made to work with NAT (often at tremendous expense, and reduced reliability). Could you explain the tremendous expense a bit more? another problem is that it only considers current applications. a big part of the problem with NAT is that it inhibits the development/deployment of useful new applications. As Phillip stated, I don't see the problem with future applications. Compare this with the security aspects that are taken care of much more than before when developing new applications NAT traversal is just another thing to think about as a protocol designer. Ciao Hannes Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On 2-okt-2007, at 15:05, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. Yellow herring? There are five RIRs that serve different parts of the world. Each of them will give people pretty much all the addresses they reasonably need if they pay the RIR fees (starts at a few thousand dollars a year) and maybe qualify for some minimum size. There may be people who can't afford this, or people who can't afford to buy the connectivity to make these addresses useful, but the address space in and of itself is not the issue. Point in case: China. By the turn of the century, they only had 7.57 million addresses of the 1.6 billion in use at that point (as far as I can determine easily right now, there may be some differences) but today it's 130 million of 2.55 billion. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Head in the sand is substituting the statement shortage of IP addresses for the condition of the inability to use the addresses (take your pick when it comes to infrastructure deficiencies). Ray -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 9:32 AM To: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
should have been is -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 9:06 AM To: Ray Plzak Cc: philemon; Hannes Tschofenig; Stephen Sprunk; ietf@ietf.org; Paul Hoffman Subject: Re: IPv4 to IPv6 transition Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Ray, I don't think it's quite fair to refer to ostriches when ARIN is already on record: http://www.arin.net/v6/v6-resolution.html Also, for those who like to see things in real time, there's always http://penrose.uk6x.com/ Regards Brian Carpenter University of Auckland On 2007-10-03 02:47, Ray Plzak wrote: Head in the sand is substituting the statement shortage of IP addresses for the condition of the inability to use the addresses (take your pick when it comes to infrastructure deficiencies). Ray -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 9:32 AM To: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
dedicate to ostriches... http://www.apple.com/en/downloads/dashboard/networking_security/ ipv420.html On 2007/10/02, at 22:32, Tim Chown wrote: On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --- Ruri Hiromi [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. All one has to do is apply for them from the RIR. Getting a service provider to route them is a different problem, especially when they profit from running your traffic through their NAT. ..or especially when a politically repressive government encourages ISPs to provide addresses through NAT because a) they can control content access better (by tricks such as transparent DNS proxies on the NAT box) and b) because makes it more difficult for dissident web site to pop up right and left. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Peers, servers and consumers (was RE: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition)
From: Ted Hardie [mailto:[EMAIL PROTECTED] There are essentially three classes of network actor: client, server and peer. In any given interaction there is always an initiator and a responder. In most cases these correspond to the client and the server. In a peer-to-peer application a given machine may be either an initiator or a responder. As you imply, at the IP layer the few in common use are: unicast flow initiator, unicast flow destination, and multicast group (anycast in the typical use being a mechanism to select which instance will be the unicast destination for a specific flow). The difference between peer and server as unicast flow destination is zero. It is as far as the network layer is concerned. A client server interaction is mediated through the DNS exclusively. A peer-peer interaction is typically mediated through DNS and a broker in combination. In the case of peer-to-peer messaging that is through SIP. Unless you mean peer in some specific sense, like a participant in a DHT-based overlay topology, as the sip p2p working group is aiming for? If so, is there something about the overlay traversal that you believe will affect the v4 distribution? (At the moment that group is discussing reusing mechanisms like ICE and STUN for setting up the traversal in the presence of NATs). That is a logical approach if you assume that the NAT people insist that the net work around them. But the NAT folk are more than willing to meet in the middle. There is a potential win-win here. The NAT folk can avoid the need to continue to build in work-arrounds into their product and application designers can build to something that can be expected to work interoperably. All we need to do is to make the NAT a little less unpredictable. Now lets look at what the typical consumer does and does not want to put on the Internet. They do want to run peer-to-peer applications. They do want to run client applications such as the Web. Very few want to host servers and many explicitly do not want the inherent exposure that opening a server port entails. First, I think making judgements about what the typical consumer will want in the future based on the existing situation is pretty limiting, if not downright likely to crack your crystal ball. Aside from more and cheaper, few such predictions are likely to be right. Such predictions only need to hold until we arrive at the world of IPv6. I also think by making the distinction server port you are going past what the typical consumer wants or understands. If a company provides a mechanism that allows them to do X in some environments but not in others, it will be perceived as a flaw. The music sharing built into iTunes is a case in point. It provides a mechanism that allows people to stream music from their collection to some set of other people. The restrictions to a subnet were, from the lay perspective, perceived as just so much jargon. You and I may recognize that making the connection work through two NATs is non-trivial, but the typical consumer doesn't in my limited experience seem to know or care. They want X to work, and they don't see X in boxes like client/server, peer, other. Exactly, there must be a branding regime so that a consumer knows that if his NAT box has the 'It Just Works' brand that they are assured that it will just work with Itunes etc. If you are a consumer trying to figure out why their videocam software won't work you are going to have a pretty ugly experience today. Even if you know about the basic networking concepts you will find it pretty difficult with most of the consumer oriented client to find information on the ports the protocol expects to be able to use. If we can satisfy those users needs with the 50% of the IPv4 address space that gives us the other 50% of the address space to meet the needs of the other 5%. I guess I missed the how of this, in a world where peers routinely want to open unicast flows to a potentially unbounded set of destinations (other peers). Or do you believe the peer network mechanisms at hand (like using public-IP peers as supernodes) scale well enough to make this work? I would certainly like to avoid the set of schemes that work around NAT by routing all traffic through a nearby node that has unrestricted connectivity. Alice calls Bob and it is routed through Carol's machine. Ugh! Alice should be able to call Bob and the data packets travel directly from Alice to Bob even when Bob is behind a NAT. That is possible even with IP address pooling, all that is necessary is to configure the systems in such a way that Bob can advertise an IP address and port number in Internet IPv4 address space that will route to the port his peer is listening to in his NAT'ed address space. The second is that you mean that any device which serves as an intersection point between
RE: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
What I was proposing was closer to the second. From my (no doubt incorrect as far as layer 4 folk are concerned) point of view the 'Internet' is defined by consistency of the name space, not the address space. So a user is on the Internet if they are in a situation where the machine they are using resolves a DNS name in a manner that is consistent with the result they would get at any other point that is by mutual consensus considered to be 'the Internet'. As far as a user is concerned they should no more know or care about the value of their IP address or which particular numbering space that is is in than they would the SS7 termination number for their telephone service - provided that they receive the service they expect. In my view of Internet architecture the inter-network is not a network, it is a network of networks. A host machine is never on the Internet, only a network (or at a higher level of abstraction a user) can be on the Internet. Even though you may have IPv4 run to the host the host is still on the network, not the Internet. Obviously the easiest way to achieve this is for the address space to be consistent and universal. In the pure IPv6 world this is entirely practical. In the IPv4 world the fact is that we are running out of addresses and will shortly have to begin rationing them in some fashion. If we refuse to the market will ration them in a fashion that is both unpredictable and less likely to be to our liking. I think that if we get SIP right we can ration the pool of IPv4 addresses in such a way that nobody is inconvenienced. All we need to do is to be a little carefull in protocol design. I don't see any reason to get bent out of shape about rationing IPv4 addresses, the IPv4 Internet is going to go away. If someone is going to design a new protocol for IPv4 they need to deal with the IP address rationing that will soon become the norm. If they can't deal with that they need to layer on IPv6 instead. There are essentially three classes of network actor: client, server and peer. In any given interaction there is always an initiator and a responder. In most cases these correspond to the client and the server. In a peer-to-peer application a given machine may be either an initiator or a responder. Except in rare situations (e.g. FTP) NAT does not cause problems when the initiator of the communication is behind a NAT. The problem with NAT comes when the responder is behind a NAT. When the message hits a NAT box it needs to know where to forward the packet. Now lets look at what the typical consumer does and does not want to put on the Internet. They do want to run peer-to-peer applications. They do want to run client applications such as the Web. Very few want to host servers and many explicitly do not want the inherent exposure that opening a server port entails. I think that 95% of consumers would be more than happy with a solution that only gives them client and peer-to-peer on IPv4 but does so reliably and robustly. If we can satisfy those users needs with the 50% of the IPv4 address space that gives us the other 50% of the address space to meet the needs of the other 5%. Don't think of it as NAT, think of it as a specialized form of IP header compression within a network that just happens to map IPv6 space to a 32 bit address space that may or may not be the IANA regulated one. -Original Message- From: Ted Hardie [mailto:[EMAIL PROTECTED] Sent: Monday, July 16, 2007 12:02 PM To: Hallam-Baker, Phillip; Hannes Tschofenig; Brian E Carpenter Cc: Melinda Shore; ietf@ietf.org Subject: Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach. There are two ways I can read this, and I suspect I've got them both wrong. The first is the flag day meaning for where the numbering scheme changes--that is, re-deploy all applications on some day at which we decide the numbering scheme changes. The second is that you mean that any device which serves as an intersection point between v4 and v6 must also serve as a back-to-back user agent for all applications that run across it. That is, for the scenario v6-endpoint---[boundary]--v4 segment---[boundary]--v6-endpoint there would be a full-on termination of the application at each boundary, and a new application flow, which is itself not guaranteed to reach the original destination of the flow. Is either of those what you meant? If not, can you clarify? thanks, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Peers, servers and consumers (was RE: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition)
There are essentially three classes of network actor: client, server and peer. In any given interaction there is always an initiator and a responder. In most cases these correspond to the client and the server. In a peer-to-peer application a given machine may be either an initiator or a responder. As you imply, at the IP layer the few in common use are: unicast flow initiator, unicast flow destination, and multicast group (anycast in the typical use being a mechanism to select which instance will be the unicast destination for a specific flow). The difference between peer and server as unicast flow destination is zero. Unless you mean peer in some specific sense, like a participant in a DHT-based overlay topology, as the sip p2p working group is aiming for? If so, is there something about the overlay traversal that you believe will affect the v4 distribution? (At the moment that group is discussing reusing mechanisms like ICE and STUN for setting up the traversal in the presence of NATs). Now lets look at what the typical consumer does and does not want to put on the Internet. They do want to run peer-to-peer applications. They do want to run client applications such as the Web. Very few want to host servers and many explicitly do not want the inherent exposure that opening a server port entails. First, I think making judgements about what the typical consumer will want in the future based on the existing situation is pretty limiting, if not downright likely to crack your crystal ball. Aside from more and cheaper, few such predictions are likely to be right. I also think by making the distinction server port you are going past what the typical consumer wants or understands. If a company provides a mechanism that allows them to do X in some environments but not in others, it will be perceived as a flaw. The music sharing built into iTunes is a case in point. It provides a mechanism that allows people to stream music from their collection to some set of other people. The restrictions to a subnet were, from the lay perspective, perceived as just so much jargon. You and I may recognize that making the connection work through two NATs is non-trivial, but the typical consumer doesn't in my limited experience seem to know or care. They want X to work, and they don't see X in boxes like client/server, peer, other. If we can satisfy those users needs with the 50% of the IPv4 address space that gives us the other 50% of the address space to meet the needs of the other 5%. I guess I missed the how of this, in a world where peers routinely want to open unicast flows to a potentially unbounded set of destinations (other peers). Or do you believe the peer network mechanisms at hand (like using public-IP peers as supernodes) scale well enough to make this work? Don't think of it as NAT, think of it as a specialized form of IP header compression within a network that just happens to map IPv6 space to a 32 bit address space that may or may not be the IANA regulated one. You had mentioned that your vision was closer to the second scenario I put forward. That scenario was The second is that you mean that any device which serves as an intersection point between v4 and v6 must also serve as a back-to-back user agent for all applications that run across it. That seems to me a good bit more than specialized header compression. Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 2007-07-14 00:07, Melinda Shore wrote: On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Maybe by a lack of simplicity? draft-woodyatt-ald-01 is a recent proposal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
Hi Brian, regarding lack of simplicity: Different solutions build on different assumptions. If you make specific assumptions then the solution is much simpler. There is a recent document that aims to compare some of the NAT / firewall protocol proposals: http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt It is not yet finished but might give you an idea what the different assumptions of some of the proposals are. Ciao Hannes Brian E Carpenter wrote: On 2007-07-14 00:07, Melinda Shore wrote: On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Maybe by a lack of simplicity? draft-woodyatt-ald-01 is a recent proposal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. The only difference is that we have both sides of the gateway running IP albeit with different numbering schemes. So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] Sent: Monday, July 16, 2007 01:30 AM Pacific Standard Time To: Brian E Carpenter Cc: Melinda Shore; ietf@ietf.org Subject:Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition Hi Brian, regarding lack of simplicity: Different solutions build on different assumptions. If you make specific assumptions then the solution is much simpler. There is a recent document that aims to compare some of the NAT / firewall protocol proposals: http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt It is not yet finished but might give you an idea what the different assumptions of some of the proposals are. Ciao Hannes Brian E Carpenter wrote: On 2007-07-14 00:07, Melinda Shore wrote: On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Maybe by a lack of simplicity? draft-woodyatt-ald-01 is a recent proposal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
Many SBC vendors would agree with your assessment. They would then add a list of the other advantages for putting application layer functionality into the network. The problems of this approach are, however, well-known. Hence, I would like to avoid them by decoupling the two interactions. Ciao Hannes Hallam-Baker, Phillip wrote: The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. The only difference is that we have both sides of the gateway running IP albeit with different numbering schemes. So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] Sent: Monday, July 16, 2007 01:30 AM Pacific Standard Time To: Brian E Carpenter Cc: Melinda Shore; ietf@ietf.org Subject:Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition Hi Brian, regarding lack of simplicity: Different solutions build on different assumptions. If you make specific assumptions then the solution is much simpler. There is a recent document that aims to compare some of the NAT / firewall protocol proposals: http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt It is not yet finished but might give you an idea what the different assumptions of some of the proposals are. Ciao Hannes Brian E Carpenter wrote: On 2007-07-14 00:07, Melinda Shore wrote: On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Maybe by a lack of simplicity? draft-woodyatt-ald-01 is a recent proposal. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 7/16/07 4:13 AM, Brian E Carpenter [EMAIL PROTECTED] wrote: Maybe by a lack of simplicity? Midcom and SIMCO are very simple. I think that there are a few problems, which taken in aggregate make NAT control a hard sell. One is that in even modestly complex networks either the application has to be aware of and make decisions about topology or that the traversal mechanism has to be aware of and make decisions about topology. I started the network-friendly midcom stuff (which turned into the NSIS nat and firewall work) because of that, but after having spent more time with it I really think it is not deployable in real networks, which we can talk about some other time. Another problem is the lack of naming and lookup facilities. DNS SRV records are probably going to be as good as it gets. VoIP protocols and others that make use of embedded addresses actually do have an advantage here, because they're able to transmit an acquired address in the application signaling. However, that won't help with servers, P2P, and so on. And, of course, there are heaps of political issues. Some of them are as crude as being about who controls what, but there are some more subtle ones around business models (the last time I talked about this Keith insisted that the IETF doesn't do business models, and I still encourage him to take a good look at what's going on in what's now the RAI area), as well, that shape the technical decisions that are made. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 7/16/07 6:29 AM, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. Maybe, but there are differences that make it harder. Chief among these is that there were one or two gateways for CSNet, a handful for BITNET, and so on, and there was just the one application. Furthermore, there was no need to either modify the endpoint or inform the endpoint that it should gateway its email through a particular host. The latter was handled on the server. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On Mon Jul 16 11:29:54 2007, Hallam-Baker, Phillip wrote: The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. The only difference is that we have both sides of the gateway running IP albeit with different numbering schemes. If I read this correctly, you're essentially stating that the Internet terminates at the ISP side of the NAT. So hosts located on the wrong side of the NAT are simply not part of the Internet - they merely happen to use the same technology. Is that a correct paraphrase of what you're saying? That does strikes me as a fundamental failing of NATs if so. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
Melinda Shore wrote: On 7/16/07 6:29 AM, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc. Maybe, but there are differences that make it harder. Chief among these is that there were one or two gateways for CSNet, a handful for BITNET, and so on, and there was just the one application. Furthermore, there was no need to either modify the endpoint or inform the endpoint that it should gateway its email through a particular host. The latter was handled on the server. Widespread deployment of ALG's as mediators means you have to upgrade the network to support new applications. or applications are built on top of hostile tunnels over your alg infrastructure (sound familiar?). While some enterprise networks seem to favor this, it's not really the Internet. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 7/16/07 10:43 AM, Joel Jaeggli [EMAIL PROTECTED] wrote: Widespread deployment of ALG's as mediators means you have to upgrade the network to support new applications. or applications are built on top of hostile tunnels over your alg infrastructure (sound familiar?). While some enterprise networks seem to favor this, it's not really the Internet. At some point a lot of these things tend to look awfully similar to one another (NATs look like tunnel endpoints look like relays, etc.) but they tend to break out into broad categories. So, you have some mechanisms that operate at the network layer and some that operate at the session or application layer. The lower in the stack they sit the more general they can be, clearly, but then you tend to encounter more problems around reachability and findability. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach. There are two ways I can read this, and I suspect I've got them both wrong. The first is the flag day meaning for where the numbering scheme changes--that is, re-deploy all applications on some day at which we decide the numbering scheme changes. The second is that you mean that any device which serves as an intersection point between v4 and v6 must also serve as a back-to-back user agent for all applications that run across it. That is, for the scenario v6-endpoint---[boundary]--v4 segment---[boundary]--v6-endpoint there would be a full-on termination of the application at each boundary, and a new application flow, which is itself not guaranteed to reach the original destination of the flow. Is either of those what you meant? If not, can you clarify? thanks, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
Fact: There are NATs and stateful packet filtering firewalls that cause problems for some applications. It is quite likely that these devices will not go away. Phillip also seems to have this view. I replied to him with regard to the conclusion he draw. He seems to think that the right way to deal with these boxes is to put application layer functionality on NATs (and potentially firewalls as well). I replied to his mail since I don't believe this is the right approach. Instead, I believe that the current work on legacy NAT traversal is already doing a good job. There is, however, room for improvement by allowing the end host to interact with NATs and firewalls. Some folks are working on this subject already for some time. Does this make sense to you? Ciao Hannes Iljitsch van Beijnum wrote: On 13-jul-2007, at 22:11, Hannes Tschofenig wrote: As Phillip stated, I don't see the problem with future applications. Compare this with the security aspects that are taken care of much more than before when developing new applications NAT traversal is just another thing to think about as a protocol designer. There is no magical NAT traversal switch that you can flip and your protocol will work through NAT with no problems 100% of the time. Just like there is no such switch for security. Yes, there were (are?) protocols that were more NAT-unfriendly than they needed to be, case in point FTP. I don't think the IETF creates protocols that fail when used through a NAT when it's just as easy to make the protocol work though the NAT as is the case with FTP. However, the reason why MOST protocols/applications have trouble with NAT is because they need to receive incoming sessions. Short of rewriting the protocol to work over UDP or through a third-party server, pretty much the only way to traverse NAT in these cases is to go up to the NAT device, and ask it to open up a TCP port, pretty please with a cherry on top? This works well if: - the NAT device is a fairly modern one created for a market where this functionality is considered important (i.e., home users) - the application or the OS implements the necessary open sesame logic - there is a well-reachable server providing referrals - there is only a single NAT between the outside and the host trying to receive incoming TCP sessions (There could be a firewall in the way, too, but that's not relevant for this discussion.) The first three are likely to get better in the future, but more than one NAT is extremely likely to become more common as we run out of IPv4 addresses. Note though that even with the above in place there are still problems caused by NAT that can only be solved by additional application logic or application layer gateways in the NAT. (The case where multi-party referrals by IP address happen. Yes, by FQDN would be better but not every host has a working DNS name.) So whichever way you slice it, the best case scenario for NAT is that it doesn't get in the way. The worst case is that it absolutely, positively breaks your application despite huge amounts of NAT workaround logic and a lot time spent debugging the problem. As with most things in life, some people are lucky enough to live in a best case world, others are prone to be bitten by the worst case more than their fair share. What I consider the most important problem with NATs is that they don't fail gracefully. When a NAT gets in the way, the application generally doesn't get to do what it wants to do, but without any feedback as to why. This means the user doesn't know what the problem is and doesn't have any clue about solving it. It's like a world where rather than giving you warnings or tickets, police officers sneak up on you from behind and knock you unconscious without you knowing why if you break a traffic rule. It's painful and you don't understand why it happens. Come to think of it, not unlike trying to send files or videoconference using instant messaging with a NAT at both ends. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Jul 13, 2007, at 10:57 AM, Hallam-Baker, Phillip wrote: I think we need to look beyond whether NAT is evil (or not) and whether NATPT is the solution (or not) and look to see how we might manage a transition to IPv6 in a way that is not predicated on holding ISP customers hostage. People have been there and done that, anyone remember when the anti- spam blacklists started talking about 'collateral damage' with great glee? Within a very short time a very large number of email admins hated the self appointed maintainers of the blacklists more than the spammers. Anyone with a published mailbox not protected by a blocking strategy quickly learns email is dysfunctional. Lost DSNs of silently discarded messages, or messages directed to a junk folders never reviewed are all too common problems. Black-hole lists bounded by AS CIDR ranges is not a gleeful strategy. Some ISPs host servers involved in nefarious activities and reassign addresses periodically to thwart a per address blocking strategy. To disabuse unfair accusations of abusing the service, we will offer a full range of blocking strategies freely selected by each customer. Customers can then find their optimal balance between filtering and IP address blocking techniques of which there are many. Unfortunately, few filtering applications alone are able to handle the current level of abuse without address black-holing. And unfortunately, offering a more graduated approach increases the level of abuse seen on the Internet as a whole. IPv6 will not make this problem go away. IPv6 will necessitate development of a means to positively verify the administrative domain of the _client_ sending traffic into the public address space before the transition to IPv6 can be embraced by existing public messaging services. We have three Internets: IPV4, IPv4+NAT and IPv6. Perhaps this breakdown should include these perspectives as well. IPv6+6to4, IPv6+NAT. This strongly suggests to me that during the transition, a period I expect to last until 2025, we will want the standard Internet allocation to be a /64 of IPv6 plus a share in a pool of IPv4 addreses behind a NAT. The correlation of IPv6 addresses within IPv4 space might be dynamically assigned by newer services, such as PNRP. NATs will remain a part of the Internet long into the foreseeable future, regardless of what might be said or done. Perhaps new types of DNS records need to be developed to express complex paths now required by today's applications operating within the reality of mixed topologies. Such navigation will likely be handled at what might be seen as new sub-layers. What I would like to get to is a situation where a consumer can 1) purchase Internet connectivity as a commodity with a well defined SLA that assures them that the connection will work for the purposes they wish to use it 2) obtain a report from their Internet gateway device(s) that tells them whether the SLA is being met or not. When an ISP permits their customers to abuse the Internet, recipients of this abuse MUST BE ALLOWED to block abusive traffic. These blocks will not disappear quickly, nor are these blocks directly managed by ISPs offering now blocked outbound connectivity. A customer of such an ISP may have no recourse, but to seek different providers regardless of what is within their SLA. There is no need to receive a report, the customer will be aware of the problem rather quickly. Perhaps this can be solved by offering a tasting period. ; ) From the point of view of the consumer all that matters is that their client applications and their peer-2-peer applications work. The typical consumer does not host servers at their home and we want the sophisticated consumer to move to IPv6. Consumers often violate the AUP of their residential Internet provider. Acknowledging this, some AUPs are making exceptions where semi-private versus public server use might be allowed. These exceptions often permits things like remote access or various peer-to- peer applications. These applications are fairly common and supported by various mechanisms included in typical IPv4 wireless routers. Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. I am mighty unimpressed by the fact that when I plug the VOIP connector made by vendor X into the wirless/NAT box made by vendor X that I have to muck about entering port forwarding controls by hand. And even less impressed by the fact that a good 50% of the anti-NAT sentiment on this list comes from employees of vendor X. STUN does not appear to me to be an architecturally principled approach, it is a work around. Techniques employed to navigate through NAT and firewall barriers are often based upon various assumptions. The small percentage of
Re: IPv4 to IPv6 transition
The way to fix this situation in my view is to make the NAT box SIP aware by building a SIP proxy capability into the NAT box. The designers of NAT boxes go to great efforts to try to work around applications. Leave approaches such as STUN to the case where you are dealing with a legacy box. My SIP ATA sits behind a iptables based NAT, and I have never had a problem with it. No STUN either. Symmetric IP Masquerading does the trick. Then again, it is not a commercial NAT device, just a function of the iptables firewalling suite in the linux kernel and associated userland tools. Enjoy, Scott sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. there are a couple of problems with this analysis: one is that it considers only application protocols that are in widespread use. there are lots of applications that are used by limited communities that are nevertheless important. and of course, since NATs are so pervasive, most of the applications that are in widespread use have been made to work with NAT (often at tremendous expense, and reduced reliability). another problem is that it only considers current applications. a big part of the problem with NAT is that it inhibits the development/deployment of useful new applications. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Future applications are the easiest to deal with. If we have a proper encapsulation of the network layer the application will run fine on either an IPv6 or an IPv4/NAT network or a transitional IPv6 plus NAT pool of IPv4 addresses. The only thing that the application designer needs to take care of is that they use an appropriately structured API that can handle 32/128 bit address issues. This is no different in principle from what is involved in writing clean 32/64 code. From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Fri 13/07/2007 3:27 PM To: Hallam-Baker, Phillip Cc: Stephen Sprunk; Jun-ichiro itojun Hagino; Paul Hoffman; ietf@ietf.org Subject: Re: IPv4 to IPv6 transition Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. there are a couple of problems with this analysis: one is that it considers only application protocols that are in widespread use. there are lots of applications that are used by limited communities that are nevertheless important. and of course, since NATs are so pervasive, most of the applications that are in widespread use have been made to work with NAT (often at tremendous expense, and reduced reliability). another problem is that it only considers current applications. a big part of the problem with NAT is that it inhibits the development/deployment of useful new applications. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Hallam-Baker, Phillip wrote: Future applications are the easiest to deal with. If we have a proper encapsulation of the network layer the application will run fine on either an IPv6 or an IPv4/NAT network or a transitional IPv6 plus NAT pool of IPv4 addresses. The only thing that the application designer needs to take care of is that they use an appropriately structured API that can handle 32/128 bit address issues. This is no different in principle from what is involved in writing clean 32/64 code. I always find these kinds of statements amusing. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Hi Phillip, ~Snip~ Most application protocols work just fine behind NAT. I agree. I am playing games for a really long time and I rarely had ever problems with NATs. Obviously these companies don't shy away from solution that would be classified as architectural not nice. Without knowing the NAT traversal details of the different games I play I could imagine that they even carry their payloads on top of HTTP, if nothing else works. Nasty! FTP works with an ugly work-around. The main protocol that breaks down is SIP. Not with the work that was done on NAT traversal. I am mighty unimpressed by the fact that when I plug the VOIP connector made by vendor X into the wirless/NAT box made by vendor X that I have to muck about entering port forwarding controls by hand. And even less impressed by the fact that a good 50% of the anti-NAT sentiment on this list comes from employees of vendor X. STUN does not appear to me to be an architecturally principled approach, it is a work around. I wonder why you think so. What's the problem with STUN? The way to fix this situation in my view is to make the NAT box SIP aware by building a SIP proxy capability into the NAT box. The designers of NAT boxes go to great efforts to try to work around applications. Leave approaches such as STUN to the case where you are dealing with a legacy box. I think that's a really horrible solution. There are good protocols out there to provide legacy NAT traversal. If NAT (and firewall vendors) would implement protocols that support NAT traversal then the performance issues can also be taken care of. Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Hi Keith, Keith Moore wrote: Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. there are a couple of problems with this analysis: one is that it considers only application protocols that are in widespread use. there are lots of applications that are used by limited communities that are nevertheless important. Namely? and of course, since NATs are so pervasive, most of the applications that are in widespread use have been made to work with NAT (often at tremendous expense, and reduced reliability). Could you explain the tremendous expense a bit more? another problem is that it only considers current applications. a big part of the problem with NAT is that it inhibits the development/deployment of useful new applications. As Phillip stated, I don't see the problem with future applications. Compare this with the security aspects that are taken care of much more than before when developing new applications NAT traversal is just another thing to think about as a protocol designer. Ciao Hannes Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
there are a couple of problems with this analysis: one is that it considers only application protocols that are in widespread use. there are lots of applications that are used by limited communities that are nevertheless important. Namely? that's a silly question. you wouldn't recognize the names if you saw them, because they're not in widespread use. and of course, since NATs are so pervasive, most of the applications that are in widespread use have been made to work with NAT (often at tremendous expense, and reduced reliability). Could you explain the tremendous expense a bit more? several kinds of expense: one is due to added implementation complexity where you have to implement your own addressing and routing scheme within the application - and this results also in poorer performance and (usually) degraded reliability because there are more things in the signal path that can fail. another kind of expense is that when trying to set up communication between two or more peers that are all behind NAT you usually need to have a rendezvous server that is on the public network that can mediate between the hosts that are NAT-crippled. it costs money to provide those servers, especially if you get a lot of usage. this tends to mean that the application can no longer be free or open source, because there has to be a way to pay for those servers. this is hugely costly to the user community. another problem is that it only considers current applications. a big part of the problem with NAT is that it inhibits the development/deployment of useful new applications. As Phillip stated, I don't see the problem with future applications. that's probably because you don't develop applications, so you can afford to be naive about them. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 13-jul-2007, at 22:11, Hannes Tschofenig wrote: As Phillip stated, I don't see the problem with future applications. Compare this with the security aspects that are taken care of much more than before when developing new applications NAT traversal is just another thing to think about as a protocol designer. There is no magical NAT traversal switch that you can flip and your protocol will work through NAT with no problems 100% of the time. Just like there is no such switch for security. Yes, there were (are?) protocols that were more NAT-unfriendly than they needed to be, case in point FTP. I don't think the IETF creates protocols that fail when used through a NAT when it's just as easy to make the protocol work though the NAT as is the case with FTP. However, the reason why MOST protocols/applications have trouble with NAT is because they need to receive incoming sessions. Short of rewriting the protocol to work over UDP or through a third-party server, pretty much the only way to traverse NAT in these cases is to go up to the NAT device, and ask it to open up a TCP port, pretty please with a cherry on top? This works well if: - the NAT device is a fairly modern one created for a market where this functionality is considered important (i.e., home users) - the application or the OS implements the necessary open sesame logic - there is a well-reachable server providing referrals - there is only a single NAT between the outside and the host trying to receive incoming TCP sessions (There could be a firewall in the way, too, but that's not relevant for this discussion.) The first three are likely to get better in the future, but more than one NAT is extremely likely to become more common as we run out of IPv4 addresses. Note though that even with the above in place there are still problems caused by NAT that can only be solved by additional application logic or application layer gateways in the NAT. (The case where multi-party referrals by IP address happen. Yes, by FQDN would be better but not every host has a working DNS name.) So whichever way you slice it, the best case scenario for NAT is that it doesn't get in the way. The worst case is that it absolutely, positively breaks your application despite huge amounts of NAT workaround logic and a lot time spent debugging the problem. As with most things in life, some people are lucky enough to live in a best case world, others are prone to be bitten by the worst case more than their fair share. What I consider the most important problem with NATs is that they don't fail gracefully. When a NAT gets in the way, the application generally doesn't get to do what it wants to do, but without any feedback as to why. This means the user doesn't know what the problem is and doesn't have any clue about solving it. It's like a world where rather than giving you warnings or tickets, police officers sneak up on you from behind and knock you unconscious without you knowing why if you break a traffic rule. It's painful and you don't understand why it happens. Come to think of it, not unlike trying to send files or videoconference using instant messaging with a NAT at both ends. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
Iljitsch van Beijnum wrote: I don't think the IETF creates protocols that fail when used through a NAT when it's just as easy to make the protocol work though the NAT as is the case with FTP. yes, but it's not just as easy to make FTP work through the NAT...at least, not without losing the ability for one host to transfer files between two other hosts. (it turns out that in the modern world, this feature of the FTP protocol is dangerous for security reasons. but it was a useful feature, and the existence of NATs make it difficult to re-implement that feature.) However, the reason why MOST protocols/applications have trouble with NAT is because they need to receive incoming sessions. Short of rewriting the protocol to work over UDP or through a third-party server, pretty much the only way to traverse NAT in these cases is to go up to the NAT device, and ask it to open up a TCP port, pretty please with a cherry on top? This works well if: - the NAT device is a fairly modern one created for a market where this functionality is considered important (i.e., home users) - the application or the OS implements the necessary open sesame logic - there is a well-reachable server providing referrals - there is only a single NAT between the outside and the host trying to receive incoming TCP sessions - and the site isn't relying on the NAT to also be a firewall. ...and the only problem I have with the above is that the word MOST can be misleading. it's not as if most of the problems with NATs would go away if only all NATs were to suddenly support UPnP extensions to allow NAT traversal. that would certainly help, but significant brain-damage would remain. also, your MOST is based on how things are today, but the net seems to change fairly significantly every two years. The first three are likely to get better in the future, but more than one NAT is extremely likely to become more common as we run out of IPv4 addresses. Note though that even with the above in place there are still problems caused by NAT that can only be solved by additional application logic or application layer gateways in the NAT. and only if the NAT can somehow be aware of every application that needs to traverse it - including proprietary applications, enterprise-specific applications, applications that need end-to-end encryption, and so on. in other words, putting ALGs in the NATs is not a practical solution. (The case where multi-party referrals by IP address happen. Yes, by FQDN would be better but not every host has a working DNS name.) which, coupled with several other reasons, implies that FQDNs would not necessarily be better. So whichever way you slice it, the best case scenario for NAT is that it doesn't get in the way. The worst case is that it absolutely, positively breaks your application despite huge amounts of NAT workaround logic and a lot time spent debugging the problem. As with most things in life, some people are lucky enough to live in a best case world, others are prone to be bitten by the worst case more than their fair share. yup. the point is that it's a large and diverse network, and sweeping generalizations about things like how NAT affects that network are extremely dubious. What I consider the most important problem with NATs is that they don't fail gracefully. what I consider the most important problem with NATs is that they're not accountable for the damage that they do. similarly for interception proxies. so when the application breaks, the reason it breaks is not apparent to the user or to the party that installed the box that modified the traffic, and it's hard to get the problem fixed (e.g. by firing the sysadmin who installed the damn thing, or by ceasing to do business with the NAT or proxy vendor that misrepresented his product). things that actively modify traffic without being visible to end systems are almost inherently going to cause huge problems if they're widely deployed. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
...and the only problem I have with the above is that the word MOST can be misleading. it's not as if most of the problems with NATs would go away if only all NATs were to suddenly support UPnP extensions to allow NAT traversal. that would certainly help, but significant brain-damage would remain. also, your MOST is based on how things are today, but the net seems to change fairly significantly every two years. I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. UPnP is not that protocol. In an IPv6 world there will still be site perimeter gateways which block incoming traffic, just like PAT/NAT does today. It would simplify life if hosts could register an interest with their site perimeter gateway so that when a packet of interest comes along, the gateway can either forward it, or notify the host that the packet will be queued for pickup. Presumably the notification and packet release will be done over distances less than a kilometer or two so that the turnaround time does not prevent TCP sockets from being opened. This sort of general protocol still provides site protection. For instance the site administrators can choose which hosts to parley with. It could also be leveraged to provide some sort of host proxy services, i.e. my host tells the site perimeter to accept VoIP calls for me and forward those calls to host X when I'm not there. When I disconnect or shutdown my host, keepalives not longer go to the gateway, and any incoming VoIP calls go to the designated host proxy which accepts the calls for me. Of course this host proxy is a fancy answering machine, or maybe it is a device which can shunt the call to my mobile phone. Of course, before we can realistically define such a protocol, we need to define the role of a site perimeter gateway, probably with different levels of service corresponding to different site sizes and different administrative models. Once the world was simple and there were hosts (computers), routers (special dedicated computers) and bridges. Now it is rather more complex with firewalls, load balancers, switch/routers and so on. Leaving aside the question of whether or not an IPv6 Internet site perimeter gateway needs to be in a single device or not, just what must it do, what might it do, and what will it not do? --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition
On 7/13/07 5:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe that we need a more general protocol for hosts inside a site perimeter to communicate with the perimeter gateways and request services from them. We've actually got several of them, starting with SOCKS (which could have been extended), continuing through RSIP, on to midcom and SIMCO. Note that midcom was so named under the assumption that whatever was done would be extensible to other sorts of middleboxes than firewalls and NATs We could spend an awful lot of time talking about why none of them has caught on, but I think it's fair to say that that failure has not been caused by a perceived lack of generality. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
There are two fundamental flaws with your claims. 'What we need is a transition strategy that is more effective than dual stack.' 'The typical consumer does not host servers.' There is no 'one size fits all' transition strategy, and no amount of hot air will fix that. Dual-stack is promoted as the primary path because it allows for an application by application graceful deployment by each independent organization. Every other approach applies a forcing function somewhere, and those typically come with a cost that is not localized to the person doing the work. As you note, it assumes that IPv4 is retained to allow that smooth transition. If people insist on waiting until there is no more IPv4 to be had, the state will no longer be dual-stack, it will be a panic driven deployment of hacks. For dual-stack to work, people need to use the approach well ahead of IPv4 exhaustion. Claiming we need something more effective is just hot-air, because 'effectiveness' will be measured differently in every one of the millions of individual deployment environments. The second statement is the result of nat, not a desired situation. The average non-geek will not intentionally host a service, but anyone that runs skype or the like without a nat is providing a super-node service. Despite your claim, typical consumers do this kind of hosting, and would do more of it if there were no nat. The more we move toward p2p apps being the norm, the more that services will be hosted on non-traditional 'servers' and at non-traditional points in the network (ie: the home). The real solution to your claim about the need for a more effective strategy would be to stop allocating IPv4 to the ISPs that do not deliver IPv6 native service to all of their customers. If the IPv6 native service existed the dual-stack approach would work just fine. Of course the IETF can't tell the RIRs to stop allocating IPv4, and since the RIRs are dominated by the ISPs there is no chance of a policy change that would force deployment of IPv6 to the edges. In the end, the IETF did what it could do by defining a set of tools that can be used to get IPv6 deployed. The fact that the ISPs are not taking advantage of those and moving ahead is outside of what we can impact. If they try and come back with complaints about tools not working, we can work to fix those, but at the current burn rate the time for any standards fixing has passed. Even if we modified the spec for transition tools today, by the time the resulting products hit the streets we would be well into panic mode from the exhaustion of IPv4. Essentially the only thing we can do now is stand back and get ready to roast marshmallows on the fire of the media driven panic when the pool runs dry. Tony From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Friday, July 13, 2007 10:57 AM To: Stephen Sprunk; Keith Moore; Jun-ichiro itojun Hagino Cc: Paul Hoffman; ietf@ietf.org Subject: IPv4 to IPv6 transition I think we need to look beyond whether NAT is evil (or not) and whether NATPT is the solution (or not) and look to see how we might manage a transition to IPv6 in a way that is not predicated on holding ISP customers hostage. People have been there and done that, anyone remember when the anti-spam blacklists started talking about 'collateral damage' with great glee? Within a very short time a very large number of email admins hated the self appointed maintainers of the blacklists more than the spammers. We have three Internets: IPV4, IPv4+NAT and IPv6. Clearly the IPv4 Internet is going to run out of addresses. That does not mean that IPv4 will go away however. As far as the ISPs are concerned IPv4+NAT works just fine for residential connections. What we need is a transition strategy that is more effective than dual stack. IPv6 is not going to work as a solution to the IPv4 address space crunch if every IPv6 Internet user has to have an IPv4 address as well. This strongly suggests to me that during the transition, a period I expect to last until 2025, we will want the standard Internet allocation to be a /64 of IPv6 plus a share in a pool of IPv4 addreses behind a NAT. What I would like to get to is a situation where a consumer can 1) purchase Internet connectivity as a commodity with a well defined SLA that assures them that the connection will work for the purposes they wish to use it 2) obtain a report from their Internet gateway device(s) that tells them whether the SLA is being met or not. From the point of view of the consumer all that matters is that their client applications and their peer-2-peer applications work. The typical consumer does not host servers at their home and we want the sophisticated consumer to move to IPv6. Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. I am mighty unimpressed by the fact that when I plug the VOIP connector made by
