Subject: Re: [tsvwg] q about draft-stewart-natsupp-tsvwg-00

From: Michael Tüxen <[email-masked]>
Date: Mon, 1 Feb 2010 09:36:30 +0100

On Jan 31, 2010, at 10:28 PM, Yoshifumi Nishida wrote:

> 
> Hello, 
> Recently, I've read draft-stewart-natsupp-tsvwg-00.
> I guess the approach will eventually be related to other multi home support transport 
> protocols. So, I personally prefer to use general methods if possible.
> 
> My naive question is why we have to make NAT boxes send SCTP packets.
> Can't we use ICMP Error Packet Translation in RFC5508 for this?
Why not make them send SCTP packets? You need to change them anyway...
In principle, as long as all information needed is available, we could
use ICMP messages. But as I said: What is the difference?
> 
> Also, the draft seems to presume SCTP end nodes can know whether they are behind NAT
> or not. But, how do they know it? ICMP Query Mapping?
This is left open. A node having a private address talking to
a node with a global address knows that it needs to use the mechanism.
You could also use it always, as long as you peer supports it.
> Thanks,
> --
> Yoshifumi Nishida
> [email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 01 Feb 2010 19:47:51 +0900 (JST)

Hello Michael, 
Thanks for the response.

From: Michael Tüxen <[email-masked]>
Subject: Re: [tsvwg] q about draft-stewart-natsupp-tsvwg-00
Date: Mon, 1 Feb 2010 09:36:30 +0100
Message-ID: <[email-masked]>

 > use ICMP messages. But as I said: What is the difference?

I think sending SCTP packet from NAT boxes will require NAT boxes to perform 
source spoofing, which will be a bit tricky. 
Also, although it's not very sure, other trasnport protocols which support multihome 
will be standardilized in future. Using general method will make NAT's implementation
simple rather than using protocol depndent method. 

 > You could also use it always, as long as you peer supports it.

I personally would like to avoid to make transport layer interprete IP addresses,
but, yes, that's a possible way. Thanks for the clarification.

--
Yoshifumi Nishida
[email-masked]