Regarding the firewalls and IPv6, I agree with your comment, but also there are some other reasons why that's bad, see: draft-vives-v6ops-ipv6-security-ps-03.txt and draft-palet-v6ops-ipv6security-02.txt Regards, Jordi > De: Jonathan Rosenberg <jdrosen@xxxxxxxxx> > Responder a: <ietf-bounces@xxxxxxxx> > Fecha: Mon, 14 Mar 2005 10:34:51 -0500 > Para: Tony Hain <alh-ietf@xxxxxxxx> > CC: "ietf@xxxxxxxx" <ietf@xxxxxxxx> > Asunto: Re: FW: Why? > > inline. > > Tony Hain wrote: > >> Joel M. Halpern wrote: >> >>> This discussion seems to take as a premise the view that if we define >>> applications only on IPv6, even though they could be defined on IPv4, that >>> this will give people a reason to use IPv6. >>> It also seems to take as a premise that if we don't define ways to work >>> around NATs, people won't use the applications with NATs. >> >> >> I suffer from no such disillusions as those are not the premise for the >> initial note, though without having the background in the original note it >> is easy to see why someone might come to that conclusion. >> >> My assumption is that the market will not ignore the opportunity to develop >> NAT traversal technologies. That does not equate to a need for the IETF to >> waste valuable resources standardizing hacks that attempt to mask previous >> hacks. In particular the IAB needs to be looking forward and helping the >> application community understand that there are approaches today that allow >> them to ignore the nonsense that has grown in the network by using IPv6 >> tunneling as a NAT traversal tool. This approach completely avoids the need >> for complex and error prone ALGs. > > I agree that ALGs are not the answer, and I believe the reasons for that > are treated in: > > http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-considerations-00. > txt > > As I mentioned during the plenary, the document above makes a case that > the right answer in many situations are vpn-ish technologies that > include v6 tunnels. However, different applications have different > needs, and there are real differences between the various vpn-ish > solutions (TURN, STUN, teredo, etc.) that are driving their development > and adoption. For VoIP, where the nat traversal issue has been > especially painful, the increase in voice latency, packet loss, and > substantial cost increase of relaying traffic through the tunnel > servers, has driven people to solutions like STUN. Thus, I cannot agree > that there only needs to be a single solution here. > > That said, I agree that the IAB nat traversal consideration document > lacks adequate consideration of how evolution plays into this, and I'll > endeavor to improve the document on that front. > > Another concern I have is that, in an IPv6-only world, even if you > eliminate NAT, there will still be firewalls, and those firewalls will > frequently have the property that they block traffic coming from the > outside to a particular IP/port on the inside unless an outbound packet > has been generated from the inside from that IP/port. This means that IP > addresses are not globally reachable. You'd still need most of the same > solutions we have on the table today to deal with this problem. Indeed, > in the VoIP space, I believe you'd need pretty much everything, > excepting you'd be able to remove a single attribute from a few of the > protocols (STUN and TURN in particular), which tell the endpoint its > address on the other side of the NAT. The endpoint knows its address, > but all of the protocol machinery is still needed to rendezvous with the > other participant in the call. > > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@xxxxxxxxx FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf