Re: [Mip4] New revision for rfc3344bis; UDP inconsistency and candidate solution

[Alexandru Petrescu <alexandru.petrescu at motorola.com>]

Henrik Levkowetz wrote:
> Hi,
>
> on 2006-11-22 09:27 Sami Vaarala said the following:
> > Charles E. Perkins wrote:
> > > Hello folks, [...] As pointed out, copying the value of the 
> > > destination port into the source port should be identically the
> > >  same as setting the source port value to 434.  So, the value
> > > of the field cannot be described as "variable" as things now 
> > > stand.
> > Hi,
> >
> > I haven't been following this discussion closely, but there may 
> > be cases with NATs and port forwarding where this assumption is 
> > incorrect.  For instance, if the HA is behind a port forwarding 
> > device, the MN may be sending to port 434 but HA receiving at 
> > some other port.
>
> I agree with Sami.  Removing the 'variable' characterisation is 
> fine, but I'd still prefer to retain the current language which 
> specifies copying the incoming destination port value into the 
> outgoing source port value.

Somehow yes.

Isn't it that the 'variable' word is there to mention that the src
port number of RegRep can be anything (not necessarily 434)?  Tcp
server implementations often run that way: listen on a well-known port
number for establishing connections but use the next available (above
10000) port number for src of packet sent by server.

I don't have strong feelings about that, and implementations with
fixed 434 port number on both ways can work ok too.

Alex


--
Mip4 mailing list: Mip4 at ietf.org
   Web interface: https://www1.ietf.org/mailman/listinfo/mip4
    Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/