idnits 2.17.1 draft-ietf-dhc-dhcpv6-ctep-opt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 235. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 251), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 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 (October 22, 2005) is 6754 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 (Obsoleted by RFC 8415) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Daniel Park 3 Internet-Draft SAMSUNG Electronics 4 Expires: April 22, 2006 A. Vijayabhaskar 5 HP 6 October 22, 2005 8 Configured Tunnel End Point Option for DHCPv6 9 draft-ietf-dhc-dhcpv6-ctep-opt-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 22, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 For the newly deployed IPv6 networks to interoperate with vastly 43 deployed IPv4 networks, various transition mechanisms had been 44 proposed. One such mechanism is configured tunnels. This document 45 provides a tunnel discovery mechanism by which the DHCPv6 servers can 46 provide information about the available configured tunnel end points 47 to reach the IPv6 nodes which are separated by IPv4 networks. 49 1. Introduction 51 In the initial deployment of IPv6, the IPv6 nodes may need to 52 communicate with the other IPv6 nodes via IPv4 networks. Configured 53 tunnels [RFC4213] provide a way to encapsulate the IPv6 packets in 54 IPv4 packets and tunnel them in the IPv4 network. 56 This document defines a new option called Configured Tunnel End Point 57 by which the DHCPv6 [RFC3315] server can notify the client with the 58 list of end point of the configured tunnels to the various IPv6 59 networks separated by the IPv4 networks. 61 2. Background 63 Configured Tunnel described in this document is a simple and 64 temporary mechanism which allows isolated IPv6 networks or hosts, 65 attached to a legacy IPv4 network which has no native IPv6 66 connectivity, to communicate with other such IPv6 networks or hosts 67 with manual configuration. The configured tunnel end-point received 68 from the DHCPv6 server is not used for IPv6 connectivity as long as 69 IPv6 networks or hosts are communicating with other IPv6 networks or 70 hosts via IPv6 network which has native IPv6 connectivity and only 71 available when communicating with other IPv6 networks or hosts via 72 IPv4 networks. 74 In this scenario, 6to4 [RFC3056] can be a possible alternative 75 instead of configured tunnel. 77 As indicated in [RFC3056], the mechanisms are intended as a start-up 78 transition tool used during the period of co-existence of IPv4 and 79 IPv6. It is not intended as a permanent solution. 81 3. Requirements 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 4. Terminology 89 This document uses terminology specific to IPv6 and DHCPv6 as defined 90 in "Terminology" section of the DHCPv6 specification [RFC3315]. 92 5. Configured Tunnel End Point Option 94 The Configured Tunnel End Point Option gives the information to the 95 clients about the Configured Tunnel End Point [RFC4213] to be 96 contacted for reaching the nodes in the various IPv6 networks which 97 are separated by IPv4 networks. The clients are expected to install 98 these routes in their machines. 100 The format of the Configured Tunnel End Point Option is as shown 101 below: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | OPTION_CTEP | option-len | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | prefix-len | | 109 +-+-+-+-+-+-+-+-+ | 110 | | 111 | Configured TEP Address (16 bytes) | 112 | | 113 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | |... (if multiple tunnels are in use) 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 option-code: OPTION_CTEP (TBD) 119 option-len: Total length of the prefix-len, Configured Tunnel Address 120 lists in octets; It should be a multiple of 17. 122 prefix-len: prefix length of this Configured TEP Address in bits. 124 Configured TEP Address: IPv6 Address of the Configured TEP. 126 The clients are expected to install the routes identified by the 127 tuples (prefix-len, Configured TEP Address) once they receive this 128 option from the server. 130 6. Appearance of this option 132 The Configured Tunnel End Point Option MUST NOT appear in other than 133 the following messages: Solicit, Advertise, Request, Renew, Rebind, 134 Information-Request and Reply. 136 The option numbers of Configured Tunnel End Point option MAY appear 137 in the Option Request Option [RFC3315] in the following messages: 138 Solicit, Request, Renew, Rebind, Information-Request and Reconfigure. 140 7. multiple Tunnel End Point Considerations 142 For the simple tunnel discovery, one tunnel endpoint is generally 143 used and it assumes that all the networks will be reached through the 144 same endpoint. In this case, one Configured TEP field in the TEP 145 option is used for configured tunnel service. 147 The list of endpoints can be installed if the IPv6 host load-sharing 148 is honored, but there may not be a need for installing multiple 149 configured tunnel endpoints unless administrator wants two for 150 redundancy purposes. It is beyond scope of this document. 152 8. Security Considerations 154 The Configured Tunnel End Point Option may be used by an intruder 155 DHCPv6 server to provide invalid or incorrect configured tunnel end 156 point. This makes the client unable to reach its destination IPv6 157 node or to reach incorrect destination. The latter one has very 158 severe security issues as IPv6 destination is spoofed here. 160 To avoid attacks through this option, the DHCPv6 client SHOULD use 161 authenticated DHCP (see section "Authentication of DHCP messages" in 162 the DHCPv6 specification [RFC3315]). 164 9. IANA Considerations 166 IANA is requested to assign an option code to the following options 167 from the option-code space defined in "DHCPv6 Options" section of the 168 DHCPv6 specification [RFC3315]. 170 Option Name Value Described in 172 OPTION_CTEP TBD Section 4 174 10. References 176 10.1 Normative References 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 182 M. Carney, "Dynamic Host Configuration Protocol for IPv6 183 (DHCPv6)", RFC 3315, July 2003. 185 10.2 Informative References 187 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 188 via IPv4 Clouds", RFC 3056, February 2001. 190 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 191 for IPv6 Hosts and Routers", RFC 4213, October 2005. 193 Authors' Addresses 195 Soohong Daniel Park 196 SAMSUNG Electronics 197 416 Maetan-3dong, Yeongtong-gu 198 Suwon-si, Gyeonggi-do 442-742 199 KOREA 201 Phone: +82 31 200 4635 202 EMail: soohong.park@samsung.com 204 Vijayabhaskar A K 205 Hewlett-Packard 206 29, Cunningham Road 207 Bangalore 560052 208 INDIA 210 Phone: +91 80 205308582 211 EMail: vijayak@india.hp.com 213 Intellectual Property Statement 215 The IETF takes no position regarding the validity or scope of any 216 Intellectual Property Rights or other rights that might be claimed to 217 pertain to the implementation or use of the technology described in 218 this document or the extent to which any license under such rights 219 might or might not be available; nor does it represent that it has 220 made any independent effort to identify any such rights. Information 221 on the procedures with respect to rights in RFC documents can be 222 found in BCP 78 and BCP 79. 224 Copies of IPR disclosures made to the IETF Secretariat and any 225 assurances of licenses to be made available, or the result of an 226 attempt made to obtain a general license or permission for the use of 227 such proprietary rights by implementers or users of this 228 specification can be obtained from the IETF on-line IPR repository at 229 http://www.ietf.org/ipr. 231 The IETF invites any interested party to bring to its attention any 232 copyrights, patents or patent applications, or other proprietary 233 rights that may cover technology that may be required to implement 234 this standard. Please address the information to the IETF at 235 ietf-ipr@ietf.org. 237 Disclaimer of Validity 239 This document and the information contained herein are provided on an 240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 242 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 243 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 244 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 247 Copyright Statement 249 Copyright (C) The Internet Society (2005). This document is subject 250 to the rights, licenses and restrictions contained in BCP 78, and 251 except as set forth therein, the authors retain all their rights. 253 Acknowledgment 255 Funding for the RFC Editor function is currently provided by the 256 Internet Society.