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

["Ahmad Muhanna" <amuhanna at nortel.com>]

Since this has been out there with no reported issues and problems for a
long time, I believe if we need to make any changes, we need to allow
the current wording for backward compatibility.

Regards,
Ahmad
 

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik at levkowetz.com] 
> Sent: Wednesday, November 22, 2006 3:09 AM
> To: Sami Vaarala
> Cc: Charles E. Perkins; Mobile IPv4 Mailing List
> Subject: Re: [Mip4] New revision for rfc3344bis; UDP 
> inconsistency and candidate solution
> 
> 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.
> 
> 
> 	Henrik
> 
> 

--
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/