RE: SCTP-over-UDP and port 9899

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]]
> Sent: Wednesday, December 07, 2011 1:25 PM
> To: Dan Wing
> Cc: 'Randy Stewart'; 'Chris Benson'; [e-mail]
> Subject: Re: SCTP-over-UDP and port 9899
> 
> 
> On Dec 7, 2011, at 10:10 PM, Dan Wing wrote:
> 
> >> -----Original Message-----
> >> From: Michael Tuexen [mailto:[e-mail]]
> >> Sent: Wednesday, December 07, 2011 12:48 PM
> >> To: Dan Wing
> >> Cc: 'Randy Stewart'; 'Chris Benson'; [e-mail]
> >> Subject: Re: SCTP-over-UDP and port 9899
> >>
> >> On Dec 7, 2011, at 9:35 PM, Dan Wing wrote:
> >>
> >>>> Fine great, I'm happy with the text.
> >>>
> >>> Great.
> >> Is it acceptable for you that the SCTP stack uses only
> >> a single UDP port or do you want a single port per
> >> protocol family or even more ports?
> >
> > I assume you're asking because you're thinking of SCTP
> > running on those several interfaces.  With that in mind,
> Well, I'm thinking about SCTP/UDP/IPv4 and SCTP/UDP/IPv6.
> Do you have any other stack in mind? I think the ID only
> talks about these two above stacks.
> > whatever port a SCTP-over-UDP is listening on is likely
> > to be rewritten by NAT (or other address sharing, e.g.,
> > dIVI, 4rd, etc.).  So, the SCTP-over-UDP clients cannot
> I don't care about any rewriting by NATs. This is already
> covered by the ID. I'm thinking about how many UDP sockets
> you expect an SCTP stack to use for en/decapsulation.
> One socket dealing with IPv4 and IPv6? Then one port is enough.

Yep, agreed.

> One for IPv4 and another one for IPv6? Then you have
> 2 bind calls which might make is hard to bind the same
> port number.
> Currently on Mac OS X I bind both sockets (kernel sockets)
> to the same port.

Ok.

> If one binding fails I close the other one
> and report an error.

That seems problematic.  What do you expect the caller to
do when it receives that error?  Give up and go home, or 
call you again?

> > require that a single SCTP-over-UDP server have the
> > same UDP port from the perspective of the SCTP-over-UDP
> > client.  Instead, the server's UDP port needs to be
> > communicated to the SCTP-over-UDP client within SCTP
> > itself using either (a) SCTP's existing AddAddress mechanism
> > -- which would need to be extended to accomodate/know/learn
> > of the UDP rewriting that occurred on that pathor some, or
> > (b) other means such as DNS SRV records.
> Hmmm. I have the feeling that I'm missing something?

What you have in the I-D (with the text change Randall suggested)
will work fine when the SCTP-over-UDP server has a publicly-
routed IP address and lovely things like that.

If, in the future, we have SCTP-over-UDP servers that are
behind their own NAT, things get more complicated.  I am
thinking of this complication, and thinking of ways to solve
it.  It's something we don't necessarily need to write down
yet, and certainly don't need to fix yet.  

But, we may.  It depends on if IPv4 really go away.

> How can you
> put the UDP port number into the SCTP payload?

That's a separate(able) problem.  Answers can include UPnP 
IGD, PCP, STUN, and other spiffy protocols for NAT traversal.

> The port numbers
> might get rewritten by a NAT box and this wouldn't rewrite the
> SCTP payload. That is why the SCTP just uses as the destination
> port of outgoing packets what the source port of incoming packets was.

Yeah, somewhere around 99% of transport protocols do that, too.

-d


> Best regards
> Michael
> >
> > -d
> >
> >
> >> Best regards
> >> Michael
> >>>
> >>>> But it is clear to you that
> >>>>
> >>>> the source port of outgoing packets is the same as the destination
> >>>> port of incoming packets.
> >>>>
> >>>> Or do you think that this is not true?
> >>>
> >>> -d
> >>>
> >>>
> >>>
> >
> >