idnits 2.17.1 draft-ietf-6man-dad-proxy-05.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 (September 19, 2012) is 4234 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-02 == Outdated reference: A later version (-11) exists of draft-ietf-savi-send-08 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 4 Intended status: Standards Track X. Pougnard 5 Expires: March 23, 2013 France Telecom Orange 6 H. Li 7 Huawei Technologies 8 September 19, 2012 10 Duplicate Address Detection Proxy 11 draft-ietf-6man-dad-proxy-05 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 March 23, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . . . . . . . . 4 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. DAD Proxy state machine . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 This document specifies a function called Duplicate Address Detection 87 (DAD) proxy allowing the use of DAD by the nodes on the same point- 88 to-multipoint domain with "split-horizon" forwarding scheme. It only 89 impacts the first hop router and it doesn't need modifications on the 90 other IPv6 nodes. This mechanism is fully effective if all the nodes 91 of a point-to-multipoint domain (except the DAD proxy itself) perform 92 DAD. 94 This document explains also why DAD mechanism [RFC4862] cannot be 95 used in a point-to-multipoint architecture with "split-horizon" 96 forwarding scheme (IPv6 over PPP [RFC5072] is not affected). One of 97 the main reasons is that, because of this forwarding scheme, IPv6 98 nodes on the same point-to-multipoint domain cannot have direct 99 communication: any communication between them must go through the 100 first hop router of the same domain. 102 It is assumed in this document that Link-layer addresses on a point- 103 to-multipoint domain are unique from the first hop router's point of 104 view (e.g. in an untrusted Ethernet architecture this assumption can 105 be guaranteed thanks to mechanisms such as "MAC Address Translation" 106 performed by an aggregation device between IPv6 nodes and the first 107 hop router). 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Background 117 Terminology in this document follows that in Neighbor Discovery for 118 IP version 6 (IPv6) [RFC4861] and IPv6 Stateless Address 119 Autoconfiguration [RFC4862]. In addition, this section defines 120 additional terms related to Digital Subscriber Line (DSL) and Fiber 121 access architectures, which are an important case where the solution 122 described in this document can be used: 124 Customer Premises Equipment (CPE) 125 The first IPv6 node in a customer's network. 127 Access Node (AN) 128 The first aggregation point in the public access network. It 129 is considered as a L2 bridge in this document. 131 Broadband Network Gateway (BNG) 132 The first hop router from the CPE's point of view. 134 VLAN N:1 architecture 135 A point-to-multipoint architecture where many CPEs are 136 connected to the same VLAN. The CPEs may be connected on the 137 same or different Access Nodes. 139 split-horizon model 140 A forwarding scheme where CPEs cannot have direct layer 2 141 communications between them (i.e. IP flows must be forwarded 142 through the BNG via routing). 144 The following figure shows where are the different entities defined 145 above. 147 +------+ +----+ 148 | CPE3 |---------| AN | 149 +------+ +----+ 150 | 151 | 152 +------+ +----+ 153 | CPE2 |---------| AN |---+ 154 +------+ +----+ | 155 +------+ | | 156 | CPE1 |------------+ | 157 +------+ +-----+ 158 | BNG |--- Internet 159 +-----+ 161 Figure 1: DSL and Fiber access Architecture 163 3. Why existing IETF solutions are not sufficient? 165 In a DSL or Fiber access architecture depicted in Figure 1, CPE1,2,3 166 and the BNG are IPv6 nodes, while AN is a L2 bridge providing 167 connectivity between the BNG and each CPE. The AN enforces a split- 168 horizon model so that CPEs can only send and receive frames (e.g. 169 Ethernet frames) to and from the BNG but not to each other. That 170 said, the BNG is on a same link with all CPE, but one CPE is not on a 171 same link with any other CPE. 173 3.1. Duplicate Address Detection 175 Duplicate Address Dectection (DAD) [RFC4862] is performed when an 176 IPv6 node verifies the uniqueness of a tentative IPv6 address. This 177 node sends a Neighbor Solicitation (NS) message with the IP 178 destination set to the solicited-node multicast address of the 179 tentative address. This NS message is multicasted to other nodes on 180 the same link. When the tentative address is already used on the 181 link by another node, this last one replies with a Neighbor 182 Advertisement (NA) message to inform the first node. So when 183 performing DAD, a node expects the NS messages to be received by any 184 node currently using the tentative address. 186 However, in a point-to-multipoint network with split-horizon 187 forwarding scheme implemented in the AN, the CPEs are prevented from 188 talking to each other directly. All packets sent out from a CPE are 189 forwarded by the AN only to the BNG but not to any other CPE. NS 190 messages sent by a certain CPE will be received only by the BNG and 191 will not reach other CPEs. So, other CPEs have no idea that a 192 certain IPv6 address is used by another CPE. That means, in a 193 network with split-horizon, DAD, as defined in [RFC4862], can't work 194 properly without an additional help. 196 3.2. Neighbor Discovery Proxy 198 Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND 199 messages between different IP links where the subnet prefix is the 200 same. A ND Proxy function on a bridge ensures that packets between 201 nodes on different segments can be received by this function and have 202 the correct link-layer address type on each segment. When the ND 203 proxy receives a multicast ND message, it forwards it to all other 204 interfaces on a same link. 206 In DSL or Fiber networks, when the AN, acting as a ND Proxy, receives 207 a ND message from a CPE, it will forward it to the BNG but none of 208 other CPEs, as only the BNG is on the same link with the CPE. Hence, 209 implementing ND Proxy on the AN would not help a CPE acknowledge 210 link-local addresses used by other CPEs. 212 As the BNG must not forward link-local scoped messages sent from a 213 CPE to other CPEs, ND Proxy cannot be implemented in the BNG. 215 3.3. 6LoWPAN Neighbor Discovery 217 [I-D.ietf-6lowpan-nd] defines an optional modification of DAD for a 218 6LowPAN. When a 6LoWPAN node wants to configure an IPv6 address, it 219 registers that address with one or more of its default routers using 220 the Address Registration option (ARO). If this address is already 221 owned by another node, the router informs the 6LoWPAN node this 222 address cannot be configured. 224 This mechanism requires modifications in all hosts in order to 225 support the Address Registration option. 227 3.4. IPv6 Mobility Manager 229 According to [RFC6275], a home agent acts as a proxy for mobile nodes 230 when they are away from the home network: the home agent defends an 231 mobile node's home address by replying to NS messages with NA 232 messages. 234 There is a problem for this mechanism if it is applied in a DSL or 235 Fiber public access network. Operators of such networks require a NA 236 message is only received by the sender of the corresponding NS 237 message, for security and scalability reasons. However, the home 238 agent per [RFC6275] multicasts NA messages on the home link and all 239 nodes on this link will receive these NA messages. This shortcoming 240 prevents this mechanism being deployed in DSL or Fiber access 241 networks directly. 243 4. Duplicate Address Detection Proxy (DAD-Proxy) specifications 245 4.1. DAD-Proxy Data structure 247 A BNG needs to store in a Binding Table information related to the 248 IPv6 addresses generated by any CPE. This Binding Table MAY be 249 distinct from the Neighbor Cache. 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 On the reception of an unsolicited NA (e.g., when a CPE wishes to 262 inform its neighbors of a new link-layer address) for an IPv6 address 263 already recorded in the Binding Table, each entry associated to this 264 IPv6 address MUST be updated consequently: the current Link-layer 265 Address is replaced by the one included in the unsolicited NA 266 message. 268 4.2. DAD-Proxy mechanism 270 When a CPE performs DAD, as specified in [RFC4862], it sends a 271 Neighbor Solicitation (NS) message, with the unspecified address as 272 the source address, in order to check if a tentative address is 273 already in use on the link. The BNG receives this message and MUST 274 perform actions depending on the information in the Binding Table. 276 4.2.1. No entry exists for the tentative address 278 When there is no entry for the tentative address, the BNG MUST create 279 one with the following information: 281 o IPv6 Address Field set to the tentative address in the NS message. 283 o Link-layer Address Field set to the Link-layer source address in 284 the Link-layer Header of the NS message. 286 The BNG MUST NOT reply to the CPE or forward the NS message. 288 4.2.2. An entry already exists for the tentative address 290 When there is an entry for the tentative address, the BNG MUST check 291 the following conditions: 293 o The address in the Target Address Field in the NS message is equal 294 to the address in the IPv6 Address Field in the entry. 296 o The source address of the IPv6 Header in the NS message is equal 297 to the unspecified address. 299 When these conditions are met and the source address of the Link- 300 Layer Header in the NS message is equal to the address in the Link- 301 Layer Address Field in the entry, that means the CPE is still 302 performing DAD for this address. The BNG MUST NOT reply to the CPE 303 or forward the NS message. 305 When these conditions are met and the source address of the Link- 306 Layer Header in the NS message is not equal to the address in the 307 Link-Layer Address Field in the entry, that means possibly another 308 CPE performs DAD for an already owned address. The BNG then has to 309 verify whether there is a real conflict by checking if the CPE whose 310 IPv6 address is in the entry is still connected. In the following, 311 we will call IPv6-CPE1 the IPv6 address of the existing entry in the 312 Binding Table, Link-layer-CPE1 the Link-layer address of that entry 313 and Link-layer-CPE2 the Link-layer address of the CPE which is 314 performing DAD, which is different from Link-layer-CPE1. 316 The BNG MUST check if the potential address conflict is real. In 317 particular: 319 o If IPv6-CPE1 is in the Neighbor Cache and it is associated with 320 Link-layer-CPE1, the reachability of IPv6-CPE1 MUST be confirmed 321 as explained in Section 4.2.3. 323 o If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is 324 associated with another Link-layer address than Link-layer-CPE1, 325 that means that there is possibly a conflict with another CPE, but 326 that CPE did not perform DAD. This situation is out of the scope 327 of this document, since one assumption made above is that all the 328 nodes of a point-to-multipoint domain (except the DAD proxy 329 itself) perform DAD. 331 o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST 332 create a new entry based on the information of the entry in the 333 Binding Table. This step is necessary in order to trigger the 334 reachibility check as explained in Section 4.2.3. The entry in 335 the Neighbor Cache MUST be created based on the algorithm defined 336 in section 7.3.3 of [RFC4861], in particular by considering the 337 case as if a packet other than a solicited Neighbor Advertisement 338 was received from IPv6-CPE1. That means that the new entry of the 339 Neighbor Cache MUST contain the following information: 341 * IPv6 address: IPv6-CPE1 343 * Link-layer address: Link-layer-CPE1 345 * State: STALE 347 Then the reachability of IPv6-CPE1 MUST be confirmed as soon as 348 possible following the procedure explained in section 4.2.3. 350 4.2.3. Confirmation of reachability to check the validity of the 351 conflict 353 Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the 354 reachability of IPv6-CPE1 is checked by using the NUD (Neighbor 355 Unreachibility Detection) mechanism described in section 7.3.1 of 356 [RFC4861]. This mechanism MUST be triggered as if a packet has to be 357 sent to IPv6-CPE1. Note that in some cases this mechanism does not 358 do anything, for instance if the state of the entry is REACHABLE and 359 a positive confirmation was received recently that the forward path 360 to the IPv6-CPE1 was functioning properly (see RFC 4861 for more 361 details). 363 Next, the behavior of the BNG depends on the result of the NUD 364 process, as explained in the following sections. 366 4.2.3.1. The result of the NUD process is negative 368 If the result of the NUD process is negative (i.e. if this process 369 removes IPv6-CPE1 from the Neighbor Cache), that means that the 370 potential conflict is not real. 372 The conflicting entry in the Binding Table (Link-layer-CPE1) is 373 deleted and it is replaced by a new entry with the same IPv6 address, 374 but the Link-layer address of the CPE which is performing DAD (Link- 375 layer-CPE2), as explained in Section 4.2.1. 377 4.2.3.2. The result of the NUD process is positive 379 If the result of the NUD process is positive (i.e. if after this 380 process the state of IPv6-CPE1 is REACHABLE), that means that the 381 potential conflict is real. 383 As shown in Figure 2, the BNG MUST reply to CPE that is performing 384 DAD (CPE2 in Figure 1) with a NA message which has the following 385 format: 387 Layer 2 Header Fields: 389 Source Address 390 The Link-layer address of the interface on which the BNG 391 received the NS message. 393 Destination Address 394 The source address in the Layer 2 Header of the NS 395 message received by the BNG (i.e. Link-layer-CPE2) 397 IPv6 Header Fields: 399 Source Address 400 An address assigned to the interface from which the 401 advertisement is sent. 403 Destination Address 404 The all-nodes multicast address. 406 ICMPv6 Fields: 408 Target Address 409 The tentative address already used (i.e. IPv6-CPE1). 411 Target Link-layer address 412 The Link-layer address of the interface on which the BNG 413 received the NS message. 415 CPE1 CPE2 BNG 416 | | | 417 (a)| | | 418 | | | 419 (b)|===================>| 420 | | |(c) 421 | | | 422 | (d)| | 423 | | | 424 | (e)|=========>| 425 | | | 426 | |<=========|(f) 427 | | | 429 (a) CPE1 generated a tentative address 430 (b) CPE1 performs DAD for this one 431 (c) BNG updates its Binding Table 432 (d) CPE2 generates a same tentative address 433 (e) CPE2 performs DAD for this one 434 (f) BNG informs CPE2 that DAD fails 436 Figure 2 438 The BNG and the CPE MUST support the Unicast Transmission on Link- 439 layer of IPv6 Multicast Messages [RFC6085], to be able, respectively, 440 to generate and to process such a packet format. 442 5. IANA Considerations 444 No new options or messages are defined in this document. 446 6. Security Considerations 448 6.1. Interoperability with SEND 450 If SEcure Neighbor Discovery (SEND) [RFC3971] is used, the mechanism 451 specified in this document may break the security. Indeed, if an 452 entry already exists and the BNG has to send a reply (cf. 453 Section 4.2.2), the BNG doesn't own the private key(s) associated 454 with to the Cryptographically Generated Addresses (CGA) [RFC3972] to 455 correctly sign the proxied ND messages [RFC5909]. 457 To keep the same level of security, Secure Proxy ND Support for SEND 458 [RFC6496] SHOULD be used and implemented on the BNG and the CPEs. 460 6.2. IP source address spoofing protection 462 To ensure a protection against IP source address spoofing in data 463 packets, this proposal MAY be used in combinaison with Source Address 464 Validation Improvement (SAVI) mechanisms [RFC6620] 465 [I-D.ietf-savi-send] [I-D.ietf-savi-mix]. 467 7. Acknowledgments 469 The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh 470 Krishnan and Tassos Chatzithomaoglou for their comments. The authors 471 would like also to thank the IETF 6man WG members and the BBF 472 community for their support. 474 8. References 476 8.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 482 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 483 September 2007. 485 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 486 Address Autoconfiguration", RFC 4862, September 2007. 488 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 489 "Address Mapping of IPv6 Multicast Packets on Ethernet", 490 RFC 6085, January 2011. 492 8.2. Informative References 494 [I-D.ietf-6lowpan-nd] 495 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 496 Discovery Optimization for Low Power and Lossy Networks 497 (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress), 498 August 2012. 500 [I-D.ietf-savi-mix] 501 Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI 502 for Mixed Address Assignment Methods Scenario", 503 draft-ietf-savi-mix-02 (work in progress), April 2012. 505 [I-D.ietf-savi-send] 506 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 507 Address Validation Implementation", 508 draft-ietf-savi-send-08 (work in progress), 509 September 2012. 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 (ND Proxy)", RFC 4389, April 2006. 520 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 521 PPP", RFC 5072, September 2007. 523 [RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing 524 Neighbor Discovery Proxy: Problem Statement", RFC 5909, 525 July 2010. 527 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 528 in IPv6", RFC 6275, July 2011. 530 [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 531 Martinez, "Secure Proxy ND Support for SEcure Neighbor 532 Discovery (SEND)", RFC 6496, February 2012. 534 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 535 SAVI: First-Come, First-Served Source Address Validation 536 Improvement for Locally Assigned IPv6 Addresses", 537 RFC 6620, May 2012. 539 Appendix A. DAD Proxy state machine 541 This appendix contains a summary (cf. Table 1) of the actions done by 542 the BNG when it receives a DAD based NS (DAD-NS) message. The 543 tentative address in this message is IPv6-CPE1 and the associated 544 Link-layer address is Link-layer-CPE2. The actions are precisely 545 specified in Section 4.2. 547 +------------+---------------------+-------------------+------------+ 548 | Event | Check | Action | New event | 549 +------------+---------------------+-------------------+------------+ 550 | DAD-NS | o No entry for | Create an entry | - | 551 | message | IPv6-CPE1 in the | for IPv6-CPE1 | | 552 | reception. | Binding Table. | bound to | | 553 | | | Link-layer-CPE2 | | 554 | | | in the Binding | | 555 | | | Table. | | 556 | | o Entry for | - | Existing | 557 | | IPv6-CPE1 in the | | entry | 558 | | Binding Table. | | | 559 | Existing | o Link-layer-CPE2 | - | - | 560 | entry | bound to IPv6-CPE1 | | | 561 | | in the Binding | | | 562 | | Table. | | | 563 | | o Another | - | Conflict? | 564 | | Link-layer address, | | | 565 | | Link-layer-CPE1, | | | 566 | | bound to IPv6-CPE1 | | | 567 | | in the Binding | | | 568 | | Table. | | | 569 | Conflict? | o IPv6-CPE1 | - | Reachable? | 570 | | associated to | | | 571 | | Link-layer-CPE1 in | | | 572 | | the Neighbor Cache. | | | 573 | | o IPv6-CPE1 | Out of scope. | - | 574 | | associated to | | | 575 | | another Link-layer | | | 576 | | address than | | | 577 | | Link-layer-CPE1 in | | | 578 | | the Neighbor Cache. | | | 579 | | o IPv6-CPE1 is not | Create an entry | Reachable? | 580 | | in the Neighbor | for IPv6-CPE1 | | 581 | | Cache. | associated to | | 582 | | | Link-layer-CPE1 | | 583 | | | in the Neighbor | | 584 | | | Cache. | | 585 | Reachable? | o NUD process is | IPv6-CPE2 is | - | 586 | | negative. | bound to | | 587 | | | Link-layer-CPE2, | | 588 | | | instead to | | 589 | | | Link-layer-CPE1, | | 590 | | | in the Binding | | 591 | | | Table. | | 592 | | o NUD process is | A NA message is | - | 593 | | positive. | sent. | | 594 +------------+---------------------+-------------------+------------+ 595 Table 1 597 Authors' Addresses 599 Fabio Costa 600 France Telecom Orange 601 61 rue des Archives 602 75141 Paris Cedex 03 603 France 605 Email: fabio.costa@orange.com 607 Jean-Michel Combes 608 France Telecom Orange 609 38 rue du General Leclerc 610 92794 Issy-les-Moulineaux Cedex 9 611 France 613 Email: jeanmichel.combes@orange.com 615 Xavier Pougnard 616 France Telecom Orange 617 2 avenue Pierre Marzin 618 22300 Lannion 619 France 621 Email: xavier.pougnard@orange.com 623 Hongyu Li 624 Huawei Technologies 625 Huawei Industrial Base 626 Shenzhen 627 China 629 Email: lihy@huawei.com