idnits 2.17.1 draft-xu-rangi-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 10, 2010) is 5007 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 60, but not defined == Missing Reference: 'RFC535' is mentioned on line 300, but not defined == Unused Reference: 'GOALS' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'H-DHT' is defined on line 564, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-iab-raws-report-01 == Outdated reference: A later version (-06) exists of draft-irtf-rrg-design-goals-01 ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group X. Xu 2 Internet Draft Huawei 3 Intended status: Informational 4 Expires: February 2011 August 10, 2010 6 Routing Architecture for the Next Generation Internet (RANGI) 7 draft-xu-rangi-04.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on February 10, 2011. 31 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents carefully, 40 as they describe your rights and restrictions with respect to this 41 document. 43 for the Next Generation Internet (RANGI) 45 Abstract 47 IRTF Routing Research Group (RRG) is exploring a new routing and 48 addressing architecture to address the issues with the current 49 Internet, e.g., mobility, multi-homing, traffic engineering, and 50 especially the routing scalability issue. This document describes a 51 new identifier (ID)/locator split based routing and addressing 52 architecture, called Routing Architecture for the Next Generation 53 Internet (RANGI), in an attempt to deal with the above problems. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC-2119 [RFC2119]. 61 Table of Contents 63 1. Introduction.................................................3 64 2. Architecture Description.....................................3 65 2.1. Host Identifiers........................................3 66 2.2. Host Locators...........................................5 67 2.3. Packet Formats..........................................6 68 2.4. ID->Locator Mapping Resolution..........................6 69 2.5. Routing and Forwarding System...........................8 70 2.6. Site Multi-homing and Traffic-Engineering...............9 71 2.7. Host Mobility and Multi-homing.........................10 72 2.8. Network Mobility.......................................11 73 3. Summary.....................................................11 74 4. Security Considerations.....................................12 75 5. IANA Considerations.........................................12 76 6. Acknowledgments.............................................12 77 7. References..................................................12 78 for the Next Generation Internet (RANGI) 80 1. Introduction 82 The Default Free Zone (DFZ) routing table size has been growing at an 83 increasing and potentially alarming rate for several years, which has 84 detrimental impact on the routing system scalability and the routing 85 convergence performance. This so-called routing scalability issue has 86 drawn significant attention from both industry and academia. After 87 much discussion following the IAB Routing and Addressing workshop 88 [RAWS] in Amsterdam, a common conclusion was reached that the 89 explosive growth in the DFZ routing table is mainly caused by the 90 wide adoption of multi-homing, traffic engineering and provider- 91 independent address. However, the underlying reason for this issue is 92 the overloading of IP address semantics of both identifiers and 93 locators. This overloading makes it impossible to renumber IP 94 addresses in a topologically aggregatable way. 96 At present, the IRTF Routing Research Group (RRG) is chartered to 97 explore a new routing and addressing architecture which is expected 98 to support the multi-homing, traffic-engineering, mobility and 99 simplified renumbering features in a more scalable way. 101 This document describes a new ID/locator split architecture, called 102 Routing Architecture for the Next Generation Internet (RANGI), which 103 aims to deal with the above issues. Similar with Host Identity 104 Protocol (HIP) [RFC4423], RANGI also introduces a host identifier (ID) 105 layer between the IPv6 network layer and the transport layer. As a 106 result, the transport-layer associations (e.g., TCP connections) are 107 no longer bound to IP addresses, but to the host IDs. Unlike HIP, 108 RANGI adopts hierarchical and cryptographic host IDs which have 109 delegation-oriented structure. As a result, the corresponding ID- 110 >locator mapping system for such identifiers has a reasonable 111 business model and clear trust boundaries. In addition, RANGI uses 112 special IPv4-embeded IPv6 addresses as locators. With such locators, 113 site-controlled traffic-engineering and simplified renumbering can be 114 easily achieved, meanwhile, the deployment cost of this new 115 architecture is reduced greatly. 117 2. Architecture Description 119 2.1. Host Identifiers 121 In RANGI, host IDs are hierarchical and 128-bit long. As depicted in 122 Figure 1, a host ID consists of two parts: the leftmost n bits (Note 123 that the suitable value of "n" has not been determined yet, while the 124 value of " n" is set to 64 in our current prototype) part is the 125 Administrative Domain (AD) ID which has embedded organizational 126 for the Next Generation Internet (RANGI) 128 affiliation and global uniqueness, and the remaining part (i.e., the 129 rightmost 128-n bits)is the Local Host ID which is generated by 130 computing a cryptographic one-way hash function from a public key of 131 the ID owner and auxiliary parameters, e.g., the ID owner's AD ID. 132 The binding between the public key and the host ID can be verified by 133 re-computing the hash value and by comparing the hash with the host 134 ID. As these identifiers are expected to be used along with IPv6 135 addresses at both applications and APIs, especially in the RANGI 136 transition mechanisms defined in [RANGI-PROXY], it is desired to 137 explicitly distinguish host IDs from IPv6 addresses (i.e., locators) 138 and vice versa. Hence, a separate prefix for identifiers SHOULD be 139 allocated by the IANA. As a result, several leftmost bits in the AD 140 ID field SHOULD be reserved to fill this dedicated prefix. 142 |<------- n bits --------->|<-- 128-n bits-->| 143 +--------------------------+-----------------+ 144 | Administrative Domain ID | Local Host ID | 145 +--------------------------+-----------------+ 146 | \ 147 | \ 148 | \ 149 | \ 150 | \ 151 +------------+--------------+-----------+ 152 |Country Code|Authority Code|Region Code| <------Example 153 +------------+--------------+-----------+ 155 Figure 1. Host Identifier Structure 157 The approach of generating hierarchical RANGI host IDs is similar to 158 that for Cryptographically Generated Addresses (CGA) [RFC3972]. The 159 major difference is that the prefix of the RANGI host ID is AD ID, 160 rather than ordinary IPv6 address prefix. In CGA, the process of 161 generating a new address takes three input values: a 64-bit subnet 162 prefix, the public key of the address owner as a DER-encoded ASN.1 163 structure of the type SubjectPublicKeyInfo and the security parameter 164 Sec, which is an unsigned three-bit integer. In contrast, the process 165 of generating a hierarchical host ID in RANGI also takes three input 166 values: the n-bit AD ID, the public key of the host ID owner and the 167 security parameter Sec. Therefore, if we set the value of n to 64, 168 the process of generating RANGI host IDs can be compatible with that 169 for CGA. 171 The benefits of using hierarchical host IDs in RANGI include but not 172 limited to: 1) manage the global identifier namespace in a scalable 173 way; 2) hold a reasonable economic model and clear trust boundaries 174 for the Next Generation Internet (RANGI) 176 in the corresponding ID->Locator mapping system; 3) ease the 177 transition from the current Internet to RANGI. 179 In RANGI, the global uniqueness of host IDs is guaranteed through 180 some registration mechanism. Since the AD IDs are globally unique and 181 owned by the corresponding host ID registration and administrative 182 authorities of different countries respectively, the Local Host IDs 183 are only REQUIRED to be unique within the corresponding AD scope. 185 The resolution infrastructure for flat labels has no "pay-for-your- 186 own" model, as names are stored at essentially random nodes (See 187 Layered Naming Architecture (LNA) [LNA]). In contrast, the resolution 188 infrastructure for hierarchical host IDs in RANGI has reasonable 189 business model and clear trust boundaries since host IDs can be 190 stored in the corresponding authoritative servers according to their 191 organizational structures. To some extent, the business model of the 192 ID->Locator mapping system in RANGI is similar to that for the Domain 193 Name Service (DNS). 195 In the RANGI transition mechanisms described in [RANGI-PROXY], the 196 identifiers of RANGI hosts are treated as ordinary IPv6 addresses by 197 legacy IPv6 hosts. Upon receives a packet with the destination 198 address being a host ID, the router SHOULD forward the packet 199 according to the destination IPv6 address as normal. In the end, the 200 packet will be forwarded to a dedicated proxy that is responsible for 201 translating the packets between RANGI and IPv6. Since the identifiers 202 are hierarchical and delegation-oriented aggregatable, such 203 identifier-based routing during transition period will not cause any 204 routing scalability issue. For more details, please refer to [RANGI- 205 PROXY]. 207 2.2. Host Locators 209 The host locators in RANGI are ordinary IPv6 addresses. Since the 210 IPv4/IPv6 coexistence and transition will last for a long period, in 211 order to reduce the deployment cost of this new routing and 212 addressing architecture, RANGI uses specific IPv4-embeded IPv6 213 addresses as locators. As shown in Figure 2, the leftmost 96-bit part 214 of a locator is called Locator Domain Identifier (LD ID), while the 215 rightmost 32-bit part is filled with an IPv4 address which is 216 REQUIRED to be unique within the scope of corresponding LD. LD IDs 217 are used to globally identify each site network which is allowed to 218 adopt independent IPv4 address space (either public or private IPv4 219 addresses). Actually, LD IDs are Provider-Assigned (PA) /96 IPv6 220 prefixes which are topologically aggregatable in provider networks. 222 for the Next Generation Internet (RANGI) 224 |<------- 96 bits -------->|<---- 32 bits--->| 225 +--------------------------+-----------------+ 226 | LD ID | IPv4 | 227 +--------------------------+-----------------+ 229 Figure 2. Host Locator Structure 231 Similar with the Intra-Site Automatic Tunnel Addressing Protocol 232 (ISATAP) [RFC5214], this specific locator can be used for 233 automatically tunneling IPv6 packets over IPv4 site networks. 235 2.3. Packet Formats 237 RANGI reuse the IPv6 packet format to maximum extent. The host IDs 238 are filled as options in the Destination Option Header, whereas the 239 locators are filled as IPv6 addresses in the IPv6 header. Packets 240 sent from a RANGI host can be protected by attaching the public key 241 and auxiliary parameters and by signing the packets with the 242 corresponding private key. The protection works without a 243 certification authority or any security infrastructure. 245 The details about the packet format and how to use IPsec to carry the 246 data traffic will be described in the latter version of this draft or 247 in a separate draft. 249 2.4. ID->Locator Mapping Resolution 251 ID/locator split implies a need for storing and distributing the 252 mappings from host IDs to locators. 254 In RANGI, the mappings from Fully Qualified Domain Names (FQDNs) to 255 host IDs are stored in the DNS system, while the mappings from host 256 IDs to locators are stored in a distributed ID->Locator mapping 257 system which can be built on the current DNS infrastrature. In a DNS 258 based ID->Locator mapping system, if there are too many entries to be 259 maintained by the authoritative servers of a given Administrative 260 Domain (AD), Distribute Hash Table (DHT) technology can be used 261 further to make these authoritative servers scale better. That is to 262 say, the mappings maintained by a given AD will be distributed among 263 a group of authoritative servers in a DHT fashion. As a result, the 264 robustness feature of DHT is inherited naturally into the ID->Locator 265 mapping system. Meanwhile, there is no trust issue since each AD 266 authority runs its own DHT ring which maintains only mappings for the 267 identifiers belonging to this AD. 269 for the Next Generation Internet (RANGI) 271 A detailed mapping lookup example is given as follows: 273 1. A host ID will be transformed to a FQDN format string. Firstly, a 274 host ID is expressed as "country-code.authority-code.region- 275 code.local-host-ID" by inserting dots between adjacent fields, then 276 by reversing the fields and attaching with the suffix "rangiid.arpa." 277 it is transformed into a FQDN-format string as "local-host-ID.region- 278 code.authority-code.country-code.rangiid.arpa." 280 2. The FQDN-format string is used as a key to locate the 281 authoritative DNS server which maintains the desired resource records. 283 In order to facilitate such a lookup process, a new sub-domain " 284 rangiid.arpa." needs to be inserted into the current domain name 285 hierarchy. This sub-domain can delegate its own sub-domains according 286 to the hierarchy of the FQDN-format string of the host ID. A new 287 Resource Record (RR) named RANGI is also defined for the ID->Locator 288 mappings, in which the NAME field is filled with the FQDN-format 289 string of a host ID, while the RDATA field is filled with the 290 corresponding locator information, including but not limited to an 291 IPv6 address (i.e., locator) and its preference, and so on. 293 The resolution infrastructure for flat names has no "pay-for-your- 294 own" model, as the flat names are stored at essentially random nodes. 295 In contrast, the resolution infrastructure for hierarchical host IDs, 296 as used in RANGI, has reasonable business and trust models because 297 hierarchical host IDs have clear organization affiliation. 299 To prevent the Man-in-the-Middle attacks during mapping lookups, the 300 DNS Security Extensions (DNSSEC) [RFC535] is strongly recommended for 301 the origin authentication and integrity assurance of the DNS data. 303 To prevent DNS recursive servers caching antique ID->Locator mapping 304 information, the TTL of a RANGI RR for a mobile host SHOULD be set to 305 0 or a very small value. However, if a host (i.e., Correspondence 306 Node) wants to cache the RR of the communicating host (i.e., Mobile 307 Node), it can reset the TTL of that RR to a reasonable value 308 internally. 310 The Secure DNS Dynamic Update mechanism defined in [RFC3007] is 311 directly used for dynamically updating the ID->Locator mapping 312 entries in the ID->Locator mapping system in a secure way. 314 for the Next Generation Internet (RANGI) 316 2.5. Routing and Forwarding System 318 In RANGI, site networks (i.e., LDs) are connected to the IPv6 319 Internet via site border routers called Locator Domain Border Routers 320 (LDBRs). LDBRd play the similar role as ISATAP [RFC5214] routers. 322 A simple RANGI routing procedure is illustrated in Figure 3. Host A 323 (as source host) looks up the locator of host B (as destination host) 324 through the ID->Locator mapping system before communicating with host 325 B. Since these two hosts are located in different LDs, A will tunnel 326 the packets destined for B to one of its local LDBRs, e.g., BR1. 327 Otherwise, A will tunnel the packets destined for B directly towards 328 B's IPv4 address. Once the packets arrive at the LDBR of the 329 destination site, e.g., BR4, it will tunnel the IPv6 packets towards 330 B's IPv4 address which is the last four octets of the destination 331 locator. 333 +-------------+ +-------------+ +-------------+ +-------------+ 334 | Payload | | Payload | | Payload | | Payload | 335 +-------------+ +-------------+ +-------------+ +-------------+ 336 |HI(A)->HI(B) | |HI(A)->HI(B) | |HI(A)->HI(B) | |HI(A)->HI(B) | 337 +-------------+ +-------------+ +-------------+ +-------------+ 338 |IPv6->IPv6 | |IPv6->IPv6 | |IPv6->IPv6 | |IPv6->IPv6 | 339 | (A) (B) | | (A) (B) | | (A) (B) | | (A) (B) | 340 +-------------+ +-------------+ +-------------+ +-------------+ 341 |IPv4->IPv4 | |IPv4->IPv4 | 342 | (A) (BR1) | | (BR4) (B) | 343 +-------------+ +-------------+ 344 |<- A to BR1 ->|<-BR1 to BR2 ->|<-BR3 to BR4 ->| |<-BR4 to B ->| 346 +--------- ------ ---------| 347 +---+ \ / \ / +---+ 348 | A | \ / \ / /| B | 349 +---+\\ \ / \ / // +---+ 350 | \\ | | | | / | 351 | \\ +---+ +---+ +---+ +---+// | 352 | \|BR1+----+BR2+------+BR3+---+BR4+/ | 353 | +---+ +---+ +---+ +---+ | 354 | | | | | | 355 \ LD #1 / \ Internet / \ LD #3 / 356 \ / \ / \ / 357 \ / \ / \ / 358 ------ ------ ------ 360 Figure 3. Routing Procedure 362 for the Next Generation Internet (RANGI) 364 LDBRs are dual-stack routers which could be able to perform source- 365 based policy routing and source address rewriting according to 366 traffic-engineering policies on the outgoing packets. 368 Hosts can get the IPv4 addresses of their local LDBRs in several ways, 369 e.g., a new Dynamic Host Configuration Protocol (DHCP) option, or a 370 site-scope well-known anycast address dedicated for LDBRs. 372 In RANGI, IPv6-over-IPv4 tunnels are deployed in the site networks. 373 Hence, RANGI can achieve a smooth IPv4/IPv6 transition in the scope 374 of site networks. 376 2.6. Site Multi-homing and Traffic-Engineering 378 In RANGI, each multi-homed site shall be assigned a /96 IPv6 prefix 379 from each upstream ISP. Each host inside the multi-homed site, in 380 turn, has multiple locators by concatenating the provider-assigned 381 /96 IPv6 prefix with its locally unique IPv4 address. Hosts register 382 the mappings from their identifiers to locators on the ID->Locator 383 mapping system. As shown in Figure 4, host A is a RANGI host inside a 384 multi-homed site, and it has two locators which are respectively 385 synthesized from the LD IDs delegated from ISP1 and ISP2 and its IPv4 386 address. Host A chooses either one as the source locator of the 387 outgoing packets. Upon receiving the packets, the site border router, 388 BR1, performs source-based policy routing. For example, if the source 389 locator is from ISP1, the packets will be forwarded to ISP1, 390 otherwise, they will be forwarded to ISP2. In addition, BR1 could 391 also rewrite the LD ID of the source locator to the one assigned from 392 another ISP according to the configured traffic-engineering policy, 393 and then forward the packets to the corresponding ISP according to 394 source-based policy routing. Similar to the GSE [GSE], the site- 395 controlled traffic-engineering by rewriting the source LD ID will 396 impact the path (upstream ISP) selection for both outgoing packets 397 and returned packets. 399 In addition, since each ID->locator mapping in the ID->Locator 400 mapping system is associated with a preference. By setting different 401 preference values for different locators of a given host which is 402 located inside a multi-homed site network, the upstream ISP selection 403 for the incoming traffic can also influenced. 405 for the Next Generation Internet (RANGI) 407 ---------- 408 / \ 409 | | 410 +---+ | 411 +BR2| | 412 /+---+ | 413 / | ISP#1 | 414 / \ / 415 /------ / \ / 416 +---* \ / -------- 417 | A | \ / 418 +---+\\ \ / 419 | \\ | / 420 | \\ +---+ / 421 | \|BR1+/ 422 | +---+-- 423 | | -- ---------- 424 \ / -- / \ 425 \ Site A / -- | | 426 \ / -- +---+ | 427 ------ -+BR3| | 428 +---+ | 429 | | 430 \ ISP#2 / 431 \ / 432 -------- 434 Figure 4. Site Multi-homing and Traffic-engineering 436 2.7. Host Mobility and Multi-homing 438 To some extent, host multi-homing is similar to host mobility since 439 their effects on the network and on correspondents are identical. 441 In RANGI, when a host physically moves from one attachment point of 442 network to another in the event of mobility or re-homing, it SHOULD 443 inform its current correspondents of its new locator as soon as 444 possible. Furthermore, it needs to update its locator information on 445 the ID->Locator mapping authoritative server timely. In the case of 446 simultaneous mobility, at least one of the communicating entities 447 SHOULD resolve the correspondence node's new locator from the ID- 448 >Locator mapping system so as to continue their communication. 450 In order to allow legacy IPv6 hosts to initiate communicates with 451 RANGI mobile hosts, many RANGI transit proxies SHOULD be deployed in 452 the transit networks and each of them is dedicated to a bunch of 453 for the Next Generation Internet (RANGI) 455 identifiers in a given AD scope and is responsible for translating 456 packets from IPv6 and RANGI, and vice versa. For more details, please 457 refer to the transit proxy mechanism defined in [RANGI-PROXY]. 459 2.8. Network Mobility 461 To mitigate the registration burden on the ID->Locator mapping system 462 triggered by network mobility, NEMO mechanism [RFC3963] is reused in 463 RANGI to support network mobility. That is to say, the mobile router 464 is responsible for updating its current locator on its home agent. As 465 a result, network mobility event is transparent to the hosts inside 466 that mobile network. Details about network mobility will be explored 467 in the latter version of this draft. 469 3. Summary 471 RANGI achieves almost all of goals set by RRG, which are listed as 472 follows: 474 1) Routing Scalability: Scalability is achieved by separating 475 identifiers from locators. 477 2) Traffic Engineering: Hosts inside a multi-homed site can 478 suggest the upstream ISP for outgoing and returned packets by 479 using the appropriate source locator, while the local LDBRs have 480 the final decision on the upstream ISP selection since they can 481 perform site-controlled traffic-engineering through source locator 482 rewritting. 484 3) Mobility and Multi-homing: Sessions will not be interrupted due to 485 locator change in the case of mobility or re-homing. 487 4) Simplified Renumbering: When changing providers, the local IPv4 488 addresses of the site do not need to change. Hence the internal 489 routers within the site don't need renumbering. 491 5) Decoupling Location and Identifier: Obvious. 493 6) Routing Stability: Since the locators are topologically 494 aggregatable and the internal topology within the LD will not be 495 disclosed outside, routing stability could be improved greatly. 497 7) Routing Security: RANGI reuses existing routing system and does 498 not introduce any new security risk into the routing system. 500 for the Next Generation Internet (RANGI) 502 8) Incremental Deployability: RANGI allows an easy transition from 503 IPv4 networks to IPv6 networks. In addition, RANGI proxy allows 504 RANGI-aware hosts to communicate to legacy IPv4 or IPv6 hosts, 505 and vice-versa. 507 4. Security Considerations 509 TBD. 511 5. IANA Considerations 513 A specific prefix for host IDs needs to be assigned from the IPv6 514 address space. 516 Two new options in the Destination Option Header need to be assigned 517 for the host ID and its corresponding parameter date structure 518 respectively. 520 6. Acknowledgments 522 The author would like to thank Raj Jain, Xuewei Wang and Dacheng 523 Zhang for their valuable contributions. Thanks SHOULD also be given 524 to Paul Francis, Lixia Zhang, Brain Carpenter, Dave Oran, Joel 525 Halpern, and Tony Li for their insightful comments. 527 This research project is partially funded by the National"863" Hi- 528 Tech Program of China. 530 7. References 532 [RAWS] D. Meyer, L. Zhang, and K. Fall. "Report from the IAB Workshop 533 on Routing and Addressing", Internet draft, draft-iab-raws- 534 report-01.txt, work in progress, February 2007. 536 [GOALS] T. Li, "Design Goals for Scalable Internet Routing", draft- 537 irtf-rrg-design-goals-01, July 2007. 539 [RFC4423] R. Moskowitz and P. Nikander, "Host Identity Protocol (HIP) 540 Architecture", RFC 4423, May 2006. 542 [RFC3972] T. Aura, "Cryptographically Generated Addresses (CGA)", 543 RFC3972, Mar 2005. 545 [RFC3963] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert 546 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 547 January 2005. 549 for the Next Generation Internet (RANGI) 551 [RFC5214] F. Templin, T. Gleeson, "Intra-Site Automatic Tunnel 552 Addressing Protocol (ISATAP)", RFC 5214, March, 2008. 554 [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 555 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 556 April 1997. 558 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 559 RFC 2535, March 1999. 561 [RFC3007] B. Wellington, "Secure Domain Name System Dynamic Update", 562 RFC 3007, November 2000. 564 [H-DHT] L. Garces-Erice, E. Biersack, P. Felber, K. Ross, and G. 565 Urvoy-Keller, "Hierarchical Peer-to-peer Systems", In Proc. 566 Euro-Par 2003, Klagenfurt, Austria, 2003. 568 [GSE] M. O'Dell, "GSE-An Alternative Addressing Architecture for 569 IPv6", Internet-Draft, Feb 1997. 571 [LNA] Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia 572 Ratnasamy,Scott Shenker, Ion Stoica and Michael Walfish, "A 573 Layered Naming Architecture for the Internet", Proc. ACM 574 SIGCOMM, Portland, Oregon, USA, August 30 - September 3, 575 2004. 577 [RANGI-PROXY] X. Xu, "Transition Mechanisms for Routing Architecture 578 for the Next Generation Internet (RANGI)", draft-xu-rangi- 579 proxy-01.txt, July 2009. 581 Authors' Addresses 583 Xiaohu Xu 584 Huawei Technologies, 585 No.3 Xinxi Rd., Shang-Di Information Industry Base, 586 Hai-Dian District, Beijing 100085, P.R. China 587 Phone: +86 10 82882573 588 Email: xuxh@huawei.com