Network Working Group X. Xu
Internet Draft Huawei
Intended status: Informational
Expires: August 2010 February 12, 2010
Routing Architecture for the Next Generation Internet (RANGI)
draft-xu-rangi-03.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 August 12, 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
(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.
Xu Expires August 12, 2010 [Page 1]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
Abstract
IRTF Routing Research Group (RRG) is exploring a new routing and
addressing architecture to address the issues with the current
Internet, e.g., mobility, multi-homing, traffic engineering, and
especially the routing scalability issue. This document describes a
new identifier (ID)/locator split based routing and addressing
architecture, called Routing Architecture for the Next Generation
Internet (RANGI), in an attempt to deal with the above problems.
Table of Contents
1. Introduction.................................................3
2. Architecture Description.....................................3
2.1. Host Identifiers........................................3
2.2. Host Locators...........................................5
2.3. Packet Formats..........................................6
2.4. ID->Locator Mapping Resolution..........................6
2.5. Routing and Forwarding System...........................8
2.5.1. Host Behavior......................................8
2.5.2. LDBR Behavior......................................8
2.5.3. Non-LDBR Behavior..................................8
2.5.4. Forwarding Procedures..............................8
2.6. Site Multi-homing and Traffic-Engineering..............10
2.7. Host Mobility and Multi-homing.........................12
2.8. Network Mobility.......................................12
3. Summary.....................................................13
4. Security Considerations.....................................14
5. IANA Considerations.........................................14
6. Acknowledgments.............................................14
7. References..................................................14
Xu Expires August 12, 2010 [Page 2]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
1. Introduction
The Default Free Zone (DFZ) routing table size has been growing at an
increasing and potentially alarming rate for several years, which has
detrimental impact on the routing system scalability and the routing
convergence performance. This so-called routing scalability issue has
drawn significant attention from both industry and academia. After
much discussion following the IAB Routing and Addressing workshop
[RAWS] in Amsterdam, a common conclusion was reached that the
explosive growth in the DFZ routing table is mainly caused by the
wide adoption of multi-homing, traffic engineering and provider-
independent address. However, the underlying reason for this issue is
the overloading of IP address semantics of both identifiers and
locators. This overloading makes it impossible to renumber IP
addresses in a topologically aggregatable way.
At present, the IRTF Routing Research Group (RRG) is chartered to
explore a new routing and addressing architecture which is expected
to support the multi-homing, traffic-engineering, mobility and
simplified renumbering features in a more scalable way.
This document describes a new ID/locator split architecture, called
Routing Architecture for the Next Generation Internet (RANGI), which
aims to deal with the above issues. Similar with Host Identity
Protocol (HIP) [RFC4423], RANGI also introduces a host identifier (ID)
layer between the IPv6 network layer and the transport layer. As a
result, the transport-layer associations (e.g., TCP connections) are
no longer bound to IP addresses, but to the host IDs. Unlike HIP,
RANGI adopts hierarchical and cryptographic host IDs which have
delegation-oriented structure. As a result, the corresponding ID-
>locator mapping system for such identifiers has a reasonable
business model and clear trust boundaries. In addition, RANGI uses
special IPv4-embeded IPv6 addresses as locators. With such locators,
not only site-controlled traffic-engineering and simplified
renumbering can be easily achieved, but also the deployment cost of
this new architecture is reduced greatly.
2. Architecture Description
2.1. Host Identifiers
In RANGI, host IDs are hierarchical and 128-bit long. As depicted in
Figure 1, a host ID consists of two parts: the leftmost n bits (Note
that the suitable value of "n" has not been determined yet) part is
the Administrative Domain (AD) ID which has embedded organizational
affiliation and global uniqueness, and the remaining part (i.e., the
Xu Expires August 12, 2010 [Page 3]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
rightmost 128-n bits)is the Local Host ID which is generated by
computing a cryptographic one-way hash function from a public key of
the ID owner and auxiliary parameters, e.g., the ID owner's AD ID.
The binding between the public key and the host ID can be verified by
re-computing the hash value and by comparing the hash with the host
ID. As these identifiers are expected to be used along with IPv6
addresses at both applications and APIs, especially in the RANGI
transition mechanisms defined in [RANGI-PROXY], it is desired to
explicitly distinguish host IDs from IPv6 addresses (i.e., locators)
and vice versa. Hence, a separate prefix for identifiers should be
allocated by the IANA. As a result, several leftmost bits in the AD
ID field should be reserved to fill this dedicated prefix.
|<------- n bits --------->|<-- 128-n bits-->|
+--------------------------+-----------------+
| Administrative Domain ID | Local Host ID |
+--------------------------+-----------------+
| \
| \
| \
| \
| \
+------------+--------------+-----------+
|Country Code|Authority Code|Region Code| <------Example
+------------+--------------+-----------+
Figure 1. Host Identifier Structure
The approach of generating hierarchical RANGI host IDs is similar to
that for Cryptographically Generated Addresses (CGA) [RFC3972]. The
major difference is that the prefix of the RANGI host ID is AD ID,
rather than ordinary IPv6 address prefix. In CGA, the process of
generating a new address takes three input values: a 64-bit subnet
prefix, the public key of the address owner as a DER-encoded ASN.1
structure of the type SubjectPublicKeyInfo and the security parameter
Sec, which is an unsigned three-bit integer. In contrast, the process
of generating a hierarchical host ID in RANGI also takes three input
values: the n-bit AD ID, the public key of the host ID owner and the
security parameter Sec. Therefore, if we set the value of n to 64,
host IDs can be compatible with CGAs.
The benefits of using hierarchical host IDs in RANGI include but not
limited to: 1) manage the global identifier namespace in a scalable
way; 2) hold a reasonable economic model and clear trust boundaries
in the corresponding ID->Locator mapping system; 3) ease the
transition from the current Internet to RANGI.
Xu Expires August 12, 2010 [Page 4]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
In RANGI, the global uniqueness of host IDs is guaranteed through
some registration mechanism. Since the AD IDs are globally unique and
owned by the corresponding host ID registration and administrative
authorities of different countries respectively, the Local Host IDs
are only required to be unique within the corresponding AD scope.
The resolution infrastructure for flat labels has no "pay-for-your-
own" model, as names are stored at essentially random nodes (See
Layered Naming Architecture (LNA) [LNA]). In contrast, the resolution
infrastructure for hierarchical host IDs in RANGI has reasonable
business model and clear trust boundaries since host IDs can be
stored in the corresponding nodes according to their organizational
structures. To some extent, the business model of the ID->Locator
mapping system is similar with that for the Domain Name Service (DNS)
In the transition mechanisms for RANGI described in [RANGI-PROXY],
the identifiers of RANGI-aware hosts are treated as ordinary IPv6
addresses by legacy hosts. When a router receives a packet using a
host ID as the destination address, it needs to forward the packet
according to the destination IPv6 address as normal. In the end, the
packet will be forwarded to a dedicated proxy that is responsible for
translating the packets between RANGI and IPv6. Since the identifiers
are hierarchical and delegation-oriented aggregatable, such
identifier-based routing during transition period will not cause any
routing scalability issue. For more details, please refer to [RANGI-
PROXY].
2.2. Host Locators
The host locators in RANGI are ordinary IPv6 addresses. Since the
IPv4/IPv6 coexistence and transition will last for a long period, in
order to reduce the deployment cost of this new routing and
addressing architecture, RANGI uses specific IPv4-embeded IPv6
addresses as locators. As shown in Figure 2, the leftmost 96-bit part
of a locator is Locator Domain Identifier (LD ID), while the
rightmost 32-bit part is filled with an IPv4 address which is
required to be unique within the scope of corresponding LD. LD IDs
are used to globally identify each site network which is allowed to
adopt independent IPv4 address space (either public or private IPv4
addresses). Actually, LD IDs are Provider-Assigned (PA) /96 IPv6
prefixes which are topologically aggregatable in provider networks.
Xu Expires August 12, 2010 [Page 5]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
|<------- 96 bits -------->|<---- 32 bits--->|
+--------------------------+-----------------+
| LD ID | IPv4 |
+--------------------------+-----------------+
Figure 2. Host Locator Structure
Similar with the Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP) [RFC5214], this specific locator can be used for
automatically tunneling IPv6 packets over IPv4 networks.
2.3. Packet Formats
RANGI reuse the IPv6 packet format to maximum extent. The host IDs
are filled as options in the Destination Option Header, whereas the
locators are filled as IPv6 addresses in the IPv6 header. Packets
sent from a RANGI host can be protected by attaching the public key
and auxiliary parameters and by signing the packets with the
corresponding private key. The protection works without a
certification authority or any security infrastructure.
The details about the packet format and how to use IPsec to carry the
data traffic will be described in the latter version of this draft or
in a separate draft.
2.4. ID->Locator Mapping Resolution
ID/locator split implies a need for storing and distributing the
mappings from host IDs to locators.
In RANGI, the mappings from Fully Qualified Domain Names (FQDNs) to
host IDs are stored in the DNS system, while the mappings from host
IDs to locators are stored in a distributed ID->Locator mapping
system (e.g., a reverse DNS system). In a reverse DNS based mapping
infrastructure, If there are too many entries to be maintained by the
authoritative servers of a given Administrative Domain (AD),
Distribute Hash Table (DHT) technology can be used to make these
authoritative servers scale better. That is to say, the mappings
maintained by a given AD will be distributed among a group of
authoritative servers in a DHT fashion. As a result, the robustness
feature of DHT is inherited naturally into the ID->Locator mapping
system. Meanwhile, there is no trust issue since each AD authority
runs its own DHT ring which maintains only its presidial mappings.
Xu Expires August 12, 2010 [Page 6]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
A detailed lookup example is given as follows:
1. A host ID will be transformed to a FQDN format string. Firstly, a
host ID is expressed as "country-code.authority-code.region-
code.local-host-ID" by inserting dots between adjacent fields, then
by reversing the fields and attaching with the
suffix "RANGI.EXAMPLE." it is transformed into a FQDN-format
string "local-host-ID.region-code.authority-code.country-
code.RANGI.EXAMPLE."
2. The FQDN-format string is used as a key to locate the DNS server
or the DHT ring maintaining the desired resource records in the
reverse DNS infrastructure. If the DHT ring is located, the Local
Host ID part SHOULD be used as a key to locate the associated peer in
the DHT ring.
3. After an authoritative DNS server or a DHT peer has been located,
the Local Host ID is used to find out the related mapping entries for
that identifier.
In order to facilitate such a lookup process, a new sub-domain,
called "RANGI.EXAMPLE.", needs to be inserted into the current domain
name space tree structure. This domain can delegate its sub-domains
according to the hierarchy of the FQDN-format string of the host ID.
A new Resource Record (RR) named RANGI is also defined for the ID-
>Locator mappings, in which the NAME field is filled with the FQDN-
format string of a host ID, while the RDATA field is filled with the
corresponding locator information, including but not limited to an
IPv6 address (i.e., locator) and its preference, and so on.
The resolution infrastructure for flat names has no "pay-for-your-
own" model, as the flat names are stored at essentially random nodes.
In contrast, the resolution infrastructure for hierarchical host IDs,
as used in RANGI, has reasonable business and trust models because
hierarchical host IDs have clear organization affiliation and they
can be allocated and managed with clear administrative boundaries.
To prevent the Man-in-the-Middle attacks during mapping lookups, the
DNS Security Extensions (DNSSEC) [RFC535] is strongly recommended for
the origin authentication and integrity assurance of the DNS data.
To prevent DNS recursive servers caching antique ID->Locator mapping
information, the TTL of a RANGI RR for a mobile host should be set to
0 or a very small value. However, if a host (i.e., Correspondence
Node) wants to cache the RR of the communicating host (i.e., Mobile
Xu Expires August 12, 2010 [Page 7]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
Node), it can reset the TTL of that RR to a reasonable value
internally.
The Secure DNS Dynamic Update mechanism defined in [RFC3007] is
directly used for dynamically updating the ID->Locator mapping
entries in the ID->Locator mapping system in a secure way.
2.5. Routing and Forwarding System
Within RANGI, LDs are connected via Locator Domain Border Routers
(LDBRs). A LDBR has at least one locally unique IPv4 address in each
LD to which it is connected. The adjacent LDBRs exchange LD ID or LD
prefix (Specific LD IDs can be aggregated into one LD prefix)
reachability information with an inter-LD routing protocol. In fact,
the Border Gateway Protocol (BGP) for IPv6 address family can be used
directly as the inter-LD routing protocol.
2.5.1. Host Behavior
Generally, a RANGI host needs to obtain the locator of the
destination host from the ID->Locator mapping system before
initiating a communication. If the communication parties share a same
LD ID, they can exchange packets directly over an IPv4 tunnel.
Otherwise, the traffic will be relayed by LDBRs through IPv4 tunnels.
Hosts can get the IPv4 addresses of their local LDBRs in several ways,
e.g., a new Dynamic Host Configuration Protocol (DHCP) option, or a
well-known LD-scope anycast address specific for LDBRs.
2.5.2. LDBR Behavior
LDBRs establish BGP sessions among them so as to exchange LD
reachability information (i.e., IPv6 routing information with the
mask length less than /96). LDBRs forward RANGI packets according to
the destination IPv6 addresses (i.e., locators) as normal.
2.5.3. Non-LDBR Behavior
The non-LDBRs just need to support IPv4 forwarding capability. So
there is no need to upgrade them.
2.5.4. Forwarding Procedures
RANGI introduces a two-level routing mechanism which is composed of
LD ID based routing and IPv4 address based routing. The former is
Xu Expires August 12, 2010 [Page 8]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
used for inter-LD routing while the latter is used for intra-LD
routing.
A simple RANGI routing procedure is illustrated in Figure 3. Host A
(as source host) looks up the current locator of host B (as
destination host) through the ID->Locator mapping system. After
obtaining that information, host A will tunnel the packets with
destination address being host B to one of its local LDBRs. The LDBR
shall find the next-hop LDBR based on the IPv6 globally routable
locator, and forward the packets to it. For the intermediate transit
networks, if the Non-LDBR routers which the packets have to traverse
are legacy IPv4 routers, the ingress LDBR (for that locator domain)
forwards the packet to the egress LDBR of the same locator domain
over IPv4 tunnels.
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | | Payload | | Payload | | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
|HI(A)->HI(B) | |HI(A)->HI(B) | |HI(A)->HI(B) | |HI(A)->HI(B) |
+-------------+ +-------------+ +-------------+ +-------------+
|IPv6->IPv6 | |IPv6->IPv6 | |IPv6->IPv6 | |IPv6->IPv6 |
| (A) (B) | | (A) (B) | | (A) (B) | | (A) (B) |
+-------------+ +-------------+ +-------------+ +-------------+
|IPv4->IPv4 | | IPv4->IPv4 | |IPv4->IPv4 |
| (A) (BR1) | |(BR2) (BR3) | | (BR4) (B) |
+-------------+ +-------------+ +-------------+
|<- A to BR1 ->|<-BR1 to BR2 ->|<-BR2 to BR3 ->| |<-BR4 to B ->|
+--------- ------ ---------|
+---+ \ / \ / +---+
| A | \ / \ / /| B |
+---+\\ \ / \ / // +---+
| \\ | | | | / |
| \\ +---+ +---+ +---+ +---+// |
| \|BR1+----+BR2+------+BR3+---+BR4+/ |
| +---+ +---+ +---+ +---+ |
| | | | | |
\ / \ / \ /
\ LD #1 / \ LD #2 / \ LD #3 /
\ / \ / \ /
------ ------ ------
Figure 3. Routing Procedure
Xu Expires August 12, 2010 [Page 9]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
In RANGI, IPv6-over-IPv4 tunnels are employed for intra-LD routing
between LDBRs (or between LDBRs and hosts). Hence, RANGI can achieve
a smooth IPv4/IPv6 transition. Once the internal routers within LDs
are upgraded to IPv6, the requirement of IPv6 over IPv4 tunnel
between the LDBRs or between LDBRs and hosts will be eliminated and
the packets will be delivered by the LDBRs and the internal IPv6
routers hop by hop without tunneling as shown in Figure 4.
+-------------------+ +-------------------+ +-------------------+
| Payload | | Payload | | Payload |
+-------------------| +-------------------| +-------------------|
| HI(A)->HI(B) | | HI(A)->HI(B) | | HI(A)->HI(B) |
+-------------------| +-------------------| +-------------------|
| IPv6(A)->IPv6(B) | | IPv6(A)->IPv6(B) | | IPv6(A)->IPv6(B) |
+-------------------| ++------------------| +-------------------|
|IPv4(A)->IPv4(BR1) |
+-------------------+
|<--- A to BR1 --->|<----- BR1 to BR4 --->|<--- BR4 to B --->|
+--------- ------ ---------|
+---+ \ / \ / +---+
| A | \ / \ / /| B |
+---+\\ \ / \ / // +---+
| \\ | | | | / |
| \\ +---+ +---+ +---+ +---+// |
| \|BR1+----+BR2+------+BR3+---+BR4+/ |
| +---+ +---+ +---+ +---+ |
| | | | | |
\ LD #1 / \ LD #2 / \ LD #3 /
\ (IPv4) / \ (IPv6) / \ (IPv6) /
\ / \ / \ /
------ ------ ------
Figure 4. IPv4/IPv6 Transition
2.6. Site Multi-homing and Traffic-Engineering
In RANGI, Each multi-homed stub LD shall be assigned a LD ID by each
upstream ISP. In fact, these LD IDs are /96 IPv6 prefixes which are
topologically aggregatable in provider networks. Each Host within the
multi-homed site, in turn, has multiple locators by concatenating the
provider-assigned LD IDs with its locally unique IPv4 address. These
hosts register the mappings from their identifiers to locators with
the ID->Locator mapping system. As shown in Figure 5, host A which is
located in a multi-homed site, has two LD IDs, LD ID_1 and LD ID_2,
assigned separately from ISP1 and ISP2. Host A chooses either one as
Xu Expires August 12, 2010 [Page 10]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
the source LD ID of the outgoing packets. Upon receiving the packets,
the site exit LDBR, BR1, implements source-based policy routing. For
example, if the source LD is LD ID_1, the packets will be forwarded
to the ISP1's network, otherwise, they will be forwarded to ISP2's
network.
------
/ \
/ \
/ \
| |
+---+ |
+BR2| |
/+---+ |
/ | |
/ \ /
/------ / \ ISP#1 /
+---* \ / \ /
| A | \ / ------
+---+\\ \ /
| \\ | /
| \\ +---+ /
| \|BR1+/ ------
| +---+-- / \
| | -- / \
\ / -- / \
\ Site A / -- | |
\ / -- +---+ |
------ --+BR3| |
+---+ |
| |
\ /
\ ISP#2 /
\ /
------
Figure 5. Site Multi-homing and Traffic-engineering
The site-controlled traffic-engineering works as follows:
1) The source host sends out packets with the source LD ID being one
of its LD IDs (assuming LD ID 1 being used).
2) The packets are intercepted by the LDBR BR1, and according to the
traffic-engineering policy, the source LD IDs of the packets may
Xu Expires August 12, 2010 [Page 11]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
be re-written from LD ID_1 to LD ID_2. Then BR1 forwards the
packets into ISP2's network according to source-based routing
policies.
3) Once the packets arrive at the destination host, that host will
use the source LD IDs in the received packets as the destination
LD IDs in the response packets. So the response packets will also
enter site A through ISP2's network.
4) The source host could accept this change and use LD ID 2 as source
LD ID in the subsequent packets.
Similar to the GSE [GSE], the site-controlled traffic-engineering by
rewriting the source LD ID will have effect on the path (upstream ISP)
selection for both the outgoing packets and the incoming packets. In
addition, the multi-homing and traffic-engineering usages in RANGI
will not cause any routing scalability issue.
2.7. Host Mobility and Multi-homing
To some extent, host multi-homing is similar with host mobility since
their effects on the network and on correspondents are identical.
In RANGI, when a host physically moves from one point of network
attachment to another in the event of mobility or re-homing, it
should inform its existing correspondents of its new locator as soon
as possible. Furthermore, it needs to update its locator information
in the ID->Locator mapping system through the Secure DNS Dynamic
Update mechanism [RFC3007] so that any new correspondent could
correctly initiate communications to it at its new locator. In case
of simultaneous mobility, at least one of the communicating entities
has to resort to the ID->Locator mapping system for resolving the
correspondence node's new locator so as to continue their
communication.
In order to allow legacy IPv6 hosts to initiate communicates to RANGI
mobile hosts, many home-agent like devices SHOULD be deployed in the
transit networks and each of them is dedicated to a bunch of
identifiers within a given AD scope and is responsible for
translating packets between IPv6 and RANGI. For more details, please
refer to the transit proxy mechanism defined in [RANGI-PROXY].
2.8. Network Mobility
To mitigate the registration burden on the ID->Locator mapping system
triggered by network mobility, NEMO mechanism [RFC3963] is reused in
Xu Expires August 12, 2010 [Page 12]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
RANGI to support network mobility. That is to say, the mobile router
is responsible for updating its locator on its home agent. As a
result, network mobility event is transparent to the hosts within
that mobile network.
3. Summary
RANGI achieves almost all of goals set by RRG, which are listed as
follows:
1) Routing Scalability: Scalability is achieved by separating
identifiers from locators. Global routing is done based on
provider assigned locators.
2) Traffic Engineering: Site border router can overwrite the source
locator of the outgoing packets before performing source-based
policy routing. That is to say, hosts located in a multi-homed
site can suggest the upstream ISP for outbound and inbound
traffics, while the first-hop LDBR (i.e., site border router) has
the final decision right on the upstream ISP selection.
3) Mobility and Multi-homing: Applications and transport layers are
bound to host IDs and so the sessions will not be interrupted due
to locator change in cases of mobility or multi-homing.
4) Simplified Renumbering: When changing providers, the local IPv4
addresses of the site do not need to change. Hence the internal
routers within the site don't need renumbering.
5) Decoupling Location and Identifier: Obvious.
6) Routing Quality: Since LDBRs only exchange LD reachability and the
topology within LD will not be disclosed outside, the routing
stability is improved significantly.
7) Routing Security: RANGI reuses existing routing system and does
not introduce any new security risk into the routing system.
8) Incremental Deployability: The non-LDBRs (e.g., internal routers
within a site) can still be IPv4-only. Meanwhile, RANGI allows
easy transition from IPv4 networks to IPv6 networks. In addition,
the transition mechanisms for RANGI defined in [RANGI-PROXY] allow
RANGI hosts to initiate communications to legacy IPv4 or IPv6
hosts, and vice versa.
Xu Expires August 12, 2010 [Page 13]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
4. Security Considerations
TBD.
5. IANA Considerations
A specific prefix for host IDs needs to be assigned from the IPv6
address space.
Two new options in the Destination Option Header need to be assigned
for the host ID and its corresponding parameter date structure
respectively.
6. Acknowledgments
The author would like to thank Raj Jain, Xuewei Wang and Dacheng
Zhang for their valuable contributions. Thanks should also be given
to Paul Francis, Lixia Zhang, Brain Carpenter, Dave Oran, Joel
Halpern, and Tony Li for their insightful comments.
This research project is partially funded by the National"863" Hi-
Tech Program of China.
7. References
[RAWS] D. Meyer, L. Zhang, and K. Fall. "Report from the IAB Workshop
on Routing and Addressing", Internet draft, draft-iab-raws-
report-01.txt, work in progress, February 2007.
[GOALS] T. Li, "Design Goals for Scalable Internet Routing", draft-
irtf-rrg-design-goals-01, July 2007.
[RFC4423] R. Moskowitz and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[RFC3972] T. Aura, "Cryptographically Generated Addresses (CGA)",
RFC3972, Mar 2005.
[RFC3963] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[RFC5214] F. Templin, T. Gleeson, "Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)", RFC 5214, March, 2008.
Xu Expires August 12, 2010 [Page 14]
Internet-Draft Routing Architecture February, 2009
for the Next Generation Internet (RANGI)
[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC3007] B. Wellington, "Secure Domain Name System Dynamic Update",
RFC 3007, November 2000.
[H-DHT] L. Garces-Erice, E. Biersack, P. Felber, K. Ross, and G.
Urvoy-Keller, "Hierarchical Peer-to-peer Systems", In Proc.
Euro-Par 2003, Klagenfurt, Austria, 2003.
[GSE] M. O'Dell, "GSE-An Alternative Addressing Architecture for
IPv6", Internet-Draft, Feb 1997.
[LNA] Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia
Ratnasamy,Scott Shenker, Ion Stoica and Michael Walfish, "A
Layered Naming Architecture for the Internet", Proc. ACM
SIGCOMM, Portland, Oregon, USA, August 30 - September 3,
2004.
[RANGI-PROXY] X. Xu, ''Transition Mechanisms for Routing Architecture
for the Next Generation Internet (RANGI)'', draft-xu-rangi-
proxy-01.txt, July 2009.
Xu Expires July 25, 2010 [Page 14]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
Authors' 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