RFC 6115
Recommendation for a Routing Architecture
Pages: 73
Informational
Informational
Part 4 of 4 – Pages 56 to 73
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
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.
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.
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
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
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.
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
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.
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
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.
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.
[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/>.
[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.
[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.
[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.
[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.
[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.
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