Network Working Group                                              X. Xu
Internet Draft                                                    Huawei
Intended status: Informational
Expires: July 2010                                      January 25, 2010


       Routing Architecture for the Next Generation Internet (RANGI)
                           draft-xu-rangi-02.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 July 25, 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 July 25, 2010               [Page 1]


Internet-Draft             Routing Architecture              July, 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. 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. Multi-homing and Traffic-Engineering...................10
      2.7. Mobility...............................................12
   3. Summary.....................................................12
   4. Security Considerations.....................................13
   5. IANA Considerations.........................................13
   6. Acknowledgments.............................................13
   7. References..................................................14

















Xu                       Expires July 25, 2010                [Page 2]


Internet-Draft             Routing Architecture              July, 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 an ID/locator split approach, 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 (i.e., TCP connections and UDP
   associations) are no longer bound to IP addresses, but to the host
   IDs. The major difference from the HIP is that the host IDs in RANGI
   are hierarchical and cryptographic host IDs which have organizational
   structure. As a result, the ID/locator mapping system for such
   identifiers has reasonable business model and clear trust boundaries.
   In addition, RANGI uses special IPv4-embeded IPv6 addresses as
   locators. With such locators, site-controlled traffic-engineering can
   be easily achieved and the renumbering burden during ISP change is
   also eliminated greatly. Besides, the deployment cost of such a new
   architecture is reduced greatly and the new architecture could be
   deployed in a more incremental way.

2. Architecture Description

   2.1. Host Identifiers

   Similar to HIP, RANGI is a host-based ID/locator split architecture.
   The host IDs in RANGI are hierarchical and 128-bit long. As depicted
   in Figure 1, a host ID consists of two parts: the leftmost n-bit


Xu                       Expires July 25, 2010                [Page 3]


Internet-Draft             Routing Architecture              July, 2009
                   for the Next Generation Internet (RANGI)


   (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 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 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 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 for this purpose.

          |<------- n bits --------->|<-- 128-n bits-->|
          +--------------------------+-----------------+
          | Administrative Domain ID |   Local Host ID |
          +--------------------------+-----------------+
          |                            \
          |                              \
          |                                \
          |                                   \
          |                                      \
          +-----------+-------------+-------------+
          | Country ID| Authority ID| Region ID   | <------Example
          +-----------+-------------+-------------+

                    Figure 1. Host Identifier Structure

   The approach of generating hierarchical host IDs in RANGI is similar
   to the 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 new 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 the hierarchical host ID in RANGI include but not
   limited to: 1) manage the global identifier namespace in a scalable


Xu                       Expires July 25, 2010                [Page 4]


Internet-Draft             Routing Architecture              July, 2009
                   for the Next Generation Internet (RANGI)


   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 the 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 from 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 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 the locator is Locator Domain Identifier (LD ID) while the
   rightmost 32-bit part is filled with an IPv4 address which is
   required to be locally unique within the scope of corresponding LD.
   LD IDs are used to globally identify each autonomous site network
   which could 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 providers'
   networks.



Xu                       Expires July 25, 2010                [Page 5]


Internet-Draft             Routing Architecture              July, 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 the destination IPv4 site
   networks since the embedded IPv4 address of the destination locator
   is used as the tunnel destination address directly.

   2.3. Packet Formats

   RANGI reuse IPv6 protocol stack and packet format to maximum extent.
   The host ID simply appears as an option in the Destination Option
   Header, whereas the locator is filled as the IPv6 address 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.

   2.4. ID/Locator Mapping Resolution

   ID/locator split implies a need for storing and distributing the
   mappings from identifiers to locators.

   In RANGI, the mappings from Fully Qualified Domain Names (FQDNs) to
   identifiers 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 server of a given AD, Distribute Hash Table (DHT)
   technology can be used to scale that authoritative server because the
   Local Host ID part is a flat label. As a result, the mappings
   belonging to a given AD will be maintained by a group of DHT peers in
   a distributed way. As a result, the robustness of DHT is inherited
   naturally into the ID/Locator mapping system. Meanwhile, there is no
   trust issue since each of these ADs runs their own DHT ring which
   only maintains their presidial mappings.

   A detailed lookup example is given as follows:




Xu                       Expires July 25, 2010                [Page 6]


Internet-Draft             Routing Architecture              July, 2009
                   for the Next Generation Internet (RANGI)


   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 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-to-
   Loc 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 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 the hierarchical host
   IDs, as used in RANGI, has reasonable business and trust models,
   because the hierarchical host IDs have clear organization affiliation
   and the identifier resources can be allocated and managed with clear
   administrative boundaries.

   To prevent the Man-in-the-Middle attack during mapping lookups, the
   DNS Security Extensions (DNSSEC) [RFC2065] is strongly recommended
   for the origin authentication and integrity assurance of the DNS data.

   The mechanism defined in DNS UPDATE [RFC2136] is directly used for
   dynamically updating the RRs in the corresponding zone. To support
   mobility, the TTL of a RANGI RR should be set to 0 or a very small
   value to prevent a DNS resolver caching antique mapping information.
   However, if a host (i.e., Correspondence Node) wants to cache the RR
   of the communicating host (i.e., Mobile Node), it can reset the TTL
   to a reasonable value internally.


Xu                       Expires July 25, 2010                [Page 7]


Internet-Draft             Routing Architecture              July, 2009
                   for the Next Generation Internet (RANGI)


   To secure the dynamic update of ID-to-Locator mappings, the mechanism
   defined in the Cryptographically Generated Addresses (CGA) [RFC3972]
   is used for the purposes of data integrity protection and origin
   authentication, e.g., the update message is attached with the public
   key of the update sender and auxiliary parameters, and is signed with
   the corresponding private key.

   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
   initializing 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 July 25, 2010                [Page 8]


Internet-Draft             Routing Architecture              July, 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 July 25, 2010                [Page 9]


Internet-Draft             Routing Architecture              July, 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. 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 July 25, 2010               [Page 10]


Internet-Draft             Routing Architecture              July, 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 July 25, 2010               [Page 11]


Internet-Draft             Routing Architecture              July, 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. Mobility

   In RANGI, when a host physically moves from one attachment to another,
   its host ID remains unchanged. The host needs to register the new
   locator with the ID/locator mapping system. Meanwhile, it should
   notify the corresponding entity of its new locator as soon as
   possible.

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.



Xu                       Expires July 25, 2010               [Page 12]


Internet-Draft             Routing Architecture              July, 2009
                   for the Next Generation Internet (RANGI)


   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 within a LD can still be
      IPv4-only. 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 communicate with the legacy
      IPv4 or IPv6 hosts, and vice versa.

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.







Xu                       Expires July 25, 2010               [Page 13]


Internet-Draft             Routing Architecture              July, 2009
                   for the Next Generation Internet (RANGI)


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.

   [RFC5214] F. Templin, T. Gleeson, ''Intra-Site Automatic Tunnel
             Addressing Protocol (ISATAP),'' RFC 5214, March, 2008.

   [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, ''Dynamic
             Updates in the Domain Name System (DNS UPDATE)'', RFC 2136,
             April 1997.

   [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Protocol
             Security Extensions", RFC 2065, January 1997.

   [RFC2137] Eastlake, D., "Secure Domain Name System Dynamic Update",
             RFC 2137, April 1997.

   [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