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: "Soliman, Hesham" <[email-masked]>
Date: Thu, 27 Apr 2006 11:24:32 -0700

Alex, 

I don't understand the problem you seem to see with this. The packet is 
received with the src and dst ports in it, the receiving implementation
would simply send outgoing packets to the src port in the received
packet. What is the problem? In this context you can thing of IPv6
as an application running over UDP. 

Hesham 

 > -----Original Message-----
 > From: Alexandru Petrescu [mailto:[email-masked]] 
 > Sent: Thursday, April 27, 2006 1:39 PM
 > To: Henrik Levkowetz
 > Cc: Zhang, Qiang [NTK]; [email-masked]; Soliman, Hesham
 > 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))
 > 
 > 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Apr 2006 20:42:56 +0200

Soliman, Hesham wrote:
> Alex,
> 
> I don't understand the problem you seem to see with this. The packet
> is received with the src and dst ports in it, the receiving
> implementation would simply send outgoing packets to the src port in
> the received packet. What is the problem?

Hesham, the question is about implementing it.  At UDP level there's no 
information available to "send outgoing packets to the src port in
the received packet" simply because UDP doesn't know what packet needs a 
response.  MIP6 does, and in in the case of BU/BAck only.  IPv6 doesn't. 
   TCPv6 doess.  App carried in UDPv6 doess too.  But these apps don't 
know about the below UDP naturally.

E.g. an IPv6 app on GW needing to write to MN behind NAT has no idea 
about which UDP dst port number to use, and can't find it on GW.  Do you 
agree?

The negative consequence is the following:  MN behind NAT sends BU in 
UDP to GW, mip6 on GW gets it, GW _may_ know how to reply the BAck UDP 
back to MN - and thus the "UDP tunnel" is open.  But after this, if an 
UDPv6 app wants to write to MN it should write to some UDPv4 dst port 
number - which one?  If it uses the port number previously used by BAck 
it's not necessarily the good one, because NAT may have removed it.  Do 
you agree?

Alex

> In this context you can thing of IPv6 as an application running over
> UDP.

Assume
> 
> Hesham
> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Thursday, April 27,
>> 2006 1:39 PM To: Henrik Levkowetz Cc: Zhang, Qiang [NTK];
>> [email-masked]; Soliman, Hesham 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))
>> 
>> 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:
>> 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".
>> 
>> 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.
>> 
>> 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.
>> 
>>  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
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Apr 2006 23:10:52 +0200

Hesham, should I take the lack of reply as an acknowledgement that there
_is_ an issue about port numbers for NAT traversal?

Alex

Alexandru Petrescu wrote:
> Soliman, Hesham wrote:
>> Alex,
>> 
>> I don't understand the problem you seem to see with this. The 
>> packet is received with the src and dst ports in it, the receiving 
>> implementation would simply send outgoing packets to the src port 
>> in the received packet. What is the problem?
> 
> Hesham, the question is about implementing it.  At UDP level there's
>  no information available to "send outgoing packets to the src port
> in the received packet" simply because UDP doesn't know what packet 
> needs a response.  MIP6 does, and in in the case of BU/BAck only. 
> IPv6 doesn't. TCPv6 doess.  App carried in UDPv6 doess too.  But 
> these apps don't know about the below UDP naturally.
> 
>  about which UDP dst port number to use, and can't find it on GW.  Do
>  you agree?
> 
>  UDP to GW, mip6 on GW gets it, GW _may_ know how to reply the BAck 
> UDP back to MN - and thus the "UDP tunnel" is open.  But after this,
>  if an UDPv6 app wants to write to MN it should write to some UDPv4 
> dst port number - which one?  If it uses the port number previously 
> used by BAck it's not necessarily the good one, because NAT may have
>  removed it.  Do you agree?
> 
> Alex
> 
> 
> 
>> In this context you can thing of IPv6 as an application running 
>> over UDP.
> 
> Assume
>> 
>> Hesham
>> 
>>> [mailto:[email-masked]] Sent: Thursday, April 
>>> 27, 2006 1:39 PM To: Henrik Levkowetz Cc: Zhang, Qiang [NTK]; 
>>> for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its 
>>> CoA but NAT's address (when NAT))
>>> 
>>> 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.
>>> 
>>> 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:
>>> originating port but "[protocols carried by UDP] responses".  Our
>>>  carried protocol here is IPv6, and there's no "IPv6 response".
>>> 
>>>  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.
>>> 
>>> 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).
>>> 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6