Network Working Group DY Kim Internet-Draft Chungnam University Intended status: Experimental August 16, 2012 Expires: February 17, 2013 Network Architecture with Recursive Addressing draft-dykim-nara-01 Abstract 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on February 17, 2013. Copyright Notice Copyright (c) 2012 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 DY Kim Expires February 17, 2013 [Page 1] Internet-Draft NARA August 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. INTRA-DOMAIN ROUTING . . . . . . . . . . . . . . . . . . . . . 6 4. INTER-DOMAIN ROUTING . . . . . . . . . . . . . . . . . . . . . 8 5. IMPLEMENTATION CHOICES . . . . . . . . . . . . . . . . . . . . 9 5.1. Node Address . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Domain Address . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Name Servers . . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Routing Protocols . . . . . . . . . . . . . . . . . . . . 10 6. CONSEQUENCES . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Recursive Internet . . . . . . . . . . . . . . . . . . . . 11 6.2. No Address Depletion . . . . . . . . . . . . . . . . . . . 11 6.3. No Inadvertent Internet Governance . . . . . . . . . . . . 11 6.4. Fast Mobility . . . . . . . . . . . . . . . . . . . . . . 11 6.5. Site Multi-homing and Migration . . . . . . . . . . . . . 12 6.6. Host Multi-homing . . . . . . . . . . . . . . . . . . . . 12 6.7. Traffic Engineering . . . . . . . . . . . . . . . . . . . 12 6.8. No Renumbering . . . . . . . . . . . . . . . . . . . . . . 12 6.9. Semantic Overloading . . . . . . . . . . . . . . . . . . . 12 7. CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 DY Kim Expires February 17, 2013 [Page 2] Internet-Draft NARA August 2012 1. Introduction 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[IEN0001][IEN0019][RFC1498] and so as the main obstacle hindering the Internet from providing fast mobility and seamless multihoming. A considerable number of protocols based on the Loc/ID Separation(LIS) architecture have been proposed. Some of them are host-based solutions [RFC4423][GSE][ILNP][IEEE-MCOM]while others are router-based[LISP][IRON][Ivip]. Most such proposals share one thing; IDs and Locs are global. 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. NARA is very close to the ideas proposed in ENCAPS and hIPv4[RFC1955][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. 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. 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. 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. DY Kim Expires February 17, 2013 [Page 3] Internet-Draft NARA August 2012 2. ARCHITECTURE 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. +-----+ +-----------+ +------------+ | APP |-----|NameS-Local|---......---|NameS-Global| +-----+ +-----------+ +------------+ | +---|---+ | TP/IP | +---|---+ | +--------+ +----|---------------------------+ |Domain_A| | | Domain | +--------+ | +------+ +-------+ | | | | node |-------------|iDomain| | | | +------+ | +-------+ | | | +------+ +---+ +--------+ | | node | | G |---|Domain_B| | +------+ +---+ +--------+ +--------------------------------+ Figure 1: Architectiral Overview of NARA 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. 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. 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. Inter-domain routing is done solely on domain addresses while intra- DY Kim Expires February 17, 2013 [Page 4] Internet-Draft NARA August 2012 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. 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. 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. 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. 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. 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. DY Kim Expires February 17, 2013 [Page 5] Internet-Draft NARA August 2012 3. INTRA-DOMAIN ROUTING 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. 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. Hosts may not involve themselves directly with such routing tables. It is up to routers to route packets exiting nodes. 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. 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. 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. DY Kim Expires February 17, 2013 [Page 6] Internet-Draft NARA August 2012 +------------------------------------------------------------+ | 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 |------+ +-----+ Figure 2: Intra-domain Routing of NARA DY Kim Expires February 17, 2013 [Page 7] Internet-Draft NARA August 2012 4. INTER-DOMAIN ROUTING 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. 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. +----------------------------------------------------------+ | +----+ +----+ +----+ | | | 11 | | 37 | | 15 | | | +----+ +----+ +----+ | | |___ | | | | |___| | | | +----+ +-----+ +-----+ +----+ | | | 25 |----| 1 |------------------| 3 |----| 41 | | | +----+ +-----+ +-----+ +----+ | | | |___________ | | | | | | | | | |___________| | | +----+ +-----+ +-----+ | | | 22 |----| 2 |------------------| 4 | | | +----+ +-----+ +-----+ | | +----+ | | |11,1| | | |15,3| | | |22,2| | | |25,1| | | |37,1| | | |41,3| | | +----+ | +---------------------------------------------------------- Figure 3: Inter-domain Routing of NARA DY Kim Expires February 17, 2013 [Page 8] Internet-Draft NARA August 2012 5. IMPLEMENTATION CHOICES 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. 5.1. Node Address 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. 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. 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. 5.2. Domain Address 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. 5.3. Gateway 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. 5.4. Name Servers 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. DY Kim Expires February 17, 2013 [Page 9] Internet-Draft NARA August 2012 5.5. Routing Protocols 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. 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. DY Kim Expires February 17, 2013 [Page 10] Internet-Draft NARA August 2012 6. CONSEQUENCES 6.1. Recursive Internet 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. The Internet modeled as with NARA can be asserted to be scalable and expandable without bound. 6.2. No Address Depletion 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. 6.3. No Inadvertent Internet Governance 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. 6.4. Fast Mobility 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. 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. DY Kim Expires February 17, 2013 [Page 11] Internet-Draft NARA August 2012 6.5. Site Multi-homing and Migration Domain addresses also don't change at migration to new upstream transit domains. 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. 6.6. Host Multi-homing 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[RFC6182]. 6.7. Traffic Engineering 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. 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. 6.8. No Renumbering Since node addresses are local, no renumbering of nodes is necessary at domain migration or multi-homing. 6.9. Semantic Overloading 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. DY Kim Expires February 17, 2013 [Page 12] Internet-Draft NARA August 2012 7. CONCLUSIONS 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. DY Kim Expires February 17, 2013 [Page 13] Internet-Draft NARA August 2012 8. Security Considerations None. DY Kim Expires February 17, 2013 [Page 14] Internet-Draft NARA August 2012 9. Normative References [GSE] O'Dell , M., "GSE - An Alternate Addressing Architecture for IPv6 draft-ietf-ipngwg-gseaddr-00", February 1997. [IEEE-MCOM] Kafle, V., "An ID/locator split architecture for future networks", February 2010. [IEN0001] Hinchley, A., "Issues in the interconnection of datagram networksh", July 1977. [IEN0019] Shoch, J., "Inter-network naming, addressing, and routing", January 1978. [ILNP] Atkinson , R., Bhatti, S., and U. Andrews, "ILNP Architectural Description draft-irtf-rrg-ilnp-arch-03", May 2012. [IRON] Templin, F., "The Internet Routing Overlay Network (IRON) draft-templin-iron-16", December 2010. [Ivip] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture draft-whittle-ivip-arch-04", March 2010. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP) draft-ietf-lisp-23", May 2012. [RFC1498] Saltzer, J., "On the naming and binding of network destinations", August 1993. [RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", June 1996. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", May 2006. [RFC6182] Ford, A., "Architectural Guidelines for Multipath TCP Development", March 2011. [RFC6306] Frejborg, P., "Hierarchical IPv4 Framework", July 2011. DY Kim Expires February 17, 2013 [Page 15] Internet-Draft NARA August 2012 Author's Address Dae Young KIM Chungnam University InfoCom Eng. Daejeon 305-764 South KOREA Phone: +82 42 821 6862 Email: dykim@cnu.kr DY Kim Expires February 17, 2013 [Page 16]