Internet DRAFT - draft-dykim-recursive-addressing
draft-dykim-recursive-addressing
Network Working Group DY. KIM
Internet-Draft Chungnam University
Intended status: Standards Track December 14, 2011
Expires: June 16, 2012
NARA : Network Architecture with Recursive Addressing
draft-dykim-recursive-addressing-00.txt
Abstract
This document describes network architecture based on recursive
addressing. The Internet is modeled as a network of autonomous
sites, each being a collection of nodes. Each site is named by a
site address drawn from a global number space while each node is
named by a node address drawn from a number space local to each site.
Routing among sites depends solely on site addresses while that
within each site on node addresses. Flat routing to render inherent
mobility as well as mapped routing to additionally cope with table
size are proposed. 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 June 16, 2012.
Copyright Notice
Copyright (c) 2011 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
KIM Expires June 16, 2012 [Page 1]
Internet-Draft 2 December 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. INTERIOR ROUTING . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Flat-Address Routing . . . . . . . . . . . . . . . . . . . 7
3.2. Mapped-Address Routing . . . . . . . . . . . . . . . . . . 8
4. EXTERIOR ROUTING . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Flat-Address Routing . . . . . . . . . . . . . . . . . . . 9
4.2. Virtual-Address Routing . . . . . . . . . . . . . . . . . 10
5. IMPLEMENTATION CHOICES . . . . . . . . . . . . . . . . . . . . 11
5.1. Node Address . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Site Address . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Name Servers . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 12
6. DEPLOYABILITY . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Distribution of Site Addresses . . . . . . . . . . . . . . 13
6.2. Changes to DNS . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Changes to Hosts . . . . . . . . . . . . . . . . . . . . . 13
6.4. Changes to Routers . . . . . . . . . . . . . . . . . . . . 13
6.5. Use of IP Option Field . . . . . . . . . . . . . . . . . . 14
6.6. Introduction of Extra Servers . . . . . . . . . . . . . . 14
7. CONSEQUENCES . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Recursive Internet . . . . . . . . . . . . . . . . . . . . 15
7.2. No Address Depletion . . . . . . . . . . . . . . . . . . . 15
7.3. No Inadvertent Internet Governance . . . . . . . . . . . . 15
7.4. Fast Mobility . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Site Multi-homing and Migration . . . . . . . . . . . . . 16
7.6. Host Multi-homing . . . . . . . . . . . . . . . . . . . . 16
7.7. Traffic Engineering . . . . . . . . . . . . . . . . . . . 16
7.8. No Renumbering . . . . . . . . . . . . . . . . . . . . . . 17
7.9. Semantic Overloading . . . . . . . . . . . . . . . . . . . 17
8. CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
KIM Expires June 16, 2012 [Page 2]
Internet-Draft 2 December 2011
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 Internet's inability of
efficient multi-homing, for which semantic overloading of IP address
has been blamed. This semantic overloading, that IP addresses are
used as both identifiers(IDs) and 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 multihoming.
A considerable number of new protocols based on the Loc/ID
Separation(LIS) architecture have been proposed thus far. 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 Locators are global. Although some are based on
local addressing, addresses at the granularity of a node are exposed
to DFZ routing.
This document proposes an architecture, named NARA, based on local
addressing in its strict sense. Local addresses, for nodes, are
never exploited in DFZ (called exterior in this document) routing. A
collection of nodes under an autonomous administration is called a
site, and only site addresses identifying them are used for exterior
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 principle can be recursively repeated inwards
and outwards off a given network tier. In this respect, NARA can be
considered as one of recursive network architectures.
Following sections describe the architecture of NARA and associated
routing, along with implementation choices for better chance of
deployability. Consequences of the proposal are provided before
KIM Expires June 16, 2012 [Page 3]
Internet-Draft 2 December 2011
concluding the document.
KIM Expires June 16, 2012 [Page 4]
Internet-Draft 2 December 2011
2. Architecture
The Internet is modeled as a networked collection of autonomous
sites. A site is a collection of nodes, also called either
hosts(leaf node) or routers(relay nodes). A subset of hosts and an
associated router forms a subnet. Therefore, a site can also be
considered as a networked collection of subnets. A site itself can
be a leaf or a transit
+-----+ +-------+
| APP |-----| NameS |
+-----+ +-------+
|
+---|---+
| TP/IP |
+---|---+
| +--------+
+----|---------------------------+ | SITE_A |
| | SITE | +--------+
| +------+ +-------+ | |
| | node |-------------| iSITE | | |
| +------+ | +-------+ | |
| +------+ +--|--+ | +--------+
| | node | | G |---| SITE_B |
| +------+ +--|--+ +--------+
+--------------------------------+
Figure 1: Operational overview of NARA
The Internet therefore governed by two-tier administration, i.e., the
global authority and site authorities.
A site is named by a global site address while a node by a node
address local to a given site. Now that each subnet is associated
with a router, it can be identified by a router address.
Exterior routing among sites is done solely on site addresses while
interior routing on node addresses. Node addresses are not used in
exterior routing. That is, exterior and interior routings are
orthogonal to each other.
Transport connections are also associated with node addresses. In
this sense, it can be said that node addresses are semantically
overloaded. In this proposed network architecture, semantic
overloading of addresses is not considered harmful; it is considered
rather natural and even desirable.
Neither node- nor site-addresses bear topological significance; they
KIM Expires June 16, 2012 [Page 5]
Internet-Draft 2 December 2011
each consume separate flat number spaces. Node addresses don't
change while nodes are moving around within a site. Site addresses
also don't change at migration between upstream network providers as
well as at multi-homing.
Node names are global. A name server provides mapping between a node
name and a {node address, site address} tuple. If the site address
is local, packets are delivered to the target interior node by use of
an interior routing. If it is foreign, packets are delivered to one
of exterior routers, aka gateways, interfacing with other sites.
KIM Expires June 16, 2012 [Page 6]
Internet-Draft 2 December 2011
3. INTERIOR ROUTING
Packets in the site tier, interior to sites, are routed solely on
node addresses. Site addresses don't come into play in interior
routing. Any protocols including OSPF and IS-IS can be applied to
this interior routing.
+------------------------------------------------------------+
| mapper +--------------+ +--------------+ |
| +-------+ | +---+ +---+ | | +---+ +---+ | |
| | 1, 91 | | | 6 | | 4 | | | | 3 | | 2 | | |
| | 2, 97 | | +---+ +---+ | | +---+ +---+ | |
| | 3, 97 | | +----+ | | +----+ | |
| | 4, 94 | +----| 94 |----+ +----| 97 |----+ |
| | 5, 91 | +----+--------1-------+----+ |
| | 6, 94 | | |__________2_____ | |
| +-------+ 2| | |1 |
| +----+--------1-------+----+ |
| {node,subnet} +----| 91 |----+ | 96 | |
| ={node,router} | +----+ | +----+ |
| | +---+ +---+ | | |
| | | 1 | | 5 | | | |
| | +---+ +---+ | | |
| +--------------+ +-----+ |
+-----------------------------------------------| 101 |------+
+-----+
Figure 2: Interior routing of NARA
3.1. Flat-Address Routing
In a scenario of flat-address routing, node addresses are directly
used in routing and forwarding decisions. Each router maintains a
table of {target node address, target router address, next-hop router
address} 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 to all other routers in the site by the previous
and/or newly visited subnet router(s). Host mobility provided
directly by routers in this way can hence be fast.
When a subnet moves along with the associated router, such a move
will be perceived as a topological change of the network and will be
reflected in the routing tables at the speed of associated link-state
updates. Henceforth, (subnet) network mobility is provided also as
KIM Expires June 16, 2012 [Page 7]
Internet-Draft 2 December 2011
an inherent feature of the routing.
3.2. Mapped-Address Routing
In a scenario of mapped-address routing, a common mapping server
inside a given site is used in order to shrink the table size of each
routers. {target node address, target router address} tuples are
maintained by the mapping server whereas routers will keep only
{target router address, next-hop router address} tuples as with usual
router activities. At reception of the first packet from a node
after a given inactive interval, the router will consult the mapping
server for the associated target router address. The associated
next-hop router will then be determined by a given routing algorithm.
Acquired {target node address, target router address} tuples may be
cached at routers but will be short-lived lest stale information be
used for mobile hosts.
Hosts themselves need not be aware of existence of the mapping
server. They will continue to involve themselves only with node
addresses, for source and target, and rely on routers for path
finding. They will behave themselves the same way as they do with
flat routing.
This scenario of mapped-address routing is very similar to the
related operation of cellular networks. This might rather be
considered as a merit, for cellular networks are known for their fast
mobility.
KIM Expires June 16, 2012 [Page 8]
Internet-Draft 2 December 2011
4. EXTERIOR ROUTING
Packets in the global tier, exterior to sites, are routed solely on
site addresses. Node addresses are not advertised into the global
tier. Any protocols, BGP, OSPF or IS-IS, can be applied to this
exterior routing.
+----------------------------------------------------------+
| +----+ +----+ +----+ |
| | 11 | | 37 | | 15 | |
| +----+ +----+ +----+ |
| |_12_ | | |
| |___|13 |31 |
| +----+ +-----+ +-----+ +----+ |
| | 25 |-11-| 1 |------------------| 3 |-32-| 41 | |
| +----+ +-----+ +-----+ +----+ |
| | |___________ | |
| | | | |
| | |___________| |
| +----+ +-----+ +-----+ |
| | 22 |-21-| 2 |------------------| 4 | |
| +----+ +-----+ +-----+ |
| +----+ |
| |11,1| |
| |15,3| |
| |22,2| |
| |25,1| |
| |37,1| |
| |41,3| |
| +----+ |
+----------------------------------------------------------+
Figure 3: Exterior routing of NARA
Each transit-sites can be considered to correspond, in a generic
network graph, to relay nodes(routers) whereas leaf sites to leaf
nodes(hosts). Therefore, symmetry of network architecture repeats
itself at each tier.
4.1. Flat-Address Routing
In a scenario of flat-address routing, site addresses are directly
used in routing and forwarding decisions. Each transit gateway
maintains a table of {target site address, target transit-site
address, next-hop transit-site address} tuples. Tables are updated
through routing information exchange between transit gateways. For
multi-homed target sites, multiple entries for the same target site
may exist with different next-hop transit-site addresses.
KIM Expires June 16, 2012 [Page 9]
Internet-Draft 2 December 2011
Leaf gateways may not involve themselves directly with such routing
tables. It is up to transit gateways to route packets exiting leaf
sites.
4.2. Virtual-Address Routing
In a scenario of virtual-address routing, aggregatable addresses are
used in order to shrink the routing table size. Transit gateways may
use PA(provider-aggregatable) prefixes as virtual addresses for
routing instead of site addresses. Each site address will then be
associated with one or more (for multi-homing) PA prefixes, with such
mapping maintained by a mapping server in the global tier. A site
address will be converted by an upstream transit gateway to a PA
prefix at entering that upstream provider, and the PA prefix will
subsequently be converted back to the site address at leaving the
upstream provider into the downstream target site.
Leaf gateways themselves need not be aware of existence of such PA
prefixes. They will continue to involve themselves only with site
addresses, for source and target, and hence behave themselves the
same way as they do with flat routing.
KIM Expires June 16, 2012 [Page 10]
Internet-Draft 2 December 2011
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 addresses can be used for local node
addresses. However, since 32-bit might be more than enough for most
sites, use of IPv4 addresses might be more appealing.
Use of IPv4 addresses ensures minimal changes to existing vast
population of IPv4 hosts. Also, 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 nodes themselves. That is, although IP
addresses will continue to be used, interpretation of their context
will be changed.
5.2. Site Address
32-bit IP addresses can be used for site addresses. The uniqueness
of the site addresses will be maintained by the distribution
authorities like ICANN.
One might wonder where to carry site addresses. It is proposed to
carry them in the IPv4 option field of length 32 bits. It is long
enough to accommodate a considerable number of sites that may
additionally come into being in the global Internet.
Another option is to follow the scheme proposed in hIPv4. That is,
node addresses and site addresses can be swapped by gateways (called
Locator Swap Router in hIPv4) at exiting and entering given sites.
5.3. Name Servers
In the two-tier model described here, names are globally unique. DNS
can continue to be used with a bit of extension; to return {node
address, site address} pairs instead of {IP address}.
The scope of names can be an issue in recursive repetition of this
network architecture. If the tiers would recurse without bound
inwards and/or outwards, demanding uniqueness of names in the entire
resultant network may not be feasible because of excessive length of
the names.
KIM Expires June 16, 2012 [Page 11]
Internet-Draft 2 December 2011
Name resolution can also be done recursively. For example, if a
remote node wants to get a body temperature of a human node, an
application message "get body temperature" may first be targeted to
the human node of an address pair (node, site), for which a name
server as in Fig. 1 has done the mapping. Then, the content of the
message may be used to consult another name server encompassing the
tier pair one level deeper, that is the tier where the human body
belongs and another covering the nodes inside the human body. This
name server can then return an address pair (in-human node, human
node) to continue address swapping to reach the final thermometer.
That is to say, context-awareness may ensure recursive name service.
5.4. Routing Protocols
OSPF or IS-IS can be used for interior 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 better suited in this sense because it inherently deals with node
addresses.
Although other protocols, in principle, could also be used for
exterior routing, BGP4 with some modification with virtual-address
routing might be a choice more acceptable, as a start, to most
existing ISPs and large transit sites.
KIM Expires June 16, 2012 [Page 12]
Internet-Draft 2 December 2011
6. DEPLOYABILITY
6.1. Distribution of Site Addresses
The first step towards to introduction of NARA is that site addresses
be distributed and managed by naming and numbering authorities like
ICANN and regional Internet registries.
6.2. Changes to DNS
DNS shall be recoded or reconfigured to deal with {node address, site
address} pairs in place of only {IP address}. Necessary changes
would be trivial and so could be done in a global scale with minimal
pains.
6.3. Changes to Hosts
As far as transport connections are concerned, nothing changes for
hosts.
The only change would be reconfigure and enable hosts to put the site
address acquired from DNS into the IP option field. There'll be rare
need to look into the site address in received packets since it is
not associated with transport connections at all; the node address
only will be.
6.4. Changes to Routers
If flat-address routing is used, a new column has to be added to the
routing table to house target node addresses. Also, membership
change of children nodes per each router should be added to link-
state update messages.
A potential concern about the flat-address routing is that the number
of table entries will considerably increase to accommodate all
possible active nodes in a given site. This may be seen as too much
a burden for large sites, although it may be quite manageable for
small sites. The resultant table size could be economically
affordable even for larger sites, considering the current memory
technology. Another issue might be the lookup speed for such large
tables, for which there might be an ample number of smart
implementation techniques.
Benefits from this large flat tables is, however, huge. Mobility,
for both hosts and subnets, is provided as an inherent function of
routing. No extra infrastructural element is needed, and the
provided mobility is very fast, i.e., at the speed of broadcast
packet propagation.
KIM Expires June 16, 2012 [Page 13]
Internet-Draft 2 December 2011
If mapped-address routing should be used, the table to be managed by
each router will be the same as with usual routing; {target router
address, next-hop router address}. Only extra action to be taken is
consult an in-site server for {target node address, target router
address} mapping, to be cached for persistent continuation of smooth
packet flow for an ongoing session. Necessary code changes will be
minimal.
6.5. Use of IP Option Field
Hosts and routers will have to be ready to use IP option fields. It
is asserted by a lot of experts that use of the IP option field is
not going to work since most routers today, interior as well as
exterior, are configured by network operators simply to ignore any IP
options.
However, as long as the problem is non-use of an available facility
rather than lack of its implementation, it would highly be encouraged
to reconfigure the nodes to respond to option fields to switch to the
operational mode proposed by NARA.
Another side effect of the use of the IP option field is increasing
the packet size by 64-bits; 32 bits for each source and target site
addresses. This should, however, be a minimal burden in view of the
benefits from the new architecture as well as compared to other new
network architectural proposals most of which inevitably increase the
packet size.
6.6. Introduction of Extra Servers
If mapped-address interior routing is to be used, a mapping server
has to be installed inside each site. If virtual-address exterior
routing is to be used, another mapping server has to be installed in
the exterior (global) tier. Installation and management of such
servers involve only central management authorities, not every client
nodes or sites, and hence any cost or pains should be confined to a
small number of entities.
KIM Expires June 16, 2012 [Page 14]
Internet-Draft 2 December 2011
7. CONSEQUENCES
7.1. Recursive Internet
In NARA, the network architectures of the interior (in-site) 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.
7.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 sites' need. The
same should be true of the 32-bit site address length. In fact,
migration to IPv6 is not a requirement anymore, but merely a
luxurious option.
7.3. No Inadvertent Internet Governance
Since sites don't have to buy node address spaces from any
authorities, the impact of the Internet governance will reduce only
to a minimal necessity.
7.4. Fast Mobility
Host mobility inside a site is provided as default. Transport
connections are associated with node addresses which don't change
while nodes are moving inside a given site. Transport connections
don't break at in-site host mobility. And since such mobility is
directly provided by link-state routing, with periodic link-state
updates augmented by immediate event broadcast, host mobility is as
fast as the speed of broadcast packet propagation.
Network(subnet) mobility is also provided as an inherent feature of
interior 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
site.
KIM Expires June 16, 2012 [Page 15]
Internet-Draft 2 December 2011
Mobility across sites poses a number of challenges. In order to
continue communication in a newly visited site, node authentication
will have to take place before anything. Such authentication process
may take a considerable number of seconds, if not minutes, hard to
guarantee non-breakage of transport connections.
Even if authentication may be swift enough to guarantee sustaining
mobile connections, reflection of site changes onto the name server
might take at least tens of seconds to converge. If this time lag is
not to be borne, the gateway of the previous site might continue
redirecting the incoming packets to the newly visited site, just long
enough for name servers to converge. Engineering techniques employed
by cellular networks might enlighten the detailed design of fast
cross-site mobility in NARA.
7.5. Site Multi-homing and Migration
Site addresses also don't change at migration to new upstream transit
sites. Therefore, there's no need for refreshing DNS for nodes
inside migrating sites. The only action might be to update the
entries for migrating sites in the {site address, PA prefix} mapping
server, yet only in the case of virtual-address routing.
Site multi-homing with flat exterior routing is not a problem,
either. The same site address of a multi-homed site will simply be
seen simultaneously in gateway routing tables of involved upstream
transit sites. In the case of virtual-address routing, multiple
entries will exist in the mapping server for the same multi-homed
site, a {site address, PA prefix} pair for each upstream transit
sites.
7.6. Host Multi-homing
Host multi-homing can also be supported. If a host is multi-homed on
multiple sites, there'd be multiple return values {node address, site
address} for the same name. Transport connections through different
sites 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].
7.7. Traffic Engineering
Gateways of a multi-homed sites can control inbound traffic according
to the remote site addresses. Interior routers can also choose exit
gateways in accordance with target site addresses.
KIM Expires June 16, 2012 [Page 16]
Internet-Draft 2 December 2011
If traffic engineering in the granularity of a node is desired, nodes
may involve themselves in informing the subnet routers of their
preferred site address of a given remote multi-homed site or even the
preferred site address of a given remote multi-homed node. The same
can be done for preference about the exiting gateway.
MPTCP can additionally be employed with no impact on the normal NARA
operation, to benefit from its implicit traffic engineering
capability, too.
7.8. No Renumbering
Since node addresses are local, no renumbering of nodes is necessary
at site migration or multi-homing.
7.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 sites, 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 in one way or another and so
should rather be received as a natural phenomenon of networking.
KIM Expires June 16, 2012 [Page 17]
Internet-Draft 2 December 2011
8. CONCLUSIONS
A network architecture based on local and recursive addressing is
introduced. The Internet is seen as a collection of sites, each
being itself a collection of nodes. Addresses local to a given sites
name nodes whereas global addresses name sites. Mobility, of both
hosts and subnets, is very fast because it is provided directly by
routers as one of their inherent features. Frozen site as well as
node addresses guarantee seamless site migration and multi-homing
with no need for 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.
KIM Expires June 16, 2012 [Page 18]
Internet-Draft 2 December 2011
9. Security Considerations
None.
KIM Expires June 16, 2012 [Page 19]
Internet-Draft 2 December 2011
10. 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., "ILNP Concept of Operations
draft-rja-ilnp-intro-11", July 2011.
[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-12", April 2011.
[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.
KIM Expires June 16, 2012 [Page 20]
Internet-Draft 2 December 2011
Author's Address
Dae Young KIM
Chungnam University
99 Daehak-ro, Yuseong-gu
Daejeon
South KOREA
Phone: +82 42 821 6861
Email: dykim@cnu.ac.kr
KIM Expires June 16, 2012 [Page 21]
