idnits 2.17.1 draft-ietf-6man-dad-proxy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (June 20, 2011) is 4693 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) == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-17 == Outdated reference: A later version (-14) exists of draft-ietf-savi-fcfs-09 == Outdated reference: A later version (-11) exists of draft-ietf-savi-send-05 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group F. Costa 3 Internet-Draft J-M. Combes 4 Intended status: Standards Track X. Pougnard 5 Expires: December 22, 2011 France Telecom Orange 6 H. Li 7 Huawei Technologies 8 June 20, 2011 10 Duplicate Address Detection Proxy 11 draft-ietf-6man-dad-proxy-01 13 Abstract 15 The document describes a mechanism allowing the use of Duplicate 16 Address Detection (DAD) by IPv6 nodes in a point-to-multipoint 17 architecture with "split-horizon" forwarding scheme. Based on the 18 DAD signalling, the first hop router stores in a Binding Table all 19 known IPv6 addresses used on a point-to-multipoint domain (e.g. 20 VLAN). When a node performs DAD for an address already used by 21 another node, the first hop router replies instead of this last one. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 22, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Why existing IETF solutions are not sufficient? . . . . . . . 4 61 3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 5 62 3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . . 5 63 3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . 5 64 3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6 65 4. Duplicate Address Detection Proxy (DAD-Proxy) 66 specifications . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. DAD-Proxy Data structure . . . . . . . . . . . . . . . . . 6 68 4.2. DAD-Proxy mechanism . . . . . . . . . . . . . . . . . . . 6 69 4.2.1. No entry exists for the tentative address . . . . . . 7 70 4.2.2. An entry already exists for the tentative address . . 7 71 4.2.3. Confirmation of reachability to check the validity 72 of the conflict . . . . . . . . . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 6.1. Interoperability with SEND . . . . . . . . . . . . . . . . 10 76 6.2. IP source address spoofing protection . . . . . . . . . . 11 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 This document explains why Duplicate Address Detection (DAD) 87 mechanism [RFC4862] cannot be used in a point-to-multipoint 88 architecture with "split-horizon" forwarding scheme. One of the main 89 reasons is that, because of this forwarding scheme, IPv6 nodes on the 90 same point-to-multipoint domain cannot have direct communication: any 91 communication between them must go through the first hop router of 92 the same domain. 94 This document also specifies a function called DAD proxy allowing the 95 use of DAD by the nodes on the same point-to-multipoint domain with 96 "split-horizon" forwarding scheme. It only impacts the first hop 97 router and it doesn't need modifications on the other IPv6 nodes. 98 This mechanism is fully effective if all the nodes of a point-to- 99 multipoint domain (except the DAD proxy itself) perform DAD. 100 However, if it is necessary to cover the scenarios where this 101 assumption is not met, additional solutions could be defined in the 102 future that work in conjunction with the mechanism described here. 104 It is assumed in this document that Link-layer addresses on a point- 105 to-multipoint domain are unique from the first hop router's point of 106 view (e.g. in an untrusted Ethernet architecture this assumption can 107 be guaranteed thanks to mechanisms such as "MAC Address Translation" 108 performed by an aggregation device between IPv6 nodes and the first 109 hop router). 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Background 119 Terminology in this document follows that in Neighbor Discovery for 120 IP version 6 (IPv6) document [RFC4861] and IPv6 Stateless Address 121 Autoconfiguration document [RFC4862]. In addition, this section 122 defines additional terms related to DSL and Fiber access 123 architectures, which are an important case where the solution 124 described in this document can be used: 126 Customer Premises Equipment (CPE) 127 The first IPv6 node in a customer's network. 129 Access Node (AN) 130 The first aggregation point in the public access network. It 131 is considered as a L2 bridge in this document. 133 Broadband Network Gateway (BNG) 134 The first hop router from the CPE's point of view. 136 VLAN N:1 architecture 137 A point-to-multipoint architecture where many CPEs are 138 connected to the same VLAN. The CPEs may be connected on the 139 same or different Access Nodes. 141 split-horizon model 142 A forwarding scheme where CPEs cannot have direct layer 2 143 communications between them (i.e. IP flows must be forwarded 144 through the BNG via routing). 146 The following figure shows where are the different entities defined 147 above. 149 +------+ +----+ 150 | CPE3 |---------| AN | 151 +------+ +----+ 152 | 153 | 154 +------+ +----+ 155 | CPE2 |---------| AN |---+ 156 +------+ +----+ | 157 +------+ | | 158 | CPE1 |------------+ | 159 +------+ +-----+ 160 | BNG |--- Internet 161 +-----+ 163 Figure 1: DSL and Fiber access Architecture 165 3. Why existing IETF solutions are not sufficient? 167 In a DSL or Fiber access architecture depicted in Figure 1, CPE1,2,3 168 and the BNG are IPv6 nodes, while AN is a L2 bridge providing 169 connectivity between the BNG and each CPE. The AN enforces a split- 170 horizon model so that CPEs can only send and receive frames (e.g. 171 Ethernet frames) to and from the BNG but not to each other. That 172 said, the BNG is on a same link with all CPE, but one CPE is not on a 173 same link with any other CPE. 175 3.1. Duplicate Address Detection 177 Duplicate Address Dectection (DAD) [RFC4862] is performed when an 178 IPv6 node verifies the uniqueness of a tentative IPv6 address. This 179 node sends a Neighbor Solicitation (NS) message with the IP 180 destination set to solicited-node multicast address of the tentative 181 address. This NS message is multicasted to other nodes on a same 182 link. When the tentative address is already used on the link by 183 another node, this last one replies with a Neighbor Advertisement 184 (NA) message to inform the first node. So when performing DAD, a 185 node expects the NS messages are received by other nodes. 187 However, in a point-to-multipoint network with split-horizon 188 forwarding scheme implemented in the AN, the CPEs are prevented from 189 talking to each other directly. All packets sent out from a CPE 190 would be forwarded by AN only to the BNG but not to any other CPE. 191 That said, NS messages sent by a certain CPE will be received only by 192 the BNG and will not reach other CPEs. So, other CPEs have no idea 193 that a certain IPv6 address is used by another CPE. That means, in a 194 network with split-horizon, DAD per [RFC4862] can't work properly 195 without an additional helper. 197 3.2. Neighbor Discovery Proxy 199 Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND 200 messages between different IP links where the subnet prefix is the 201 same. A ND Proxy function on a bridge ensures that packets between 202 nodes on different segments can be received by this function and have 203 the correct link-layer address type on each segment. When the ND 204 proxy receives a multicast ND message, it forwards it to all other 205 interfaces on a same link. 207 In DSL or Fiber networks, when AN, acting as a ND Proxy, receives a 208 ND message from a CPE, it will forward it to the BNG but none of 209 other CPEs, as only the BNG is on the same link with the CPE. Hence, 210 implementing ND Proxy on AN would not help a CPE acknowledge link- 211 local addresses used by other CPEs. 213 As the BNG must not forward link-local scoped messages sent from a 214 CPE to other CPEs, ND Proxy cannot be implemented in the BNG. 216 3.3. 6LoWPAN Neighbor Discovery 218 [I-D.ietf-6lowpan-nd] defines an optional modification of DAD for a 219 6LowPAN. When a 6LoWPAN node wants to configure an IPv6 address, it 220 registers that address with one or more of its default router using 221 the Address Registration option (ARO). If this address is already 222 owned by another node, the router informs the 6LoWPAN node this 223 address cannot be configured. 225 A problem for this mechanism is that it requires modifications in 226 hosts in order to support the Address Registration option. 228 3.4. IPv6 Mobility Manager 230 According to [RFC3775], a home agent acts as a proxy for mobile nodes 231 when these last ones are away from the home network: the home agent 232 defends an mobile node's home address by replying to NS messages with 233 NA messages. 235 There is a problem for this mechanism if it is applied in a DSL or 236 Fiber public access network. Operators of such networks require a NA 237 message is only received by the sender of the corresponding NS 238 message, for security and scalability reasons. However, the home 239 agent per [RFC3775] multicasts NA messages on the home link and all 240 nodes on this link will receive these NA messages. This shortcoming 241 prevents this mechanism being deployed in DSL or Fiber access 242 networks directly. 244 4. Duplicate Address Detection Proxy (DAD-Proxy) specifications 246 4.1. DAD-Proxy Data structure 248 A BNG needs to store in a Binding Table information related to the 249 IPv6 addresses generated by any CPE. This must be done per point to 250 multipoint domain (e.g. per Ethernet VLAN). Each entry in this 251 Binding Table MUST contain the following fields: 253 o IPv6 Address 255 o Link-layer Address 257 For security or performances reasons, it must be possible to limit 258 the number of IPv6 Addresses per Link-layer Address (possibly, but 259 not necessarily, to 1). 261 4.2. DAD-Proxy mechanism 263 When a CPE performs DAD, as specified in [RFC4862], it sends a 264 Neighbor Solicitation (NS) message, with the unspecified address as 265 source address, in order to check if a tentative address is already 266 in use on the link. The BNG receives this message and MUST perform 267 actions depending on the information in the Binding Table. 269 4.2.1. No entry exists for the tentative address 271 When there is no entry for the tentative address, the BNG MUST create 272 one with following information: 274 o IPv6 Address Field set to the tentative address in the NS message. 276 o Link-layer Address Field set to the Link-layer source address in 277 the Link-layer Header of the NS message. 279 The BNG MUST NOT reply to the CPE or forward the NS message. 281 4.2.2. An entry already exists for the tentative address 283 When there is an entry for the tentative address, the BNG MUST check 284 the following conditions: 286 o The address in the Target Address Field in the NS message is equal 287 to the address in the IPv6 Address Field in the entry. 289 o The source address of the IPv6 Header in the NS message is equal 290 to the unspecified address. 292 When these conditions are met and the source address of the Link- 293 Layer Header in the NS message is equal to the address in the Link- 294 Layer Address Field in the entry, that means the CPE is still 295 performing DAD for this address. The BNG MUST NOT reply to the CPE 296 or forward the NS message. 298 When these conditions are met and the source address of the Link- 299 Layer Header in the NS message is not equal to the address in the 300 Link-Layer Address Field in the entry, that means possibly another 301 CPE performs DAD for an already owned address. The BNG then has to 302 verify whether there is a real conflict by checking if the CPE whose 303 IPv6 address is in the entry is still connected. In the following, 304 we will call IPv6-CPE1 the IPv6 address of the existing entry, Link- 305 layer-CPE1 the Link-layer address of that entry and Link-layer-CPE2 306 the Link-layer address of the CPE which is performing DAD, which is 307 different from Link-layer-CPE1. 309 The BNG MUST check if the potential address conflict is real. In 310 particular: 312 o If IPv6-CPE1 is in the Neighbor Cache and it is associated with 313 Link-layer-CPE1, the reachability of IPv6-CPE1 MUST be confirmed 314 as explained in Section 4.2.3. 316 o If IPv6-CPE1 is in the Neighbor Cache, but it is associated with 317 another Link-layer address than Link-layer-CPE1, that means that 318 there is possibly a conflict with another CPE, but that CPE did 319 not perform DAD. This situation is out of the scope of this 320 document, since one assumption made above is that all the nodes of 321 a point-to-multipoint domain (except the DAD proxy itself) perform 322 DAD. This case could be covered in the future by additional 323 solutions that work in conjunction with the DAD proxy. 325 o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST 326 create a new entry based on the information of the entry in the 327 Binding Table. This step is necessary in order to trigger the 328 reachibility check as explained in Section 4.2.3. The entry in 329 the Neighbor Cache MUST be created based on the algorithm defined 330 in section 7.3.3 of [RFC4861], in particular by considering the 331 case as if a packet other than a solicited Neighbor Advertisement 332 was received from IPv6-CPE1. That means that the new entry of the 333 Neighbor Cache MUST contain the following information: 335 * IPv6 address: IPv6-CPE1 337 * Link-layer address: Link-layer-CPE1 339 * State: STALE 341 Then the reachability of IPv6-CPE1 MUST be confirmed as soon as 342 possible following the procedure explained in section 4.2.3. 344 4.2.3. Confirmation of reachability to check the validity of the 345 conflict 347 Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the 348 reachability of IPv6-CPE1 is checked by using the NUD (Neighbor 349 Unreachibility Detection) mechanism described in section 7.3.1 of 350 [RFC4861]. This mechanism MUST be triggered as if a packet has to be 351 sent to IPv6-CPE1. Note that in some cases this mechanism does not 352 do anything, for instance if the state of the entry is REACHABLE and 353 a positive confirmation was received recently that the forward path 354 to the IPv6-CPE1 was functioning properly (see RFC 4861 for more 355 details). 357 Next, the behavior of the BNG depends on the result of the NUD 358 process, as explained in the following sections. 360 4.2.3.1. The result of the NUD process is negative 362 If the result of the NUD process is negative (i.e. if this process 363 removes IPv6-CPE1 from the Neighbor Cache), that means that the 364 potential conflict is not real. 366 The conflicting entry in the Binding Table (Link-layer-CPE1) is 367 deleted and it is replaced by a new entry with the same IPv6 address, 368 but the Link-layer address of the CPE which is performing DAD (Link- 369 layer-CPE2), as explained in Section 4.2.1. 371 4.2.3.2. The result of the NUD process is positive 373 If the result of the NUD process is positive (i.e. if after this 374 process the state of IPv6-CPE1 is REACHABLE), that means that the 375 potential conflict is real. 377 As shown in Figure 2, the BNG MUST reply to CPE that is performing 378 DAD (CPE2 in Figure 1) with a NA message which has the following 379 format: 381 Layer 2 Header Fields: 383 Source Address 384 The Link-layer address of the interface on which the BNG 385 received the NS message. 387 Destination Address 388 The source address in the Layer 2 Header of the NS 389 message received by the BNG (i.e. Link-layer-CPE2) 391 IPv6 Header Fields: 393 Source Address 394 An address assigned to the interface from which the 395 advertisement is sent. 397 Destination Address 398 The all-nodes multicast address. 400 ICMPv6 Fields: 402 Target Address 403 The tentative address already used (i.e. IPv6-CPE1). 405 Target Link-layer address 406 The Link-layer address of the interface on which the BNG 407 received the NS message. 409 CPE1 CPE2 BNG 410 | | | 411 (a)| | | 412 | | | 413 (b)|===================>| 414 | | |(c) 415 | | | 416 | (d)| | 417 | | | 418 | (e)|=========>| 419 | | | 420 | |<=========|(f) 421 | | | 423 (a) CPE1 generated a tentative address 424 (b) CPE1 performs DAD for this one 425 (c) BNG updates its Binding Table 426 (d) CPE2 generates a same tentative address 427 (e) CPE2 performs DAD for this one 428 (f) BNG informs CPE2 that DAD fails 430 Figure 2 432 The BNG and the CPE MUST support the Unicast Transmission on Link- 433 layer of IPv6 Multicast Messages [RFC6085], to be able, respectively, 434 to generate and to process such a packet format. 436 5. IANA Considerations 438 No new options or messages are defined in this document. 440 6. Security Considerations 442 6.1. Interoperability with SEND 444 If SEcure Neighbor Discovery (SEND) [RFC3971] is used, the mechanism 445 specified in this document may break the security. Indeed, if an 446 entry already exists and the BNG has to send a reply (cf. 447 Section 4.2.2), the BNG doesn't own the private key(s) associated 448 with to the Cryptographically Generated Addresses (CGA) [RFC3972] to 449 correctly sign the proxied ND messages [RFC5909]. 451 To keep the same level of security, Secure Proxy ND Support for SEND 452 [I-D.ietf-csi-proxy-send] SHOULD be used and implemented on the BNG 453 and the CPEs. 455 6.2. IP source address spoofing protection 457 To ensure a protection against IP source address spoofing in data 458 packets, this proposal may be used in combinaison with Source Address 459 Validation Improvement (SAVI) mechanisms [I-D.ietf-savi-fcfs] 460 [I-D.ietf-savi-send]. 462 7. Acknowledgments 464 TbD 466 8. References 468 8.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 474 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 475 September 2007. 477 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 478 Address Autoconfiguration", RFC 4862, September 2007. 480 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 481 "Address Mapping of IPv6 Multicast Packets on Ethernet", 482 RFC 6085, January 2011. 484 8.2. Informative References 486 [I-D.ietf-6lowpan-nd] 487 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 488 Discovery Optimization for Low Power and Lossy Networks 489 (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), 490 June 2011. 492 [I-D.ietf-csi-proxy-send] 493 Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 494 Martinez, "Secure Proxy ND Support for SEND", 495 draft-ietf-csi-proxy-send-05 (work in progress), May 2010. 497 [I-D.ietf-savi-fcfs] 498 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 499 SAVI: First-Come First-Serve Source-Address Validation for 500 Locally Assigned IPv6 Addresses", draft-ietf-savi-fcfs-09 501 (work in progress), April 2011. 503 [I-D.ietf-savi-send] 504 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 505 Address Validation Implementation", 506 draft-ietf-savi-send-05 (work in progress), April 2011. 508 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 509 in IPv6", June 2004. 511 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 512 Neighbor Discovery (SEND)", RFC 3971, March 2005. 514 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 515 RFC 3972, March 2005. 517 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 518 Proxies", RFC 4389, April 2006. 520 [RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing 521 Neighbor Discovery Proxy: Problem Statement", RFC 5909, 522 July 2010. 524 Appendix A. Open issues 526 o What happens when the BNG receives a NA message with O-bit set to 527 1 (e.g. the Link-Layer address of the CPE has changed)? 529 Authors' Addresses 531 Fabio Costa 532 France Telecom Orange 533 38 rue du General Leclerc 534 92794 Issy-les-Moulineaux Cedex 9 535 France 537 Email: fabio.costa@orange-ftgroup.com 538 Jean-Michel Combes 539 France Telecom Orange 540 38 rue du General Leclerc 541 92794 Issy-les-Moulineaux Cedex 9 542 France 544 Email: jeanmichel.combes@orange-ftgroup.com 546 Xavier Pougnard 547 France Telecom Orange 548 2 avenue Pierre Marzin 549 22300 Lannion 550 France 552 Email: xavier.pougnard@orange-ftgroup.com 554 Hongyu Li 555 Huawei Technologies 556 Huawei Industrial Base 557 Shenzhen 558 China 560 Email: lihy@huawei.com