RE: I-D Action: draft-rosenberg-internet-wait-hourglass-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

> -----Original Message-----
> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On 
> Behalf Of Bernard Aboba
> Sent: Friday, February 15, 2008 6:21 AM
> To: ietf@xxxxxxxx
> Subject: Re: I-D Action: 
> draft-rosenberg-internet-wait-hourglass-00.txt
> 
> Lars Eggert said:
> 
> "A big driver for SCTP was for use a signaling protocol. 
> Other SDOs are  
> using SCTP for signaling in their network architectures, and 
> are also  
> now introducing NAT functionality at controlled places in these  
> architectures. This is why I believe and have argued that an 
> IETF BCP  
> that documents how to correctly NAT SCTP is the right thing to  
> produce. (And, FWIW, DCCP. There's some interest in that as 
> well, but  
> not such an immediate one as for SCTP.) As a SIP-area person, this  
> mode of operation should be familiar to you.
> 
> Will this BCP make SCTP available behind a home NAT? Nope. But it  
> provides a specification that people can refer to who design network  
> architectures that are more tightly controlled than the end user  
> Internet, i.e., where people can define and then require 
> their NATs to  
> have this functionality."
> 
> I agree with Lars here -- having a specification is the first step.

There is a milestone in BEHAVE for a SCTP NAT, along the lines of
BEHAVE's milestones (some completed) for TCP, UDP, and ICMP.  We also
have a milestone for a DCCP NAT.

> However, I would suspect that clearly specifying how SCTP and DCCP 
> work with NAT would eventually make it possible to obtain a home NAT 
> supporting those protocols, particularly if implementations were made 
> available within the popular distributions (e.g. DD-WRT) on 
> which those home NATs are frequently based. 

I am not aware of the status of SCTP NAT code, but I did learn
this week that there is a Linux implementation of DCCP NAT.

> On another note, I think it makes a difference whether 
> UDP/TCP is combined 
> with IP at the waist, or whether UDP/TCP is considered a 
> lower layer on 
> which IP, etc. can run.  That is, whether we have general NAT 
> traversal 
> mechanisms which support a wide array of applications, or 
> whether we end 
> up having to modify each individual protocol.  The draft 
> seems to suggest 
> the latter approach.  I disagree. 

A simple UDP tunneling protocol sounds useful, too.

There are currently two drafts for running SCTP and DCCP over
UDP.  I look forward to discussing the benefits of a 
per-protocol UDP tunneling approach versus a generic, simple 
UDP tunnel approach.

-d

_______________________________________________

Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]