Subject: Re: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT))

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Apr 2006 19:39:08 +0200

Hi, let me bring back this issue about UDP port number with NAT, in
DS-MIPv6 draft-ietf-mip6-nemo-v4traversal-01.txt

The draft can't be implemented, because the Gateway/HA doesn't know what
to put in the dst port number of UDP packets sent back to MN, through NAT.

Previously it was said that the Gateway would need to respond back to
the NAT with the right dst port number, but that would not be a problem
because UDP would copy the incoming src port number and put it into the
dst port number towards NAT.

Basically it's not enough to just say that "UDP responses go back to the
originating port" for several reasons.  For (1) strictly speaking,
there's no such thing as "UDP response".  The UDP header only has src,
dst ports and checksum, there is no id there to be able to match
responses.  Only a protocol carried by UDP, such as DHCP or MIP has
"responses", identified by "transaction id" or "identification" 
respectively, present in the UDP payload.  In DS-MIPv6 we try to carry 
IPv6 in UDP and IPv6 itself doesn't have a "IPv6 response" either, still 
because no special identifier in the IPv6 packet.

Henrik Levkowetz wrote:
> [...] regarding the Port number, Alex, but this is no different from 
> any other UDP responses, which go back to the originating port.

To re-iterate, it's not "UDP responses" that go back to originating port
but "[protocols carried by UDP] responses".  Our carried protocol here
is IPv6, and there's no "IPv6 response".

(2) The UDP encapsulating interfaces (I'm aware of) don't usually
respond to UDP packets.  What they do is encapsulate (or de-capsulate)
and forward to another interface, according to the routing
table.  The UDP code (not interface) just forwards the datagram to the
proper socket number, based only on port number.

To exemplify the problem: DS-MIPv6 section 4.1 "NAT detection and
traversal" suggests that the BAck is sent to MN in response of a BU.  It
is the mip6 code (modified to do DS-MIPv6) that will send the BAck, and
put it on the UDP interface.  It is not the UDP code in the kernel that
replies to this message, it's the mip6 code.

(3) Even if the kernel UDP code sent a reply back, it does not have 
means to store the src port of an incoming BU encapsulated in UDP and 
eventually put same dst port in the UDP packet encapsulating the reply. 
  While TCP does save data with respect to incoming packets and send 
back data accordingly, simple UDP doesn't.

And this is not all.  If we simply add text in the document
saying that the dst port number of UDP packets sent to NAT MUST be the
same as the src port number in the UDP packet received from NAT - it's
not enough, because the spec should provide the implementer a means to
relate the two packets.  What could this identifier be?  And such
that it can't be spoofed?  (the IPv4 src address can't be used because
there's only one NAT for many mobiles behind it, the UDP src port is
changed by NAT for same ongoing flow).

How should we deal with the port numbers in UDP packets carrying IPv6
when NAT?

Alex

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6