[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                        B. Sarikaya
Internet-Draft                                                    F. Xia
Intended status: Standards Track                              Huawei USA
Expires: July 29, 2011                                  January 25, 2011


                      NAT64 for Proxy Mobile IPv6
             draft-sarikaya-behave-netext-nat64-pmip-01.txt

Abstract

   This memo specifies modifications required to Mobile Access Gateway
   and Local Mobility Anchor to integrate NAT64 with Proxy Mobile IP so
   that mobile nodes (MN) receiving network-based mobility management
   using Proxy Mobile IPv6 (PMIPv6) can communicate with IPv4 only
   servers.  The protocol is based on local mobility anchors maintaining
   a table similar to NAT64 and linking it to the binding cache.  The
   changes include better keepalive management in order to preserve
   battery on the mobile node as well as multicast support for NAT64
   integrated into the current multicast support scheme in Proxy Mobile
   IPv6 so that IPv6 only mobile nodes can receive multicast data from
   IPv4 only content providers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 29, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Sarikaya & Xia            Expires July 29, 2011                 [Page 1]


Internet-Draft              NAT64 for PMIPv6                January 2011


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Unicast Translation  . . . . . . . . . . . . . . . . . . . . .  5
   5.  Multicast Translation  . . . . . . . . . . . . . . . . . . . .  7
   6.  Handover and Localized Routing . . . . . . . . . . . . . . . .  9
   7.  Extensions to Proxy Mobile IPv6  . . . . . . . . . . . . . . . 10
     7.1.  Multicast Extensions . . . . . . . . . . . . . . . . . . . 10
   8.  Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     12.2. Informative references . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

























Sarikaya & Xia            Expires July 29, 2011                 [Page 2]


Internet-Draft              NAT64 for PMIPv6                January 2011


1.  Introduction

   With IPv4 address depletion on the horizon, many techniques are being
   standardized for IPv6 migration including NAT64
   [I-D.ietf-behave-v6v4-xlate-stateful].  NAT64 together with DNS64
   [I-D.ietf-behave-dns64] enables IPv6-only hosts to communicate with
   IPv4-only servers.

   NAT64 is designed for fixed hosts.  When used for mobile nodes
   several problems occur as described in
   [I-D.haddad-mext-nat64-mobility-harmful].  In this document we
   redesign NAT64 for network based mobility protocol called Proxy
   Mobile IPv6.  The design uses DNS64 as is and integrates NAT64
   operation with the binding cache of Proxy Mobile IPv6.

   The document continues in Section 3 with a set of requirements on a
   solution for NAT64 for Proxy Mobile IPv6.  In Section 4 the protocol
   design is presented, multicast translation is explained in Section 5
   while handover and localized routing cases are covered in Section 6
   for unicast.  In Section 7 extensions to PMIPv6 are described.


2.  Terminology

   This document uses the terminology defined in [RFC5213],
   [I-D.ietf-behave-v6v4-xlate-stateful], [I-D.ietf-behave-dns64],
   [I-D.ietf-behave-v6v4-xlate], [RFC6052] and [RFC5844].


3.  Requirements

   NAT64 has two main problems if used for the mobile nodes: the first
   one is related to mobility and the second one is related to NAT
   keepalives.

   DNS64 uses the IPv6 prefix assigned to the NAT64 IPv6 interface in
   the domain in translating IPv4 address of the server to an IPv6
   address.  This prefix will be referred to as Pref64 as in
   [I-D.ietf-behave-v6v4-xlate-stateful].  [RFC6052] defines two types
   of prefixes: Well-Known Prefix or Network-Specific Prefix.  If the
   well-known prefix of 64:FF9B::/96 is used then the mobile node would
   always get the same mapping wherever it moves so no problems can be
   anticipated.  However, for various reasons this is not expected to be
   the case in general.

   If Network-Specific Prefixes (NSP) are used problems called prefix
   mismatch problem can be anticipated especially for mobile nodes
   [I-D.korhonen-behave-nat64-learn-analysis].  This happens because



Sarikaya & Xia            Expires July 29, 2011                 [Page 3]


Internet-Draft              NAT64 for PMIPv6                January 2011


   DNS64 server used by the mobile node may use a different NSP that
   NAT64 box is not configured with.

   When the mobile node moves to a different domain, the mobile node
   sends DNS requests to the new MAG.  The new MAG forwards the request
   to the DNS server in the visited domain.  This case poses problems
   because NSP in the IPv6 address synthesized by the local DNS64 is not
   recognized by the home domain NAT64 server, i.e. its interface is not
   configured with this NSP.  In this case the mobile node's IPv6 packet
   may not reach the destination IPv4-only server.

   NAT64 protocol should enable host mobility and should avoid the
   prefix mismatch problem.  This requirement is met by redesigning
   NAT64 protocol so that the local mobility anchor which keeps track of
   the host's mobility knows about all prefixes used.

   NAT64 is a NAT device which keeps NAT table as the NAT state.  NAT
   state is soft state and it expires if it is not refreshed during a
   certain time interval.  NAT devices delete existing bindings at the
   end of a time interval if no activity is detected during that
   interval.  Timer values of a minimum of two and maximum of five
   minutes for UDP [RFC4787] and 2 hours and four minutes [RFC2663] for
   TCP [RFC5382] are recommended [I-D.ietf-behave-v6v4-xlate-stateful].
   However, existing NAT devices are known to have non-deterministic and
   typically short expiration times especially for UDP-based bindings.

   Outbound refresh (mobile node initiated) is necessary for allowing
   the client (mobile node) to keep the mapping alive.  NAT keepalives
   are used for this purpose [RFC5245].  Mobile nodes go to sleep mode
   when inactive in which battery usage is minimized.  However sending
   NAT keepalive messages for outbound refresh may drain the mobile
   node's battery because it has to cut short its sleep mode.

   NAT keepalives should be avoided for the mobile nodes.  This
   requirement is met by integrating NAT64 state with binding cache that
   the local mobility anchor creates for the mobile node in order to
   keep track of its mobility and by having the local mobility anchor to
   refresh NAT binding with the NAT device.

   While resolving issues of NAT64 related to mobility, it is desirable
   to keep compatibility with fixed hosts.  This requirement is met by
   reusing DNS64 for mobile nodes as well.

   NAT64 translates IPv6 packet into IPv4 packet and vice versa and the
   translation algorithm is defined in [I-D.ietf-behave-v6v4-xlate].
   However translation algorithm is deficient in that IPv6 extension
   headers (except fragmentation header) and IPv4 options are not
   translated.  Proxy Mobile IPv6 uses extension header in registration



Sarikaya & Xia            Expires July 29, 2011                 [Page 4]


Internet-Draft              NAT64 for PMIPv6                January 2011


   signaling using PBU/PBA messages.  PBU/PBA are exchanged between MAG
   and LMA and not between mobile node and correspondent node.  Because
   of this the deficiency is avoided.

   The behaviour of IPv4-only or dual stack mobile nodes using network
   based mobility protocol Proxy Mobile IPv6 is specified in [RFC5844].
   However this document does not specify how IPv6-only mobile nodes can
   access IPv4-only servers.  Hence this specification complements
   [RFC5844].

   NAT64 is designed for unicast communication, the translation
   algorithm is defined in [I-D.ietf-behave-v6v4-xlate] does not
   translate multicast packets.  IPv6 only hosts receiving multicast
   data from IPv4 only servers is not covered.

   For many applications multicast communication for mobile nodes is a
   requirement.  This requirement is met by designing a multicast
   translation scheme for Proxy Mobile IPv6.  This technique applies to
   any source multicast as well as source specific multicast.


4.  Unicast Translation

   This section discusses extensions to NAT64 to support mobility.
   Multicast extensions are discussed next in Section 5.  It is assumed
   that NAT64 and LMA can be hosted in different machines, however it is
   also possible that LMA and NAT64 coexist in the same node.

   When forwarding packets sent by the mobile node, the local mobility
   anchor first checks the Source Address field in the binding cache.  A
   further check is made if the destination address's prefix matches
   Pref64 in the prefix table.  In case of a match, IPv6-only flag in
   the binding cache entry for the mobile node is set if it was not set
   already.

   If NAT64 and LMA are collocated, LMA creates a "NAT state" of

   <MN source address, IPv6 source port> <--> <IPv4 Interface address,
   IPv4 source port> This state is linked to the binding cache entry for
   MN.

   To this NAT state this specification adds keepalive interval K which
   is used to make sure LMA/NAT64 initiates NAT64 keepalives.  MN does
   not have to shorten the time it spends in dormant state and drain its
   battery.

   Translation into IPv4 packet takes place at the NAT64 server.  If
   NAT64 server is collocated then the local mobility anchor translates



Sarikaya & Xia            Expires July 29, 2011                 [Page 5]


Internet-Draft              NAT64 for PMIPv6                January 2011


   IPv6 packet into an IPv4 packet following the algorithm presented in
   [I-D.ietf-behave-v6v4-xlate].

   LMA (collocated with NAT64 or not) keeps IPv6-only flag and Pref64 in
   the binding cache.  This state is linked to the binding cache entry
   for MN.  The home agent forwards IPv6 packet towards NAT64 server.

   When forwarding any subsequent packets for the same session
   corresponding to <MN source address, source port>, LMA finds the
   corresponding entry in the NAT table and creates the corresponding
   IPv4 packet using this entry.  The above procedure of new NAT64 state
   creation is repeated only when a new session is started by MN.

   In case of collocated LMA and NAT64, an incoming IPv4 packet is
   processed as follows: When LMA receives a packet addressed to its
   IPv4 interface it searches the NAT table for the corresponding MN
   IPv6 source address and port.  For example the tuple <203.0.113.1,
   2000> would match the network-specific prefix (NSP) of 2001:FF00::/64
   and the source port of 1500.  LMA creates an IPv6 packet from IPv4
   packet using this information.  IPv4 packet is translated into an
   IPv6 packet following the algorithm presented in
   [I-D.ietf-behave-v6v4-xlate].  Next LMA fetches MN's binding cache
   entry and finds the MAG MN is associated with.  LMA encapsulates IPv6
   packet and sends it to the MAG.

   If LMA and NAT64 are not collocated, NAT64 translates IPv4 packet and
   forwards to LMA as IPv6 packet.  LMA, after receiving the incoming
   IPv6 packet to the mobile node's home network, searches its binding
   cache and finds MN's attached MAG address (Proxy-CoA) and
   encapsulates the packet and sends it to MAG.  MAG decapsulates IPv6
   packet and forwards it to MN.

   Keepalive interval is used to send NAT keepalive messages.  NAT
   keepalive messages are ICMP Echo Request messages [RFC3519].  ICMPv6
   Echo Request message MUST be encoded with a UDP header.  The packet's
   destination address is the destination address associated with the
   keepalive interval.  The source address is MN's address.  Keepalive
   interval is used to keep track of inactivity of the mobile node's
   session with its NAT64 host, IPv4-only server.  UDP header contains
   the source and destination port numbers of NAT64 binding.  Any ICMP
   Echo Request message sent from the local mobility anchor serves as
   outbound refresh message for the session and any corresponding ICMP
   Echo Reply received serves as the inbound refresh.

   ICMPv6 Echo Request message encoded in UDP header is translated into
   ICMPv4 Echo Request message with UDP header at NAT64 server following
   translation rules defined in [I-D.ietf-behave-v6v4-xlate] since the
   UDP header preserves the source and destination port numbers that are



Sarikaya & Xia            Expires July 29, 2011                 [Page 6]


Internet-Draft              NAT64 for PMIPv6                January 2011


   needed in order to match with NAT64 binding.  An ICMPv4 Echo is sent
   to IPv4 only server as an IPv4 packet with UDP header.  IPv4 server
   replies with IPv4 Echo Reply which is translated into ICMPv6 Echo
   Reply message and received by the local mobility anchor.

   Keepalive interval of K seconds controls the frequency of keepalive
   messages.  K is a protocol constant with a default value.  The
   default value should be less that the timeout value used by the NAT
   server.  Because of this K can be set to the default value of 110
   seconds [RFC3519].

   Local mobility anchor forwards any subsequent packets for the same
   session corresponding to <MN source address, source port> and
   refreshes the keepalive interval.  Local mobility anchor does not do
   any inbound refresh.  Local mobility anchor MUST not forward ICMPv6
   Echo Reply message to MN.  Incoming packets for this session do not
   refresh the keepalive interval since it is the interval for outbound
   refresh.  It is up to IPv4 only server to do the inbound refreshes.


5.  Multicast Translation

   In this section we specify how mobile node can receive IPv4 multicast
   data from IPv4-only content provider based on currently adopted base
   solution for supporting multicast in Proxy Mobile IPv6
   [I-D.ietf-multimob-pmipv6-base-solution].

   IPv6-only mobile node will join IPv4 multicast group by sending MLD
   Membership Report message to MLD Proxy which is located at the mobile
   access gateway.  Mobile node will use synthesized IPv6 address of
   IPv4 multicast group address, e.g. a /96 prefix used for any source
   multicast called IPV6_TRASM_ADDRESS prefix followed by a.b.c.d, IPv4
   multicast group address.  IPV6_TRASM_ADDRESS prefix takes the form of
   FFxx::/96, it is non-SSM prefix [I-D.venaas-behave-mcast46].
   Multicast router at the local mobility anchor receives an aggregate
   join message from the mobile access gateway for the group
   IPV6_TRASM_ADDRESS prefix:a.b.c.d.

   Each local mobility anchor is assigned a unique IPV6_TRASM_ADDRESS
   prefix.  Mobile nodes can learn this value by means out of scope with
   this document.  With this, mobile node can easily create an IPv6
   multicast address from the IPv4 group address a.b.c.d that it wants
   to join.

   Local mobility anchor as multicast anchor checks the group address
   and recognizes IPV6_TRASM_ADDRESS prefix.  It next checks the last 32
   bits is an IPv4 multicast address in range 224/8 - 239/8.  If all
   checks succeed, local mobility anchor joins a.b.c.d using IGMP on its



Sarikaya & Xia            Expires July 29, 2011                 [Page 7]


Internet-Draft              NAT64 for PMIPv6                January 2011


   IPv4 interface.

   When local mobility anchor receives multicast data for the group
   a.b.c.d, it first obtains the IPv6 address IPV6_TRASM_ADDRESS prefix:
   a.b.c.d and then checks to see if it has any outgoing interfaces
   towards the mobile access gateway which happens when at least one
   mobile node is subscribed to this address.

   Local mobility anchor will then translate IPv4 multicast data packet
   into an IPv6 multicast data packet.  The destination address is IPv6
   group address IPV6_TRASM_ADDRESS prefix:a.b.c.d and source address is
   local mobility anchor's IPv6 interface address.  The value in Type of
   Service (TOS) field of IPv4 packet is copied into IPv6 Traffic Class
   field.  IPv4 Protocol and TTL fields are copied into IPv6 Next Header
   and Hop Limit fields respectively.  IPv4 payload is copied into IPv6
   payload.  UDP checksum is updated which completes the packet
   translation process [Thesis].  Local mobility anchor tunnels the
   packet to the mobile access gateway to which the mobile node is
   connected, i.e. to Proxy-CoA.  The mobile access gateway duplicates
   the packet and forwards to each MN based on the membership status of
   the multicast group IPV6_TRASM_ADDRESS prefix:a.b.c.d.

   Any IPv4 fragments sent by the routers must be translated into IPv6
   packets with IPv6 Fragment Header.  Fragmentation Offset field is
   copied into the corresponding field in the Fragment Header. 16-bit
   Identification field is copied into the low-order 16 bits of IPv6
   Fragment Header Identification field.  The high-order bits of the 32-
   bit IPv6 Fragment Header Identification field are set to zero.  More
   Fragments (MF) flag is copied to the corresponding field in IPv6
   Fragment Header [Thesis].

   Multicast translation described in this section is mobile node
   agnostic.  Local mobility anchor gets Multicast Listener Discovery
   messages from the proxy instance in one of the mobile access gateways
   when the membership database of the mobile access gateway changes.
   For the local mobility anchor it is sufficient to know if there is at
   least one member in the corresponding downstream Multicast Listener
   Discovery proxy instance and because of this local mobility anchor
   does not need to consult its binding cache.

   Source-Specific Multicast (SSM) can also be supported similar to the
   Any Source Multicast (ASM) described above.  In case of SSM, IPv4
   multicast addresses use 232.0.0.0/8 prefix and IPv6 multicast
   addresses use FF3X::/96 prefix.  A unique SSM prefix can be
   configured such as FF3E::/96.  This prefix is referred to as
   IPV6_TRSSM_ADDRESS prefix.  Since SSM translation requires a unique
   address for each IPv4 multicast source, an IPv6 unicast prefix must
   be configured to the translator to represent IPv4 sources.  This



Sarikaya & Xia            Expires July 29, 2011                 [Page 8]


Internet-Draft              NAT64 for PMIPv6                January 2011


   prefix is prepended to IPv4 source addresses in translated packets.
   Also this prefix must be routed towards the translator on the IPv6
   network, to enable reverse path forwarding for multicast, and to
   inform other PIM routers about the correct destination for PIM (S,G)
   Join messages [Thesis].


6.  Handover and Localized Routing

   In Proxy Mobile IPv6 mobile node is always at home, i.e. its home
   address does not change even if it moves.  If the move is within the
   same domain served by the same DNS64 entity the mobile node can
   continue to send/receive packets with IPv4 only server and the
   protocol defined in Section 4 can be used for translating IPv6
   packets into IPv4 and vice versa.

   If MN moves to a domain where DNS64 entity changes MN initiates
   communication with IPv4-only server, it gets a different synthetic
   AAAA RR with a different IPv6 address of the destination.  This
   creates a prefix mismatch problem.  MN sends its IPv6 packet to the
   local MAG which tunnels it to MN's LMA.

   LMA checks the source address (mobile node's home address) in the
   binding cache for any entry with IPv6-only flag set.  Next
   destination address' prefix is checked in the binding cache.  In case
   the prefix does not match, the destination address' prefix is checked
   in a list of Pref64's that are supported.  In case of a match, a new
   binding cache entry is added with the new Pref64.  LMA is responsible
   for routing the MN's packet with the new Pref64.  The packet may take
   a longer path or the packet may not even reach the destination due to
   a non existing roaming agreement with the foreign network.

   If the prefix does not match, local mobility anchor forwards the
   packet since this packet should be going to another IPv6 destination
   host.

   If IPv6-only flag is not set then this is the first packet sent to a
   new IPv4-only server.  LMA processes this packet as described in
   Section 4.

   The effect of handover on multicast translation depends on how
   IPV6_TRASM_ADDRESS prefix is configured.  Mobile node may get a
   different IPV6_TRASM_ADDRESS prefix locally after moving to a new
   mobile access gateway.  Mobile node sends a join request (Multicast
   Listener Discovery Report message) with a new multicast group
   address.  Local mobility anchor adds this group address to its
   membership database.  Local mobility anchor MUST add the new
   IPV6_TRASM_ADDRESS prefix to the multicast prefix table.



Sarikaya & Xia            Expires July 29, 2011                 [Page 9]


Internet-Draft              NAT64 for PMIPv6                January 2011


   Localized routing in PMIPv6 is used to avoid reverse tunneling every
   packet to local mobility anchor by enabling the MAG to directly send
   the packets to another MAG where the correspondent node for this
   mobile node is associated [I-D.ietf-netext-pmip-lr].  The other MAG
   may be connected to a different LMA.

   NAT64 for PMIPv6 is supported at the local mobility anchor not at the
   mobile access gateway so it would not work when localized routing is
   used.  Since NAT64 assumes that MN is communicating with IPv4-only
   servers these servers are not expected to be associated with any
   mobile access gateway in the domain.  This means that no trigger can
   be found to initiate localized routing for communication between the
   mobile node and IPv4-only server.


7.  Extensions to Proxy Mobile IPv6

   Binding cache entry contains the following new entry:

   A flag indicating whether or not this mobile node is IPv6-only node
   and Pref64, the prefix used to route NAT64 traffic to NAT64 server.

   IPv6-only flag is set after receiving the first IPv6 packet
   containing a synthetic IPv6 address.  This flag is used to connect
   the binding cache with the NAT table.

   Local mobility anchor has a table of NAT64 prefixes, Pref64 that are
   supported in PMIPv6 domain and its roaming partners.  For each
   Pref64, local mobility anchor keeps a 32-bit suffix which is
   concatenated to the prefix.  The resulting 96-bit value is
   concatenated with IPv4 address of the destination IPv4-only server to
   obtain the synthesized IPv6 address.

   If the Well-Known Prefix is used this table contains 64:FF9B::/96.
   In this case there is no associated suffix.

7.1.  Multicast Extensions

   Multicast anchor at the local mobility anchor MUST support at least
   one IPV6_TRASM_ADDRESS prefix and one IPV6_TRSSM_ADDRESS prefix.
   Multicast anchor at the local mobility anchor MUST support IGMP on
   its IPv4 interface.

   Local mobility anchor has a table of IPV6_TRASM_ADDRESS and
   IPV6_TRSSM_ADDRESS prefixes.  This table normally contains a single
   entry, i.e. the local prefix value.  It may be populated by more
   entries in case of handover as described in Section 6.  The entries
   are kept as soft-state and removed after a period of no activity.



Sarikaya & Xia            Expires July 29, 2011                [Page 10]


Internet-Draft              NAT64 for PMIPv6                January 2011


   Multicast anchor at the local mobility anchor MUST support at least
   one IPV6_TRSSM_ADDRESS prefix.  Multicast anchor at the local
   mobility anchor MUST support IGMPv3 on its IPv4 interface as source
   filtering needed for SSM is supported only by IGMPv3.


8.  Protocol Constants

   K 110 seconds (as defined in [RFC3519].


9.  Security Considerations

   For IPv4-only or dual stack mobile nodes security considerations
   stated in [RFC5844] apply.  This document specifies additional
   procedures PMIPv6 for the case of IPv6-only mobile nodes which are
   not covered in [RFC5844].  Security considerations for IPv4 interface
   of the local mobility anchor is similar to
   [I-D.ietf-behave-v6v4-xlate-stateful] and the considerations stated
   there apply.


10.  IANA Considerations

   None.


11.  Acknowledgements

   TBD.


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers",
              draft-ietf-behave-v6v4-xlate-stateful-12 (work in
              progress), July 2010.



Sarikaya & Xia            Expires July 29, 2011                [Page 11]


Internet-Draft              NAT64 for PMIPv6                January 2011


   [I-D.ietf-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
              "DNS64: DNS extensions for Network Address Translation
              from IPv6 Clients to IPv4 Servers",
              draft-ietf-behave-dns64-11 (work in progress),
              October 2010.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [I-D.ietf-behave-v6v4-xlate]
              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
              progress), September 2010.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

12.2.  Informative references

   [Thesis]   Teemu Kiviniemi, Helsinki University of Technology,
              Master's Thesis, "Implementation of an IPv4 to IPv6
              Multicast Translator", October 2009.




Sarikaya & Xia            Expires July 29, 2011                [Page 12]


Internet-Draft              NAT64 for PMIPv6                January 2011


   [I-D.haddad-mext-nat64-mobility-harmful]
              Haddad, W. and C. Perkins, "A Note on NAT64 Interaction
              with Mobile IPv6",
              draft-haddad-mext-nat64-mobility-harmful-01 (work in
              progress), April 2010.

   [I-D.ietf-netext-pmip-lr]
              Krishnan, S., Koodli, R., Loureiro, P., Wu, W., and A.
              Dutta, "Localized Routing for Proxy Mobile IPv6",
              draft-ietf-netext-pmip-lr-01 (work in progress),
              October 2010.

   [RFC3519]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
              Network Address Translation (NAT) Devices", RFC 3519,
              April 2003.

   [I-D.venaas-behave-mcast46]
              Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
              IPv4 - IPv6 multicast translator",
              draft-venaas-behave-mcast46-02 (work in progress),
              December 2010.

   [I-D.ietf-multimob-pmipv6-base-solution]
              Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in PMIPv6
              Domains", draft-ietf-multimob-pmipv6-base-solution-07
              (work in progress), December 2010.

   [I-D.korhonen-behave-nat64-learn-analysis]
              Korhonen, J. and T. Savolainen, "Analysis of solution
              proposals for hosts to learn NAT64 prefix",
              draft-korhonen-behave-nat64-learn-analysis-01 (work in
              progress), January 2011.


















Sarikaya & Xia            Expires July 29, 2011                [Page 13]


Internet-Draft              NAT64 for PMIPv6                January 2011


Authors' Addresses

   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org


   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com

































Sarikaya & Xia            Expires July 29, 2011                [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/