<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="exp" docName="draft-dykim-nara-01" ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="NARA">Network Architecture with Recursive
    Addressing</title>

    <author fullname="Dae Young KIM" surname="DY Kim">
      <organization>Chungnam University</organization>

      <address>
        <postal>
          <street>InfoCom Eng.</street>

          <city>Daejeon</city>

          <code>305-764</code>

          <country>South KOREA</country>
        </postal>

        <phone>+82 42 821 6862</phone>

        <email>dykim@cnu.kr</email>
      </address>
    </author>

    <date/>

    <abstract>
      <t>A network architecture based on recursive addressing is proposed. The
      Internet is modeled as a network of autonomous domains, each being a
      collection of nodes. Each domain is named by a global address whereas
      each node by a local address. Inter-domain routing depends solely on
      domain addresses while intra-domain routing on node addresses. Routing
      based on node or domain addresses render inherent mobility as well as
      seamless multi-homing capability. The model can recursively repeat
      itself both outwards and inwards in the network, enabling its
      applicability, for example, to inter-planetary as well as body area
      networks.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Scalability of the Internet has long been recognized as one of its
      major problems. Explosion of DFZ(Default Free Zone) routing tables, one
      aspect of the problem, has resulted from the Internet's inability of
      efficient multi-homing, for which semantic overloading of the IP address
      has been blamed. This semantic overloading, that IP addresses are used
      as both the identifiers(IDs) and the Locators(Locs) for nodes, has also
      been perceived as against the naming and addressing principles<xref
      target="IEN0001"/><xref target="IEN0019"/><xref target="RFC1498"/> and
      so as the main obstacle hindering the Internet from providing fast
      mobility and seamless multihoming. <vspace blankLines="1"/>A
      considerable number of protocols based on the Loc/ID Separation(LIS)
      architecture have been proposed. Some of them are host-based solutions
      <xref target="RFC4423"/><xref target="GSE"/><xref target="ILNP"/><xref
      target="IEEE-MCOM"/>while others are router-based<xref
      target="LISP"/><xref target="IRON"/><xref target="Ivip"/>. Most such
      proposals share one thing; IDs and Locs are global. <vspace
      blankLines="1"/>This document proposes an architecture, named NARA,
      based on local addressing in its strict sense. Local addresses, for
      nodes, are never exploited in DFZ routing. A collection of nodes under
      an autonomous administration is called a domain, and only domain
      addresses identifying them are used for inter-domain routing. That way,
      the global network is split into two rather orthogonal tiers. <vspace
      blankLines="1"/>NARA is very close to the ideas proposed in ENCAPS and
      hIPv4<xref target="RFC1955"/><xref target="RFC6306"/>. The latter two,
      however, name node interfaces (or point of attachment: PoA) with either
      global IP addresses (in ENCAPS) or local Endpoint Locators (in hIPv4),
      whereas node themselves are named by local addresses in NARA. <vspace
      blankLines="1"/>Node addresses in NARA are semantically overloaded. They
      are used for end-to-end connections as well as for routing. This is a
      stark contrast to prevalent arguments of LIS. Semantic overloading is
      not seen as an evil in NARA, but is rather positively exploited to
      provide fast mobility and seamless multihoming. <vspace
      blankLines="1"/>Although this document describes NARA in two-tier
      networks, the same addressing and routing principles can be recursively
      repeated inwards and outwards off a given network tier. In this sense,
      NARA can be considered as one of recursive network architectures.
      <vspace blankLines="1"/>Following sections provide a generic description
      of the NARA architecture and associated routings. Implemetation choices
      for a better chance of deployability are then discussed. Consequences of
      the proposal are discussed before concluding the document.</t>
    </section>

    <section title="ARCHITECTURE">
      <t>The Internet is modeled as a networked collection of autonomous
      domains. A domain is a collection of nodes, also called either
      hosts(leaf nodes) or routers(relay nodes). A subset of hosts and an
      associated router forms a subnet. Therefore, a domain can also be
      considered as a networked collection of subnets. A domain itself can be
      a leaf or a transit.<vspace blankLines="1"/> <figure align="center"
          height="30" title="Figure 1: Architectiral Overview of NARA"
          width="40">
          <artwork>
  +-----+     +-----------+            +------------+
  | APP |-----|NameS-Local|---......---|NameS-Global|
  +-----+     +-----------+            +------------+
     |
 +---|---+
 | TP/IP |
 +---|---+
     |                                 +--------+
+----|---------------------------+     |Domain_A|
|    |         Domain            |     +--------+
| +------+             +-------+ |        |  
| | node |-------------|iDomain| |        |
| +------+       |     +-------+ |        |  
|             +------+         +---+   +--------+
|             | node |         | G |---|Domain_B|
|             +------+         +---+   +--------+
+--------------------------------+</artwork>
        </figure> The Internet at one instance of the hierarchy is therefore
      governed by the two-tier administration, i.e., the global authority and
      the local domain authorities. <vspace blankLines="1"/>A domain is named
      by a global address while a node by an address local to a given domain.
      Now that each subnet is associated with a router, it can be identified
      by the router address. Therefore, the subnet address and the router
      address will be used interchangeably in this document.<vspace
      blankLines="1"/>A domain is marked by a gateway router, G in Fig. 1. One
      of the important functions of the gateway is to swap addresses of
      packets at their passing in either direction. That is, when a packet
      leaves a domain, its address is swapped to a global address. When
      entering a domain, its address is swapped back to a local address. In
      fact, a gateway is a NAT(Network Address/Port Translator) router.<vspace
      blankLines="1"/>Inter-domain routing is done solely on domain addresses
      while intra-domain routing on node addresses. Node addresses are never
      exposed to inter-domain routing. That is, inter- and intra-domain
      routings are orthogonal to each other.<vspace blankLines="1"/>In
      addition to routing, node addresses are also associated with transport
      connections. In this sense, it can be said that node addresses are
      semantically overloaded. In NARA, semantic overloading of addresses is
      not considered harmful; it is rather natural and even desirable. <vspace
      blankLines="1"/>For a transport connection between a local node and a
      global node, the far end of the connection as seen by a local node would
      be identified by {global node address, port} as usual. However, that as
      seen by the global node would be identified by {global domain address,
      port} because of the NAT funtion of the gateway.<vspace
      blankLines="1"/>Normally, neither node- nor domain-addresses bear
      topological significance; they each consume separate flat number spaces.
      Node addresses don't change while nodes are moving around within a
      domain. Domain addresses don't change at migration across upstream
      network providers as well as at multi-homing. In a rare case of
      implementation instance, domain addresses might bear topological
      significance as with the current Internet. In this case, only the domain
      address would change at migration to a different network provider. At
      multi-homing, a domain can be given multiple domain addresses from
      different network providers.<vspace blankLines="1"/>The FQDN(Fully
      Qualified Domain Name) of a node would be resloved first to a domain
      address by a global name server. A local name server then resolves the
      rest to a local node address.<vspace blankLines="1"/>A node in a given
      domain can itself be a domain. That is, the node can be marked by a
      gateway and contain children nodes inside. This way, the generic
      two-tier architecture can recur as needed.</t>
    </section>

    <section title="INTRA-DOMAIN ROUTING">
      <t>Packets in the domain tier, interior to domains, are routed solely on
      node addresses. Domain addresses don't come into play in intra-domain
      routing. Any protocols including OSPF and ISIS can be applied to this
      intra-domain routing.<vspace blankLines="1"/>Node addresses are directly
      used in routing and forwarding decisions. Each router maintains an
      address table of {node, (associated) router, next-hop router} tuples.
      Tables are updated through routing information exchange between routers.
      <vspace blankLines="1"/>Hosts may not involve themselves directly with
      such routing tables. It is up to routers to route packets exiting nodes.
      <vspace blankLines="1"/>When a node moves from one subnet to another,
      such a membership change is broadcast as a link-state update to all
      other routers in the domain by the previous and/or newly visited subnet
      router(s). Host mobility is provided directly by routers in this way and
      hence is fast. <vspace blankLines="1"/>Moving of a subnet is the same as
      moving of the associated router, and such a move will be perceived as a
      topological change of the network and so will be reflected in the
      routing tables at link-state updates. Henceforth, (subnet) network
      mobility is provided also as an inherent feature of the routing.<vspace
      blankLines="1"/>A sever mapping node addresses to associated router
      addresses could be deployed in the domain to shrink the router table
      size. In this scenario, moving of a node is not broadcast to all routers
      but is notified only to the mapping server. The mapping server maintains
      an address table of {node, router} tuples whereas only {node, next-hop
      router} are cached in each router. When the target node address of an
      incoming packet is missing in its forwarding table, the router consults
      the mapping server to acquire the {node, router} tuple. Then by further
      consulting its own routing table, the router would generate a cache
      entry of {node, next-hop router} in the forwarding table. Expiraton
      timers for forwarding cache would be an engineering issue.</t>

      <figure align="center" height="30"
              title="Figure 2: Intra-domain Routing of NARA" width="30">
        <artwork>
+------------------------------------------------------------+
|      mapper        +--------------+      +--------------+  |
|    +-------+       | +---+  +---+ |      | +---+  +---+ |  |
|    | 1, 91 |       | | 6 |  | 4 | |      | | 3 |  | 2 | |  |
|    | 2, 97 |       | +---+  +---+ |      | +---+  +---+ |  |
|    | 3, 97 |       |    +----+    |      |    +----+    |  |
|    | 4, 94 |       +----| 94 |----+      +----| 97 |----+  |
|    | 5, 91 |            +----+----------------+----+       |
|    | 6, 94 |               |  |________________  |         |
|    +-------+               |                  |  |         |
|                         +----+----------------+----+       |
|  {node,subnet}     +----| 91 |----+           | 96 |       |
| ={node,router}     |    +----+    |           +----+       | 
|                    | +---+  +---+ |              |         |
|                    | | 1 |  | 5 | |              |         |
|                    | +---+  +---+ |              |         |
|                    +--------------+           +-----+      |
+-----------------------------------------------| 101 |------+
                                                +-----+</artwork>
      </figure>
    </section>

    <section title="INTER-DOMAIN ROUTING">
      <t>Packets in the global tier, exterior to domains, are routed solely on
      domain addresses. Node addresses are not advertised into the global
      tier. Any protocols, BGP, OSPF or ISIS, can be applied to this
      inter-domain routing. <vspace blankLines="1"/>Each transit-domains can
      be considered to correspond, in a generic network graph, to relay
      nodes(routers) whereas leaf domains to leaf nodes(hosts). That is,
      symmetry of network architecture repeats itself at each tier. Therefore,
      the same routing features of intra-domain routing can be applied to
      inter-domain routing with tranist-domains and leaf domains in place of
      routers and hosts, respectively.<figure align="center" height="30"
          title="Figure 3: Inter-domain Routing of NARA" width="30">
          <artwork>
+----------------------------------------------------------+
|  +----+    +----+                   +----+               |
|  | 11 |    | 37 |                   | 15 |               |
|  +----+    +----+                   +----+               |
|     |___    |                         |                  |
|         |___|                         |                  |
|  +----+    +-----+                  +-----+    +----+    |
|  | 25 |----|  1  |------------------|  3  |----| 41 |    |
|  +----+    +-----+                  +-----+    +----+    |
|              |  |___________           |                 |
|              |             |           |                 |
|              |             |___________|                 |
|  +----+    +-----+                  +-----+              |
|  | 22 |----|  2  |------------------|  4  |              |
|  +----+    +-----+                  +-----+              |
|              +----+                                      |
|              |11,1|                                      |
|              |15,3|                                      |
|              |22,2|                                      |
|              |25,1|                                      |
|              |37,1|                                      |
|              |41,3|                                      |
|              +----+                                      |
+----------------------------------------------------------</artwork>
        </figure></t>
    </section>

    <section title="IMPLEMENTATION CHOICES">
      <t>Although the proposed network architecture of NARA is described in a
      generic way, it can be tailored for smooth and incremental deployment in
      the existing Internet.</t>

      <section title="Node Address">
        <t>In principle, both IPv4 and IPv6 private addresses can be used for
        local node addresses. However, since the range of IPv4 private
        addresses might be enough for most domains, use of IPv4 addresses
        might be more appealing. <vspace blankLines="1"/>Use of IPv4 addresses
        ensures minimal changes to existing vast population of IPv4 hosts.
        Transition to IPv6 addresses will not be a requisite anymore, but a
        luxurious option at most. <vspace blankLines="1"/>It is to be noted
        that IP addresses adopted as such do not name interfaces anymore but
        name nodes themselves. That is, although IP addresses will continue to
        be used, interpretation of their context will be changed.</t>
      </section>

      <section title="Domain Address">
        <t>The routing prefix of a whole domain, i.e., the aggragate address
        of the whole PA(provider-aggregatable) addresses already assigned to
        the domain, can be used as the domain address. However, since the
        provider does not have to assign a huge range of addresses to a domain
        anymore, only a single full-32-bit PA address can also be given to a
        domain, thus saving a lot of the public address resource.</t>
      </section>

      <section title="Gateway">
        <t>An important funtion of the gateway is to swap addresses of packets
        passing throught it. That is, a gateway is a NAT router. A node
        address will be replaced with a domain address at packet exit, and
        vice versa at packet entry.</t>
      </section>

      <section title="Name Servers">
        <t>DNS working in a strictly hiearchical manner would serve the
        purpose of the name servers of NARA. The FQDN(Fully Qualified Domain
        Name) of a node would be resloved first to a domain address by a
        global name server. A local name server then resolves the rest to a
        local node address.</t>
      </section>

      <section title="Routing Protocols">
        <t>OSPF or IS-IS can be used for intra-domain routing. A difference is
        that IP addresses (as node addresses) now points to nodes instead of
        interfaces. Changes to OSPF coding should be minimal. IS-IS might be
        preferable since it inherently deals with node addresses. <vspace
        blankLines="1"/>Although other protocols, in principle, could also be
        used for inter-domain routing, BGP4 with PA addresses might be the
        immediate option not much to disturb the current operation of the
        Internet.</t>
      </section>
    </section>

    <section title="CONSEQUENCES">
      <section title="Recursive Internet">
        <t>In NARA, the network architectures of the interior (intra-domain)
        and the exterior (global) tiers are symmetric, basically the same.
        Therefore, the same generic architecture can be repeated without bound
        outwards as well as inwards. For example, in the design of an
        inter-planetary Internet, the same architecture can be placed on top
        of the global Internet. Also, in accommodating edge networks like body
        area networks which by themselves may each consist of a huge number of
        internal nodes(e.g. in the case of intelligent robots), repetition of
        the same architecture might significantly reduce the complexity of the
        whole-scale networking. <vspace blankLines="1"/>The Internet modeled
        as with NARA can be asserted to be scalable and expandable without
        bound.</t>
      </section>

      <section title="No Address Depletion">
        <t>Since the global Internet is split into two tiers of manageable
        size, there'd be no danger of address depletion. The 32-bit length for
        node addresses will be more than enough for most domains' need. The
        same should be true of the 32-bit domain address length. In fact,
        migration to IPv6 is not a requirement anymore, but merely a luxurious
        option.</t>
      </section>

      <section title="No Inadvertent Internet Governance">
        <t>Since domains don't have to buy node address spaces from any
        authorities, the impact of the Internet governance will reduce only to
        a minimal necessity.</t>
      </section>

      <section title="Fast Mobility">
        <t>Host mobility inside a domain is provided as default. Transport
        connections are associated with node addresses which don't change
        while nodes are moving inside a given domain. Transport connections
        don't break at intra-domain host mobility. And since such mobility is
        directly provided by link-state routing, with periodic link-state
        updates augmented by immediate event broadcasts, host mobility is as
        fast as the frequency and speed of broadcast packet propagation.
        <vspace blankLines="1"/>Network(subnet) mobility is also provided as
        an inherent feature of intra-domain routing. Renumbering of mobile
        subnets is not necessary since each subnet is identified by the
        associated router address which, being itself a node address, does not
        change inside a given domain.</t>
      </section>

      <section title="Site Multi-homing and Migration">
        <t>Domain addresses also don't change at migration to new upstream
        transit domains.<vspace blankLines="1"/>Domain multi-homing with flat
        address is not a problem, either. The same domain address of a
        multi-homed domain will simply be seen simultaneously in gateway
        routing tables of involved upstream transit domains.</t>
      </section>

      <section title="Host Multi-homing">
        <t>Host multi-homing can also be supported. If a host is multi-homed
        on multiple domains, there'd be multiple return domain addresses for
        the same name. Transport connections through different domains would
        be considered as different ones. If there's need to converge these
        multiple connections to be presented as a single virtual transport
        connection to a given application, some sort of session management
        function might be exploited on top of the transport layer as is done
        with MPTCP<xref target="RFC6182"/>.</t>
      </section>

      <section title="Traffic Engineering">
        <t>Gateways of a multi-homed domains can control inbound traffic
        according to the remote domain addresses. Interior routers can also
        choose exit gateways in accordance with target domain addresses.
        <vspace blankLines="1"/>If traffic engineering in the granularity of a
        node is desired, nodes may involve themselves in informing the subnet
        routers of their preferred domain address of a given remote
        multi-homed domain or even the preferred domain address of a given
        remote multi-homed node. The same can be done for preference about the
        exiting gateway.</t>
      </section>

      <section title="No Renumbering">
        <t>Since node addresses are local, no renumbering of nodes is
        necessary at domain migration or multi-homing.</t>
      </section>

      <section title="Semantic Overloading">
        <t>The current proposal implicitly suggests that semantic overloading
        of an address may not be seen as a fatal problem to a network
        architecture. The addresses, of nodes and domains, are used both for
        identification and routing in NARA. This contextual malleability of
        addresses is seen as rather a virtue than an evil. It can also be
        argued that whatever separation one might engineer, semantic
        overloading would inevitably result one way or another and so should
        rather be received as a natural phenomenon of networking.</t>
      </section>
    </section>

    <section title="CONCLUSIONS">
      <t>A network architecture based on local and recursive addressing is
      introduced. The Internet is seen as a collection of domains, each being
      itself a collection of nodes. Addresses local to a given domain name
      nodes whereas global addresses do domains. Mobility, of both hosts and
      subnets, is fast because it is provided directly by routers as one of
      their inherent features. Frozen domain- as well as node- addresses
      guarantee seamless domain migration and multi-homing with no need of
      renumbering. Address depletion is not an issue anymore and the Internet
      governance reduces to a minimal necessity. The proposed network model
      can repeat itself outwards as well as inwards, enabling its
      applicability to inter-plenary Internet as well as to body area
      networks.</t>
    </section>

    <section title="Security Considerations">
      <t>None.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="IEN0001">
        <front>
          <title>Issues in the interconnection of datagram networksh</title>

          <author initials="A." surname="Hinchley"/>

          <date month="July" year="1977"/>
        </front>
      </reference>

      <reference anchor="IEN0019">
        <front>
          <title>Inter-network naming, addressing, and routing</title>

          <author initials="J. F." surname="Shoch"/>

          <date month="January" year="1978"/>
        </front>
      </reference>

      <reference anchor="RFC1498">
        <front>
          <title>On the naming and binding of network destinations</title>

          <author initials="J.H." surname="Saltzer"/>

          <date month="August" year="1993"/>
        </front>
      </reference>

      <reference anchor="RFC4423">
        <front>
          <title>Host Identity Protocol (HIP) Architecture</title>

          <author initials="R." surname="Moskowitz"/>

          <author initials="P." surname="Nikander"/>

          <date month="May" year="2006"/>
        </front>
      </reference>

      <reference anchor="GSE">
        <front>
          <title>GSE - An Alternate Addressing Architecture for IPv6
          draft-ietf-ipngwg-gseaddr-00</title>

          <author initials="M." surname="O'Dell "/>

          <date month="February" year="1997"/>
        </front>
      </reference>

      <reference anchor="ILNP">
        <front>
          <title>ILNP Architectural Description
          draft-irtf-rrg-ilnp-arch-03</title>

          <author initials="R." surname="Atkinson "/>

          <author initials="S. N." surname="Bhatti"/>

          <author initials="U. St." surname="Andrews"/>

          <date month="May" year="2012"/>
        </front>
      </reference>

      <reference anchor="IEEE-MCOM">
        <front>
          <title>An ID/locator split architecture for future networks</title>

          <author initials="V.P." surname="Kafle"/>

          <date month="February" year="2010"/>
        </front>
      </reference>

      <reference anchor="LISP">
        <front>
          <title>Locator/ID Separation Protocol (LISP)
          draft-ietf-lisp-23</title>

          <author initials="D." surname="Farinacci"/>

          <author initials="V." surname="Fuller"/>

          <author initials="D." surname="Meyer"/>

          <author initials="D." surname="Lewis"/>

          <date month="May" year="2012"/>
        </front>
      </reference>

      <reference anchor="IRON">
        <front>
          <title>The Internet Routing Overlay Network (IRON)
          draft-templin-iron-16</title>

          <author initials="F." surname="Templin"/>

          <date month="December" year="2010"/>
        </front>
      </reference>

      <reference anchor="Ivip">
        <front>
          <title>Ivip (Internet Vastly Improved Plumbing) Architecture
          draft-whittle-ivip-arch-04</title>

          <author initials="R." surname="Whittle"/>

          <date month="March" year="2010"/>
        </front>
      </reference>

      <reference anchor="RFC1955">
        <front>
          <title>New Scheme for Internet Routing and Addressing (ENCAPS) for
          IPNG</title>

          <author initials="R." surname="Hinden"/>

          <date month="June" year="1996"/>
        </front>
      </reference>

      <reference anchor="RFC6306">
        <front>
          <title>Hierarchical IPv4 Framework</title>

          <author initials="P." surname="Frejborg"/>

          <date month="July" year="2011"/>
        </front>
      </reference>

      <reference anchor="RFC6182">
        <front>
          <title>Architectural Guidelines for Multipath TCP
          Development</title>

          <author initials="A." surname="Ford"/>

          <date month="March" year="2011"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
