Subject: RE: [Tsvwg] SCTP and NAT

From: [email-masked]
Date: Tue, 16 Apr 2002 16:10:40 +0300

Hi all!

	I'm not a real expert about NATs and I would like people to comment about this mail, but... what about the Hostname Address Parameter?

	It is true that in this case you need a DNS aware of the existence of the NAT (I think they are called Application Level Gateway in RFC 2663, I haven't read that new RFC Michael pointed out), but they do exist (otherwise, how would you set up a server inside a stub domain?)... The receiver of such parameter would do the DNS query and should get the globally unique addresses of the peer... The NATs in its normal behavior will do the rest...

	This was the reason behind the use of the Hostname Address Parameter, right? Or am I missing something?

	Thanks! Any comment is very welcome!

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Randall Stewart [mailto:[email-masked]]
> Sent: 16. April 2002 15:58
> To: Poetzl, Joachim
> Cc: [email-masked]
> Subject: Re: [Tsvwg] SCTP and NAT
> 
> 
> A small comment or two..
> 
> "Poetzl, Joachim" wrote:
> 
> > Does SCTP work with NAT?
> 
> I think Michael as pointed out a "new" RFC that discusses this in
> some detail. But I will add a few rambling thoughts on the matter....
> 
> NAT's WILL work with SCTP if you are talking singly homed and the
> SCTP implementation as enough address selection sense to NOT include
> any addresses in the address list. I believe our implementation on
> BSD will do this (available at http://www.sctp.org and soon it
> will be released as part of kame). The basic idea is that the 
> SCTP implementation behind the NAT must realize it has a private
> address and then only send either the INIT or INIT-ACK back to
> the "global" address without listing any of its addresses.
> 
> If the SCTP implementation is multi-homed and would like to 
> be able to take advantage of that ... say something like:
> 
>            (Private Address)-----NAT-1-----IP-X(Global address)
>     IP-P1-----+
> SCTP
>     IP-P2-----+
>            (Private Address)-----NAT-2-----IP-Y(Global address)
> 
> The SCTP implementation would require assistance from the two
> NAT's in order to make this work..
> 
> You would need the NAT's to:
> 
> 1) Do stateful inspection of the address lists and substitute
>     IP-P1/IP-P2 for IP-X and IP-X (in the INIT/INIT-ACK messages). 
> 2) Communicate with the peer NAT through some mechanism to
>    allocate a COMMON port number and setup the mapping.
> 3) Coordinate the tear down of this state when the association
>    ends.. note that EITHER side could get the tear down indication.
> 
> I don't believe there is ANY way this can be done today without
> further work on NAT's which I DO NOT advocate. A far better way
> to get multi-homing is to move to IPv6 and then both sides can
> have nice global addresses :>
> 
> R
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Tue, 16 Apr 2002 08:26:35 -0500

Ivan:

Yes, I do agree. The host-name-address parameter was designed for JUST
such a thing. You do need DNS aware NAT's. But more importantly you
need an SCTP implementation that understands and sends this
parameter. For a USER land implementation this is not to hard of
issue ... since you are in a library someplace, in user space, and
making a hostname lookup call is NOT an issue.

But when you think in terms of a KERNEL implementation the issue
becomes MUCH MUCH harder. You must from within the kernel make
an UP call to a user application (aka DNS). Then suspend the process
doing the INIT (if we are in a blocking mode) and wait for the response
from user land to the kernel. This gets really ugly really fast.. it
can be done.. don't get me wrong... but it is a difficult thing to do.

One other little item ... if you really want to have multi-homing you
still need some NAT-NAT coordination protocol to allocate a shared
PORT amongst the two NAT's that you are multi-homed with. Without this
feature in a NAT I just don't see the value in writting all this kernel
code.. since if you just send a INIT/INIT-ACK off without listing
addresses you can setup the association singly-homed... 

Thus the only thing that I can think the DNS work (upcall in kernel..
uggh)
will do for you is help you when you need to be multi-homed with a NAT
and the NAT-NAT allocation issue is still left open.. so I just don't
see how this feature does anything to help you...IMHO...

But of course I never was very excited about the host-name-address
parameter 
:-0

R