[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Intarea Working Group                                    V. Deshpande
Internet-Draft
Intended status: Experimental
Expires: April, 2019                                     Oct 10, 2018

                    IP address space reclassification
       draft-deshpande-intarea-ipaddress-reclassification-04.txt

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or
   IETF Contributions published or made publicly available
   before November 10, 2008. The person(s) controlling the
   copyright in some of this material may not have granted
   the IETF Trust the right to allow modifications of such
   material outside the IETF Standards Process.  Without
   obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be
   modified outside the IETF Standards Process, and derivative
   works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or
   to translate it into languages other than English.

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be

Deshpande            Expires April 10, 2019                  [Page 1]


Internet-Draft       IP address reclassification           April 2019


   accessed at http://www.ietf.org/shadow.html

   This Internet-Draft will expire on March, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this
   document. Please review these documents carefully, as they
   describe your rights and restrictions with respect to this
   document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section
   4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

   Abstract

   This draft proposes IP address reclassification. By understanding
   how the Network is evolving from wireless technologies and comparing
   with an abstract mathematical topological space model, changes such
   as addition of a Virtual address space and Virtual BGP neighborship
   are proposed.
   The limitations of current Internet Architecture are identified and
   the corrections needed for the traffic bottleneck present in the
   current Internet Architecture are described further.
   The interdependence of IPv6 ULA addressing scheme, multipath and
   multipath TCP with the virtual neighborship and the virtual address
   space are explored.

   Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. The Mathematical premise for the electromagnetic equivalent . . 3
   3. Design considerations for the Internet architecture  . . .  . . 3
   4. Complexities in analyzing the Internet as a topological space . 4
   4.1 Complexity of Computation . . . . . . . . . . . . . . . . . .  4
   4.2 Complexity of Algorithms . . . . . . . . . . . . . . . . . . . 4
   4.3 Complexity of Connectedness . . . . . . . . . . . . . . . . .  4
   4.4 The Problem of Observability . . . . . . . . . . . . .  . . .  5
   5. Internet architecture based on the design considerations . . .  5
   6. IPv6 address assignment for the Virtual address space . . . . . 9
   7. Glossary of terms and definitions . . . . . . . . . . . . . .  10
   8. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . .  11
   11.1. Normative References . . . . . . . . . . . . . . . . . . .  11
   11.2. Informative References . . . . . . . . . . . . . . . . . .  12
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12

Deshpande            Expires April 10, 2019                  [Page 2]


Internet-Draft       IP address reclassification           April 2019

   1. Introduction

   This draft proposes IPv6 address re-classification. An attempt is
   made to identify the significant traffic bottlenecks in the
   Internet. IPv6 address space is re-classified by adding a new virtual
   address space which facilitated a highly parallelized traffic control
   system to resolve the traffic bottleneck problems.
   By assuming a mathematical premise of a finite topological space
   with interior, exterior and closure an attempt is made to
   retain the open system interconnection characteristic of the
   Internet in the virtual address space through virtual BGP
   neighborship. Multipath and Multipath TCP connections are also
   recognized as being suitable for implementing the virtual BGP
   neighborship. The IPv6 ULA addressing scheme is recognized as being
   well suited for address assignment in the virtual address space.
   A more detailed architecture is beyond scope as of now however an
   attempt is made to spell out the design guidelines. A glossary at
   the end contains the meaning of terms and definitions used in this
   draft.

   2. The Mathematical premise for the electromagnetic equivalent

   The electromagnetic phenomenon observed in a waveguide is that the
   wave propagation can be restricted to one dimension through total
   internal reflection. At the critical angle the wave is split into
   two or more waves. This is the principle behind multipath
   propagation and also the basis for MIMO technology. Mathematically
   this is similar to the path connectedness in a finite topological
   space. The MIMO routing principles are thus applicable to wired
   networks. MIMO is equivalent to Multipath. Therefore as MIMO routing
   is cluster by cluster, multipath routing in wired networks is also
   restricted to occur through clusters rather than between nodes.

   3. Design considerations for the Internet architecture

   Rather than viewing Computer communication as Host to Host as in
   the traditional OSI and TCP models the computational and algorithmic
   complexity of a network can be better understood by taking a step
   back and viewing the communication as Machine to Machine.

   On applying the principles of the Von Neumann bottleneck the
   significant traffic can be identified as transit traffic between
   ISPs and peer to peer traffic between ISPs. In other words the
   Inter-AS traffic and the CsC traffic.

Deshpande            Expires April 10, 2019                  [Page 3]


Internet-Draft       IP address reclassification           April 2019

   4. Complexities in analyzing the Internet as a topological space

   4.1 Complexity of Computation
   4.1.1 A local computation may not yield a global routing table which
   can resolve global routing problems.
   4.1.2 OSPF computation is evenly spread through the area or the core
   AS.

   4.2 Complexity of Algorithms
   4.2.1 OSPF is based on Heap sort which is a maximally efficient
   priority queue based on the heap data structure
   4.2.2 OSPF redistribution repeats the advertisement of routes. A
   classful boundary exists between areas as OSPF reoriginates
   summary routes at an ABR
   4.2.3 The above constraints bring about restrictions on
   redistribution,re-routing, multipath routing due to the classful
   queuing and addressing limits.
   4.2.4 BGP selects and inserts certain routes (path selection
   attributes) and merges routes. Therefore BGP can be considered as
   having characteristics of selection, insertion sorts as well as
   merge sort.

   4.3 Complexity of Connectedness
   4.3.1 Path connectedness in a finite space acts as a limitation
   for multipath routing. Thus multipath routing in wired networks
   need to evolve from MIMO routing.
   4.3.2 A Tree is a (Un)Directed Acyclic Graph (DAG).
   4.3.3 A Polytree (sort of a tree on top of a tree) is a DAG whose
   underlying undirected graph is a tree (Refer Figure 3).
   4.3.4 In order to design the Internet architecture the acyclic
   aspects of a Tree structure must be considered.
   4.3.5 DAG traversal can be performed in-order, pre-order,
   post-order and in-level.
   4.3.6 The IBGP full mesh is similar to a strongly connected
   component in a DAG.
   4.3.7 Critical path analysis is needed to enhance the Internet
   architecture.
   4.3.8 Features such as Transitive reduction and Critical path
   Analysis should resolve the Internet routing, congestion and
   convergence challenges.

Deshpande            Expires April 10, 2019                  [Page 4]


Internet-Draft       IP address reclassification           April 2019

   4.4 The Problem of Observability
   The above complexities of Computation, algorithms and connectedness
   are bounded by an AS. Thus all must be concurrently observed at
   multiple provider edge points on an AS to serve any purpose from a
   control plane perspective.
   Observability can be more clearly understood through the concept
   of a virtual state that is assumed to be occurring in Virtual BGP.
   This is similar to the BGP modes Read-only, Calculating best path,
   and Read and Write.
   +--------------+       +--------------+
   |              |       |              |
   |  Readable    |       | Observable   |
   |              +------->              |
   |              |       |              |
   +------^-------+       +------+-------+
          |                      |
          |                      |
   +------+-------+       +------v-------+
   |              |       |              |
   |  Writable    |       | Functionable |
   |              <-------+              |
   |              |       |              |
   +--------------+       +--------------+
   Figure 1: Observability

   5. Internet architecture based on the design considerations

   The significant traffic is controlled by BGP and Route
   reflectors. The flow of this significant traffic traverses a
   hierarchical tree structure through various tiers of the service
   provider network. Therefore it can be inferred that the traffic is
   flowing in top-down(north-south manner). In order to introduce
   parallelism (east-west traffic) for this significant traffic,
   Multipath TCP, dynamic path recalculation and re-routing by virtual
   redistribution(transit reduction) through RR clusters are feasible
   techniques. These techniques can be implemented within an AS. But
   due to the problem of Observability the analytical data needed for
   these techniques is present at the provider edges of the AS. Due to
   this point presence at various edges of an AS and the classful queue
   and algorithmic boundaries as described previously, a control plane
   in a separate address space is needed. The complex plane
   characteristics of the topological space indicates that the new
   address space needs to be a virtual address space.

Deshpande            Expires April 10, 2019                  [Page 5]


Internet-Draft       IP address reclassification           April 2019

   The virtual address space can facilitate pre-ordering of flows,
   pre-establishment of connections and pre-originating of routes. The
   virtual address space can also pre-classify QoS for the significant
   traffic.
   There is an implicit redundancy between distributed firewalls.
   This suggests that virtual redistribution is feasible. Virtual
   redistribution is a pre-origination and re-origination of a route as
   usually happens on an Area Border Router in OSPF. However in the
   IBGP Core the pre-origination and re-origination must occur at a
   Route Reflector through clusters. However the reorigination is for
   a route or a set of routes already present in the routing table to
   follow an alternate feasible path.

   +--------------+-----------------+--------------+
   |              |                 |              |
   |              |                 |              |
   |   Process    |   Application   |   Process    |
   |              |                 |              |
   |              |                 |              |
   +-----------------------------------------------+
   |              |                 |              |
   |              |                 |              |
   |   Host       |   Transport     |    Host      |
   |              |                 |              |
   |              |                 |              |
   +-----------------------------------------------+
   |              |                 |              |
   |              |                 |              |
   |   Node and   |   Internet      |   Node and   |
   |   Cluster    |                 |   Cluster    |
   |              |                 |              |
   +-----------------------------------------------+
   |              |                 |              |
   |              |                 |              |
   |   Media      |    Link         |   Media      |
   |              |                 |              |
   |              |                 |              |
   +--------------+-----------------+--------------+
   Figure 2:
   TCP/IP Model with different communication functions at each layer

Deshpande            Expires April 10, 2019                  [Page 6]


Internet-Draft       IP address reclassification           April 2019

   However a major challenge exists at the boundary of the AS due to
   closure property.  There exists a boundary value problem or in other
   words the boundary between EBGP and IBGP needs to be analyzed as a
   closed set. Therefore a unique mapping is needed at each point that
   connects to the Virtual address space at the AS boundary. As the
   critical network information is at the boundary of the AS the
   virtual address space needs to connect to each AS boundary on at
   the most 2 to 3 points for each AS. The Data folds onto itself at
   the AS boundary.
+--------------------------------------------------------------------+
|     +--------------------------------------------------------+     |
|     |      Global Segment Controller (AS or Domain)          |     |
|     +--------------------------------------------------------+     |
|                                                                    |
|                     Virtual Address Space                          |
|     +-------------------------+  +---------------------------+     |
|     |Global Segment Controller|  |Global Segment Controller  |     |
|     +-------------------------+  +---------------------------+     |
| +-----------------+  +-------------------+   +-------------------+ |
| | Local Segment   |  |  Local Segment    |   | Local Segment     | |
| |  Controller     |  |   Controller      |   |  Controller       | |
| +-----------------+  +-------------------+   +-------------------+ |
+--------------------------------------------------------------------+
           |             |     |  Virtual BGP neighbor-|         |
           |             |     |  ship IPv6 ULA links  |         |
  +------+ |             |     |  with Multipath TCP   |         |
  |PoP   +-v-----------+ |     |     +-----------------v-----+   |
  +------+ Tier 2 N/W  | |     |     ^                       |   |
  +------+             +-------------+    Tier 1 N/W         |   |
  |PoP   +------+------+ |     |     |                       |   |
  +------+      |        |     |     +------------+----------+   |
                |        |     |                  |              |
                |        | +---v----+     +-------v----------+   |
                +---------->        |     ^                  |   |
                         | | IXP    +-----+   Tier 2 ISP     <---+
                         | +--------+     +------------------+
                   +-----v----------+     +-------v----------+
                +--+  Tier 3 ISP    +----->  Tier 3 ISP      +--+
                |  +----------------+     +------------------+  |
+---------------v-----------------------------------------------v----+
|                          Internet Users                            |
+--------------------------------------------------------------------+
   Figure 3: Internet architecture with Virtual address space

Deshpande            Expires April 10, 2019                  [Page 7]


Internet-Draft       IP address reclassification           April 2019

   Thus by introducing virtual neighborship via virtual EBGP
   neighborship between local and global controllers and virtual IBGP
   neighborship within local and global controllers in the virtual
   address space the Internet can still retain its Open system
   characteristics. This circuvemtion of the closure property is by
   k-nearest neighbor algorithm. The local and global controllers are
   tightly coupled with the nearest neighbors as identified through the
   routing data set and loosely coupled with farthest neighbors. In
   this manner the Open system interconnection characteristic of the
   Internet is retained. By incorporating a local and global controller
   label in every IPv6 packet a routing data set can be computed at the
   Controllers which can dynamically detect which controllers are
   loosely coupled and which controllers are tightly coupled. The local
   and global controllers pairing and virtual EBGP neighborship
   segregates the virtual address space facilitating proper
   administrative control by different service providers.
   The virtual address space should only be utilized on a best effort
   basis for transit stability and peer to peer stability. Critical path
   analysis is mandatory. The virtual address space can facilitate a
   highly parallelized redundant traffic control system.
   Implementation of the virtual neighborship through EBGP would
   require another address family. For convenience it can be called
   as Virtual address family. As the Virtual address space facilitates
   a highly parallelized traffic control system, Virtual neighborship
   needs redundancy between each node. This capability can be
   implemented through Multipath TCP, and BGP Multihop.

   +---------------------------------------------+
   |          Virtual address space              |
   | +-------------+            +--------------+ |
   | |             |            |              | |
   | |  Global     |            | Global       | |
   | |  Controller | Loosely    | Controller   | |
   | |             | Coupled    |              | |
   | |             <------------>              | |
   | |    Virtual  |  Coupling  | Virtual      | |
   | |    IBGP     | depends on | IBGP         | |
   | |             |   K-NN     |              | |
   | +-----^-------+            +-------^------+ |
   |       |        Virtual EBGP        |        |
   |       |        Neighborship        |        |
   |       |                            |        |
   | +-----v-------+            +-------v------+ |
   | |             |            |              | |
   | |     Virtual |            | Virtual      | |
   | |     IBGP    | Tightly    | IBGP         | |
   | |             | Coupled    |              | |
   | |             <------------>              | |
   | | Local       |            |  Local       | |
   | | Controller  |            |  Controller  | |
   | |             |            |              | |
   | +-------------+            +--------------+ |
   +---------------------------------------------+
   Figure 4: Virtual BGP Neighborship in the Virtual address space

Deshpande            Expires April 10, 2019                  [Page 8]


Internet-Draft       IP address reclassification           April 2019

   6. IPv6 address assignment for the Virtual address space

   The IPv6 ULA address blocks match the requirements of the Virtual
   address space perfectly except that the address requirement is not
   for sites but within AS and between Service provider networks.
   fc00::/8 address block can be assigned for virtual EBGP sessions
   between Controllers as the block was also intended for global
   allocation.
   fd00::/8 address block can be assigned for virtual IBGP sessions
   within a Controller as the upper half (fd00::/8) is used for
   "probabilistically unique" addresses in which the /8 prefix is
   combined with a 40-bit locally generated pseudorandom number to
   obtain a /48 private prefix. The way addresses in fd00::/8 are
   chosen, means that there is only a negligible chance that two AS
   that wish to merge or communicate with each other, will have
   conflicting ULA addresses.
   Additionally a local and global controller label must be present
   in every IPv6 packet a routing data set can be computed at the
   Controllers which can dynamically detect which controllers are
   loosely coupled and which controllers are tightly coupled.

   +--------------+--------------------+----------------------+
   |              |                    |  Segment Controller  |
   | Version      |  Traffic class     |  Label (Local and    |
   |              |                    |  Global)             |
   +--------------+---------+----------+--------+-------------+
   |                        |                   |             |
   |  Payload length        |  Next header      |  Hop limit  |
   |                        |                   |             |
   +------------------------+-------------------+-------------+
   |                                                          |
   |                      Source Address                      |
   |                                                          |
   |                                                          |
   +----------------------------------------------------------+
   |                                                          |
   |                                                          |
   |                    Destination Address                   |
   |                                                          |
   +----------------------------------------------------------+
   Figure 5:
   IPv6 with Local and Global Controller label replacing the Flow
   label

Deshpande            Expires April 10, 2019                  [Page 9]


Internet-Draft       IP address reclassification           April 2019

   7. Glossary of terms and definitions:

   Node: A redistribution point having one or more Network interface
   cards with addresses.

   Host: A Computer is a node connected to a Computer network and
   assigned a network address.

   Abstract Machine: An abstract model of Computation used for
   analyzing the complexity of algorithms.

   MIMO Routing: Routing a cluster by cluster in each hop, where the
   number of nodes is larger or equal to one.

   Path Connected space: A path connected space is a stronger notion
   of connectedness. Every path connected space is connected. In a
   finite connected space a connected space is the same as path
   connected space.

   Transitive reduction: a transitive reduction of a directed graph D
   is another directed graph with the same vertices and as few edges
   as possible, such that if there is a (directed) path from vertex v
   to vertex w in D, then there is also such a path in the reduction.

   The Von Neumann bottleneck(as described by John Backus):
   Surely there must be a less primitive way of making big changes in
   the store than by pushing vast numbers of words back and forth
   through the Von Neumann bottleneck. Not only is this tube a
   literal bottleneck for the data traffic of a problem, but, more
   importantly, it is an intellectual bottleneck that has kept us tied
   to word-at-a-time thinking instead of encouraging us to think in
   terms of the larger conceptual units of the task at hand. Thus,
   programming is basically planning and detailing the enormous traffic
   of word through the Von Neumann bottleneck, and much of that traffic
   concerns not significant data itself, but where to find it.

Deshpande            Expires April 10, 2019                  [Page 10]


Internet-Draft       IP address reclassification            April 2019

   8. Security Considerations
   A more robust security model can be built around the Virtual
   address space.

   9. IANA Considerations
   This document describes the need for IP address space
   reclassification

   10. Conclusions
   The IPv6 address space reclassification into a Physical address
   space and a Virtual address space is proposed. The mapping between
   these two occurs at the BGP AS Boundary. Together these two address
   spaces provide the ability to build an ideal Topological space for
   the Internet which facilitates a highly parallelized redundant
   traffic control system.

   11. References
   11.1. Normative References
   [RFC793]      "Transmission Control Protocol", RFC 793,
   September 1981.
   [RFC4271] Y. Rekhter, S. Hares and T. Li, "A Border Gateway
   Protocol 4 (BGP-4)", RFC 4271, January 2006.
   [RFC4274]     D. Meyer and K. Patel, "BGP-4 Protocol
   Analysis", RFC 4274, January 2006.
   [RFC7868]     G. Savage, J. Ng, S. Moore, D. Slice,
   P. Paluch, R. White, "Cisco's Enhanced Interior Gateway Routing
   Protocol (EIGRP)", RFC 7868, January 2006.
   [RFC3513]     R. Hinden, S. Deering,
   "Internet Protocol Version 6 (IPv6) Addressing Architecture",
   RFC 3513, April 2003.
   [RFC6182]     A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar,
   "Architectural Guidelines for Multipath TCP Development", RFC 6182,
   March 2011.
   [RFC4864]     G. Van De Velde, T. Hain, R. Droms, B. Carpenter,
   E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
   [RFC6437]     s. Amante, B. Carpenter,S. Jiang,J. Rajahalme "IPv6
   Flow Label Specification", RFC 6437, Nov 2011.
   [RFC3549]     J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov "Linux
   Netlink as an IP Services Protocol", RFC 3549, Jul 2003.

Deshpande            Expires April 10, 2019                  [Page 11]


Internet-Draft       IP address reclassification            April 2019

   11.2. Informative References
   Daniel Fischer, David Basin and Thomas Engel
   Topology Dynamics and Routing for Predictable Mobile
   SETL for Internet Data processing by David Bacon
   https://cs.nyu.edu/bacon/phd-thesis/diss.pdf

   12. Acknowledgments
   This document was prepared using 2-Word-v2.0.template.dot.

   Copyright (c) 2018 IETF Trust and the persons identified as
   authors of the code. All rights reserved Redistribution and
   use in source and binary forms, with or without modification,
   is permitted pursuant to, and subject to the license terms
   contained in, the Simplified BSD License set forth in Section
   4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info).

   Author's Address
   Vineet Deshpande
   Flat no. B-303, Peninsula Pinnacles,
   Adigara Kalahalli, Sarjapur-Attibel,
   Bangalore 562125
   India

   Phone: 91 7259600661
   Email: vineetdeshpande@yahoo.com

Deshpande            Expires April 10, 2019                  [Page 12]

Internet-Draft       IP address reclassification            April 2019

Html markup produced by rfcmarkup 1.128, available from https://tools.ietf.org/tools/rfcmarkup/