idnits 2.17.1 draft-daniel-dhc-dhcpv6-ctep-opt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 2003) is 7437 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) ** Obsolete normative reference: RFC 3315 (ref. '1') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. '3') (Obsoleted by RFC 4213) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Daniel Park 2 Internet-Draft SAMSUNG Electronics 3 Expires : June 2004 A.K. Vijayabhaskar 4 Hewlett-Packard 5 December 2003 7 Configured Tunnel End Point Option for DHCPv6 8 draft-daniel-dhc-dhcpv6-ctep-opt-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 For the newly deployed IPv6 networks to interoperate with vastly 38 deployed IPv4 networks, various transition mechanisms had been 39 proposed. One such mechanism is configured tunnels. This document 40 provides a mechanism by which the DHCPv6 servers can provide 41 information about the various configured tunnel end points to reach 42 the IPv6 nodes which are separated by IPv4 networks. 44 1. Introduction 46 In the initial deployment of IPv6, the IPv6 nodes may need to 47 communicate with the other IPv6 nodes via IPv4 networks. Configured 48 tunnels [3] provide a way to encapsulate the IPv6 packets in IPv4 49 packets and tunnel them in the IPv4 network. 51 This document defines a new option called Configured Tunnel End 52 Point by which the DHCPv6 [1] server can notify the client with the 53 list of end point of the configured tunnels to the various IPv6 54 networks separated by the IPv4 networks. 56 2. Requirements 58 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 59 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 60 document, are to be interpreted as described in RFC 2119 [2] 62 3. Terminology 64 This document uses terminology specific to IPv6 and DHCPv6 as 65 defined in "Terminology" section of the DHCPv6 specification [1]. 67 4. Configured Tunnel End Point Option 69 The Configured Tunnel End Point Option gives the information to the 70 clients about the Configured Tunnel End Point [3] to be contacted 71 for reaching the nodes in the various IPv6 networks which are 72 separated by IPv4 networks. The clients are expected to install 73 these routes in their machines. 75 The format of the Configured Tunnel End Point Option is as shown 76 below: 78 0 1 2 3 79 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | OPTION_CTEP | option-len | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | prefix-len | | 84 +-+-+-+-+-+-+-+-+-+ | 85 | | 86 | Destination Prefix (16 bytes) | 87 | | 88 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | | | 90 +-+-+-+-+-+-+-+-+-+ | 91 | Configured TEP Address (16 bytes) | 92 | | 93 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | | prefix-len | | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 96 | | 97 | Destination Prefix (16 bytes) | 98 | | 99 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | | | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 102 | | 103 | Configured TEP Address (16 bytes) | 104 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 105 | | | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 107 | . . . | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 option-code: OPTION_CTEP (TBD) 112 option-len: Total length of the prefix-len, Destination Prefix and 113 Configured Tunnel Address lists in octets; It should be 114 a multiple of 33. 116 prefix-len: prefix length of the Destination Prefix 118 Destination Prefix: IPv6 Prefix; 120 Configured TEP Address: IPv6 Address of the Configured TEP. 122 The clients are expected to install the routes identified by the 123 tuples once 124 they receive this option from the server. 126 5. Appearance of this option 128 The Configured Tunnel End Point Option MUST NOT appear in other 129 than the following messages: Solicit, Advertise, Request, Renew, 130 Rebind, Information-Request and Reply. 132 The option numbers of Configured Tunnel End Point option MAY appear 133 in the Option Request Option [1] in the following messages: Solicit, 134 Request, Renew, Rebind, Information-Request and Reconfigure. 136 6. Security Considerations 138 The Configured Tunnel End Point Option may be used by an intruder 139 DHCPv6 server to provide invalid or incorrect configured tunnel end 140 point. This makes the client unable to reach its destination IPv6 141 node or to reach incorrect destination. The latter one has very 142 severe security issues as IPv6 destination is spoofed here. 144 To avoid attacks through this option, the DHCPv6 client SHOULD use 145 authenticated DHCP (see section "Authentication of DHCP messages" in 146 the DHCPv6 specification [1]). 148 7. IANA Considerations 150 IANA is requested to assign an option code to the following options 151 from the option-code space defined in "DHCPv6 Options" section of 152 the DHCPv6 specification [1]. 154 Option Name Value Described in 155 OPTION_CTEP TBD Section 4 157 8. References 159 8.1 Normative References 161 [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and 162 R.Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 163 (DHCPv6)", RFC 3315, July 2003. 165 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 166 Levels", BCP 14, RFC 2119, March 1997. 168 8.2 Informative References 170 [3] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 171 Hosts and Routers", RFC 2893, August 2000. 173 9. Authors' Addresses 175 Soohong Daniel Park 176 Mobile Platform Laboratory, SAMSUNG Electronics. 177 416. Maetan-Dong, Paldal-Gu, 178 Suwon, Gyeonggi-Do 179 Korea 181 Phone: +81-31-200-4508 182 E-Mail: soohong.park@samsung.com 184 Vijayabhaskar A K 185 Hewlett-Packard STSD-I 186 29, Cunningham Road 187 Bangalore - 560052 188 India 190 Phone: +91-80-2053085 191 E-Mail: vijayak@india.hp.com 193 Full Copyright Statement 195 Copyright (C) The Internet Society (2003). All Rights Reserved. 197 This document and translations of it may be copied and furnished to 198 others, and derivative works that comment on or otherwise explain it 199 or assist in its implementation may be prepared, copied, published 200 and distributed, in whole or in part, without restriction of any 201 kind, provided that the above copyright notice and this paragraph 202 are included on all such copies and derivative works. However, this 203 document itself may not be modified in any way, such as by removing 204 the copyright notice or references to the Internet Society or other 205 Internet organizations, except as needed for the purpose of 206 developing Internet standards in which case the procedures for 207 copyrights defined in the Internet Standards process must be 208 followed, or as required to translate it into languages other than 209 English. 211 The limited permissions granted above are perpetual and will not be 212 revoked by the Internet Society or its successors or assigns. 214 This document and the information contained herein is provided on an 215 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 216 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 217 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 218 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 219 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 221 Acknowledgement 223 Funding for the RFC Editor function is currently provided by the 224 Internet Society. Thanks to the DHC Working Group for their time 225 and input into the specification. In particular, thanks to Pekka 226 Savola, Bernie Volz, Ralph Droms, for their valuable comments on 227 this work.