The consensus of the room at the BEHAVE BoF (which included a number of prominent NAT vendors) was not only that the IETF could draft recommendations to make NATs a lesser evil, but further, that some important NAT vendors would be likely to follow these recommendations. Regardless of how tactical this work may be, given longer-term solutions to the addressing problem, I think there is value in executing on it, and a significant community of interest behind it. I must agree with Harald that the number of IPv4 NATs sold is likely to increase for at least a few more years now, especially in residential Ethernet hubs/WiFi base stations, most of which have regular firmware upgrades, etc. I certainly don't think it is impossible for us to influence the design of these devices. If consumers at least have the option of buying such devices that are more favorable to their applications, then I think we will have made a significant difference here. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Brian E Carpenter [mailto:brc@xxxxxxxxxxxxxx] > Sent: Monday, September 20, 2004 5:04 AM > To: Pekka Savola > Cc: iesg@xxxxxxxx; ietf@xxxxxxxx > Subject: 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 ietf@xxxxxxxx as > > ietf-behave@xxxxxxxxxxxxxxxxxxx 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 (iesg@xxxxxxxx) 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf