Re: SCTP-over-UDP and port 9899

[Michael Tuexen <[e-mail]>]

On Nov 2, 2011, at 3:27 AM, Dan Wing wrote:

>>> For the server, yes, that's okay.  That is what IANA-registered
>>> default ports are all about.
>> But the SCTP stack is neither a client nor a server...
> 
> "Bullpucky".  Next you're going to say that "peer to peer" 
> doesn't have a client and a server.
No, I mean it seriously: The local UDP encapsulation port number
is a variable of the stack (for example in the FreeBSD kernel
configurable via a sysctl variable). If you want to use one
number if the application will ever call listen() and a different
one it it calls never listen(), how should the stack decide that?
Same for a userland stack...
> 
>>>> That is why I used a MAY. But I'm open to use any other formulation.
>>>> Do you have a suggestion?
>>> 
>>> Yes -- be silent about the source port.  Say nothing in the
>>> document about the source port.
>> I just talk about the local UDP encapsulation port...
>> However, it is the destination port of incoming packets and
>> the source port of outgoing packets (as every local port
>> number is).
>> 
>> Would it be acceptable for you if I replace
>> 
>> Each SCTP stack uses a single local UDP encapsulation port number
>> as the source port for all of its outgoing SCTP packets
>> and as the destination port for all its incoming SCTP packets.
>> 
>> by
>> 
>> Each SCTP stack uses a single local UDP encapsulation port number.
>> 
>> However, later on I'm saying that the local UDP port is used
>> as the source port for outgoing packets. I think I have to say
>> that, since I need to say what the source and destination port
>> of the inserted UDP are.
> 
> Do you understand why I am concerned with specifying the 
> source UDP port number?  It gets re-written by NATs, and
> the primary reason for this draft is to allow SCTP to work
> when behind a NAT.
I'm not sure why you are concerned.
The ID says: Use 9899 when possible as the local encapsulation
port (I'm using MAY). For outgoing packets this local encapsulation
port number is use as the source port by the sending host.
Of course, it can be rewritten on the path to the receiver and
that is fine. The peer will store the possibly changed source
port as its remote encapsulation port number. This is (at least
I think) described in the ID. This is the processing which
you want to be supported, I think, and of course it is.

Just to be clear: If the sender puts some number in the source
port field, it can not be assumed that the same value is there
when the packet is received. I know that and that is handled.

Put it in other words:
* Each SCTP stack chooses a local encapsulation port. Right?
* Why not choose, when possible, the 9899. Possible or not?
I don't see that anything breaks.

Best regards
Michael
> 
> -d
> 
> 
>> Best regards
>> Michael
>>> 
>>> -d
>>> 
>>> 
>>>> 
>>>> Best regards
>>>> Michael
>>>>> 
>>>>> -d
>>>>> 
>>>>>> Best regards
>>>>>> Michael
>>>>>>> 
>>>>>>> -d
>>>>>>> 
>>>>>>> 
>>>>>>>> Best regards
>>>>>>>> Michael
>>>>>>>>> 
>>>>>>>>> -d
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Best regards
>>>>>>>>>> Michael
>>>>>>>>>>> 
>>>>>>>>>>> -d
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
> 
>