Subject: RE: draft-huitema-v6ops-unmaneval-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Sat, 15 Mar 2003 11:42:03 -0800

Itojun,
 
When it comes to traversing NAT, the issue is how to "come in", not how to "go out". AFAIK, teredo is the only solution that allows "self deploy" because it let UDP packets "come in". All the other solutions are variations on fixed tunnels, and thus require some form of contract between a user and a tunnel endpoint. You can clearly do PPP over TCP, but you can only do that if you initiate the connection from inside the NAT towards a fixed tunnel end-point; in that case, I believe that a UDP base tunnel will provide a lesser overhead, and will avoid the "head of line blocking" issues found in TCP. RFC 2893 tunneling only works with some NAT, and as such cannot be a generic solution.
 
-- Christian Huitema

________________________________

From: Jun-ichiro itojun Hagino [mailto:[email-masked]]
Sent: Sat 3/15/2003 9:13 AM
To: [email-masked]
Subject: draft-huitema-v6ops-unmaneval-00.txt

>2.1    Evaluation of connectivity mechanisms
>  
>   In case A, IPv6 capable hosts seek IPv6 connectivity in order to
>   participate with applications in the global IPv6 Internet. The
>   connectivity requirement can be met in two ways: Teredo [TEREDO], or
>   UDP tunnels.

        there are many other ways to solve case A, including:
        - IPv6 PPP over TCP (can penetrate any NAT as it is TCP)
        - RFC2893 tunnelling with certain NAT/decapsulator configuration
        if you wish to limit solutions to teredo and UDP tunnels, you would
        need to describe why.

>6       Provisional recommendations
>   -    To meet case A requirements, we need to develop and standardize
>        the Teredo or similar technology.

        therefore, it is too early to conclude like this.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Sun, 16 Mar 2003 15:07:41 +0200 (EET)

On Sat, 15 Mar 2003, Christian Huitema wrote:
> When it comes to traversing NAT, the issue is how to "come in", not how
> to "go out". AFAIK, teredo is the only solution that allows "self
> deploy" because it let UDP packets "come in". All the other solutions
> are variations on fixed tunnels, and thus require some form of contract
> between a user and a tunnel endpoint. 

By "coming in" you probably refer to "coming in without an explicit 
tunnel".

Not being to just "come in" could be considered a feature, too.

Especially if "coming in" doesn't work on any properly implemented
(=secure) NAT boxes.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2003 19:15:53 +0100 (CET)

> When it comes to traversing NAT, the issue is how to "come in", not how to
> "go out". AFAIK, teredo is the only solution that allows "self deploy"
> because it let UDP packets "come in". All the other solutions are variations
> on fixed tunnels, and thus require some form of contract between a user and
> a tunnel endpoint. You can clearly do PPP over TCP, but you can only do that
> if you initiate the connection from inside the NAT towards a fixed tunnel
> end-point; in that case, I believe that a UDP base tunnel will provide a
> lesser overhead, and will avoid the "head of line blocking" issues found in
> TCP. RFC 2893 tunneling only works with some NAT, and as such cannot be a
> generic solution.

While I disagree with your conclusion, the point of this email is merely
that the document doesn't seem to be consistent with what your conclusion.

Above you say that there is only one (type of) solution which solves
the problem. Yet the draft says that there are two: Teredo [TEREDO], or
UDP tunnels.
Did you intend that the draft say "Teredo which uses UDP tunnels" or
something like that?

   Erik