GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3519

Network Working Group H. Levkowetz Request for Comments: 3519 ipUnplugged Category: Standards Track S. Vaarala

                                                               Netseal
                                                            April 2003
  Mobile IP Traversal of Network Address Translation (NAT) Devices

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

 Mobile IP's datagram tunnelling is incompatible with Network Address
 Translation (NAT).  This document presents extensions to the Mobile
 IP protocol and a tunnelling method which permits mobile nodes using
 Mobile IP to operate in private address networks which are separated
 from the public internet by NAT devices.  The NAT traversal is based
 on using the Mobile IP Home Agent UDP port for encapsulated data
 traffic.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1   Terminology . . . . . . . . . . . . . . . . . . . . . .  2
     1.2   Problem description . . . . . . . . . . . . . . . . . .  3
     1.3   Assumptions . . . . . . . . . . . . . . . . . . . . . .  4
 2.  NAT Traversal Overview. . . . . . . . . . . . . . . . . . . .  5
     2.1   Basic Message Sequence. . . . . . . . . . . . . . . . .  5
 3.  New Message Formats . . . . . . . . . . . . . . . . . . . . .  6
     3.1   UDP Tunnel Request Extension. . . . . . . . . . . . . .  6
           3.1.1 F (Force) Flag. . . . . . . . . . . . . . . . . .  7
           3.1.2 R (Registration through FA Required) flag . . . .  8
           3.1.3 Reserved Fields . . . . . . . . . . . . . . . . .  8
           3.1.4 Encapsulation . . . . . . . . . . . . . . . . . .  8
           3.1.5 Mobile IP Registration Bits . . . . . . . . . . .  9
     3.2   UDP Tunnel Reply Extension. . . . . . . . . . . . . . .  9
           3.2.1 Reply Code. . . . . . . . . . . . . . . . . . . . 10

Levkowetz & Vaarala Standards Track [Page 1] RFC 3519 NAT Traversal for Mobile IP April 2003

     3.3   MIP Tunnel Data Message . . . . . . . . . . . . . . . . 10
     3.4   UDP Tunnelling Flag in Agent Advertisements . . . . . . 11
     3.5   New Registration Reply Codes. . . . . . . . . . . . . . 12
 4.  Protocol Behaviour. . . . . . . . . . . . . . . . . . . . . . 12
     4.1   Relation to standard MIP tunnelling . . . . . . . . . . 12
     4.2   Encapsulating IP Headers in UDP . . . . . . . . . . . . 13
     4.3   Decapsulation . . . . . . . . . . . . . . . . . . . . . 15
     4.4   Mobile Node Considerations. . . . . . . . . . . . . . . 15
     4.5   Foreign Agent Considerations. . . . . . . . . . . . . . 16
     4.6   Home Agent Considerations . . . . . . . . . . . . . . . 18
           4.6.1 Error Handling. . . . . . . . . . . . . . . . . . 19
     4.7   MIP signalling versus tunnelling. . . . . . . . . . . . 20
     4.8   Packet fragmentation. . . . . . . . . . . . . . . . . . 21
     4.9   Tunnel Keepalive. . . . . . . . . . . . . . . . . . . . 21
     4.10  Detecting and compensating for loss of NAT mapping. . . 22
     4.11  Co-located registration through FA. . . . . . . . . . . 24
 5.  Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
     5.1   Movement Detection and Private Address Aliasing . . . . 24
     5.2   Mobility Binding Lifetime . . . . . . . . . . . . . . . 25
 6.  Security Considerations . . . . . . . . . . . . . . . . . . . 26
     6.1   Traffic Redirection Vulnerabilities . . . . . . . . . . 27
           6.1.1 Manipulation of the Registration
                 Request Message . . . . . . . . . . . . . . . . . 27
           6.1.2 Sending a Bogus Keepalive Message . . . . . . . . 27
     6.2   Use of IPsec. . . . . . . . . . . . . . . . . . . . . . 28
     6.3   Firewall Considerations . . . . . . . . . . . . . . . . 28
 7.  UNSAF Considerations. . . . . . . . . . . . . . . . . . . . . 28
 8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
 9.  Intellectual Property Rights. . . . . . . . . . . . . . . . . 30
 10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 31
 11. Normative References. . . . . . . . . . . . . . . . . . . . . 31
 12. Informative References. . . . . . . . . . . . . . . . . . . . 32
 13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 33
 14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 34

1. Introduction

1.1 Terminology

 The Mobile IP related terminology described in RFC 3344 [10] is used
 in this document.  In addition, the following terms are used:
 Forward Tunnel
    A tunnel that forwards packets towards the mobile node.  It starts
    at the home agent, and ends at the mobile node's care-of address.

Levkowetz & Vaarala Standards Track [Page 2] RFC 3519 NAT Traversal for Mobile IP April 2003

 Reverse Tunnel
    A tunnel that starts at the mobile node's care-of address and
    terminates at the home agent.
 NAT
    Network Address Translation.  "Traditional NAT would allow hosts
    within a private network to transparently access hosts in the
    external network, in most cases.  In a traditional NAT, sessions
    are uni-directional, outbound from the private network." -- RFC
    2663 [11].  Basic NAT and NAPT are two varieties of NAT.
 Basic NAT
    "With Basic NAT, a block of external addresses are set aside for
    translating addresses of hosts in a private domain as they
    originate sessions to the external domain.  For packets outbound
    from the private network, the source IP address and related fields
    such as IP, TCP, UDP and ICMP header checksums are translated.
    For inbound packets, the destination IP address and the checksums
    as listed above are translated." -- RFC 2663 [11].
 NAPT
    Network Address Port Translation.  "NAPT extends the notion of
    translation one step further by also translating transport
    identifier (e.g., TCP and UDP port numbers, ICMP query
    identifiers).  This allows the transport identifiers of a number
    of private hosts to be multiplexed into the transport identifiers
    of a single external address.  NAPT allows a set of hosts to share
    a single external address.  Note that NAPT can be combined with
    Basic NAT so that a pool of external addresses are used in
    conjunction with port translation." -- RFC 2663 [11].
 In this document, the more general term NAT is used to cover both
 NATs and NAPTs.  In most deployment cases today, we believe that the
 NATs used are of the NAPT variety.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in BCP 14, RFC 2119 [6].

1.2 Problem description

 A basic assumption that Mobile IP [10] makes is that mobile nodes and
 foreign agents are uniquely identifiable by a globally routable IP
 address.  This assumption breaks down when a mobile node attempts to
 communicate from behind a NAT.

Levkowetz & Vaarala Standards Track [Page 3] RFC 3519 NAT Traversal for Mobile IP April 2003

 Mobile IP relies on sending traffic from the home network to the
 mobile node or foreign agent through IP-in-IP tunnelling.  IP nodes
 which communicate from behind a NAT are reachable only through the
 NAT's public address(es).  IP-in-IP tunnelling does not generally
 contain enough information to permit unique translation from the
 common public address(es) to the particular care-of address of a
 mobile node or foreign agent which resides behind the NAT; in
 particular there are no TCP/UDP port numbers available for a NAT to
 work with.  For this reason, IP-in-IP tunnels cannot in general pass
 through a NAT, and Mobile IP will not work across a NAT.
 Mobile IP's Registration Request and Reply will on the other hand be
 able to pass through NATs and NAPTs on the mobile node or foreign
 agent side, as they are UDP datagrams originated from the inside of
 the NAT or NAPT.  When passing out, they make the NAT set up an
 address/port mapping through which the Registration Reply will be
 able to pass in to the correct recipient.  The current Mobile IP
 protocol does however not permit a registration where the mobile
 node's IP source address is not either the CoA, the Home Address, or
 0.0.0.0.
 What is needed is an alternative data tunnelling mechanism for Mobile
 IP which will provide the means needed for NAT devices to do unique
 mappings so that address translation will work, and a registration
 mechanism which will permit such an alternative tunnelling mechanism
 to be set up when appropriate.
 This mechanism will address 3 different scenarios:
  1. A mobile node with co-located address behind a NAT; no FA
  1. A mobile node registered with an FA where both the mobile node and

the FA are behind the same NAT

  1. A mobile node with co-located address using an FA which demands

that registrations pass through the FA (sets the "R" bit) where

    both the mobile node and the FA are behind the same NAT

1.3 Assumptions

 The primary assumption in this document is that the network allows
 communication between an UDP port chosen by the mobile node and the
 home agent UDP port 434.  If this assumption does not hold, neither
 Mobile IP registration nor data tunnelling will work.
 This document does NOT assume that mobility is constrained to a
 common IP address space.  On the contrary, the routing fabric between
 the mobile node and the home agent may be partitioned into a

Levkowetz & Vaarala Standards Track [Page 4] RFC 3519 NAT Traversal for Mobile IP April 2003

 "private" and a "public" network, and the assumption is that some
 mechanism is needed in addition to vanilla Mobile IP according to RFC
 3344 [10] in order to achieve mobility within disparate IP address
 spaces.
 For a more extensive discussion of the problems with disparate
 address spaces, and how they may be solved, see RFC 3024 [9].
 The reverse tunnels considered here are symmetric, that is, they use
 the same configuration (encapsulation method, IP address endpoints)
 as the forward tunnel.

2. NAT Traversal Overview

 This section gives a brief overview of the MIP UDP tunnelling
 mechanism which may be used to achieve NAT traversal for Mobile IP.
 In MIP UDP tunnelling, the mobile node may use an extension
 (described below) in its Registration Request to indicate that it is
 able to use Mobile IP UDP tunnelling instead of standard Mobile IP
 tunnelling if the home agent sees that the Registration Request seems
 to have passed through a NAT.  The home agent may then send a
 registration reply with an extension indicating acceptance (or
 denial).  After assent from the home agent, MIP UDP tunnelling will
 be available for use for both forward and reverse tunnelling.  UDP
 tunnelled packets sent by the mobile node use the same ports as the
 registration request message.  In particular, the source port may
 vary between new registrations, but remains the same for all
 tunnelled data and re-registrations.  The destination port is always
 434.  UDP tunnelled packets sent by the home agent uses the same
 ports, but in reverse.

2.1 Basic Message Sequence

 The message sequence diagram below exemplifies setting up and using a
 Mobile IP UDP tunnel as described in this document.  The tunnel is
 set up by the use of specific extensions in the initial Mobile IP
 Registration Request and Reply exchange.  Thereafter, any traffic
 from the home agent to the mobile node is sent through the UDP
 tunnel.  The mobile node may at its discretion use the UDP tunnel for
 reverse tunnelling or not, although in most cases where MIP UDP
 tunnelling is needed, reverse tunnelling will also be needed.

Levkowetz & Vaarala Standards Track [Page 5] RFC 3519 NAT Traversal for Mobile IP April 2003

 mobile node            NAT           home agent
      |                  |                  |
      |                  |                  |
      | Registration     |                  |
      | Request with     |                  |
      |-----------------///--------------->>|
      |UDP Tunnel Request|                  |
      |                  |                  +
      |                  |                  || IP Source and
      |                  |                  || CCoA address
      |                  |                  || discrepancy
      |                  |                  || seen
      |                  | Registration     +
      |                  | Reply with       |
      |<<---------------///-----------------|
      |                  | UDP Tunnel Reply.|
      |                  |                  |
      | UDP tunnelled pkg|                  |
      |=================///===============>>|
      |                  | UDP tunnelled pkg|
      |<<===============///=================|
      |                  |                  ||absence of
      |                  |                  ||traffic for
      |                  |                  ||UDP keepalive
      | UDP keepalive    |                  ||period
      |-----------------///--------------->>+
      .                  .                  +
      .                  .                  .
      .                  .                  .

3. New Message Formats

3.1 UDP Tunnel Request Extension

 This extension is a skippable extension.  It signifies that the
 sender is capable of handling MIP UDP tunnelling, and optionally that
 a particular encapsulation format is requested in the MIP UDP tunnel.
 The format of this extension is as shown below.  It adheres to the
 short extension format described in [10].
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |    Sub-Type   |   Reserved 1  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|R| Reserved 2| Encapsulation |          Reserved 3           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Levkowetz & Vaarala Standards Track [Page 6] RFC 3519 NAT Traversal for Mobile IP April 2003

 Type                144
 Length              6.  Length in bytes of this extension, not
                     including the Type and Length bytes.
 Sub-Type            0
 Reserved 1          Reserved for future use.  MUST be set to 0 on
                     sending, MUST be ignored on reception.
 F                   F (Force) flag.  Indicates that the mobile
                     node wants to force MIP UDP tunnelling to be
                     established.
 R                   R (Registration through FA Required) flag.
                     Indicates that the R bit was set in the FA's
                     Agent Advertisement.  Registration is being
                     made using a co-located care-of address, but
                     through the FA.
 Reserved 2          Reserved for future use.  MUST be set to 0 on
                     sending, MUST be ignored on reception.
 Encapsulation       Indicates the type of tunnelled data, using
                     the same numbering as the IP Header Protocol
                     Field.
 Reserved 3          Reserved for future use.  MUST be set to 0 on
                     sending, MUST be verified as 0 on receipt;
                     otherwise the extension must be handled as not
                     understood and silently skipped.

3.1.1 F (Force) Flag

 Indicates that the mobile node wants to use traversal regardless of
 the outcome of NAT detection performed by the home agent.  This is
 useful if the route between the mobile node and the home agent works
 for Mobile IP signalling packets, but not for generic data packets
 (e.g., because of firewall filtering rules).  If the home agent
 supports this protocol, it SHOULD either accept the traversal and
 reply with a UDP Tunnel Reply Extension or reject the Registration
 Request.  In case of the registration failing, the Home Agent SHOULD
 send a Registration Reply with Code field set to 129
 ("administratively prohibited").

Levkowetz & Vaarala Standards Track [Page 7] RFC 3519 NAT Traversal for Mobile IP April 2003

 If the HA does not understand the UDP Tunnel Request Extension, it
 will silently discard it, and if everything else is fine, it will
 reply with a registration reply with reply code 0 (registration
 accepted), but without any UDP Tunnel Reply Extension.  In this case,
 the mobile node MUST NOT use MIP UDP tunnelling.

3.1.2 R (Registration through FA Required) flag

 This flag MUST be set by the mobile node when it is using a co-
 located address, but registering through an FA because it has
 received an Agent Advertisement with the 'R' bit set.

3.1.3 Reserved Fields

 The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt,
 while the 'Reserved 3' field must be 0 on receipt, otherwise this
 extension MUST be handled as not understood and silently skipped.
 This permits future additions to this extension to be made which
 either can co-exist with old implementations, or will force a
 rejection of the extension from an old implementation.

3.1.4 Encapsulation

 The 'Encapsulation' field defines the mode of encapsulation requested
 if MIP UDP tunnelling is accepted by the home agent.  This field uses
 the same values as the IP header Protocol field:
    4     IP header (IP-in-UDP tunnelling) RFC 2003 [4]
    47    GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
    55    Minimal IP encapsulation header RFC 2004 [5]
 If the home agent finds that UDP tunnelling is not needed, the
 encapsulation will be determined by the 'M' and 'G' flags of the
 registration request; but if the home agent finds that MIP UDP
 tunnelling should be done, the encapsulation is determined from the
 value of the Encapsulation field.  If the value of this field is
 zero, it defaults to the value of 'M' and 'G' fields in the
 Registration Request message, but if it is non-zero, it indicates
 that a particular encapsulation is desired.

Levkowetz & Vaarala Standards Track [Page 8] RFC 3519 NAT Traversal for Mobile IP April 2003

3.1.5 Mobile IP Registration Bits

 The Mobile IP registration bits S, B, D, M, G and T retain their
 meaning as described in RFC 3344 [10] and RFC 3024 [9] (except that
 the significance of the M and G bits may be modified by the
 Encapsulation field when MIP UDP tunnelling is used, as described
 above).  The use of the M and G bits together with MIP UDP tunnelling
 is also touched upon in Section 4.1.
 When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation
 by the mobile node) MUST be set, otherwise UDP tunnelling would not
 be meaningful.
 Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP
 tunnelling, even if not all traffic will be reverse tunnelled.  This
 ensures that a HA which is not prepared to accept reverse tunnelling
 will not accept a registration which may later turn out to be
 unusable.  Also see the discussion of use of the 'T' bit in Foreign
 Agent Considerations (Section 4.5).

3.2 UDP Tunnel Reply Extension

 This extension is a non-skippable extension.  It is sent in reply to
 a UDP Tunnel Request extension, and indicates whether or not the HA
 will use MIP UDP tunnelling for the current mobility binding.  The
 format of this extension is as shown below.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |    Sub-Type   |  Reply Code   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|        Reserved             |     Keepalive Interval        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type                44
 Length              6.  Length in bytes of this extension, not
                     including the Type and Length bytes.
 Sub-Type            0
 Reply Code          Indicates whether the HA assents or declines
                     to use UDP tunnelling for the current mobility
                     binding.  See Section 3.2.1 below.

Levkowetz & Vaarala Standards Track [Page 9] RFC 3519 NAT Traversal for Mobile IP April 2003

 F                   F (Forced) flag.  Indicates that tunnelling is
                     being forced because the F flag was set in the
                     tunnelling request, irrespective of the
                     detection of a NAT or not.
 Keepalive Interval  Specifies the NAT keepalive interval that the
                     mobile node SHOULD use.  A keepalive packet
                     SHOULD be sent if Keepalive Interval seconds
                     have elapsed without any signalling or data
                     traffic being sent.  If this field is set to
                     0, the mobile node MUST use its default
                     configured keepalive interval.
 Reserved            Reserved for future use.  MUST be set to 0 on
                     sending, MUST be ignored on reception.

3.2.1 Reply Code

 The Reply Code field of the UDP Tunnel Reply Extension indicates if
 UDP tunnelling have been accepted and will be used by the HA.  Values
 in the range 0 ..  63 indicate assent, i.e., that tunnelling will be
 done, while values in the range 64 ..  255 indicate that tunnelling
 should not be done.  More information may be given by the value of
 the response code.
 The following response codes are defined for use in the code field of
 the UDP Tunnel Reply Extension:
    0     Will do tunnelling
    64    Tunnelling declined, reason unspecified

3.3 MIP Tunnel Data Message

 This MIP message header serves to differentiate traffic tunnelled
 through the well-known port 434 from other Mobile IP messages, e.g.,
 Registration Requests and Registration Replies.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |  Next Header  |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type                4

Levkowetz & Vaarala Standards Track [Page 10] RFC 3519 NAT Traversal for Mobile IP April 2003

 Next Header         Indicates the type of tunnelled data, using
                     the same numbering as the IP Header Protocol
                     Field.
 Reserved            Reserved for future use.  MUST be set to 0 on
                     sending, MUST be ignored on reception.
 The Next Header field uses the same values as the IP header Protocol
 field.  Immediately relevant for use with Mobile IP are the following
 values:
     4    IP header (IP-in-UDP tunnelling) RFC 2003 [4]
    47    GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
    55    Minimal IP encapsulation header RFC 2004 [5]
 The receiver of a tunnelled packet MUST check that the Next Header
 value matches the tunnelling mode established for the mobility
 binding with which the packet was sent.  If a discrepancy is
 detected, the packet MUST be dropped.  A log entry MAY be written,
 but in this case the receiver SHOULD ensure that the amount of log
 entries written is not excessive.
 In addition to the encapsulation forms listed above, the MIP UDP
 tunnelling can potentially support other encapsulations, by use of
 the Next Header field in the MIP Tunnel Data Header and the
 Encapsulation Header field of the UDP Tunnel Request Extension
 (Section 3.1).

3.4 UDP Tunnelling Flag in Agent Advertisements

 The only change to the Mobility Agent Advertisement Extension defined
 in RFC 3344 [10] is a flag indicating that the foreign agent
 generating the Agent Advertisement supports MIP UDP Tunnelling.  The
 flag is inserted after the flags defined in [10].
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |        Sequence Number        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Lifetime            |R|B|H|F|M|G|r|T|U|   reserved  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  zero or more Care-of Addresses               |
 |                              ...                              |

Levkowetz & Vaarala Standards Track [Page 11] RFC 3519 NAT Traversal for Mobile IP April 2003

 The flag is defined as follows:
 U     UDP Tunnelling support.  This Agent supports MIP UDP Tunnelling
       as specified in this document.  This flag SHOULD be set in
       advertisements sent by a foreign agent which supports MIP UDP
       tunnelling and is situated behind a NAT.  It MUST NOT be set in
       advertisements from foreign agents which are not situated
       behind a NAT, and thus has no need to advertise the capability.

3.5 New Registration Reply Codes

 One new registration reply code is defined:
    ERROR_HA_UDP_ENCAP_UNAVAIL      Requested UDP tunnel encapsulation
                                    unavailable
 This is used by the HA to distinguish the registration denial caused
 by an unavailable UDP tunnel encapsulation mode from a denial caused
 by unavailable standard tunnel encapsulation requested by use of the
 'T' bit together with either 'M' or 'G' bit.

4. Protocol Behaviour

4.1 Relation to standard MIP tunnelling

 The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP
 encapsulation.  The mobile node MAY request alternative forms of
 encapsulation to be used with UDP tunnelling by setting the 'M' bit
 and/or the 'G' bit of a Mobile IP registration request, or by
 explicitly requesting a particular encapsulation for the MIP UDP
 tunnel by using the Encapsulation field.  The M and G bits retain the
 meaning as described in RFC 3344 [10] within the context of MIP UDP
 tunnelling.  The UDP tunnelling version of the classic MIP
 encapsulation methods can be summarised as:
 IP in UDP.  When Mobile IP UDP tunnelling is used, this is the
    default encapsulation type.  Any home agent and mobile node that
    implements Mobile IP UDP tunnelling MUST implement this
    encapsulation type.
 GRE in UDP.  If the 'G' bit is set in a registration request and
    the Encapsulation field is zero, the mobile node requests that its
    home agent use GRE encapsulation [3] for datagrams tunnelled to
    the mobile node.  If MIP UDP tunnelling is also requested and
    accepted, GRE-in-UDP encapsulation SHALL be used in the same cases
    as GRE in IP encapsulation would be used if the MIP UDP tunnelling
    had not been requested.

Levkowetz & Vaarala Standards Track [Page 12] RFC 3519 NAT Traversal for Mobile IP April 2003

 Minimal encapsulation in UDP.  If the 'M' bit is set and the
    Encapsulation field is zero, the mobile node requests that its
    home agent use minimal encapsulation [5] for datagrams tunnelled
    to the mobile node.  If MIP UDP tunnelling is also used, minimal
    encapsulation in UDP SHALL be used in the same cases as minimal
    encapsulation according to RFC 2004 [5] would be used if the MIP
    UDP tunnelling had not been requested.
 When the Encapsulation field is non-zero, a particular encapsulation
 format is requested for the MIP UDP tunnel.  If tunnelling is
 indicated, the request MUST either be accepted using the requested
 encapsulation, or rejected with the error code
 ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation
 unavailable" defined in Section 3.5.  On receipt of this error, the
 mobile node MAY choose to send a new Registration Request with
 different requirements on MIP UDP tunnelling encapsulation.

4.2 Encapsulating IP Headers in UDP

 MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a
 manner analogous to that described for IP-in-IP tunnelling in RFC
 2003 [4], with the exception of the addition of an UDP header [1] and
 MIP Message header [10] between the outer and inner IP header.
 Mobile IP Registration Requests and Registration Replies are already
 in the form of UDP messages, and SHALL NOT be tunnelled even when MIP
 IP-in-UDP tunnelling is in force.

Levkowetz & Vaarala Standards Track [Page 13] RFC 3519 NAT Traversal for Mobile IP April 2003

 To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an
 outer IP header [2], UDP header [1] and MIP Message header [10] is
 inserted before the datagram's existing IP header, as follows:
                                     +---------------------------+
                                     |                           |
                                     |      Outer IP Header      |
                                     +---------------------------+
                                     |                           |
                                     |        UDP Header         |
                                     +---------------------------+
                                     |      MIP Tunnel Data      |
                                     |      Message Header       |
 +---------------------------+       +---------------------------+
 |                           |       |                           |
 |         IP Header         |       |         IP Header         |
 +---------------------------+ ====> +---------------------------+
 |                           |       |                           |
 |         IP Payload        |       |         IP Payload        |
 |                           |       |                           |
 |                           |       |                           |
 +---------------------------+       +---------------------------+
 The outer IP header Source Address and Destination Address, together
 with the UDP header Source Port and Destination Port, identify the
 "endpoints" of the tunnel.  The inner IP header Source Address and
 Destination Addresses identify the original sender and the recipient
 of the datagram, respectively.  The inner IP header is not changed by
 the encapsulator, except to decrement the TTL by one if the
 tunnelling is being done as part of forwarding the datagram as noted
 in RFC 2003 [4], and remains unchanged during its delivery to the
 tunnel exit point.  No change to IP options in the inner header
 occurs during delivery of the encapsulated datagram through the
 tunnel.  Note that the security options of the inner IP header MAY
 affect the choice of security options for the encapsulating (outer)
 IP header.
 Minimal Encapsulation and GRE encapsulation is done in an analogous
 manner, following RFC 2004 [5] for Minimal Encapsulation and RFC 2784
 [8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in
 place of the outer IP header.
 All other provisions and requirements of RFC 2003 [4] and RFC 3024
 [9] are in force, except in one respect, as covered in Packet
 Fragmentation (Section 4.8).

Levkowetz & Vaarala Standards Track [Page 14] RFC 3519 NAT Traversal for Mobile IP April 2003

4.3 Decapsulation

 Before decapsulation is actually done, the decapsulating node MUST
 verify that the outer IP addresses and UDP port numbers exactly match
 the values used for the tunnel, with the exception of tunnels that
 are "half bound" (as described in Section 4.11) where the source UDP
 port can change.
 IP-in-UDP encapsulated traffic is decapsulated simply by stripping
 off the outer IP, UDP and MIP header, which leaves the original IP
 packet which is forwarded as is.
 Minimal IP encapsulation is processed by the receiver conceptually as
 follows.  First, the UDP and the Mobile IP headers are removed from
 the packet, and the Protocol field of the IP header replaced with the
 Next Header field in the MIP Tunnel Data header.  Second, the
 remaining IP header total length and checksum are adjusted to match
 the stripped packet.  Third, ordinary minimal IP encapsulation
 processing is done.
 GRE encapsulated traffic is processed according to RFC 2784 [8] and
 RFC 1701 [3], with the delivery header consisting of the outer IP,
 UDP and MIP headers.

4.4 Mobile Node Considerations

 The UDP Tunnel Request Extension MAY be used in a Mobile IP
 Registration Request from the mobile node to the home agent when the
 mobile node uses a co-located care-of address.  It SHALL NOT be used
 by the mobile node when it is registering with a foreign agent care-
 of address.
 The purpose of this extension is to indicate to the home agent that
 the mobile node is able to accept MIP UDP tunnelling if the home
 agent has an indication that the mobile node resides behind a NAT or
 NAPT.  It thus functions as a conditional solicitation for the use of
 MIP UDP tunnelling.
 As per Section 3.2 and 3.6.1.3 of RFC 3344 [10], the mobile node MUST
 place this Extension before the Mobile-Home Authentication Extension
 in registration messages, so that it is covered by the Mobile-Home
 Authentication Extension.
 If the mobile node includes the UDP Tunnel Request extension in a
 registration request, but receives a registration reply without a UDP
 Tunnel Reply extension, it MUST assume that the HA does not

Levkowetz & Vaarala Standards Track [Page 15] RFC 3519 NAT Traversal for Mobile IP April 2003

 understand this extension, and it MUST NOT use UDP tunnelling.  If
 the mobile node is in fact behind a NAT, the registration may then
 succeed, but traffic will not be able to traverse the NAT.
 When the mobile node sends MIP UDP tunnelled data, it MUST use the
 same UDP source port as was used for the most recent registration
 request.
 When the mobile node re-registers without having moved, it SHOULD
 take care to use the same source port as was used for the original
 registration of the current mobility binding.  Otherwise, while the
 home agent would change destination port on acceptance of the new
 registration, and the mobile node would presumably start listening on
 the new port, the packets in flight from the home agent at the time
 of change will be dropped when arriving at the mobile node's old
 port.  (This does not mean that the home agent should refuse a
 registration request using MIP UDP tunnelling where a new port have
 been used, as this might be the result of the NAT dropping state, the
 mobile node re-booting, changing interface, etc.)
 If a mobile node is registering through a foreign agent but using a
 co-located care-of address, and the agent advertisement from the
 foreign agent had the 'U' bit set, the mobile node MUST set the 'R'
 flag in its UDP Tunnel Request Extension, in order to make the HA use
 MIP UDP tunnelling.  In this case, the mobile node also MUST send a
 keepalive as soon as its registration has been accepted.
 If a mobile node is registering through a foreign agent but using a
 co-located care-of address, and the agent advertisement from the
 foreign agent does not have the 'U' bit set, the mobile node MUST NOT
 include a UDP Tunnel Request Extension in the registration request.

4.5 Foreign Agent Considerations

 The UDP Tunnel Request Extension MAY be used by a foreign agent when
 it is forwarding a Mobile IP Registration Request to a home agent,
 when the foreign agent is situated behind a NAT or has some other
 compelling reason to require MIP UDP tunnelling.
 The purpose of this extension is to indicate to the home agent that
 the foreign agent is able to accept MIP UDP tunnelling if the home
 agent has an indication that the foreign agent resides behind a NAT
 or NAPT.  It thus functions as a conditional solicitation for the use
 of MIP UDP tunnelling.
 A foreign agent which requires the mobile node to register through a
 foreign agent by setting the 'R' bit in the agent advertisement, MUST
 NOT add the UDP Tunnel Request Extension when forwarding a

Levkowetz & Vaarala Standards Track [Page 16] RFC 3519 NAT Traversal for Mobile IP April 2003

 registration request which uses a co-located care-of address, as this
 will lead to a UDP tunnel being set up from the home agent to the
 foreign agent instead of to the mobile node.
 As per Section 3.2 and 3.7.2.2 of RFC 3344 [10], the foreign agent
 when using this extension MUST place it after the Mobile-Home
 Authentication Extension in registration messages.  If the foreign
 agent shares a mobility security association with the home agent and
 therefore appends a Foreign-Home Authentication Extension, the UDP
 Tunnel Request Extension MUST be placed before the Foreign-Home
 Authentication Extension.
 As the home agent detects the presence of a NAT in the path between
 the sender and itself by seeing a mismatch between the IP source
 address and the care-of address given in the registration request, it
 is REQUIRED that the foreign agent, when using this extension, sends
 the registration request with an IP source address matching the
 care-of address.
 A foreign agent using MIP UDP tunnelling to a home agent because the
 FA is situated behind a NAT may be configured to encourage reverse
 tunnelling, or be neutral about it, depending on the characteristics
 of the NAT.  If the NAT translates all source addresses of outgoing
 packets to its own public address, it will not be possible to
 maintain sessions when moving away from this network if the mobile
 node has used triangular routing instead of reverse tunnelling.  On
 the other hand, if it is known that the NAT is smart enough to not
 translate publicly routable source addresses, AND does not do ingress
 filtering, triangular routing may succeed.  The leg from the home
 agent to the foreign agent will still use MIP UDP tunnelling to pass
 through the NAT.
 Therefore, if it is known when configuring a foreign agent behind a
 NAT that the NAT will translate public as well as private addresses,
 or it is known that ingress filtering is being done between the
 private and public networks, the foreign agent SHOULD reply to
 registration requests which don't have the 'T' bit set with a reply
 code 75, "reverse tunnel is mandatory and 'T' bit not set".
 Conversely, if it is known that the NAT is smart about not
 translating public addresses, and no ingress filtering is done, so it
 is reasonable to believe that a mobile node with a publicly routable
 address may be able to keep up sessions when moving to or from this
 network, the foreign agent MAY be configured to forward registration
 requests even if they don't have the 'T' bit set.

Levkowetz & Vaarala Standards Track [Page 17] RFC 3519 NAT Traversal for Mobile IP April 2003

 If the behaviour of the NAT is unknown in this respect, it SHOULD be
 assumed that it will translate all addresses, thus the foreign agent
 SHOULD be configured to reply to registration requests which don't
 have the 'T' bit set with a reply code 75, "reverse tunnel is
 mandatory and 'T' bit not set".

4.6 Home Agent Considerations

 The purpose of the MIP UDP Tunnel Reply Extension is to indicate
 whether or not the home agent accepts the use of MIP UDP tunnelling
 for this mobility binding, and to inform the mobile node or foreign
 agent of the suggested tunnel keepalive interval to be used.
 The UDP Tunnel Reply Extension MUST be used in a Mobile IP
 Registration Reply from the home agent to the mobile node when it has
 received and accepted a UDP Tunnel Request (Section 3.1) from a
 mobile node.
 The home agent MUST use a mismatch between source IP address and
 care-of address in the Mobile IP Registration Request message as the
 indication that a mobile node may reside behind a NAT.  If the
 Registration Request also contains the UDP Tunnel Request extension
 without the 'R' flag set, and the home agent is capable of, and
 permits MIP UDP tunnelling, the home agent SHALL respond with a
 registration reply containing an assenting UDP Tunnel Reply Extension
 as described in Section 3.2.  If the 'R' flag is set, special
 considerations apply, as described below.
 If the home agent receives a Registration Request with matching
 source IP address and co-located care-of address which contains a MIP
 UDP Tunnel Request Extension, the home agent SHOULD respond with a
 Registration Reply containing a declining UDP Tunnel Reply - unless
 tunnelling has been explicitly requested by the mobile node using the
 'F' flag as described in Section 3.1.
 If the home agent assents to UDP tunnelling, it MUST use the source
 address of the registration request as the effective care-of address,
 rather than the care-of address given in the registration request,
 except in the case where the 'R' flag is set in the UDP Tunnel
 Request Extension.
 If the home agent receives a Registration Request with the 'R' flag
 set in the UDP Tunnel Request Extension, it SHOULD reply with an
 assenting UDP Tunnel Reply Extension if it is capable of, and permits
 MIP UDP tunnelling.  In this case, however, the source address and
 port of the registration request may be a NAT'ed version of the
 foreign agent source address and port.  In order to direct tunnelled
 traffic correctly to the mobile node, the home agent MUST wait for

Levkowetz & Vaarala Standards Track [Page 18] RFC 3519 NAT Traversal for Mobile IP April 2003

 the first keepalive packet from the mobile node to arrive, before it
 can send traffic back to the correct NAT port (the one which is
 mapped to the MN).  In this case, the home agent MUST check that the
 outer source address (but not the port) of this keepalive packet is
 identical with the source address of the corresponding registration
 request.  The inner source address (that of the encapsulated ICMP
 echo request) MUST be the home address of the mobile node, and the
 inner destination address MUST be that of the home agent.  If all
 this holds, the outer source address and port of this keepalive
 packet SHALL be used by the HA as the outer destination address and
 port of the MIP UDP tunnel when forwarding traffic to the mobile
 node.
 The home agent SHOULD be consistent in acknowledging support for UDP
 tunnelling or not.  A home agent which understands the UDP Tunnel
 Request Extension and is prepared to respond positively to such a
 request SHOULD also respond with a UDP Tunnel Reply Extension
 containing a declining reply code if use of MIP UDP tunnelling is not
 indicated for a session.  The mobile node MUST NOT assume such
 behaviour from the home agent, since the home agent may undergo a
 software change with reboot, a policy change or a replacement; and
 consequently a change of behaviour.

4.6.1 Error Handling

 The following actions take place when things go wrong.
 The HA does not support the UDP Tunnel Request extension:
    The home agent ignores the extension and proceeds normally, which
    would be to refuse the registration if the IP source address does
    not match the care-of address, the home address or 0.0.0.0.  Even
    if the HA mistakenly does accept the registration, the mobile node
    will not be able to receive forward tunnelled data if it is behind
    a NAT.
    (It would be beneficial to have the mobile node de-register in
    this case.  The mobile node, however, normally has no way of
    telling that it is behind a NAT if it does not receive a UDP
    Tunnelling Reply.)
 NAT detected by home agent, but traversal not allowed:
    In some cases the home agent may disable NAT traversal even though
    it supports the UDP Tunnel Request extension and a NAT is
    detected.  In this case, the home agent SHOULD send a Registration
    Reply with the Code field set to 129, "administratively
    prohibited".

Levkowetz & Vaarala Standards Track [Page 19] RFC 3519 NAT Traversal for Mobile IP April 2003

 NAT not detected, 'F' flag set, but home agent does not allow forced
 use of MIP UDP tunnelling:
    The home agent SHOULD send a Registration Reply with the Code
    field set to 129, "administratively prohibited".
 UDP Tunnel Request extension sent by the mobile node (placed before
 the MN-HA authentication extension), but 'D' bit in registration
 request header not set:
    The home agent SHOULD send a Registration Reply with the Code
    field set to 134, "poorly formed Request".
 UDP Tunnel Request extension sent by the foreign agent (placed after
 the MN-HA authentication extension), but 'D' bit is set:
    The home agent SHOULD send a Registration Reply with the Code
    field set to 134, "poorly formed Request".
 Reserved 3 field of UDP Tunnel Request extension is nonzero:
    The home agent SHOULD send a Registration Reply with the Code
    field set to 134, "poorly formed Request".
 Encapsulation type requested in UDP Tunnel Request extension is
 unsupported:
    The home agent SHOULD send a Registration Reply with the Code
    field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel
    encapsulation unavailable" defined in Section 3.5.

4.7 MIP signalling versus tunnelling

 UDP tunnelling SHALL be used only for data packets, and only when the
 mobility binding used for sending was established using the UDP
 Tunnel Request, and accepted by an UDP Tunnel Reply from the home
 agent.  After MIP UDP tunnelling has been established for a mobility
 binding, data packets that are forward or reverse tunnelled using
 this mobility binding MUST be tunnelled using MIP UDP tunnelling, not
 IP-in-IP tunnelling or some other tunnelling method.
 As a consequence:
  1. Mobile IP signalling is never tunnelled.
  1. When using simultaneous bindings, each binding may have a

different type (i.e., UDP tunnelling bindings may be mixed with

    non-UDP tunnelling bindings).

Levkowetz & Vaarala Standards Track [Page 20] RFC 3519 NAT Traversal for Mobile IP April 2003

  1. Tunnelling is only allowed for the duration of the binding

lifetime.

4.8 Packet fragmentation

 From RFC 3022 [12]:
 "Translation of outbound TCP/UDP fragments (i.e., those originating
 from private hosts) in NAPT set-up are doomed to fail.  The reason is
 as follows.  Only the first fragment contains the TCP/UDP header that
 would be necessary to associate the packet to a session for
 translation purposes.  Subsequent fragments do not contain TCP/UDP
 port information, but simply carry the same fragmentation identifier
 specified in the first fragment.  Say, two private hosts originated
 fragmented TCP/UDP packets to the same destination host.  And, they
 happened to use the same fragmentation identifier.  When the target
 host receives the two unrelated datagrams, carrying same
 fragmentation id, and from the same assigned host address, it is
 unable to determine which of the two sessions the datagrams belong
 to.  Consequently, both sessions will be corrupted."
 Because of this, if the mobile node or foreign agent for any reason
 needs to send fragmented packets, the fragmentation MUST be done
 prior to the encapsulation.  This differs from the case for IP-in-IP
 tunnelling, where fragmentation may be done before or after
 encapsulation, although RFC 2003 [4] recommends doing it before
 encapsulation.
 A similar issue exists with some firewalls, which may have rules that
 only permit traffic on certain TCP and UDP ports, and not arbitrary
 outbound (or inbound) IP traffic.  If this is the case and the
 firewall is not set to do packet reassembly, a home agent behind a
 firewall will also have to do packet fragmentation before MIP UDP
 encapsulation.  Otherwise, only the first fragment (which contains
 the UDP header) will be allowed to pass from the home agent out
 through the firewall.
 For this reason, the home agent SHOULD do packet fragmentation before
 it does MIP UDP encapsulation.

4.9 Tunnel Keepalive

 As the existence of the bi-directional UDP tunnel through the NAT is
 dependent on the NAT keeping state information associated with a
 session, as described in RFC 2663 [11], and as the NAT may decide
 that the session has terminated after a certain time, keepalive
 messages may be needed to keep the tunnel open.  The keepalives
 should be sent more often than the timeout value used by the NAT.

Levkowetz & Vaarala Standards Track [Page 21] RFC 3519 NAT Traversal for Mobile IP April 2003

 This timeout may be assumed to be a couple of minutes, according to
 RFC 2663 [11], but it is conceivable that shorter timeouts may exist
 in some NATs.
 For this reason the extension used to set up the UDP tunnel has the
 option of setting the keepalive message interval to another value
 than the default value, see Section 3.2.
 The keepalive message sent MUST consist of a properly UDP
 encapsulated ICMP echo request directed to the home agent.
 For each mobility binding which has UDP tunnelling established, the
 non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive
 packet if no other packet to the HA has been sent in K seconds.  Here
 K is a parameter with a default value of 110 seconds.  K may be set
 to another value by the HA as described in the UDP tunnelling reply
 extension (Section 3.2).
 Except for the case where the mobile node registers with a co-located
 address through an FA (see Section 4.11) MIP UDP tunnelling is done
 using the same ports that have already been used for the registration
 request / reply exchange.  The MN or FA will send its first keepalive
 message at the earliest K seconds after the registration request was
 sent.  The same UDP source port MUST be used for the keepalive
 messages as was used for the original Registration Messages and for
 data messages.
 The remote UDP tunnel endpoint MUST use two-way keepalives consisting
 of UDP encapsulated ICMP Echo Request/Reply messages.  The rationale
 for using two-way keepalives is two-fold:
 1. Two-way keepalives allow the mobile node to detect loss of a NAT
    mapping.  Detection of NAT mapping loss in turn allows the MN to
    compensate by re-registering and using a shorter keepalive to
    avoid loss of NAT mappings in the future.
 2. One-way keepalives (keepalives sent by MN or FA, but without any
    reply from the home agent) actually cause more keepalive traffic
    overhead; the keepalive messages have to be sent more frequently
    to compensate for occasional loss of keepalive messages.  In
    contrast, two-way keepalives are acknowledged, and retransmissions
    occur only when a response is not received for a keepalive request
    within a reasonable time.

4.10 Detecting and compensating for loss of NAT mapping

 When a mobile node is using UDP encapsulated ICMP Echo Request/Reply
 messages as keepalives, it will have to deal with the possibility

Levkowetz & Vaarala Standards Track [Page 22] RFC 3519 NAT Traversal for Mobile IP April 2003

 that a NAT mapping is lost by a NAT device.  The crucial thing here
 is of course not the loss of the NAT mapping in itself; but rather
 that the home agent, in the absence of a Registration Request through
 the new mapping, will continue to send traffic to the NAT port
 associated with the old mapping.
 If the mobile node does not get a reply to its UDP encapsulated ICMP
 Echo Request even after a number of retransmissions, and is still
 connected to the same router that was used to establish the current
 mobility binding, the mobile node SHOULD re-register with the home
 agent by sending an Registration Request.  This lets the HA know
 about the new NAT mapping and restores connectivity between mobile
 node and home agent.
 Having established a new mobility binding, the mobile node MAY use a
 shorter keepalive interval than before the NAT mapping was lost; in
 particular, the mobile node MAY deviate from the keepalive interval
 assigned by the home agent.  If the binding loss continues to occur,
 the mobile node may shorten the keepalive interval each time it re-
 registers, in order to end up with a keepalive interval that is
 sufficient to keep the NAT mapping alive.  The strategy used to
 arrive at a keepalive interval when a NAT mapping is lost is
 implementation dependent.  However, the mobile node MUST NOT use a
 keepalive less than 10 seconds.
 Note that the above discussion only applies when the mobile node is
 re-registering through the same router, and thus presumably through
 the same NAT device that lost a NAT mapping earlier.  If the MN moves
 and still finds itself behind a NAT, it SHOULD return to its original
 keepalive interval (the default value, or as assigned by the home
 agent) and it SHOULD NOT do any keepalive interval compensation
 unless it discovers a loss of NAT mapping in the new environment.
 The home agent MUST NOT attempt to detect or compensate for NAT
 binding loss by dynamically changing the keepalive interval assigned
 in the Registration Reply; the home agent does not have enough
 information to do this reliably and should thus not do it at all.
 The mobile node is in a much better position to determine when a NAT
 mapping has actually been lost.  Note also that a MN is allowed to
 let a NAT mapping expire if the MN no longer needs connectivity.
 The discussion above does only in a limited sense apply to a foreign
 agent which is situated behind a NAT and using MIP UDP tunnelling.
 In this case, it is a matter of permanently configuring the FA to use
 a keepalive interval which is lower than the NAT mapping lifetime,
 rather than trying to dynamically adapt to the binding lifetimes of
 different NATs.

Levkowetz & Vaarala Standards Track [Page 23] RFC 3519 NAT Traversal for Mobile IP April 2003

4.11 Co-located registration through FA

 This section summarizes the protocol details which have been
 necessary in order to handle and support the case when a mobile node
 registers with a co-located address through a foreign agent, due to
 the FA advertisements having the 'R' bit set.  It gives background
 information, but lists no new requirements.
 When a mobile registers a co-located care-of address through an FA,
 the registration request which reaches the HA will have a different
 care-of address in the registration request compared to the source
 address in the registration request IP-header.  If the registration
 request also contains a UDP Tunnel Request Extension, the HA will
 erroneously set up a UDP tunnel, which will go to the FA instead of
 the MN.  For this reason, as mentioned in Section 4.4, the mobile
 node must not include a UDP Tunnel Request Extension in the
 registration if it is registering a co-located address through an FA
 which does not have the 'U' bit set in its advertisements.
 In order to still be able to use MIP UDP tunnelling in this case,
 foreign agents which are situated behind a NAT are encouraged to send
 advertisements which have the 'U' bit set, as described in Section
 3.4.
 If the FA advertisement has the 'U' bit set, indicating that it is
 behind a NAT, and also the 'R' bit set, and the mobile node wishes to
 use a co-located care-of address, it MUST set the 'R' flag in the UDP
 Tunnel Request Extension, in order to inform the HA of the situation
 so that it may act appropriately, as described in Section 4.4.
 Because the UDP tunnel is now taking another path than the
 registration requests, the home agent, when handling registrations of
 this type, must wait till the arrival of the first keepalive packet
 before it can set up the tunnel to the correct address and port.  To
 reduce the possibility of tunnel hijacking by sending a keepalive
 with a phony source address, it is required that only the port of the
 keepalive packet may be different from that of the registration
 request; the source address must be the same.  This means that if the
 FA and MN are communicating with the HA through different NATs, the
 connection will fail.

5. Implementation Issues

5.1 Movement Detection and Private Address Aliasing

 In providing a mobile node with a mechanism for NAT traversal of
 Mobile IP traffic, we expand the address space where a mobile node
 may function and acquire care-of addresses.  With this comes a new

Levkowetz & Vaarala Standards Track [Page 24] RFC 3519 NAT Traversal for Mobile IP April 2003

 problem of movement detection and address aliasing.  We here have a
 case which may not occur frequently, but is mentioned for
 completeness:
 Since private networks use overlapping address spaces, they may be
 mistaken for one another in some situations; this is referred to as
 private address aliasing in this document.  For this reason, it may
 be necessary for mobile nodes implementing this specification to
 monitor the link layer address(es) of the gateway(s) used for sending
 packets.  A change in the link layer address indicates probable
 movement to a new network, even if the IP address remains reachable
 using the new link layer address.
 For instance, a mobile node may obtain the co-located care-of address
 10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP
 from network #1.  It then moves to network #2, which uses an
 identical addressing scheme.  The only difference for the mobile node
 is the gateway's link layer address.  The mobile node should store
 the link layer address it initially obtains for the gateway (using
 ARP, for instance).  The mobile node may then detect changes in the
 link layer address in successive ARP exchanges as part of its
 ordinary movement detection mechanism.
 In rare cases the mobile nodes may not be able to monitor the link
 layer address of the gateway(s) it is using, and may thus confuse one
 point of attachment with another.  This specification does not
 explicitly address this issue.  The potential traffic blackout caused
 by this situation may be limited by ensuring that the mobility
 binding lifetime is short enough; the re-registration caused by
 expiration of the mobility binding fixes the problem (see Section
 5.2).

5.2 Mobility Binding Lifetime

 When responding to a registration request with a registration reply,
 the home agent is allowed to decrease the lifetime indicated in the
 registration request, as covered in RFC 3344 [10].  When using UDP
 tunnelling, there are some cases where a short lifetime is
 beneficial.
 First, if the NAT mapping maintained by the NAT device is dropped, a
 connection blackout will arise.  New packets sent by the mobile node
 (or the foreign agent) will establish a new NAT mapping, which the
 home agent will not recognize until a new mobility binding is
 established by a new registration request.
 A second case where a short lifetime is useful is related to the
 aliasing of private network addresses.  In case the mobile node is

Levkowetz & Vaarala Standards Track [Page 25] RFC 3519 NAT Traversal for Mobile IP April 2003

 not able to detect mobility and ends up behind a new NAT device (as
 described in Section 5.1), a short lifetime will ensure that the
 traffic blackout will not be exceedingly long, and is terminated by a
 re-registration.
 The definition of "short lifetime" in this context is dependent on
 the requirements of the usage scenario.  Suggested maximum lifetime
 returned by the home agent is 60 seconds, but in case the
 abovementioned scenarios are not considered a problem, longer
 lifetimes may of course be used.

6. Security Considerations

 The ordinary Mobile IP security mechanisms are also used with the NAT
 traversal mechanism described in this document.  However, there is
 one noticeable change: the NAT traversal mechanism requires that the
 HA trust unauthenticated address (and port) fields possibly modified
 by NATs.
 Relying on unauthenticated address information when forming or
 updating a mobility binding leads to several redirection attack
 vulnerabilities.  In essence, an attacker may do what NATs do, i.e.,
 modify addresses and ports and thus cause traffic to be redirected to
 a chosen address.  The same vulnerabilities apply to both MN-HA and
 FA-HA NAT traversal.
 In more detail: without a NAT, the care-of address in the
 registration request will be directly used by the HA to send traffic
 back to the MN (or the FA), and the care-of address is protected by
 the MN-HA (or FA-HA) authentication extension.  When communicating
 across a NAT, the effective care-of address from the HA point of view
 is that of the NAT, which is not protected by any authentication
 extension, but inferred from the apparent IP source address of
 received packets.  This means that by using the mobile IP
 registration extensions described in this document to enable
 traversal of NATs, one is opening oneself up to having the care-of
 address of a MN (or a FA) maliciously changed by an attacker.
 Some, but not all, of the attacks could be alleviated to some extent
 by using a simple routability check.  However, this document does not
 specify such a mechanism for simplicity reasons and because the
 mechanism would not protect against all redirection attacks.  To
 limit the duration of such redirection attacks, it is RECOMMENDED to
 use a conservative (that is, short) mobility binding lifetime when
 using the NAT traversal mechanism specified in this document.
 The known security issues are described in the sections that follow.

Levkowetz & Vaarala Standards Track [Page 26] RFC 3519 NAT Traversal for Mobile IP April 2003

6.1 Traffic Redirection Vulnerabilities

6.1.1 Manipulation of the Registration Request Message

 An attacker on the route between the mobile node (or foreign agent)
 and the home agent may redirect mobility bindings to a desired
 address simply by modifying the IP and UDP headers of the
 Registration Request message.  Having modified the binding, the
 attacker no longer needs to listen to (or manipulate) the traffic.
 The redirection is in force until the mobility binding expires or the
 mobile node re-registers.
 This vulnerability may be used by an attacker to read traffic
 destined to a mobile node, and to send traffic impersonating the
 mobile node.  The vulnerability may also be used to redirect traffic
 to a victim host in order to cause denial-of-service on the victim.
 The only defense against this vulnerability is to have a short time
 between re-registrations, which limits the duration of the
 redirection attack after the attacker has stopped modifying
 registration messages.

6.1.2 Sending a Bogus Keepalive Message

 When registering through an FA using a co-located care-of address,
 another redirection vulnerability opens up.  Having exchanged
 Registration Request/Reply messages with the HA through the FA, the
 MN is expected to send the first keepalive message to the HA, thus
 finalizing the mobility binding (the binding will remain in a "half
 bound" state until the keepalive is received).
 Having observed a Registration Request/Reply exchange, an attacker
 may send a bogus keepalive message assuming that the mobility binding
 is in the "half bound" state.  This opens up a similar redirection
 attack as discussed in Section 6.1.1.  Note, however, that the
 attacker does not need to be able to modify packets in flight; simply
 being able to observe the Registration Request/Reply message exchange
 is sufficient to mount the attack.
 With this in mind, the home agent MUST NOT accept a keepalive message
 from a different source IP address than where the Registration
 Request came from, as specified in Section 4.6.  This requirement
 limits the extent of the attack to redirecting the traffic to a bogus
 UDP port, while the IP address must remain the same as in the initial
 Registration Request.

Levkowetz & Vaarala Standards Track [Page 27] RFC 3519 NAT Traversal for Mobile IP April 2003

 The only defenses against this vulnerability are: (1) to have a short
 time between re-registrations, which limits the duration of the
 redirection attack after the attacker has stopped sending bogus
 keepalive messages, and (2) to minimize the time the binding is in a
 "half bound" state by having the mobile node send the first keepalive
 message immediately after receiving an affirmative registration
 reply.

6.2 Use of IPsec

 If the intermediate network is considered insecure, it is recommended
 that IPsec be used to protect user data traffic.  However, IPsec does
 not protect against the redirection attacks described previously,
 other than to protect confidentiality of hijacked user data traffic.
 The NAT traversal mechanism described in this document allows all
 IPsec-related traffic to go through NATs without any modifications to
 IPsec.  In addition, the IPsec security associations do not need to
 be re-established when the mobile node moves.

6.3 Firewall Considerations

 This document does not specify a general firewall traversal
 mechanism.  However, the mechanism makes it possible to use only a
 single address and a port for all MN-HA (or FA-HA) communication.
 Furthermore, using the same port for the MIP UDP tunnelled traffic as
 for control messages makes it quite probable that if a MIP
 registration can reach the home agent, MIP tunnelling and reverse
 tunnelling using the described mechanism will also work.

7. UNSAF Considerations

 The mechanism described in this document is not an "UNilateral Self-
 Address Fixing" (UNSAF) mechanism.  Although the mobile node makes no
 attempt to determine or use the NAT translated address, the mobile
 node through the registration process does attempt to keep the NAT
 mapping alive through refresh messages.  This section attempts to
 address issues that may be raised through this usage through the
 framework of the unsaf considerations IAB document [13].
 1. Precise definition.
    This proposal extends the Mobile IP v4 registration process to
    work across intervening NATs.  The Home Agent detects the presence
    of the NAT by examining the source address in the packet header
    and comparing it with the address contained in the registration
    message.

Levkowetz & Vaarala Standards Track [Page 28] RFC 3519 NAT Traversal for Mobile IP April 2003

    The NAT address and port detected by the home agent are not
    exported or communicated to any other node anywhere.
 2. Exit strategy.
    This mechanism will go out of use as IPv6 and Mobile IP v6 is
    deployed, obviating the need for MIPv4 NAT traversal.
    It can also be noted that this mechanism makes no changes to the
    base MIPv4 protocol which makes it dependent on the presence of
    NATs or the current extensions - i.e., no additional protocol
    changes would be needed if NATs were to go away.
 3. Issues making systems more brittle.
    The specific issue which is relevant here is that the effective
    care-of address (being the source address in the IP header
    received by the HA) is not protected by the Mobile IP
    authentication extension, and therefore may be spoofed.  This is
    discussed in some detail in Section 6, Security Considerations.
 4. Requirements for longer term solutions.
    The trivial long term solution is a transition to an environment
    where NATs are not required.  The most obvious such environment
    would be an IPv6 based internet.
    In the presence of NATs, an improved solution would require
  • the ability to discover the translations done by each NAT along

the route

  • the ability to validate the authority of each NAT to do those

translations

  • communicating as part of the signed registration request the

address of the NAT closest to the HA, for use as the effective

       care-of address from the viewpoint of the HA.
  • configuration of all intermediate NATs to accept only packets

from the neighbour NATs.

 5. Impact on existing, deployed NATs.
    One precursor of the mechanism described here has been used
    successfully across deployed NATs in Sweden, Germany, England,
    Japan and the USA, without necessitating neither adjustments of
    the NATs in question, nor adjustment of any protocol parameters.
    At the time of writing, little experience exist with the exact
    implementation proposed in this document, but effort has been put
    into making this mechanism even more robust and adaptive than its
    precursors.

Levkowetz & Vaarala Standards Track [Page 29] RFC 3519 NAT Traversal for Mobile IP April 2003

    With respect to the base Mobile IP specification, the impact of
    this document is that an increased frequency of registration
    requests is recommended from a security perspective when the NAT
    traversal mechanism is used.

8. IANA Considerations

 The numbers for the extensions defined in this document have been
 taken from the numbering space defined for Mobile IP messages,
 registration extensions and error codes defined in RFC 3344 [10].
 This document proposes one new message, two new extensions and a new
 error code that require type numbers and an error code value that
 have been assigned by IANA.  The two new extensions also introduce
 two new sub-type numbering spaces to be managed by IANA.
 Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request
 Extension.  The type number for this extension is 144.  This
 extension introduces a new sub-type numbering space where the value 0
 has been assigned to this extension.  Approval of new Tunnel Request
 Extension sub-type numbers is subject to Expert Review, and a
 specification is required [7].
 Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply
 Extension.  The type value for this extension is 44.  This extension
 introduces a new sub-type numbering space where the value 0 has been
 assigned to this extension.  Approval of new Tunnel Reply Extension
 sub-type numbers is subject to Expert Review, and a specification is
 required [7].
 Section 3.3 defines a new Mobile IP message, the Tunnel Data message.
 The type value for this message is 4.
 Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL:
 "Requested UDP tunnel encapsulation unavailable", from the numbering
 space for values defined for use with the Code field of Mobile IP
 Registration Reply Messages.  Code number 142 has been assigned from
 the subset "Error Codes from the Home Agent".
 The values for the Next Header field in the MIP Tunnel Data Message
 (Section 3.3) shall be the same as those used for the Protocol field
 of the IP header [2], and requires no new number assignment.

9. Intellectual Property Rights

 The IETF has been notified of intellectual property rights claimed in
 regard to some or all of the specification contained in this
 document.  For more information consult the online list of claimed
 rights (www.ietf.org/ipr.html).

Levkowetz & Vaarala Standards Track [Page 30] RFC 3519 NAT Traversal for Mobile IP April 2003

10. Acknowledgements

 Much of the text in Section 4.2 has been taken almost verbatim from
 RFC 2003, IP Encapsulation within IP [4].
 Adding support for the FA case was suggested by George Tsirtsis and
 Frode B. Nilsen.  Roy Jose pointed out a problem with binding
 updates, and Frode, Roy and George pointed out that there are cases
 where triangular routes may work, and suggested that reverse
 tunnelling need not be mandatory.  Roy and Qiang Zhang drew attention
 to a number of sections which needed to be corrected or stated more
 clearly.
 Phil Roberts helped remove a number of rough edges.  Farid Adrangi
 pointed out the DoS issue now covered in Security Considerations
 (Section 6).  Francis Dupont's helpful comments made us extend the
 Security Considerations section to make it more comprehensive and
 clear.  Milind Kulkarni and Madhavi Chandra pointed out the required
 match between the FA source and care-of addresses when the mechanism
 is used by an FA, and also contributed a number of clarifications to
 the text.
 Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and
 Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik
 Liden at ipUnplugged.  They have read and re-read the text, and
 contributed many valuable corrections and insights.

11. Normative References

 [1]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
      1980.
 [2]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
 [3]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
      Encapsulation (GRE)", RFC 1701, October 1994.
 [4]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
      1996.
 [5]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
      October 1996.
 [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [7]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Levkowetz & Vaarala Standards Track [Page 31] RFC 3519 NAT Traversal for Mobile IP April 2003

 [8]  Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
      "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
 [9]  Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC
      3024, January 2001.
 [10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
      2002.

12. Informative References

 [11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
      (NAT) Terminology and Considerations", RFC 2663, August 1999.
 [12] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
      Translator (Traditional NAT)", RFC 3022, January 2001.
 [13] Daigle, L., Editor, and IAB, "IAB Considerations for UNilateral
      Self-Address Fixing (UNSAF)", RFC 3424, November 2002.

Levkowetz & Vaarala Standards Track [Page 32] RFC 3519 NAT Traversal for Mobile IP April 2003

13. Authors' Addresses

 Henrik Levkowetz
 ipUnplugged AB
 Arenavagen 23
 Stockholm  S-121 28
 SWEDEN
 Phone: +46 708 32 16 08
 EMail: henrik@levkowetz.com
 Sami Vaarala
 Netseal
 Niittykatu 6
 Espoo  02201
 FINLAND
 Phone: +358 9 435 310
 EMail: sami.vaarala@iki.fi

Levkowetz & Vaarala Standards Track [Page 33] RFC 3519 NAT Traversal for Mobile IP April 2003

14. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Levkowetz & Vaarala Standards Track [Page 34]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3519.txt · Last modified: 2003/05/15 15:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki