Network Working Group S. Joshi Internet-Draft S. Ooghe Intended status: Standards Track Alcatel Lucent Expires: September 23, 2010 March 22, 2010 Interface Identifier Assignment in IPv6 SLAAC draft-ietf-6man-neighbor-inform-00 Abstract This document proposes an optional mechanism as part of IPv6 Stateless Address Autoconfiguration for distribution of unique interface identifiers to IPv6 hosts on a link. Hosts can then use these unique interface identifiers to generate unique autoconfigured link local and global unicast addresses. This mechanism is intended for use in networks where link layer identifiers are used for generating interface identifiers and where non unique link layer identifiers will result in duplicate link local addresses. An example of such network is Ethernet Broadband access networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 23, 2010. Copyright Notice Joshi & Ooghe Expires September 23, 2010 [Page 1] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. IPv6 Specification Dependency . . . . . . . . . . . . . . . . 5 4. Neighbor Inform Message Format . . . . . . . . . . . . . . . . 6 5. Receiving Neighbor INFORM . . . . . . . . . . . . . . . . . . 8 5.1. Validating of Neighbor Inform Messages . . . . . . . . . . 8 5.2. Node Specification . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Host Configuration Variable . . . . . . . . . . . . . 8 5.2.2. Processing Neighbor Inform . . . . . . . . . . . . . . 9 6. Delegating Interface Identifier . . . . . . . . . . . . . . . 10 6.1. Delegating Node Specification . . . . . . . . . . . . . . 10 6.1.1. Node Configuration Variable . . . . . . . . . . . . . 10 6.1.2. Interface Initialization . . . . . . . . . . . . . . . 10 6.1.3. Sending Neighbor Inform . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Joshi & Ooghe Expires September 23, 2010 [Page 2] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Joshi & Ooghe Expires September 23, 2010 [Page 3] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 1. Introduction This document introduces an optional mechanism for delegation of interface identifier as part of Stateless Address Autoconfiguration (SLAAC) [RFC4862]. A new optional message Neighbor Inform is introduced to Neighbor Discovery [RFC4861] to enable delegation of interface identifier. A delegating node uses the message as part of SLAAC to delegate unique interface identifiers to hosts on a link. A typical case is an ethernet based broadband access network consisting of large number of Customer Premise Equiment (CPE) devices conneting to service providers core network. In such a network it's quite likely that either a legitimate or a malicious CPE will have a duplicate MAC address and this would result in two or more hosts on the same link arriving at same EUI-64 based interface identifier as defined in [RFC2464]. Non-unique interface identifier will lead to duplicate link local and global unicast IPv6 addresses and as a result in Denial of Service for legitimate users. Deploying Network Address Translation is a possible solution to this problem, however it considerably increases the complexity and processing capability required in Broadband Access Nodes. A protocol based solution is desirable as it is scalable and expandable. Joshi & Ooghe Expires September 23, 2010 [Page 4] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 2. Terminology 2.1. General node - a device that implements IPv6. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links or ATM networks as well as Internet-layer (or higher-layer) "tunnels", such as tunnels over IPv4 or IPv6 itself. neighbors - nodes attached to the same link. delegating node - a node that distributes interface identifiers to neighbors. host - any node that is not a router. proxy - a node that responds to Neighbor Discovery query messages on behalf of another node. tentative address - an address whose uniqueness on a link is being verified, prior to its assignment to an interface. A tentative address is not considered assigned to an interface in the usual sense. An interface discards received packets addressed to a tentative address, but accepts Neighbor Discovery packets related to Duplicate Address Detection for the tentative address. solicited-node multicast address - a multicast address to which Neighbor Solicitation messages are sent. The algorithm for computing the address is given in [RFC4291]. 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Joshi & Ooghe Expires September 23, 2010 [Page 5] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 3. IPv6 Specification Dependency This document describes a new neighbor discovery message and the processing associated with this message. This document should be read in conjunction with IPv6 Neighbor Discovery [RFC4861] and IPv6 Stateless Address Autoconfiguration [RFC4862]. Joshi & Ooghe Expires September 23, 2010 [Page 6] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 4. Neighbor Inform Message Format A delegating node sends Neighbor Inform message in response to Neighbor Solicatation message sent as part of Duplicate Address detection. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|R|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 1: Neighbor Inform Message Format IP Fields: Source Address - An address assigned to the interface from which the inform is sent. Destination Address - The solicited-node multicast address. Hop Limit - 255 ICMP Fields: Type - 155 Code 0 - Reconfigure Checksum - ICMP checksum. S - Solicited flag. When set, the S-bit indicates that inform was sent in response to a message from Destination address. R - Router flag. When set, the R-bit indicates that the sender is a router. P - Proxy flag. When set, the P-bit indicates that the sender is a Neighbor Discovery Proxy. Joshi & Ooghe Expires September 23, 2010 [Page 7] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 Reserved- 29-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Possible options: Identifier- Identifier is ICMP code of message that caused this INFORM (e.g. 135 - Solicit) Target address - The IP address of the target of the solicitation. Option must be included if ICMP Code is 0 and Identifier is SOLICIT. Interface-ID - Alternative interface ID to be used when reconfiguring link local IPv6 address. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. Joshi & Ooghe Expires September 23, 2010 [Page 8] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 5. Receiving Neighbor INFORM 5.1. Validating of Neighbor Inform Messages A node MUST silently discard any received Neighbor Inform messages that do not satisfy all of the following validity checks: - The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. - ICMP Checksum is valid. - ICMP Code is 0. - ICMP length (derived from the IP length) is 24 or more octets. - Target Address is not solicited node multicast address of tentative address assigned to receiving interface. - If the IP Destination Address is a multicast address the Solicited flag is zero. - All included options have a length that is greater than zero. The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values. The contents of any defined options that are not specified to be used with Neighbor Inform messages MUST be ignored and the packet processed as normal. A Neighbor Inform that passes the validity checks is called a "valid inform". 5.2. Node Specification 5.2.1. Host Configuration Variable A node MUST allow for the following conceptual variables to be configured by system management. The specific variable names are used for demonstration purposes only, and an implementation is not required to have them, so long as its external behavior is consistent with that described in this document. Default values are specified to simplify configuration in common cases. For each interface: NbrRcvInform Joshi & Ooghe Expires September 23, 2010 [Page 9] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 A flag indicating whether processing of received Neighbor Inform messages is enabled on this interface. Enabling would indicate that node will accept delegated interface identifier for the interface. Default Value :FALSE 5.2.2. Processing Neighbor Inform On receipt of a valid Neighbor Inform message on an interface, node behavior depends on whether target address option in message matches a tentative address or an address assigned to the interface. If the target address is not tentative (i.e., it is assigned to the receiving interface), the Neighbor Inform message is silently discarded by the node. If the node has not transmitted a Neighbor Solicit with target address. This could be the case where two nodes with same tentative address are attempting DAD and delegating node has responded to other nodes Solicit request. The Neighbor Inform message is silently discarded by the node and node proceeds with DAD for tentative address. If the target address option in the Inform message matches tentative address of the received interface then the tentative address is determined as duplicate. A tentative address that is determined to be duplicate SHOULD NOT be assigned to the interface, and the node SHOULD log a system management error. If Interface-ID option is present in the Inform message, node MUST use the interface identifier provided to regenerate an IPv6 link local or global unicast address and reinitiate Duplicate Address Detection (DAD). Joshi & Ooghe Expires September 23, 2010 [Page 10] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 6. Delegating Interface Identifier 6.1. Delegating Node Specification 6.1.1. Node Configuration Variable A node MUST allow for the following conceptual variables to be configured by system management. The specific variable names are used for demonstration purposes only, and an implementation is not required to have them, so long as its external behavior is consistent with that described in this document. Default values are specified to simplify configuration in common cases. For each interface: NbrDelegationEnable A flag indicating whether sending of Neighbor Inform messages is enabled on this interface. Setting the flag to true would indicate that node will act as a delegating node on that interface. Default Value :FALSE 6.1.2. Interface Initialization The node joines all-nodes multicast address on interfaces enabled for delegation. 6.1.3. Sending Neighbor Inform A delegating node sends a Neighbor Inform in response to a Neighbor Soliciation received as part of Duplicate Addresses Detection initiated by an IPv6 host. Neighbor Solicit messages sent as part of DAD have source address set as unspecified address. The Target Address of the Inform is copied from the Target Address of the soliciation. The node populates the Interface-ID of the inform either from a database or using a dynamic algorithm. The node may use additional information from received Solicit message e.g. link local address,vlan or physical interface (e.g. DSL) to arrive at a unique Interface-ID to be delegated. Furthermore, if a node is a router, it MUST set the Router flag to one;otherwise it must set the flag to zero If a node is a proxy, it MUST set the proxy flag to one;otherwise it must set the flag to zero Joshi & Ooghe Expires September 23, 2010 [Page 11] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 The node MUST set the solicited flag to one and multicast the inform to all-nodes address. Joshi & Ooghe Expires September 23, 2010 [Page 12] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 7. IANA Considerations IANA is requested to assign a new ICMPv6 Type (155) for NEIGHBOR INFORM message. Joshi & Ooghe Expires September 23, 2010 [Page 13] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 8. Security Considerations Unsecured Neighbor Discovery has a number of security issues, which are discussed in detail in [RFC3756]. Security mechanisms to protect Neighbor Discovery are described in [RFC3971]. Joshi & Ooghe Expires September 23, 2010 [Page 14] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 9. Acknowledgements This document liberally borrows text from RFC4862 and RFC4861. Joshi & Ooghe Expires September 23, 2010 [Page 15] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 10.2. Informative References [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Joshi & Ooghe Expires September 23, 2010 [Page 16] Internet-Draft Interface Identifier Assignment in SLAAC March 2010 Authors' Addresses Shrinivas Joshi Alcatel Lucent RR Towers IV, Thiruvika Industrial Estate, Guindy Chennai, Tamil Nadu 600032 India Phone: +91-44-3099-8165 Email: shrinivas_ashok.joshi@alcatel-lucent.com Sven Ooghe Alcatel Lucent Copernicuslaan 50 Antwerp 2018 Belgium Phone: +32-32404226 Email: sven.ooghe@alcatel-lucent.com Joshi & Ooghe Expires September 23, 2010 [Page 17]