From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5558.txt | 2019 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2019 insertions(+) create mode 100644 doc/rfc/rfc5558.txt (limited to 'doc/rfc/rfc5558.txt') diff --git a/doc/rfc/rfc5558.txt b/doc/rfc/rfc5558.txt new file mode 100644 index 0000000..68c4426 --- /dev/null +++ b/doc/rfc/rfc5558.txt @@ -0,0 +1,2019 @@ + + + + + + +Independent Submission F. Templin, Ed. +Request for Comments: 5558 Boeing Research & Technology +Category: Informational February 2010 +ISSN: 2070-1721 + + + Virtual Enterprise Traversal (VET) + +Abstract + + Enterprise networks connect routers over various link types, and may + also connect to provider networks and/or the global Internet. + Enterprise network nodes require a means to automatically provision + IP addresses/prefixes and support internetworking operation in a wide + variety of use cases including Small Office, Home Office (SOHO) + networks, Mobile Ad hoc Networks (MANETs), multi-organizational + corporate networks and the interdomain core of the global Internet + itself. This document specifies a Virtual Enterprise Traversal (VET) + abstraction for autoconfiguration and operation of nodes in + enterprise networks. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5558. + + + + + + + + + + + + + + + +Templin Informational [Page 1] + +RFC 5558 VET February 2010 + + +IESG Note + + This RFC is not a candidate for any level of Internet Standard. The + IETF disclaims any knowledge of the fitness of this RFC for any + purpose and in particular notes that the decision to publish is not + based on IETF review for such things as security, congestion control, + or inappropriate interaction with deployed protocols. The RFC Editor + has chosen to publish this document at its discretion. Readers of + this RFC should exercise caution in evaluating its value for + implementation and deployment. See RFC 3932 for more information. + + Note that the IETF AUTOCONF Working Group is working on a similar + protocol solution that may become available in the future. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + +Templin Informational [Page 2] + +RFC 5558 VET February 2010 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................6 + 3. Enterprise Characteristics .....................................10 + 4. Autoconfiguration ..............................................11 + 4.1. Enterprise Router (ER) Autoconfiguration ..................12 + 4.2. Enterprise Border Router (EBR) Autoconfiguration ..........13 + 4.2.1. VET Interface Autoconfiguration ....................13 + 4.2.1.1. Interface Initialization ..................14 + 4.2.1.2. Enterprise Border Gateway + Discovery and Enterprise Identification ...14 + 4.2.1.3. EID Configuration .........................15 + 4.2.2. Provider-Aggregated (PA) EID Prefix + Autoconfiguration ..................................15 + 4.2.3. Provider-Independent (PI) EID Prefix + Autoconfiguration ..................................16 + 4.3. Enterprise Border Gateway (EBG) Autoconfiguration .........17 + 4.4. VET Host Autoconfiguration ................................17 + 5. Internetworking Operation ......................................18 + 5.1. Routing Protocol Participation ............................18 + 5.2. RLOC-Based Communications .................................18 + 5.3. EID-Based Communications ..................................18 + 5.4. IPv6 Router Discovery and Prefix Registration .............18 + 5.4.1. IPv6 Router and Prefix Discovery ...................18 + 5.4.2. IPv6 PA Prefix Registration ........................19 + 5.4.3. IPv6 PI Prefix Registration ........................20 + 5.4.4. IPv6 Next-Hop EBR Discovery ........................21 + 5.5. IPv4 Router Discovery and Prefix Registration .............23 + 5.6. VET Encapsulation .........................................24 + 5.7. SEAL Encapsulation ........................................24 + 5.8. Generating Errors .........................................25 + 5.9. Processing Errors .........................................25 + 5.10. Mobility and Multihoming Considerations ..................26 + 5.11. Multicast ................................................27 + 5.12. Service Discovery ........................................28 + 5.13. Enterprise Partitioning ..................................29 + 5.14. EBG Prefix State Recovery ................................29 + 6. Security Considerations ........................................30 + 7. Related Work ...................................................30 + 8. Acknowledgements ...............................................31 + 9. Contributors ...................................................31 + 10. References ....................................................31 + 10.1. Normative References .....................................31 + 10.2. Informative References ...................................33 + Appendix A. Duplicate Address Detection (DAD) Considerations .... 36 + + + + + +Templin Informational [Page 3] + +RFC 5558 VET February 2010 + + +1. Introduction + + Enterprise networks [RFC4852] connect routers over various link types + (see [RFC4861], Section 2.2). The term "enterprise network" in this + context extends to a wide variety of use cases and deployment + scenarios. For example, an "enterprise" can be as small as a SOHO + network, as complex as a multi-organizational corporation, or as + large as the global Internet itself. Mobile Ad hoc Networks (MANETs) + [RFC2501] can also be considered as a challenging example of an + enterprise network, in that their topologies may change dynamically + over time and that they may employ little/no active management by a + centralized network administrative authority. These specialized + characteristics for MANETs require careful consideration, but the + same principles apply equally to other enterprise network scenarios. + + This document specifies a Virtual Enterprise Traversal (VET) + abstraction for autoconfiguration and internetworking operation, + where addresses of different scopes may be assigned on various types + of interfaces with diverse properties. Both IPv4 [RFC0791] and IPv6 + [RFC2460] are discussed within this context. The use of standard + DHCP [RFC2131] [RFC3315] and neighbor discovery [RFC0826] [RFC1256] + [RFC4861] mechanisms is assumed unless otherwise specified. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Templin Informational [Page 4] + +RFC 5558 VET February 2010 + + + Provider-Edge Interfaces + x x x + | | | + +--------------------+---+--------+----------+ E + | | | | | n + | I | | .... | | t + | n +---+---+--------+---+ | e + | t | +--------+ /| | r + | e I x----+ | Host | I /*+------+--< p I + | r n | |Function| n|**| | r n + | n t | +--------+ t|**| | i t + | a e x----+ V e|**+------+--< s e + | l r . | E r|**| . | e r + | f . | T f|**| . | f + | V a . | +--------+ a|**| . | I a + | i c . | | Router | c|**| . | n c + | r e x----+ |Function| e \*+------+--< t e + | t s | +--------+ \| | e s + | u +---+---+--------+---+ | r + | a | | .... | | i + | l | | | | o + +--------------------+---+--------+----------+ r + | | | + x x x + Enterprise-Edge Interfaces + + Figure 1: Enterprise Router (ER) Architecture + + Figure 1 above depicts the architectural model for an Enterprise + Router (ER). As shown in the figure, an ER may have a variety of + interface types including enterprise-edge, enterprise-interior, + provider-edge, internal-virtual, as well as VET interfaces used for + IP-in-IP encapsulation. The different types of interfaces are + defined, and the autoconfiguration mechanisms used for each type are + specified. This architecture applies equally for MANET routers, in + which enterprise-interior interfaces correspond to the wireless + multihop radio interfaces typically associated with MANETs. Out of + scope for this document is the autoconfiguration of provider + interfaces, which must be coordinated in a manner specific to the + service provider's network. + + Enterprise networks must have a means for supporting both Provider- + Independent (PI) and Provider-Aggregated (PA) IP prefixes. This is + especially true for enterprise scenarios that involve mobility and + multihoming. Also in scope are ingress filtering for multihomed + sites, adaptation based on authenticated ICMP feedback from on-path + routers, effective tunnel path MTU mitigations, and routing scaling + suppression as required in many enterprise network scenarios. + + + +Templin Informational [Page 5] + +RFC 5558 VET February 2010 + + + Recognizing that one size does not fit all, the VET specification + provides adaptable mechanisms that address these issues, and more, in + a wide variety of enterprise network use cases. + + VET represents a functional superset of 6over4 [RFC2529] and Intra- + Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], and it + further supports additional encapsulations such as IPsec [RFC4301], + Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320], etc. + Together, these technologies serve as functional building blocks for + a new Internetworking architecture known as Routing and Addressing in + Networks with Global Enterprise Recursion [RFC5720][RANGERS]. + + The VET principles can be either directly or indirectly traced to the + deliberations of the ROAD group in January 1992, and also to still + earlier works including NIMROD [RFC1753], the Catenet model for + internetworking [CATENET] [IEN48] [RFC2775], etc. [RFC1955] captures + the high-level architectural aspects of the ROAD group deliberations + in a "New Scheme for Internet Routing and Addressing (ENCAPS) for + IPNG". + + VET is related to the present-day activities of the IETF AUTOCONF, + DHC, IPv6, MANET, and v6OPS working groups, as well as the IRTF RRG + working group. + +2. Terminology + + The mechanisms within this document build upon the fundamental + principles of IP-in-IP encapsulation. The terms "inner" and "outer" + are used to, respectively, refer to the innermost IP {address, + protocol, header, packet, etc.} *before* encapsulation, and the + outermost IP {address, protocol, header, packet, etc.} *after* + encapsulation. VET also allows for inclusion of "mid-layer" + encapsulations between the inner and outer layers, including IPsec + [RFC4301], the Subnetwork Encapsulation and Adaptation Layer (SEAL) + [RFC5320], etc. + + The terminology in the normative references apply; the following + terms are defined within the scope of this document: + + subnetwork + the same as defined in [RFC3819]. + + enterprise + the same as defined in [RFC4852]. An enterprise is also + understood to refer to a cooperative networked collective with a + commonality of business, social, political, etc. interests. + + + + + +Templin Informational [Page 6] + +RFC 5558 VET February 2010 + + + Minimally, the only commonality of interest in some enterprise + network scenarios may be the cooperative provisioning of + connectivity itself. + + site + a logical and/or physical grouping of interfaces that connect a + topological area less than or equal to an enterprise in scope. A + site within an enterprise can, in some sense, be considered as an + enterprise unto itself. + + Mobile Ad hoc Network (MANET) + a connected topology of mobile or fixed routers that maintain a + routing structure among themselves over dynamic links, where a + wide variety of MANETs share common properties with enterprise + networks. The characteristics of MANETs are defined in [RFC2501], + Section 3. + + enterprise/site/MANET + throughout the remainder of this document, the term "enterprise" + is used to collectively refer to any of enterprise/site/MANET, + i.e., the VET mechanisms and operational principles can be applied + to enterprises, sites, and MANETs of any size or shape. + + Enterprise Router (ER) + As depicted in Figure 1, an Enterprise Router (ER) is a fixed or + mobile router that comprises a router function, a host function, + one or more enterprise-interior interfaces, and zero or more + internal virtual, enterprise-edge, provider-edge, and VET + interfaces. At a minimum, an ER forwards outer IP packets over + one or more sets of enterprise-interior interfaces, where each set + connects to a distinct enterprise. + + Enterprise Border Router (EBR) + an ER that connects edge networks to the enterprise and/or + connects multiple enterprises together. An EBR is a tunnel + endpoint router, and it configures a separate VET interface over + each set of enterprise-interior interfaces that connect the EBR to + each distinct enterprise. In particular, an EBR may configure + multiple VET interfaces -- one for each distinct enterprise. All + EBRs are also ERs. + + Enterprise Border Gateway (EBG) + an EBR that connects VET interfaces configured over child + enterprises to a provider network -- either directly via a + provider-edge interface or indirectly via another VET interface + configured over a parent enterprise. EBRs may act as EBGs on some + VET interfaces and as ordinary EBRs on other VET interfaces. All + EBGs are also EBRs. + + + +Templin Informational [Page 7] + +RFC 5558 VET February 2010 + + + enterprise-interior interface + an ER's attachment to a link within an enterprise. Packets sent + over enterprise-interior interfaces may be forwarded over multiple + additional enterprise-interior interfaces within the enterprise + before they are forwarded via an enterprise-edge interface, + provider-edge interface, or a VET interface configured over a + different enterprise. Enterprise-interior interfaces connect + laterally within the IP network hierarchy. + + enterprise-edge interface + an EBR's attachment to a link (e.g., an Ethernet, a wireless + personal area network, etc.) on an arbitrarily complex edge + network that the EBR connects to an enterprise and/or provider + network. Enterprise-edge interfaces connect to lower levels + within the IP network hierarchy. + + provider-edge interface + an EBR's attachment to the Internet or to a provider network + outside of the enterprise via which the Internet can be reached. + Provider-edge interfaces connect to higher levels within the IP + network hierarchy. + + internal-virtual interface + an interface that is internal to an EBR and does not in itself + directly attach to a tangible physical link, e.g., an Ethernet + cable. Examples include a loopback interface, a virtual LAN + interface, or some form of tunnel interface. + + Virtual Enterprise Traversal (VET) + an abstraction that uses IP-in-IP encapsulation to create an + overlay that spans an enterprise in a single (inner) IP hop. + + VET interface + an EBR's tunnel virtual interface used for Virtual Enterprise + Traversal. The EBR configures a VET interface over a set of + underlying interfaces belonging to the same enterprise. When + there are multiple distinct enterprises (each with their own + distinct set of underlying interfaces), the EBR configures a + separate VET interface over each set of underlying interfaces, + i.e., the EBR configures multiple VET interfaces. + + The VET interface encapsulates each inner IP packet in any mid- + layer headers plus an outer IP header, then it forwards it on an + underlying interface such that the Time to Live (TTL) / Hop Limit + in the inner header is not decremented as the packet traverses the + enterprise. The VET interface therefore presents an automatic + tunneling abstraction that represents the enterprise as a single + IP hop. + + + +Templin Informational [Page 8] + +RFC 5558 VET February 2010 + + + VET interfaces in non-multicast environments are Non-Broadcast, + Multiple Access (NBMA); VET interfaces in multicast environments + are multicast capable. + + VET host + any node (host or router) that configures a VET interface for host + operation only. Note that a single node may configure some of its + VET interfaces as host interfaces and others as router interfaces. + + VET node + any node that configures and uses a VET interface. + + Provider-Independent (PI) prefix + an IPv6 or IPv4 prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) + that is either self-generated by an ER or delegated to an + enterprise by a registry. + + Provider Aggregated (PA) prefix + an IPv6 or IPv4 prefix that is delegated to an enterprise by a + provider network. + + Routing Locator (RLOC) + a non-link-local IPv4 or IPv6 address taken from a PI/PA prefix + that can appear in enterprise-interior and/or interdomain routing + tables. Global-scope RLOC prefixes are delegated to specific + enterprises and are routable within both the enterprise-interior + and interdomain routing regions. Enterprise-local-scope RLOC + prefixes (e.g., IPv6 Unique Local Addresses [RFC4193], IPv4 + privacy addresses [RFC1918], etc.) are self-generated by + individual enterprises and routable only within the enterprise- + interior routing region. + + ERs use RLOCs for operating the enterprise-interior routing + protocol and for next-hop determination in forwarding packets + addressed to other RLOCs. End systems use RLOCs as addresses for + communications between endpoints within the same enterprise. VET + interfaces treat RLOCs as *outer* IP addresses during IP-in-IP + encapsulation. + + Endpoint Interface iDentifier (EID) + an IPv4 or IPv6 address taken from a PI/PA prefix that is routable + within an enterprise-edge or VET overlay network scope, and may + also appear in enterprise-interior and/or interdomain mapping + tables. EID prefixes are typically separate and distinct from any + RLOC prefix space. + + + + + + +Templin Informational [Page 9] + +RFC 5558 VET February 2010 + + + Edge network routers use EIDs for operating the enterprise-edge or + VET overlay network routing protocol and for next-hop + determination in forwarding packets addressed to other EIDs. End + systems use EIDs as addresses for communications between endpoints + either within the same enterprise or within different enterprises. + VET interfaces treat EIDs as *inner* IP addresses during IP-in-IP + encapsulation. + + The following additional acronyms are used throughout the document: + + CGA - Cryptographically Generated Address + DHCP(v4, v6) - Dynamic Host Configuration Protocol + FIB - Forwarding Information Base + ISATAP - Intra-Site Automatic Tunnel Addressing Protocol + NBMA - Non-Broadcast, Multiple Access + ND - Neighbor Discovery + PIO - Prefix Information Option + PRL - Potential Router List + PRLNAME - Identifying name for the PRL (default is "isatap") + RIO - Route Information Option + RS/RA - IPv6 ND Router Solicitation/Advertisement + SEAL - Subnetwork Encapsulation and Adaptation Layer + SLAAC - IPv6 StateLess Address AutoConfiguation + +3. Enterprise Characteristics + + Enterprises consist of links that are connected by Enterprise Routers + (ERs) as depicted in Figure 1. ERs typically participate in a + routing protocol over enterprise-interior interfaces to discover + routes that may include multiple Layer 2 or Layer 3 forwarding hops. + Enterprise Border Routers (EBRs) are ERs that connect edge networks + to the enterprise and/or join multiple enterprises together. + Enterprise Border Gateways (EBGs) are EBRs that either directly or + indirectly connect enterprises to provider networks. + + An enterprise may be as simple as a small collection of ERs and their + attached edge networks; an enterprise may also contain other + enterprises and/or be a subnetwork of a larger enterprise. An + enterprise may further encompass a set of branch offices and/or + nomadic hosts connected to a home office over one or several service + providers, e.g., through Virtual Private Network (VPN) tunnels. + + Enterprises that comprise link types with sufficiently similar + properties (e.g., Layer 2 (L2) address formats, maximum transmission + units (MTUs), etc.) can configure a sub-IP layer routing service such + that IP sees the enterprise as an ordinary shared link the same as + for a (bridged) campus LAN. In that case, a single IP hop is + sufficient to traverse the enterprise without IP layer encapsulation. + + + +Templin Informational [Page 10] + +RFC 5558 VET February 2010 + + + Enterprises that comprise link types with diverse properties and/or + configure multiple IP subnets must also provide a routing service + that operates as an IP layer mechanism. In that case, multiple IP + hops may be necessary to traverse the enterprise such that care must + be taken to avoid multi-link subnet issues [RFC4903]. + + Conceptually, an ER embodies both a host function and router + function. The host function supports Endpoint Interface iDentifier + (EID)-based and/or Routing LOCator (RLOC)-based communications + according to the weak end-system model [RFC1122]. The router + function engages in the enterprise-interior routing protocol, + connects any of the ER's edge networks to the enterprise, and may + also connect the enterprise to provider networks (see Figure 1). + + In addition to other interface types, VET nodes configure VET + interfaces that view all other VET nodes in an enterprise as single- + hop neighbors attached to a virtual link. VET nodes configure a + separate VET interface for each distinct enterprise to which they + connect, and discover other EBRs on each VET interface that can be + used for forwarding packets to off-enterprise destinations. + + For each distinct enterprise, an enterprise trust basis must be + established and consistently applied. For example, in enterprises in + which EBRs establish symmetric security associations, mechanisms such + as IPsec [RFC4301] can be used to assure authentication and + confidentiality. In other enterprise network scenarios, asymmetric + securing mechanisms such as SEcure Neighbor Discovery (SEND) + [RFC3971] may be necessary to authenticate exchanges based on trust + anchors. + + Finally, in enterprises with a centralized management structure + (e.g., a corporate campus network), the enterprise name service and a + synchronized set of EBGs can provide infrastructure support for + virtual enterprise traversal. In that case, the EBGs can provide a + "default mapper" [APT] service used for short-term packet forwarding + until EBR neighbor relationships can be established. In enterprises + with a distributed management structure (e.g., MANETs), peer-to-peer + coordination between the EBRs themselves may be required. + Recognizing that various use cases will entail a continuum between a + fully distributed and fully centralized approach, the following + sections present the mechanisms of Virtual Enterprise Traversal as + they apply to a wide variety of scenarios. + +4. Autoconfiguration + + ERs, EBRs, EBGs, and VET hosts configure themselves for operation as + specified in the following subsections. + + + + +Templin Informational [Page 11] + +RFC 5558 VET February 2010 + + +4.1. Enterprise Router (ER) Autoconfiguration + + ERs configure enterprise-interior interfaces and engage in any + routing protocols over those interfaces. + + When an ER joins an enterprise, it first configures a unique IPv6 + link-local address on each enterprise-interior interface and + configures an IPv4 link-local address on each enterprise-interior + interface that requires an IPv4 link-local capability. IPv6 link- + local address generation mechanisms that provide sufficient + uniqueness include Cryptographically Generated Addresses (CGAs) + [RFC3972], IPv6 Privacy Addresses [RFC4941], StateLess Address + AutoConfiguration (SLAAC) using EUI-64 interface identifiers + [RFC4291] [RFC4862], etc. The mechanisms specified in [RFC3927] + provide an IPv4 link-local address generation capability. + + Next, the ER configures an RLOC on each of its enterprise-interior + interfaces and engages in any routing protocols on those interfaces. + The ER can configure an RLOC via explicit management, DHCP + autoconfiguration, pseudo-random self-generation from a suitably + large address pool, or through an alternate autoconfiguration + mechanism. + + Alternatively (or in addition), the ER can request RLOC prefix + delegations via an automated prefix delegation exchange over an + enterprise-interior interface and can assign the prefix(es) on + enterprise-edge interfaces. In that case, the ER can use an RLOC + assigned to an enterprise-edge interface for enterprise-interior + routing protocol operation and next-hop determination purposes. Note + that in some cases, the same enterprise-edge interfaces may assign + both RLOC and an EID addresses if there is a means for source address + selection. In other cases (e.g., for separation of security + domains), RLOCs and EIDs must be assigned on separate sets of + enterprise-edge interfaces. + + Self-generation of RLOCs for IPv6 can be from a large IPv6 local-use + address range, e.g., IPv6 Unique Local Addresses [RFC4193]. Self- + generation of RLOCs for IPv4 can be from a large IPv4 private address + range (e.g., [RFC1918]). When self-generation is used alone, the ER + must continuously monitor the RLOCs for uniqueness, e.g., by + monitoring the routing protocol. + + DHCP generation of RLOCs may require support from relays within the + enterprise. For DHCPv6, relays that do not already know the RLOC of + a server within the enterprise forward requests to the + 'All_DHCP_Servers' site-scoped IPv6 multicast group [RFC3315]. For + DHCPv4, relays that do not already know the RLOC of a server within + the enterprise forward requests to the site-scoped IPv4 multicast + + + +Templin Informational [Page 12] + +RFC 5558 VET February 2010 + + + group address 'All_DHCPv4_Servers', which should be set to + 239.255.2.1 unless an alternate multicast group for the site is + known. DHCPv4 servers that delegate RLOCs should therefore join the + 'All_DHCPv4_Servers' multicast group and service any DHCPv4 messages + received for that group. + + A combined approach using both DHCP and self-generation is also + possible when the ER configures both a DHCP client and relay that are + connected, e.g., via a pair of back-to-back connected Ethernet + interfaces, a tun/tap interface, a loopback interface, inter-process + communication, etc. The ER first self-generates a temporary RLOC + used only for the purpose of procuring an actual RLOC taken from a + disjoint addressing range. The ER then engages in the routing + protocol and performs a DHCP client/relay exchange using the + temporary RLOC as the address of the relay. When the DHCP server + delegates an actual RLOC address/prefix, the ER abandons the + temporary RLOC and re-engages in the routing protocol using an RLOC + taken from the delegation. + + In some enterprise use cases (e.g., MANETs), assignment of RLOCs on + enterprise-interior interfaces as singleton addresses (i.e., as + addresses with /32 prefix lengths for IPv4, and as addresses with + /128 prefix lengths for IPv6) may be necessary to avoid multi-link + subnet issues. + +4.2. Enterprise Border Router (EBR) Autoconfiguration + + EBRs are ERs that configure VET interfaces over distinct sets of + underlying interfaces belonging to the same enterprise; an EBR can + connect to multiple enterprises, in which case it would configure + multiple VET interfaces. In addition to the ER autoconfiguration + procedures specified in Section 4.1, EBRs perform the following + autoconfiguration operations. + +4.2.1. VET Interface Autoconfiguration + + VET interface autoconfiguration entails: + + 1) interface initialization, + 2) EBG discovery and enterprise identification, and + 3) EID configuration. + + These functions are specified in the following sections. + + + + + + + + +Templin Informational [Page 13] + +RFC 5558 VET February 2010 + + +4.2.1.1. Interface Initialization + + EBRs configure a VET interface over a set of underlying interfaces + belonging to the same enterprise, where the VET interface presents a + virtual-link abstraction in which all EBRs in the enterprise appear + as single-hop neighbors through the use of IP-in-IP encapsulation. + After the EBR configures a VET interface, it initializes the + interface and assigns an IPv6 link-local address and an IPv4 link- + local address if necessary. + + When IPv6 and IPv4 are used as the inner/outer protocols + (respectively), the EBR autoconfigures an ISATAP link-local address + ([RFC5214], Section 6.2) on the VET interface to support packet + forwarding and operation of the IPv6 neighbor discovery protocol. + The ISATAP link-local address embeds an IPv4 RLOC, and need not be + checked for uniqueness since the IPv4 RLOC itself is managed for + uniqueness (see Section 4.1). + + Link-local address configuration for other inner/outer IP protocol + combinations is through administrative configuration or through an + unspecified alternate method. Link-local address configuration for + other inner/outer IP protocol combinations may not be necessary if an + EID can be configured through other means (see Section 4.2.1.3). + + After the EBR initializes a VET interface, it can communicate with + other VET nodes as single-hop neighbors on the VET interface from the + viewpoint of the inner IP protocol. + +4.2.1.2. Enterprise Border Gateway Discovery and Enterprise + Identification + + The EBR next discovers a list of EBGs for each of its VET interfaces. + The list can be discovered through information conveyed in the + routing protocol, through the Potential Router List (PRL) discovery + mechanisms outlined in Section 8.3.2 of [RFC5214], through DHCP + options, etc. In multicast-capable enterprises, EBRs can also listen + for advertisements on the 'rasadv' [RASADV] multicast group address. + + In particular, whether or not routing information is available, the + EBR can discover the list of EBGs by resolving an identifying name + for the PRL ('PRLNAME') formed as 'hostname.domainname', where + 'hostname' is an enterprise-specific name string and 'domainname' is + an enterprise-specific DNS suffix. The EBR discovers 'PRLNAME' + through manual configuration, a DHCP option, 'rasadv' protocol + advertisements, link-layer information (e.g., an IEEE 802.11 Service + Set Identifier (SSID)), or through some other means specific to the + enterprise. In the absence of other information, the EBR sets the + + + + +Templin Informational [Page 14] + +RFC 5558 VET February 2010 + + + 'hostname' component of 'PRLNAME' to "isatap" and sets the + 'domainname' component only if an enterprise-specific DNS suffix + "example.com" is known (e.g., as "isatap.example.com"). + + The global Internet interdomain routing core represents a specific + example of an enterprise network scenario, albeit on an enormous + scale. The 'PRLNAME' assigned to the global Internet interdomain + routing core is "isatap.net". + + After discovering 'PRLNAME', the EBR can discover the list of EBGs by + resolving 'PRLNAME' to a list of RLOC addresses through a name + service lookup. For centrally managed enterprises, the EBR resolves + 'PRLNAME' using an enterprise-local name service (e.g., the + enterprise-local DNS). For enterprises with a distributed management + structure, the EBR resolves 'PRLNAME' using Link-Local Multicast Name + Resolution (LLMNR) [RFC4795] over the VET interface. In that case, + all EBGs in the PRL respond to the LLMNR query, and the EBR accepts + the union of all responses. + + Each distinct enterprise must have a unique identity that EBRs can + use to uniquely discern their enterprise affiliations. 'PRLNAME' as + well as the RLOCs of EBGs and the IP prefixes they aggregate serve as + an identifier for the enterprise. + +4.2.1.3. EID Configuration + + After EBG discovery, the EBR configures EIDs on its VET interfaces. + When IPv6 and IPv4 are used as the inner/outer protocols + (respectively), the EBR autoconfigures EIDs as specified in Section + 5.4.1. In particular, the EBR acts as a host on its VET interfaces + for router and prefix discovery purposes but acts as a router on its + VET interfaces for routing protocol operation and packet forwarding + purposes. + + EID configuration for other inner/outer IP protocol combinations is + through administrative configuration or through an unspecified + alternate method; in some cases, such EID configuration can be + performed independently of EBG discovery. + +4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration + + EBRs can acquire Provider-Aggregated (PA) EID prefixes through + autoconfiguration exchanges with EBGs over VET interfaces, where each + EBG may be configured as either a DHCP relay or DHCP server. + + For IPv4 EIDs, the EBR acquires prefixes via an automated IPv4 prefix + delegation exchange, explicit management, etc. + + + + +Templin Informational [Page 15] + +RFC 5558 VET February 2010 + + + For IPv6 EIDs, the EBR acquires prefixes via DHCPv6 Prefix Delegation + exchanges. In particular, the EBR (acting as a requesting router) + can use DHCPv6 prefix delegation [RFC3633] over the VET interface to + obtain IPv6 EID prefixes from the server (acting as a delegating + router). + + The EBR obtains prefixes using either a 2-message or 4-message DHCPv6 + exchange [RFC3315]. For example, to perform the 2-message exchange, + the EBR's DHCPv6 client forwards a Solicit message with an IA_PD + option to its DHCPv6 relay, i.e., the EBR acts as a combined client/ + relay (see Section 4.1). The relay then forwards the message over + the VET interface to an EBG, which either services the request or + relays it further. The forwarded Solicit message will elicit a reply + from the server containing PA IPv6 prefix delegations. + + The EBR can propose a specific prefix to the DHCPv6 server per + Section 7 of [RFC3633], e.g., if a prefix delegation hint is + available. The server will check the proposed prefix for consistency + and uniqueness, then return it in the reply to the EBR if it was able + to perform the delegation. + + After the EBR receives PA prefix delegations, it can provision the + prefixes on enterprise-edge interfaces as well as on other VET + interfaces for which it is configured as an EBG. It can also + provision the prefixes on enterprise-interior interfaces as long as + other nodes on those interfaces unambiguously associate the prefixes + with the EBR. + +4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration + + Independent of any PA prefixes, EBRs can acquire and use Provider- + Independent (PI) EID prefixes that are self-configured (e.g., using + [RFC4193], etc.) and/or delegated by a registration authority (e.g., + using [CENTRL-ULA], etc.). When an EBR acquires a PI prefix, it must + also obtain credentials that it can use to prove prefix ownership + when it registers the prefixes with EBGs within an enterprise (see + Sections 5.4 and 5.5). + + After the EBR receives PI prefix delegations, it can provision the + prefixes on enterprise-edge interfaces as well as on other VET + interfaces for which it is configured as an EBG. It can also + provision the prefixes on enterprise-interior interfaces as long as + other nodes on those interfaces can unambiguously associate the + prefixes with the EBR. + + The minimum-sized IPv6 PI prefix that an EBR may acquire is a /56. + + The minimum-sized IPv4 PI prefix that an EBR may acquire is a /24. + + + +Templin Informational [Page 16] + +RFC 5558 VET February 2010 + + +4.3. Enterprise Border Gateway (EBG) Autoconfiguration + + EBGs are EBRs that connect child enterprises to provider networks via + provider-edge interfaces and/or via VET interfaces configured over + parent enterprises. EBGs autoconfigure their provider-edge + interfaces in a manner that is specific to the provider connections, + and they autoconfigure their VET interfaces that were configured over + parent enterprises, using the EBR autoconfiguration procedures + specified in Section 4.2. + + For each of its VET interfaces configured over a child enterprise, + the EBG initializes the interface and configures an EID the same as + for an ordinary EBR (see Section 4.2.1). It must then arrange to add + one or more of its RLOCs associated with the child enterprise to the + PRL, and it must maintain these resource records in accordance with + [RFC5214], Section 9. In particular, for each VET interface + configured over a child enterprise, the EBG adds the RLOCs to name- + service resource records for 'PRLNAME'. + + EBGs respond to LLMNR queries for 'PRLNAME' on VET interfaces + configured over child enterprises with a distributed management + structure. + + EBGs configure a DHCP relay/server on VET interfaces configured over + child enterprises that require DHCP services. + + To avoid looping, EBGs must not configure a default route on a VET + interface configured over a child interface. + +4.4. VET Host Autoconfiguration + + Nodes that cannot be attached via an EBR's enterprise-edge interface + (e.g., nomadic laptops that connect to a home office via a Virtual + Private Network (VPN)) can instead be configured for operation as a + simple host connected to the VET interface. Such VET hosts perform + the same VET interface autoconfiguration procedures as specified for + EBRs in Section 4.2.1, but they configure their VET interfaces as + host interfaces (and not router interfaces). VET hosts can then send + packets to the EID addresses of other hosts on the VET interface, or + to off-enterprise EID destinations via a next-hop EBR. + + Note that a node may be configured as a host on some VET interfaces + and as an EBR/EBG on other VET interfaces. + + + + + + + + +Templin Informational [Page 17] + +RFC 5558 VET February 2010 + + +5. Internetworking Operation + + Following the autoconfiguration procedures specified in Section 4, + ERs, EBRs, EBGs, and VET hosts engage in normal internetworking + operations as discussed in the following sections. + +5.1. Routing Protocol Participation + + Following autoconfiguration, ERs engage in any RLOC-based IP routing + protocols and forward IP packets with RLOC addresses. EBRs can + additionally engage in any EID-based IP routing protocols and forward + IP packets with EID addresses. Note that the EID-based IP routing + domains are separate and distinct from any RLOC-based IP routing + domains. + +5.2. RLOC-Based Communications + + When permitted by policy and supported by routing, end systems can + avoid VET interface encapsulation through communications that + directly invoke the outer IP protocol using RLOC addresses instead of + EID addresses. End systems can use source address selection rules to + determine whether to use EID or RLOC addresses based on, e.g., name- + service records. + +5.3. EID-Based Communications + + In many enterprise scenarios, the use of EID-based communications + (i.e., instead of RLOC-based communications) may be necessary and/or + beneficial to support address scaling, NAT avoidance, security domain + separation, site multihoming, traffic engineering, etc. + + The remainder of this section discusses internetworking operation for + EID-based communications using the VET interface abstraction. + +5.4. IPv6 Router Discovery and Prefix Registration + + The following sections discuss router and prefix discovery + considerations for the case of IPv6 as the inner IP protocol. + +5.4.1. IPv6 Router and Prefix Discovery + + EBGs follow the router and prefix discovery procedures specified in + [RFC5214], Section 8.2. They send solicited RAs over VET interfaces + for which they are configured as gateways with default router + lifetimes, with PIOs that contain PA prefixes for SLAAC, and with any + other required options/parameters. The RAs can also include PIOs + with the 'L' bit set to 0 and with a prefix such as '2001: DB8::/48' + + + + +Templin Informational [Page 18] + +RFC 5558 VET February 2010 + + + as a hint of an aggregated prefix from which the EBG is willing to + delegate longer PA prefixes. When PIOs that contain PA prefixes for + SLAAC are included, the 'M' flag in the RA should also be set to 0. + + VET nodes follow the router and prefix discovery procedures specified + in [RFC5214], Section 8.3. They discover EBGs within the enterprise + as specified in Section 4.2.1.2, then perform RS/RA exchanges with + the EBGs to establish and maintain default routes. In particular, + the VET node sends unicast RS messages to EBGs over its VET + interface(s) to receive RAs. Depending on the enterprise network + trust basis, VET nodes may be required to use SEND to secure the + RS/RA exchanges. + + When the VET node receives an RA, it authenticates the message, then + configures a default route based on the Router Lifetime. If the RA + contains Prefix Information Options (PIOs) with the 'A' and 'L' bits + set to 1, the VET node also autoconfigures IPv6 addresses from the + advertised prefixes using SLAAC and assigns them to the VET + interface. Thereafter, the VET node accepts packets that are + forwarded by EBGs for which it has current default routing + information (i.e., ingress filtering is based on the default router + trust relationship rather than a prefix-specific ingress filter + entry). + + In enterprises in which DHCPv6 is preferred, DHCPv6 exchanges between + EBRs and EBGs may be sufficient to convey default router and prefix + information. In that case, RS/RA exchanges may not be necessary. + +5.4.2. IPv6 PA Prefix Registration + + After an EBR discovers default routes, it can use DHCP prefix + delegation to obtain PA prefixes via an EBG as specified in Section + 4.2.2. The DHCP server ensures that the delegations are unique and + that the EBG's router function will forward IP packets over the VET + interface to the correct EBR. In particular, the EBG must register + and track the PA prefixes that are delegated to each EBR. + + The PA prefix registrations remain active in the EBGs as long as the + EBR continues to issue DHCP renewals over the VET interface before + lease lifetimes expire. The lease lifetime also keeps the delegation + state active even if communications between the EBR and DHCP server + are disrupted for a period of time (e.g., due to an enterprise + network partition) before being reestablished (e.g., due to an + enterprise network merge). + + + + + + + +Templin Informational [Page 19] + +RFC 5558 VET February 2010 + + +5.4.3. IPv6 PI Prefix Registration + + After an EBR discovers default routes, it must register its PI + prefixes by sending RAs to a set of one or more EBGs with Route + Information Options (RIOs) [RFC4191] that contain the EBR's PI + prefixes. Each RA must include the RLOC of an EBG as the outer IP + destination address and a link-local address assigned to the VET + interface as the inner IP destination address. For enterprises that + use SEND, the RAs also include a CGA link-local inner source address, + SEND credentials, plus any certificates needed to prove ownership of + the PI prefixes. The EBR additionally tracks the set of EBGs to + which it sends RAs so that it can send subsequent RAs to the same + set. + + When the EBG receives the RA, it first authenticates the message; if + the authentication fails, the EBG discards the RA. Otherwise, the + EBG installs the PI prefixes with their respective lifetimes in its + Forwarding Information Base (FIB) and configures them for both + ingress filtering [RFC3704] and forwarding purposes. In particular, + the EBG configures the FIB entries as ingress filter rules to accept + packets received on the VET interface that have a source address + taken from the PI prefixes. It also configures the FIB entries to + forward packets received on other interfaces with a destination + address taken from the PI prefixes to the EBR that registered the + prefixes on the VET interface. + + The EBG then publishes the PI prefixes in a distributed database + (e.g., in a private instance of a routing protocol in which only EBGs + participate, via an automated name-service update mechanism + [RFC3007], etc.). For enterprises that are managed under a + centralized administrative authority, the EBG also publishes the PI + prefixes in the enterprise-local name-service (e.g., the enterprise- + local DNS [RFC1035]). + + In particular, the EBG publishes each /56 prefix taken from the PI + prefixes as a separate Fully Qualified Domain Name (FQDN) that + consists of a sequence of 14 nibbles in reverse order (i.e., the same + as in [RFC3596], Section 2.5) followed by the string 'ip6' followed + by the string 'PRLNAME'. For example, when 'PRLNAME' is + "isatap.example.com", the EBG publishes the prefix '2001:DB8::/56' + as: + + '0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. + + The EBG includes the outer RLOC source address of the RA (e.g., in a + DNS A resource record) in each prefix publication. For enterprises + that use SEND, the EBG also includes the inner IPv6 CGA source + address (e.g., in a DNS AAAA record) in each prefix publication. If + + + +Templin Informational [Page 20] + +RFC 5558 VET February 2010 + + + the prefix was already installed in the distributed database, the EBG + instead adds the outer RLOC source address (e.g., in an additional + DNS A record) to the preexisting publication to support PI prefixes + that are multihomed. For enterprises that use SEND, this latter + provision requires all EBRs of a multihomed site that advertise the + same PI prefixes in RAs to use the same CGA and the same SEND + credentials. + + After the EBG authenticates the RA and publishes the PI prefixes, it + next acts as a Neighbor Discovery proxy (NDProxy) [RFC4389] on the + VET interfaces configured over any of its parent enterprises, and it + relays a proxied RA to the EBGs on those interfaces. (For + enterprises that use SEND, the EBG additionally acts as a SEcure + Neighbor Discovery Proxy (SENDProxy) [SEND-PROXY].) EBGs in parent + enterprises that receive the proxied RAs in turn act as + NDProxys/SENDProxys to relay the RAs to EBGs on their parent + enterprises, etc. The RA proxying and PI prefix publication recurses + in this fashion and ends when an EBR attached to an interdomain + routing core is reached. + + After the initial PI prefix registration, the EBR that owns the + prefix(es) must periodically send additional RAs to its set of EBGs + to refresh prefix lifetimes. Each such EBG tracks the set of EBGs in + parent enterprises to which it relays the proxied RAs, and should + relay subsequent RAs to the same set. + + This procedure has a direct analogy in the Teredo method of + maintaining state in network middleboxes through the periodic + transmission of "bubbles" [RFC4380]. + +5.4.4. IPv6 Next-Hop EBR Discovery + + VET nodes discover destination-specific next-hop EBRs within the + enterprise by querying the name service for the /56 IPv6 PI prefix + taken from a packet's destination address, by forwarding packets via + a default route to an EBG, or by some other inner-IP-to-outer-IP + address mapping mechanism. For example, for the IPv6 destination + address '2001:DB8:1:2::1' and 'PRLNAME' "isatap.example.com" the VET + node can lookup the domain name: + + '0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.isatap.example.com'. + + If the name-service lookup succeeds, it will return RLOC addresses + (e.g., in DNS A records) that correspond to next-hop EBRs to which + the VET node can forward packets. (In enterprises that use SEND, it + will also return an IPv6 CGA address, e.g., in a DNS AAAA record.) + + + + + +Templin Informational [Page 21] + +RFC 5558 VET February 2010 + + + Name-service lookups in enterprises with a centralized management + structure use an infrastructure-based service, e.g., an enterprise- + local DNS. Name-service lookups in enterprises with a distributed + management structure and/or that lack an infrastructure-based name- + service instead use LLMNR over the VET interface. When LLMNR is + used, the EBR that performs the lookup sends an LLMNR query (with the + /56 prefix taken from the IP destination address encoded in dotted- + nibble format as shown above) and accepts the union of all replies it + receives from other EBRs on the VET interface. When an EBR receives + an LLMNR query, it responds to the query IFF it aggregates an IP + prefix that covers the prefix in the query. + + Alternatively, in enterprises with a stable and highly-available set + of EBGs, the VET node can simply forward an initial packet via a + default route to an EBG. The EBG will forward the packet to a next- + hop EBR on the VET interface and return an ICMPv6 Redirect [RFC4861] + (using SEND, if necessary). If the packet's source address is on- + link on the VET interface, the EBG returns an ordinary "router-to- + host" redirect with the source address of the packet as its + destination. If the packet's source address is not on-link, the EBG + instead returns a "router-to-router" redirect with the link-local + ISATAP address of the previous-hop EBR as its destination. When IPv4 + is used as the outer IP protocol, the EBG also includes in the + redirect one or more IPv6 Link-Layer Address Options (LLAOs) that + contain the IPv4 RLOCs of potential next-hop EBRs arranged in order + from lowest to highest priority (i.e., the first LLAO contains the + lowest priority RLOC and the final LLAO option contains the highest + priority). These LLAOs are formatted using a modified version of the + form specified in Section 5 of [RFC2529], as shown in Figure 2 (the + LLAO format for IPv6 as the outer IP protocol is out of scope). + + +-------+-------+-------+-------+-------+-------+-------+-------+ + | Type |Length | TTL | IPv4 Address | + +-------+-------+-------+-------+-------+-------+-------+-------+ + + Figure 2: VET Link-Layer Address Option Format + + For each such IPv6/IPv4 LLAO, the Type is set to 2 (for Target Link- + Layer Address Option), Length is set to 1, and IPv4 Address is set to + the IPv4 RLOC of the next-hop EBR. TTL is set to the time in seconds + that the recipient may cache the RLOC, where the value 65535 + represents infinity and the value 0 suspends forwarding through this + RLOC. + + When a VET host receives an ordinary "router-to-host" redirect, it + processes the redirect exactly as specified in [RFC4861], Section 8. + When an EBR receives a "router-to-router" redirect, it discovers the + RLOC addresses of potential next-hop EBRs by examining the LLAOs + + + +Templin Informational [Page 22] + +RFC 5558 VET February 2010 + + + included in the redirect. The EBR then installs a FIB entry that + contains the /56 prefix of the destination address encoded in the + redirect and the list of RLOCs of potential next-hop EBRs. The EBR + then enables the FIB entry for forwarding to next-hop EBRs but DOES + NOT enable it for ingress filtering acceptance of packets from next- + hop EBRs (i.e., the forwarding determination is unidirectional). + + In enterprises in which spoofing is possible, after discovering + potential next-hop EBRs (either through name-service lookup or ICMP + redirect) the EBR must send authenticating credentials before + forwarding packets via the next-hops. To do so, the EBR must send + RAs over the VET interface (using SEND, if necessary) to one or more + of the potential next-hop EBRs with an RLOC as the outer IP + destination address. The RAs must include a Route Information Option + (RIO) [RFC4191] that contains the /56 PI prefix of the original + packet's source address. After sending the RAs, the EBR can either + enable the new FIB entry for forwarding immediately or delay until it + receives an explicit acknowledgement that a next-hop EBR received the + RA (e.g., using the SEAL explicit acknowledgement mechanism -- see + Section 5.7). + + When a next-hop EBR receives the RA, it authenticates the message + then it performs a name-service lookup on the prefix in the RIO if + further authenticating evidence is required. If the name service + returns resource records that are consistent with the inner and outer + IP addresses of the RA, the next-hop EBR then installs the prefix in + the RIO in its FIB and enables the FIB entry for ingress filtering + but DOES NOT enable it for forwarding purposes. After an EBR sends + initial RAs following a redirect, it should send periodic RAs to + refresh the next-hop EBR's ingress filter prefix lifetimes as long as + traffic is flowing. + + EBRs retain the FIB entries created as a result of an ICMP redirect + until all RLOC TTLs expire, or until no hints of forward progress + through any of the associated RLOCs are received. In this way, RLOC + liveness detection exactly parallels IPv6 Neighbor Unreachability + Detection ([RFC4861], Section 3). + +5.5. IPv4 Router Discovery and Prefix Registration + + When IPv4 is used as the inner IP protocol, router discovery and + prefix registration exactly parallel the mechanisms specified for + IPv6 in Section 5.4. To support this, modifications to the ICMPv4 + Router Advertisement [RFC1256] function to include SEND constructs + and modifications to the ICMPv4 Redirect [RFC0792] function to + support router-to-router redirects will be specified in a future + + + + + +Templin Informational [Page 23] + +RFC 5558 VET February 2010 + + + document. Additionally, publications for IPv4 prefixes will be in + dotted-nibble format in the 'ip4.isatap.example.com' domain. For + example, the IPv4 prefix 192.0.2/24 would be represented as: + + '2.0.0.0.0.c.ip4.isatap.example.com' + +5.6. VET Encapsulation + + VET nodes forward packets by consulting the FIB to determine a + specific EBR/EBG as the next-hop router on a VET interface. When + multiple next-hop routers are available, VET nodes can use default + router preferences, routing protocol information, traffic engineering + configurations, etc. to select the best exit router. When there is + no FIB information other than "default" available, VET nodes can + discover the next-hop EBR/EBG through the mechanisms specified in + Section 5.4 and Section 5.5. + + VET interfaces encapsulate inner IP packets in any mid-layer headers + followed by an outer IP header according to the specific + encapsulation type (e.g., [RFC4301], [RFC5214], [RFC5320], etc.); + they next submit the encapsulated packet to the outer IP forwarding + engine for transmission on an underlying interface. + + For forwarding to next-hop addresses over VET interfaces that use + IPv6-in-IPv4 encapsulation, VET nodes determine the outer destination + address (i.e., the IPv4 RLOC of the next-hop EBR) through static + extraction of the IPv4 address embedded in the next-hop ISATAP + address. For other IP-in-IP encapsulations, determination of the + outer destination address is through administrative configuration or + through an unspecified alternate method. When there are multiple + candidate destination RLOCs available, the VET node should only + select an RLOC for which there is current forwarding information in + the outer IP protocol FIB. + +5.7. SEAL Encapsulation + + VET nodes should use SEAL encapsulation [RFC5320] over VET interfaces + to accommodate path MTU diversity, to defeat source address spoofing, + and to monitor next-hop EBR reachability. SEAL encapsulation + maintains a unidirectional and monotonically incrementing per-packet + identification value known as the 'SEAL_ID'. When a VET node that + uses SEAL encapsulation sends a SEND-protected Router Advertisement + (RA) or Router Solicitation (RS) message to another VET node, both + nodes cache the new SEAL_ID as per-tunnel state used for maintaining + a window of unacknowledged SEAL_IDs. + + + + + + +Templin Informational [Page 24] + +RFC 5558 VET February 2010 + + + In terms of security, when a VET node receives an ICMP message, it + can confirm that the packet-in-error within the ICMP message + corresponds to one of its recently sent packets by examining the + SEAL_ID along with source and destination addresses, etc. + Additionally, a next-hop EBR can track the SEAL_ID in packets + received from EBRs for which there is an ingress filter entry and + discard packets that have SEAL_ID values outside of the current + window. + + In terms of next-hop reachability, an EBR can set the SEAL + "Acknowledgement Requested" bit in messages to receive confirmation + that a next-hop EBR is reachable. Setting the "Acknowledgement + Requested" bit is also used as the method for maintaining the window + of outstanding SEAL_IDs. + +5.8. Generating Errors + + When an EBR receives an IPv6 packet over a VET interface and there is + no matching ingress filter entry, it drops the packet and returns an + ICMPv6 [RFC4443] "Destination Unreachable; Source address failed + ingress/egress policy" message to the previous-hop EBR subject to + rate limiting. + + When an EBR receives an IPv6 packet over a VET interface, and there + is no longest-prefix-match FIB entry for the destination, it returns + an ICMPv6 "Destination Unreachable; No route to destination" message + to the previous hop EBR subject to rate limiting. + + When an EBR receives an IPv6 packet over a VET interface and the + longest-prefix-match FIB entry for the destination is via a next-hop + configured over the same VET interface the packet arrived on, the EBR + forwards the packet, then (if the FIB prefix is longer than ::/0) + sends a router-to-router ICMPv6 Redirect message (using SEND, if + necessary) to the previous-hop EBR as specified in Section 5.4.4. + + Generation of other ICMP messages [RFC0792] [RFC4443] is the same as + for any IP interface. + +5.9. Processing Errors + + When an EBR receives an ICMPv6 "Destination Unreachable; Source + address failed ingress/egress policy" message from a next-hop EBR, + and there is a longest-prefix-match FIB entry for the original + packet's destination that is more specific than ::/0, the EBR + discards the message and marks the FIB entry for the destination as + "forwarding suspended" for the RLOC taken from the source address of + the ICMPv6 message. The EBR should then allow subsequent packets to + flow through different RLOCs associated with the FIB entry until it + + + +Templin Informational [Page 25] + +RFC 5558 VET February 2010 + + + forwards a new RA to the suspended RLOC. If the EBR receives + excessive ICMPv6 ingress/egress policy errors through multiple RLOCs + associated with the same FIB entry, it should delete the FIB entry + and allow subsequent packets to flow through an EBG if supported in + the specific enterprise scenario. + + When a VET node receives an ICMPv6 "Destination Unreachable; No route + to destination" message from a next-hop EBR, it forwards the ICMPv6 + message to the source of the original packet as normal. If the EBR + has longest-prefix-match FIB entry for the original packet's + destination that is more specific than ::/0, the EBR also deletes the + FIB entry. + + When an EBR receives an authentic ICMPv6 Redirect, it processes the + packet as specified in Section 5.4.4. + + When an EBG receives new mapping information for a specific + destination prefix, it can propagate the update to other EBRs/EBGs by + sending an ICMPv6 redirect message to the 'All Routers' link-local + multicast address with an LLAO with the TTL for the unreachable LLAO + set to zero, and with a NULL packet in error. + + Additionally, a VET node may receive ICMP "Destination Unreachable; + net / host unreachable" messages from an ER indicating that the path + to a VET neighbor may be failing. The VET node should first check, + e.g., the SEAL_ID, IPsec sequence number, source address of the + original packet if available, etc. to obtain reasonable assurance + that the ICMP message is authentic, then should mark the longest- + prefix-match FIB entry for the destination as "forwarding suspended" + for the RLOC destination address of the ICMP packet-in-error. If the + VET node receives excessive ICMP unreachable errors through multiple + RLOCs associated with the same FIB entry, it should delete the FIB + entry and allow subsequent packets to flow through a different route. + +5.10. Mobility and Multihoming Considerations + + EBRs that travel between distinct enterprise networks must either + abandon their PA prefixes that are relative to the "old" enterprise + and obtain new ones relative to the "new" enterprise or somehow + coordinate with a "home" enterprise to retain ownership of the + prefixes. In the first instance, the EBR would be required to + coordinate a network renumbering event using the new PA prefixes + [RFC4192]. In the second instance, an ancillary mobility management + mechanism must be used. + + EBRs can retain their PI prefixes as they travel between distinct + enterprise networks as long as they register the prefixes with new + EBGs and (preferably) withdraw the prefixes from old EBGs prior to + + + +Templin Informational [Page 26] + +RFC 5558 VET February 2010 + + + departure. Prefix registration with new EBGs is coordinated exactly + as specified in Section 5.4.3; prefix withdrawal from old EBGs is + simply through re-announcing the PI prefixes with zero lifetimes. + + Since EBRs can move about independently of one another, stale FIB + entry state may be left in VET nodes when a neighboring EBR departs. + Additionally, EBRs can lose state for various reasons, e.g., power + failure, machine reboot, etc. For this reason, EBRs are advised to + set relatively short PI prefix lifetimes in RIO options, and to send + additional RAs to refresh lifetimes before they expire. (EBRs should + place conservative limits on the RAs they send to reduce congestion, + however.) + + EBRs may register their PI prefixes with multiple EBGs for + multihoming purposes. EBRs should only forward packets via EBGs with + which it has registered its PI prefixes, since other EBGs may drop + the packets and return ICMPv6 "Destination Unreachable; Source + address failed ingress/egress policy" messages. + + EBRs can also act as delegating routers to sub-delegate portions of + their PI prefixes to requesting routers on their enterprise-edge + interfaces and on VET interfaces for which they are configured as + EBGs. In this sense, the sub-delegations of an EBR's PI prefixes + become the PA prefixes for downstream-dependent nodes. Downstream- + dependent nodes that travel with a mobile provider EBR can continue + to use addresses configured from PA prefixes; downstream-dependent + nodes that move away from their provider EBR must perform address/ + prefix renumbering when they associate with a new provider. + + The EBGs of a multihomed enterprise should participate in a private + inner IP routing protocol instance between themselves (possibly over + an alternate topology) to accommodate enterprise partitions/merges as + well as intra-enterprise mobility events. These peer EBGs should + accept packets from one another without respect to the destination + (i.e., ingress filtering is based on the peering relationship rather + than a prefix-specific ingress filter entry). + +5.11. Multicast + + In multicast-capable deployments, ERs provide an enterprise-wide + multicasting service (e.g., Simplified Multicast Forwarding (SMF) + [MANET-SMF], Protocol Independent Multicast (PIM) routing, Distance + Vector Multicast Routing Protocol (DVMRP) routing, etc.) over their + enterprise-interior interfaces such that outer IP multicast messages + of site-scope or greater scope will be propagated across the + enterprise. For such deployments, VET nodes can also provide an + inner IP multicast/broadcast capability over their VET interfaces + through mapping of the inner IP multicast address space to the outer + + + +Templin Informational [Page 27] + +RFC 5558 VET February 2010 + + + IP multicast address space. In that case, operation of link-scoped + (or greater scoped) inner IP multicasting services (e.g., a link- + scoped neighbor discovery protocol) over the VET interface is + available, but link-scoped services should be used sparingly to + minimize enterprise-wide flooding. + + VET nodes encapsulate inner IP multicast messages sent over the VET + interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an + outer IP header with a site-scoped outer IP multicast address as the + destination. For the case of IPv6 and IPv4 as the inner/outer + protocols (respectively), [RFC2529] provides mappings from the IPv6 + multicast address space to a site-scoped IPv4 multicast address space + (for other IP-in-IP encapsulations, mappings are established through + administrative configuration or through an unspecified alternate + static mapping). + + Multicast mapping for inner IP multicast groups over outer IP + multicast groups can be accommodated, e.g., through VET interface + snooping of inner multicast group membership and routing protocol + control messages. To support inner-to-outer IP multicast mapping, + the VET interface acts as a virtual outer IP multicast host connected + to its underlying interfaces. When the VET interface detects that an + inner IP multicast group joins or leaves, it forwards corresponding + outer IP multicast group membership reports on an underlying + interface over which the VET interface is configured. If the VET + node is configured as an outer IP multicast router on the underlying + interfaces, the VET interface forwards locally looped-back group + membership reports to the outer IP multicast routing process. If the + VET node is configured as a simple outer IP multicast host, the VET + interface instead forwards actual group membership reports (e.g., + IGMP messages) directly over an underlying interface. + + Since inner IP multicast groups are mapped to site-scoped outer IP + multicast groups, the VET node must ensure that the site-scope outer + IP multicast messages received on the underlying interfaces for one + VET interface do not "leak out" to the underlying interfaces of + another VET interface. This is accommodated through normal site- + scoped outer IP multicast group filtering at enterprise boundaries. + +5.12. Service Discovery + + VET nodes can perform enterprise-wide service discovery using a + suitable name-to-address resolution service. Examples of flooding- + based services include the use of LLMNR [RFC4795] over the VET + + + + + + + +Templin Informational [Page 28] + +RFC 5558 VET February 2010 + + + interface or multicast DNS [mDNS] over an underlying interface. More + scalable and efficient service discovery mechanisms are for further + study. + +5.13. Enterprise Partitioning + + EBGs can physically partition an enterprise by configuring multiple + VET interfaces over multiple distinct sets of underlying interfaces. + In that case, each partition (i.e., each VET interface) must + configure its own distinct 'PRLNAME' (e.g., + 'isatap.zone1.example.com', 'isatap.zone2.example.com', etc.). + + EBGs can logically partition an enterprise using a single VET + interface by sending RAs with PIOs containing different IPv6 PA + prefixes to group nodes into different logical partitions. EBGs can + identify partitions, e.g., by examining RLOC prefixes, observing the + interfaces over which RSs are received, etc. In that case, a single + 'PRLNAME' can cover all partitions. + +5.14. EBG Prefix State Recovery + + EBGs must retain explicit state that tracks the inner IP prefixes + owned by EBRs within the enterprise, e.g., so that packets are + delivered to the correct EBRs and not incorrectly "leaked out" of the + enterprise via a default route. For PA prefixes, the state is + maintained via an EBR's DHCP prefix delegation lease renewals, while + for PI prefixes the state is maintained via an EBR's periodic prefix + registration RAs. + + When an EBG loses some or all of its state (e.g., due to a power + failure), it must recover the state so that packets can be forwarded + over correct routes. If the EBG aggregates PA prefixes from which + the IP prefixes of all EBRs in the enterprise are sub-delegated, then + the EBG can recover state through DHCP prefix delegation lease + renewals, through bulk lease queries, or through on-demand name- + service lookups based due to IP packet forwarding. If the EBG serves + as an anchor for PI prefixes, however, care must be taken to avoid + looping while state is recovered through prefix registration RAs from + EBRs. In that case, when the EBG that is recovering state forwards + an IP packet for which it has no explicit route other than ::/0, it + must first perform an on-demand name-service lookup to refresh state. + + + + + + + + + + +Templin Informational [Page 29] + +RFC 5558 VET February 2010 + + +6. Security Considerations + + Security considerations for MANETs are found in [RFC2501]. + + Security considerations with tunneling that apply also to VET are + found in [RFC2529] [RFC5214]. In particular, VET nodes must verify + that the outer IP source address of a packet received on a VET + interface is correct for the inner IP source address using the + procedures specified in Section 7.3 of [RFC5214] in conjunction with + the ingress filtering mechanisms specified in this document. + + SEND [RFC3971], IPsec [RFC4301], and SEAL [RFC5320] provide + additional securing mitigations to detect source address spoofing and + bogus RA messages sent by rogue routers. + + Rogue routers can send bogus RA messages with spoofed RLOC source + addresses that can consume network resources and cause EBGs to + perform extra work. Nonetheless, EBGs should not "blacklist" such + RLOCs, as that may result in a denial of service to the RLOCs' + legitimate owners. + +7. Related Work + + Brian Carpenter and Cyndi Jung introduced the concept of intra-site + automatic tunneling in [RFC2529]; this concept was later called: + "Virtual Ethernet" and investigated by Quang Nguyen under the + guidance of Dr. Lixia Zhang. Subsequent works by these authors and + their colleagues have motivated a number of foundational concepts on + which this work is based. + + Telcordia has proposed DHCP-related solutions for MANETs through the + CECOM MOSAIC program. + + The Naval Research Lab (NRL) Information Technology Division uses + DHCP in their MANET research testbeds. + + Security concerns pertaining to tunneling mechanisms are discussed in + [TUNNEL-SEC]. + + Default router and prefix information options for DHCPv6 are + discussed in [DEF-ROUTER]. + + An automated IPv4 prefix delegation mechanism is proposed in + [SUBNET]. + + RLOC prefix delegation for enterprise-edge interfaces is discussed in + [MANET-REC]. + + + + +Templin Informational [Page 30] + +RFC 5558 VET February 2010 + + + MANET link types are discussed in [LINKTYPE]. + + Various proposals within the IETF have suggested similar mechanisms. + +8. Acknowledgements + + The following individuals gave direct and/or indirect input that was + essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James + Bound, Scott Brim, Brian Carpenter, Thomas Clausen, Claudiu Danilov, + Ralph Droms, Dino Farinacci, Vince Fuller, Thomas Goff, Joel Halpern, + Bob Hinden, Sapumal Jayatissa, Dan Jen, Darrel Lewis, Tony Li, Joe + Macker, David Meyer, Thomas Narten, Pekka Nikander, Dave Oran, + Alexandru Petrescu, John Spence, Jinmei Tatuya, Dave Thaler, Ole + Troan, Michaela Vanderveen, Lixia Zhang, and others in the IETF + AUTOCONF and MANET working groups. Many others have provided + guidance over the course of many years. + +9. Contributors + + The following individuals have contributed to this document: + + Eric Fleischman (eric.fleischman@boeing.com) + Thomas Henderson (thomas.r.henderson@boeing.com) + Steven Russert (steven.w.russert@boeing.com) + Seung Yi (seung.yi@boeing.com) + + Ian Chakeres (ian.chakeres@gmail.com) contributed to earlier versions + of the document. + + Jim Bound's foundational work on enterprise networks provided + significant guidance for this effort. We mourn his loss and honor + his contributions. + +10. References + +10.1. Normative References + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, September 1981. + + [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or + Converting Network Protocol Addresses to 48.bit Ethernet + Address for Transmission on Ethernet Hardware", STD 37, + RFC 826, November 1982. + + + + +Templin Informational [Page 31] + +RFC 5558 VET February 2010 + + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC + 2131, March 1997. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, March + 2005. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences + and More-Specific Routes", RFC 4191, November 2005. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "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. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007. + + + +Templin Informational [Page 32] + +RFC 5558 VET February 2010 + + + [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)", RFC + 5214, March 2008. + +10.2. Informative References + + [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet + Switching Networks", May 1974. + + [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in + Progress, September 2009. + + [MANET-REC] Clausen, T. and U. Herberg, "MANET Router Configuration + Recommendations", Work in Progress, February 2009. + + [LINKTYPE] Clausen, T., "The MANET Link Type", Work in Progress, + October 2008. + + [DEF-ROUTER] Droms, R. and T. Narten, "Default Router and Prefix + Advertisement Options for DHCPv6", Work in Progress, + October 2009. + + [SEND-PROXY] Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy + ND Support for SEND", Work in progress, July 2009. + + [SUBNET] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, + "Subnet Allocation Option", Work in Progress, October + 2009. + + [CENTRL-ULA] Hinden, R., Huston, G., and T. Narten, "Centrally + Assigned Unique Local IPv6 Unicast Addresses", Work in + Progress, June 2007. + + [MANET-SMF] Macker, J., Ed. and SMF Design Team, "Simplified + Multicast Forwarding for MANET", Work in Progress, July + 2009. + + [TUNNEL-SEC] Hoagland, J., Krishnan, S., and D. Thaler, "Security + Concerns With IP Tunneling", Work in Progress, October + 2008. + + [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., + and L. Zhang, "APT: A Practical Transit Mapping + Service", Work in Progress, November 2007. + + [IEN48] Cerf, V., "The Catenet Model for Internetworking", IEN + 48, July 1978. + + + + +Templin Informational [Page 33] + +RFC 5558 VET February 2010 + + + [RASADV] Microsoft, "Remote Access Server Advertisement (RASADV) + Protocol Specification", October 2008. + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC + 1256, September 1991. + + [RFC1753] Chiappa, N., "IPng Technical Requirements Of the Nimrod + Routing and Addressing Architecture", RFC 1753, December + 1994. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, + G., and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [RFC1955] Hinden, R., "New Scheme for Internet Routing and + Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. + + [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking + (MANET): Routing Protocol Performance Issues and + Evaluation Considerations", RFC 2501, January 1999. + + [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over + IPv4 Domains without Explicit Tunnels", RFC 2529, March + 1999. + + [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, + February 2000. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for + Multihomed Networks", BCP 84, RFC 3704, March 2004. + + [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., + Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and + L. Wood, "Advice for Internet Subnetwork Designers", BCP + 89, RFC 3819, July 2004. + + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", RFC 3927, + May 2005. + + [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for + Renumbering an IPv6 Network without a Flag Day", RFC + 4192, September 2005. + + + + + +Templin Informational [Page 34] + +RFC 5558 VET February 2010 + + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, February + 2006. + + [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor + Discovery Proxies (ND Proxy)", RFC 4389, April 2006. + + [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-Local + Multicast Name Resolution (LLMNR)", RFC 4795, January + 2007. + + [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. + Green, "IPv6 Enterprise Network Analysis - IP Layer 3 + Focus", RFC 4852, April 2007. + + [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June + 2007. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, September 2007. + + [RFC5320] Templin, F., "The Subnetwork Encapsulation and + Adaptation Layer (SEAL)", RFC 5320, February 2010. + + [RFC5720] Templin, F., "Routing and Addressing in Networks with + Global Enterprise Recursion (RANGER)", RFC 5720, + February 2010. + + [RANGERS] Russert, S., Ed., Fleischman, E., Ed., and F. Templin, + Ed., "RANGER Scenarios", Work in Progress, September + 2009. + + + + + + + + + + + + + +Templin Informational [Page 35] + +RFC 5558 VET February 2010 + + +Appendix A. Duplicate Address Detection (DAD) Considerations + + A priori uniqueness determination (also known as "pre-service DAD") + for an RLOC assigned on an enterprise-interior interface would + require either flooding the entire enterprise or somehow discovering + a link in the enterprise on which a node that configures a duplicate + address is attached and performing a localized DAD exchange on that + link. But, the control message overhead for such an enterprise-wide + DAD would be substantial and prone to false-negatives due to packet + loss and intermittent connectivity. An alternative to pre-service + DAD is to autoconfigure pseudo-random RLOCs on enterprise-interior + interfaces and employ a passive in-service DAD (e.g., one that + monitors routing protocol messages for duplicate assignments). + + Pseudo-random IPv6 RLOCs can be generated with mechanisms such as + CGAs, IPv6 privacy addresses, etc. with very small probability of + collision. Pseudo-random IPv4 RLOCs can be generated through random + assignment from a suitably large IPv4 prefix space. + + Consistent operational practices can assure uniqueness for EBG- + aggregated addresses/prefixes, while statistical properties for + pseudo-random address self-generation can assure uniqueness for the + RLOCs assigned on an ER's enterprise-interior interfaces. Still, an + RLOC delegation authority should be used when available, while a + passive in-service DAD mechanism should be used to detect RLOC + duplications when there is no RLOC delegation authority. + +Author's Address + + Fred L. Templin (editor) + Boeing Research & Technology + P.O. Box 3707 MC 7L-49 + Seattle, WA 98124 + USA + + EMail: fltemplin@acm.org + + + + + + + + + + + + + + + +Templin Informational [Page 36] + -- cgit v1.2.3