Network Working Group F. Templin Internet-Draft Boeing Research & Technology Updates: 5214 (if approved) December 8, 2009 Intended status: Standards Track Expires: June 11, 2010 Dynamic Host Configuration Protocol (DHCPv4) Option for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) draft-templin-isatap-dhcp-06.txt Abstract This document specifies a Dynamic Host Configuration Protocol (DHCPv4) option for nodes that implement the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 11, 2010. Copyright Notice Copyright (c) 2009 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 Templin Expires June 11, 2010 [Page 1] Internet-Draft ISATAP DHCP Option December 2009 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Requirements . . . . . . . . . . . . . . . . . 3 3. ISATAP DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 3 4. ISATAP Client Behavior . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Appendix A. Backward Compatibility . . . . . . . . . . . . . . . . 5 Appendix B. Anycast Services . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Templin Expires June 11, 2010 [Page 2] Internet-Draft ISATAP DHCP Option December 2009 1. Introduction This document specifies a Dynamic Host Configuration Protocol option [RFC2131][RFC2132] for nodes that implement the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]. The option encodes configuration information used by clients to initialize the Potential Router List as specified in [RFC5214], section 8.3.2. The option format is similar to that specified in [RFC3361], and includes a list of IPv4 addresses and domain names that form the Potential Router List. 2. Terminology and Requirements The terminology of ISATAP [RFC5214] applies to this document. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. ISATAP DHCPv4 Option The ISATAP DHCPv4 option encodes a list of IPv4 addresses followed by a list of DNS [RFC1035] fully-qualified domain names (FQDNs) using the following format: Code Len N <- IPv4 addr's -> <- FQDN's -> +----+----+----+----+----+----+----+----+----+----+----+ | TBD| Len| N | a1 | a2 | ...| aN | f1 | f2 | ...| fM | +----+----+----+----+----+----+----+----+----+----+----+ Figure 1: ISATAP DHCPv4 Option Format As shown in Figure 1, the DHCPv4 option code is followed immediately by a 'Len' octet that indicates the total number of option octets that follow. The 'Len' octet is followed by an 'N' octet with a value (0 <= N <= 255) that indicates the total number of 4-octet IPv4 addresses in the list that follows. The final IPv4 address is followed by a list of 'M' DNS FQDNs encoded exactly as specified in Section 3.1 of [RFC1035], where M is implicitly derived by parsing the remaining portion of the option beyond the final IPv4 address. For example, if the administrator wishes to advertise the IPv4 addresses '192.0.2.3' and '192.0.2.3', and the FQDNs "isatap.com", "isatap.org" and "isatap.net", the DHCPv4 option is encoded as shown in Figure 2 (with numeric values represented as decimal): Templin Expires June 11, 2010 [Page 3] Internet-Draft ISATAP DHCP Option December 2009 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |TBD| 45| 2 |192| 00| 02| 02|192| 00| 02| 03| 6 |'i'|'s'|'a'| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |'t'|'a'|'p'| 3 |'c'|'o'|'m'| 0 | 6 |'i'|'s'|'a'|'t'|'a'|'p'| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 3 |'o'|'r'|'g'| 0 | 6 |'i'|'s'|'a'|'t'|'a'|'p'| 3 |'n'|'e'| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |'t'| 0 | +---+---+ Figure 2: ISATAP DHCPv4 Option Example If the length of the ISATAP DHCPv4 Option exceeds 254 octets, the option is encoded as for DHCP long options as specified in [RFC3396]. 4. ISATAP Client Behavior ISATAP clients use the information encoded in the ISATAP DHCPv4 option to initialize the Potential Router List as specified in Section 8.3.2 of [RFC5214]. The ISATAP client itself (i.e., and not the DHCP server) resolves each FQDN into a list of IPv4 addresses, since the name resolution service available to the ISATAP client may in some cases be more responsive to dynamic updates than the name resolution service available to the DHCP server. After the ISATAP client initializes the Potential Router List, it performs router and prefix discovery as specified in Sections 8.3.3 and 8.3.4 of [RFC5214]. 5. IANA Considerations A new DHCPv4 option number for ISATAP is requested. 6. Security Considerations The security considerations in [RFC2131] apply. 7. Acknowledgments The following individuals are acknowledged for their contributions: Jim Bound, Ralph Droms, Ted Lemon, Mohan Parthasarathy, Pekka Savola. 8. References Templin Expires June 11, 2010 [Page 4] Internet-Draft ISATAP DHCP Option December 2009 8.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. 8.2. Informative References [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. Appendix A. Backward Compatibility The ISATAP DHCP option can be used in the presence of legacy ISATAP clients, which typically construct a FQDN for the Potential Router List by concatenating the string "isatap" with a connection-specific DNS suffix "example.com" received from the DHCP server (e.g., as "isatap.example.com"). Administrators should therefore ensure that the Potential Router List discovered by clients that implement the ISATAP DHCP option is consistent with the Potential Router List discovered by legacy clients. Appendix B. Anycast Services Some of the IPv4 addresses that appear in the Potential Router List may be anycast addresses, i.e., they may be configured on the ISATAP Templin Expires June 11, 2010 [Page 5] Internet-Draft ISATAP DHCP Option December 2009 interfaces of multiple routers. In that case, each ISATAP router interface that configures the same anycast address must provide equivalent packet forwarding and IPv6 Neighbor Discovery services. Use of an anycast address as the IP destination address of tunneled packets can have subtle interactions with tunnel path MTU and neighbor discovery. For example, if the initial fragments of a fragmented tunneled packet with an anycast IP destination address are routed to different egress tunnel endpoints than the remaining fragments, the multiple endpoints will be left with incomplete reassembly buffers. This issue can be mitigated by ensuring that each egress tunnel endpoint implements a proactive reassembly buffer garbage collection strategy. Additionally, ingress tunnel endpoints that send packets with an anycast IP destination address must use the minimum path MTU for all egress tunnel endpoints that configure the same anycast address as the tunnel MTU. Finally, ingress tunnel endpoints must treat ICMP unreachable messages from a router within the tunnel as at most a weak indication of neighbor unreachability, since the failures may only be transient and quickly corrected through reconvergence of the underlying routing protocol. Use of an anycast address as the IP source address of tunneled packets can lead to more serious issues. For example, when the IP source address of a tunneled packet is anycast, ICMP messages produced by routers within the tunnel might be delivered to different ingress tunnel endpoints than the ones that produced the packets. In that case, functions such as path MTU discovery and neighbor unreachability detection may experience non-deterministic behavior that can lead to communications failures. Additionally, the fragments of multiple tunneled packets produced by multiple ingress tunnel endpoints may be delivered to the same reassembly buffer at a single egress tunnel endpoint. In that case, data corruption may result due to fragment misassociation during reassembly. In view of these considerations, ISATAP routers that configure an anycast address should also configure one or more unicast addresses from the Potential Router List; they should further accept tunneled packets destined to any of their anycast or unicast addresses, but should send tunneled packets using a unicast address as the source address. The sole exception to this rule is that ISATAP routers should respond to unicast IPv6 Neighbor and Router Solicitation messages by using the destination address of the solicitation as the source address for the corresponding advertisement messages, i.e., whether the address is anycast or unicast. In order to influence traffic to use an anycast route (and thereby leverage the natural fault tolerance afforded by anycast), ISATAP routers should set higher preferences on the default routes they Templin Expires June 11, 2010 [Page 6] Internet-Draft ISATAP DHCP Option December 2009 advertise using an anycast address as the source and set lower preferences on the default routes they advertise using a unicast address as the source (see: [RFC4191]). Author's Address Fred L. Templin Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires June 11, 2010 [Page 7]