15. Name-Based Sockets
Name-based sockets are an evolution of the existing address-based
sockets, enabling applications to initiate and receive communication
sessions based on the use of domain names in lieu of IP addresses.
Name-based sockets move the existing indirection from domain names to
IP addresses from its current position in applications down to the IP
layer. As a result, applications communicate exclusively based on
domain names, while the discovery, selection, and potentially in-
session re-selection of IP addresses is centrally performed by the IP
Name-based sockets help mitigate the Internet routing scalability
problem by separating naming and addressing more consistently than
what is possible with the existing address-based sockets. This
supports IP address aggregation because it simplifies the use of IP
addresses with high topological significance, as well as the dynamic
replacement of IP addresses during network-topological and host-
A particularly positive effect of name-based sockets on Internet
routing scalability is the new incentives for edge network operators
to use provider-assigned IP addresses, which are more aggregatable
than the typically preferred provider-independent IP addresses. Even
though provider-independent IP addresses are harder to get and more
expensive than provider-assigned IP addresses, many operators desire
provider-independent addresses due to the high indirect cost of
provider-assigned IP addresses. This indirect cost is comprised of
both difficulties in multihoming, and tedious and largely manual
renumbering upon provider changes.
Name-based sockets reduce the indirect cost of provider-assigned IP
addresses in three ways, and hence make the use of provider-assigned
IP addresses more acceptable: (1) They enable fine-grained and
responsive multihoming. (2) They simplify renumbering by offering an
easy means to replace IP addresses in referrals with domain names.
This helps avoiding updates to application and operating system
configurations, scripts, and databases during renumbering. (3) They
facilitate low-cost solutions that eliminate renumbering altogether.
One such low-cost solution is IP address translation, which in
combination with name-based sockets loses its adverse impact on
The prerequisite for a positive effect of name-based sockets on
Internet routing scalability is their adoption in operating systems
and applications. Operating systems should be augmented to offer
name-based sockets as a new alternative to the existing address-based
sockets, and applications should use name-based sockets for their
communications. Neither an instantaneous, nor an eventually complete
transition to name-based sockets is required, yet the positive effect
on Internet routing scalability will grow with the extent of this
Name-based sockets were hence designed with a focus on deployment
incentives, comprising both immediate deployment benefits as well as
low deployment costs. Name-based sockets provide a benefit to
application developers because the alleviation of applications from
IP address management responsibilities simplifies and expedites
application development. This benefit is immediate owing to the
backwards compatibility of name-based sockets with legacy
applications and legacy peers. The appeal to application developers,
in turn, is an immediate benefit for operating system vendors who
adopt name-based sockets.
Name-based sockets furthermore minimize deployment costs: Alternative
techniques to separate naming and addressing provide applications
with "surrogate IP addresses" that dynamically map onto regular IP
addresses. A surrogate IP address is indistinguishable from a
regular IP address for applications, but does not have the
topological significance of a regular IP address. Mobile IP and the
Host Identity Protocol are examples of such separation techniques.
Mobile IP uses "home IP addresses" as surrogate IP addresses with
reduced topological significance. The Host Identity Protocol uses
"host identifiers" as surrogate IP addresses without topological
significance. A disadvantage of surrogate IP addresses is their
incurred cost in terms of extra administrative overhead and, for some
techniques, extra infrastructure. Since surrogate IP addresses must
be resolvable to the corresponding regular IP addresses, they must be
provisioned in the DNS or similar infrastructure. Mobile IP uses a
new infrastructure of home agents for this purpose, while the Host
Identity Protocol populates DNS servers with host identities. Name-
based sockets avoid this cost because they function without surrogate
IP addresses, and hence without the provisioning and infrastructure
requirements that accompany surrogate addresses.
Certainly, some edge networks will continue to use provider-
independent addresses despite name-based sockets, perhaps simply due
to inertia. But name-based sockets will help reduce the number of
those networks, and thus have a positive impact on Internet routing
A more comprehensive description of name-based sockets can be found
Name-based sockets contribution to the routing scalability problem is
to decrease the reliance on PI addresses, allowing a greater use of
PA addresses, and thus a less fragmented routing table. It provides
end hosts with an API which makes the applications address-agnostic.
The name abstraction allows the hosts to use any type of locator,
independent of format or provider. This increases the motivation and
usability of PA addresses. Some applications, in particular
bootstrapping applications, may still require hard coded IP
addresses, and as such will still motivate the use of PI addresses.
The main incentives and drivers are geared towards the transition of
applications to the name-based sockets. Adoption by applications
will be driven by benefits in terms of reduced application
development cost. Legacy applications are expected to migrate to the
new API at a slower pace, as the name-based sockets are backwards
compatible, this can happen in a per-host fashion. Also, not all
applications can be ported to a FQDN dependent infrastructure, e.g.,
DNS functions. This hurdle is manageable, and may not be a definite
obstacle for the transition of a whole domain, but it needs to be
taken into account when striving for mobility/multihoming of an
entire site. The transition of functions on individual hosts may be
trivial, either through upgrades/changes to the OS or as linked
libraries. This can still happen incrementally and independently, as
compatibility is not affected by the use of name-based sockets.
Name-based sockets rely on the transition of individual applications
and are backwards compatible, so they do not require bilateral
upgrades. This allows each host to migrate its applications
independently. Name-based sockets may make an individual client
agnostic to the networking medium, be it PA/PI IP-addresses or in a
the future an entirely different networking medium. However, an
entire edge-network, with internal and external services will not be
able to make a complete transition in the near future. Hence, even
if a substantial fraction of the hosts in an edge-network use name-
based sockets, PI addresses may still be required by the edge-
network. In short, new services may be implemented using name-based
sockets, old services may be ported. Name-based sockets provide an
increased motivation to move to PA-addresses as actual provider
independence relies less and less on PI-addressing.
No rebuttal was submitted for this proposal.
16. Routing and Addressing in Networks with Global Enterprise Recursion
RANGER is a locator/identifier separation approach that uses IP-in-IP
encapsulation to connect edge networks across transit networks such
as the global Internet. End systems use endpoint interface
identifier (EID) addresses that may be routable within edge networks
but do not appear in transit network routing tables. EID to Routing
Locator (RLOC) address bindings are instead maintained in mapping
tables and also cached in default router FIBs (i.e., very much the
same as for the global DNS and its associated caching resolvers).
RANGER enterprise networks are organized in a recursive hierarchy
with default mappers connecting lower layers to the next higher layer
in the hierarchy. Default mappers forward initial packets and push
mapping information to lower-tier routers and end systems through
RANGER is an architectural framework derived from the Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP).
o provides a scalable routing system alternative in instances where
dynamic routing protocols are impractical
o naturally supports a recursively-nested "network-of-networks" (or,
o uses asymmetric security mechanisms (i.e., secure neighbor
discovery) to secure router discovery and the redirection
o can quickly detect path failures and pick alternate routes
o naturally supports provider-independent addressing
o support for site multihoming and traffic engineering
o ingress filtering for multihomed sites
o mobility-agile through explicit cache invalidation (much more
reactive than dynamic DNS)
o supports neighbor discovery and neighbor unreachability detection
o no changes to end systems
o no changes to most routers
o supports IPv6 transition
o compatible with true identity/locator split mechanisms such as HIP
(i.e., packets contain a HIP Host Identity Tag (HIT) as an end
system identifier, IPv6 address as endpoint interface identifier
(EID) in the inner IP header and IPv4 address as Routing LOCator
(RLOC) in the outer IP header)
o prototype code available
o new code needed in enterprise border routers
o locator/path liveness detection using RFC 4861 neighbor
unreachability detection (i.e., extra control messages, but data-
[IRON] [RANGER_Scen] [VET] [SEAL] [RFC5201] [RFC5214] [RFC5720]
The RANGER architectural framework is intended to be applicable for a
Core-Edge Separation (CES) architecture for scalable routing, using
either IPv4 or IPv6 -- or using both in an integrated system which
may carry one protocol over the other.
However, despite [IRON] being readied for publication as an
experimental RFC, the framework falls well short of the level of
detail required to envisage how it could be used to implement a
practical scalable routing solution. For instance, the document
contains no specification for a mapping protocol, or how the mapping
lookup system would work on a global scale.
There is no provision for RANGER's ITR-like routers being able to
probe the reachability of end-user networks via multiple ETR-like
routers -- nor for any other approach to multihoming service
Nor is there any provision for inbound TE or support of mobile
devices which frequently change their point of attachment.
Therefore, in its current form, RANGER cannot be contemplated as a
superior scalable routing solution to some other proposals which are
specified in sufficient detail and which appear to be feasible.
RANGER uses its own tunneling and PMTUD management protocol: SEAL.
Adoption of SEAL in its current form would prevent the proper
utilization of jumbo frame paths in the DFZ, which will become the
norm in the future. SEAL uses "Packet Too Big" [RFC4443] and
"Fragmentation Needed" [RFC0792] messages to the sending host only to
fix a preset maximum packet length. To avoid the need for the SEAL
layer to fragment packets of this length, this MTU value (for the
input of the tunnel) needs to be set significantly below 1500 bytes,
assuming the typically ~1500 byte MTU values for paths across the DFZ
today. In order to avoid this excessive fragmentation, this value
could only be raised to a ~9k byte value at some time in the future
where essentially all paths between ITRs and ETRs were jumbo frame
The Internet Routing Overlay Network (IRON) [IRON] is a scalable
Internet routing architecture that builds on the RANGER recursive
enterprise network hierarchy [RFC5720]. IRON bonds together
participating RANGER networks using VET [VET] and SEAL [SEAL] to
enable secure and scalable routing through automatic tunneling within
the Internet core. The IRON-RANGER automatic tunneling abstraction
views the entire global Internet DFZ as a virtual Non-Broadcast
Multi-Access (NBMA) link similar to ISATAP [RFC5214].
IRON-RANGER is an example of a Core-Edge Separation (CES) system.
Instead of a classical mapping database, however, IRON-RANGER uses a
hybrid combination of a proactive dynamic routing protocol for
distributing highly aggregated Virtual Prefixes (VPs) and an on-
demand data driven protocol for distributing more-specific Provider-
Independent (PI) prefixes derived from the VPs.
The IRON-RANGER hierarchy consists of recursively-nested RANGER
enterprise networks joined together by IRON routers that participate
in a global BGP instance. The IRON BGP instance is maintained
separately from the current Internet BGP Routing LOCator (RLOC)
address space (i.e., the set of all public IPv4 prefixes in the
Internet). Instead, the IRON BGP instance maintains VPs taken from
Endpoint Interface iDentifier (EID) address space, e.g., the IPv6
global unicast address space. To accommodate scaling, only O(10k) --
O(100k) VPs are allocated e.g., using /20 or shorter IPv6 prefixes.
IRON routers lease portions of their VPs as Provider-Independent (PI)
prefixes for customer equipment (CEs), thereby creating a sustainable
business model. CEs that lease PI prefixes propagate address
mapping(s) throughout their attached RANGER networks and up to VP-
owning IRON router(s) through periodic transmission of "bubbles" with
authentication and PI prefix information. Routers in RANGER networks
and IRON routers that receive and forward the bubbles securely
install PI prefixes in their FIBs, but do not inject them into the
RIB. IRON routers therefore keep track of only their customer base
via the FIB entries and keep track of only the Internet-wide VP
database in the RIB.
IRON routers propagate more-specific prefixes using secure
redirection to update router FIBs. Prefix redirection is driven by
the data plane and does not affect the control plane. Redirected
prefixes are not injected into the RIB, but rather are maintained as
FIB soft state that is purged after expiration or route failure.
Neighbor unreachability detection is used to detect failure.
Secure prefix registrations and redirections are accommodated through
the mechanisms of SEAL. Tunnel endpoints using SEAL synchronize
sequence numbers, and can therefore discard any packets they receive
that are outside of the current sequence number window. Hence, off-
path attacks are defeated. These synchronized tunnel endpoints can
therefore exchange prefixes with signed certificates that prove
prefix ownership in such a way that DoS vectors that attack crypto
calculation overhead are eliminated due to the prevention of off-path
CEs can move from old RANGER networks and re-inject their PI prefixes
into new RANGER networks. This would be accommodated by IRON-RANGER
as a site multihoming event while host mobility and true locator-ID
separation is accommodated via HIP [RFC5201].
As can be seen from the extensive list of proposals above, the group
explored a number of possible solutions. Unfortunately, the group
did not reach rough consensus on a single best approach.
Accordingly, the recommendation has been left to the co-chairs. The
remainder of this section describes the rationale and decision of the
As a reminder, the goal of the research group was to develop a
recommendation for an approach to a routing and addressing
architecture for the Internet. The primary goal of the architecture
is to provide improved scalability for the routing subsystem.
Specifically, this implies that we should be able to continue to grow
the routing subsystem to meet the needs of the Internet without
requiring drastic and continuous increases in the amount of state or
processing requirements for routers.
There is a general concern that the cost and structure of the routing
and addressing architecture as we know it today may become
prohibitively expensive with continued growth, with repercussions to
the health of the Internet. As such, there is an urgent need to
examine and evaluate potential scalability enhancements.
For the long term future of the Internet, it has become apparent that
IPv6 is going to play a significant role. It has taken more than a
decade, but IPv6 is starting to see some non-trivial amount of
deployment. This is in part due to the depletion of IPv4 addresses.
It therefore seems apparent that the new architecture must be
applicable to IPv6. It may or may not be applicable to IPv4, but not
addressing the IPv6 portion of the network would simply lead to
recreating the routing scalability problem in the IPv6 domain,
because the two share a common routing architecture.
Whatever change we make, we should expect that this is a very long-
lived change. The routing architecture of the entire Internet is a
loosely coordinated, complex, expensive subsystem, and permanent,
pervasive changes to it will require difficult choices during
deployment and integration. These cannot be undertaken lightly.
By extension, if we are going to the trouble, pain, and expense of
making major architectural changes, it follows that we want to make
the best changes possible. We should regard any such changes as
permanent and we should therefore aim for long term solutions that
place the network in the best possible position for ongoing growth.
These changes should be cleanly integrated, first-class citizens
within the architecture. That is to say that any new elements that
are integrated into the architecture should be fundamental
primitives, on par with the other existing legacy primitives in the
architecture, that interact naturally and logically when in
combination with other elements of the architecture.
Over the history of the Internet, we have been very good about
creating temporary, ad-hoc changes, both to the routing architecture
and other aspects of the network layer. However, many of these band-
aid solutions have come with a significant overhead in terms of long-
term maintenance and architectural complexity. This is to be avoided
and short-term improvements should eventually be replaced by long-
term, permanent solutions.
In the particular instance of the routing and addressing architecture
today, we feel that the situation requires that we pursue both short-
term improvements and long-term solutions. These are not
incompatible because we truly intend for the short-term improvements
to be completely localized and temporary. The short-term
improvements are necessary to give us the time necessary to develop,
test, and deploy the long-term solution. As the long-term solution
is rolled out and gains traction, the short-term improvements should
be of less benefit and can subsequently be withdrawn.
17.2. Recommendation to the IETF
The group explored a number of proposed solutions but did not reach
consensus on a single best approach. Therefore, in fulfillment of
the routing research group's charter, the co-chairs recommend that
the IETF pursue work in the following areas:
Identifier-Locator Network Protocol (ILNP) [ILNP_Site]
We selected Evolution because it is a short-term improvement. It can
be applied on a per-domain basis, under local administration and has
immediate effect. While there is some complexity involved, we feel
that this option is constructive for service providers who find the
additional complexity to be less painful than upgrading hardware.
This improvement can be deployed by domains that feel it necessary,
for as long as they feel it is necessary. If this deployment lasts
longer than expected, then the implications of that decision are
wholly local to the domain.
We recommended ILNP because we find it to be a clean solution for the
architecture. It separates location from identity in a clear,
straightforward way that is consistent with the remainder of the
Internet architecture and makes both first-class citizens. Unlike
the many map-and-encap proposals, there are no complications due to
tunneling, indirection, or semantics that shift over the lifetime of
a packet's delivery.
We recommend further work on automating renumbering because even with
ILNP, the ability of a domain to change its locators at minimal cost
is fundamentally necessary. No routing architecture will be able to
scale without some form of abstraction, and domains that change their
point of attachment must fundamentally be prepared to change their
locators in line with this abstraction. We recognize that [RFC5887]
is not a solution so much as a problem statement, and we are simply
recommending that the IETF create effective and convenient mechanisms
for site renumbering.
This document presents a small portion of the overall work product of
the Routing Research Group, who have developed all of these
architectural approaches and many specific proposals within this
19. Security Considerations
Space precludes a full treatment of security considerations for all
proposals summarized herein. [RFC3552] However, it was a requirement
of the research group to provide security that is at least as strong
as the existing Internet routing and addressing architecture. Each
technical proposal has slightly different security considerations,
the details of which are in many of the references cited.
20. Informative References
[CRM] Flinck, H., "Compact routing in locator identifier mapping
Liu, C. and P. Albitz, "DNS & BIND", 2006, 5th
Edition, O'Reilly & Associates, Sebastopol, CA, USA. ISBN
Sriram, K., Kim, Y., and D. Montgomery, "Enhanced
Efficiency of Mapping Distribution Protocols in Scalable
Routing and Addressing Architectures", Proceedings of the
ICCCN, Zurich, Switzerland, August 2010,
Sriram, K., Gleichmann, P., Kim, Y., and D. Montgomery,
"Enhanced Efficiency of Mapping Distribution Protocols in
Scalable Routing and Addressing Architectures", Presented
at the LISP WG meeting, IETF 78, July 2010. Originally
presented at the RRG meeting at IETF 72,
Zhang, B. and L. Zhang, "Evolution Towards Global Routing
Scalability", Work in Progress, October 2009.
Whittle, R., "DRTM - Distributed Real Time Mapping for
Ivip and LISP", Work in Progress, March 2010.
Whittle, R., "Ivip4 ETR Address Forwarding", Work
in Progress, January 2010.
Whittle, R., "Glossary of some Ivip and scalable routing
terms", Work in Progress, March 2010.
Whittle, R., "TTR Mobility Extensions for Core-Edge
Separation Solutions to the Internet's Routing Scaling
Problem", August 2008,
Whittle, R., "Prefix Label Forwarding (PLF) - Modified
Header Forwarding for IPv6",
Whittle, R., "IPTM - Ivip's approach to solving the
problems with encapsulation overhead, MTU, fragmentation
and Path MTU Discovery", January 2010,
Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the
Internet Architecture Through Naming", IEEE Journal on
Selected Areas in Communication (JSAC) 28(8),
[LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
Work in Progress, February 2010.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", Work in Progress,
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", Work in Progress,
Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an
Integrated Service through the Use of Naming", ACM
International Workshop on Mobility in the Evolving
Internet (MobiArch) 2, Kyoto, Japan, August 2007.
Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through
Naming: Impact on DNS", ACM International Workshop on
Mobility in the Evolving Internet (MobiArch) 3, Seattle,
USA, August 2008.
Vogt, C., "Simplifying Internet Applications Development
With A Name-Based Sockets Interface", December 2009, <http
Russert, S., Fleischman, E., and F. Templin, "RANGER
Scenarios", Work in Progress, July 2010.
[RANGI] Xu, X., "Routing Architecture for the Next Generation
Internet (RANGI)", Work in Progress, August 2010.
Xu, X., "Transition Mechanisms for Routing Architecture
for the Next Generation Internet (RANGI)", Work
in Progress, July 2009.
Xu, X., "Routing Architecture for the Next-Generation
Internet (RANGI)", <http://www.ietf.org/proceedings/76/
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, June 2009.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
IPv6 Network Address Translation", RFC 5902, July 2010.
Li, T., "Design Goals for Scalable Internet Routing", Work
in Progress, January 2011.