idnits 2.17.1 draft-deshpande-intarea-ipaddress-reclassification-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 9. IANA Considerations' ) ** The abstract seems to contain references ([RFC3513], [RFC793], [RFC4271], [RFC4864], [RFC7868], [RFC6182], [RFC4274], [RFC3549], [RFC6437]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 10, 2018) is 2024 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? 'RFC793' on line 458 looks like a reference -- Missing reference section? 'RFC4271' on line 460 looks like a reference -- Missing reference section? 'RFC4274' on line 462 looks like a reference -- Missing reference section? 'RFC7868' on line 464 looks like a reference -- Missing reference section? 'RFC3513' on line 467 looks like a reference -- Missing reference section? 'RFC6182' on line 470 looks like a reference -- Missing reference section? 'RFC4864' on line 473 looks like a reference -- Missing reference section? 'RFC6437' on line 475 looks like a reference -- Missing reference section? 'RFC3549' on line 477 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Intarea Working Group V. Deshpande 2 Internet-Draft 3 Intended status: Experimental 4 Expires: April, 2019 Oct 10, 2018 6 IP address space reclassification 7 draft-deshpande-intarea-ipaddress-reclassification-04.txt 9 Status of This Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 This document may contain material from IETF Documents or 15 IETF Contributions published or made publicly available 16 before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted 18 the IETF Trust the right to allow modifications of such 19 material outside the IETF Standards Process. Without 20 obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be 22 modified outside the IETF Standards Process, and derivative 23 works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or 25 to translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet 28 Engineering Task Force (IETF), its areas, and its working 29 groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of 33 six months and may be updated, replaced, or obsoleted by 34 other documents at any time. It is inappropriate to use 35 Internet-Drafts as reference material or to cite them other 36 than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be 42 accessed at http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on March, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this 53 document. Please review these documents carefully, as they 54 describe your rights and restrictions with respect to this 55 document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 57 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Abstract 62 This draft proposes IP address reclassification. By understanding 63 how the Network is evolving from wireless technologies and comparing 64 with an abstract mathematical topological space model, changes such 65 as addition of a Virtual address space and Virtual BGP neighborship 66 are proposed. 67 The limitations of current Internet Architecture are identified and 68 the corrections needed for the traffic bottleneck present in the 69 current Internet Architecture are described further. 70 The interdependence of IPv6 ULA addressing scheme, multipath and 71 multipath TCP with the virtual neighborship and the virtual address 72 space are explored. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. The Mathematical premise for the electromagnetic equivalent . . 3 78 3. Design considerations for the Internet architecture . . . . . 3 79 4. Complexities in analyzing the Internet as a topological space . 4 80 4.1 Complexity of Computation . . . . . . . . . . . . . . . . . . 4 81 4.2 Complexity of Algorithms . . . . . . . . . . . . . . . . . . . 4 82 4.3 Complexity of Connectedness . . . . . . . . . . . . . . . . . 4 83 4.4 The Problem of Observability . . . . . . . . . . . . . . . . 5 84 5. Internet architecture based on the design considerations . . . 5 85 6. IPv6 address assignment for the Virtual address space . . . . . 9 86 7. Glossary of terms and definitions . . . . . . . . . . . . . . 10 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 93 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 94 1. Introduction 96 This draft proposes IPv6 address re-classification. An attempt is 97 made to identify the significant traffic bottlenecks in the 98 Internet. IPv6 address space is re-classified by adding a new virtual 99 address space which facilitated a highly parallelized traffic control 100 system to resolve the traffic bottleneck problems. 101 By assuming a mathematical premise of a finite topological space 102 with interior, exterior and closure an attempt is made to 103 retain the open system interconnection characteristic of the 104 Internet in the virtual address space through virtual BGP 105 neighborship. Multipath and Multipath TCP connections are also 106 recognized as being suitable for implementing the virtual BGP 107 neighborship. The IPv6 ULA addressing scheme is recognized as being 108 well suited for address assignment in the virtual address space. 109 A more detailed architecture is beyond scope as of now however an 110 attempt is made to spell out the design guidelines. A glossary at 111 the end contains the meaning of terms and definitions used in this 112 draft. 114 2. The Mathematical premise for the electromagnetic equivalent 116 The electromagnetic phenomenon observed in a waveguide is that the 117 wave propagation can be restricted to one dimension through total 118 internal reflection. At the critical angle the wave is split into 119 two or more waves. This is the principle behind multipath 120 propagation and also the basis for MIMO technology. Mathematically 121 this is similar to the path connectedness in a finite topological 122 space. The MIMO routing principles are thus applicable to wired 123 networks. MIMO is equivalent to Multipath. Therefore as MIMO routing 124 is cluster by cluster, multipath routing in wired networks is also 125 restricted to occur through clusters rather than between nodes. 127 3. Design considerations for the Internet architecture 129 Rather than viewing Computer communication as Host to Host as in 130 the traditional OSI and TCP models the computational and algorithmic 131 complexity of a network can be better understood by taking a step 132 back and viewing the communication as Machine to Machine. 134 On applying the principles of the Von Neumann bottleneck the 135 significant traffic can be identified as transit traffic between 136 ISPs and peer to peer traffic between ISPs. In other words the 137 Inter-AS traffic and the CsC traffic. 139 4. Complexities in analyzing the Internet as a topological space 141 4.1 Complexity of Computation 142 4.1.1 A local computation may not yield a global routing table which 143 can resolve global routing problems. 144 4.1.2 OSPF computation is evenly spread through the area or the core 145 AS. 147 4.2 Complexity of Algorithms 148 4.2.1 OSPF is based on Heap sort which is a maximally efficient 149 priority queue based on the heap data structure 150 4.2.2 OSPF redistribution repeats the advertisement of routes. A 151 classful boundary exists between areas as OSPF reoriginates 152 summary routes at an ABR 153 4.2.3 The above constraints bring about restrictions on 154 redistribution,re-routing, multipath routing due to the classful 155 queuing and addressing limits. 156 4.2.4 BGP selects and inserts certain routes (path selection 157 attributes) and merges routes. Therefore BGP can be considered as 158 having characteristics of selection, insertion sorts as well as 159 merge sort. 161 4.3 Complexity of Connectedness 162 4.3.1 Path connectedness in a finite space acts as a limitation 163 for multipath routing. Thus multipath routing in wired networks 164 need to evolve from MIMO routing. 165 4.3.2 A Tree is a (Un)Directed Acyclic Graph (DAG). 166 4.3.3 A Polytree (sort of a tree on top of a tree) is a DAG whose 167 underlying undirected graph is a tree (Refer Figure 3). 168 4.3.4 In order to design the Internet architecture the acyclic 169 aspects of a Tree structure must be considered. 170 4.3.5 DAG traversal can be performed in-order, pre-order, 171 post-order and in-level. 172 4.3.6 The IBGP full mesh is similar to a strongly connected 173 component in a DAG. 174 4.3.7 Critical path analysis is needed to enhance the Internet 175 architecture. 176 4.3.8 Features such as Transitive reduction and Critical path 177 Analysis should resolve the Internet routing, congestion and 178 convergence challenges. 180 4.4 The Problem of Observability 181 The above complexities of Computation, algorithms and connectedness 182 are bounded by an AS. Thus all must be concurrently observed at 183 multiple provider edge points on an AS to serve any purpose from a 184 control plane perspective. 185 Observability can be more clearly understood through the concept 186 of a virtual state that is assumed to be occurring in Virtual BGP. 187 This is similar to the BGP modes Read-only, Calculating best path, 188 and Read and Write. 189 +--------------+ +--------------+ 190 | | | | 191 | Readable | | Observable | 192 | +-------> | 193 | | | | 194 +------^-------+ +------+-------+ 195 | | 196 | | 197 +------+-------+ +------v-------+ 198 | | | | 199 | Writable | | Functionable | 200 | <-------+ | 201 | | | | 202 +--------------+ +--------------+ 203 Figure 1: Observability 205 5. Internet architecture based on the design considerations 207 The significant traffic is controlled by BGP and Route 208 reflectors. The flow of this significant traffic traverses a 209 hierarchical tree structure through various tiers of the service 210 provider network. Therefore it can be inferred that the traffic is 211 flowing in top-down(north-south manner). In order to introduce 212 parallelism (east-west traffic) for this significant traffic, 213 Multipath TCP, dynamic path recalculation and re-routing by virtual 214 redistribution(transit reduction) through RR clusters are feasible 215 techniques. These techniques can be implemented within an AS. But 216 due to the problem of Observability the analytical data needed for 217 these techniques is present at the provider edges of the AS. Due to 218 this point presence at various edges of an AS and the classful queue 219 and algorithmic boundaries as described previously, a control plane 220 in a separate address space is needed. The complex plane 221 characteristics of the topological space indicates that the new 222 address space needs to be a virtual address space. 224 The virtual address space can facilitate pre-ordering of flows, 225 pre-establishment of connections and pre-originating of routes. The 226 virtual address space can also pre-classify QoS for the significant 227 traffic. 228 There is an implicit redundancy between distributed firewalls. 229 This suggests that virtual redistribution is feasible. Virtual 230 redistribution is a pre-origination and re-origination of a route as 231 usually happens on an Area Border Router in OSPF. However in the 232 IBGP Core the pre-origination and re-origination must occur at a 233 Route Reflector through clusters. However the reorigination is for 234 a route or a set of routes already present in the routing table to 235 follow an alternate feasible path. 237 +--------------+-----------------+--------------+ 238 | | | | 239 | | | | 240 | Process | Application | Process | 241 | | | | 242 | | | | 243 +-----------------------------------------------+ 244 | | | | 245 | | | | 246 | Host | Transport | Host | 247 | | | | 248 | | | | 249 +-----------------------------------------------+ 250 | | | | 251 | | | | 252 | Node and | Internet | Node and | 253 | Cluster | | Cluster | 254 | | | | 255 +-----------------------------------------------+ 256 | | | | 257 | | | | 258 | Media | Link | Media | 259 | | | | 260 | | | | 261 +--------------+-----------------+--------------+ 262 Figure 2: 263 TCP/IP Model with different communication functions at each layer 264 However a major challenge exists at the boundary of the AS due to 265 closure property. There exists a boundary value problem or in other 266 words the boundary between EBGP and IBGP needs to be analyzed as a 267 closed set. Therefore a unique mapping is needed at each point that 268 connects to the Virtual address space at the AS boundary. As the 269 critical network information is at the boundary of the AS the 270 virtual address space needs to connect to each AS boundary on at 271 the most 2 to 3 points for each AS. The Data folds onto itself at 272 the AS boundary. 273 +--------------------------------------------------------------------+ 274 | +--------------------------------------------------------+ | 275 | | Global Segment Controller (AS or Domain) | | 276 | +--------------------------------------------------------+ | 277 | | 278 | Virtual Address Space | 279 | +-------------------------+ +---------------------------+ | 280 | |Global Segment Controller| |Global Segment Controller | | 281 | +-------------------------+ +---------------------------+ | 282 | +-----------------+ +-------------------+ +-------------------+ | 283 | | Local Segment | | Local Segment | | Local Segment | | 284 | | Controller | | Controller | | Controller | | 285 | +-----------------+ +-------------------+ +-------------------+ | 286 +--------------------------------------------------------------------+ 287 | | | Virtual BGP neighbor-| | 288 | | | ship IPv6 ULA links | | 289 +------+ | | | with Multipath TCP | | 290 |PoP +-v-----------+ | | +-----------------v-----+ | 291 +------+ Tier 2 N/W | | | ^ | | 292 +------+ +-------------+ Tier 1 N/W | | 293 |PoP +------+------+ | | | | | 294 +------+ | | | +------------+----------+ | 295 | | | | | 296 | | +---v----+ +-------v----------+ | 297 +----------> | ^ | | 298 | | IXP +-----+ Tier 2 ISP <---+ 299 | +--------+ +------------------+ 300 +-----v----------+ +-------v----------+ 301 +--+ Tier 3 ISP +-----> Tier 3 ISP +--+ 302 | +----------------+ +------------------+ | 303 +---------------v-----------------------------------------------v----+ 304 | Internet Users | 305 +--------------------------------------------------------------------+ 306 Figure 3: Internet architecture with Virtual address space 307 Thus by introducing virtual neighborship via virtual EBGP 308 neighborship between local and global controllers and virtual IBGP 309 neighborship within local and global controllers in the virtual 310 address space the Internet can still retain its Open system 311 characteristics. This circuvemtion of the closure property is by 312 k-nearest neighbor algorithm. The local and global controllers are 313 tightly coupled with the nearest neighbors as identified through the 314 routing data set and loosely coupled with farthest neighbors. In 315 this manner the Open system interconnection characteristic of the 316 Internet is retained. By incorporating a local and global controller 317 label in every IPv6 packet a routing data set can be computed at the 318 Controllers which can dynamically detect which controllers are 319 loosely coupled and which controllers are tightly coupled. The local 320 and global controllers pairing and virtual EBGP neighborship 321 segregates the virtual address space facilitating proper 322 administrative control by different service providers. 323 The virtual address space should only be utilized on a best effort 324 basis for transit stability and peer to peer stability. Critical path 325 analysis is mandatory. The virtual address space can facilitate a 326 highly parallelized redundant traffic control system. 327 Implementation of the virtual neighborship through EBGP would 328 require another address family. For convenience it can be called 329 as Virtual address family. As the Virtual address space facilitates 330 a highly parallelized traffic control system, Virtual neighborship 331 needs redundancy between each node. This capability can be 332 implemented through Multipath TCP, and BGP Multihop. 334 +---------------------------------------------+ 335 | Virtual address space | 336 | +-------------+ +--------------+ | 337 | | | | | | 338 | | Global | | Global | | 339 | | Controller | Loosely | Controller | | 340 | | | Coupled | | | 341 | | <------------> | | 342 | | Virtual | Coupling | Virtual | | 343 | | IBGP | depends on | IBGP | | 344 | | | K-NN | | | 345 | +-----^-------+ +-------^------+ | 346 | | Virtual EBGP | | 347 | | Neighborship | | 348 | | | | 349 | +-----v-------+ +-------v------+ | 350 | | | | | | 351 | | Virtual | | Virtual | | 352 | | IBGP | Tightly | IBGP | | 353 | | | Coupled | | | 354 | | <------------> | | 355 | | Local | | Local | | 356 | | Controller | | Controller | | 357 | | | | | | 358 | +-------------+ +--------------+ | 359 +---------------------------------------------+ 360 Figure 4: Virtual BGP Neighborship in the Virtual address space 361 6. IPv6 address assignment for the Virtual address space 363 The IPv6 ULA address blocks match the requirements of the Virtual 364 address space perfectly except that the address requirement is not 365 for sites but within AS and between Service provider networks. 366 fc00::/8 address block can be assigned for virtual EBGP sessions 367 between Controllers as the block was also intended for global 368 allocation. 369 fd00::/8 address block can be assigned for virtual IBGP sessions 370 within a Controller as the upper half (fd00::/8) is used for 371 "probabilistically unique" addresses in which the /8 prefix is 372 combined with a 40-bit locally generated pseudorandom number to 373 obtain a /48 private prefix. The way addresses in fd00::/8 are 374 chosen, means that there is only a negligible chance that two AS 375 that wish to merge or communicate with each other, will have 376 conflicting ULA addresses. 377 Additionally a local and global controller label must be present 378 in every IPv6 packet a routing data set can be computed at the 379 Controllers which can dynamically detect which controllers are 380 loosely coupled and which controllers are tightly coupled. 382 +--------------+--------------------+----------------------+ 383 | | | Segment Controller | 384 | Version | Traffic class | Label (Local and | 385 | | | Global) | 386 +--------------+---------+----------+--------+-------------+ 387 | | | | 388 | Payload length | Next header | Hop limit | 389 | | | | 390 +------------------------+-------------------+-------------+ 391 | | 392 | Source Address | 393 | | 394 | | 395 +----------------------------------------------------------+ 396 | | 397 | | 398 | Destination Address | 399 | | 400 +----------------------------------------------------------+ 401 Figure 5: 402 IPv6 with Local and Global Controller label replacing the Flow 403 label 404 7. Glossary of terms and definitions: 406 Node: A redistribution point having one or more Network interface 407 cards with addresses. 409 Host: A Computer is a node connected to a Computer network and 410 assigned a network address. 412 Abstract Machine: An abstract model of Computation used for 413 analyzing the complexity of algorithms. 415 MIMO Routing: Routing a cluster by cluster in each hop, where the 416 number of nodes is larger or equal to one. 418 Path Connected space: A path connected space is a stronger notion 419 of connectedness. Every path connected space is connected. In a 420 finite connected space a connected space is the same as path 421 connected space. 423 Transitive reduction: a transitive reduction of a directed graph D 424 is another directed graph with the same vertices and as few edges 425 as possible, such that if there is a (directed) path from vertex v 426 to vertex w in D, then there is also such a path in the reduction. 428 The Von Neumann bottleneck(as described by John Backus): 429 Surely there must be a less primitive way of making big changes in 430 the store than by pushing vast numbers of words back and forth 431 through the Von Neumann bottleneck. Not only is this tube a 432 literal bottleneck for the data traffic of a problem, but, more 433 importantly, it is an intellectual bottleneck that has kept us tied 434 to word-at-a-time thinking instead of encouraging us to think in 435 terms of the larger conceptual units of the task at hand. Thus, 436 programming is basically planning and detailing the enormous traffic 437 of word through the Von Neumann bottleneck, and much of that traffic 438 concerns not significant data itself, but where to find it. 440 8. Security Considerations 441 A more robust security model can be built around the Virtual 442 address space. 444 9. IANA Considerations 445 This document describes the need for IP address space 446 reclassification 448 10. Conclusions 449 The IPv6 address space reclassification into a Physical address 450 space and a Virtual address space is proposed. The mapping between 451 these two occurs at the BGP AS Boundary. Together these two address 452 spaces provide the ability to build an ideal Topological space for 453 the Internet which facilitates a highly parallelized redundant 454 traffic control system. 456 11. References 457 11.1. Normative References 458 [RFC793] "Transmission Control Protocol", RFC 793, 459 September 1981. 460 [RFC4271] Y. Rekhter, S. Hares and T. Li, "A Border Gateway 461 Protocol 4 (BGP-4)", RFC 4271, January 2006. 462 [RFC4274] D. Meyer and K. Patel, "BGP-4 Protocol 463 Analysis", RFC 4274, January 2006. 464 [RFC7868] G. Savage, J. Ng, S. Moore, D. Slice, 465 P. Paluch, R. White, "Cisco's Enhanced Interior Gateway Routing 466 Protocol (EIGRP)", RFC 7868, January 2006. 467 [RFC3513] R. Hinden, S. Deering, 468 "Internet Protocol Version 6 (IPv6) Addressing Architecture", 469 RFC 3513, April 2003. 470 [RFC6182] A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar, 471 "Architectural Guidelines for Multipath TCP Development", RFC 6182, 472 March 2011. 473 [RFC4864] G. Van De Velde, T. Hain, R. Droms, B. Carpenter, 474 E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. 475 [RFC6437] s. Amante, B. Carpenter,S. Jiang,J. Rajahalme "IPv6 476 Flow Label Specification", RFC 6437, Nov 2011. 477 [RFC3549] J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov "Linux 478 Netlink as an IP Services Protocol", RFC 3549, Jul 2003. 480 11.2. Informative References 481 Daniel Fischer, David Basin and Thomas Engel 482 Topology Dynamics and Routing for Predictable Mobile 483 SETL for Internet Data processing by David Bacon 484 https://cs.nyu.edu/bacon/phd-thesis/diss.pdf 486 12. Acknowledgments 487 This document was prepared using 2-Word-v2.0.template.dot. 489 Copyright (c) 2018 IETF Trust and the persons identified as 490 authors of the code. All rights reserved Redistribution and 491 use in source and binary forms, with or without modification, 492 is permitted pursuant to, and subject to the license terms 493 contained in, the Simplified BSD License set forth in Section 494 4.c of the IETF Trust's Legal Provisions Relating to IETF 495 Documents (http://trustee.ietf.org/license-info). 497 Author's Address 498 Vineet Deshpande 499 Flat no. B-303, Peninsula Pinnacles, 500 Adigara Kalahalli, Sarjapur-Attibel, 501 Bangalore 562125 502 India 504 Phone: 91 7259600661 505 Email: vineetdeshpande@yahoo.com