One document matched: draft-xu-rangi-proxy-00.txt
Network Working Group Xiaohu Xu
Internet Draft Huawei
Intended status: Informational Raj Jain
Expires: September 2009 Washington Univ. in St. Louis
March 4, 2009
A Transition Mechanism for
Routing Architecture for the Next Generation Internet (RANGI)
draft-xu-rangi-proxy-00.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 September 4, 2009.
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.
Abstract
The Routing Architecture for the Next Generation Internet (RANGI) is
a proposal for solving routing scalability, mobility, multihoming,
Xu and Jain Expires September 4, 2009 [Page 1]
Internet-Draft A Transition Mechanism for RANGI March 2009
traffic engineering and other issues facing the current Internet.
RANGI is described in a separate document [RANGI]. This document
describes a transition mechanism for RANGI. With this mechanism,
legacy IPv4 or IPv6 hosts can communicate with RANGI hosts, and vice
versa. This allows RANGI to be deployed incrementally in the current
Internet.
Table of Contents
1. Introduction.................................................3
2. Transition Mechanism.........................................3
2.1. Communication between IPv6 and RANGI Hosts..............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 IPv4 and RANGI Hosts..............6
2.2.1. IPv4 Hosts Communicate with RANGI Hosts............7
2.2.2. RANGI Hosts Communicate with IPv4 Hosts............7
3. Security Considerations......................................8
4. Conclusions..................................................8
5. References...................................................8
5.1. Normative References....................................8
5.2. Informative References..................................9
Author's Addresses..............................................9
Xu and Jain Expires September 4, 2009 [Page 2]
Internet-Draft A Transition Mechanism for RANGI March 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 hybrid proposal that combines and enhances the ideas from
several proposals particularly those based on identifier/locator
split approach. It introduces a hierarchical and cryptographic host
identifier and adopts a hierarchical routing mechanism to support
routing across multiple independent address spaces. To allow smooth
transition from IPv4 to IPv6, it adopts an IPv6 address with an IPv4
embedded in the last four bytes as locator.
RANGI uses a 128-bit host identifier, which consists 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 its public key as in
Cryptographically Generated Addresses (CGA)[CGA]. The locator is a
provider-assigned IPv6 address with local IPv4 address embedded in
the last four octets. The mapping from FQDN to identifier is stored
in Domain Name Service (DNS) system, whereas the mapping from
identifier to locator is stored in another mapping system (e.g.,
hierarchical Distributed Hash Table (DHT) system, reverse DNS system,
etc.). Since the identifier is as long as IPv6 address, it can be
stored directly in DNS servers as an AAAA resource record (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 a transition mechanism with which legacy
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.
In order to distinguish identifiers from ordinary IPv6 addresses and
locators, identifiers use a specific prefix, which is to be allocated
by IANA.
2. Transition Mechanism
2.1. Communication between IPv6 and RANGI Hosts
As mentioned previously, RANGI hosts can store their identifiers as
AAAA resource records in the DNS system. Thus, when a legacy IPv6
host makes a DNS query for a RANGI host, the identifier is returned
Xu and Jain Expires September 4, 2009 [Page 3]
Internet-Draft A Transition Mechanism for RANGI March 2009
as an AAAA resource record in the DNS response. This identifier is
processed by the legacy host as an IPv6 address.
As shown in Figure 1, A is a legacy IPv6 host, and B is a RANGI host.
The proxy is located as the exit border router in the IPv6 site, and
maintains an Identifier (ID)/Locator mapping table which is used
during the process of transforming IPv6 packets to RANGI packets and
vice versa. For the remainder of this document, the ID/Locator
mapping table is called mapping table for short.
+-------------------------+ +-------------------------+
| +--------+ +-+-----+ | +--------+ |
| | A +--------- --+ Proxy +-----+----------+ B | |
| +--------+ +-+-----+ | +--------+ |
| | | |
| IPv6 Site Network | | RANGI Site Network |
+-------------------------+ +-------------------------+
Figure 1. Communication between IPv6 and RANGI Networks
The basic idea is to make the proxy assign each legacy IPv6 host a
secure identifier (associated with a public/private key pair). Then
the packets between the proxy and the RANGI host can be secured in an
IPsec tunnel. It should be noted that if security is not required,
the Provider-Independent (PI) IPv6 address of the legacy IPv6 host
could be used as an identifier directly.
2.1.1. IPv6 Hosts Communicate with RANGI Hosts
Assume IPv6 Host A attempts to initiate a communication with RANGI
host B. Host A performs a DNS lookup for B's IPv6 address, and the
identifier of B is returned as an AAAA resource record. Then host A
constructs IPv6 packets with B's identifier as the destination IPv6
address.
We assume here that the proxy has advertised in the IPv6 site network
an IPv6 route to the identifier-specific prefixes. So the packets
with the identifier as the destination IPv6 address can reach the
proxy along that route. 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 A and store the mapping between A's IP
address and the identifier in its mapping table (as illustrated in
Figure 2).
Xu and Jain Expires September 4, 2009 [Page 4]
Internet-Draft A Transition Mechanism for RANGI March 2009
+------------+------------+------------+---------+
|IPv6 Address| Identifier | Locator | TTL(s) |
+------------+------------+------------+---------+
| IPv6(A) | Temp ID(A) | | 20 |
+------------+------------+------------+---------+
| ... | ... | ... | ... |
+------------+------------+------------+---------+
Figure 2. ID/locator Mapping Table
Meanwhile, the proxy also attempts to find B's locator in its mapping
table. If not found, it should perform a lookup through the
ID/locator mapping system. Once resolution succeeds, the proxy should
cache the ID/locator mapping information in its mapping table and
transform the 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
In Figure 3, the source identifier in RANGI packets is A's temporary
identifier, the destination identifier is B's identifier, the source
locator is one of the proxy's locators, and the destination locator
is B's locator.
After receiving the packets, B sends response packets back. Once the
response packets arrive at the proxy, the proxy transforms these
packets into IPv6 packets according to the mapping entries in its
mapping table. In the IPv6 packets, the source address is B's
identifier, and the destination address is A's IPv6 address.
2.1.2. RANGI Hosts Communicate with IPv6 Hosts
In order to make the legacy IPv6 hosts in a site accessible to RANGI
hosts, the proxy should assign each of its IPv6 hosts a globally
unique identifier and store the mapping of the identifier and the
corresponding IPv6 address in its mapping table. The identifier
Xu and Jain Expires September 4, 2009 [Page 5]
Internet-Draft A Transition Mechanism for RANGI March 2009
should also be stored in the DNS system as an AAAA resource record.
Moreover, the identifier, associated with one of the proxy's locators,
should be stored in the ID/locator mapping systems.
Before initiating a communication with IPv6 host A, RANGI host B
needs to perform a DNS lookup and gets A's identifier as an AAAA
resource record. Then B obtains A's locator (the proxy's locator in
fact) from the ID/locator mapping system according to A's identifier.
After that, B constructs RANGI packets and sends them out.
Upon receiving the packets, the proxy finds the IPv6 address of A in
its mapping table, and caches B's identifier and locator in its
mapping table. The proxy then transforms the packets into IPv6
packets. In the IPv6 packets, B's identifier is used as the source
IPv6 address, while A's IPv6 address is used as the destination IPv6
address.
When A receives the packets, it sends response packets back.
Upon receiving the response packets, the proxy transforms the packets
into RANGI packets according to the corresponding mapping entries.
2.2. Communication between IPv4 and RANGI Hosts
The process of translating between IPv4 and RANGI is a bit more
complex than the translation between IPv6 and RANGI. As shown in
Figure 4, again there is a proxy located as exit border router in
legacy IPv4 site network.
+-------------------+ +--------------------+
|+------+ +--+----+ | +------+ |
|| A +--------+ Proxy +---+-----------+ B | |
|+------+ +--+----+ | +------+ |
| | | |
| IPv4 Site Network | | RANGI Site Network |
+-------------------+ +--------------------+
Figure 4. Communication between IPv4 and RANGI Hosts
The basic idea is to make the proxy assign each legacy IPv4 host a
secure identifier (associated with a public/private key pair). Then
the packets between proxy and RANGI host can be secured in an IPsec
tunnel. Again, if there is no need for security, the proxy could use
the combination of a specific /96 IPv6 prefix and A's IPv4 address as
A's identifier.
Xu and Jain Expires September 4, 2009 [Page 6]
Internet-Draft A Transition Mechanism for RANGI March 2009
2.2.1. IPv4 Hosts Communicate with RANGI Hosts
Before initiating a communication with RANGI host B, the IPv4 host A
performs a DNS lookup for B's IPv4 address. The DNS request would
travel from IPv4 network towards the DNS server S on the RANGI
network. Upon receiving the DNS request, the proxy rewrites the "A"
record in the DNS message as "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
Upon receiving the corresponding DNS response, the proxy obtain B's
identifier as an AAAA resource record, allocates B a temporary IPv4
address from its local IPv4 address pool, and caches the mapping of
B's identifier and IPv4 address in its mapping table. Meanwhile, the
proxy replaces the AAAA record in DNS response as an A record with
the temporary IPv4 address filled in and sends this DNS response
message to the DNS resolver. In addition, the proxy resolves B's
locator according to the identifier from ID/locator mapping system.
Once the resolution succeeds, the proxy caches the mapping in its
mapping table. Optionally, the proxy could assign A a temporary
identifier and cache the binding of this identifier, 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 A.
As the DNS resolution succeeds, 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.2.2. RANGI Hosts Communicate with IPv4 Hosts
In order to make IPv4 hosts in a site accessible to RANGI hosts, the
site proxy should assign each IPv4 host in the site a globally unique
Xu and Jain Expires September 4, 2009 [Page 7]
Internet-Draft A Transition Mechanism for RANGI March 2009
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 IPv4 host A, RANGI host B
obtains A's identifier and locator from its DNS system and ID/locator
mapping system, respectively. With such information, B would
construct RANGI packets and send them to A.
Upon receiving these packets, the proxy would allocate B a temporary
IPv4 address from its local IPv4 address pool, and cache the binding
of 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
from A into RANGI packets going to B according to the mapping entries
mentioned above.
3. Security Considerations
The security details related to the proxy mechanism has not been
explored.
4. Conclusions
With the proxy mechanism defined in this document, legacy IPv6 and
IPv4 hosts can communicate with RANGI hosts and vice versa. This
allows RANGI to be deployed incrementally.
This first draft is our initial attempt to develop a transition
mechanism. We are still working on several details and would
appreciate feedback and suggestions for improvement.
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.
Xu and Jain Expires September 4, 2009 [Page 8]
Internet-Draft A Transition Mechanism for RANGI March 2009
[RFC2234] D. Crocker and P. Overell (Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 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 and R. Jain, "Routing Architecture for the Next
Generation Internet (RANGI), draft-xu-rangi-00, March 2009.
[HRA] X. Xu and D. Guo, "Hierarchical Routing Architecture," Proc.
4th Euro-NGI Conference on Next Generation Internetworks,
Krakow, Poland, 28-30 April 2008, 7 pp.,
http://www.cse.wustl.edu/~jain/papers/hra.htm
[CGA] T. Aura, "Cryptographically Generated Addresses (CGA)",
RFC3972, Mar 2005.
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
Raj Jain
Washington University in Saint Louis
One Brookings Drive, Campus Box 1045
Saint Louis, MO 63130 USA
Phone: +1 314 935 4963
Email: jain@cse.wustl.edu
Xu and Jain Expires September 4, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 12:12:31 |