idnits 2.17.1 draft-joshi-6man-neighbor-inform-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 23, 2010) is 5146 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Joshi 3 Internet-Draft S. Ooghe 4 Intended status: Standards Track Alcatel Lucent 5 Expires: September 24, 2010 March 23, 2010 7 Interface Identifier Assignment in IPv6 SLAAC 8 draft-joshi-6man-neighbor-inform-00 10 Abstract 12 This document proposes an optional mechanism as part of IPv6 13 Stateless Address Autoconfiguration for distribution of unique 14 interface identifiers to IPv6 hosts on a link. Hosts can then use 15 these unique interface identifiers to generate unique autoconfigured 16 link local and global unicast addresses. 18 This mechanism is intended for use in networks where link layer 19 identifiers are used for generating interface identifiers and where 20 non unique link layer identifiers will result in duplicate link local 21 addresses. An example of such network is Ethernet Broadband access 22 networks. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 24, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 3. IPv6 Specification Dependency . . . . . . . . . . . . . . . . 5 71 4. Neighbor Inform Message Format . . . . . . . . . . . . . . . . 6 73 5. Receiving Neighbor INFORM . . . . . . . . . . . . . . . . . . 8 74 5.1. Validating of Neighbor Inform Messages . . . . . . . . . . 8 75 5.2. Node Specification . . . . . . . . . . . . . . . . . . . . 8 76 5.2.1. Host Configuration Variable . . . . . . . . . . . . . 8 77 5.2.2. Processing Neighbor Inform . . . . . . . . . . . . . . 9 79 6. Delegating Interface Identifier . . . . . . . . . . . . . . . 10 80 6.1. Delegating Node Specification . . . . . . . . . . . . . . 10 81 6.1.1. Node Configuration Variable . . . . . . . . . . . . . 10 82 6.1.2. Interface Initialization . . . . . . . . . . . . . . . 10 83 6.1.3. Sending Neighbor Inform . . . . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 This document introduces an optional mechanism for delegation of 100 interface identifier as part of Stateless Address Autoconfiguration 101 (SLAAC) [RFC4862]. A new optional message Neighbor Inform is 102 introduced to Neighbor Discovery [RFC4861] to enable delegation of 103 interface identifier. A delegating node uses the message as part of 104 SLAAC to delegate unique interface identifiers to hosts on a link. 106 A typical case is an ethernet based broadband access network 107 consisting of large number of Customer Premise Equiment (CPE) devices 108 conneting to service providers core network. In such a network it's 109 quite likely that either a legitimate or a malicious CPE will have a 110 duplicate MAC address and this would result in two or more hosts on 111 the same link arriving at same EUI-64 based interface identifier as 112 defined in [RFC2464]. Non-unique interface identifier will lead to 113 duplicate link local and global unicast IPv6 addresses and as a 114 result in Denial of Service for legitimate users. 116 Deploying Network Address Translation is a possible solution to this 117 problem, however it considerably increases the complexity and 118 processing capability required in Broadband Access Nodes. A protocol 119 based solution is desirable as it is scalable and expandable. 121 2. Terminology 123 2.1. General 125 node - a device that implements IPv6. 127 link - a communication facility or medium over which nodes can 128 communicate at the link layer, i.e., the layer immediately below 129 IP. Examples are Ethernets (simple or bridged), PPP links or ATM 130 networks as well as Internet-layer (or higher-layer) "tunnels", 131 such as tunnels over IPv4 or IPv6 itself. 133 neighbors - nodes attached to the same link. 135 delegating node - a node that distributes interface identifiers to 136 neighbors. 138 host - any node that is not a router. 140 proxy - a node that responds to Neighbor Discovery query messages 141 on behalf of another node. 143 tentative address - an address whose uniqueness on a link is being 144 verified, prior to its assignment to an interface. A tentative 145 address is not considered assigned to an interface in the usual 146 sense. An interface discards received packets addressed to a 147 tentative address, but accepts Neighbor Discovery packets related 148 to Duplicate Address Detection for the tentative address. 150 solicited-node multicast address - a multicast address to which 151 Neighbor Solicitation messages are sent. The algorithm for 152 computing the address is given in [RFC4291]. 154 2.2. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 3. IPv6 Specification Dependency 162 This document describes a new neighbor discovery message and the 163 processing associated with this message. This document should be 164 read in conjunction with IPv6 Neighbor Discovery [RFC4861] and IPv6 165 Stateless Address Autoconfiguration [RFC4862]. 167 4. Neighbor Inform Message Format 169 A delegating node sends Neighbor Inform message in response to 170 Neighbor Solicatation message sent as part of Duplicate Address 171 detection. 173 0 1 2 3 174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type | Code | Checksum | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |S|R|P| Reserved | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Options ... 181 +-+-+-+-+-+-+-+-+-+-+-+- 183 Figure 1: Neighbor Inform Message Format 185 IP Fields: 187 Source Address - An address assigned to the interface from which 188 the inform is sent. 190 Destination Address - The solicited-node multicast address. 192 Hop Limit - 255 194 ICMP Fields: 196 Type - 155 198 Code 0 - Reconfigure 200 Checksum - ICMP checksum. 202 S - Solicited flag. When set, the S-bit indicates that inform was 203 sent in response to a message from Destination address. 205 R - Router flag. When set, the R-bit indicates that the sender is 206 a router. 208 P - Proxy flag. When set, the P-bit indicates that the sender is 209 a Neighbor Discovery Proxy. 211 Reserved- 29-bit unused field. It MUST be initialized to zero by 212 the sender and MUST be ignored by the receiver. 214 Possible options: 216 Identifier- Identifier is ICMP code of message that caused this 217 INFORM (e.g. 135 - Solicit) 219 Target address - The IP address of the target of the solicitation. 220 Option must be included if ICMP Code is 0 and Identifier is 221 SOLICIT. 223 Interface-ID - Alternative interface ID to be used when 224 reconfiguring link local IPv6 address. 226 Future versions of this protocol may define new option types. 227 Receivers MUST silently ignore any options they do not recognize and 228 continue processing the message. 230 5. Receiving Neighbor INFORM 232 5.1. Validating of Neighbor Inform Messages 234 A node MUST silently discard any received Neighbor Inform messages 235 that do not satisfy all of the following validity checks: 237 - The IP Hop Limit field has a value of 255, i.e., the packet 238 could not possibly have been forwarded by a router. 240 - ICMP Checksum is valid. 242 - ICMP Code is 0. 244 - ICMP length (derived from the IP length) is 24 or more octets. 246 - Target Address is not solicited node multicast address of 247 tentative address assigned to receiving interface. 249 - If the IP Destination Address is a multicast address the 250 Solicited flag is zero. 252 - All included options have a length that is greater than zero. 254 The contents of the Reserved field, and of any unrecognized options, 255 MUST be ignored. Future, backward-compatible changes to the protocol 256 may specify the contents of the Reserved field or add new options; 257 backward-incompatible changes may use different Code values. The 258 contents of any defined options that are not specified to be used 259 with Neighbor Inform messages MUST be ignored and the packet 260 processed as normal. A Neighbor Inform that passes the validity 261 checks is called a "valid inform". 263 5.2. Node Specification 265 5.2.1. Host Configuration Variable 267 A node MUST allow for the following conceptual variables to be 268 configured by system management. The specific variable names are 269 used for demonstration purposes only, and an implementation is not 270 required to have them, so long as its external behavior is consistent 271 with that described in this document. Default values are specified 272 to simplify configuration in common cases. 274 For each interface: 276 NbrRcvInform 277 A flag indicating whether processing of received Neighbor Inform 278 messages is enabled on this interface. Enabling would indicate that 279 node will accept delegated interface identifier for the interface. 281 Default Value :FALSE 283 5.2.2. Processing Neighbor Inform 285 On receipt of a valid Neighbor Inform message on an interface, node 286 behavior depends on whether target address option in message matches 287 a tentative address or an address assigned to the interface. 289 If the target address is not tentative (i.e., it is assigned to the 290 receiving interface), the Neighbor Inform message is silently 291 discarded by the node. 293 If the node has not transmitted a Neighbor Solicit with target 294 address. This could be the case where two nodes with same tentative 295 address are attempting DAD and delegating node has responded to other 296 nodes Solicit request. The Neighbor Inform message is silently 297 discarded by the node and node proceeds with DAD for tentative 298 address. 300 If the target address option in the Inform message matches tentative 301 address of the received interface then the tentative address is 302 determined as duplicate. 304 A tentative address that is determined to be duplicate SHOULD NOT be 305 assigned to the interface, and the node SHOULD log a system 306 management error. 308 If Interface-ID option is present in the Inform message, node MUST 309 use the interface identifier provided to regenerate an IPv6 link 310 local or global unicast address and reinitiate Duplicate Address 311 Detection (DAD). 313 6. Delegating Interface Identifier 315 6.1. Delegating Node Specification 317 6.1.1. Node Configuration Variable 319 A node MUST allow for the following conceptual variables to be 320 configured by system management. The specific variable names are 321 used for demonstration purposes only, and an implementation is not 322 required to have them, so long as its external behavior is consistent 323 with that described in this document. Default values are specified 324 to simplify configuration in common cases. 326 For each interface: 328 NbrDelegationEnable 330 A flag indicating whether sending of Neighbor Inform messages is 331 enabled on this interface. Setting the flag to true would indicate 332 that node will act as a delegating node on that interface. 334 Default Value :FALSE 336 6.1.2. Interface Initialization 338 The node joines all-nodes multicast address on interfaces enabled for 339 delegation. 341 6.1.3. Sending Neighbor Inform 343 A delegating node sends a Neighbor Inform in response to a Neighbor 344 Soliciation received as part of Duplicate Addresses Detection 345 initiated by an IPv6 host. Neighbor Solicit messages sent as part of 346 DAD have source address set as unspecified address. 348 The Target Address of the Inform is copied from the Target Address of 349 the soliciation. The node populates the Interface-ID of the inform 350 either from a database or using a dynamic algorithm. The node may 351 use additional information from received Solicit message e.g. link 352 local address,vlan or physical interface (e.g. DSL) to arrive at a 353 unique Interface-ID to be delegated. 355 Furthermore, if a node is a router, it MUST set the Router flag to 356 one;otherwise it must set the flag to zero 358 If a node is a proxy, it MUST set the proxy flag to one;otherwise it 359 must set the flag to zero 360 The node MUST set the solicited flag to one and multicast the inform 361 to all-nodes address. 363 7. IANA Considerations 365 IANA is requested to assign a new ICMPv6 Type (155) for NEIGHBOR 366 INFORM message. 368 8. Security Considerations 370 Unsecured Neighbor Discovery has a number of security issues, which 371 are discussed in detail in [RFC3756]. Security mechanisms to protect 372 Neighbor Discovery are described in [RFC3971]. 374 9. Acknowledgements 376 This document liberally borrows text from RFC4862 and RFC4861. 378 10. References 380 10.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 386 Architecture", RFC 4291, February 2006. 388 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 389 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 390 September 2007. 392 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 393 Address Autoconfiguration", RFC 4862, September 2007. 395 10.2. Informative References 397 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 398 Networks", RFC 2464, December 1998. 400 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 401 Discovery (ND) Trust Models and Threats", RFC 3756, 402 May 2004. 404 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 405 Neighbor Discovery (SEND)", RFC 3971, March 2005. 407 Authors' Addresses 409 Shrinivas Joshi 410 Alcatel Lucent 411 RR Towers IV, Thiruvika Industrial Estate, Guindy 412 Chennai, Tamil Nadu 600032 413 India 415 Phone: +91-44-3099-8165 416 Email: shrinivas_ashok.joshi@alcatel-lucent.com 418 Sven Ooghe 419 Alcatel Lucent 420 Copernicuslaan 50 421 Antwerp 2018 422 Belgium 424 Phone: +32-32404226 425 Email: sven.ooghe@alcatel-lucent.com