Subject: Re: (ngtrans) FAITH translator

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Jul 1999 14:42:35 -0700

Itojun,

Was is the difference in capabilities between the FAITH TCP relay
and NAT-PT?
They seem rather similar (special stuff needed for FTP etc) except
that NAT-PT can do UDP and ping in addition to TCP.

   Erik

---

From: [email-masked]
Date: Thu, 15 Jul 1999 06:53:57 +0900

>that NAT-PT can do UDP and ping in addition to TCP.

	I would say that they are similar in part, but has different
	characteristics.

	NAT-PT is a IPv4/v6 header translator, which needs great care on
	path MTU considerations and fragment considerations.  It can
	support not only TCP but others.

	FAITH is a TCP relay translator.  This terminates TCP connection
	at translator box and has no issues on path MTU or fragmented packet.
	However, it supports only TCP.  Implementation is simpler IMHO.
	Another benefit of TCP termination is that we never forward needless
	TCP options across IPv4 TCP and IPv6 TCP.  This characteristics
	has been very important in firewall community (NAT has benefit in
	security as attacker can inject arbitrary TCP options and other
	tricks), and I think it still holds for translator case.

	See draft-ietf-ngtrans-translator-01.txt for more discussions
	on differences due to the diffrences translation layers.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jul 1999 01:20:32 -0500

>         FAITH is a TCP relay translator.

i.e. NAT-PT is potentially of general use and FAITH isn't.

  Brian

---

From: [email-masked]
Date: Thu, 15 Jul 1999 15:26:54 +0900

>i.e. NAT-PT is potentially of general use and FAITH isn't.

	If you cover TCP you can cover most of the traffic.  See firewall
	products available on the market.

itojun

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 15 Jul 1999 15:38:58 +0900

> i.e. NAT-PT is potentially of general use and FAITH isn't.

So, what? 

Take look at IPv4 firewalls. There are some categories including
header converter (i.e. NAT), TCP relays (e.g. SOCKS), and ALGs.

Some guys like NAT, other guys like TCP relays.

P.S.

I don't know that both BIS and FAITH are worth standardizing.

--Kazu

---

From: [email-masked]
Date: Thu, 15 Jul 1999 15:46:19 +0900

>I don't know that both BIS and FAITH are worth standardizing.

	I agree that they are not standard-track kind of thing.

	Isn't it good to share experiences with broader public, than let it
	sit only in source code? (which is not made public in some cases)
	Making them an informational RFC is the way to go, I believe.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jul 1999 01:50:56 -0500

>         products available on the market.
But we want IPv6 to be more attractive than current possibilities.

  Brian

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 15 Jul 1999 15:53:02 +0900

From: [email-masked]
Subject: Re: (ngtrans) FAITH translator 
Date: Thu, 15 Jul 1999 15:46:19 +0900

> 	Making them an informational RFC is the way to go, I believe.

I guess other media like KAME's newsletter are enough. However, please
do what you think is right.

--Kazu

---

From: [email-masked]
Date: Thu, 15 Jul 1999 15:58:32 +0900

>But we want IPv6 to be more attractive than current possibilities.

	Me too.

	Translators are for communicating those *legacy* IPv4-only nodes.
	If you are communicating with IPv6 peers, you don't use translators,
	you have NO problem.  What is your problem in this story?

itojun

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 15 Jul 1999 15:58:28 +0900

From: Brian E Carpenter <[email-masked]>
Subject: Re: (ngtrans) FAITH translator
Date: Thu, 15 Jul 1999 01:50:56 -0500

> But we want IPv6 to be more attractive than current possibilities.

IPv6 itself is more attractive than IPv4. 

However, we are discussing translators between IPv4 and IPv6. It is
unavoidable that translators acts as NAT/firewall. So, itojun rose
firewall examples.

--Kazu

---

From: [email-masked]
Date: Thu, 15 Jul 1999 16:02:22 +0900

>do what you think is right.

	I think you are tired of politics around here :-)

	I submitted the draft to the list, and then I'll see if people likes
	it to be published or not.  In either case, I'll put them somewhere
	on our webpage.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jul 1999 07:18:00 -0500

Well, I prefer a solution that translates TCP+UDP to
a solution that translates only UDP. So I don't see
the added value of FAITH.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 15 Jul 1999 22:22:01 +0900

From: Brian E Carpenter <[email-masked]>
Subject: Re: (ngtrans) FAITH translator
Date: Thu, 15 Jul 1999 07:18:00 -0500

> the added value of FAITH.

UDP translation in IP level is ad-hoc anyway. Such ad-hoc translation
can be implement in transport level (i.e. UDP relay).

You should understand that UDP doesn't tell its session termination in
any level.

We implemented TCP relay, not because we can relay TCP only in
transport level, but because the implementation of TCP relay is easy
and enough in the real world.

--Kazu

---

From: "Perry E. Metzger" <[email-masked]>
Date: 15 Jul 1999 11:16:17 -0400

> the added value of FAITH.

These are all just transitional methods anyway. I think it is fine if
there are several and we experiment with them. They aren't going to be 
"standardized" with a capital "S" anyway.

Perry

---

From: Jim Bound <[email-masked]>
Date: Thu, 15 Jul 1999 20:17:06 -0400

>	Making them an informational RFC is the way to go, I believe.

Something I have learned recently with much thought as I try to be a
kinder and gentler Jim.  As engineers when we suggest something as a
solution we do it purely as thats what we do by nature.  But when in the
IETF we have two modes.  First - we do the above.  Second - we are
proposing an idea as a standards track solution, and that may mean an
alternative solution or replacement solution to another idea.  I think
in sending email on mechs and tools for transition it would help and
affect response how one is presenting an idea and solution.  If its not
mean't for a standards track solution saying that will give the
impression for the response.  I think it also reduces friction of normal
competition. 

/jim