idnits 2.17.1 draft-irtf-rrg-recommendation-14.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2010) is 4970 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-frejborg-hipv4-09 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-08 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-04 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-01 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-05 == Outdated reference: A later version (-06) exists of draft-irtf-rrg-design-goals-02 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-03 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-nonce-06 == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-17 == Outdated reference: A later version (-40) exists of draft-templin-intarea-vet-16 == Outdated reference: A later version (-17) exists of draft-templin-iron-12 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force T. Li, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational September 17, 2010 5 Expires: March 21, 2011 7 Recommendation for a Routing Architecture 8 draft-irtf-rrg-recommendation-14 10 Abstract 12 It is commonly recognized that the Internet routing and addressing 13 architecture is facing challenges in scalability, multihoming, and 14 inter-domain traffic engineering. This document presents, as a 15 recommendation of future directions for the IETF, solutions which 16 will aid the future scalability of the Internet. To this end, this 17 document surveys many of the proposals that were brought forward for 18 discussion in this activity, as well as some of the subsequent 19 analysis and the architectural recommendation of the chairs. This 20 document is a product of the Routing Research Group. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 21, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.1. Background to This Document . . . . . . . . . . . . . . . 6 58 1.2. Areas of Group Consensus . . . . . . . . . . . . . . . . . 7 59 1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8 60 2. Locator Identifier Separation Protocol (LISP) . . . . . . . . 9 61 2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 9 63 2.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 10 65 2.1.4. References . . . . . . . . . . . . . . . . . . . . . . 10 66 2.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 2.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 2.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 13 69 3. Routing Architecture for the Next Generation Internet 70 (RANGI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 3.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 13 73 3.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 13 74 3.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 14 75 3.1.4. References . . . . . . . . . . . . . . . . . . . . . . 14 76 3.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 3.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 3.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 16 79 4. Internet Vastly Improved Plumbing (Ivip) . . . . . . . . . . . 16 80 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 4.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 17 82 4.1.2. Extensions . . . . . . . . . . . . . . . . . . . . . . 18 83 4.1.2.1. TTR Mobility . . . . . . . . . . . . . . . . . . . 18 84 4.1.2.2. Modified Header Forwarding . . . . . . . . . . . . 18 85 4.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 19 86 4.1.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 19 87 4.1.5. References . . . . . . . . . . . . . . . . . . . . . . 19 88 4.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 4.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 4.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 22 91 5. Hierarchical IPv4 Framework (hIPv4) . . . . . . . . . . . . . 22 92 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 5.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 22 94 5.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 23 95 5.1.3. Costs And Issues . . . . . . . . . . . . . . . . . . . 24 96 5.1.4. References . . . . . . . . . . . . . . . . . . . . . . 24 97 5.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 5.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 5.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 26 100 6. Name overlay (NOL) service for scalable Internet routing . . . 26 101 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 6.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 26 103 6.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 26 104 6.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 27 105 6.1.4. References . . . . . . . . . . . . . . . . . . . . . . 28 106 6.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 6.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 29 108 6.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 30 109 7. Compact routing in locator identifier mapping system (CRM) . . 30 110 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 7.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 30 112 7.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 30 113 7.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 31 114 7.1.4. References . . . . . . . . . . . . . . . . . . . . . . 31 115 7.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 7.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 32 117 7.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 33 118 8. Layered mapping system (LMS) . . . . . . . . . . . . . . . . . 33 119 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 33 120 8.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 33 121 8.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 33 122 8.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 34 123 8.1.4. References . . . . . . . . . . . . . . . . . . . . . . 34 124 8.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 34 125 8.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 35 126 8.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 35 127 9. 2-phased mapping . . . . . . . . . . . . . . . . . . . . . . . 35 128 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 35 129 9.1.1. Considerations . . . . . . . . . . . . . . . . . . . . 35 130 9.1.2. Basics of a 2-phased mapping . . . . . . . . . . . . . 36 131 9.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 36 132 9.1.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 37 133 9.1.5. References . . . . . . . . . . . . . . . . . . . . . . 37 134 9.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 37 135 9.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 37 136 9.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 37 137 10. Global Locator, Local Locator, and Identifier Split 138 (GLI-Split) . . . . . . . . . . . . . . . . . . . . . . . . . 37 139 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 37 140 10.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 37 141 10.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 38 142 10.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 39 143 10.1.4. References . . . . . . . . . . . . . . . . . . . . . . 39 145 10.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 39 146 10.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 40 147 10.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 41 148 11. Tunneled Inter-domain Routing (TIDR) . . . . . . . . . . . . . 41 149 11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 41 150 11.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 41 151 11.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 41 152 11.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 42 153 11.1.4. References . . . . . . . . . . . . . . . . . . . . . . 42 154 11.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 42 155 11.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 43 156 11.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 43 157 12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 44 158 12.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 44 159 12.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 44 160 12.1.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . 44 161 12.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 46 162 12.1.4. References . . . . . . . . . . . . . . . . . . . . . . 46 163 12.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 46 164 12.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 47 165 12.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 49 166 13. Enhanced Efficiency of Mapping Distribution Protocols in 167 Map-and-Encap Schemes (EEMDP) . . . . . . . . . . . . . . . . 49 168 13.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 49 169 13.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 49 170 13.1.2. Management of Mapping Distribution of Subprefixes 171 Spread Across Multiple ETRs . . . . . . . . . . . . . 49 172 13.1.3. Management of Mapping Distribution for Scenarios 173 with Hierarchy of ETRs and Multihoming . . . . . . . . 50 174 13.1.4. References . . . . . . . . . . . . . . . . . . . . . . 51 175 13.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 51 176 13.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 52 177 13.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 53 178 14. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 53 179 14.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 53 180 14.1.1. Need for Evolution . . . . . . . . . . . . . . . . . . 54 181 14.1.2. Relation to Other RRG Proposals . . . . . . . . . . . 54 182 14.1.3. Aggregation with Increasing Scopes . . . . . . . . . . 54 183 14.1.4. References . . . . . . . . . . . . . . . . . . . . . . 56 184 14.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 56 185 14.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 57 186 14.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 57 187 15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 57 188 15.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 57 189 15.1.1. References . . . . . . . . . . . . . . . . . . . . . . 59 190 15.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 59 191 15.2.1. Deployment . . . . . . . . . . . . . . . . . . . . . . 60 192 15.2.2. Edge-networks . . . . . . . . . . . . . . . . . . . . 60 194 15.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 60 195 15.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 60 196 16. Routing and Addressing in Networks with Global Enterprise 197 Recursion (IRON-RANGER) . . . . . . . . . . . . . . . . . . . 61 198 16.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 61 199 16.1.1. Gains . . . . . . . . . . . . . . . . . . . . . . . . 61 200 16.1.2. Costs . . . . . . . . . . . . . . . . . . . . . . . . 62 201 16.1.3. References . . . . . . . . . . . . . . . . . . . . . . 62 202 16.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 62 203 16.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 63 204 16.4. Counterpoint . . . . . . . . . . . . . . . . . . . . . . . 64 205 17. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 64 206 17.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 65 207 17.2. Recommendation to the IETF . . . . . . . . . . . . . . . . 66 208 17.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 66 209 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 210 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 211 20. Security Considerations . . . . . . . . . . . . . . . . . . . 67 212 21. Informative References . . . . . . . . . . . . . . . . . . . . 67 213 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73 215 1. Introduction 217 It is commonly recognized that the Internet routing and addressing 218 architecture is facing challenges in scalability, multihoming, and 219 inter-domain traffic engineering. The problem being addressed has 220 been documented in [I-D.narten-radir-problem-statement], and the 221 design goals that we have discussed can be found in 222 [I-D.irtf-rrg-design-goals]. 224 This document surveys many of the proposals that were brought forward 225 for discussion in this activity. For some of the proposals, this 226 document also includes additional analysis showing some of the 227 concerns with specific proposals, and how some of those concerns may 228 be addressed. Readers are cautioned not to draw any conclusions 229 about the degree of interest or endorsement by the Routing Research 230 Group (RRG) from the presence of any proposals in this document, or 231 the amount of analysis devoted to specific proposals. 233 1.1. Background to This Document 235 The RRG was chartered to research and recommend a new routing 236 architecture for the Internet. The goal was to explore many 237 alternatives and build consensus around a single proposal. The only 238 constraint on the group's process was that the process be open and 239 the group set forth with the usual process of discussing proposals 240 and trying to build consensus around them. There were no explicit 241 contingencies in the group's process for the eventuality that the 242 group did not reach consensus. 244 The group met at every IETF meeting from March 2007 to March 2010 and 245 discussed many proposals, both in person and via its mailing list. 246 Unfortunately, the group did not reach consensus. Rather than lose 247 the contributions and progress that had been made, the chairs (Lixia 248 Zhang, Tony Li) elected to collect the proposals of the group and 249 some of the debate concerning the proposals and make a recommendation 250 from those proposals. Thus, the recommendation reflects the opinions 251 of the chairs and not necessarily the consensus of the group. 253 The group was able to reach consensus on a number of items that are 254 included below. The proposals included here were collected in an 255 open call amongst the group. Once the proposals were collected, the 256 group was solicited to submit critiques of each proposal. The group 257 was asked to self-organize to produce a single critique for each 258 proposal. In cases where there were several critiques submitted, the 259 editor selected one. The proponents of each proposal then were given 260 the opportunity to write a rebuttal of the critique. Finally, the 261 group again had the opportunity to write a counterpoint of the 262 rebuttal. For pragmatic reasons, each submission was severely 263 constrained in length. 265 All of the proposals were given the opportunity to progress their 266 documents to RFC status, however, not all of them have chosen to 267 pursue this path. As a result, some of the references in this 268 document may become inaccessible. This is unfortunately unavoidable. 270 The group did reach consensus that the overall document should be 271 published. The document has been reviewed by many of the active 272 members of the Research Group. 274 1.2. Areas of Group Consensus 276 The group was also able to reach broad and clear consensus on some 277 terminology and several important technical points. For the sake of 278 posterity, these are recorded here: 280 1. A "node" is either a host or a router. 282 2. A "router" is any device that forwards packets at the Network 283 Layer (e.g. IPv4, IPv6) of the Internet Architecture. 285 3. A "host" is a device that can send/receive packets to/from the 286 network, but does not forward packets. 288 4. A "bridge" is a device that forwards packets at the Link Layer 289 (e.g. Ethernet) of the Internet Architecture. An Ethernet 290 switch or Ethernet hub are examples of bridges. 292 5. An "address" is an object that combines aspects of identity with 293 topological location. IPv4 and IPv6 addresses are current 294 examples. 296 6. A "locator" is a structured topology-dependent name that is not 297 used for node identification, and is not a path. Two related 298 meanings are current, depending on the class of things being 299 named: 301 1. The topology-dependent name of a node's interface. 303 2. The topology-dependent name of a single subnetwork OR 304 topology-dependent name of a group of related subnetworks 305 that share a single aggregate. An IP routing prefix is a 306 current example of this last. 308 7. An "identifier" is a topology-independent name for a logical 309 node. Depending upon instantiation, a "logical node" might be a 310 single physical device, a cluster of devices acting as a single 311 node, or a single virtual partition of a single physical device. 312 An OSI End System Identifier (ESID) is an example of an 313 identifier. A Fully-Qualified Domain Name that precisely names 314 one logical node is another example. (Note well that not all 315 FQDNs meet this definition.) 317 8. Various other names (i.e. other than addresses, locators, or 318 identifiers), each of which has the sole purpose of identifying 319 a component of a logical system or physical device, might exist 320 at various protocol layers in the Internet Architecture. 322 9. The Research Group has rough consensus that separating identity 323 from location is desirable and technically feasible. However, 324 the Research Group does NOT have consensus on the best 325 engineering approach to such an identity/location split. 327 10. The Research Group has consensus that the Internet needs to 328 support multihoming in a manner that scales well and does not 329 have prohibitive costs. 331 11. Any IETF solution to Internet scaling has to not only support 332 multihoming, but address the real-world constraints of the end 333 customers (large and small). 335 1.3. Abbreviations 337 This section lists some of the most common abbreviations used in the 338 remainder of this document. 340 DFZ Default-Free Zone 342 EID Endpoint IDentifer: The precise definition varies depending on 343 the proposal. 345 ETR Egress Tunnel Router: In a system that tunnels traffic across 346 the existing infrastructure by encapsulating it, the device close 347 to the actual ultimate destination that decapsulates the traffic 348 before forwarding it to the ultimate destination. 350 FIB Forwarding Information Base: The forwarding table, used in the 351 data plane of routers to select the next hop for each packet. 353 ITR Ingress Tunnel Router: In a system that tunnels traffic across 354 the existing infrastructure by encapsulating it, the device close 355 to the actual original source that encapsulates the traffic before 356 using the tunnel to send it to the appropriate ETR. 358 PA Provider Aggregatable: Address space that can be aggregated as 359 part of a service provider's routing advertisements. 361 PI Provider Independent: Address space assigned by an Internet 362 registry independent of any service provider. 364 PMTUD Path Maximum Transmission Unit Discovery: The process or 365 mechanism that determines the largest packet that can be sent 366 between a given source and destination with being either i) 367 fragmented (IPv4 only), or ii) discarded (if not fragmentable) 368 because it is too large to be sent down one link in the path from 369 the source to the destination. 371 RIB Routing Information Base. The routing table, used in the 372 control plane of routers to exchange routing information and 373 construct the FIB. 375 RLOC Routing LOCator: The precise definition varies depending on the 376 proposal. 378 xTR Tunnel Router: In some systems, the term used to describe a 379 device which can function as both an ITR and an ETR. 381 2. Locator Identifier Separation Protocol (LISP) 383 2.1. Summary 385 2.1.1. Key Idea 387 Implements a locator-identifier separation mechanism using 388 encapsulation between routers at the "edge" of the Internet. Such a 389 separation allows topological aggregation of the routable addresses 390 (locators) while providing stable and portable numbering of end 391 systems (identifiers). 393 2.1.2. Gains 395 o topological aggregation of locator space (RLOCs) used for routing, 396 which greatly reduces both the overall size and the "churn rate" 397 of the information needed to operate the Internet global routing 398 system 400 o separate identifier space (EIDs) for end-systems, effectively 401 allowing "PI for all" (no renumbering cost for connectivity 402 changes) without adding state to the global routing system 404 o improved traffic engineering capabilities that explicitly do not 405 add state to the global routing system and whose deployment will 406 allow active removal of the more-specific state that is currently 407 used 409 o no changes required to end systems 411 o no changes to Internet "core" routers 413 o minimal and straightforward changes to "edge" routers 415 o day-one advantages for early adopters 417 o defined router-to-router protocol 419 o defined database mapping system 421 o defined deployment plan 423 o defined interoperability/interworking mechanisms 425 o defined scalable end-host mobility mechanisms 427 o prototype implementation already exists and undergoing testing 429 o production implementations in progress 431 2.1.3. Costs 433 o mapping system infrastructure (map servers, map resolvers, ALT 434 routers) (new potential business opportunity) 436 o Interworking infrastructure (proxy ITRs) (new potential business 437 opportunity) 439 o overhead for determining/maintaining locator/path liveness (common 440 issue for all id/loc separation proposals) 442 2.1.4. References 444 [I-D.ietf-lisp] [I-D.ietf-lisp-alt] [I-D.ietf-lisp-ms] 445 [I-D.ietf-lisp-interworking] [I-D.meyer-lisp-mn] 446 [I-D.farinacci-lisp-lig] [I-D.meyer-loc-id-implications] 448 2.2. Critique 450 LISP-ALT distributes mapping information to ITRs via (optional, 451 local, potentially caching) Map Resolvers and with globally 452 distributed query servers: ETRs and optional Map Servers (MS). 454 A fundamental problem with any global query server network is that 455 the frequently long paths and greater risk of packet loss may cause 456 ITRs to drop or significantly delay the initial packets of many new 457 sessions. ITRs drop the packet(s) they have no mapping for. After 458 the mapping arrives, the ITR waits for a resent packet and will 459 tunnel that packet correctly. These "initial packet delays" reduce 460 performance and so create a major barrier to voluntary adoption on 461 wide enough basis to solve the routing scaling problem. 463 ALT's delays are compounded by its structure being "aggressively 464 aggregated", without regard to the geographic location of the 465 routers. Tunnels between ALT routers will often span 466 intercontinental distances and traverse many Internet routers. 468 The many levels to which a query typically ascends in the ALT 469 hierarchy before descending towards its destination will often 470 involve excessively long geographic paths and so worsen initial 471 packet delays. 473 No solution has been proposed for these problems or for the 474 contradiction between the need for high aggregation while making the 475 ALT structure robust against single points of failure. 477 LISP's ITRs multihoming service restoration depends on them 478 determining reachability of end-user networks via two or more ETRs. 479 Large numbers of ITRs doing this is inefficient and may overburden 480 ETRs. 482 Testing reachability of the ETRs is complex and costly - and 483 insufficient. ITRs cannot test network reachability via each ETR, 484 since the ITRs have no address of a device in that network. So ETRs 485 must report network un-reachability to ITRs. 487 LISP involves complex communication between ITRs and ETRs, with UDP 488 and 64-bit LISP headers in all traffic packets. 490 The advantage of LISP+ALT is that its ability to handle billions of 491 EIDs is not constrained by the need to transmit or store the mapping 492 to any one location. Such numbers, beyond a few tens of millions of 493 EIDs, will only result if the system is used for Mobility. Yet the 494 concerns just mentioned about ALT's structure arise from the millions 495 of ETRs which would be needed just for non-mobile networks. 497 In LISP's mobility approach each Mobile Node (MN) needs an RLOC 498 address to be its own ETR, meaning the MN cannot be behind NAT. 499 Mapping changes must be sent instantly to all relevant ITRs every 500 time the MN gets a new address - which LISP cannot achieve. 502 In order to enforce ISP filtering of incoming packets by source 503 address, LISP ITRs would have to implement the same filtering on each 504 decapsulated packet. This may be prohibitively expensive. 506 LISP monolithically integrates multihoming failure detection and 507 restoration decision-making processes into the Core-Edge Separation 508 (CES) scheme itself. End-user networks must rely on the necessarily 509 limited capabilities which are built into every ITR. 511 LISP-ALT may be able to solve the routing scaling problem, but 512 alternative approaches would be superior because they eliminate the 513 initial packet delay problem and give end-user networks real-time 514 control over ITR tunneling. 516 2.3. Rebuttal 518 Initial-packet loss/delays turn out not to be a deep issue. 519 Mechanisms for interoperation with the legacy part of the network are 520 needed in any viably deployable design, and LISP has such mechanisms. 521 If needed, initial packets can be sent via those legacy mechanisms 522 until the ITR has a mapping. (Field experience has shown that the 523 caches on those interoperation devices are guaranteed to be 524 populated, as 'crackers' doing address-space sweeps periodically send 525 packets to every available mapping.) 527 On ALT issues, it is not at all mandatory that ALT be the mapping 528 system used in the long term. LISP has a standardized mapping system 529 interface, in part to allow reasonably smooth deployment of whatever 530 new mapping system(s) experience might show are required. At least 531 one other mapping system (LISP-TREE), which avoids ALT's problems 532 (such as query load concentration at high-level nodes), has already 533 been laid out and extensively simulated. Exactly what mixture of 534 mapping system(s) is optimal is not really answerable without more 535 extensive experience, but LISP is designed to allow evolutionary 536 changes to other mapping system(s). 538 As far as ETR reachability goes, a potential problem to which there 539 is a solution which has an adequate level of efficiency, complexity 540 and robustness is not really a problem. LISP has a number of 541 overlapping mechanisms which it is believed will provide adequate 542 reachability detection (along the three axes above), and in field 543 testing to date, they have behaved as expected. 545 Operation of LISP devices behind a NAT has already been demonstrated. 546 A number of mechanisms to update correspondent nodes when a mapping 547 is updated have been designed (some are already in use). 549 2.4. Counterpoint 551 No counterpoint was submitted for this proposal. 553 3. Routing Architecture for the Next Generation Internet (RANGI) 555 3.1. Summary 557 3.1.1. Key Idea 559 Similar to Host Identity Protocol (HIP) [RFC4423], RANGI introduces a 560 host identifier layer between the network layer and the transport 561 layer, and the transport-layer associations (i.e., TCP connections) 562 are no longer bound to IP addresses, but to host identifiers. The 563 major difference from HIP is that the host identifier in RANGI is a 564 128-bit hierarchical and cryptographic identifier which has 565 organizational structure. As a result, the corresponding ID->locator 566 mapping system for such identifiers has a reasonable business model 567 and clear trust boundaries. In addition, RANGI uses IPv4-embedded 568 IPv6 addresses as locators. The Locator Domain Identifier (LD ID) 569 (i.e., the leftmost 96 bits) of this locator is a provider-assigned 570 /96 IPv6 prefix, while the last four octets of this locator is a 571 local IPv4 address (either public or private). This special locator 572 could be used to realize 6over4 automatic tunneling (borrowing ideas 573 from ISATAP [RFC5214]), which will reduce the deployment cost of this 574 new routing architecture. Within RANGI, the mappings from FQDN to 575 host identifiers are stored in the DNS system, while the mappings 576 from host identifiers to locators are stored in a distributed id/ 577 locator mapping system (e.g., a hierarchical Distributed Hash Table 578 (DHT) system, or a reverse DNS system). 580 3.1.2. Gains 582 RANGI achieves almost all of the goals set forth by RRG as follows: 584 1. Routing Scalability: Scalability is achieved by decoupling 585 identifiers from locators. 587 2. Traffic Engineering: Hosts located in a multihomed site can 588 suggest the upstream ISP for outbound and inbound traffic, while 589 the first-hop Locator Domain Border Router (LDBR) (i.e., site 590 border router) has the final decision on the upstream ISP 591 selection. 593 3. Mobility and Multihoming: Sessions will not be interrupted due to 594 locator change in cases of mobility or multihoming. 596 4. Simplified Renumbering: When changing providers, the local IPv4 597 addresses of the site do not need to change. Hence the internal 598 routers within the site don't need renumbering. 600 5. Decoupling Location and Identifier: Obvious. 602 6. Routing Stability: Since the locators are topologically 603 aggregatable and the internal topology within the LD will not be 604 disclosed outside, routing stability could be improved greatly. 606 7. Routing Security: RANGI reuses the current routing system and 607 does not introduce any new security risks into the routing 608 system. 610 8. Incremental Deployability: RANGI allows an easy transition from 611 IPv4 networks to IPv6 networks. In addition, RANGI proxy allows 612 RANGI-aware hosts to communicate to legacy IPv4 or IPv6 hosts, 613 and vice-versa. 615 3.1.3. Costs 617 1. A host change is required. 619 2. The first-hop LDBR change is required to support site-controlled 620 traffic-engineering capability. 622 3. The ID->Locator mapping system is a new infrastructure to be 623 deployed. 625 4. RANGI proxy needs to be deployed for communication between RANGI- 626 aware hosts and legacy hosts. 628 3.1.4. References 630 [RFC3007] [RFC4423] [I-D.xu-rangi] [I-D.xu-rangi-proxy] [RANGI] 632 3.2. Critique 634 RANGI is an ID/locator split protocol that, like HIP, places a 635 cryptographically signed ID between the network layer (IPv6) and 636 transport. Unlike the HIP ID, the RANGI ID has a hierarchical 637 structure that allows it to support ID->locator lookups. This 638 hierarchical structure addresses two weaknesses of the flat HIP ID: 639 the difficulty of doing the ID->locator lookup, and the 640 administrative scalability of doing firewall filtering on flat IDs. 641 The usage of this hierarchy is overloaded: it serves to make the ID 642 unique, to drive the lookup process, and possibly other things like 643 firewall filtering. More thought is needed as to what constitutes 644 these levels with respect to these various roles. 646 The RANGI draft suggests FQDN->ID lookup through DNS, and separately 647 an ID->locator lookup which may be DNS or may be something else (a 648 hierarchy of DHTs). It would be more efficient if the FQDN lookup 649 produces both ID and locators (as does ILNP). Probably DNS alone is 650 sufficient for the ID->locator lookup since individual DNS servers 651 can hold very large numbers of mappings. 653 RANGI provides strong sender identification, but at the cost of 654 computing crypto. Many hosts (public web servers) may prefer to 655 forgo the crypto at the expense of losing some functionality 656 (receiver mobility or dynamic multihome load balance). While RANGI 657 doesn't require that the receiver validate the sender, it may be good 658 to have a mechanism whereby the receiver can signal to the sender 659 that it is not validating, so that the sender can avoid locator 660 changes. 662 Architecturally there are many advantages to putting the mapping 663 function at the end host (versus at the edge). This simplifies the 664 neighbor aliveness and delayed first packet problems, and avoids 665 stateful middleboxes. Unfortunately, the early-adopter incentive for 666 host upgrade may not be adequate (HIP's lack of uptake being an 667 example). 669 RANGI does not have an explicit solution for the mobility race 670 condition (there is no mention of a home-agent like device). 671 However, host-to-host notification combined with fallback on the 672 ID->locators lookup (assuming adequate dynamic update of the lookup 673 system) may be good enough for the vast majority of mobility 674 situations. 676 RANGI uses proxies to deal with both legacy IPv6 and IPv4 sites. 677 RANGI proxies have no mechanisms to deal with the edge-to-edge 678 aliveness problem. The edge-to-edge proxy approach dirties-up an 679 otherwise clean end-to-end model. 681 RANGI exploits existing IPv6 transition technologies (ISATAP and 682 softwire). These transition technologies are in any event being 683 pursued outside of RRG and do not need to be specified in RANGI 684 drafts per se. RANGI only needs to address how it interoperates with 685 IPv4 and legacy IPv6, which through proxies it appears to do 686 adequately well. 688 3.3. Rebuttal 690 The reason why the ID->Locator lookup is separated from the FQDN->ID 691 lookup is: 1) not all applications are tied to FQDNs, and 2) it seems 692 unnecessary to require all devices to possess a FQDN of their own. 693 Basically RANGI uses DNS to realize the ID->Locator mapping system. 694 If there are too many entries to be maintained by the authoritative 695 servers of a given Administrative Domain (AD), Distribute Hash Table 696 (DHT) technology can be used to make these authoritative servers 697 scale better, e.g., the mappings maintained by a given AD will be 698 distributed among a group of authoritative servers in a DHT fashion. 699 As a result, the robustness feature of DHT is inherited naturally 700 into the ID->Locator mapping system. Meanwhile, there is no trust 701 issue since each AD authority runs its own DHT ring which maintains 702 only the mappings for those identifiers that are administrated by 703 that AD authority. 705 For host mobility, if communicating entities are RANGI nodes, the 706 mobile node will notify the correspondent node of its new locator 707 once its locator changes due to a mobility or re-homing event. 708 Meanwhile, it should also update its locator information in the 709 ID->Locator mapping system in a timely fashion by using the Secure 710 DNS Dynamic Update mechanism defined in [RFC3007]. In case of 711 simultaneous mobility, at least one of the nodes has to resort to the 712 ID->Locator mapping system for resolving the correspondent node's new 713 locator so as to continue their communication. If the correspondent 714 node is a legacy host, Transit Proxies, which play a similar function 715 to the home-agents in Mobile IP, will relay the packets between the 716 communicating parties. 718 RANGI uses proxies (e.g., Site Proxy and Transit Proxy) to deal with 719 both legacy IPv6 and IPv4 sites. Since proxies function as RANGI 720 hosts, they can handle Locator Update Notification messages sent from 721 remote RANGI hosts (or even from remote RANGI proxies) correctly. 722 Hence there is no edge-to-edge aliveness problem. Details will be 723 specified in the latter version of RANGI-PROXY. 725 The intention behind RANGI using IPv4-embedded IPv6 addresses as 726 locators is to reduce the total deployment cost of this new Internet 727 architecture and to avoid renumbering the site internal routers when 728 such a site changes ISPs. 730 3.4. Counterpoint 732 No counterpoint was submitted for this proposal. 734 4. Internet Vastly Improved Plumbing (Ivip) 735 4.1. Summary 737 4.1.1. Key Ideas 739 Ivip (pr. eye-vip, est. 2007-06-15) is a core-edge separation scheme 740 for IPv4 and IPv6. It provides multihoming, portability of address 741 space and inbound traffic engineering for end-user networks of all 742 sizes and types, including those of corporations, SOHO and mobile 743 devices. 745 Ivip meets all the constraints imposed by the need for widespread 746 voluntary adoption [Ivip Constraints]. 748 Ivip's global fast-push mapping distribution network is structured 749 like a cross-linked multicast tree. This pushes all mapping changes 750 to full database query servers (QSDs) within ISPs and end-user 751 networks which have ITRs. Each mapping change is sent to all QSDs 752 within a few seconds. 754 ITRs gain mapping information from these local QSDs within a few tens 755 of milliseconds. QSDs notify ITRs of changed mappings with similarly 756 low latency. ITRs tunnel all traffic packets to the correct ETR 757 without significant delay. 759 Ivip's mapping consists of a single ETR address for each range of 760 mapped address space. Ivip ITRs do not need to test reachability to 761 ETRs because the mapping is changed in real-time to that of the 762 desired ETR. 764 End-user networks control the mapping, typically by contracting a 765 specialized company to monitor the reachability of their ETRs and 766 change the mapping to achieve multihoming and/or Traffic Engineering 767 (TE). So the mechanisms which control ITR tunneling are controlled 768 by the end-user networks in real-time and are completely separate 769 from the core-edge separation scheme itself. 771 ITRs can be implemented in dedicated servers or hardware-based 772 routers. The ITR function can also be integrated into sending hosts. 773 ETRs are relatively simple and only communicate with ITRs rarely - 774 for Path MTU management with longer packets. 776 Ivip-mapped ranges of end-user address space need not be subnets. 777 They can be of any length, in units of IPv4 addresses or IPv6 /64s. 779 Compared to conventional unscalable BGP techniques, and to the use of 780 core-edge separation architectures with non-real-time mapping 781 systems, end-user networks will be able to achieve more flexible and 782 responsive inbound TE. If inbound traffic is split into several 783 streams, each to addresses in different mapped ranges, then real-time 784 mapping changes can be used to steer the streams between multiple 785 ETRs at multiple ISPs. 787 Default ITRs in the DFZ (DITRs, similar to LISP's Proxy Tunnel 788 Routers) tunnel packets sent by hosts in networks which lack ITRs. 789 So multihoming, portability and TE benefits apply to all traffic. 791 ITRs request mappings either directly from a local QSD or via one or 792 more layers of caching query servers (QSCs) which in turn request it 793 from a local QSD. QSCs are optional but generally desirable since 794 they reduce the query load on QSDs. 796 ETRs may be in ISP or end-user networks. IP-in-IP encapsulation is 797 used, so there is no UDP or any other header. PMTUD (Path MTU 798 Discovery) management with minimal complexity and overhead will 799 handle the problems caused by encapsulation, and adapt smoothly to 800 jumbo frame paths becoming available in the DFZ. The outer header's 801 source address is that of the sending host - which enables existing 802 ISP Border Router (BR) filtering of source addresses to be extended 803 to encapsulated traffic packets by the simple mechanism of the ETR 804 dropping packets whose inner and outer source address do not match. 806 4.1.2. Extensions 808 4.1.2.1. TTR Mobility 810 The Translating Tunnel Router (TTR) approach to mobility [Ivip 811 Mobility] is applicable to all core-edge separation techniques and 812 provides scalable IPv4 and IPv6 mobility in which the MN keeps its 813 own mapped IP address(es) no matter how or where it is physically 814 connected, including behind one or more layers of NAT. 816 Path-lengths are typically optimal or close to optimal and the MN 817 communicates normally with all other non-mobile hosts (no stack or 818 app changes), and of course other MNs. Mapping changes are only 819 needed when the MN uses a new TTR, which would typically be if the MN 820 moved more than 1000km. Mapping changes are not required when the MN 821 changes its physical address(es). 823 4.1.2.2. Modified Header Forwarding 825 Separate schemes for IPv4 and IPv6 enable tunneling from ITR to ETR 826 without encapsulation. This will remove the encapsulation overhead 827 and PMTUD problems. Both approaches involve modifying all routers 828 between the ITR and ETR to accept a modified form of the IP header. 829 These schemes require new FIB/RIB functionality in DFZ and some other 830 routers but do not alter the BGP functions of DFZ routers. 832 4.1.3. Gains 834 Amenable to widespread voluntary adoption due to no need for host 835 changes, complete support for packets sent from non-upgraded networks 836 and no significant degradation in performance. 838 Modular separation of the control of ITR tunneling behavior from the 839 ITRs and the core-edge separation scheme itself: end-user networks 840 control mapping in any way they like, in real-time. 842 A small fee per mapping change deters frivolous changes and helps pay 843 for pushing the mapping data to all QSDs. End-user networks who make 844 frequent mapping changes for inbound TE, should find these fees 845 attractive considering how it improves their ability to utilize the 846 bandwidth of multiple ISP links. 848 End-user networks will typically pay the cost of Open ITR in the DFZ 849 (OITRD) forwarding to their networks. This provides a business model 850 for OITRD deployment and avoids unfair distribution of costs. 852 Existing source address filtering arrangements at BRs of ISPs and 853 end-user networks are prohibitively expensive to implement directly 854 in ETRs, but with the outer header's source address being the same as 855 the sending host's address, Ivip ETRs inexpensively enforce BR 856 filtering on decapsulated packets. 858 4.1.4. Costs 860 QSDs receive all mapping changes and store a complete copy of the 861 mapping database. However, a worst case scenario is 10 billion IPv6 862 mappings, each of 32 bytes, which fits on a consumer hard drive today 863 and should fit in server DRAM by the time such adoption is reached. 865 The maximum number of non-mobile networks requiring multihoming etc. 866 is likely to be ~10M, so most of the 10B mappings would be for mobile 867 devices. However, TTR mobility does not involve frequent mapping 868 changes since most MNs only rarely move more than 1000km. 870 4.1.5. References 872 [I-D.whittle-ivip4-etr-addr-forw] [Ivip PMTUD] [Ivip6] [Ivip 873 Constraints] [Ivip Mobility] [I-D.whittle-ivip-drtm] 874 [I-D.whittle-ivip-glossary] 876 4.2. Critique 878 Looked at from the thousand foot level, Ivip shares the basic design 879 approaches with LISP and a number of other Map-and-Encap designs 880 based on the core-edge separation. However the details differ 881 substantially. Ivip's design makes a bold assumption that, with 882 technology advances, one could afford to maintain a real time 883 distributed global mapping database for all networks and hosts. Ivip 884 proposes that multiple parties collaborate to build a mapping 885 distribution system that pushes all mapping information and updates 886 to local, full database query servers located in all ISPs within a 887 few seconds. The system has no single point of failure, and uses 888 end-to-end authentication. 890 A "real time, globally synchronized mapping database" is a critical 891 assumption in Ivip. Using that as a foundation, Ivip design avoids 892 several challenging design issues that others have studied 893 extensively, that include 895 1. special considerations of mobility support that add additional 896 complexity to the overall system; 898 2. prompt detection of ETR failures and notification to all relevant 899 ITRs, which turns out to be a rather difficult problem; and 901 3. development of a partial-mapping lookup sub-system. Ivip assumes 902 the existence of local query servers with a full database with 903 the latest mapping information changes. 905 To be considered as a viable solution to Internet routing scalability 906 problem, Ivip faces two fundamental questions. First, whether a 907 global-scale system can achieve real time synchronized operations as 908 assumed by Ivip is an entirely open question. Past experiences 909 suggest otherwise. 911 The second question concerns incremental rollout. Ivip represents an 912 ambitious approach, with real-time mapping and local full database 913 query servers - which many people regard as impossible. Developing 914 and implementing Ivip may take a fair amount of resources, yet there 915 is an open question regarding how to quantify the gains by first 916 movers - both those who will provide the Ivip infrastructure and 917 those that will use it. Significant global routing table reduction 918 only happens when a large enough number of parties have adopted Ivip. 919 The same question arises for most other proposals as well. 921 One belief is that Ivip's more ambitious mapping system makes a good 922 design tradeoff for the greater benefits for end-user networks and 923 for those which develop the infrastructure. Another belief is that 924 this ambitious design is not viable. 926 4.3. Rebuttal 928 Since the Summary and Critique were written, Ivip's mapping system 929 has been significantly redesigned: DRTM - Distributed Real Time 930 Mapping [I-D.whittle-ivip-drtm]. 932 DRTM makes it easier for ISPs to install their own ITRs. It also 933 facilitates Mapped Address Block (MAB) operating companies - which 934 need not be ISPs - leasing Scalable Provider Independent (SPI) 935 address space to end-user networks with almost no ISP involvement. 936 ISPs need not install ITRs or ETRs. For an ISP to support its 937 customers using SPI space, they need only allow the forwarding of 938 outgoing packets whose source addresses are from SPI space. End-user 939 networks can implement their own ETRs on their existing PA 940 address(es) - and MAB operating companies make all the initial 941 investments. 943 Once SPI adoption becomes widespread, ISPs will be motivated to 944 install their own ITRs to locally tunnel packets sent from customer 945 networks which must be tunneled to SPI-using customers of the same 946 ISP - rather than letting these packets exit the ISP's network and 947 return in tunnels to ETRs in the network. 949 There is no need for full-database query servers in ISPs or for any 950 device which stores the full mapping information for all Mapped 951 Address Blocks (MABs). ISPs that want ITRs will install two or more 952 Map Resolver (MR) servers. These are caching query servers which 953 query multiple typically nearby query servers which are full-database 954 for the subset of MABs they serve. These "nearby" query servers will 955 be at DITR sites, which will be run by, or for, MAB operating 956 companies who lease MAB space to large numbers of end-user networks. 957 These DITR-site servers will usually be close enough to the MRs to 958 generate replies with sufficiently low delay and risk of packet loss 959 for ITRs to buffer initial packets for a few tens of milliseconds 960 while the mapping arrives. 962 DRTM will scale to billions of micronets, tens of thousands of MABs 963 and potentially hundreds of MAB operating companies, without single 964 points of failure or central coordination. 966 The critique implies a threshold of adoption is required before 967 significant routing scaling benefits occur. This is untrue of any 968 Core-Edge Separation proposal, including LISP and Ivip. Both can 969 achieve scalable routing benefits in direct proportion to their level 970 of adoption by providing portability, multihoming and inbound TE to 971 large numbers of end-user networks. 973 Core-Edge Elimination (CEE) architectures require all Internet 974 communications to change to IPv6 with a new Locator/Identifier 975 Separation naming model. This would impose burdens of extra 976 management effort, packets and session establishment delays on all 977 hosts - which is a particularly unacceptable burden on battery- 978 operated mobile hosts which rely on wireless links. 980 Core-Edge Separation architectures retain the current, efficient, 981 naming model, require no changes to hosts and support both IPv4 and 982 IPv6. Ivip is the most promising architecture for future development 983 because its scalable, distributed, real-time mapping system best 984 supports TTR Mobility, enables ITRs to be simpler and gives real-time 985 control of ITR tunneling to the end-user network or to organizations 986 they appoint to control the mapping of their micronets. 988 4.4. Counterpoint 990 No counterpoint was submitted for this proposal. 992 5. Hierarchical IPv4 Framework (hIPv4) 994 5.1. Summary 996 5.1.1. Key Idea 998 The Hierarchical IPv4 Framework (hIPv4) adds scalability to the 999 routing architecture by introducing additional hierarchy in the IPv4 1000 address space. The IPv4 addressing scheme is divided into two parts, 1001 the Area Locator (ALOC) address space which is globally unique and 1002 the Endpoint Locator (ELOC) address space which is only regionally 1003 unique. The ALOC and ELOC prefixes are added as a shim header 1004 between the IP header and transport protocol header, the shim header 1005 is identified with a new protocol number in the IP header. Instead 1006 of creating a tunneling (i.e. overlay) solution a new routing element 1007 is needed in the service provider's routing domain (called ALOC 1008 realm) - a Locator Swap Router. The current IPv4 forwarding plane 1009 remains intact and no new routing protocols, mapping systems or 1010 caching solutions are required. The control plane of the ALOC realm 1011 routers needs some modification in order for ICMP to be compatible 1012 with the hIPv4 framework. When an area (one or several ASes) of an 1013 ISP has transformed into an ALOC realm, only ALOC prefixes are 1014 exchanged with other ALOC realms. Directly attached ELOC prefixes 1015 are only inserted to the RIB of the local ALOC realm, ELOC prefixes 1016 are not distributed to the DFZ. Multihoming can be achieved in two 1017 ways, either the enterprise requests an ALOC prefix from the RIR 1018 (this is not recommended) or the enterprise receives the ALOC 1019 prefixes from their upstream ISPs. ELOC prefixes are PI addresses 1020 and remain intact when a upstream ISP is changed, only the ALOC 1021 prefix is replaced. When the RIB of the DFZ is compressed 1022 (containing only ALOC prefixes), ingress routers will no longer know 1023 the availability of the destination prefix, thus the endpoints must 1024 take more responsibility for their sessions. This can be achieved by 1025 using multipath enabled transport protocols, such as SCTP (RFC 4960) 1026 and Multipath TCP (MPTCP), at the endpoints. The multipath transport 1027 protocols also provide a session identifier, i.e. verification tag or 1028 token, thus the location and identifier split is carried out - site 1029 mobility, endpoint mobility, and mobile site mobility are achieved. 1030 DNS needs to be upgraded: in order to resolve the location of an 1031 endpoint, the endpoint must have one ELOC value (current A-record) 1032 and at least one ALOC value in DNS (in multihoming solutions there 1033 will be several ALOC values for an endpoint). 1035 5.1.2. Gains 1037 1. Improved routing scalability: Adding additional hierarchy to the 1038 address space enables more hierarchy in the routing architecture. 1039 Early adapters of an ALOC realm will no longer carry the current 1040 RIB of the DFZ - only ELOC prefixes of their directly attached 1041 networks and ALOC prefixes from other service provider that have 1042 migrated are installed in the ALOC realm's RIB. 1044 2. Scalable support for traffic engineering: Multipath enabled 1045 transport protocols are recommended to achieve dynamic load- 1046 balancing of a session. Support for Valiant Load-balancing 1047 [Valiant] schemes has been added to the framework; more research 1048 work is required around VLB switching. 1050 3. Scalable support for multihoming: Only attachment points of a 1051 multihomed site are advertised (using the ALOC prefix) in the 1052 DFZ. DNS will inform the requester on how many attachment points 1053 the destination endpoint has. It is the initiating endpoint's 1054 choice/responsibility to choose which attachment point is used 1055 for the session; endpoints using multipath enabled transport 1056 protocols can make use of several attachment points for a 1057 session. 1059 4. Simplified Renumbering: When changing provider, the local ELOC 1060 prefixes remains intact, only the ALOC prefix is changed at the 1061 endpoints. The ALOC prefix is not used for routing or forwarding 1062 decisions in the local network. 1064 5. Decoupling Location and Identifier: The verification tag (SCTP) 1065 and token (MPTCP) can be considered to have the characteristics 1066 of a session identifier and thus a session layer is created 1067 between the transport and application layer in the TCP/IP model. 1069 6. Routing quality: The hIPv4 framework introduces no tunneling or 1070 caching mechanisms, only a swap of the content in the IPv4 header 1071 and locator header at the destination ALOC realm is required, 1072 thus current routing and forwarding algorithms are preserved as 1073 such. Valiant Load-balancing might be used as a new forwarding 1074 mechanism. 1076 7. Routing Security: Similar as with today's DFZ, except that ELOC 1077 prefixes can not be hijacked (by injecting a longest match 1078 prefix) outside an ALOC realm. 1080 8. Deployability: The hIPv4 framework is an evolution of the current 1081 IPv4 framework and is backwards compatible with the current IPv4 1082 framework. Sessions in a local network and inside an ALOC realm 1083 might in the future still use the current IPv4 framework. 1085 5.1.3. Costs And Issues 1087 1. Upgrade of the stack at an endpoint that is establishing sessions 1088 outside the local ALOC realm. 1090 2. In a multihoming solution the border routers should be able to 1091 apply policy based routing upon the ALOC value in the locator 1092 header. 1094 3. New IP allocation policies must be set by the RIRs. 1096 4. Short timeframe before the expected depletion of the IPv4 address 1097 space occurs. 1099 5. Will enterprises give up their current globally unique IPv4 1100 address block allocation they have gained? 1102 6. Coordination with MPTCP is highly desirable. 1104 5.1.4. References 1106 [I-D.frejborg-hipv4] 1108 5.2. Critique 1110 hIPv4 is an innovative approach to expanding the IPv4 addressing 1111 system in order to resolve the scalable routing problem. This 1112 critique does not attempt a full assessment of hIPv4's architecture 1113 and mechanisms. The only question addressed here is whether hIPv4 1114 should be chosen for IETF development in preference to, or together 1115 with, the only two proposals which appear to be practical solutions 1116 for IPv4: Ivip and LISP. 1118 Ivip and LISP appear to have a major advantage over hIPv4 in terms of 1119 support for packets sent from non-upgraded hosts/networks. Ivip's 1120 DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel 1121 Routers) both accept packets sent by any non-upgraded host/network 1122 and tunnel them to the correct ETR - so providing full benefits of 1123 portability, multihoming and inbound TE for these packets as well as 1124 those sent by hosts in networks with ITRs. hIPv4 appears to have no 1125 such mechanism - so these benefits are only available for 1126 communications between two upgraded hosts in upgraded networks. 1128 This means that significant benefits for adopters - the ability to 1129 rely on the new system to provide the portability, multihoming and 1130 inbound TE benefits for all, or almost all, their communications - 1131 will only arise after all, or almost all networks upgrade their 1132 networks, hosts and addressing arrangements. hIPv4's relationship 1133 between adoption levels and benefits to any adopter therefore are far 1134 less favorable to widespread adoption than those of Core-Edge 1135 Separation (CES) architectures such as Ivip and LISP. 1137 This results in hIPv4 also being at a disadvantage regarding the 1138 achievement of significant routing scaling benefits - which likewise 1139 will only result once adoption is close to ubiquitous. Ivip and LISP 1140 can provide routing scaling benefits in direct proportion to their 1141 level of adoption, since all adopters gain full benefits for all 1142 their communications, in a highly scalable manner. 1144 hIPv4 requires stack upgrades, which are not required by any CES 1145 architecture. Furthermore, a large number of existing IPv4 1146 application protocols convey IP addresses between hosts in a manner 1147 which will not work with hIPv4: "There are several applications that 1148 are inserting IPv4 address information in the payload of a packet. 1149 Some applications use the IPv4 address information to create new 1150 sessions or for identification purposes. This section is trying to 1151 list the applications that need to be enhanced; however, this is by 1152 no means a comprehensive list." [I-D.frejborg-hipv4] 1154 If even a few widely used applications would need to be rewritten to 1155 operate successfully with hIPv4, then this would be such a 1156 disincentive to adoption to rule out hIPv4 ever being adopted widely 1157 enough to solve the routing scaling problem, especially since CES 1158 architectures fully support all existing protocols, without the need 1159 for altering host stacks. 1161 It appears that hIPv4 involves major practical difficulties which 1162 mean that in its current form it is not suitable for IETF 1163 development. 1165 5.3. Rebuttal 1167 No rebuttal was submitted for this proposal. 1169 5.4. Counterpoint 1171 No counterpoint was submitted for this proposal. 1173 6. Name overlay (NOL) service for scalable Internet routing 1175 6.1. Summary 1177 6.1.1. Key Idea 1179 The basic idea is to add a name overlay (NOL) onto the existing 1180 TCP/IP stack. 1182 Its functions include: 1184 1. Managing host name configuration, registration and 1185 authentication; 1187 2. Initiating and managing transport connection channels (i.e., 1188 TCP/IP connections) by name; 1190 3. Keeping application data transport continuity for mobility. 1192 At the edge network, we introduce a new type of gateway, a Name 1193 Transfer Relay (NTR), which blocks the PI addresses of edge networks 1194 into upstream transit networks. NTRs performs address and/or port 1195 translation between blocked PI addresses and globally routable 1196 addresses, which seem like today's widely used NAT/NAPT devices. 1197 Both legacy and NOL applications behind a NTR can access the outside 1198 as usual. To access the hosts behind a NTR from outside, we need to 1199 use NOL traverse the NTR by name and initiate connections to the 1200 hosts behind it. 1202 Different from proposed host-based ID/Locator split solutions, such 1203 as HIP, Shim6, and name-oriented stack, NOL doesn't need to change 1204 the existing TCP/IP stack, sockets and their packet formats. NOL can 1205 co-exist with the legacy infrastructure, and the core-edge separation 1206 solutions (e.g., APT, LISP, Six/one, Ivip, etc.) 1208 6.1.2. Gains 1209 1. Reduce routing table size: Prevent edge network PI address from 1210 leaking into transit network by deploying gateway NTRs. 1212 2. Traffic Engineering: For legacy and NOL application sessions, 1213 the incoming traffic can be directed to a specific NTR by DNS. 1214 In addition, for NOL applications, initial sessions can be 1215 redirected from one NTR to other appropriate NTRs. These 1216 mechanisms provide some support for traffic engineering. 1218 3. Multihoming: When a PI addressed network connects to the 1219 Internet by multihoming with several providers, it can deploy 1220 NTRs to block the PI addresses from leaking into provider 1221 networks. 1223 4. Transparency: NTRs can be allocated PA addresses from the 1224 upstream providers and store them in NTRs' address pool. By DNS 1225 query or NOL session, any session that want to access the hosts 1226 behind the NTR can be delegated to a specific PA address in the 1227 NTR address pool. 1229 5. Mobility: The NOL layer manages the traditional TCP/IP transport 1230 connections, and provides application data transport continuity 1231 by checkpointing the transport connection at sequence number 1232 boundaries. 1234 6. No need to change TCP/IP stack, sockets and DNS system. 1236 7. No need for extra mapping system. 1238 8. NTR can be deployed unilaterally, just like NATs 1240 9. NOL applications can communicate with legacy applications. 1242 10. NOL can be compatible with existing solutions, such as APT, 1243 LISP, Ivip, etc. 1245 11. End user controlled multipath indirect routing based on 1246 distributed NTRs. This will give benefits to the performance- 1247 aware applications, such as, MSN, Video streaming, etc. 1249 6.1.3. Costs 1251 1. Legacy applications have trouble with initiating access to the 1252 servers behind NTR. Such trouble can be resolved by deploying 1253 NOL proxy for legacy hosts, or delegating globally routable PA 1254 addresses in the NTR address pool for these servers, or deploying 1255 a proxy server outside the NTR. 1257 2. NOL may increase the number of entries in DNS, but it is not 1258 drastic, because it only increases the number of DNS records at 1259 domain granularity not the number of hosts. The name used in 1260 NOL, for example, is similar to an email address 1261 hostname@domain.net. The needed DNS entries and query is just 1262 for "domain.net", and the NTR knows the "hostnames". Not only 1263 will the number of DNS records be increased, but the dynamics of 1264 DNS might be agitated as well. However the scalability and 1265 performance of DNS is guaranteed by its naming hierarchy and 1266 caching mechanisms. 1268 3. Address translating/rewriting costs on NTRs. 1270 6.1.4. References 1272 No references were submitted. 1274 6.2. Critique 1276 1. Applications on hosts need to be rebuilt based on a name overlay 1277 library to be NOL-enabled. The legacy software that is not 1278 maintained will not be able to benefit from NOL in the core-edge 1279 elimination situation. In the core-edge separation scheme, a new 1280 gateway NTR is deployed to prevent edge specific PI prefixes from 1281 leaking into the transit core. NOL doesn't impede the legacy 1282 endpoints behind the NTR from accessing the outside Internet, but 1283 the legacy endpoints cannot or will have difficultly accessing 1284 the endpoints behind a NTR without the help of NOL. 1286 2. In the case of core-edge elimination, the end site will be 1287 assigned multiple PA address spaces, which leads to renumbering 1288 troubles when switching to other upstream providers. Upgrading 1289 endpoints to support NOL doesn't give any benefits to edge 1290 networks. Endpoints have little incentive to use NOL in a core- 1291 edge elimination scenario, and the same is true with other host- 1292 based ID/locator split proposals. Edge networks prefer PI 1293 address space to PA address space whether they are IPv4 or IPv6 1294 networks. 1296 3. In the core-edge separation scenario, the additional gateway NTR 1297 is to prevent the specific prefixes from the edge networks, just 1298 like a NAT or the ITR/ETR of LISP. A NTR gateway can be seen as 1299 an extension of NAT (Network Address Translation). Although NATs 1300 are deployed widely, upgrading them to support NOL extension or 1301 deploying additional new gateway NTRs at the edge networks are on 1302 a voluntary basis and have few economic incentives. 1304 4. The stateful or stateless translation for each packet traversing 1305 a NTR will require the cost of the CPU and memory of NTRs, and 1306 increase forwarding delay. Thus, it is not appropriate to deploy 1307 NTRs at the high-level transit networks where aggregated traffic 1308 may cause congestion at the NTRs. 1310 5. In the core-edge separation scenario, the requirement for 1311 multihoming and inter-domain traffic engineering will make end 1312 sites accessible via multiple different NTRs. For reliability, 1313 all of the associations between multiple NTRs and the end site 1314 name will be kept in DNS, which may increase the load of DNS. 1316 6. To support mobility, it is necessary for DNS to update the 1317 corresponding name-NTR mapping records when an end system moves 1318 from behind one NTR to another NTR. The NOL-enabled end relies 1319 on the NOL layer to preserve the continuity of the transport 1320 layer, since the underlying TCP/UDP transport session would be 1321 broken when the IP address changed. 1323 6.3. Rebuttal 1325 NOL resembles neither CEE nor CES as a solution. By supporting 1326 application level session through the name overlay layer, NOL can 1327 support some solutions in the CEE style. However, NOL is in general 1328 closer to CES solutions, i.e., preventing PI prefixes of edge 1329 networks from entering into the upstream transit networks. This is 1330 done by the NTR, like the ITR/ETRs in CES solutions, but NOL has no 1331 need to define the clear boundary between core and edge networks. 1332 NOL is designed to try to provide end users or networks a service 1333 that facilitates the adoption of multihoming, multipath routing and 1334 traffic engineering by the indirect routing through NTRs, and, in the 1335 mean time, doesn't accelerate, or decrease, the growth of global 1336 routing table size. 1338 Some problems are described in the NOL critique. In the original NOL 1339 proposal document, the DNS query for a host that is behind a NTR will 1340 induce the return of the actual IP addresses of the host and the 1341 address of the NTR. This arrangement might cause some difficulties 1342 for legacy applications due to the non-standard response from DNS. 1343 To resolve this problem, we instead have the NOL service use a new 1344 namespace, and have DNS not return NTR IP address for the legacy 1345 hosts. The names used for NOL are formatted like email addresses, 1346 such as "des@domain.net". The mapping between "domain.net" and IP 1347 address of corresponding NTR will be registered in DNS. The NOL 1348 layer will understand the meaning of the name "des@domain.net" , and 1349 it will send a query to DNS only for "domain.net". DNS will then 1350 return IP addresses of the corresponding NTRs. Legacy applications, 1351 will still use the traditional FQDN name and DNS will return the 1352 actual IP address of the host. However, if the host is behind a NTR, 1353 the legacy applications may be unable to access the host. 1355 The stateless address translation or stateful address and port 1356 translation may cause a scaling problem with the number of table 1357 entries NTR must maintain. And legacy applications can not initiate 1358 sessions with hosts inside the NOL-adopting End User Network (EUN). 1359 However, these problems may not be a big barrier for the deployment 1360 of NOL or other similar approaches. Many NAT-like boxes, proxy, and 1361 firewall devices are widely used at the Ingress/Egress points of 1362 Enterprise networks, campus networks or other stub EUNs. The hosts 1363 running as servers can be deployed outside NTRs or be assigned PA 1364 addresses in a NTR-adopting EUN. 1366 6.4. Counterpoint 1368 No counterpoint was submitted for this proposal. 1370 7. Compact routing in locator identifier mapping system (CRM) 1372 7.1. Summary 1374 7.1.1. Key Idea 1376 This proposal is to build a highly scalable locator identity mapping 1377 system using compact routing principles. This provides the means for 1378 dynamic topology adaption to facilitate efficient aggregation [CRM]. 1379 Map servers are assigned as cluster heads or landmarks based on their 1380 capability to aggregate EID announcements. 1382 7.1.2. Gains 1384 Minimizes the routing table sizes at the system level (i.e., map 1385 servers). Provides clear upper bounds for routing stretch that 1386 define the packet delivery delay of the map request/first packet. 1388 Organizes the mapping system based on the EID numbering space, 1389 minimizes the administrative overhead of managing the EID space. No 1390 need for administratively planned hierarchical address allocation as 1391 the system will find convergence into a set of EID allocations. 1393 Availability and robustness of the overall routing system (including 1394 xTRs and map servers) is improved because of the potential to use 1395 multiple map servers and direct routes without the involvement of map 1396 servers. 1398 7.1.3. Costs 1400 The scalability gains will materialize only in large deployments. If 1401 the stretch is bounded to those of compact routing (worst case 1402 stretch less or equal to 3, on average 1+epsilon) then xTRs need to 1403 have memory/cache for the mappings of its cluster. 1405 7.1.4. References 1407 [CRM] 1409 7.2. Critique 1411 The CRM proposal is not a complete proposal, and therefore cannot be 1412 considered for further development by the IETF as a scalable routing 1413 solution. 1415 While Compact Routing principles may be able to improve a mapping 1416 overlay structure such as LISP-ALT there are several objections to 1417 this approach. 1419 Firstly, a CRM-modified ALT structure would still be a global query 1420 server system. No matter how ALT's path lengths and delays are 1421 optimized, there is a problem with a querier - which could be 1422 anywhere in the world - relying on mapping information from one or 1423 ideally two or more authoritative query servers, which could also be 1424 anywhere in the world. The delays and risks of packet loss that are 1425 inherent in such a system constitute a fundamental problem. This is 1426 especially true when multiple, potentially long, traffic streams are 1427 received by ITRs and forwarded over the CRM networks for delivery to 1428 the destination network. ITRs must use the CRM infrastructure while 1429 they are awaiting a map reply. The traffic forwarded on the CRM 1430 infrastructure functions as map requests and can present a 1431 scalability and performance issue to the infrastructure. 1433 Secondly, the alterations contemplated in this proposal involve the 1434 roles of particular nodes in the network being dynamically assigned 1435 as part of its self-organizing nature. 1437 The discussion of Clustering in the middle of page 4 also indicates 1438 that particular nodes are responsible for registering EIDs from 1439 typically far-distant ETRs, all of which are handling closely related 1440 EIDs which this node can aggregate. Since MSes are apparently nodes 1441 within the compact routing system, and the process of an MS deciding 1442 whether to accept EID registrations is determined as part of the 1443 self-organizing properties of the system, there are concerns about 1444 how EID registration can be performed securely, when no particular 1445 physical node is responsible for it. 1447 Thirdly there are concerns about individually owned nodes performing 1448 work for other organizations. Such problems of trust and of 1449 responsibilities and costs being placed on those who do not directly 1450 benefit already exist in the interdomain routing system, and are a 1451 challenge for any scalable routing solution. 1453 There are simpler solutions to the mapping problem than having an 1454 elaborate network of routers. If a global-scale query system is 1455 still preferred, then it would be better to have ITRs use local MRs, 1456 each of which is dynamically configured to know the IP address of the 1457 million or so authoritative Map Server (MS) query servers - or two 1458 million or so assuming they exist in pairs for redundancy. 1460 It appears that the inherently greater delays and risks of packet 1461 loss of any global query server system make them unsuitable mapping 1462 solutions for Core-Edge Elimination or Core-Edge Separation 1463 architectures. The solution to these problems appears to involve a 1464 greater number of widely distributed authoritative query servers, one 1465 or more of which will therefore be close enough to each querier that 1466 delays and risk of packet loss are reduced to acceptable levels. 1467 Such a structure would be suitable for map requests, but perhaps not 1468 for handling traffic packets to be delivered to the destination 1469 networks. 1471 7.3. Rebuttal 1473 CRM is most easily understood as an alteration to the routing 1474 structure of the LISP-ALT mapping overlay system, by altering or 1475 adding to the network's BGP control plane. 1477 CRM's aims include the delivery of initial traffic packets to their 1478 destination networks where they also function as map requests. These 1479 packet streams may be long and numerous in the fractions of a second 1480 to perhaps several seconds that may elapse before the ITR receives 1481 the map reply. 1483 Compact Routing principles are used to optimize the path length taken 1484 by these query or traffic packets through a significantly modified 1485 version of the ALT (or similar) network while also generally reducing 1486 typical or maximum paths taken by the query packets. 1488 An overlay network is a diversion from the shortest path. However, 1489 CMR limits this diversion and provides an upper bound. Landmark 1490 routers/servers could deliver more than just the first traffic 1491 packet, subject to their CPU capabilities and their network 1492 connectivity bandwidths. 1494 The trust between the landmarks (mapping servers) can be built based 1495 on the current BGP relationships. Registration to the landmark nodes 1496 needs to be authenticated mutually between the MS and the system that 1497 is registering. This part is not documented in the proposal text. 1499 7.4. Counterpoint 1501 No counterpoint was submitted for this proposal. 1503 8. Layered mapping system (LMS) 1505 8.1. Summary 1507 8.1.1. Key Ideas 1509 The layered mapping system proposal builds a hierarchical mapping 1510 system to support scalability, analyzes the design constraints and 1511 presents an explicit system structure; designs a two-cache mechanism 1512 on ingress tunneling router (ITR) to gain low request delay and 1513 facilitates data validation. Tunneling and mapping are done at the 1514 core and no change is needed on edge networks. The mapping system is 1515 run by interest groups independent of any ISP, which conforms to 1516 economical model and can be voluntarily adopted by various networks. 1517 Mapping systems can also be constructed stepwise, especially in the 1518 IPv6 scenario. 1520 8.1.2. Gains 1522 1. Scalability 1524 1. Distributed storage of mapping data avoids central storage of 1525 massive amounts of data and restricts updates within local 1526 areas. 1528 2. The cache mechanism in an ITR reduces request loads on 1529 mapping system reasonably. 1531 2. Deployability 1533 1. No change on edge systems, only tunneling in core routers, 1534 and new devices in core networks. 1536 2. The mapping system can be constructed stepwise: a mapping 1537 node needn't be constructed if none of its responsible ELOCs 1538 is allocated. This makes sense especially for IPv6. 1540 3. Conforms to a viable economic model: the mapping system 1541 operators can profit from their services; core routers and 1542 edge networks are willing to join the circle either to avoid 1543 router upgrades or realize traffic engineering. Benefits 1544 from joining are independent of the scheme's implementation 1545 scale. 1547 3. Low request delay: The low number of layers in the mapping 1548 structure and the two-stage cache help achieve low request delay. 1550 4. Data consistency: The two-stage cache enables an ITR to update 1551 data in the map cache conveniently. 1553 5. Traffic engineering support: Edge networks inform the mapping 1554 system of their prioritized mappings with all upstream routers, 1555 thus giving the edge networks control over their ingress flows. 1557 8.1.3. Costs 1559 1. Deployment of LMS needs to be further discussed. 1561 2. The structure of mapping system needs to be refined according to 1562 practical circumstances. 1564 8.1.4. References 1566 [LMS Summary] [LMS] 1568 8.2. Critique 1570 LMS is a mapping mechanism based on core-edge separation. In fact, 1571 any proposal that needs a global mapping system with keys with 1572 similar properties to that of an "edge address" in a core-edge 1573 separation scenario can use such a mechanism. This means that those 1574 keys are globally unique (by authorization or just statistically), at 1575 the disposal of edge users, and may have several satisfied mappings 1576 (with possibly different weights). A proposal to address routing 1577 scalability that needs mapping but doesn't specify the mapping 1578 mechanism can use LMS to strengthen its infrastructure. 1580 The key idea of LMS is similar to that of LISP+ALT: that the mapping 1581 system should be hierarchically organized to gain scalability for 1582 storage and updates, and to achieve quick indexing for lookups. 1583 However, LMS advocates an ISP-independent mapping system and ETRs are 1584 not the authorities of mapping data. ETRs or edge-sites report their 1585 mapping data to related mapping servers. 1587 LMS assumes that mapping servers can be incrementally deployed in 1588 that a server may not be constructed if none of its administered edge 1589 addresses are allocated, and that mapping servers can charge for 1590 their services, which provides the economic incentive for their 1591 existence. How this brand-new system can be constructed is still not 1592 clear. Explicit layering is only an ideal state, and the proposal 1593 analyzes the layering limits and feasibility, rather than provide a 1594 practical way for deployment. 1596 The drawbacks of LMS's feasibility analysis also include that it 1) 1597 is based on current PC power and may not represent future 1598 circumstances (especially for IPv6), and 2) does not consider the 1599 variability of address utilization. Some IP address spaces may be 1600 effectively allocated and used while some may not, causing some 1601 mapping servers to be overloaded while others poorly utilized. More 1602 thoughts are needed as to the flexibility of the layer design. 1604 LMS doesn't fit well for mobility. It does not solve the problem 1605 when hosts move faster than the mapping updates and propagation 1606 between relative mapping servers. On the other hand, mobile hosts 1607 moving across ASes and changing their attachment points (core 1608 addresses) is less frequent than hosts moving within an AS. 1610 Separation needs two planes: core-edge separation, which is to gain 1611 routing table scalability and identity-location separation, which is 1612 to achieve mobility. GLI does a good clarification of this and in 1613 that case, LMS can be used to provide identity-to-core address 1614 mapping. Of course, other schemes may be competent and LMS can be 1615 incorporated with them if the scheme has global keys and needs to map 1616 them to other namespaces. 1618 8.3. Rebuttal 1620 No rebuttal was submitted for this proposal. 1622 8.4. Counterpoint 1624 No counterpoint was submitted for this proposal. 1626 9. 2-phased mapping 1628 9.1. Summary 1630 9.1.1. Considerations 1632 1. A mapping from prefixes to ETRs is an M:M mapping. Any change of 1633 a (prefix, ETR) pair should be updated in a timely manner which 1634 can be a heavy burden to any mapping system if the relation 1635 changes frequently. 1637 2. A prefix<->ETR mapping system cannot be deployed efficiently if 1638 it is overwhelmed by the worldwide dynamics. Therefore the 1639 mapping itself is not scalable with this direct mapping scheme. 1641 9.1.2. Basics of a 2-phased mapping 1643 1. Introduce an AS number in the middle of the mapping, the phase I 1644 mapping is prefix<->AS#, phase II mapping is AS#<->ETRs. This 1645 creates a M:1:M mapping model. 1647 2. It is fair to assume that all ASes know their local prefixes (in 1648 the IGP) better than others and that it is most likely that local 1649 prefixes can be aggregated when they can be mapped to the AS 1650 number, which will reduce the number of mapping entries. ASes 1651 also know clearly their ETRs on the border between core and edge. 1652 So all mapping information can be collected locally. 1654 3. A registry system will take care of the phase I mapping 1655 information. Each AS should have a registration agent to notify 1656 the registry of the local range of IP address space. This system 1657 can be organized as a hierarchical infrastructure like DNS, or 1658 alternatively as a centralized registry like "whois" in each RIR. 1659 Phase II mapping information can be distributed between xTRs as a 1660 BGP extension. 1662 4. The basic forwarding procedure is that the ITR first gets the 1663 destination AS number from the phase I mapper (or from cache) 1664 when the packet is entering the "core". Then it will extract the 1665 closest ETR for the destination AS number. This is local, since 1666 phase II mapping information has been "pushed" to it through BGP 1667 updates. Finally, the ITR tunnels the packet to the 1668 corresponding ETR. 1670 9.1.3. Gains 1672 1. Any prefix reconfiguration (aggregation/deaggregation) within an 1673 AS will not be reflected in the mapping system. 1675 2. Local prefixes can be aggregated with a high degree of 1676 efficiency. 1678 3. Both phase I and phase II mappings can be stable. 1680 4. A stable mapping system will reduce the update overhead 1681 introduced by topology changes and/or routing policy dynamics. 1683 9.1.4. Summary 1685 1. The 2-phased mapping scheme introduces an AS number between the 1686 mapping prefixes and ETRs. 1688 2. The decoupling of direct mapping makes highly dynamic updates 1689 stable, therefore it can be more scalable than any direct mapping 1690 designs. 1692 3. The 2-phased mapping scheme is adaptable to any core/edge split 1693 based proposals. 1695 9.1.5. References 1697 No references were submitted. 1699 9.2. Critique 1701 This is a simple idea on how to scale mapping. However, this design 1702 is too incomplete to be considered a serious input to RRG. Take the 1703 following 2 issues as example: 1705 First, in this 2-phase scheme, an AS is essentially the unit of 1706 destinations (i.e. sending ITRs find out destination AS D, then send 1707 data to one of of D's ETR). This does not offer much choice for 1708 traffic engineering. 1710 Second, there is no consideration whatsoever on failure detection and 1711 handling. 1713 9.3. Rebuttal 1715 No rebuttal was submitted for this proposal. 1717 9.4. Counterpoint 1719 No counterpoint was submitted for this proposal. 1721 10. Global Locator, Local Locator, and Identifier Split (GLI-Split) 1723 10.1. Summary 1725 10.1.1. Key Idea 1727 GLI-Split implements a separation between global routing (in the 1728 global Internet outside edge networks) and local routing (inside edge 1729 networks) using global and local locators (GLs, LLs). In addition, a 1730 separate static identifier (ID) is used to identify communication 1731 endpoints (e.g. nodes or services) independently of any routing 1732 information. Locators and IDs are encoded in IPv6 addresses to 1733 enable backwards-compatibility with the IPv6 Internet. The higher 1734 order bits store either a GL or a LL while the lower order bits 1735 contain the ID. A local mapping system maps IDs to LLs and a global 1736 mapping system maps IDs to GLs. The full GLI-mode requires nodes 1737 with upgraded networking stacks and special GLI-gateways. The GLI- 1738 gateways perform stateless locator rewriting in IPv6 addresses with 1739 the help of the local and global mapping system. Non-upgraded IPv6 1740 nodes can also be accommodated in GLI-domains since an enhanced DHCP 1741 service and GLI-gateways compensate their missing GLI-functionality. 1742 This is an important feature for incremental deployability. 1744 10.1.2. Gains 1746 The benefits of GLI-Split are 1748 o Hierarchical aggregation of routing information in the global 1749 Internet through separation of edge and core routing 1751 o Provider changes not visible to nodes inside GLI-domains 1752 (renumbering not needed) 1754 o Rearrangement of subnetworks within edge networks not visible to 1755 the outside world (better support of large edge networks) 1757 o Transport connections survive both types of changes 1759 o Multihoming 1761 o Improved traffic engineering for incoming and outgoing traffic 1763 o Multipath routing and load balancing for hosts 1765 o Improved resilience 1767 o Improved mobility support without home agents and triangle routing 1769 o Interworking with the classic Internet 1771 * without triangle routing over proxy routers 1773 * without stateful NAT 1775 These benefits are available for upgraded GLI-nodes, but non-upgraded 1776 nodes in GLI-domains partially benefit from these advanced features, 1777 too. This offers multiple incentives for early adopters and they 1778 have the option to migrate their nodes gradually from non-GLI stacks 1779 to GLI-stacks. 1781 10.1.3. Costs 1783 o Local and global mapping system 1785 o Modified DHCP or similar mechanism 1787 o GLI-gateways with stateless locator rewriting in IPv6 addresses 1789 o Upgraded stacks (only for full GLI-mode) 1791 10.1.4. References 1793 [GLI] [Valiant] 1795 10.2. Critique 1797 GLI-Split makes a clear distinction between two separation planes: 1798 the separation between identifier and locator, which is to meet end- 1799 users needs including mobility; and the separation between local and 1800 global locator, to make the global routing table scalable. The 1801 distinction is needed since ISPs and hosts have different 1802 requirements, also make the changes inside and outside GLI-domains 1803 invisible to their opposites. 1805 A main drawback of GLI-Split is that it puts a burden on hosts. 1806 Before routing a packet received from upper layers, network stacks in 1807 hosts first need to resolve the DNS name to an IP address; if the IP 1808 address is GLI-formed, it may look up the map from the identifier 1809 extracted from the IP address to the local locator. If the 1810 communication is between different GLI-domains, hosts may further 1811 look up the mapping from the identifier to the global locator. 1812 Having the local mapping system forward requests to the global 1813 mapping system for hosts is just an option. Though host lookup may 1814 ease the burden of intermediate nodes which would otherwise to 1815 perform the mapping lookup, the three lookups by hosts in the worst 1816 case may lead to large delays unless a very efficient mapping 1817 mechanism is devised. The work may also become impractical for low- 1818 powered hosts. On one hand, GLI-split can provide backward 1819 compatibility where classic and upgraded IPv6 hosts can communicate, 1820 which is its big virtue; while the upgrades may work against hosts' 1821 enthusiasm to change, compared to the benefits they would gain. 1823 GLI-split provides additional features to improve TE and to improve 1824 resilience, e.g., exerting multipath routing. However the cost is 1825 that more burdens are placed on hosts, e.g. they may need more lookup 1826 actions and route selections. However, these kinds of tradeoffs 1827 between costs and gains exists in most proposals. 1829 One improvement of GLI-Split is its support for mobility by updating 1830 DNS data as GLI-hosts move across GLI-domains. Through this the GLI- 1831 corresponding-node can query DNS to get a valid global locator of the 1832 GLI-mobile-node and need not query the global mapping system (unless 1833 it wants to do multipath routing), giving more incentives for nodes 1834 to become GLI-enabled. The merits of GLI-Split, simplified-mobility- 1835 handover provision, compensates for the costs of this improvement. 1837 GLI-Split claims to use rewriting instead of tunneling for 1838 conversions between local and global locators when packets span GLI- 1839 domains. The major advantage is that this kind of rewriting needs no 1840 extra state, since local and global locators need not map to each 1841 other. Many other rewriting mechanisms instead need to maintain 1842 extra state. It also avoids the MTU problem faced by the tunneling 1843 methods. However, GLI-Split achieves this only by compressing the 1844 namespace size of each attribute (identifier, local and global 1845 locator). GLI-Split encodes two namespaces (identifier and local/ 1846 global locator) into an IPv6 address, each has a size of 2^64 or 1847 less, while map-and-encap proposals assume that identifier and 1848 locator each occupy a 128 bit space. 1850 10.3. Rebuttal 1852 The arguments in the GLI-Split critique are correct. There are only 1853 two points that should be clarified here. (1) First, it is not a 1854 drawback that hosts perform the mapping lookups. (2) Second, the 1855 critique proposed an improvement to the mobility mechanism, which is 1856 of general nature and not specific to GLI-Split. 1858 1. The additional burden on the hosts is actually a benefit, 1859 compared to having the same burden on the gateways. If the 1860 gateway would perform the lookups and packets addressed to 1861 uncached EIDs arrive, a lookup in the mapping system must be 1862 initiated. Until the mapping reply returns, packets must be 1863 either dropped, cached, or the packets must be sent over the 1864 mapping system to the destination. All these options are not 1865 optimal and have their drawbacks. To avoid these problems in 1866 GLI-Split, the hosts perform the lookup. The short additional 1867 delay is not a big issue in the hosts because it happens before 1868 the first packets are sent. So no packets are lost or have to be 1869 cached. GLI-Split could also easily be adapted to special GLI- 1870 hosts (e.g., low power sensor nodes) that do not have to do any 1871 lookup and simply let the gateway do all the work. This 1872 functionality is included anyway for backward compatibility with 1873 regular IPv6-hosts inside the GLI-domain. 1875 2. The critique proposes a DNS-based mobility mechanism as an 1876 improvement to GLI-Split. However, this improvement is an 1877 alternative mobility approach which can be applied to any routing 1878 architecture including GLI-Split and raises also some concerns, 1879 e.g., the update speed of DNS. Therefore, we prefer to keep this 1880 issue out of the discussion. 1882 10.4. Counterpoint 1884 No counterpoint was submitted for this proposal. 1886 11. Tunneled Inter-domain Routing (TIDR) 1888 11.1. Summary 1890 11.1.1. Key Idea 1892 Provides a method for locator-identifier separation using tunnels 1893 between routers on the edge of the Internet transit infrastructure. 1894 It enriches the BGP protocol for distributing the identifier-to- 1895 locator mapping. Using new BGP attributes, "identifier prefixes" are 1896 assigned inter-domain routing locators so that they will not be 1897 installed in the RIB and will be moved to a new table called Tunnel 1898 Information Base (TIB). Afterwards, when routing a packet to an 1899 "identifier prefix", the TIB will be searched first to perform 1900 tunneling, and secondly the RIB for actual routing. After the edge 1901 router performs tunneling, all routers in the middle will route this 1902 packet until the router at the tail-end of the tunnel. 1904 11.1.2. Gains 1906 o Smooth deployment 1908 o Size reduction of the global RIB 1910 o Deterministic customer traffic engineering for incoming traffic 1912 o Numerous forwarding decisions for a particular address prefix 1914 o Stops AS number space depletion 1916 o Improved BGP convergence 1918 o Protection of the inter-domain routing infrastructure 1920 o Easy separation of control traffic and transit traffic 1921 o Different layer-2 protocol-IDs for transit and non-transit traffic 1923 o Multihoming resilience 1925 o New address families and tunneling techniques 1927 o Support for IPv4 or IPv6, and migration to IPv6 1929 o Scalability, stability and reliability 1931 o Faster inter-domain routing 1933 11.1.3. Costs 1935 o Routers on the edge of the inter-domain infrastructure will need 1936 to be upgraded to hold the mapping database (i.e. the TIB) 1938 o "Mapping updates" will need to be treated differently from usual 1939 BGP "routing updates" 1941 11.1.4. References 1943 [I-D.adan-idr-tidr] [TIDR identifiers] [TIDR and LISP] [TIDR AS 1944 forwarding] 1946 11.2. Critique 1948 TIDR is a Core-Edge Separation architecture from late 2006 which 1949 distributes its mapping information via BGP messages which are passed 1950 between DFZ routers. 1952 This means that TIDR cannot solve the most important goal of scalable 1953 routing - to accommodate much larger numbers of end-user network 1954 prefixes (millions or billions) without each such prefix directly 1955 burdening every DFZ router. Messages advertising routes for TIDR- 1956 managed prefixes may be handled with lower priority, but this would 1957 only marginally reduce the workload for each DFZ router compared to 1958 handling an advertisement of a conventional PI prefix. 1960 Therefore, TIDR cannot be considered for RRG recommendation as a 1961 solution to the routing scaling problem. 1963 For a TIDR-using network to receive packets sent from any host, every 1964 BR of all ISPs must be upgraded to have the new ITR-like 1965 functionality. Furthermore, all DFZ routers would need to be altered 1966 so they accepted and correctly propagated the routes for end-user 1967 network address space, with the new LOCATOR attribute which contains 1968 the ETR address and a REMOTE-PREFERENCE value. Firstly, if they 1969 received two such advertisements with different LOCATORs, they would 1970 advertise a single route to this prefix containing both. Secondly, 1971 for end-user address space (for IPv4) to be more finely divided, the 1972 DFZ routers must propagate LOCATOR-containing advertisements for 1973 prefixes longer than /24. 1975 TIDR's ITR-like routers store the full mapping database - so there 1976 would be no delay in obtaining mapping, and therefore no significant 1977 delay in tunneling traffic packets. 1979 The TIDR ID is written as if traffic packets are classified by 1980 reference to the RIB - but routers use the FIB for this purpose, and 1981 "FIB" does not appear in the ID. 1983 TIDR does not specify a tunneling technique, leaving this to be 1984 chosen by the ETR-like function of BRs and specified as part of a 1985 second-kind of new BGP route advertised by that ETR-like BR. There 1986 is no provision for solving the PMTUD problems inherent in 1987 encapsulation-based tunneling. 1989 ITR functions must be performed by already busy routers of ISPs, 1990 rather than being distributed to other routers or to sending hosts. 1991 There is no practical support for mobility. The mapping in each end- 1992 user route advertisement includes a REMOTE-PREFERENCE for each ETR- 1993 like BR, but this is used by the ITR-like functions of BRs to always 1994 select the LOCATOR with the highest value. As currently described, 1995 TIDR does not provide inbound load splitting TE. 1997 Multihoming service restoration is achieved initially by the ETR-like 1998 function of BR at the ISP whose link to the end-user network has just 1999 failed, looking up the mapping to find the next preferred ETR-like 2000 BR's address. The first ETR-like router tunnels the packets to the 2001 second ETR-like router in the other ISP. However, if the failure was 2002 caused by the first ISP itself being unreachable, then connectivity 2003 would not be restored until a revised mapping (with higher REMOTE- 2004 PREFERENCE) from the reachable ETR-like BR of the second ISP 2005 propagated across the DFZ to all ITR-like routers, or the withdrawn 2006 advertisement for the first one reaches the ITR-like router. 2008 11.3. Rebuttal 2010 No rebuttal was submitted for this proposal. 2012 11.4. Counterpoint 2014 No counterpoint was submitted for this proposal. 2016 12. Identifier-Locator Network Protocol (ILNP) 2018 12.1. Summary 2020 12.1.1. Key Ideas 2022 o Provides crisp separation of Identifiers from Locators. 2024 o Identifiers name nodes, not interfaces. 2026 o Locators name subnetworks, rather than interfaces, so they are 2027 equivalent to an IP routing prefix. 2029 o Identifiers are never used for network-layer routing, whilst 2030 Locators are never used for Node Identity. 2032 o Transport-layer sessions (e.g. TCP session state) use only 2033 Identifiers, never Locators, meaning that changes in location have 2034 no adverse impact on an IP session. 2036 12.1.2. Benefits 2038 o The underlying protocol mechanisms support fully scalable site 2039 multihoming, node multihoming, site mobility, and node mobility. 2041 o ILNP enables topological aggregation of location information while 2042 providing stable and topology-independent identities for nodes. 2044 o In turn, this topological aggregation reduces both the routing 2045 prefix "churn" rate and the overall size of the Internet's global 2046 routing table, by eliminating the value and need for more-specific 2047 routing state currently carried throughout the global (default- 2048 free) zone of the routing system. 2050 o ILNP enables improved Traffic Engineering capabilities without 2051 adding any state to the global routing system. TE capabilities 2052 include both provider-driven TE and also end-site-controlled TE. 2054 o ILNP's mobility approach: 2056 * eliminates the need for special-purpose routers (e.g. Home 2057 Agent and/or Foreign Agent now required by Mobile IP & NEMO). 2059 * eliminates "triangle routing" in all cases. 2061 * supports both "make before break" and "break before make" 2062 layer-3 handoffs. 2064 o ILNP improves resilience and network availability while reducing 2065 the global routing state (as compared with the currently deployed 2066 Internet). 2068 o ILNP is Incrementally Deployable: 2070 * No changes are required to existing IPv6 (or IPv4) routers. 2072 * Upgraded nodes gain benefits immediately ("day one"); those 2073 benefits gain in value as more nodes are upgraded (this follows 2074 Metcalfe's Law). 2076 * Incremental Deployment approach is documented. 2078 o ILNP is Backwards Compatible: 2080 * ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully 2081 backwards compatible with IPv4). 2083 * Reuses existing known-to-scale DNS mechanisms to provide 2084 identifier/locator mapping. 2086 * Existing DNS Security mechanisms are reused without change. 2088 * Existing IP Security mechanisms are reused with one minor 2089 change (IPsec Security Associations replace the current use of 2090 IP Addresses with the use of Identifier values). NB: IPsec is 2091 also backwards compatible. 2093 * Backwards Compatibility approach is documented. 2095 o No new or additional overhead is required to determine or to 2096 maintain locator/path liveness. 2098 o ILNP does not require locator rewriting (NAT); ILNP permits and 2099 tolerates NAT should that be desirable in some deployment(s). 2101 o Changes to upstream network providers do not require node or 2102 subnetwork renumbering within end-sites. 2104 o Compatible with and can facilitate the transition from current 2105 single-path TCP to multipath TCP. 2107 o ILNP can be implemented such that existing applications (e.g. 2108 applications using the BSD Sockets API) do NOT need any changes or 2109 modifications to use ILNP. 2111 12.1.3. Costs 2113 o End systems need to be enhanced incrementally to support ILNP in 2114 addition to IPv6 (or IPv4 or both). 2116 o DNS servers supporting upgraded end systems also should be 2117 upgraded to support new DNS resource records for ILNP. (DNS 2118 protocol & DNS security do not need any changes.) 2120 12.1.4. References 2122 [ILNP Site] [MobiArch1] [MobiArch2] [MILCOM1] [MILCOM2] [DNSnBIND] 2123 [I-D.carpenter-behave-referral-object] [I-D.rja-ilnp-nonce] [RFC4033] 2124 [RFC4034] [RFC4035] [RFC5534] [RFC5902] 2126 12.2. Critique 2128 The primary issue for ILNP is how the deployment incentives and 2129 benefits line up with the RRG goal of reducing the rate of growth of 2130 entries and churn in the core routing table. If a site is currently 2131 using PI space, it can only stop advertising that space when the 2132 entire site is ILNP capable. This needs at least clear elucidation 2133 of the incentives for ILNP which are not related to routing scaling, 2134 in order for there to be a path for this to address the RRG needs. 2135 Similarly, the incentives for upgrading hosts need to align with the 2136 value for those hosts. 2138 A closely related question is whether this mechanism actually 2139 addresses the sites need for PI addresses. Assuming ILNP is 2140 deployed, the site does achieve flexible, resilient, communication 2141 using all of its Internet connections. While the proposal addresses 2142 the host updates when the host learns of provider changes, there are 2143 other aspects of provider change that are not addressed. This 2144 includes renumbering router, subnets, and certain servers. (It is 2145 presumed that most servers, once the entire site has moved to ILNP, 2146 will not be concerned if their locator changes. However, some 2147 servers must have known locators, such as the DNS server.) The 2148 issues described in [RFC5887] will be ameliorated, but not resolved. 2149 To be able to adopt this proposal, and have sites use it, we need to 2150 address these issues. When a site changes points of attachment only 2151 a small amount of DNS provisioning should be required. The LP record 2152 is apparently intended to help with this. It is also likely that the 2153 use of dynamic DNS will help this. 2155 The ILNP mechanism is described as being suitable for use in 2156 conjunction with mobility. This raises the question of race 2157 conditions. To the degree that mobility concerns are valid at this 2158 time, it is worth asking how communication can be established if a 2159 node is sufficiently mobile that it is moving faster than the DNS 2160 update and DNS fetch cycle can effectively propagate changes. 2162 This proposal does presume that all communication using this 2163 mechanism is tied to DNS names. While it is true that most 2164 communication does start from a DNS name, it is not the case that all 2165 exchanges have this property. Some communication initiation and 2166 referral can be done with an explicit I/L pair. This does appear to 2167 require some extensions to the existing mechanism (for both sides to 2168 add locators). In general, some additional clarity on the 2169 assumptions regarding DNS, particularly for low end devices, would 2170 seem appropriate. 2172 One issue that this proposal shares with many others is the question 2173 of how to determine which locator pairs (local and remote) are 2174 actually functional. This is an issue both for initial 2175 communications establishment, and for robustly maintaining 2176 communication. While it is likely that a combination of monitoring 2177 of traffic (in the host, where this is tractable), coupled with other 2178 active measures, can address this. ICMP is clearly insufficient. 2180 12.3. Rebuttal 2182 ILNP eliminates the perceived need for PI addressing, and encourages 2183 increased DFZ aggregation. Many enterprise users view DFZ scaling 2184 issues as too abstruse. So ILNP creates more user-visible incentives 2185 to upgrade deployed systems. 2187 ILNP mobility eliminates Duplicate Address Detection (DAD), reducing 2188 the layer-3 handoff time significantly, compared to IETF standard 2189 Mobile IP. [MobiArch1] [MobiArch2] ICMP Location updates separately 2190 reduce the layer-3 handoff latency. 2192 Also, ILNP enables both host multihoming and site multihoming. 2193 Current BGP approaches cannot support host multihoming. Host 2194 multihoming is valuable in reducing the site's set of externally 2195 visible nodes. 2197 Improved mobility support is very important. This is shown by the 2198 research literature and also appears in discussions with vendors of 2199 mobile devices (smartphones, MP3-players). Several operating system 2200 vendors push "updates" with major networking software changes in 2201 maintenance releases today. Security concerns mean most hosts 2202 receive vendor updates more quickly these days. 2204 ILNP enables a site to hide exterior connectivity changes from 2205 interior nodes, using various approaches. One approach deploys 2206 unique local address (ULA) prefixes within the site and has the site 2207 border router(s) rewrite the Locator values. The usual NAT issues 2208 don't arise because the Locator value is not used above the network- 2209 layer. [MILCOM1] [MILCOM2] 2211 [RFC5902] makes clear that many users desire IPv6 NAT, with site 2212 interior obfuscation as a major driver. This makes global-scope PI 2213 addressing much less desirable for end sites than formerly. 2215 ILNP-capable nodes can talk existing IP with legacy IP-only nodes, 2216 with no loss of current IP capability. So ILNP-capable nodes will 2217 never be worse off. 2219 Secure Dynamic DNS Update is standard, and widely supported in 2220 deployed hosts and DNS servers. [DNSnBIND] says many sites have 2221 deployed this technology without realizing it (e.g. by enabling both 2222 the DHCP server and Active Directory of MS-Windows Server). 2224 If a node is as mobile as the critique says, then existing IETF 2225 Mobile IP standards also will fail. They also use location updates 2226 (e.g. MN->HA, MN->FA). 2228 ILNP also enables new approaches to security that eliminate 2229 dependence upon location-dependent ACLs without packet 2230 authentication. Instead, security appliances track flows using 2231 Identifier values, and validate the I/L relationship 2232 cryptographically [RFC4033] [RFC4034] [RFC4035] or non- 2233 cryptographically by reading the [I-D.rja-ilnp-nonce]. 2235 The DNS LP record has a more detailed explanation now. LP records 2236 enable a site to change its upstream connectivity by changing the L 2237 records of a single FQDN covering the whole site, providing 2238 scalability. 2240 DNS-based server load balancing works well with ILNP by using DNS SRV 2241 records. DNS SRV records are not new, are widely available in DNS 2242 clients & servers, and are widely used today in the IPv4 Internet for 2243 Server Load Balancing. 2245 Recent ILNP I-Ds discuss referrals in more detail. A node with a 2246 binary-referral can find the FQDN using DNS PTR records, which can be 2247 authenticated [RFC4033] [RFC4034] [RFC4035]. Approaches such as 2248 [I-D.carpenter-behave-referral-object] improve user experience and 2249 user capability, so are likely to self-deploy. 2251 Selection from multiple Locators is identical to an IPv4 system 2252 selecting from multiple A records for its correspondent. Deployed IP 2253 nodes can track reachability via existing host mechanisms, or by 2254 using the SHIM6 method. [RFC5534] 2256 12.4. Counterpoint 2258 No counterpoint was submitted for this proposal. 2260 13. Enhanced Efficiency of Mapping Distribution Protocols in Map-and- 2261 Encap Schemes (EEMDP) 2263 13.1. Summary 2265 13.1.1. Introduction 2267 We present some architectural principles pertaining to the mapping 2268 distribution protocols, especially applicable to map-and-encap (e.g., 2269 LISP) type of protocols. These principles enhance the efficiency of 2270 the map-and-encap protocols in terms of (1) better utilization of 2271 resources (e.g., processing and memory) at Ingress Tunnel Routers 2272 (ITRs) and mapping servers, and consequently, (2) reduction of 2273 response time (e.g., first packet delay). We consider how Egress 2274 Tunnel Routers (ETRs) can perform aggregation of end-point ID (EID) 2275 address space belonging to their downstream delivery networks, in 2276 spite of migration/re-homing of some subprefixes to other ETRs. This 2277 aggregation may be useful for reducing the processing load and memory 2278 consumption associated with map messages, especially at some 2279 resource-constrained ITRs and subsystems of the mapping distribution 2280 system. We also consider another architectural concept where the 2281 ETRs are organized in a hierarchical manner for the potential benefit 2282 of aggregation of their EID address spaces. The two key 2283 architectural ideas are discussed in some more detail below. A more 2284 complete description can be found in [EEMDP Considerations] and 2285 [EEMDP Presentation]. 2287 It will be helpful to refer to Figures 1, 2, and 3 in the document 2288 noted above for some of the discussions that follow here below. 2290 13.1.2. Management of Mapping Distribution of Subprefixes Spread Across 2291 Multiple ETRs 2293 To assist in this discussion, we start with the high level 2294 architecture of a map-and-encap approach (it would be helpful to see 2295 Fig. 1 in the document mentioned above). In this architecture we 2296 have the usual ITRs, ETRs, delivery networks, etc. In addition, we 2297 have the ID-Locator Mapping (ILM) servers which are repositories for 2298 complete mapping information, while the ILM-Regional (ILM-R) servers 2299 can contain partial and/or regionally relevant mapping information. 2301 While a large endpoint address space contained in a prefix may be 2302 mostly associated with the delivery networks served by one ETR, some 2303 fragments (subprefixes) of that address space may be located 2304 elsewhere at other ETRs. Let a/20 denote a prefix that is 2305 conceptually viewed as composed of 16 subnets of /24 size that are 2306 denoted as a1/24, a2/24, ..., a16/24. For example, a/20 is mostly at 2307 ETR1, while only two of its subprefixes a8/24 and a15/24 are 2308 elsewhere at ETR3 and ETR2, respectively (see Fig. 2 in the 2309 document). From the point of view of efficiency of the mapping 2310 distribution protocol, it may be beneficial for ETR1 to announce a 2311 map for the entire space a/20 (rather than fragment it into a 2312 multitude of more-specific prefixes), and provide the necessary 2313 exceptions in the map information. Thus the map message could be in 2314 the form of Map:(a/20, ETR1; Exceptions: a8/24, a15/24). In 2315 addition, ETR2 and ETR3 announce the maps for a15/24 and a8/24, 2316 respectively, and so the ILMs know where the exception EID addresses 2317 are located. Now consider a host associated with ITR1 initiating a 2318 packet destined for an address a7(1), which is in a7/24 that is not 2319 in the exception portion of a/20. Now a question arises as to which 2320 of the following approaches would be the best choice: 2322 1. ILM-R provides the complete mapping information for a/20 to ITR1 2323 including all maps for relevant exception subprefixes. 2325 2. ILM-R provides only the directly relevant map to ITR1 which in 2326 this case is (a/20, ETR1). 2328 In the first approach, the advantage is that ITR1 would have the 2329 complete mapping for a/20 (including exception subnets), and it would 2330 not have to generate queries for subsequent first packets that are 2331 destined to any address in a/20, including a8/24 and a15/24. 2332 However, the disadvantage is that if there is a significant number of 2333 exception subprefixes, then the very first packet destined for a/20 2334 will experience a long delay, and also the processors at ITR1 and 2335 ILM-R can experience overload. In addition, the memory usage at ITR1 2336 can be very inefficient as well. The advantage of the second 2337 approach above is that the ILM-R does not overload resources at ITR1 2338 both in terms of processing and memory usage but it needs an enhanced 2339 map response in of the form Map:(a/20, ETR1, MS=1), where MS (more 2340 specific) indicator is set to 1 to indicate to ITR1 that not all 2341 subnets in a/20 map to ETR1. The key idea is that aggregation is 2342 beneficial and subnet exceptions must be handled with additional 2343 messages or indicators in the maps. 2345 13.1.3. Management of Mapping Distribution for Scenarios with Hierarchy 2346 of ETRs and Multihoming 2348 Now we highlight another architectural concept related to mapping 2349 management (please refer to Fig. 3 in the document). Here we 2350 consider the possibility that ETRs may be organized in a hierarchical 2351 manner. For instance ETR7 is higher in hierarchy relative to ETR1, 2352 ETR2, and ETR3, and like-wise ETR8 is higher relative to ETR4, ETR5, 2353 and ETR6. For instance, ETRs 1 through 3 can relegate the locator 2354 role to ETR7 for their EID address space. In essence, they can allow 2355 ETR7 to act as the locator for the delivery networks in their 2356 purview. ETR7 keeps a local mapping table for mapping the 2357 appropriate EID address space to specific ETRs that are 2358 hierarchically associated with it in the level below. In this 2359 situation, ETR7 can perform EID address space aggregation across ETRs 2360 1 through 3 and can also include its own immediate EID address space 2361 for the purpose of that aggregation. The many details related to 2362 this approach and special circumstances involving multihoming of 2363 subnets are discussed in detail in the detailed document noted 2364 earlier. The hierarchical organization of ETRs and delivery networks 2365 should help in the future growth and scalability of ETRs and mapping 2366 distribution networks. This is essentially recursive map-and-encap, 2367 and some of the mapping distribution and management functionality 2368 will remain local to topologically neighboring delivery networks 2369 which are hierarchically underneath ETRs. 2371 13.1.4. References 2373 [EEMDP Considerations] [EEMDP Presentation] [FIBAggregatability] 2375 13.2. Critique 2377 This scheme [EEMDP Considerations] represents one approach to mapping 2378 overhead reduction, and it is a general idea that is applicable to 2379 any proposal that includes prefix or EID aggregation. A somewhat 2380 similar idea is also used in Level-3 aggregation in the FIB 2381 aggregation proposal. [FIBAggregatability] There can be cases where 2382 deaggregation of EID prefixes occur in such a way that bulk of an EID 2383 prefix P would be attached to one locator (say, ETR1) while a few 2384 subprefixes under P would be attached to other locators elsewhere 2385 (say, ETR2, ETR3, etc.). Ideally such cases should not happen, 2386 however in reality it can happen as RIR's address allocations are 2387 imperfect. In addition, as new IP address allocations become harder 2388 to get, an IPv4 prefix owner might split previously unused 2389 subprefixes of that prefix and allocate them to remote sites (homed 2390 to other ETRs). Assuming these situations could arise in practice, 2391 the nature of the solution would be that the response from the 2392 mapping server for the coarser site would include information about 2393 the more specifics. The solution as presented seems correct. 2395 The proposal mentions that in Approach 1, the ID-Locator Mapping 2396 (ILM) system provides the complete mapping information for an 2397 aggregate EID prefix to a querying ITR including all the maps for the 2398 relevant exception subprefixes. The sheer number of such more- 2399 specifics can be worrisome, for example, in LISP. What if a 2400 company's mobile-node EIDs came out of their corporate EID-prefix? 2401 Approach 2 is far better but still there may be too many entries for 2402 a regional ILM to store. In Approach 2, the ILM communicates that 2403 there are more specifics but does not communicate their mask-length. 2404 A suggested improvement would be that rather than saying that there 2405 are more specifics, indicate what their mask-lengths are. There can 2406 be multiple mask lengths. This number should be pretty small for For 2407 IPv4 but can be large for IPv6. 2409 Later in the proposal, a different problem is addressed involving a 2410 hierarchy of ETRs and how aggregation of EID prefixes from lower 2411 level ETRs can be performed at a higher level ETR. The various 2412 scenarios here are well illustrated and described. This seems like a 2413 good idea, and a solution like LISP can support this as specified. 2414 As any optimization scheme would inevitably add some complexity; the 2415 proposed scheme for enhancing mapping efficiency comes with some of 2416 its own overhead. The gain depends on the details of specific EID 2417 blocks, i.e., how frequently the situations arise such as an ETR 2418 having a bigger EID block with a few holes. 2420 13.3. Rebuttal 2422 There are two main points in the critique that would be addressed 2423 here: (1) The gain depends on the details of specific EID blocks, 2424 i.e., how frequently the situations arise such as an ETR having a 2425 bigger EID block with a few holes, and (2) Approach 2 is lacking an 2426 added feature of conveying just the mask-length of the more specifics 2427 that exist as part of current map-response. 2429 Regarding comment (1) above, there are multiple possibilities 2430 regarding how situations can arise resulting in allocations having 2431 holes in them. An example of one of these possibilities is as 2432 follows. Org-A has historically received multiple /20s, /22s, /24s 2433 over the course of time which are adjacent to each other. At the 2434 present time, these prefixes would all aggregate to a /16 but for the 2435 fact that just a few of the underlying /24s have been allocated 2436 elsewhere historically to other organizations by an RIR or ISPs. An 2437 example of a second possibility is that Org-A has an allocation of a 2438 /16 prefix. It has suballocated a /22 to one of its subsidiaries, 2439 and subsequently sold the subsidiary to another Org-B. For ease of 2440 keeping the /22 subnet up and running without service disruption, the 2441 /22 subprefix is allowed to be transferred in the acquisition 2442 process. Now the /22 subprefix originates from a different AS and is 2443 serviced by a different ETR (as compared to the parent \16 prefix). 2444 We are in the process of performing an analysis of RIR allocation 2445 data and are aware of other studies (notably at UCLA) which are also 2446 performing similar analysis to quantify the frequency of occurrence 2447 of the holes. We feel that the problem that has been addressed is a 2448 realistic one, and the proposed scheme would help reduce the 2449 overheads associated with the mapping distribution system. 2451 Regarding comment (2) above, the suggested modification to Approach 2 2452 would be definitely beneficial. In fact, we feel that it would be 2453 fairly straight forward to dynamically use Approach 1 or Approach 2 2454 (with the suggested modification), depending on whether there are 2455 only a few (e.g., <=5) or many (e.g., >5) more specifics, 2456 respectively. The suggested modification of notifying the mask- 2457 length of the more specifics in map-response is indeed very helpful 2458 because then the ITR would not have to resend a map-query for EID 2459 addresses that match the EID address in the previous query up to at 2460 least mask-length bit positions. There can be a two-bit field in 2461 map-response that would indicate: (a) With value 00 for notifying 2462 that there are no more-specifics; (b) With value 01 for notifying 2463 that there are more-specifics and their exact information follows in 2464 additional map-responses, and (c) With value 10 for notifying that 2465 there are more-specifics and the mask-length of the next more- 2466 specific is indicated in the current map-response. An additional 2467 field will be included which will be used to specify the mask-length 2468 of the next more-specific in the case of the "10" indication (case 2469 (c) above). 2471 13.4. Counterpoint 2473 No counterpoint was submitted for this proposal. 2475 14. Evolution 2477 14.1. Summary 2479 As the Internet continues its rapid growth, router memory size and 2480 CPU cycle requirements are outpacing feasible hardware upgrade 2481 schedules. We propose to solve this problem by applying aggregation 2482 with increasing scopes to gradually evolve the routing system towards 2483 a scalable structure. At each evolutionary step, our solution is 2484 able to interoperate with the existing system and provide immediate 2485 benefits to adopters to enable deployment. This document summarizes 2486 the need for an evolutionary design, the relationship between our 2487 proposal and other revolutionary proposals and the steps of 2488 aggregation with increasing scopes. Our detailed proposal can be 2489 found in [I-D.zhang-evolution]. 2491 14.1.1. Need for Evolution 2493 Multiple different views exist regarding the routing scalability 2494 problem. Networks differ vastly in goals, behavior, and resources, 2495 giving each a different view of the severity and imminence of the 2496 scalability problem. Therefore we believe that, for any solution to 2497 be adopted, it will start with one or a few early adopters, and may 2498 not ever reach the entire Internet. The evolutionary approach 2499 recognizes that changes to the Internet can only be a gradual process 2500 with multiple stages. At each stage, adopters are driven by and 2501 rewarded with solving an immediate problem. Each solution must be 2502 deployable by individual networks who deem it necessary at a time 2503 they deem it necessary, without requiring coordination from other 2504 networks, and the solution has to bring immediate relief to a single 2505 first-mover. 2507 14.1.2. Relation to Other RRG Proposals 2509 Most proposals take a revolutionary approach that expects the entire 2510 Internet to eventually move to some new design whose main benefits 2511 would not materialize until the vast majority of the system has been 2512 upgraded; their incremental deployment plan simply ensures 2513 interoperation between upgraded and legacy parts of the system. In 2514 contrast, the evolutionary approach depicts a picture where changes 2515 may happen here and there as needed, but there is no dependency on 2516 the system as a whole making a change. Whoever takes a step forward 2517 gains the benefit by solving his own problem, without depending on 2518 others to take actions. Thus, deployability includes not only 2519 interoperability, but also the alignment of costs and gains. 2521 The main differences between our approach and more revolutionary map- 2522 and-encap proposals are: (a) we do not start with a pre-defined 2523 boundary between edge and core; and (b) each step brings immediate 2524 benefits to individual first-movers. Note that our proposal neither 2525 interferes nor prevents any revolutionary host-based solutions such 2526 as ILNP from being rolled out. However, host-based solutions do not 2527 bring useful impact until a large portion of hosts have been 2528 upgraded. Thus even if a host-based solution is rolled out in the 2529 long run, an evolutionary solution is still needed for the near term. 2531 14.1.3. Aggregation with Increasing Scopes 2533 Aggregating many routing entries to a fewer number is a basic 2534 approach to improving routing scalability. Aggregation can take 2535 different forms and be done within different scopes. In our design, 2536 the aggregation scope starts from a single router, then expands to a 2537 single network, and neighbor networks. The order of the following 2538 steps is not fixed but is merely a suggestion; it is under each 2539 individual network's discretion which steps they choose to take based 2540 on their evaluation of the severity of the problems and the 2541 affordability of the solutions. 2543 1. FIB Aggregation (FA) in a single router. A router 2544 algorithmically aggregates its FIB entries without changing its 2545 RIB or its routing announcements. No coordination among routers 2546 is needed, nor any change to existing protocols. This brings 2547 scalability relief to individual routers with only a software 2548 upgrade. 2550 2. Enabling 'best external' on PEs, ASBRs, and RRs, and turning on 2551 next-hop-self on RRs. For hierarchical networks, the RRs in each 2552 PoP can serve as a default gateway for nodes in the PoP, thus 2553 allowing the non-RR nodes in each PoP to maintain smaller routing 2554 tables that only include paths that egress out of that PoP. This 2555 is known as 'topology-based mode' Virtual Aggregation, and can be 2556 done with existing hardware and configuration changes only. 2557 Please see [Evolution Grow Presentation] for details. 2559 3. Virtual Aggregation (VA) in a single network. Within an AS, some 2560 fraction of existing routers are designated as Aggregation Point 2561 Routers (APRs). These routers are either individually or 2562 collectively maintain the full FIB table. Other routers may 2563 suppress entries from their FIBs, instead forwarding packets to 2564 APRs, which will then tunnel the packets to the correct egress 2565 routers. VA can be viewed as an intra-domain map-and-encap 2566 system to provide the operators with a control mechanism for the 2567 FIB size in their routers. 2569 4. VA across neighbor networks. When adjacent networks have VA 2570 deployed, they can go one step further by piggybacking egress 2571 router information on existing BGP announcements, so that packets 2572 can be tunneled directly to a neighbor network's egress router. 2573 This improves packet delivery performance by performing the 2574 encapsulation/decapsulation only once across these neighbor 2575 networks, as well as reducing the stretch of the path. 2577 5. Reducing RIB Size by separating the control plane from the data 2578 plane. Although a router's FIB can be reduced by FA or VA, it 2579 usually still needs to maintain the full RIB to produce complete 2580 routing announcements to its neighbors. To reduce the RIB size, 2581 a network can set up special boxes, which we call controllers, to 2582 take over the eBGP sessions from border routers. The controllers 2583 receive eBGP announcements, make routing decisions, and then 2584 inform other routers in the same network of how to forward 2585 packets, while the regular routers just focus on the job of 2586 forwarding packets. The controllers, not being part of the data 2587 path, can be scaled using commodity hardware. 2589 6. Insulating forwarding routers from routing churn. For routers 2590 with a smaller RIB, the rate of routing churn is naturally 2591 reduced. Further reduction can be achieved by not announcing 2592 failures of customer prefixes into the core, but handling these 2593 failures in a data-driven fashion, e.g., a link failure to an 2594 edge network is not reported unless and until there are data 2595 packets that are heading towards the failed link. 2597 14.1.4. References 2599 [I-D.zhang-evolution] [Evolution Grow Presentation] 2601 14.2. Critique 2603 All of the RRG proposals that scale the routing architecture share 2604 one fundamental approach, route aggregation, in different forms, 2605 e.g., LISP removes "edge prefixes" using encapsulation at ITRs, and 2606 ILNP achieves the goal by locator rewrite. In this evolutionary path 2607 proposal, each stage of the evolution applies aggregation with 2608 increasing scopes to solve a specific scalability problem, and 2609 eventually the path leads towards global routing scalability. For 2610 example, it uses FIB aggregation at the single router level, virtual 2611 aggregation at the network level, and then between neighboring 2612 networks at the inter-domain level. 2614 Compared to other proposals, this proposal has the lowest hurdle to 2615 deployment, because it does not require that all networks move to use 2616 a global mapping system or upgrade all hosts, and it is designed for 2617 each individual network to get immediate benefits after its own 2618 deployment. 2620 Criticisms of this proposal fall into two types. The first type 2621 concerns several potential issues in the technical design as listed 2622 below: 2624 1. FIB aggregation, at level-3 and level-4, may introduce extra 2625 routable space. Concerns have been raised about the potential 2626 routing loops resulting from forwarding otherwise non-routable 2627 packets, and the potential impact on RPF checking. These 2628 concerns can be addressed by choosing a lower level of 2629 aggregation and by adding null routes to minimize the extra 2630 space, at the cost of reduced aggregation gain. 2632 2. Virtual Aggregation changes the traffic paths in an ISP network, 2633 thereby introducing stretch. Changing the traffic path may also 2634 impact the reverse path checking practice used to filter out 2635 packets from spoofed sources. More analysis is need to identify 2636 the potential side-effects of VA and to address these issues. 2638 3. The current Virtual Aggregation description is difficult to 2639 understand, due to its multiple options for encapsulation and 2640 popular prefix configurations, which makes the mechanism look 2641 overly complicated. More thought is needed to simplify the 2642 design and description. 2644 4. FIB Aggregation and Virtual Aggregation may require additional 2645 operational cost. There may be new design trade-offs that the 2646 operators need to understand in order to select the best option 2647 for their networks. More analysis is needed to identify and 2648 quantify all potential operational costs. 2650 5. In contrast to a number of other proposals, this solution does 2651 not provide mobility support. It remains an open question as to 2652 whether the routing system should handle mobility. 2654 The second criticism is whether deploying quick fixes like FIB 2655 aggregation would alleviate scalability problems in the short term 2656 and reduce the incentives for deploying a new architecture; and 2657 whether an evolutionary approach would end up with adding more and 2658 more patches to the old architecture, and not lead to a fundamentally 2659 new architecture as the proposal had expected. Though this solution 2660 may get rolled out more easily and quickly, a new architecture, if/ 2661 once deployed, could solve more problems with cleaner solutions. 2663 14.3. Rebuttal 2665 No rebuttal was submitted for this proposal. 2667 14.4. Counterpoint 2669 No counterpoint was submitted for this proposal. 2671 15. Name-Based Sockets 2673 15.1. Summary 2675 Name-based sockets are an evolution of the existing address-based 2676 sockets, enabling applications to initiate and receive communication 2677 sessions based on the use of domain names in lieu of IP addresses. 2678 Name-based sockets move the existing indirection from domain names to 2679 IP addresses from its current position in applications down to the IP 2680 layer. As a result, applications communicate exclusively based on 2681 domain names, while the discovery, selection, and potentially in- 2682 session re-selection of IP addresses is centrally performed by the IP 2683 stack itself. 2685 Name-based sockets help mitigate the Internet routing scalability 2686 problem by separating naming and addressing more consistently than 2687 what is possible with the existing address-based sockets. This 2688 supports IP address aggregation because it simplifies the use of IP 2689 addresses with high topological significance, as well as the dynamic 2690 replacement of IP addresses during network-topological and host- 2691 attachment changes. 2693 A particularly positive effect of name-based sockets on Internet 2694 routing scalability is the new incentives for edge network operators 2695 to use provider-assigned IP addresses, which are more aggregatable 2696 than the typically preferred provider-independent IP addresses. Even 2697 though provider-independent IP addresses are harder to get and more 2698 expensive than provider-assigned IP addresses, many operators desire 2699 provider-independent addresses due to the high indirect cost of 2700 provider-assigned IP addresses. This indirect cost is comprised of 2701 both difficulties in multihoming, and tedious and largely manual 2702 renumbering upon provider changes. 2704 Name-based sockets reduce the indirect cost of provider-assigned IP 2705 addresses in three ways, and hence make the use of provider-assigned 2706 IP addresses more acceptable: (1) They enable fine-grained and 2707 responsive multihoming. (2) They simplify renumbering by offering an 2708 easy means to replace IP addresses in referrals with domain names. 2709 This helps avoiding updates to application and operating system 2710 configurations, scripts, and databases during renumbering. (3) They 2711 facilitate low-cost solutions that eliminate renumbering altogether. 2712 One such low-cost solution is IP address translation, which in 2713 combination with name-based sockets loses its adverse impact on 2714 applications. 2716 The prerequisite for a positive effect of name-based sockets on 2717 Internet routing scalability is their adoption in operating systems 2718 and applications. Operating systems should be augmented to offer 2719 name-based sockets as a new alternative to the existing address-based 2720 sockets, and applications should use name-based sockets for their 2721 communications. Neither an instantaneous, nor an eventually complete 2722 transition to name-based sockets is required, yet the positive effect 2723 on Internet routing scalability will grow with the extent of this 2724 transition. 2726 Name-based sockets were hence designed with a focus on deployment 2727 incentives, comprising both immediate deployment benefits as well as 2728 low deployment costs. Name-based sockets provide a benefit to 2729 application developers because the alleviation of applications from 2730 IP address management responsibilities simplifies and expedites 2731 application development. This benefit is immediate owing to the 2732 backwards compatibility of name-based sockets with legacy 2733 applications and legacy peers. The appeal to application developers, 2734 in turn, is an immediate benefit for operating system vendors who 2735 adopt name-based sockets. 2737 Name-based sockets furthermore minimize deployment costs: Alternative 2738 techniques to separate naming and addressing provide applications 2739 with "surrogate IP addresses" that dynamically map onto regular IP 2740 addresses. A surrogate IP address is indistinguishable from a 2741 regular IP address for applications, but does not have the 2742 topological significance of a regular IP address. Mobile IP and the 2743 Host Identity Protocol are examples of such separation techniques. 2744 Mobile IP uses "home IP addresses" as surrogate IP addresses with 2745 reduced topological significance. The Host Identity Protocol uses 2746 "host identifiers" as surrogate IP addresses without topological 2747 significance. A disadvantage of surrogate IP addresses is their 2748 incurred cost in terms of extra administrative overhead and, for some 2749 techniques, extra infrastructure. Since surrogate IP addresses must 2750 be resolvable to the corresponding regular IP addresses, they must be 2751 provisioned in the DNS or similar infrastructure. Mobile IP uses a 2752 new infrastructure of home agents for this purpose, while the Host 2753 Identity Protocol populates DNS servers with host identities. Name- 2754 based sockets avoid this cost because they function without surrogate 2755 IP addresses, and hence without the provisioning and infrastructure 2756 requirements that accompany surrogate addresses. 2758 Certainly, some edge networks will continue to use provider- 2759 independent addresses despite name-based sockets, perhaps simply due 2760 to inertia. But name-based sockets will help reduce the number of 2761 those networks, and thus have a positive impact on Internet routing 2762 scalability. 2764 A more comprehensive description of name-based sockets can be found 2765 in [Name Based Sockets]. 2767 15.1.1. References 2769 [Name Based Sockets] 2771 15.2. Critique 2773 Name-based sockets contribution to the routing scalability problem is 2774 to decrease the reliance on PI addresses, allowing a greater use of 2775 PA addresses, and thus a less fragmented routing table. It provides 2776 end hosts with an API which makes the applications address-agnostic. 2777 The name abstraction allows the hosts to use any type of locator, 2778 independent of format or provider. This increases the motivation and 2779 usability of PA addresses. Some applications, in particular 2780 bootstrapping applications, may still require hard coded IP 2781 addresses, and as such will still motivate the use of PI addresses. 2783 15.2.1. Deployment 2785 The main incentives and drivers are geared towards the transition of 2786 applications to the name-based sockets. Adoption by applications 2787 will be driven by benefits in terms of reduced application 2788 development cost. Legacy applications are expected to migrate to the 2789 new API at a slower pace, as the name-based sockets are backwards 2790 compatible, this can happen in a per-host fashion. Also, not all 2791 applications can be ported to a FQDN dependent infrastructure, e.g. 2792 DNS functions. This hurdle is manageable, and may not be a definite 2793 obstacle for the transition of a whole domain, but it needs to be 2794 taken into account when striving for mobility/multihoming of an 2795 entire site. The transition of functions on individual hosts may be 2796 trivial, either through upgrades/changes to the OS or as linked 2797 libraries. This can still happen incrementally and independently, as 2798 compatibility is not affected by the use of name-based sockets. 2800 15.2.2. Edge-networks 2802 Name-based sockets rely on the transition of individual applications 2803 and are backwards compatible, so they do not require bilateral 2804 upgrades. This allows each host to migrate its applications 2805 independently. Name-based sockets may make an individual client 2806 agnostic to the networking medium, be it PA/PI IP-addresses or in a 2807 the future an entirely different networking medium. However, an 2808 entire edge-network, with internal and external services will not be 2809 able to make a complete transition in the near future. Hence, even 2810 if a substantial fraction of the hosts in an edge-network use name- 2811 based sockets, PI addresses may still be required by the edge- 2812 network. In short, new services may be implemented using name-based 2813 sockets, old services may be ported. Name-based sockets provide an 2814 increased motivation to move to PA-addresses as actual provider 2815 independence relies less and less on PI-addressing. 2817 15.3. Rebuttal 2819 No rebuttal was submitted for this proposal. 2821 15.4. Counterpoint 2823 No counterpoint was submitted for this proposal. 2825 16. Routing and Addressing in Networks with Global Enterprise Recursion 2826 (IRON-RANGER) 2828 16.1. Summary 2830 RANGER is a locator-identifier separation approach that uses IP-in-IP 2831 encapsulation to connect edge networks across transit networks such 2832 as the global Internet. End systems use endpoint interface 2833 identifier (EID) addresses that may be routable within edge networks 2834 but do not appear in transit network routing tables. EID to Routing 2835 Locator (RLOC) address bindings are instead maintained in mapping 2836 tables and also cached in default router FIBs (i.e., very much the 2837 same as for the global DNS and its associated caching resolvers). 2838 RANGER enterprise networks are organized in a recursive hierarchy 2839 with default mappers connecting lower layers to the next higher layer 2840 in the hierarchy. Default mappers forward initial packets and push 2841 mapping information to lower-tier routers and end systems through 2842 secure redirection. 2844 RANGER is an architectural framework derived from the Intra-Site 2845 Automatic Tunnel Addressing Protocol (ISATAP). 2847 16.1.1. Gains 2849 o provides a scalable routing system alternative in instances where 2850 dynamic routing protocols are impractical 2852 o naturally supports a recursively-nested "network-of-networks" (or, 2853 "enterprise-within-enterprise") hierarchy 2855 o uses asymmetric security mechanisms (i.e., secure neighbor 2856 discovery) to secure router discovery and the redirection 2857 mechanism 2859 o can quickly detect path failures and pick alternate routes 2861 o naturally supports provider-independent addressing 2863 o support for site multihoming and traffic engineering 2865 o ingress filtering for multihomed sites 2867 o mobility-agile through explicit cache invalidation (much more 2868 reactive than DynDns) 2870 o supports neighbor discovery and neighbor unreachability detection 2871 over tunnels 2873 o no changes to end systems 2875 o no changes to most routers 2877 o supports IPv6 transition 2879 o compatible with true identity/locator split mechanisms such as HIP 2880 (i.e., packets contain a HIP Host Identity Tag (HIT) as an end 2881 system identifier, IPv6 address as endpoint Interface iDentifier 2882 (EID) in the inner IP header and IPv4 address as Routing LOCator 2883 (RLOC) in the outer IP header) 2885 o prototype code available 2887 16.1.2. Costs 2889 o new code needed in enterprise border routers 2891 o locator/path liveness detection using RFC4861 neighbor 2892 unreachability detection (i.e., extra control messages, but data- 2893 driven) 2895 16.1.3. References 2897 [I-D.templin-iron] [I-D.russert-rangers] [I-D.templin-intarea-vet] 2898 [I-D.templin-intarea-seal] [RFC5201] [RFC5214] [RFC5720] 2900 16.2. Critique 2902 The RANGER architectural framework is intended to be applicable for a 2903 Core-Edge Separation (CES) architecture for scalable routing, using 2904 either IPv4 or IPv6 - or using both in an integrated system which may 2905 carry one protocol over the other. 2907 However, despite the ID being readied for publication as an 2908 experimental RFC, the framework falls well short of the level of 2909 detail required to envisage how it could be used to implement a 2910 practical scalable routing solution. For instance, the ID contains 2911 no specification for a mapping protocol, or how the mapping lookup 2912 system would work on a global scale. 2914 There is no provision for RANGER's ITR-like routers being able to 2915 probe the reachability of end-user networks via multiple ETR-like 2916 routers - nor for any other approach to multihoming service 2917 restoration. 2919 Nor is there any provision for inbound TE or support of mobile 2920 devices which frequently change their point of attachment. 2922 Therefore, in its current form, RANGER cannot be contemplated as a 2923 superior scalable routing solution to some other proposals which are 2924 specified in sufficient detail and which appear to be feasible. 2926 RANGER uses its own tunneling and PMTUD management protocol: SEAL. 2927 Adoption of SEAL in its current form would prevent the proper 2928 utilization of jumbo frame paths in the DFZ, which will become the 2929 norm in the future. SEAL uses RFC 1191 PTB messages to the sending 2930 host only to fix a preset maximum packet length. To avoid the need 2931 for the SEAL layer to fragment packets of this length, this MTU value 2932 (for the input of the tunnel) needs to be set significantly below 2933 1500 bytes, assuming the typically ~1500 byte MTU values for paths 2934 across the DFZ today. In order to avoid this excessive 2935 fragmentation, this value could only be raised to a ~9k byte value at 2936 some time in the future where essentially all paths between ITRs and 2937 ETRs were jumbo frame capable. 2939 16.3. Rebuttal 2941 The Internet Routing Overlay Network (IRON) [I-D.templin-iron] is a 2942 scalable Internet routing architecture that builds on the RANGER 2943 recursive enterprise network hierarchy [RFC5720]. IRON bonds 2944 together participating RANGER networks using VET 2945 [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal] to 2946 enable secure and scalable routing through automatic tunneling within 2947 the Internet core. The IRON-RANGER automatic tunneling abstraction 2948 views the entire global Internet DFZ as a virtual NBMA link similar 2949 to ISATAP [RFC5214]. 2951 IRON-RANGER is an example of a Core-Edge Separation (CES) system. 2952 Instead of a classical mapping database, however, IRON-RANGER uses a 2953 hybrid combination of a proactive dynamic routing protocol for 2954 distributing highly aggregated Virtual Prefixes (VPs) and an on- 2955 demand data driven protocol for distributing more-specific Provider 2956 Independent (PI) prefixes derived from the VPs. 2958 The IRON-RANGER hierarchy consists of recursively-nested RANGER 2959 enterprise networks joined together by IRON routers that participate 2960 in a global BGP instance. The IRON BGP instance is maintained 2961 separately from the current Internet BGP Routing LOCator (RLOC) 2962 address space (i.e., the set of all public IPv4 prefixes in the 2963 Internet). Instead, the IRON BGP instance maintains VPs taken from 2964 Endpoint Interface iDentifier (EID) address space, e.g., the IPv6 2965 global unicast address space. To accommodate scaling, only O(10k) - 2966 O(100k) VPs are allocated e.g., using /20 or shorter IPv6 prefixes. 2968 IRON routers lease portions of their VPs as Provider Independent (PI) 2969 prefixes for customer equipment (CEs), thereby creating a sustainable 2970 business model. CEs that lease PI prefixes propagate address 2971 mapping(s) throughout their attached RANGER networks and up to VP- 2972 owning IRON router(s) through periodic transmission of "bubbles" with 2973 authentication and PI prefix information. Routers in RANGER networks 2974 and IRON routers that receive and forward the bubbles securely 2975 install PI prefixes in their FIBs, but do not inject them into the 2976 RIB. IRON routers therefore keep track of only their customer base 2977 via the FIB entries and keep track of only the Internet-wide VP 2978 database in the RIB. 2980 IRON routers propagate more-specific prefixes using secure 2981 redirection to update router FIBs. Prefix redirection is driven by 2982 the data plane and does not affect the control plane. Redirected 2983 prefixes are not injected into the RIB, but rather are maintained as 2984 FIB soft state that is purged after expiration or route failure. 2985 Neighbor unreachability detection is used to detect failure. 2987 Secure prefix registrations and redirections are accommodated through 2988 the mechanisms of SEAL. Tunnel endpoints using SEAL synchronize 2989 sequence numbers, and can therefore discard any packets they receive 2990 that are outside of the current sequence number window. Hence, off- 2991 path attacks are defeated. These synchronized tunnel endpoints can 2992 therefore exchange prefixes with signed certificates that prove 2993 prefix ownership in such a way that DoS vectors that attack crypto 2994 calculation overhead are eliminated due to the prevention of off-path 2995 attacks. 2997 CEs can move from old RANGER networks and re-inject their PI prefixes 2998 into new RANGER networks. This would be accommodated by IRON-RANGER 2999 as a site multihoming event while host mobility and true locator-ID 3000 separation is accommodated via HIP [RFC5201]. 3002 16.4. Counterpoint 3004 No counterpoint was submitted for this proposal. 3006 17. Recommendation 3008 As can be seen from the extensive list of proposals above, the group 3009 explored a number of possible solutions. Unfortunately, the group 3010 did not reach rough consensus on a single best approach. 3011 Accordingly, the recommendation has been left to the co-chairs. The 3012 remainder of this section describes the rationale and decision of the 3013 co-chairs. 3015 As a reminder, the goal of the research group was to develop a 3016 recommendation for an approach to a routing and addressing 3017 architecture for the Internet. The primary goal of the architecture 3018 is to provide improved scalability for the routing subsystem. 3019 Specifically, this implies that we should be able to continue to grow 3020 the routing subsystem to meet the needs of the Internet without 3021 requiring drastic and continuous increases in the amount of state or 3022 processing requirements for routers. 3024 17.1. Motivation 3026 There is a general concern that the cost and structure of the routing 3027 and addressing architecture as we know it today may become 3028 prohibitively expensive with continued growth, with repercussions to 3029 the health of the Internet. As such, there is an urgent need to 3030 examine and evaluate potential scalability enhancements. 3032 For the long term future of the Internet, it has become apparent that 3033 IPv6 is going to play a significant role. It has taken more than a 3034 decade, but IPv6 is starting to see some non-trivial amount of 3035 deployment. This is in part due to the depletion of IPv4 addresses. 3036 It therefore seems apparent that the new architecture must be 3037 applicable to IPv6. It may or may not be applicable to IPv4, but not 3038 addressing the IPv6 portion of the network would simply lead to 3039 recreating the routing scalability problem in the IPv6 domain, 3040 because the two share a common routing architecture. 3042 Whatever change we make, we should expect that this is a very long- 3043 lived change. The routing architecture of the entire Internet is a 3044 loosely coordinated, complex, expensive subsystem, and permanent, 3045 pervasive changes to it will require difficult choices during 3046 deployment and integration. These cannot be undertaken lightly. 3048 By extension, if we are going to the trouble, pain, and expense of 3049 making major architectural changes, it follows that we want to make 3050 the best changes possible. We should regard any such changes as 3051 permanent and we should therefore aim for long term solutions that 3052 place the network in the best possible position for ongoing growth. 3053 These changes should be cleanly integrated, first-class citizens 3054 within the architecture. That is to say that any new elements that 3055 are integrated into the architecture should be fundamental 3056 primitives, on par with the other existing legacy primitives in the 3057 architecture, that interact naturally and logically when in 3058 combination with other elements of the architecture. 3060 Over the history of the Internet, we have been very good about 3061 creating temporary, ad-hoc changes, both to the routing architecture 3062 and other aspects of the network layer. However, many of these band- 3063 aid solutions have come with a significant overhead in terms of long- 3064 term maintenance and architectural complexity. This is to be avoided 3065 and short-term improvements should eventually be replaced by long- 3066 term, permanent solutions. 3068 In the particular instance of the routing and addressing architecture 3069 today, we feel that the situation requires that we pursue both short- 3070 term improvements and long-term solutions. These are not 3071 incompatible because we truly intend for the short-term improvements 3072 to be completely localized and temporary. The short-term 3073 improvements are necessary to give us the time necessary to develop, 3074 test, and deploy the long-term solution. As the long-term solution 3075 is rolled out and gains traction, the short-term improvements should 3076 be of less benefit and can subsequently be withdrawn. 3078 17.2. Recommendation to the IETF 3080 The group explored a number of proposed solutions but did not reach 3081 consensus on a single best approach. Therefore, in fulfillment of 3082 the routing research group's charter, the co-chairs recommend that 3083 the IETF pursue work in the following areas: 3085 Aggregation in Increasing Scopes [I-D.zhang-evolution] 3087 Identifier/Locator Network Protocol (ILNP) [ILNP Site] 3089 Renumbering [RFC5887] 3091 17.3. Rationale 3093 We selected Aggregation in Increasing Scopes because it is a short- 3094 term improvement. It can be applied on a per-domain basis, under 3095 local administration and has immediate effect. While there is some 3096 complexity involved, we feel that this option is constructive for 3097 service providers who find the additional complexity to be less 3098 painful than upgrading hardware. This improvement can be deployed by 3099 domains that feel it necessary, for as long as they feel it is 3100 necessary. If this deployment lasts longer than expected, then the 3101 implications of that decision are wholly local to the domain. 3103 We recommended ILNP because we find it to be a clean solution for the 3104 architecture. It separates location from identity in a clear, 3105 straightforward way that is consistent with the remainder of the 3106 Internet architecture and makes both first-class citizens. Unlike 3107 the many map-and-encap proposals, there are no complications due to 3108 tunneling, indirection, or semantics that shift over the lifetime of 3109 a packets delivery. 3111 We recommend further work on automating renumbering because even with 3112 ILNP, the ability of a domain to change its locators at minimal cost 3113 is fundamentally necessary. No routing architecture will be able to 3114 scale without some form of abstraction, and domains that change their 3115 point of attachment must fundamentally be prepared to change their 3116 locators in line with this abstraction. We recognize that [RFC5887] 3117 is not a solution so much as a problem statement, and we are simply 3118 recommending that the IETF create effective and convenient mechanisms 3119 for site renumbering. 3121 18. Acknowledgments 3123 This document represents a small portion of the overall work product 3124 of the Routing Research Group, who have developed all of these 3125 architectural approaches and many specific proposals within this 3126 solution space. 3128 19. IANA Considerations 3130 This memo includes no requests to IANA. 3132 20. Security Considerations 3134 All solutions are required to provide security that is at least as 3135 strong as the existing Internet routing and addressing architecture. 3137 21. Informative References 3139 [CRM] Flinck, H., "Compact routing in locator identifier mapping 3140 system", . 3143 [DNSnBIND] 3144 Liu, C. and P. Albitz, "DNS & BIND", 2006. 3146 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA. 3147 ISBN 0-596-10057-4 3149 [EEMDP Considerations] 3150 Sriram, K., Kim, Y., and D. Montgomery, "Enhanced 3151 Efficiency of Mapping Distribution Protocols in Scalable 3152 Routing and Addressing Architectures", Proceedings of the 3153 ICCCN, August 2010, 3154 . 3156 Zurich, Switzerland 3158 [EEMDP Presentation] 3159 Sriram, K., Gleichmann, P., Kim, Y., and D. Montgomery, 3160 "Enhanced Efficiency of Mapping Distribution Protocols in 3161 Scalable Routing and Addressing Architectures", 3162 . 3164 Presented at the LISP WG meeting, IETF-78, July 2010. 3165 Originally presented at the RRG meeting at IETF-72. 3167 [Evolution Grow Presentation] 3168 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 3169 L. Zhang, "Virtual Aggregation (VA)", 3170 . 3172 [FIBAggregatability] 3173 Zhang, B., Wang, L., Zhao, X., Liu, Y., and L. Zhang, "An 3174 Evaluation Study of Router FIB Aggregatability", 3175 . 3177 [GLI] Menth, M., Hartmann, M., and D. Klein, "Global Locator, 3178 Local Locator, and Identifier Split (GLI-Split)", 3179 . 3181 [I-D.adan-idr-tidr] 3182 Adan, J., "Tunneled Inter-domain Routing (TIDR)", 3183 draft-adan-idr-tidr-01 (work in progress), December 2006. 3185 [I-D.carpenter-behave-referral-object] 3186 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 3187 K. Moore, "A Generic Referral Object for Internet 3188 Entities", draft-carpenter-behave-referral-object-01 (work 3189 in progress), October 2009. 3191 [I-D.farinacci-lisp-lig] 3192 Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", 3193 draft-farinacci-lisp-lig-02 (work in progress), 3194 February 2010. 3196 [I-D.frejborg-hipv4] 3197 Frejborg, P., "Hierarchical IPv4 Framework", 3198 draft-frejborg-hipv4-09 (work in progress), 3199 September 2010. 3201 [I-D.ietf-lisp] 3202 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 3203 "Locator/ID Separation Protocol (LISP)", 3204 draft-ietf-lisp-08 (work in progress), August 2010. 3206 [I-D.ietf-lisp-alt] 3207 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 3208 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-04 3209 (work in progress), April 2010. 3211 [I-D.ietf-lisp-interworking] 3212 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 3213 "Interworking LISP with IPv4 and IPv6", 3214 draft-ietf-lisp-interworking-01 (work in progress), 3215 August 2010. 3217 [I-D.ietf-lisp-ms] 3218 Fuller, V. and D. Farinacci, "LISP Map Server", 3219 draft-ietf-lisp-ms-05 (work in progress), April 2010. 3221 [I-D.irtf-rrg-design-goals] 3222 Li, T., "Design Goals for Scalable Internet Routing", 3223 draft-irtf-rrg-design-goals-02 (work in progress), 3224 September 2010. 3226 [I-D.meyer-lisp-mn] 3227 Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP 3228 Mobile Node", draft-meyer-lisp-mn-03 (work in progress), 3229 August 2010. 3231 [I-D.meyer-loc-id-implications] 3232 Meyer, D. and D. Lewis, "Architectural Implications of 3233 Locator/ID Separation", draft-meyer-loc-id-implications-01 3234 (work in progress), January 2009. 3236 [I-D.narten-radir-problem-statement] 3237 Narten, T., "On the Scalability of Internet Routing", 3238 draft-narten-radir-problem-statement-05 (work in 3239 progress), February 2010. 3241 [I-D.rja-ilnp-nonce] 3242 Atkinson, R., "ILNP Nonce Destination Option", 3243 draft-rja-ilnp-nonce-06 (work in progress), August 2010. 3245 [I-D.russert-rangers] 3246 Russert, S., Fleischman, E., and F. Templin, "RANGER 3247 Scenarios", draft-russert-rangers-05 (work in progress), 3248 July 2010. 3250 [I-D.templin-intarea-seal] 3251 Templin, F., "The Subnetwork Encapsulation and Adaptation 3252 Layer (SEAL)", draft-templin-intarea-seal-17 (work in 3253 progress), September 2010. 3255 [I-D.templin-intarea-vet] 3256 Templin, F., "Virtual Enterprise Traversal (VET)", 3257 draft-templin-intarea-vet-16 (work in progress), 3258 July 2010. 3260 [I-D.templin-iron] 3261 Templin, F., "The Internet Routing Overlay Network 3262 (IRON)", draft-templin-iron-12 (work in progress), 3263 September 2010. 3265 [I-D.whittle-ivip-drtm] 3266 Whittle, R., "DRTM - Distributed Real Time Mapping for 3267 Ivip and LISP", draft-whittle-ivip-drtm-01 (work in 3268 progress), March 2010. 3270 [I-D.whittle-ivip-glossary] 3271 Whittle, R., "Glossary of some Ivip and scalable routing 3272 terms", draft-whittle-ivip-glossary-01 (work in progress), 3273 March 2010. 3275 [I-D.whittle-ivip4-etr-addr-forw] 3276 Whittle, R., "Ivip4 ETR Address Forwarding", 3277 draft-whittle-ivip4-etr-addr-forw-02 (work in progress), 3278 January 2010. 3280 [I-D.xu-rangi] 3281 Xu, X., "Routing Architecture for the Next Generation 3282 Internet (RANGI)", draft-xu-rangi-04 (work in progress), 3283 August 2010. 3285 [I-D.xu-rangi-proxy] 3286 Xu, X., "Transition Mechanisms for Routing Architecture 3287 for the Next Generation Internet (RANGI)", 3288 draft-xu-rangi-proxy-01 (work in progress), July 2009. 3290 [I-D.zhang-evolution] 3291 Zhang, B. and L. Zhang, "Evolution Towards Global Routing 3292 Scalability", draft-zhang-evolution-02 (work in progress), 3293 October 2009. 3295 [ILNP Site] 3296 Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and 3297 M. Lad, "ILNP - Identifier/Locator Network Protocol", 3298 . 3300 [Ivip Constraints] 3301 Whittle, R., "List of constraints on a successful scalable 3302 routing solution which result from the need for widespread 3303 voluntary adoption", 3304 . 3306 [Ivip Mobility] 3307 Whittle, R., "TTR Mobility Extensions for Core-Edge 3308 Separation Solutions to the Internet's Routing Scaling 3309 Problem", 3310 . 3312 [Ivip PMTUD] 3313 Whittle, R., "IPTM - Ivip's approach to solving the 3314 problems with encapsulation overhead, MTU, fragmentation 3315 and Path MTU Discovery", 3316 . 3318 [Ivip6] Whittle, R., "Ivip6 - instead of map-and-encap, use the 20 3319 bit Flow Label as a Forwarding Label", 3320 . 3322 [LMS] Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A 3323 Layered Mapping System For Scalable Routing", . 3328 [LMS Summary] 3329 Sun, C., "A Layered Mapping System (Summary)", . 3333 [MILCOM1] Atkinson, R. and S. Bhatti, "Site-Controlled Secure Multi- 3334 homing and Traffic Engineering for IP", IEEE Military 3335 Communications Conference (MILCOM) 28, Boston, MA, USA, 3336 October 2009. 3338 [MILCOM2] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised 3339 Resilience, Multi-homing and Mobility Capability for IP", 3340 IEEE Military Communications Conference (MILCOM) 27, San 3341 Diego, CA, USA, November 2008. 3343 [MobiArch1] 3344 Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an 3345 Integrated Service through the Use of Naming", ACM 3346 International Workshop on Mobility in the Evolving 3347 Internet (MobiArch) 2, Kyoto, Japan, August 2007. 3349 [MobiArch2] 3350 Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through 3351 Naming: Impact on DNS", ACM International Workshop on 3352 Mobility in the Evolving Internet (MobiArch) 3, Seattle, 3353 USA, August 2008. 3355 [Name Based Sockets] 3356 Vogt, C., "Simplifying Internet Applications Development 3357 With A Name-Based Sockets Interface", . 3361 [RANGI] Xu, X., "Routing Architecture for the Next-Generation 3362 Internet (RANGI)", 3363 . 3365 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 3366 Update", RFC 3007, November 2000. 3368 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 3369 Rose, "DNS Security Introduction and Requirements", 3370 RFC 4033, March 2005. 3372 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 3373 Rose, "Resource Records for the DNS Security Extensions", 3374 RFC 4034, March 2005. 3376 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 3377 Rose, "Protocol Modifications for the DNS Security 3378 Extensions", RFC 4035, March 2005. 3380 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 3381 (HIP) Architecture", RFC 4423, May 2006. 3383 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 3384 "Host Identity Protocol", RFC 5201, April 2008. 3386 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 3387 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 3388 March 2008. 3390 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 3391 Locator Pair Exploration Protocol for IPv6 Multihoming", 3392 RFC 5534, June 2009. 3394 [RFC5720] Templin, F., "Routing and Addressing in Networks with 3395 Global Enterprise Recursion (RANGER)", RFC 5720, 3396 February 2010. 3398 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 3399 Still Needs Work", RFC 5887, May 2010. 3401 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 3402 IPv6 Network Address Translation", RFC 5902, July 2010. 3404 [TIDR AS forwarding] 3405 Adan, J., "yetAnotherProposal: AS-number forwarding", 3406 . 3408 [TIDR and LISP] 3409 Adan, J., "LISP etc architecture", 3410 . 3412 [TIDR identifiers] 3413 Adan, J., "TIDR using the IDENTIFIERS attribute", . 3416 [Valiant] Zhang-Shen, R. and N. McKeown, "Designing a Predictable 3417 Internet Backbone Network", . 3420 Author's Address 3422 Tony Li (editor) 3423 Cisco Systems 3424 170 West Tasman Dr. 3425 San Jose, CA 95134 3426 USA 3428 Phone: +1 408 853 9317 3429 Email: tony.li@tony.li