idnits 2.17.1 draft-templin-isatap-dhcp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5214, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 8, 2009) is 5253 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5214 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft Boeing Research & Technology 4 Updates: 5214 (if approved) December 8, 2009 5 Intended status: Standards Track 6 Expires: June 11, 2010 8 Dynamic Host Configuration Protocol (DHCPv4) Option for the Intra-Site 9 Automatic Tunnel Addressing Protocol (ISATAP) 10 draft-templin-isatap-dhcp-06.txt 12 Abstract 14 This document specifies a Dynamic Host Configuration Protocol 15 (DHCPv4) option for nodes that implement the Intra-Site Automatic 16 Tunnel Addressing Protocol (ISATAP). 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on June 11, 2010. 41 Copyright Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology and Requirements . . . . . . . . . . . . . . . . . 3 60 3. ISATAP DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 3 61 4. ISATAP Client Behavior . . . . . . . . . . . . . . . . . . . . 4 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 68 Appendix A. Backward Compatibility . . . . . . . . . . . . . . . . 5 69 Appendix B. Anycast Services . . . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 This document specifies a Dynamic Host Configuration Protocol option 75 [RFC2131][RFC2132] for nodes that implement the Intra-Site Automatic 76 Tunnel Addressing Protocol (ISATAP) [RFC5214]. The option encodes 77 configuration information used by clients to initialize the Potential 78 Router List as specified in [RFC5214], section 8.3.2. The option 79 format is similar to that specified in [RFC3361], and includes a list 80 of IPv4 addresses and domain names that form the Potential Router 81 List. 83 2. Terminology and Requirements 85 The terminology of ISATAP [RFC5214] applies to this document. 87 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 88 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 89 document, are to be interpreted as described in [RFC2119]. 91 3. ISATAP DHCPv4 Option 93 The ISATAP DHCPv4 option encodes a list of IPv4 addresses followed by 94 a list of DNS [RFC1035] fully-qualified domain names (FQDNs) using 95 the following format: 97 Code Len N <- IPv4 addr's -> <- FQDN's -> 98 +----+----+----+----+----+----+----+----+----+----+----+ 99 | TBD| Len| N | a1 | a2 | ...| aN | f1 | f2 | ...| fM | 100 +----+----+----+----+----+----+----+----+----+----+----+ 102 Figure 1: ISATAP DHCPv4 Option Format 104 As shown in Figure 1, the DHCPv4 option code is followed immediately 105 by a 'Len' octet that indicates the total number of option octets 106 that follow. The 'Len' octet is followed by an 'N' octet with a 107 value (0 <= N <= 255) that indicates the total number of 4-octet IPv4 108 addresses in the list that follows. The final IPv4 address is 109 followed by a list of 'M' DNS FQDNs encoded exactly as specified in 110 Section 3.1 of [RFC1035], where M is implicitly derived by parsing 111 the remaining portion of the option beyond the final IPv4 address. 113 For example, if the administrator wishes to advertise the IPv4 114 addresses '192.0.2.3' and '192.0.2.3', and the FQDNs "isatap.com", 115 "isatap.org" and "isatap.net", the DHCPv4 option is encoded as shown 116 in Figure 2 (with numeric values represented as decimal): 118 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 119 |TBD| 45| 2 |192| 00| 02| 02|192| 00| 02| 03| 6 |'i'|'s'|'a'| 120 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 121 |'t'|'a'|'p'| 3 |'c'|'o'|'m'| 0 | 6 |'i'|'s'|'a'|'t'|'a'|'p'| 122 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 123 | 3 |'o'|'r'|'g'| 0 | 6 |'i'|'s'|'a'|'t'|'a'|'p'| 3 |'n'|'e'| 124 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 125 |'t'| 0 | 126 +---+---+ 128 Figure 2: ISATAP DHCPv4 Option Example 130 If the length of the ISATAP DHCPv4 Option exceeds 254 octets, the 131 option is encoded as for DHCP long options as specified in [RFC3396]. 133 4. ISATAP Client Behavior 135 ISATAP clients use the information encoded in the ISATAP DHCPv4 136 option to initialize the Potential Router List as specified in 137 Section 8.3.2 of [RFC5214]. The ISATAP client itself (i.e., and not 138 the DHCP server) resolves each FQDN into a list of IPv4 addresses, 139 since the name resolution service available to the ISATAP client may 140 in some cases be more responsive to dynamic updates than the name 141 resolution service available to the DHCP server. 143 After the ISATAP client initializes the Potential Router List, it 144 performs router and prefix discovery as specified in Sections 8.3.3 145 and 8.3.4 of [RFC5214]. 147 5. IANA Considerations 149 A new DHCPv4 option number for ISATAP is requested. 151 6. Security Considerations 153 The security considerations in [RFC2131] apply. 155 7. Acknowledgments 157 The following individuals are acknowledged for their contributions: 158 Jim Bound, Ralph Droms, Ted Lemon, Mohan Parthasarathy, Pekka Savola. 160 8. References 161 8.1. Normative References 163 [RFC1035] Mockapetris, P., "Domain names - implementation and 164 specification", STD 13, RFC 1035, November 1987. 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, March 1997. 169 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 170 RFC 2131, March 1997. 172 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 173 Extensions", RFC 2132, March 1997. 175 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 176 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 177 November 2002. 179 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 180 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 181 March 2008. 183 8.2. Informative References 185 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 186 (DHCP-for-IPv4) Option for Session Initiation Protocol 187 (SIP) Servers", RFC 3361, August 2002. 189 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 190 More-Specific Routes", RFC 4191, November 2005. 192 Appendix A. Backward Compatibility 194 The ISATAP DHCP option can be used in the presence of legacy ISATAP 195 clients, which typically construct a FQDN for the Potential Router 196 List by concatenating the string "isatap" with a connection-specific 197 DNS suffix "example.com" received from the DHCP server (e.g., as 198 "isatap.example.com"). Administrators should therefore ensure that 199 the Potential Router List discovered by clients that implement the 200 ISATAP DHCP option is consistent with the Potential Router List 201 discovered by legacy clients. 203 Appendix B. Anycast Services 205 Some of the IPv4 addresses that appear in the Potential Router List 206 may be anycast addresses, i.e., they may be configured on the ISATAP 207 interfaces of multiple routers. In that case, each ISATAP router 208 interface that configures the same anycast address must provide 209 equivalent packet forwarding and IPv6 Neighbor Discovery services. 211 Use of an anycast address as the IP destination address of tunneled 212 packets can have subtle interactions with tunnel path MTU and 213 neighbor discovery. For example, if the initial fragments of a 214 fragmented tunneled packet with an anycast IP destination address are 215 routed to different egress tunnel endpoints than the remaining 216 fragments, the multiple endpoints will be left with incomplete 217 reassembly buffers. This issue can be mitigated by ensuring that 218 each egress tunnel endpoint implements a proactive reassembly buffer 219 garbage collection strategy. Additionally, ingress tunnel endpoints 220 that send packets with an anycast IP destination address must use the 221 minimum path MTU for all egress tunnel endpoints that configure the 222 same anycast address as the tunnel MTU. Finally, ingress tunnel 223 endpoints must treat ICMP unreachable messages from a router within 224 the tunnel as at most a weak indication of neighbor unreachability, 225 since the failures may only be transient and quickly corrected 226 through reconvergence of the underlying routing protocol. 228 Use of an anycast address as the IP source address of tunneled 229 packets can lead to more serious issues. For example, when the IP 230 source address of a tunneled packet is anycast, ICMP messages 231 produced by routers within the tunnel might be delivered to different 232 ingress tunnel endpoints than the ones that produced the packets. In 233 that case, functions such as path MTU discovery and neighbor 234 unreachability detection may experience non-deterministic behavior 235 that can lead to communications failures. Additionally, the 236 fragments of multiple tunneled packets produced by multiple ingress 237 tunnel endpoints may be delivered to the same reassembly buffer at a 238 single egress tunnel endpoint. In that case, data corruption may 239 result due to fragment misassociation during reassembly. 241 In view of these considerations, ISATAP routers that configure an 242 anycast address should also configure one or more unicast addresses 243 from the Potential Router List; they should further accept tunneled 244 packets destined to any of their anycast or unicast addresses, but 245 should send tunneled packets using a unicast address as the source 246 address. The sole exception to this rule is that ISATAP routers 247 should respond to unicast IPv6 Neighbor and Router Solicitation 248 messages by using the destination address of the solicitation as the 249 source address for the corresponding advertisement messages, i.e., 250 whether the address is anycast or unicast. 252 In order to influence traffic to use an anycast route (and thereby 253 leverage the natural fault tolerance afforded by anycast), ISATAP 254 routers should set higher preferences on the default routes they 255 advertise using an anycast address as the source and set lower 256 preferences on the default routes they advertise using a unicast 257 address as the source (see: [RFC4191]). 259 Author's Address 261 Fred L. Templin 262 Boeing Research & Technology 263 P.O. Box 3707 264 Seattle, WA 98124 265 USA 267 Email: fltemplin@acm.org