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


       Routing Architecture for the Next Generation Internet (RANGI)
                           draft-xu-rangi-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             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...........................7
      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..................................9
         2.5.4. Forwarding Procedures..............................9
      2.6. Multi-homing and Traffic-Engineering...................11
      2.7. Mobility...............................................13
   3. Summary.....................................................13
   4. Security Considerations.....................................14
   5. IANA Considerations.........................................14
   6. Acknowledgments.............................................14
   7. References..................................................14

















Xu                     Expires January 13, 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 could 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 layer between the
   IP 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 identifiers. The
   major difference from the HIP is that the host identifier in RANGI is
   hierarchical and cryptographic host identifiers which have
   organizational structure. As a result, the ID/locator mapping system
   for such identifiers has reasonable business model and trust
   boundaries. In addition, RANGI uses special IPv6 addresses with IPv4
   address embedded in the last four octets as locators. With this
   special locator, site-controlled traffic-engineering can be easily
   supported and the renumbering works during ISP change are also
   simplified greatly. Besides, the deployment cost of the 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 the HIP, RANGI is also a kind of ID/locator split
   architecture. It introduces a 128-bit hierarchical host identifier.


Xu                     Expires January 13, 2010              [Page 3]


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


   As depicted in Figure 1, this identifier is composed of two parts,
   the leftmost n-bit 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 a hash over the AD
   ID and the public key of the ID owner. In order to distinguish
   identifiers from locators (IPv6 addresses) in the transition
   mechanisms [RANGI PROXY], identifiers use a specific prefix, which is
   to be allocated from the IPv6 address space by IANA. Hence  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 purposes of the hierarchical host ID in RANGI are 1)to ease the
   management of the global identifier namespace resource; 2)to hold the
   economic and trust model in the ID/locator mapping system; 3)to ease
   the transition from the current Internet to the RANGI.

   In RANGI, the global uniqueness of host IDs should be guaranteed
   through some registration mechanism. Since the AD IDs are globally
   unique and owned by the host ID registration and administrative
   authorities from different countries, the second part of the host ID
   (i.e., the local host ID) just needs to be unique within the
   corresponding AD scope.

   The resolution infrastructure for flat label 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 the hierarchical host IDs in RANGI has reasonable
   business model and clear trust boundaries since they are stored in
   the corresponding nodes according to the organizational structures of
   the host IDs. To some extent, the business model of the ID/locator
   mapping system is similar with that for the Domain Name Service (DNS)



Xu                     Expires January 13, 2010              [Page 4]


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


   In the transition mechanisms for RANGI described in [RANGI-PROXY],
   identifiers are treated as IPv6 addresses by legacy hosts, and
   routers will forward the IPv6 packets with destination addresses
   being identifiers. Since the identifiers are hierarchical and
   aggregatable, the identifier based routing will not cause any routing
   scalability issue. For more information, please refer to [RANGI-
   PROXY].

   The approach of generating hierarchical host identifiers in RANGI is
   much similar to the Cryptographically Generated Addresses (CGA)
   [RFC3972]. The major difference is that the prefix of the RANGI host
   identifier is AD ID, rather than ordinary IPv6 address prefix. In the
   CGA, the process of generating a new CGA 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
   RANGI, the process of generating a new host identifier also takes
   three input values: the n-bit AD ID (the suitable value of "n" has
   not been determined), the public key of the host ID owner and the
   security parameter Sec.

   2.2. Host Locators

   Host locators in RANGI are just IPv6 addresses. Since the IPv4/IPv6
   coexistence and transition will last for a long period of time, in
   order to reduce the deployment cost of the new routing and addressing
   architecture, RANGI uses specific IPv6 addresses with IPv4 address
   embedded in the last 4 octets as locators. As shown in Figure 2, the
   leftmost 96-bit part of the locator is Locator Domain Identifier (LD
   ID), and it is used to globally identify each autonomous site network
   which adopts independent IPv4 address space. Actually, the LD IDs are
   provider-assigned (PA) /96 IPv6 prefixes which are topologically
   aggregatable. The rightmost 32-bit part is the host's IPv4 address
   which is locally unique in the corresponding LD scope.













Xu                     Expires January 13, 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 to
   automatically tunnel IPv6 packets over the destination IPv4 site
   networks since the IPv4 address part of the destination locator is
   used as the destination address of the tunnel header.

   2.3. Packet Formats

   RANGI-aware hosts reuse IPv6 protocol stack and packet format to
   maximum extent. The host identifier simply appears as a Next Header
   in the IPv6 header, as depicted in Figure 3, whereas the locator is
   filled as the IPv6 address in the IPv6 header, as shown in Figure 4.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Reserved               | Protocol Type |   Checksum    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                        Source Host ID                         +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Destination Host ID                     +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3. Host Identifier Header Format




Xu                     Expires January 13, 2010              [Page 6]


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


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Traffic Class |           Flow Label                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Payload Length        |  Next Header  |   Hop Limit   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                         Source LD ID                          |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Source IPv4 Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                       Destination LD ID                       |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IPv4 Address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4. Host Locator Header Format

   The details regarding 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 identifiers to locators.

   Within RANGI, the mappings from Fully Qualified Domain Names (FQDN)
   to host identifiers are stored in the DNS system, while the mappings
   from host identifiers to locators are stored in a distributed
   id/locator mapping system (e.g., a hierarchical Distributed Hash
   Table (DHT) system, or a reverse DNS system).

   When using the hierarchical DHT system as the ID/locator mapping
   system, the AD ID of the host ID is regarded as a key in the top-
   level DHT ring to locate the corresponding bottom-level DHT ring,
   whereas the local host ID part is used as a key in the corresponding
   bottom-level DHT ring to determine the corresponding peer which


Xu                     Expires January 13, 2010              [Page 7]


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


   stores the desired ID/locator mappings. In practice, the top-level
   DHT ring can split further into multiple levels according to the
   hierarchical structure of the AD ID. To some extent, such a mapping
   system is a combination of the DNS and the DHT, and the top-level is
   more like the DNS since the routing is based on the former part of
   the host identifier (i.e., hierarchical AD ID), whereas the bottom-
   level is a DHT because the routing is based on the latter part of the
   host identifier (i.e., the flat local host ID).

   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
   identifiers, as used in RANGI, has reasonable business and trust
   model, since the hierarchical host identifiers have clear
   organization affiliation and the identifier resources can be managed
   with clear administrative boundaries.

   2.5. Routing and Forwarding System

   Within the 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 source host will obtain the locator of the destination
   host from the ID/locator mapping system before initializing a
   communication. If the LD of the source host is identical with that of
   the destination host, the source host will send the packets directly
   to the destination host over an IPv4 tunnel. Otherwise, the source
   host will forward the packets towards the local LDBR over 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). LDBR can forward IPv6 packets according


Xu                     Expires January 13, 2010              [Page 8]


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


   to the LD ID of the destination locator (IPv6 address) over IPv4
   tunnels.

   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
   used for inter-LD routing while the latter is used for intra-LD
   routing.

   A simple RANGI routing procedure is illustrated in Figure 5. Source
   host A looks up the current locator of the destination host B 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.






















Xu                     Expires January 13, 2010              [Page 9]


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



   +-------------+  +-------------+  +-------------+  +-------------+
   | 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 5. Routing Procedure


   For the intra-LD routing, RANGI uses the IPv6-over-IPv4 tunnels
   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 6.









Xu                     Expires January 13, 2010             [Page 10]


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



   +-------------------+  +-------------------+  +-------------------+
   |     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 6. 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 7, 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
   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
   into the ISP1's network, otherwise, they will be forwarded into
   ISP2's network.


Xu                     Expires January 13, 2010             [Page 11]


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


                                         ------
                                        /       \
                                       /         \
                                      /           \
                                     |            |
                                    +---+         |
                                    +BR2|         |
                                   /+---+         |
                                  /  |            |
                                 /    \           /
             /------            /      \  ISP#1  /
        +---*       \          /        \       /
        | A |        \        /          ------
        +---+\\       \      /
          |    \\      |    /
          |      \\ +---+  /
          |        \|BR1+/                ------
          |         +---+--              /       \
          |            |   --           /         \
           \          /      --        /           \
            \ Site A /         --     |            |
             \      /            --  +---+         |
              ------               --+BR3|         |
                                     +---+         |
                                      |            |
                                       \           /
                                        \  ISP#2  /
                                         \       /
                                          ------

            Figure 7.  Site Multi-homing and Traffic-engineering


   The site-controlled traffic-engineering works as follows:

   I. The source host sends out packets with the source LD ID being one
        of its LD IDs (assuming LD ID 1 being used).

   II.           The packets are intercepted by the LDBR BR1, and according to the
        traffic-engineering policy, the source LD IDs of the packets may
        be re-written from LD ID_1 to LD ID_2. Then BR1 forwards the
        packets into ISP2's network due to source-based policy routing.

   III. Once the packets arrive at the destination host, that host will
        use the source LD IDs in the received packets as the destination



Xu                     Expires January 13, 2010             [Page 12]


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


        LD IDs in the response packets. So the response packets will
        also enter the site A through the ISP2's network.

   IV.           The source host could accept this change and use LD ID 2 as the
        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 as follows:

   1. Routing Scalability: Scalability is achieved by separating the
      identifiers from locators. Global routing is done based on
      provider assigned locators.

   2. Traffic Engineering: LDBRs can overwrite the LD ID part of the
      source locator and implement source-based policy routing
      according to the source LD ID.

   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
      locators (IPv4 part of the locators) do not change. The non-LDBR
      within the LD 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 could be improved greatly.



Xu                     Expires January 13, 2010             [Page 13]


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


   7. Routing Security: RANGI reuses current routing system and does
      not introduce any new security risk into the routing system.

   8. Incremental Deployability: non-LDBR within 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] allows 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 identifiers needs to be assigned from the
   IPv6 address space.

6. Acknowledgments

   The author would like to thank Raj Jain for his valuable comments and
   reviews. Thanks should also be given to several experts who commented
   on the earlier versions of this proposal including Dave Oran, Joel
   Halpern, and Tony Li.

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.

   [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.


Xu                     Expires January 13, 2010             [Page 14]


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


   [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.

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

   [RANGI-PROXY] X. Xu, "Transition Mechanisms for Routing Architecture
             for the Next Generation Internet (RANGI)", draft-xu-rangi-
             proxy-01.txt, July 2009.

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


























Xu                     Expires January 13, 2010             [Page 15]