tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6115

 
 
 

Recommendation for a Routing Architecture

Part 4 of 4, p. 56 to 73
Prev RFC Part

 


prevText      Top      Up      ToC       Page 56 
15.  Name-Based Sockets

15.1.  Summary

   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
   stack itself.

   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

Top      Up      ToC       Page 57 
   addresses with high topological significance, as well as the dynamic
   replacement of IP addresses during network-topological and host-
   attachment changes.

   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
   applications.

   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
   transition.

   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.

Top      Up      ToC       Page 58 
   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
   scalability.

   A more comprehensive description of name-based sockets can be found
   in [Name_Based_Sockets].

15.1.1.  References

   [Name_Based_Sockets]

15.2.  Critique

   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.

Top      Up      ToC       Page 59 
15.2.1.  Deployment

   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.

15.2.2.  Edge-networks

   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.

15.3.  Rebuttal

   No rebuttal was submitted for this proposal.

16.  Routing and Addressing in Networks with Global Enterprise Recursion
     (IRON-RANGER)

16.1.  Summary

   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

Top      Up      ToC       Page 60 
   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
   secure redirection.

   RANGER is an architectural framework derived from the Intra-Site
   Automatic Tunnel Addressing Protocol (ISATAP).

16.1.1.  Gains

   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,
      "enterprise-within-enterprise") hierarchy

   o  uses asymmetric security mechanisms (i.e., secure neighbor
      discovery) to secure router discovery and the redirection
      mechanism

   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
      over tunnels

   o  no changes to end systems

   o  no changes to most routers

   o  supports IPv6 transition

Top      Up      ToC       Page 61 
   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

16.1.2.  Costs

   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-
      driven) [RFC4861]

16.1.3.  References

   [IRON] [RANGER_Scen] [VET] [SEAL] [RFC5201] [RFC5214] [RFC5720]

16.2.  Critique

   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
   restoration.

   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.

Top      Up      ToC       Page 62 
   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
   capable.

16.3.  Rebuttal

   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

Top      Up      ToC       Page 63 
   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
   attacks.

   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].

17.  Recommendation

   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
   co-chairs.

   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.

Top      Up      ToC       Page 64 
17.1.  Motivation

   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

Top      Up      ToC       Page 65 
   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:

      Evolution [Evolution]

      Identifier-Locator Network Protocol (ILNP) [ILNP_Site]

      Renumbering [RFC5887]

17.3.  Rationale

   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.

Top      Up      ToC       Page 66 
18.  Acknowledgments

   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
   solution space.

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
              system", <http://www.tschofenig.priv.at/rrg/
              CR_mapping_system_0.1.pdf>.

   [DNSnBIND]
              Liu, C. and P. Albitz, "DNS & BIND", 2006, 5th
              Edition, O'Reilly & Associates, Sebastopol, CA, USA. ISBN
              0-596-10057-4.

   [EEMDP_Considerations]
              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,
              <http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf>.

   [EEMDP_Presentation]
              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,
              <http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>.

   [Evolution]
              Zhang, B. and L. Zhang, "Evolution Towards Global Routing
              Scalability", Work in Progress, October 2009.

Top      Up      ToC       Page 67 
   [Evolution_Grow_Presentation]
              Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
              L. Zhang, "Virtual Aggregation (VA)", November 2009,
              <http://www.ietf.org/proceedings/76/slides/grow-5.pdf>.

   [FIBAggregatability]
              Zhang, B., Wang, L., Zhao, X., Liu, Y., and L. Zhang, "An
              Evaluation Study of Router FIB Aggregatability",
              November 2009,
              <http://www.ietf.org/proceedings/76/slides/grow-2.pdf>.

   [GLI]      Menth, M., Hartmann, M., and D. Klein, "Global Locator,
              Local Locator, and Identifier Split (GLI-Split)",
              April 2010,
              <http://www3.informatik.uni-wuerzburg.de/TR/tr470.pdf>.

   [ILNP_DNS]
              Atkinson, R. and S. Rose, "DNS Resource Records for ILNP",
              Work in Progress, February 2011.

   [ILNP_ICMP]
              Atkinson, R., "ICMP Locator Update message", Work
              in Progress, February 2011.

   [ILNP_Intro]
              Atkinson, R., "ILNP Concept of Operations", Work
              in Progress, February 2011.

   [ILNP_Nonce]
              Atkinson, R., "ILNP Nonce Destination Option", Work
              in Progress, February 2011.

   [ILNP_Site]
              Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and
              M. Lad, "ILNP - Identifier-Locator Network Protocol",
              updated 06 January 2011,
              <http://ilnp.cs.st-andrews.ac.uk>.

   [IRON]     Templin, F., "The Internet Routing Overlay Network
              (IRON)", Work in Progress, January 2011.

   [Ivip_Constraints]
              Whittle, R., "List of constraints on a successful scalable
              routing solution which result from the need for widespread
              voluntary adoption", April 2009,
              <http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/>.

Top      Up      ToC       Page 68 
   [Ivip_DRTM]
              Whittle, R., "DRTM - Distributed Real Time Mapping for
              Ivip and LISP", Work in Progress, March 2010.

   [Ivip_EAF]
              Whittle, R., "Ivip4 ETR Address Forwarding", Work
              in Progress, January 2010.

   [Ivip_Glossary]
              Whittle, R., "Glossary of some Ivip and scalable routing
              terms", Work in Progress, March 2010.

   [Ivip_Mobility]
              Whittle, R., "TTR Mobility Extensions for Core-Edge
              Separation Solutions to the Internet's Routing Scaling
              Problem", August 2008,
              <http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.

   [Ivip_PLF]
              Whittle, R., "Prefix Label Forwarding (PLF) - Modified
              Header Forwarding for IPv6",
              <http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/>.

   [Ivip_PMTUD]
              Whittle, R., "IPTM - Ivip's approach to solving the
              problems with encapsulation overhead, MTU, fragmentation
              and Path MTU Discovery", January 2010,
              <http://www.firstpr.com.au/ip/ivip/pmtud-frag/>.

   [JSAC_Arch]
              Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the
              Internet Architecture Through Naming", IEEE Journal on
              Selected Areas in Communication (JSAC) 28(8),
              October 2010.

   [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,
              October 2010.

   [LISP+ALT]
              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", Work in Progress,
              October 2010.

Top      Up      ToC       Page 69 
   [LISP-Interworking]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6", Work in Progress,
              August 2010.

   [LISP-MN]  Meyer, D., Lewis, D., and D. Farinacci, "LISP Mobile
              Node", Work in Progress, October 2010.

   [LISP-MS]  Fuller, V. and D. Farinacci, "LISP Map Server", Work
              in Progress, October 2010.

   [LISP-TREE]
              Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
              and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support
              the LISP Mapping System", IEEE Journal on Selected Areas
              in Communications, Volume 28, Issue 8, October 2010, <http
              ://ieeexplore.ieee.org/stamp/
              stamp.jsp?tp=&arnumber=5586446>.

   [LMS]      Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A
              Layered Mapping System For Scalable Routing", <http://
              docs.google.com/
              fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN
              mFkYzBhNWJhMWEy&hl=en>.

   [LMS_Summary]
              Sun, C., "A Layered Mapping System (Summary)", <http://
              docs.google.com/
              Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en>.

   [LOC_ID_Implications]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID Separation", Work in Progress, January 2009.

   [MILCOM1]  Atkinson, R. and S. Bhatti, "Site-Controlled Secure Multi-
              homing and Traffic Engineering for IP", IEEE Military
              Communications Conference (MILCOM) 28, Boston, MA, USA,
              October 2009.

   [MILCOM2]  Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised
              Resilience, Multi-homing and Mobility Capability for IP",
              IEEE Military Communications Conference (MILCOM) 27, San
              Diego, CA, USA, November 2008.

   [MPTCP_Arch]
              Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford,
              "Architectural Guidelines for Multipath TCP Development",
              Work in Progress, February 2010.

Top      Up      ToC       Page 70 
   [MobiArch1]
              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.

   [MobiArch2]
              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.

   [Name_Based_Sockets]
              Vogt, C., "Simplifying Internet Applications Development
              With A Name-Based Sockets Interface", December 2009, <http
              ://christianvogt.mailup.net/pub/
              vogt-2009-name-based-sockets.pdf>.

   [RANGER_Scen]
              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.

   [RANGI-PROXY]
              Xu, X., "Transition Mechanisms for Routing Architecture
              for the Next Generation Internet (RANGI)", Work
              in Progress, July 2009.

   [RANGI-SLIDES]
              Xu, X., "Routing Architecture for the Next-Generation
              Internet (RANGI)", <http://www.ietf.org/proceedings/76/
              slides/RRG-1/RRG-1.htm>.

   [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,
              July 2003.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

Top      Up      ToC       Page 71 
   [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,
              September 2007.

   [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,
              March 2008.

   [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,
              February 2010.

   [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.

   [RRG_Design_Goals]
              Li, T., "Design Goals for Scalable Internet Routing", Work
              in Progress, January 2011.

Top      Up      ToC       Page 72 
   [Referral_Obj]
              Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and
              K. Moore, "A Generic Referral Object for Internet
              Entities", Work in Progress, October 2009.

   [SEAL]     Templin, F., "The Subnetwork Encapsulation and Adaptation
              Layer (SEAL)", Work in Progress, January 2011.

   [Scalability_PS]
              Narten, T., "On the Scalability of Internet Routing", Work
              in Progress, February 2010.

   [TIDR]     Adan, J., "Tunneled Inter-domain Routing (TIDR)", Work
              in Progress, December 2006.

   [TIDR_AS_forwarding]
              Adan, J., "yetAnotherProposal: AS-number forwarding",
              March 2008,
              <http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>.

   [TIDR_and_LISP]
              Adan, J., "LISP etc architecture", December 2007,
              <http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>.

   [TIDR_identifiers]
              Adan, J., "TIDR using the IDENTIFIERS attribute",
              April 2007, <http://www.ietf.org/mail-archive/web/ram/
              current/msg01308.html>.

   [VET]      Templin, F., "Virtual Enterprise Traversal (VET)", Work
              in Progress, January 2011.

   [Valiant]  Zhang-Shen, R. and N. McKeown, "Designing a Predictable
              Internet Backbone Network", November 2004, <http://
              conferences.sigcomm.org/hotnets/2004/
              HotNets-III%20Proceedings/zhang-shen.pdf>.

   [hIPv4]    Frejborg, P., "Hierarchical IPv4 Framework", Work
              in Progress, October 2010.

Top      Up      ToC       Page 73 
Author's Address

   Tony Li (editor)
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA  95134
   USA

   Phone: +1 408 853 9317
   EMail: tony.li@tony.li