Re:Why?

[JORDI PALET MARTINEZ <[e-mail]>]

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 <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: Mon, 14 Mar 2005 10:34:51 -0500
> Para: Tony Hain <[e-mail]>
> CC: "[e-mail]" <[e-mail]>
> 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
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.com
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf




_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf