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: 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: 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
On Jul 16, 2007, at 4:51 AM, Melinda Shore wrote: 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. Complex arrangements are currently are being establishing for peer-to- peer communications. These arrangements entail a structure of IP addresses used to navigate through various devices supporting protocols like Teredo. DNS currently does not provide a specific resource record type for this purpose, although conceivably fields such as Priority within an SRV resource record could define a topology structure. These addresses might then be employed at different stages of a transport topology. DNS SRV records normally return a list of IP addresses as additional information, where an application would then need to arrange this information. Although DNS is not normally used in this fashion, for our application, DNS servers are updated every so many seconds where each contains millions of records. This is done while responding to tens of thousand of queries per second. DNS protocol is also commonly used to track dynamic addresses assigned to residential routers. These routers are then associated with internal hosts having a dynamic address. Obviously DNS can handle very dynamic environments. There is little infrastructure to support this type of volatility at this time. This lack of support may change when the marketplace desires non-proprietary solutions. -Doug ___ 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
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: 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 t
