idnits 2.17.1 draft-vandevelde-v6ops-cpe-default-route-detection-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 274. 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 IETF Trust 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 (February 13, 2008) is 5916 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 informational reference (is this intentional?): RFC 3633 (ref. '1') (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group G. Van de Velde 3 Internet-Draft Cisco Systems 4 Expires: August 16, 2008 J. Brozowski 5 Comcast Cable 6 S. Miyakawa 7 NTT Communications 8 February 13, 2008 10 CPE Default Route Detection 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 16, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 When the CPE (Customer Premisses Equipment) device is a routed IPv6 45 device, then detection automation of the upstream connectivity (i.e. 46 the default-route) has not been uniformly described. There are many 47 CPE vendors, and they may have many technologies to achieve this 48 goal. This document provides an overview of the problem space, while 49 identifying various options within the solution space. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Alternatives for Default Route Detection . . . . . . . . . . . 4 56 3.1. Manual Route Configuration on the CPE . . . . . . . . . . . 4 57 3.2. Routing protocol between CPE and upstream router . . . . . 4 58 3.3. Extension of DHCPv6 with a default-router option . . . . . 4 59 3.4. CPE has both Router and Host functionality . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Intellectual Property and Copyright Statements . . . . . . . . . . 7 69 1. Introduction 71 A Service Provider (SP) providing IPv6 connectivity to customer 72 networks may want to automate provisioning of IPv6 prefixes and other 73 configuration information to reduce errors and human interaction 74 towards CPE devices. An available tool to achieve this goal is 75 DHCP-PD [1]. DHCP-PD allows for both automated assignment of IPv6 76 prefixes and of configuration parameter allocation to a customer 77 network. 79 Where DHCP-PD [1] typical delivers information about the allocated 80 address space to a customer network combined with other configuration 81 parameters, it does not provide information to the customer network 82 about the upstream connectivity through the SP. 84 This document will provide a problem definition to help the CPE 85 detect its upstream connectivity while providing insight about the 86 potential solution space. 88 2. Problem statement 90 If assumed that a customer network is comprised of at least one CPE 91 where the CPE is providing network connectivity (routed) to nodes on 92 the customer network. In this case the CPE is assumed to be more 93 than just a single host or node. It is also assumed that the CPE 94 device is dynamically allocating network and configuration 95 information through DHCP-PD. The CPE may segment received address 96 space and allocate it towards the various interfaces available to the 97 CPE. Techniques for the sub-allocation of delegated IPv6 address 98 space is out of scope for this document. 100 If the customer network consists out of multiple routers 101 hierarchically organized then only the CPE performing DHCP-PD with 102 the SP network can be used to obtain an parent prefix from which sub- 103 allocations can be derived. Additional care needs to be taken to 104 distribute the through DHCP-PD received IPv6 address space on the CPE 105 amongst the set of customer routers. These techniques and procedures 106 (i.e. hierachical DHCP services) are outside the scope of this 107 document. 109 Whereas the CPE directly connected to the SP has awareness of the 110 Service Provider allocated address space it is not made dynamically 111 aware of the upstream path to install upstream routing entries, 112 specifically the default route for the customer network. The 113 following sections outline techniques that can be used to obtain and 114 populate (default-)route information in the CPE. 116 3. Alternatives for Default Route Detection 118 3.1. Manual Route Configuration on the CPE 120 The administrator of the CPE may have out-of-band awareness of the 121 default gateway. In this case the administrator may configure routes 122 manually on the CPE. However, even if this option may seem trivial, 123 it is open to human mistakes and requires human action. Hence, it is 124 not a preferenced method of operation for fully automated CPE 125 provisioning. 127 3.2. Routing protocol between CPE and upstream router 129 If the CPE has routing capabilities then routing information can be 130 exchanged between CPE and the SP access router. A dynamic routing 131 protocol can be used to achieve this. This solution can be useful if 132 the service provider router has a limited set of CPE's connected. 133 This is due to scalability and possible state-maintenance which tend 134 to require significant amount of bandwidth and processing power. 135 This option will seldomly be useful for home networks where there are 136 often large volumes of devices that connect to a single service 137 provider access router. 139 3.3. Extension of DHCPv6 with a default-router option 141 Currently there is no option specified for DHCPv6 to identify the 142 default-router that may be used by the device. If this option were 143 available then it could be used by the CPE to detect its default- 144 router and populate the required routing information on the CPE. 145 Specification of this DHCPv6 option and device behavior to acquire 146 and populate the same is out of scope for this document. 148 3.4. CPE has both Router and Host functionality 150 RFC4861 [2] section 6.2.7. Router Advertisement Consistency defines 151 the behavior of routers related to the processing of Router 152 Advertisement messages. It is specified that routers are to inspect 153 router advertisement messages to validate the contents of the same 154 relative to the link. RFC4861 [2] also indicates that any additional 155 behavior beyond this related to the router is out of scope for the 156 RFC. 158 Further, section 6.3.4. Processing Received Router Advertisements of 159 RFC4861 [2] specifies host behavior relative to the processing of 160 router advertisements. Specifically, the detection and installation 161 of default routes is clearly specified. 163 Since a CPE can in essence be both router and host. The text in 164 RFC4861 [2] does not clearly specify how such a device should be 165 expected to behave related to the processing of router advertisements 166 specifically related to the installation of default routes. 168 A CPE device that is acting as a host and router may listen to Router 169 Advertisements from the SP network and process them as a host to 170 identify/detect its default-router. In addition this default-router 171 information can be used to install routes on the CPE towards external 172 upstream services and devices. This option can provide a scalable 173 solution for (default-)route detection and population on CPE's based 174 upon received Router Advertisement messages. This mechanism does not 175 require any protocol changes or additional traffic on the wire. 176 However, the behavior of the CPE relative to the processing of Router 177 Advertisements requires additional specification. 179 4. IANA Considerations 181 There are no extra IANA consideration for this document. 183 5. Security Considerations 185 If a CPE device acts as both Router as Host then it will inherit the 186 secruity for both Host as Router as specified in RFC4861 [2]. For 187 the remaining there are no additional security considerations for 188 this document. 190 6. Acknowledgements 192 Concept thinking has been done with Ralph Droms, Bernie Volz, Eric 193 Levy-Abegnoli during IETF70. 195 7. References 197 7.1. Normative References 199 7.2. Informative References 201 [1] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 202 Configuration Protocol (DHCP) version 6", RFC 3633, 203 December 2003. 205 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor 206 Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 208 Authors' Addresses 210 Gunter Van de Velde 211 Cisco Systems 212 De Kleetlaan 6a 213 Diegem 1831 214 Belgium 216 Phone: +32 2704 5473 217 Email: gunter@cisco.com 219 John Jason Brzozowski 220 Comcast Cable 221 1800 Bishops Gate Boulevard 222 Mt. Laurel, NJ 08054 223 USA 225 Phone: +1 609 377 6594 226 Email: john_brzozowski@cable.comcast.com 228 Shin Miyakawa 229 NTT Communications 230 Tokyo, 231 Japan 233 Phone: +81-3-6800-3262 234 Email: miyakawa@nttv6.jp 236 Full Copyright Statement 238 Copyright (C) The IETF Trust (2008). 240 This document is subject to the rights, licenses and restrictions 241 contained in BCP 78, and except as set forth therein, the authors 242 retain all their rights. 244 This document and the information contained herein are provided on an 245 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 246 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 247 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 248 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 249 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 250 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 252 Intellectual Property 254 The IETF takes no position regarding the validity or scope of any 255 Intellectual Property Rights or other rights that might be claimed to 256 pertain to the implementation or use of the technology described in 257 this document or the extent to which any license under such rights 258 might or might not be available; nor does it represent that it has 259 made any independent effort to identify any such rights. Information 260 on the procedures with respect to rights in RFC documents can be 261 found in BCP 78 and BCP 79. 263 Copies of IPR disclosures made to the IETF Secretariat and any 264 assurances of licenses to be made available, or the result of an 265 attempt made to obtain a general license or permission for the use of 266 such proprietary rights by implementers or users of this 267 specification can be obtained from the IETF on-line IPR repository at 268 http://www.ietf.org/ipr. 270 The IETF invites any interested party to bring to its attention any 271 copyrights, patents or patent applications, or other proprietary 272 rights that may cover technology that may be required to implement 273 this standard. Please address the information to the IETF at 274 ietf-ipr@ietf.org. 276 Acknowledgment 278 Funding for the RFC Editor function is provided by the IETF 279 Administrative Support Activity (IASA).