Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
Who said anything about necessary state and reasonable timeouts? I've seen more than one brand of consumer-grade box with NAT features that could not be turned off, and that even in their most permissive settings kill ssh sessions after an hour or two whether the ssh sessions had been active or not. I have one that shot down my ssh sessions after 5 minutes of aparent inactivity - Hey this tcp session hasn't seen any pr0n in 5 minutes. It must be a stalled http. Let's kill it! This is a *major* supplier of soho equipment. Moreover it was clear from the support-forum that this was a concious choice. The question is what effect a BCP from the BEHAVE-wg would have. Personally I am an optimist. Cheers Leif ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
-BEGIN PGP SIGNED MESSAGE- Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: I agree with Harald that v4 NATs are going to be here a decade from now. But that's irrelevant, if those people using the NAT only use simple client-server applications. Harald Well my house was behind 2 levels of NAT until last Harald week. Once i got rid of one level (the one I don't Harald control), some of my operational problems with keeping SSH Harald sessions up simply went away. And SSH is a client-server Harald protocol. So, you were happier with less NAT. See, I knew that making you happier behind the NAT was the wrong solution. - -- ] Elmo went to the wrong fundraiser - The Simpson | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQVL8iYqHRg3pndX9AQFmXgQAwLj3aqv7PMdSFGM3HW3147h57y78qf4S j3XUNNRQ1TfXZ8dnbjzH8vlTf+8qlmTO6eswB73ybzdwa7aG7AC7SEhYyQGWWDtR VCP+lW6AiceW5z+i7NxaWgg2baDbOgkAGSfHED53MIu+OicgG5G3FviuQ3gkzMq1 gxYgzYdFMm8= =OKNc -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
On Tue, 21 Sep 2004, Harald Tveit Alvestrand wrote: The point is which kind of applications you can reasonably expect to deploy behind an IPv4 NAT, and be happy. I agree with Harald that v4 NATs are going to be here a decade from now. But that's irrelevant, if those people using the NAT only use simple client-server applications. Well my house was behind 2 levels of NAT until last week. Once i got rid of one level (the one I don't control), some of my operational problems with keeping SSH sessions up simply went away. And SSH is a client-server protocol. Don't underestimate the capability of badly implemented and/or configured NATs to make things go boom in the night. FWIW, I don't think this is something that can be fixed whatever guidance the IETF would give. NATs will always need to keep some state for all the protocols, including TCP, and that state must be removed after a timeout. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
From: Pekka Savola [EMAIL PROTECTED] To: Harald Tveit Alvestrand [EMAIL PROTECTED] Well my house was behind 2 levels of NAT until last week. Once i got rid of one level (the one I don't control), some of my operational problems with keeping SSH sessions up simply went away. And SSH is a client-server protocol. Don't underestimate the capability of badly implemented and/or configured NATs to make things go boom in the night. FWIW, I don't think this is something that can be fixed whatever guidance the IETF would give. NATs will always need to keep some state for all the protocols, including TCP, and that state must be removed after a timeout. Who said anything about necessary state and reasonable timeouts? I've seen more than one brand of consumer-grade box with NAT features that could not be turned off, and that even in their most permissive settings kill ssh sessions after an hour or two whether the ssh sessions had been active or not. Then there are notions of DMZs, game playing mode, and VPN support. What you might guess from feature-list bullet items probably sound reasonable, but you'd probably guess wrong about what the bullet items really mean in products delivered to users. Harald misstated his injunction. You should never underestimate the capabilities of people to build things that make you say no one would do that! and then defend their braindamage as valuable features. Perhaps more NAT RFCs would help; they couldn't hurt much. They'd be a lot of work and would certainly be ignored by many people who consider themselves designers. I can't personally get enthused about telling people things that are obvious and that will be ignored, like much of what would go in new NAT RFCs. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
-BEGIN PGP SIGNED MESSAGE- Vernon == Vernon Schryver [EMAIL PROTECTED] writes: Vernon Perhaps more NAT RFCs would help; they couldn't hurt much. Vernon They'd be a lot of work and would certainly be ignored by Vernon many people who consider themselves designers. I can't Vernon personally get enthused about telling people things that are Vernon obvious and that will be ignored, like much of what would go Vernon in new NAT RFCs. They would help yes. They do have multiple costs: most people time. As you say. I can not agree more with what you said. The only value I can see to them is as a stick. Given RFC3022, RFC2663, RFC3235, etc. do we really need more carrots? Since I don't anticipate being able to book an RFC1812 compliant hotel room anytime, I'm not sure that I see the point in expending more energy. - -- ] Elmo went to the wrong fundraiser - The Simpson | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQVMhIIqHRg3pndX9AQFIbAP/QWxSeYhGMHknOmYrRUnH8DWuwfsD6Vaz eA45aK+wNN7Hc8Y4OqjMDz29pTjXEJloWOkEUleaKF2ZDBmSlXjj5bH0WlbAXJ/8 K93DSmZ1zizLMb8pVNnZjIddtJGLgYMpnF90GeU9Wv/KHhBNrnzraclz25nZKunr 3631Vmv9yZY= =DYJN -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
(Removed Cc: iesg) On Mon, 20 Sep 2004, Harald Tveit Alvestrand wrote: --On mandag, september 20, 2004 14:38:51 -0400 Michael Richardson [EMAIL PROTECTED] wrote: Harald And - here I am making a real leap of faith - if the IETF Harald recommendations for NAT devices make manufacturers who Harald listen to them create NAT devices that make their customers Harald more happy, then many of these new NAT devices may be Harald conformant to IETF recommendations. Do we really want customers of NAT devices to be happy? Given that I'm one of them, and will continue to be one until the IPv4 Internet fades to where I can ignore it yes. The point is not whether the users behind an IPv4 NAT are happy or not. The point is which kind of applications you can reasonably expect to deploy behind an IPv4 NAT, and be happy. I agree with Harald that v4 NATs are going to be here a decade from now. But that's irrelevant, if those people using the NAT only use simple client-server applications. What matters is the peer-to-peer, etc. applications which typically require solutions like STUN, TURN, Teredo, etc. My argument is that we can simplify the architecture significantly if we can assume that v4 NAT can be treversed using one particular mechanism (e.g., Teredo), and all the applications which have a more complex model than just client-server are just recommended to use IPv6 instead. If we can provide a reasonably working IPv6 connectivity solution(s), we wouldn't have to try to figure out how to make NATs behave better, how to build robust applications to work with these nicely or badly behaving NATs, etc. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
--On tirsdag, september 21, 2004 13:55:10 +0300 Pekka Savola [EMAIL PROTECTED] wrote: (Removed Cc: iesg) On Mon, 20 Sep 2004, Harald Tveit Alvestrand wrote: --On mandag, september 20, 2004 14:38:51 -0400 Michael Richardson [EMAIL PROTECTED] wrote: Harald And - here I am making a real leap of faith - if the IETF Harald recommendations for NAT devices make manufacturers who Harald listen to them create NAT devices that make their customers Harald more happy, then many of these new NAT devices may be Harald conformant to IETF recommendations. Do we really want customers of NAT devices to be happy? Given that I'm one of them, and will continue to be one until the IPv4 Internet fades to where I can ignore it yes. The point is not whether the users behind an IPv4 NAT are happy or not. The point is which kind of applications you can reasonably expect to deploy behind an IPv4 NAT, and be happy. I agree with Harald that v4 NATs are going to be here a decade from now. But that's irrelevant, if those people using the NAT only use simple client-server applications. Well my house was behind 2 levels of NAT until last week. Once i got rid of one level (the one I don't control), some of my operational problems with keeping SSH sessions up simply went away. And SSH is a client-server protocol. Don't underestimate the capability of badly implemented and/or configured NATs to make things go boom in the night. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
I think the real point is that it's quite unrealistic at this stage in the history of NAT to imagine that we can make the mess (which was inevitable anyway) any better by codifying the least-bad form of NAT behaviour. The NAT codes are shipped, burnt into lots of devices, and the IETF can't do much about it. So I think this would be wasted effort. Brian Pekka Savola wrote: [[ Resending the comment to [EMAIL PROTECTED] as [EMAIL PROTECTED] illegitimately *) automatically rejects the posts by non-subscribers. *) http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt ]] On Fri, 17 Sep 2004, The IESG wrote: A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list ([EMAIL PROTECTED]) by September 24. I do not think it's useful to spend too much energy in trying to figure how NATs work (or do not work). Further, even though the draft charter talks about IPv6 and eventual deployment, it seems to be ignoring the fact that if you use an IPv6 transition mechanism which is specifically designed to traverse NATs (see e.g., draft-huitema-v6ops-teredo-xx [this should probably be on the 'reading list']), you don't have these problems. And if you are able to use a transition mechanism which is not tied to the IP versions supported by your ISP own, the barrier for IPv6 deployment should be significantly reduced. Therefore the issue seems to boil down to whether the NAT traversal mechanism described in draft-huitema-v6ops-teredo-xx is sufficient to traverse the NATs, and whether the support for something like Teredo is expected to be sufficiently commonplace to depend on it. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
--On 20. september 2004 14:03 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: I think the real point is that it's quite unrealistic at this stage in the history of NAT to imagine that we can make the mess (which was inevitable anyway) any better by codifying the least-bad form of NAT behaviour. The NAT codes are shipped, burnt into lots of devices, and the IETF can't do much about it. So I think this would be wasted effort. My take (which is obviously biased) is that the number of NAT devices 2 years from now is likely to be significantly larger than the number of NAT devices currently deployed. And - here I am making a real leap of faith - if the IETF recommendations for NAT devices make manufacturers who listen to them create NAT devices that make their customers more happy, then many of these new NAT devices may be conformant to IETF recommendations. If we're really, really lucky - and reasonably fast - we could make the experience of people using the Internet better - make the Internet work better for those users. And that's what the IETF is supposed to do, isn't it? (Note - I sympathize with Pekka's touching faith in Teredo as the Big Solution I hope he's right. So the NAT recommendations may in that case boil down to a single sentence: Don't break Teredo If that's the case it's worth saying.) Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
-BEGIN PGP SIGNED MESSAGE- Harald == Harald Tveit Alvestrand [EMAIL PROTECTED] writes: Harald My take (which is obviously biased) is that the number of Harald NAT devices 2 years from now is likely to be significantly Harald larger than the number of NAT devices currently deployed. Yes, I agree. And multiple layers too. And at higher speed points in the network. Harald And - here I am making a real leap of faith - if the IETF Harald recommendations for NAT devices make manufacturers who Harald listen to them create NAT devices that make their customers Harald more happy, then many of these new NAT devices may be Harald conformant to IETF recommendations. Do we really want customers of NAT devices to be happy? Harald (Note - I sympathize with Pekka's touching faith in Teredo Harald as the Big Solution I hope he's right. So the NAT Harald recommendations may in that case boil down to a single Harald sentence: Harald Don't break Teredo Harald If that's the case it's worth saying.) I don't think we need a working group to say this. I think that the IAB could write a document much easier that said that. - -- ] Elmo went to the wrong fundraiser - The Simpson | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQU8juoqHRg3pndX9AQGf5QQAmosDzc+v6l5dhfmedxwaikVvmFhe6/eE LR/Re6jZ5NTjv6r51ea51bN8WOndaWp6zskwXLf+dKKfk0Ymqez7KN42nwmta0Qi 2eow3xUbzsse4zAXYH2Op7HLHJEZS4SQ16M92TBxay9hvoYj6mKnkxOp5DdbMXeQ RhFiISfLMIg= =NZkz -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
inline. Michael Richardson wrote: Harald And - here I am making a real leap of faith - if the IETF Harald recommendations for NAT devices make manufacturers who Harald listen to them create NAT devices that make their customers Harald more happy, then many of these new NAT devices may be Harald conformant to IETF recommendations. Do we really want customers of NAT devices to be happy? I think we want to enable an Internet that works and serves the needs of its users. We are still going to be seeing IPv4 on the network for a while still, and I believe it is worth our time to make sure that new applications can more easily be built for that network. During the BoF session, there were folks from many of the major vendors of such devices, and those folks said that they felt that the IETF recommendations on NAT behavior stood a good chance of being implemented. Harald (Note - I sympathize with Pekka's touching faith in Teredo Harald as the Big Solution I hope he's right. So the NAT Harald recommendations may in that case boil down to a single Harald sentence: Harald Don't break Teredo Harald If that's the case it's worth saying.) I don't think we need a working group to say this. I think that the IAB could write a document much easier that said that. I think the work to be done is far more complicated than just saying don't break teredo. There is a lot of variability in NAT treatment of fundamental IP protocols - UDP, TCP, etc. Nailing down these variabilities can make applications more robust, more secure, and easier to design and deploy - a goal I think we all share. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D.600 Lanidex Plaza Chief Technology OfficerParsippany, NJ 07054-2711 dynamicsoft [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
--On mandag, september 20, 2004 14:38:51 -0400 Michael Richardson [EMAIL PROTECTED] wrote: Harald And - here I am making a real leap of faith - if the IETF Harald recommendations for NAT devices make manufacturers who Harald listen to them create NAT devices that make their customers Harald more happy, then many of these new NAT devices may be Harald conformant to IETF recommendations. Do we really want customers of NAT devices to be happy? Given that I'm one of them, and will continue to be one until the IPv4 Internet fades to where I can ignore it yes. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
Harald, My take (which is obviously biased) is that the number of NAT devices 2 years from now is likely to be significantly larger than the number of NAT devices currently deployed. And - here I am making a real leap of faith - if the IETF recommendations for NAT devices make manufacturers who listen to them create NAT devices that make their customers more happy, then many of these new NAT devices may be conformant to IETF recommendations. I think this ship has left port a long time ago and the likelihood that the IETF can now effect enough change to make it possible to write new applications that work consistently in the presence of NATs is very low. The installed base is much to large and NAT is showing up in devices being built by people who don't pay too much attention to the IETF. The same folks who do not build in IPv6, who break path MTU discovery, who strip out TCP options, etc. Now we expect them to build good NATs... This is the IETF and if there is a constituency for working on this then I think it should happen. However, I hope no one will be surprised in 2-3 years that nothing much has changed. Bob ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
On Monday, September 20, 2004, at 06:09 PM, Bob Hinden wrote: I think this ship has left port a long time ago and the likelihood that the IETF can now effect enough change to make it possible to write new applications that work consistently in the presence of NATs is very low. The installed base is much to large and NAT is showing up in devices being built by people who don't pay too much attention to the IETF. The same folks who do not build in IPv6, who break path MTU discovery, who strip out TCP options, etc. Now we expect them to build good NATs... I'm ambivalent about it for some of the reasons you mention, plus others. I think it's important to understand that NAT really is going to be with us for the foreseeable future. It's fairly common now to have corporate security auditors require the use of NAT as a security device. That's a big fat training and cultural problem, and I don't see how the IETF would be able to change it. I don't think that it's completely unthinkable that the *unavailability* of v6 NAT might hold up a transition to v6 in some corporate environments because of their undereducated security auditors. The other thing that's important to understand is that there are often big changes between firmware releases for many consumer NAT products, and that NAT vendors tend not to see making those changes as a terrificly huge deal. I don't think I agree with your concerns about lack of interest in implementation. That said, this work in the IETF is being driven by people whose protocols break when they have a NAT in the path. I have some concerns about underinvolvement by people who build NATs for a living, but I think that it's important to at least get some requirements laid out so that it's clear what NAT manufacturers could be doing if they were interested. And I think they are interested - they're hearing complaints from their customers. My biggest concerns are about 1) scope creep, and 2) a bunch of workarounds being cobbled together and interfering with getting something better deployed. People who attended the IETF 60 BOF showed some enthusiasm for specifying inspection behaviors, which is pretty appalling on several levels. On the second point, I think there's legitimate concern that this is part of a process of developing a big jumble of duct tape and baling wire. Part of the problem here is that there's not yet a deployed solution for communicating directly with NATs, so in the interim we're doing STUN. STUN, however, doesn't work across certain varieties of NATs, so good NAT behavior has to be specified. And so it goes. Melinda ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
-BEGIN PGP SIGNED MESSAGE- I agree with Melinda. I would very much like to be able to let the desk clerk at the hotel know that I won't be paying for their Internet service, because it wasn't RFC compliant. (I now wish that someone did get the trademark on that word, and would deny it to locations that offer only NATwork service) That's the only value I see in this situation. For the the vendors that have a clue, and will likely be involved in this process, they are likely already compliant. For those that aren't compliant, they won't be there. That's tough for them. - -- ] Elmo went to the wrong fundraiser - The Simpson | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQU99x4qHRg3pndX9AQEcZwQA4i29k5yetBQw4We1w6MUPxxrHWqZyfey QQ3Dz8KA5ESIjIyxV1q8BEXCGjHWQDFdyu4aN/aztwaoYNIiEnf6WCCx6/tNkQr8 OlxCTdE/0gZtEgQ1vkY06JM8Tjy4HtVhwx+hJp8RspuATmV+3j605h4Y5oriZNgk Xz3QlHLbCMk= =2cJx -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
--On Monday, 20 September, 2004 21:38 +0200 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: Do we really want customers of NAT devices to be happy? Given that I'm one of them, and will continue to be one until the IPv4 Internet fades to where I can ignore it yes. Harald, let me make an observation that I made a few weeks ago that that, to my astonishment, actually made Latif happy. In your case, this is just a guess, but you are probably behind a NAT for two reasons (Melinda's observation about increasing corporate policies might well be a third). One is the perceived shortage of IPv4 space. Whether that perception is real, or is a marketing mechanism by ISPs who would prefer to sell you something more expensive, or is just a delusion is irrelevant for this purpose. The point is that you are behind a NAT, in part, because no one has given you enough IPv4 space. The second is that, if I'm a vendor of cheap cable/ DSL routers, I've got to love NATs. My device gets one address from the ISP. Every single clueless customer of the device has the same address space, the same netmask, etc. It is a customer support dream because no one calls up and asks unique questions about address ranges, funny masks, trick routing between addresses on both sides of the router, and so on. Until and unless we have arrangements for IPv6 that use public address space but * can be built into cheap products, and * don't impose any greater customer support costs on those vendors, or the ISPs whose customers patronize them, then the current devices do, I think it is safe to predict that IPv6 will not reduce the NAT frequency for SOHO situations one bit. I hate that conclusion but I fear it is realistic. To a certain extent, we are _causing_ NATs, especially in IPv6 environments. Now, is it worthwhile, given that, to allocate resources into this proposed WG or should the resources be put into tidying up the edges of IPv6 configuration? I don't know, but I strongly suspect that the people who are likely to do the work are different. And, if they are, this is probably a good idea, however distasteful some of us find it. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
inline. Michael Richardson wrote: I agree with Melinda. I would very much like to be able to let the desk clerk at the hotel know that I won't be paying for their Internet service, because it wasn't RFC compliant. (I now wish that someone did get the trademark on that word, and would deny it to locations that offer only NATwork service) Well, I suspect the hotel clerk won't understand and certainly won't care what an RFC is. But, their service provider does, and I'm more hopeful that the RFP's and RFI's they produce and send to their vendors includes a statement that their NATs need to be RFC compliant, because it increases the ability of their networks to support applications that are ultimately driving demand for those networks. That's the only value I see in this situation. For the the vendors that have a clue, and will likely be involved in this process, they are likely already compliant. For those that aren't compliant, they won't be there. That's tough for them. Actually, it's surprisingly more complicated than one might think to determine what the right thing is, in terms of NAT behavior and treatment of basic protocols such as UDP. Even clueful vendors appear to have differing treatments even within the same product families [1]. For some of these behaviors, such as the UDP binding timeout interval, there is value in trying to shepherd everyone to arrive at a common minimal value (as in, the binding timeout MUST be greater than X). For that example, it's not an issue of clueful or clueless implementations, but rather, getting folks at a consistent value. That is exactly what standards are for. Thanks, Jonathan R. [1] http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-01.txt -- Jonathan D. Rosenberg, Ph.D.600 Lanidex Plaza Chief Technology OfficerParsippany, NJ 07054-2711 dynamicsoft [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
[[ Resending the comment to [EMAIL PROTECTED] as [EMAIL PROTECTED] illegitimately *) automatically rejects the posts by non-subscribers. *) http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt ]] On Fri, 17 Sep 2004, The IESG wrote: A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list ([EMAIL PROTECTED]) by September 24. I do not think it's useful to spend too much energy in trying to figure how NATs work (or do not work). Further, even though the draft charter talks about IPv6 and eventual deployment, it seems to be ignoring the fact that if you use an IPv6 transition mechanism which is specifically designed to traverse NATs (see e.g., draft-huitema-v6ops-teredo-xx [this should probably be on the 'reading list']), you don't have these problems. And if you are able to use a transition mechanism which is not tied to the IP versions supported by your ISP own, the barrier for IPv6 deployment should be significantly reduced. Therefore the issue seems to boil down to whether the NAT traversal mechanism described in draft-huitema-v6ops-teredo-xx is sufficient to traverse the NATs, and whether the support for something like Teredo is expected to be sufficiently commonplace to depend on it. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
