idnits 2.17.1 draft-ietf-6man-dad-proxy-07.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 (April 9, 2013) is 4006 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 (-15) exists of draft-ietf-savi-mix-03 == Outdated reference: A later version (-11) exists of draft-ietf-savi-send-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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, Ed. 4 Intended status: Standards Track X. Pougnard 5 Expires: October 11, 2013 France Telecom Orange 6 H. Li 7 Huawei Technologies 8 April 9, 2013 10 Duplicate Address Detection Proxy 11 draft-ietf-6man-dad-proxy-07 13 Abstract 15 The document describes a proxy based mechanism allowing the use of 16 Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- 17 multipoint architecture with "split-horizon" forwarding scheme, 18 primarily deployed for Digital Subscriber Line (DSL) and Fiber access 19 architectures. Based on the DAD signalling, the first hop router 20 stores in a Binding Table all known IPv6 addresses used on a point- 21 to-multipoint domain (e.g. VLAN). When a node performs DAD for an 22 address already used by another node, the first hop router replies 23 instead of this last one. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 11, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Why existing IETF solutions are not sufficient? . . . . . . . 4 63 3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 5 64 3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . . 5 65 3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . 5 66 3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6 67 4. Duplicate Address Detection Proxy (DAD-Proxy) 68 specifications . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. DAD-Proxy Data structure . . . . . . . . . . . . . . . . . 6 70 4.2. DAD-Proxy mechanism . . . . . . . . . . . . . . . . . . . 7 71 4.2.1. No entry exists for the tentative address . . . . . . 7 72 4.2.2. An entry already exists for the tentative address . . 7 73 4.2.3. Confirmation of reachability to check the validity 74 of the conflict . . . . . . . . . . . . . . . . . . . 9 75 5. Manageability Considerations . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 7.1. Interoperability with SEND . . . . . . . . . . . . . . . . 11 79 7.2. IP source address spoofing protection . . . . . . . . . . 11 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 84 Appendix A. DAD Proxy state machine . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 This document specifies a function called Duplicate Address Detection 90 (DAD) proxy allowing the use of DAD by the nodes on the same point- 91 to-multipoint domain with "split-horizon" forwarding scheme, 92 primarily deployed for Digital Subscriber Line (DSL) and Fiber access 93 architectures. It only impacts the first hop router and it doesn't 94 need modifications on the other IPv6 nodes. This mechanism is fully 95 effective if all the nodes of a point-to-multipoint domain (except 96 the DAD proxy itself) perform DAD. 98 This document explains also why DAD mechanism [RFC4862] without a 99 proxy cannot be used in a point-to-multipoint architecture with 100 "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not 101 affected). One of the main reasons is that, because of this 102 forwarding scheme, IPv6 nodes on the same point-to-multipoint domain 103 cannot have direct communication: any communication between them must 104 go through the first hop router of the same domain. 106 It is assumed in this document that Link-layer addresses on a point- 107 to-multipoint domain are unique from the first hop router's point of 108 view (e.g. in an untrusted Ethernet architecture this assumption can 109 be guaranteed thanks to mechanisms such as "MAC Address Translation" 110 performed by an aggregation device between IPv6 nodes and the first 111 hop router). 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Background 121 Terminology in this document follows that in Neighbor Discovery for 122 IP version 6 (IPv6) [RFC4861] and IPv6 Stateless Address 123 Autoconfiguration [RFC4862]. In addition, this section defines 124 additional terms related to Digital Subscriber Line (DSL) and Fiber 125 access architectures, which are an important case where the solution 126 described in this document can be used: 128 Customer Premises Equipment (CPE) 129 The first IPv6 node in a customer's network. 131 Access Node (AN) 132 The first aggregation point in the public access network. It 133 is considered as a L2 bridge in this document. 135 Broadband Network Gateway (BNG) 136 The first hop router from the CPE's point of view. 138 VLAN N:1 architecture 139 A point-to-multipoint architecture where many CPEs are 140 connected to the same VLAN. The CPEs may be connected on the 141 same or different Access Nodes. 143 split-horizon model 144 A forwarding scheme where CPEs cannot have direct layer 2 145 communications between them (i.e. IP flows must be forwarded 146 through the BNG via routing). 148 The following figure shows where are the different entities defined 149 above. 151 +------+ +----+ 152 | CPE3 |---------| AN | 153 +------+ +----+ 154 | 155 | 156 +------+ +----+ 157 | CPE2 |---------| AN |---+ 158 +------+ +----+ | 159 +------+ | | 160 | CPE1 |------------+ | 161 +------+ +-----+ 162 | BNG |--- Internet 163 +-----+ 165 Figure 1: DSL and Fiber access Architecture 167 3. Why existing IETF solutions are not sufficient? 169 In a DSL or Fiber access architecture depicted in Figure 1, CPE1,2,3 170 and the BNG are IPv6 nodes, while AN is a L2 bridge providing 171 connectivity between the BNG and each CPE. The AN enforces a split- 172 horizon model so that CPEs can only send and receive frames (e.g. 173 Ethernet frames) to and from the BNG but not to each other. That 174 said, the BNG is on a same link with all CPE, but one CPE is not on a 175 same link with any other CPE. 177 3.1. Duplicate Address Detection 179 Duplicate Address Detection (DAD) [RFC4862] is performed when an IPv6 180 node verifies the uniqueness of a tentative IPv6 address. This node 181 sends a Neighbor Solicitation (NS) message with the IP destination 182 set to the solicited-node multicast address of the tentative address. 183 This NS message is multicasted to other nodes on the same link. When 184 the tentative address is already used on the link by another node, 185 this last one replies with a Neighbor Advertisement (NA) message to 186 inform the first node. So when performing DAD, a node expects the NS 187 messages to be received by any node currently using the tentative 188 address. 190 However, in a point-to-multipoint network with split-horizon 191 forwarding scheme implemented in the AN, the CPEs are prevented from 192 talking to each other directly. All packets sent out from a CPE are 193 forwarded by the AN only to the BNG but not to any other CPE. NS 194 messages sent by a certain CPE will be received only by the BNG and 195 will not reach other CPEs. So, other CPEs have no idea that a 196 certain IPv6 address is used by another CPE. That means, in a 197 network with split-horizon, DAD, as defined in [RFC4862], can't work 198 properly without an additional help. 200 3.2. Neighbor Discovery Proxy 202 Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND 203 messages between different IP links where the subnet prefix is the 204 same. A ND Proxy function on a bridge ensures that packets between 205 nodes on different segments can be received by this function and have 206 the correct link-layer address type on each segment. When the ND 207 proxy receives a multicast ND message, it forwards it to all other 208 interfaces on a same link. 210 In DSL or Fiber networks, when the AN, acting as a ND Proxy, receives 211 a ND message from a CPE, it will forward it to the BNG but none of 212 other CPEs, as only the BNG is on the same link with the CPE. Hence, 213 implementing ND Proxy on the AN would not help a CPE acknowledge 214 link-local addresses used by other CPEs. 216 As the BNG must not forward link-local scoped messages sent from a 217 CPE to other CPEs, ND Proxy cannot be implemented in the BNG. 219 3.3. 6LoWPAN Neighbor Discovery 221 [RFC6775] defines an optional modification of DAD for a 6LowPAN. 222 When a 6LoWPAN node wants to configure an IPv6 address, it registers 223 that address with one or more of its default routers using the 224 Address Registration option (ARO). If this address is already owned 225 by another node, the router informs the 6LoWPAN node this address 226 cannot be configured. 228 This mechanism requires modifications in all hosts in order to 229 support the Address Registration option. 231 3.4. IPv6 Mobility Manager 233 According to [RFC6275], a home agent acts as a proxy for mobile nodes 234 when they are away from the home network: the home agent defends an 235 mobile node's home address by replying to NS messages with NA 236 messages. 238 There is a problem for this mechanism if it is applied in a DSL or 239 Fiber public access network. Operators of such networks require a NA 240 message is only received by the sender of the corresponding NS 241 message, for security and scalability reasons. However, the home 242 agent per [RFC6275] multicasts NA messages on the home link and all 243 nodes on this link will receive these NA messages. This shortcoming 244 prevents this mechanism being deployed in DSL or Fiber access 245 networks directly. 247 4. Duplicate Address Detection Proxy (DAD-Proxy) specifications 249 At first, it is important to note that as this mechanism is strongly 250 based on DAD [RFC4862], it is not completely reliable and the goal of 251 this document is not to fix DAD. 253 4.1. DAD-Proxy Data structure 255 A BNG needs to store in a Binding Table information related to the 256 IPv6 addresses generated by any CPE. This Binding Table can be 257 distinct from the Neighbor Cache. This must be done per point to 258 multipoint domain (e.g. per Ethernet VLAN). Each entry in this 259 Binding Table MUST contain the following fields: 261 o IPv6 Address 263 o Link-layer Address 265 For security or performances reasons, it must be possible to limit 266 the number of IPv6 Addresses per Link-layer Address (possibly, but 267 not necessarily, to 1). 269 On the reception of an unsolicited NA (e.g., when a CPE wishes to 270 inform its neighbors of a new link-layer address) for an IPv6 address 271 already recorded in the Binding Table, each entry associated to this 272 IPv6 address MUST be updated consequently: the current Link-layer 273 Address is replaced by the one included in the unsolicited NA 274 message. 276 For security or performances reasons, the Binding Table MUST be large 277 enough for the deployment in which it is used: if the Binding Table 278 is distinct from the Neighbor Cache, it MUST have at least the same 279 size as this last one. Implementations MUST either state the fixed 280 size of Binding Table that they support or make the size 281 configurable. In the latter case, implementations MUST state the 282 largest Binding Table size that they support. Additionally, 283 implementations SHOULD allow an operator to enquire the current 284 occupancy level of the Binding Table to determine if it is about to 285 become full. Implementations encountering a full Binding Table will 286 likely handle it in a way similar to NS message loss. 288 It is recommended to apply technical solutions to minimize the risk 289 that the Binding Table becomes full. These solutions are out of the 290 scope of this document. 292 4.2. DAD-Proxy mechanism 294 When a CPE performs DAD, as specified in [RFC4862], it sends a 295 Neighbor Solicitation (NS) message, with the unspecified address as 296 the source address, in order to check if a tentative address is 297 already in use on the link. The BNG receives this message and MUST 298 perform actions specified in the following sections based on the 299 information in the Binding Table. 301 4.2.1. No entry exists for the tentative address 303 When there is no entry for the tentative address, the BNG MUST create 304 one with the following information: 306 o IPv6 Address Field set to the tentative address in the NS message. 308 o Link-layer Address Field set to the Link-layer source address in 309 the Link-layer Header of the NS message. 311 The BNG MUST NOT reply to the CPE or forward the NS message. 313 4.2.2. An entry already exists for the tentative address 315 When there is an entry for the tentative address, the BNG MUST check 316 the following conditions: 318 o The address in the Target Address Field in the NS message is equal 319 to the address in the IPv6 Address Field in the entry. 321 o The source address of the IPv6 Header in the NS message is equal 322 to the unspecified address. 324 When these conditions are met and the source address of the Link- 325 Layer Header in the NS message is equal to the address in the Link- 326 Layer Address Field in the entry, that means the CPE is still 327 performing DAD for this address. The BNG MUST NOT reply to the CPE 328 or forward the NS message. 330 When these conditions are met and the source address of the Link- 331 Layer Header in the NS message is not equal to the address in the 332 Link-Layer Address Field in the entry, that means possibly another 333 CPE performs DAD for an already owned address. The BNG then has to 334 verify whether there is a real conflict by checking if the CPE whose 335 IPv6 address is in the entry is still connected. In the following, 336 we will call IPv6-CPE1 the IPv6 address of the existing entry in the 337 Binding Table, Link-layer-CPE1 the Link-layer address of that entry 338 and Link-layer-CPE2 the Link-layer address of the CPE which is 339 performing DAD, which is different from Link-layer-CPE1. 341 The BNG MUST check if the potential address conflict is real. In 342 particular: 344 o If IPv6-CPE1 is in the Neighbor Cache and it is associated with 345 Link-layer-CPE1, the reachability of IPv6-CPE1 MUST be confirmed 346 as explained in Section 4.2.3. 348 o If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is 349 associated with another Link-layer address than Link-layer-CPE1, 350 that means that there is possibly a conflict with another CPE, but 351 that CPE did not perform DAD. This situation is out of the scope 352 of this document, since one assumption made above is that all the 353 nodes of a point-to-multipoint domain (except the DAD proxy 354 itself) perform DAD. 356 o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST 357 create a new entry based on the information of the entry in the 358 Binding Table. This step is necessary in order to trigger the 359 reachibility check as explained in Section 4.2.3. The entry in 360 the Neighbor Cache MUST be created based on the algorithm defined 361 in section 7.3.3 of [RFC4861], in particular by considering the 362 case as if a packet other than a solicited Neighbor Advertisement 363 was received from IPv6-CPE1. That means that the new entry of the 364 Neighbor Cache MUST contain the following information: 366 * IPv6 address: IPv6-CPE1 367 * Link-layer address: Link-layer-CPE1 369 * State: STALE 371 Then the reachability of IPv6-CPE1 MUST be confirmed as soon as 372 possible following the procedure explained in section 4.2.3. 374 4.2.3. Confirmation of reachability to check the validity of the 375 conflict 377 Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the 378 reachability of IPv6-CPE1 is checked by using the NUD (Neighbor 379 Unreachibility Detection) mechanism described in section 7.3.1 of 380 [RFC4861]. This mechanism MUST be triggered as if a packet has to be 381 sent to IPv6-CPE1. Note that in some cases this mechanism does not 382 do anything, for instance if the state of the entry is REACHABLE and 383 a positive confirmation was received recently that the forward path 384 to the IPv6-CPE1 was functioning properly (see RFC 4861 for more 385 details). 387 Next, the behavior of the BNG depends on the result of the NUD 388 process, as explained in the following sections. 390 4.2.3.1. The result of the NUD process is negative 392 If the result of the NUD process is negative (i.e. if this process 393 removes IPv6-CPE1 from the Neighbor Cache), that means that the 394 potential conflict is not real. 396 The conflicting entry in the Binding Table (Link-layer-CPE1) is 397 deleted and it is replaced by a new entry with the same IPv6 address, 398 but the Link-layer address of the CPE which is performing DAD (Link- 399 layer-CPE2), as explained in Section 4.2.1. 401 4.2.3.2. The result of the NUD process is positive 403 If the result of the NUD process is positive (i.e. if after this 404 process the state of IPv6-CPE1 is REACHABLE), that means that the 405 potential conflict is real. 407 As shown in Figure 2, the BNG MUST reply to CPE that is performing 408 DAD (CPE2 in Figure 1) with a NA message which has the following 409 format: 411 Layer 2 Header Fields: 413 Source Address 414 The Link-layer address of the interface on which the BNG 415 received the NS message. 417 Destination Address 418 The source address in the Layer 2 Header of the NS 419 message received by the BNG (i.e. Link-layer-CPE2) 421 IPv6 Header Fields: 423 Source Address 424 An address assigned to the interface from which the 425 advertisement is sent. 427 Destination Address 428 The all-nodes multicast address. 430 ICMPv6 Fields: 432 Target Address 433 The tentative address already used (i.e. IPv6-CPE1). 435 Target Link-layer address 436 The Link-layer address of the interface on which the BNG 437 received the NS message. 439 CPE1 CPE2 BNG 440 | | | 441 (a)| | | 442 | | | 443 (b)|===================>| 444 | | |(c) 445 | | | 446 | (d)| | 447 | | | 448 | (e)|=========>| 449 | | | 450 | |<=========|(f) 451 | | | 453 (a) CPE1 generated a tentative address 454 (b) CPE1 performs DAD for this one 455 (c) BNG updates its Binding Table 456 (d) CPE2 generates a same tentative address 457 (e) CPE2 performs DAD for this one 458 (f) BNG informs CPE2 that DAD fails 459 Figure 2 461 The BNG and the CPE MUST support the Unicast Transmission on Link- 462 layer of IPv6 Multicast Messages [RFC6085], to be able, respectively, 463 to generate and to process such a packet format. 465 5. Manageability Considerations 467 The BNG SHOULD support a mechanism to log and emit alarms whenever a 468 duplication of IPv6 addresses is detected by the DAD-Proxy function. 469 Moreover, the BNG SHOULD implement a function to allow an operator to 470 access logs and to see the current entries in the Binding Table. The 471 management of access rights to get this information is out of the 472 scope of this document. 474 6. IANA Considerations 476 No new options or messages are defined in this document. 478 7. Security Considerations 480 7.1. Interoperability with SEND 482 The mechanism described in this document will not interoperate with 483 SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG 484 not owning the private key associated with the Cryptographically 485 Generated Address (CGA) [RFC3972] needed to correctly sign the 486 proxied ND messages [RFC5909]. 488 Secure Proxy ND Support for SEND [RFC6496] has been specified to 489 address this limitation, and SHOULD be implemented and used on the 490 BNG and the CPEs. 492 7.2. IP source address spoofing protection 494 To ensure protection against IP source address spoofing in data 495 packets, this proposal can be used in combinaison with Source Address 496 Validation Improvement (SAVI) mechanisms [RFC6620] 497 [I-D.ietf-savi-send] [I-D.ietf-savi-mix]. 499 If so, the SAVI device is the BNG and the Binding Anchor for a CPE is 500 its MAC address, which is assumed to be unique in this document (cf. 501 Section 1). 503 8. Acknowledgments 505 The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh 506 Krishnan and Tassos Chatzithomaoglou for their comments. The authors 507 would like also to thank the IETF 6man WG members and the BBF 508 community for their support. 510 9. References 512 9.1. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 518 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 519 September 2007. 521 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 522 Address Autoconfiguration", RFC 4862, September 2007. 524 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 525 "Address Mapping of IPv6 Multicast Packets on Ethernet", 526 RFC 6085, January 2011. 528 9.2. Informative References 530 [I-D.ietf-savi-mix] 531 Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI 532 for Mixed Address Assignment Methods Scenario", 533 draft-ietf-savi-mix-03 (work in progress), November 2012. 535 [I-D.ietf-savi-send] 536 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 537 Address Validation Implementation", 538 draft-ietf-savi-send-09 (work in progress), April 2013. 540 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 541 Neighbor Discovery (SEND)", RFC 3971, March 2005. 543 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 544 RFC 3972, March 2005. 546 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 547 Proxies (ND Proxy)", RFC 4389, April 2006. 549 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 550 PPP", RFC 5072, September 2007. 552 [RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing 553 Neighbor Discovery Proxy: Problem Statement", RFC 5909, 554 July 2010. 556 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 557 in IPv6", RFC 6275, July 2011. 559 [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 560 Martinez, "Secure Proxy ND Support for SEcure Neighbor 561 Discovery (SEND)", RFC 6496, February 2012. 563 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 564 SAVI: First-Come, First-Served Source Address Validation 565 Improvement for Locally Assigned IPv6 Addresses", 566 RFC 6620, May 2012. 568 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 569 "Neighbor Discovery Optimization for IPv6 over Low-Power 570 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 571 November 2012. 573 Appendix A. DAD Proxy state machine 575 This appendix, informative, contains a summary (cf. Table 1) of the 576 actions done by the BNG when it receives a DAD based NS (DAD-NS) 577 message. The tentative address in this message is IPv6-CPE1 and the 578 associated Link-layer address is Link-layer-CPE2. The actions are 579 precisely specified in Section 4.2. 581 +------------+---------------------+-------------------+------------+ 582 | Event | Check | Action | New event | 583 +------------+---------------------+-------------------+------------+ 584 | DAD-NS | o No entry for | Create an entry | - | 585 | message | IPv6-CPE1 in the | for IPv6-CPE1 | | 586 | reception. | Binding Table. | bound to | | 587 | | | Link-layer-CPE2 | | 588 | | | in the Binding | | 589 | | | Table. | | 590 | | o Entry for | - | Existing | 591 | | IPv6-CPE1 in the | | entry | 592 | | Binding Table. | | | 593 | Existing | o Link-layer-CPE2 | - | - | 594 | entry | bound to IPv6-CPE1 | | | 595 | | in the Binding | | | 596 | | Table. | | | 597 | | o Another | - | Conflict? | 598 | | Link-layer address, | | | 599 | | Link-layer-CPE1, | | | 600 | | bound to IPv6-CPE1 | | | 601 | | in the Binding | | | 602 | | Table. | | | 603 | Conflict? | o IPv6-CPE1 | - | Reachable? | 604 | | associated to | | | 605 | | Link-layer-CPE1 in | | | 606 | | the Neighbor Cache. | | | 607 | | o IPv6-CPE1 | Out of scope. | - | 608 | | associated to | | | 609 | | another Link-layer | | | 610 | | address than | | | 611 | | Link-layer-CPE1 in | | | 612 | | the Neighbor Cache. | | | 613 | | o IPv6-CPE1 is not | Create an entry | Reachable? | 614 | | in the Neighbor | for IPv6-CPE1 | | 615 | | Cache. | associated to | | 616 | | | Link-layer-CPE1 | | 617 | | | in the Neighbor | | 618 | | | Cache. | | 619 | Reachable? | o NUD process is | IPv6-CPE2 is | - | 620 | | negative. | bound to | | 621 | | | Link-layer-CPE2, | | 622 | | | instead to | | 623 | | | Link-layer-CPE1, | | 624 | | | in the Binding | | 625 | | | Table. | | 626 | | o NUD process is | A NA message is | - | 627 | | positive. | sent. | | 628 +------------+---------------------+-------------------+------------+ 629 Table 1 631 Authors' Addresses 633 Fabio Costa 634 France Telecom Orange 635 61 rue des Archives 636 75141 Paris Cedex 03 637 France 639 Email: fabio.costa@orange.com 641 Jean-Michel Combes (editor) 642 France Telecom Orange 643 38 rue du General Leclerc 644 92794 Issy-les-Moulineaux Cedex 9 645 France 647 Email: jeanmichel.combes@orange.com 649 Xavier Pougnard 650 France Telecom Orange 651 2 avenue Pierre Marzin 652 22300 Lannion 653 France 655 Email: xavier.pougnard@orange.com 657 Hongyu Li 658 Huawei Technologies 659 Huawei Industrial Base 660 Shenzhen 661 China 663 Email: lihy@huawei.com