Network Working Group X. Xu
Internet Draft Huawei
Intended status: Informational
Expires: January 2010 July 13, 2009
Transition Mechanisms for
Routing Architecture for the Next Generation Internet (RANGI)
draft-xu-rangi-proxy-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Xu Expires January 13, 2010 [Page 1]
Internet-Draft Transition Mechanisms for RANGI July 2009
Abstract
The Routing Architecture for the Next Generation Internet (RANGI)
described in [RANGI] is a proposal for solving routing scalability,
mobility, multihoming, traffic engineering and other issues facing
the current Internet. This document describes some transition
mechanisms for the RANGI. With these mechanisms, legacy IPv4 and IPv6
hosts can communicate with RANGI hosts, and vice versa.
Table of Contents
1. Introduction..................................................3
2. Transition Mechanisms.........................................3
2.1. Communication between IPv6 and RANGI with Site Proxy.....3
2.1.1. IPv6 Hosts Communicate with RANGI Hosts.............4
2.1.2. RANGI Hosts Communicate with IPv6 Hosts.............5
2.2. Communication between IPv6 and RANGI without Site Proxy..6
2.3. Communication between IPv4 and RANGI with Site Proxy.....6
2.3.1. IPv4 Hosts Communicate with RANGI Hosts.............7
2.3.2. RANGI Hosts Communicate with IPv4 Hosts.............8
2.4. Communication between IPv4 and RANGI without Site Proxy..9
3. Security Considerations.......................................9
4. Acknowledgments...............................................9
5. References....................................................9
5.1. Normative References.....................................9
5.2. Informative References...................................9
Author's Addresses...............................................9
Xu Expires January 13, 2010 [Page 2]
Internet-Draft Transition Mechanisms for RANGI July 2009
1. Introduction
The Routing Architecture for the Next Generation Internet (RANGI)
described in [RANGI] is designed to address several issues that the
current Internet is facing, e.g., routing scalability, mobility,
multi-homing and traffic-engineering etc.
RANGI is a kind of id/locator split proposal which inserts an ID
layer in the middle of the network layer and the transport layer. It
introduces 128-bit long host identifiers which consist of two parts.
The first part is the Administrative Domain Identifier (AD ID) which
has organizational structure and global uniqueness, and the second
part is a cryptographic hash over the AD ID and the public key of the
host. The locators in RANGI are provider-assigned IPv6 addresses with
local IPv4 addresses embedded in the last four octets. In order to
distinguish identifiers from IPv6 addresses, identifiers are
associated with a specific prefix, which is to be allocated by IANA.
The mappings from FQDN to identifier are stored in the Domain Name
Service (DNS) system, whereas the mappings from identifier to locator
are stored in other distributed mapping system (e.g., hierarchical
Distributed Hash Table (DHT) system, reverse DNS system etc.). Since
the identifiers are as long as IPv6 addresses, they can be stored
directly in DNS servers as AAAA resource records (RR).
As specified in [Goals], incremental deployability is one of the
design goals for a new routing and addressing architecture. Thus, in
this document, we define several transition mechanisms for the RANGI
with which legacy IPv4 and IPv6 hosts can communicate with RANGI
hosts, and vice versa. Note that the Application Layer Gateway (ALG)
used for transforming the address information in application layers
is not specified in this document.
2. Transition Mechanisms
2.1. Communication between IPv6 and RANGI with Site Proxy
As mentioned previously, RANGI hosts can store their identifiers as
AAAA resource records in the DNS system. Thus, when legacy IPv6 hosts
make DNS query for RANGI hosts, identifiers are returned as AAAA
resource records in the DNS responses and are treated by legacy hosts
as IPv6 addresses.
As illustrated in Figure 1, host A is a legacy IPv6 host, host B is a
RANGI host, and a proxy is located at the edge of the IPv6 site
network for host A. This so-called site proxy maintains an Identifier
(ID)/Locator mapping table which is used to transform IPv6 packets to
RANGI packets and vice versa. In the remainder of this document, the
Xu Expires January 13, 2010 [Page 3]
Internet-Draft Transition Mechanisms for RANGI July 2009
mapping table refers to the ID/Locator mapping table, and the proxy
refers to the site proxy unless mentioned otherwise.
+-------------------------+ +-------------------------+
| +--------+ +-+-----+ | +--------+ |
| | A +--------- --+ Proxy +-----+----------+ B | |
| +--------+ +-+-----+ | +--------+ |
| | | |
| IPv6 Site Network | | Internet |
+-------------------------+ +-------------------------+
Figure 1. Communication between IPv6 and RANGI hosts
If the packets transported between the proxy and host B need to be
secured in IPsec tunnels, the proxy needs to assign each legacy IPv6
host a globally unique secure identifier (associated with a
public/private key pair). Otherwise, Provider-Independent (PI) IPv6
addresses of the legacy IPv6 hosts can be used as identifiers
directly.
2.1.1. IPv6 Hosts Communicate with RANGI Hosts
Assume host A attempts to initiate a communication with host B. Host
A performs a DNS lookup for host B's IPv6 address, and the identifier
of host B is returned as an AAAA resource record. Then host A
constructs IPv6 packets with destination IPv6 addresses being host
B's identifier.
We assume here that the proxy has announced into the IPv6 site
network an IPv6 route to the identifier-specific prefix. Hence the
packets from the site with destination IPv6 addresses being
identifiers can be forwarded towards the proxy. Upon receiving the
packets, the proxy attempts to determine the identifier corresponding
to the source IPv6 address in its mapping table. If not found, the
proxy should assign a temporary identifier for host A and store the
mapping from this identifier to host A's IP address in its mapping
table (as illustrated in Figure 2).
+------------+------------+------------+---------+
|IPv6 Address| Identifier | Locator | TTL(s) |
+------------+------------+------------+---------+
| IPv6(A) | Temp ID(A) | | 20 |
+------------+------------+------------+---------+
| ... | ... | ... | ... |
+------------+------------+------------+---------+
Figure 2. ID/locator Mapping Table
Xu Expires January 13, 2010 [Page 4]
Internet-Draft Transition Mechanisms for RANGI July 2009
Meanwhile, the proxy also attempts to find host B's locator in its
mapping table. If not found, it performs a lookup through the
ID/locator mapping system. Once resolution succeeds, the proxy caches
the ID/locator mapping information in its mapping table and
transforms the IPv6 packets into RANGI packets (see Figure 3).
Otherwise, the packets will be delayed or dropped.
+--------------------------+
| Transport |
+-----------------------------+ +-------------+------------+
| Transport | | Dest_ID | Src_ID |
+--------------+--------------+ +-------------+------------+
| Dest_IP | Src_IP | <----> |Dest_Locator |Src_Locator |
+--------------+--------------+ +-------------+------------+
| Data Link | | Data Link |
+-----------------------------+ +--------------------------+
IPv6 Packet RANGI Packet
Figure 3. Packet Header Translation
As depicted in Figure 3, the source identifier in RANGI packets is
host A's temporary identifier, the destination identifier is host B's
identifier, the source locator is one of the proxy's locators, and
the destination locator is host B's locator.
After receiving the packets, host B sends response packets back. Once
the response packets arrive at the proxy, they are transformed into
IPv6 packets according to the existing mapping entry in the mapping
table. In the IPv6 packets, the source address is host B's identifier,
and the destination address is host A's IPv6 address.
2.1.2. RANGI Hosts Communicate with IPv6 Hosts
In order to make the legacy IPv6 hosts in the site network accessible
to the RANGI hosts, the proxy should assign each of these IPv6 hosts
a globally unique identifier and store the mappings of the identifier
and the corresponding IPv6 address in its mapping table. The
identifiers should also be stored in the DNS system as AAAA resource
records of the corresponding DNS entries. Moreover, the mappings from
identifiers to one of the proxy's locators should also be registered
in the ID/locator mapping systems.
Before initiating a communication with host A, host B needs to
perform a DNS lookup and gets host A's identifier as an AAAA resource
record. Then B obtains host A's locator (the proxy's locator in fact)
from the ID/locator mapping system. After that, host B constructs
RANGI packets and sends them out.
Xu Expires January 13, 2010 [Page 5]
Internet-Draft Transition Mechanisms for RANGI July 2009
Upon receiving the RANGI packets, the proxy finds the IPv6 address of
host A in its mapping table according to the destination identifier
(host A's identifier) of these packets, and caches the identifier and
locator of host B in its mapping table. Then the proxy transforms
these RANGI packets into IPv6 packets. In the IPv6 packets, the
source IPv6 address is host B's identifier, while the destination
IPv6 address is host A's IPv6 address.
When A receives the packets, it sends response packets back. Upon
receiving the response packets, the proxy transforms the IPv6 packets
into RANGI packets according to the corresponding mapping entries.
2.2. Communication between IPv6 and RANGI without Site Proxy
At the early stage of transition, it is un-reasonable to assume that
all sites can deploy proxies for legacy IPv6 hosts at the same time.
Hence, to facilitate the IPv6 hosts within non-proxy site networks to
initiate communication with RANGI hosts, a candidate solution is to
deploy a group of special proxies in the transit network. In order to
distinguish these proxies located in transit networks from those site
proxies deployed at the edge of the site networks, they are called
transit proxies in the reminder of this document. Each of the transit
proxies takes charge of a certain range of host IDs and needs to
announce into the transit network a route to a specific prefix
representing the host ID range which it takes charge of. Except of
the above differences, the transit proxies have no other difference
from the site proxies.
For RANGI hosts to initiate communications with those hosts within
the non-proxy site network, once the RANGI hosts determine the
identifiers (e.g., AAAA records in DNS response) for destination
hosts are IPv6 addresses, rather than real identifiers, they will
initiate communications with these destination hosts in a traditional
IPv6 fashion.
2.3. Communication between IPv4 and RANGI with Site Proxy
The translation process between IPv4 packets and RANGI packets is a
bit more complex than that between IPv6 packets and RANGI packets. As
illustrated in Figure 4, Host A is a legacy IPv4 host, and host B is
a RANGI host. A proxy is located as an exit border router at the edge
of the IPv4 site network for host A.
Xu Expires January 13, 2010 [Page 6]
Internet-Draft Transition Mechanisms for RANGI July 2009
+-------------------+ +--------------------+
|+------+ +--+----+ | +------+ |
|| A +--------+ Proxy +---+-----------+ B | |
|+------+ +--+----+ | +------+ |
| | | |
| IPv4 Site Network | | Internet |
+-------------------+ +--------------------+
Figure 4. Communication between IPv4 and RANGI Hosts
In order to establish security communication channel with RANGI hosts,
the proxy needs to assign each legacy IPv4 host in its network a
globally unique secure identifier (associated with a public/private
key pair). Then the packets transported between the proxy and RANGI
hosts can be secured using the IPsec protocol. Note that if there is
no need of security, the proxy could use the synthesized IPv6
addresses of IPv4 hosts (e.g., combinations of a specific /96 IPv6
prefix and their IPv4 address) as their identifiers.
2.3.1. IPv4 Hosts Communicate with RANGI Hosts
Before initiating a communication with host B, host A performs a DNS
lookup for host B's IPv4 address. The DNS request would travel from
IPv4 site network towards the DNS server S in the RANGI network. Upon
receiving the DNS request, the proxy transforms the "A" record in the
DNS message to an "AAAA" record, and then translates this IPv4 packet
into a RANGI packet according to an already-configured mapping entry
for the DNS server S.
+------------+------------+------------+---------+
|IPv4 Address| Identifier | Locator | TTL(s) |
+------------+------------+------------+---------+
| IPv4(S) | ID(S) | Loc(S) | -- |
+------------+------------+------------+---------+
| ... | ... | ... | ... |
+------------+------------+------------+---------+
Figure 5. ID/locator Mapping Table
The identifier of host B is transported as an AAAA resource record in
the DNS response. Upon receiving the response message, the proxy
obtain host B's identifier, allocates host B a temporary IPv4 address
from its local IPv4 address pool, and caches the mapping of host B's
identifier and IPv4 address in its mapping table. In addition, the
proxy replaces the AAAA record in DNS response as an A record with
the temporary IPv4 address filled in and sends this modified DNS
response message to the DNS resolver. In addition, the proxy resolves
Xu Expires January 13, 2010 [Page 7]
Internet-Draft Transition Mechanisms for RANGI July 2009
host B's locator from the ID/locator mapping system. Once the
resolution succeeds, the proxy caches the mapping in its mapping
table. Optionally, the proxy could assign a temporary identifier for
host A and cache the binding of this identifier, host A's IPv4
address and one of the proxy's locator in its mapping table. Of
course, this action can also be performed when data packets (other
than DNS messages) are received from host A.
Once the DNS resolution succeeds, host A constructs IPv4 packets and
sends them out. Upon receiving these packets, the proxy translates
them to RANGI packets according to the existing mapping entries in
its mapping table.
When the response packets are received, the proxy transforms them
into IPv4 packets accordingly.
2.3.2. RANGI Hosts Communicate with IPv4 Hosts
In order to make IPv4 hosts in the site network accessible to RANGI
hosts, the proxy should assign each of the IPv4 hosts in its site
network a globally unique identifier, and store the bindings of the
identifiers and the corresponding IPv4 addresses in its mapping table.
In addition, these identifiers should also be stored in the DNS
system as AAAA resource records of the corresponding IPv4 hosts (of
course, this can also be implemented by using DNS-ALG on the proxy to
translate between the "A" and the "AAAA" records in the DNS messages).
The proxy also stores these identifiers and one of the proxy's
locators in the ID/locator mapping system.
Before initiating a communication with host A, host B obtains host
A's identifier and locator from the DNS system and the ID/locator
mapping system respectively. With such information, host B constructs
RANGI packets and sends them out.
Upon receiving these packets, the proxy allocates host B a temporary
IPv4 address from its local IPv4 address pool, and cache the binding
of host B's identifier, locator and the temporary IPv4 address in its
mapping table. After doing this, the proxy would transform the RANGI
packets into IPv4 packets according to the existing mapping entries
in its mapping table.
Subsequently, the proxy can also translate the response IPv4 packets
into RANGI packets according to the mapping entries.
Xu Expires January 13, 2010 [Page 8]
Internet-Draft Transition Mechanisms for RANGI July 2009
2.4. Communication between IPv4 and RANGI without Site Proxy
For IPv4 hosts within non-proxy site networks to communicate with
RANGI hosts, one can use the IPv4->IPv6 translation (e.g., NAT-PT
[RFC2766]) and the transit proxy mechanism together to realize two-
stage translation. For RANGI hosts to communicate with IPv4 hosts
within non-proxy site networks, one can just use the IPv6->IPv4
translation scheme.
3. Security Considerations
TBD.
4. Acknowledgments
The author would like to thank Raj Jain and Dacheng Zhang for their
valuable comments and reviews.
5. References
5.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
[Goals] T. Li, "Design Goals for Scalable Internet Routing", draft-
irtf-rrg-design-goals-01, July 2007.
[RANGI] X. Xu, "Routing Architecture for the Next Generation
Internet (RANGI), draft-xu-rangi-01, July 2009.
[RFC2766] G. Tsirtsis, and P. Srisuresh, "Network Address Translation
- Protocol Translation (NAT-PT)", RFC 2766, February 2000.
Author's Addresses
Xiaohu Xu
Huawei Technologies,
No.3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District, Beijing 100085, P.R. China
Phone: +86 10 82836073
Email: xuxh@huawei.com
Xu Expires January 13, 2010 [Page 9]