Network Working Group B. Sarikaya
Internet-Draft F. Xia
Intended status: Standards Track Huawei USA
Expires: December 6, 2010 June 4, 2010
NAT64 for Dual Stack Mobile IPv6
draft-sarikaya-behave-mext-nat64-dsmip-00.txt
Abstract
This memo specifies how IPv6 only mobile nodes (MN) receiving host-
based mobility management using Dual Stack Mobile IPv6 (DSMIPv6) can
communicate with IPv4 only servers. The protocol is based on home
agents maintaining a table similar to NAT64 and linking it to the
binding cache. This technique avoids the problems encountered when
NAT64 is used for mobile nodes in Dual Stack Mobile IPv6. How IPv6
only mobile nodes can receive multicast data from IPv4 only content
providers is also explained.
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 December 6, 2010.
Copyright Notice
Copyright (c) 2010 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
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
Sarikaya & Xia Expires December 6, 2010 [Page 1]
Internet-Draft NAT64 for DSMIPv6 June 2010
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. NAT64 Procedure . . . . . . . . . . . . . . . . . . . . . . . 5
5. Multicast Translation . . . . . . . . . . . . . . . . . . . . 6
6. Handover, Route Optimization and Return Routability . . . . . 7
7. Extensions to Dual Stack Mobile IPv6 . . . . . . . . . . . . . 8
7.1. Multicast Extensions . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative references . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Sarikaya & Xia Expires December 6, 2010 [Page 2]
Internet-Draft NAT64 for DSMIPv6 June 2010
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 host based mobility protocol called Dual Stack
Mobile IPv6. The design uses DNS64 as is and integrates NAT64
operation with the binding cache of Dual Stack Mobile IPv6.
The document continues in Section 3 with a set of requirements on a
solution for NAT64 for Dual Stack Mobile IPv6. In Section 4 the
protocol design is presented, multicast translation is explained in
Section 5 while handover and route optimization cases are covered in
Section 6. In Section 7 extensions to DSMIPv6 are described.
2. Terminology
This document uses the terminology defined in [RFC3775], [RFC5555],
[I-D.ietf-behave-v6v4-xlate-stateful] and [I-D.ietf-behave-dns64].
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 keep-
alives. DNS64 may use the IPv6 prefix assigned to the NAT64 IPv6
interface in the domain in translating IPv4 address of the server to
an IPv6 address. When the mobile node moves to a foreign network the
IPv6 prefix changes and as a result, the mobile node gets a different
IPv6 address for the same correspondent host it was communicating
before. However in Dual Stack Mobile IPv6, the mobile node is
anchored at the home agent which receives packets reverse tunneled
from the mobile node and sends them to their destinations. In this
case the packets from the home agent will likely not reach their
destination for properly translating into IPv4 packets and will get
dropped [I-D.haddad-mext-nat64-mobility-harmful].
Mobile nodes in Dual Stack Mobile IPv6 initiate route optimization
with the correspondent nodes when they move to a foreign network by
sending first a home test init (HoTI) message to the home agent.
This and subsequent messages (Care-of Test Init (CoTI), Home Test
Sarikaya & Xia Expires December 6, 2010 [Page 3]
Internet-Draft NAT64 for DSMIPv6 June 2010
(HoT) and Care-of Test (CoT)) contain IPv6 extension headers.
NAT64's translation algorithm [I-D.ietf-behave-v6v4-xlate] does not
translate IPv6 extension headers. As a result, HoTI and similar
messages would be rejected at the NAT64 device and the mobile node
would end up receiving an ICMP message. This fundamental restriction
of IPv6-IPv4 translation is avoided in this document by an additional
requirement not to initiate the route optimization with IPv4-only
servers.
NAT64 protocol should enable host mobility. This requirement is met
by redesigning NAT64 protocol so that the home agent 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 keepalives sent by the host are used for
this purpose [RFC3519]. Mobile nodes go to sleep mode when inactive
in which battery usage is minimized. However sending NAT keepalive
messages 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 home agent creates for the mobile node in order to keep track of
its mobility.
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.
The behaviour of IPv4-only or dual stack mobile nodes using host
based mobility protocol Mobile IPv6 is specified in [RFC5555].
However this document does not specify how IPv6-only mobile nodes can
access IPv4-only servers. Hence this specification complements
[RFC5555].
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 in a
dual stack Mobile IPv6 environment is a requirement. This
requirement is met by designing a multicast translation scheme for
Dual Stack Mobile IPv6. This technique applies to any source
multicast.
Sarikaya & Xia Expires December 6, 2010 [Page 4]
Internet-Draft NAT64 for DSMIPv6 June 2010
4. NAT64 Procedure
Mobile nodes reverse tunnel their packets to the home agent when
roaming and at the home network the home agent is the default router.
When forwarding packets sent by the mobile node, the home agent first
checks the Source Address field of the inner header in the binding
cache to find the corresponding binding cache entry for this mobile
node's home address. A further check is made if the destination
address's prefix matches Pref64. 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.
Home agent generates an IPv4 packet and sends it to the destination
IPv4-only server from its IPv4 interface. We assume that IPv4
interface address is 203.0.113.1 as in
[I-D.ietf-behave-v6v4-xlate-stateful]. As in
[I-D.ietf-behave-v6v4-xlate-stateful], home agent selects an
available source port, e.g. 2000 which becomes IPv4 packet source
port and 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. In
generating IPv4 packet, destination IPv4 address is derived from the
the last 32 bits of destination address of IPv6 packet, e.g.
192.0.2.1 and destination port of IPv6 packet is set to the
destination port of IPv4 packet. IPv6 packet is translated into an
IPv4 packet following the algorithm presented in
[I-D.ietf-behave-v6v4-xlate].
When forwarding any subsequent packets for the same session
corresponding to <MN source address, source port>, home agent finds
the corresponding entry in the NAT table and creates the
corresponding IPv4 packet using this entry. The above procedure is
repeated only when a new session is started by MN.
When home agent receives a packet addressed to its IPv4 interface it
searches the NAT table for the corresponding MN home 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. Home agent creates an IPv6 packet from IPv4 packet using
this information and the translation algorithm
[I-D.ietf-behave-v6v4-xlate]. Next home agent fetches MN's binding
cache entry and finds the mobile node's care-of address. Home agent
encapsulates IPv6 packet following [RFC3775] and sends it to the
mobile node.
Sarikaya & Xia Expires December 6, 2010 [Page 5]
Internet-Draft NAT64 for DSMIPv6 June 2010
5. Multicast Translation
In this section we specify how mobile node can receive IPv4 multicast
data from IPv4-only content provider based on the current multicast
support scheme in Dual Stack Mobile IPv6 [RFC3775].
IPv6-only mobile node will join IPv4 multicast group by sending MLD
Membership Report message to the home agent. This message is sent in
the mobile node-home agent tunnel. 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 home agent
receives this join message from the mobile node for the group
IPV6_TRASM_ADDRESS prefix:a.b.c.d.
Each home agent 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.
Home agent 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, home agent joins a.b.c.d using IGMP on its IPv4
interface.
Home agent identifies the mobile node from the tunnel and adds the
multicast group address to the multicast state associated with this
node's binding cache entry. Home agent also sets IPv6-only bit if it
was not set before.
When home agent 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 at least one mobile node is subscribed to this
address from the binding cache and multicast state. Home agent 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. IPv4 payload is copied
into IPv6 payload. Home agent duplicates the packet for each mobile
node member of this group and sends each packet tunneled to the
individual mobile node separately.
Multicast translation described in this section is not mobile node
agnostic. Home agent gets the join message directly from the mobile
node and then updates the membership database which is connected to
Sarikaya & Xia Expires December 6, 2010 [Page 6]
Internet-Draft NAT64 for DSMIPv6 June 2010
the binding cache. Home agent has to know all members of each IPv4
group so that it can correctly duplicate the data packets and tunnel
to individual mobile nodes.
6. Handover, Route Optimization and Return Routability
In Dual Stack Mobile IPv6, when the mobile node leaves home it gets a
care-of address and registers this address with its home agent. 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 and MN initiates
communication with IPv4-only server, it gets a different synthetic
AAAA RR with a different IPv6 address of the destination. MN reverse
tunnels its IPv6 packet destined to IPv4-only server to the home
agent.
Home agent checks the source address (mobile node's home address) of
the inner header in the binding cache for any entry with IPv6-only
flag set. Next destination address's prefix is checked in a list of
Pref64's that are supported. In case of a match, home agent
continues to create an IPv4 packet as described in Section 4. In
addition home agent also removes all NAT table entries matching MN
home address since MN is no longer using the same Pref64. If IPv6-
only flag is not set then this is the first packet sent to a new
IPv4-only server. Home agent processes this packet as described in
Section 4.
The effect of handover on multicast translation described in
Section 5 to handover depends on how IPV6_TRASM_ADDRESS prefix is
configured. Mobile node may get a different IPV6_TRASM_ADDRESS
prefix locally after moving to a foreign network. Mobile node sends
a join request (Multicast Listener Discovery Report message) with a
new multicast group address to the home agent in a tunnel. Home
agent adds this group address to its membership database. Home agent
MUST add the new IPV6_TRASM_ADDRESS prefix to the multicast prefix
table. Home agent MUST set IPv6-only flag in the binding cache for
this mobile node.
Route optimization (RO) in DSMIPv6 is used to avoid triangular route
every packet to the corresponding node takes by enabling the mobile
node to directly send the packets to the correspondent node
[RFC3775]. RO is established using control signaling involving the
home agent, mobile node and correspondent node. After RO is
established mobile node sends its packets directly to the
Sarikaya & Xia Expires December 6, 2010 [Page 7]
Internet-Draft NAT64 for DSMIPv6 June 2010
correspondent node. The source address of these packets are the
care-of address and MN home address is included in an extension
header called home address option. All RO packets involve extension
headers.
Because all route optimization packets (signaling and data) contain
extension headers the translation algorithm
[I-D.ietf-behave-v6v4-xlate] used in NAT64 would simple ignore the
data included in these headers. As a result, route optimization can
not even be initiated. This point is also observed in
[I-D.haddad-mext-nat64-mobility-harmful]. IPv6 only mobile nodes
involved in communication with IPv4-only servers MUST NOT use route
optimization. This ensures that all traffic between the mobile node
and corresponding node goes through the home agent and correct IPv6-
IPv4 packet translation can be conducted.
7. Extensions to Dual Stack Mobile IPv6
Binding cache entry contains the following new entry:
A flag indicating whether or not this mobile node is IPv6-only node.
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.
Home agent keeps a NAT table for IPv6-only mobile nodes communicating
with IPv4-only servers. NAT table contains at a minimum entries for
associating MN home address, IPv6 source port to the corresponding
IPv4 interface address of the home agent and source port information.
MN home address in the NAT table MUST correspond to a binding cache
entry with IPv6-only flag set.
Home agent has a table of NAT64 prefixes, Pref64 that are supported
in Dual Stack Mobile IPv6 home domain and its roaming partners. For
each Pref64, home agent 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.
IPv6-only mobile nodes MUST avoid initiating return routability
procedure described in Section 5.2.5 of [RFC3775]. When the home
agent receives a Home Test Init message, it checks the source address
Sarikaya & Xia Expires December 6, 2010 [Page 8]
Internet-Draft NAT64 for DSMIPv6 June 2010
(mobile node's home address) in the binding cache. If the
corresponding binding cache entry has its IPv6-only flag set home
agent drops the Home Test Init message.
7.1. Multicast Extensions
Multicast anchor at the home agent MUST support at least one
IPV6_TRASM_ADDRESS prefix. Multicast anchor at the home agent MUST
support IGMP on its IPv4 interface.
Home agent has a table of IPV6_TRASM_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.
8. Security Considerations
For IPv4-only or dual stack mobile nodes security considerations
stated in [RFC5555] apply. This document specifies procedures for
MIPv6 [RFC3775] for the case of IPv6-only mobile nodes which are not
covered in [RFC5555]. Security considerations for IPv4 interface of
the home agent is similar to [I-D.ietf-behave-v6v4-xlate-stateful]
and the considerations stated there apply.
9. IANA Considerations
None.
10. Acknowledgements
TBD.
11. References
11.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]
Sarikaya & Xia Expires December 6, 2010 [Page 9]
Internet-Draft NAT64 for DSMIPv6 June 2010
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-11 (work in
progress), March 2010.
[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-09 (work in progress), March 2010.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-20 (work in
progress), May 2010.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
11.2. Informative references
[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.venaas-behave-mcast46]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator",
draft-venaas-behave-mcast46-01 (work in progress),
July 2009.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
Sarikaya & Xia Expires December 6, 2010 [Page 10]
Internet-Draft NAT64 for DSMIPv6 June 2010
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 December 6, 2010 [Page 11]