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

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Nov 2006 16:22:16 -0800

Hello folks,

I have a revision of rfc3344bis all ready to go.  I am
thinking about making one further small modification,
according to the following discussion.

Some time ago, I received an e-mail about some
inconsistency in the language used by rfc3344bis
when describing the handling of the Source Port field
of Registration Reply messages by the home agent.

The confusion arises because of the following conflicting
elements of the specification:
- The UDP destination port of the Registration Request
   is set to 434
- The home agent is mandated to copy the value of the
   destination port of the Registration Request message
   into the UDP source port field of the Registration Reply
- That source port field is described as "variable".

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.

It could well be that there are implementations of
foreign agents and mobile nodes that check to make
sure that the value is correct according to the above
specified procedure, so I am reluctant to change the
actual behavior of the home agent.

I propose the following text changes:

(A) In section "3.4. Registration Reply", change

 >    UDP fields:
 >        Source Port           <variable>

to be:

    UDP fields:

        Source Port           434

This conforms also with language used in
section 3.7.2.3.

(B). In section "3.8.3.1. IP/UDP Fields", change:

 >       UDP Source Port
 >                Copied from the UDP Destination Port of the Registration
 >                Request.

to be:

          UDP Source Port
                 Set to the value 434

=============================================

I expect to send out the new revision of rfc3344bis with
these changes in the next day or two.  This revision is
otherwise the same as should have already have been
posted to the Internet Draft before the recent IETF
meeting.

Regards,
Charlie P.

PS. Thanks to Hrishikesh Kulkarni for pointing out the
        discrepancy on this matter.

-- 
Please address return e-mail to [email-masked]

-- 
Mip4 mailing list: [email-masked]
    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/

---

From: Sami Vaarala <[email-masked]>
Date: Wed, 22 Nov 2006 10:27:36 +0200

Charles E. Perkins wrote:
 > [...]

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.

This is, of course, not necessarily something that has to be dealt
with in 3344bis, but a NAT/PF supporting implementation will have
to deal with.

BR,

-Sami

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 22 Nov 2006 10:08:45 +0100

Hi,

> device, the MN may be sending to port 434 but HA receiving at some

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Nov 2006 14:22:53 +0100

Sami Vaarala 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 

Intermediary NAT/FWDs (between MN and HA) can indeed change port
numbers, but it would make little sense to change the dst port number
of a packet from MN and HA; probably they better change the src port
number of that packet.  It may happen they do though.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Nov 2006 14:22:41 +0100

Henrik Levkowetz 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 
>> 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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 22 Nov 2006 08:42:57 -0600

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:[email-masked]] 
> 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,
> 
> >> 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 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
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Nov 2006 21:28:29 -0800

Hello Ahmad and Sami,

As far as I know, the proposed wording change is
backward compatible.

Regarding port forwarding NATs, I hope there are none
that change the destination port!  The home agent can't
be listening to all the possible destination ports and
treating all incoming messages to all ports as Mobile IP
messages.

I can see that a NAT box might change the source port
number, and the wording changes I proposed would not
affect that.

Isn't this right?

Regards,
Charlie P.

---

From: Sami Vaarala <[email-masked]>
Date: Thu, 23 Nov 2006 11:41:42 +0200

> number, and the wording changes I proposed would not

There are HAs that can listen on other port(s) beside 434.
Operation on these other ports is not directly covered by
the specification as such, but it would be preferable that
the wording "just work" in that case, too.

In particular, it would be bad if an implementor decided
to support running a HA on a non-standard port, receiving
requests on some port X, but still sending responses using
port 443 as source port.  Even though that might work in
some cases, it would likely fail with NAT devices and other
stateful routers; thus it is important for the HA to copy
ports exactly from the RRQ (just swapping them).

That being said, if we want to *preclude* using other ports
in the base specification, then this change is a no-op.

Best,

-Sami

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 23 Nov 2006 11:02:21 +0100

Hi Charlie

> number, and the wording changes I proposed would not

As far as I'm concerned, this is actually immaterial.  There may
or may not be port forwarding NAT cases where the destination
port is changed.  If there are, it has to be set up so on purpose,
however; it won't happen randomly.

What I can see matters is for instance that I have come across cases
where people have for complex reasons wanted to deploy some HAs
listening to other ports than 434.  Changing the specification now to
read 'send on 434' instead of 'copy from destination port' would break
that.

Removing the statement that the port is 'variable' is, I believe,
a good thing.  It removes a blemish.

Changing from 'copy from destination port' to 434 is gratuitous
breakage; it doesn't help consistency, but it does have the potential
for harm.

	Henrik

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 23 Nov 2006 14:19:57 -0600

Hi Charlie,

Never mind, after reading this one more time, I do not see any problem
with the proposed changes.  I actually was thinking of the source UDP
port of the RRQ as sent by the FA. 

Regards,
Ahmad

> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, November 22, 2006 11:28 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Cc: Mobile IPv4 Mailing List
> As far as I know, the proposed wording change is backward compatible.
> 
> Regarding port forwarding NATs, I hope there are none that 
> change the destination port!  The home agent can't be 
> listening to all the possible destination ports and treating 
> all incoming messages to all ports as Mobile IP messages.
> 
> I can see that a NAT box might change the source port number, 
> and the wording changes I proposed would not affect that.
> 
> Isn't this right?
> 
> Regards,
> Charlie P.
> 
> 
> ext Ahmad Muhanna wrote:
> > 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
> >  
> >
> >   
> >> Subject: Re: [Mip4] New revision for rfc3344bis; UDP inconsistency 
> >> and candidate solution
> >>
> >> Hi,
> >>
> port into the

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 26 Nov 2006 17:41:06 -0800

> of the field cannot be described as "variable" as things

I agree with Sami and Henrik. just copy the
destination port on the registration request
instead of saying port 434 explicitly.

    UDP fields:

        Source Port           Copied from the UDP destination port
                              of the corresponding Registration
                              Request.

>  >                Copied from the UDP Destination Port of the Registration

and leave this as is.

Vijay