Network Working Group S. Joshi
Internet-Draft S. Ooghe
Intended status: Standards Track Alcatel Lucent
Expires: September 24, 2010 March 23, 2010
Interface Identifier Assignment in IPv6 SLAAC
draft-joshi-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 24, 2010.
Copyright Notice
Joshi & Ooghe Expires September 24, 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 24, 2010 [Page 2]
Internet-Draft Interface Identifier Assignment in SLAAC March 2010
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Joshi & Ooghe Expires September 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 2010 [Page 17]