idnits 2.17.1 draft-dupont-mext-dhcrelay-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 230. 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 : ---------------------------------------------------------------------------- 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 18, 2008) is 5884 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group F. Dupont 3 Internet-Draft ISC 4 Intended status: Experimental W. Haddad 5 Expires: August 21, 2008 Ericsson Research 6 February 18, 2008 8 DHCPv6 Relay Agents and NEMO 9 draft-dupont-mext-dhcrelay-00.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 Internet- 21 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 August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The IPv6 network mobility (NEMO) configuration relies on a prefix 43 delegation service to fulfill its task. Such service has already 44 been described in two different proposals, one is based on DHCPv6 and 45 the other extends NEMO signaling. 47 However, both failed to gather consensus. This memo describes how 48 DHCPv6 Relay Agents can be used in order to provide the missing 49 flexibility and pave the way for a solution. 51 1. Introduction 53 One aspect of network mobility support is the assignment of a prefix 54 or a set of prefixes to a Mobile Router (MR) for use on the links in 55 the Mobile Network. For this purpose, two solutions have been 56 proposed. The first one (described in [NEMOdhc]) uses DHPCv6 57 [RFC3315] Prefix Delegation [RFC3633] in the tunnel between the MR 58 and its Home Agent (HA), while the second [NEMOpd] is an adhoc 59 extension of NEMO signaling. 61 While DHCPv6 Prefix Delegation is the standard way to provide the 62 Prefix Delegation service, using it directly over the MR-HA tunnel is 63 far from immediate and a source of complexities. In an attempt to 64 avoid these complexities, the second proposal did not reuse the 65 DHCPv6 Prefix Delegation framework but failed to gain a rough 66 consensus as it went against the DHCPv6 mainstream. 68 In order to improve this situation, the use of DHCPv6 Relay Agents 69 has been suggested but was never written down and thus, had a limited 70 effect. This document aims to explain how a clever use of DHCPv6 71 Relay Agents can inject the desired flexibility to extend the 72 applicability of DHCPv6 in general and DHCPv6 Prefix Delegation in 73 particular to environments with very different constraints than in 74 the original design. 76 2. A short description of DHCPv6 Relay Agent function 78 The main function of DHCPv6 Relay Agents is to allow DHCPv6 Servers 79 to be located anywhere in the network and not only on the same link 80 than their Clients. But DHCPv6 extends it with the support of 81 multiple Relays, the resulting topology from a Client is a tree with: 82 - the Client as the tree root 83 - Relays as intermediate nodes 84 - Servers as leaves 85 Relays forward messages from downstream Clients or Relays to upstream 86 Servers or Relays, using unicast and/or multicast, and forward 87 responses back in the other way. 89 DHCPv6 Relay Agents use two specific messages (Relay-forward and 90 Relay-repl). These messages share a common header: 91 - a message type 92 - a hop-count (to detect loops) 93 - a link-address (to identify the downstream link) 94 - a peer-address (to identity the downstream Client or Relay) 95 To help the identification of the downstream link, the Relay may 96 insert an Interface-id option which will be reflected back by Servers 97 in Relay-repl messages. The content of this option is opaque, i.e., 98 Servers do not parse it. 100 On another side, for the identification of DHCPv6 Clients, Relay 101 Agents may insert Subscriber-id [RFC4580] or Remote-id [RFC4649] 102 options in Relay-forward messages. 104 3. Flexibility introduced by the use of DHCPv6 Relay Agents 106 DHCPv6 mandates the Client to use link-local address and multicast to 107 communicate with an onlink Server or Relay. Such design makes sense 108 for global address assignments but is a very annoying constraint in 109 the MR-HA context. 111 Since a Relay does not have such constraint, the idea is to co-locate 112 a Relay in the MR at the MR end of the tunnel. 114 4. Transport of DHCPv6 messages 116 DHCPv6 messages can be easily encapsulated, in fact relaying 117 encapsulates recursively DHCPv6 messages in Relay-message options. 118 But when reusing DHCPv6 code, the Relay function is the easiest, 119 i.e., when flexibility is needed to support transport of DHCPv6 120 messages in a not standard way the solution is to use (again) Relays. 121 Consequently, the main argument of NEMO Prefix Delegation [NEMOpd], 122 the overhead to run signaling then prefix delegation after each 123 movement, no more stands as DHCPv6 can be piggy-backed into the 124 mobility signaling. 126 5. Final recommendation 128 If the use of DHCPv6 Relays introduces flexibility, it shoud 129 nevertheless be mentioned that this is not a reason to enforce their 130 use. It follows that the wording should be enough accurate in order 131 to keep the choice between a Relay or another entity. For instance, 132 the DHCPv6 Prefix Delegation for NEMO [NEMOdhc] is right when it 133 allows a Relay or a Server in the Home Agent. 135 6. Acknowledgments 137 The idea described in this document is not new so we are sure it is 138 not our own idea... 140 7. Security Considerations 142 This memo proposes some ways to improve code and security analysis 143 sharing for the Prefix Delegation service so should indirectly help 144 security. 146 8. IANA Considerations 148 None. 150 9. References 152 9.1. Normative References 154 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 155 C., and M. Carney, "Dynamic Host Configuration Protocol 156 for IPv6 (DHCPv6)", RFC 3315, July 2003. 158 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 159 Host Configuration Protocol (DHCP) version 6", RFC 3633, 160 December 2003. 162 9.2. Informative References 164 [NEMOdhc] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for 165 NEMO", draft-ietf-nemo-dhcpv6-pd-03.txt (work in 166 progress), December 2007. 168 [NEMOpd] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix 169 Delegation", draft-ietf-nemo-prefix-delegation-02.txt 170 (work in progress), August 2007. 172 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 173 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 174 June 2006. 176 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 177 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 178 August 2006. 180 Authors' Addresses 182 Francis Dupont 183 ISC 185 Email: Francis.Dupont@fdupont.fr 187 Wassim Haddad 188 Ericsson Research 190 Email: Wassim.Haddad@ericsson.com 192 Full Copyright Statement 194 Copyright (C) The IETF Trust (2008). 196 This document is subject to the rights, licenses and restrictions 197 contained in BCP 78, and except as set forth therein, the authors 198 retain all their rights. 200 This document and the information contained herein are provided on an 201 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 202 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 203 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 204 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 205 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 206 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 208 Intellectual Property 210 The IETF takes no position regarding the validity or scope of any 211 Intellectual Property Rights or other rights that might be claimed to 212 pertain to the implementation or use of the technology described in 213 this document or the extent to which any license under such rights 214 might or might not be available; nor does it represent that it has 215 made any independent effort to identify any such rights. Information 216 on the procedures with respect to rights in RFC documents can be 217 found in BCP 78 and BCP 79. 219 Copies of IPR disclosures made to the IETF Secretariat and any 220 assurances of licenses to be made available, or the result of an 221 attempt made to obtain a general license or permission for the use of 222 such proprietary rights by implementers or users of this 223 specification can be obtained from the IETF on-line IPR repository at 224 http://www.ietf.org/ipr. 226 The IETF invites any interested party to bring to its attention any 227 copyrights, patents or patent applications, or other proprietary 228 rights that may cover technology that may be required to implement 229 this standard. Please address the information to the IETF at 230 ietf-ipr@ietf.org. 232 Acknowledgment 234 Funding for the RFC Editor function is provided by the IETF 235 Administrative Support Activity (IASA).