Subject: RE: [Mip6] MIP NAT Traversal

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 22 Mar 2006 11:25:19 -0800

> Just with respect to the current discussion in the meeting 
> right now, this is a good document to review:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-04.txt
> 
> The abstract says:
> 
> Abstract
> 
>    This document defines basic terminology for describing different
>    types of NAT behavior when handling Unicast UDP and also defines a
>    set of requirements that would allow many applications, such as
>    multimedia communications or on-line gaming, to work consistently.
>    Developing NATs that meet this set of requirements will greatly
>    increase the likelihood that these applications will function
>    properly.
> 
> Is there any additional considerations for MIP that should be 
> added this draft?

none. it just happens that whenever NATs are brought
up there is a lot of discussion, confusion, etc. and 
this happens every time. :)

as far DS-MIPv6, there is currently a mechanism 
described in the draft that uses a binding update as 
a keepalive message, but decouple the binding timer 
from the NAT keepalive timer. if there is traffic 
flowing, binding updates are not sent. both the BU 
and NAT keepalive timers are configurable.

Vijay

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Mar 2006 17:33:45 +0200

Vijay Devarapalli wrote:
>> Just with respect to the current discussion in the meeting right
>> now, this is a good document to review:
>> 
>> Is there any additional considerations for MIP that should be added
>> this draft?
> 
> none. it just happens that whenever NATs are brought up there is a
> lot of discussion, confusion, etc. and this happens every time. :)

Indeed.  I think this draft should clearly state somewhere what are the
assumptions it makes on the NATs this protocol is going to traverse.

At least, the draft should say somewhere that it does not specify
anything to be implemented - or respected by - the NATs and firewalls
being traversed.  And that it assumes that the NAT won't change the port
numbers of UDP packets going through it.

> as far DS-MIPv6, there is currently a mechanism described in the
> draft that uses a binding update as a keepalive message, but decouple
> the binding timer from the NAT keepalive timer. if there is traffic 
> flowing, binding updates are not sent. both the BU and NAT keepalive
> timers are configurable.

This mechanism, together with the NAT detection option, are clever ways
to deal with NATs and should be implemented.

However, I am afraid they are not enough in order to traverse some
deployed NATs.  At least one deployed NAT-FW managing a significant
number of subscribers dynamically changes the outgoing port number (the
dst port number of the packet sent by the NAT-FW to the HA-VPN-GW).
I.e. even if the MN specifies a dst UDP port number, that port number is
dynamically changed by the NAT-FW to some arbitrary value (observed in
practice being above 10.000).

Second, once a UDP connection is up between MN and HA, even if very
frequent keepalives (3s) are sent by both the MN and HA at short regular
intervals (3s), that particular NAT-FW will force changing the outgoing
port number.

Third, some times, even if continuous traffic flow between MN and HA
(video streaming) that port number will be forced changing after a
relatively longer time (few hours).

Fourth, that deployed NAT-FW will accept a very restricted range of
incoming UDP port numbers (the ones sent by MN to its HA).  IKE is not
accepted, ssh no, and so on.  The first UDP port number above 1000 is
Microsoft Streaming protocol (1755) is accepted by this particular NAT-FW.

So, a DSMIPv6 protocol with NAT traversal will not traverse this
particular deployment if it does not use 1755 outgoing port number.

Let me mention that that particular operator has a range of options for
subscribers.  The more expensive subscriptions will not block anything
to the Internet and even deliver a publicly routable IPv4 address.  Thus
for richer users the NAT and FW traversal parts of DSMIPv6 are not
needed at all and should not be used.  The cheapest subscriptions won't
give access to anything else than NAT, tcp 80, udp 1755 and dynamically
changing port numbers.

That said, it would be beneficial for this document to describe what it
assumes from the NAT-FW to support.  In a section of its own.

If there is interest, there exist also the possibility to dynamically 
learn the behaviour of the NAT-FW (learn more than just the fact that 
there's a NAT) and implicitely adapt the protocol behaviour.  "Dynamic 
path discovery" or so.  Until now this idea didn't seem to attract.

Alex