Internet DRAFT - draft-thubert-6man-wind-sail
draft-thubert-6man-wind-sail
6MAN P. Thubert
Internet-Draft E. Levy-Abegnoli
Intended status: Standards Track Cisco
Expires: April 18, 2014 October 17, 2013
Wireless Neighbor Discovery Stateful Address Identification and Location
exchange
draft-thubert-6man-wind-sail-00
Abstract
This draft proposes an extension to IPv6 Neighbor Discovery to
exchange Stateful Address Identification and Location between State
Maintaining Entities located over a backbone link about attached
nodes that are attached to the backbone via a Wireless Link, in order
to maintain all the entities up-to-date and maintain reachability as
the attached nodes move.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 18, 2014.
Copyright Notice
Copyright (c) 2013 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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 1]
Internet-Draft WiND-SAIL October 2013
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. General Context . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Efficient ND . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Proxying classical ND . . . . . . . . . . . . . . . . . . 10
4.3. Federating Large LLNs . . . . . . . . . . . . . . . . . . 11
5. New types and formats . . . . . . . . . . . . . . . . . . . . 12
6. Validation Interface Operations . . . . . . . . . . . . . . . 14
6.1. Child to Parent Operations . . . . . . . . . . . . . . . . 15
6.2. Parent to Child Operations . . . . . . . . . . . . . . . . 16
6.2.1. Address validation and registration . . . . . . . . . 16
6.2.2. Registration update . . . . . . . . . . . . . . . . . 17
6.3. Registration deletion . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
"Neighbor Discovery for IP version 6" [RFC4861] (IPv6 ND) relies
heavily on multicast signaling messages on the local Link.
Conceptually, multicast is supposed to avoid broadcast messages, but,
in most practical cases, its operation at the link level is that of a
broadcast. This did not matter much at the time ND was originally
designed, when an Ethernet network was more or less a single shared
wire, but since then, large scale switched fabrics, low-power
sleeping devices, mobile wireless devices and virtual machines have
changed the landscape dramatically.
The overhead of multicast in IPv6 ND has become significant and is
now a major annoyance in multiple scenarios, in particular for
wireless nodes. With WIFI, a multicast message will consume the
wireless link on all Access Points around a switched fabric and will
be transmitted at the lowest speed possible in order to ensure the
maximum reception by all other wireless nodes. This means that in an
environment where bandwidth is scarce, a single multicast packet may
consume the bandwidth for hundreds of unicast packets. Sadly, IPv6
ND is a major source of multicast messages in wireless devices, since
such messages are triggered each time a wireless device changes its
point of attachment.
A similar situation can be seen in a datacenter, where Virtual
Machine (VM) mobility also triggers floods of multicast messages,
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 2]
Internet-Draft WiND-SAIL October 2013
which become a major hassle as the number of VMs grows to the tens of
thousands and above. At the IETF, a Working Group was created to
discuss Address Resolution in Massive Datacenters (ARMD), but the
work did not go to completion. The problem with IPv6 ND multicast is
still present, only getting worse as the scale and degree of mobility
augments with the massive introduction of new mobile devices such as
virtualized appliances, IoT and BYOD.
At the same time, the need to better control the ownership,
utilization and location of IP addresses has become predominant in
managed networks. The Source-Address Validation Improvements (SAVI)
Working Group has proposed methods to locate, validate the ownership,
and police the utilization of IPv6 addresses by snooping IPv6 ND and
DHCP operations. But snooping requires being on the path of the
protocols and is limited in particular in and for unicast responses.
Mobile nodes such as BYOD may change their point of attachment in the
network but an eventual renumbering can be disruptive to existing
connections. Virtual devices - typically VMs in a datacenter - also
move though in a different fashion, from a physical device to the
next. In any case, the need to maintain a same IPv6 address across
movements implies the creation of very large, eventually multi-link,
subnets. In such a large subnet, it might be difficult with the
existing protocols to differentiate duplication from a rapid sequence
of movements. And if it is indeed a sequence of movements, then it
might be difficult to select the freshest information, and additional
signaling is required to obtain the actual location of an address in
a deterministic fashion.
In a modern managed switched fabric, a number of devices host IPv6
State Maintaining Entities (6SMEs) that hold Stateful Address
Identification and Location (SAIL) information about the entity that
owns an IPv6 address. A 6SME needs to reascertain periodically the
state that it maintains and eliminate stale information. It is of
common interest between all 6SMEs to share their information and help
one another learn new state, update existing state and remove stale
state rapidly. A Binding Table maintained by a secured registration
protocol is certainly a more robust basis for 6SME activity than a
classical IPv6 NDP [RFC4861] Neighbor Cache management coupled
with protocol snooping as currently found with SAVI [RFC6620].
Mobile IPv6 [RFC6275] introduced such a registration protocol to
maintain a tunnel and enable an IPv6 ND proxy operation over a Home
Network. Applied to IPv6 Neighbor Discovery, the registration model
balances the benefits of distributed StateLess Address
AutoConfiguration (SLAAC) [RFC4862] for scalability and autonomic
behaviours with the capability to reject or recuse an autoconfigured
address on an exception basis - based for instance on administrative
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 3]
Internet-Draft WiND-SAIL October 2013
policies -, which is a desired feature for managed networks that
classically are operated with DHCPv6 [RFC3115]. In that sense, the
ND registration allows a scalable hybrid of managed and non-managed
networks while minimizing the total number of multicast messages
between hosts, as well as between hosts and routers.
An IPv6 ND registration mechanism was standardized as Neighbor
Discovery Optimization for Low-power and Lossy Networks [RFC6775].
The host to SME router operation is generalized by wireless ND [I-D
.chakrabarti-nordmark-6man-efficient-nd] for devices that are not
necessarily attached to a LLN but may still benefit from
registration. [RFC6775] also introduces a protocol between SMEs
based on new ICMP messages. This draft extends that model in order
to allow for a distributed, eventually hierarchical set of SMEs to
share and maintain SAIL states.
2. Terminology
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 [RFC2119].
Readers are expected to be familiar with all the terms and concepts
that are discussed in "Neighbor Discovery for IP version 6"
[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
Neighbor Discovery Optimization for Low-power and Lossy Networks
[RFC6775] and "Multi-link Subnet Support in IPv6" [I-D.ietf-ipv6
-multilink-subnets].
Readers may benefit from reading the "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks" [RFC6550] specification; "Multi-Link
Subnet Issues" [RFC4903]; "Mobility Support in IPv6" [RFC6275];
"Neighbor Discovery Proxies (ND Proxy)" [RFC4389]; "FCFS SAVI:
First-Come, First-Served Source Address Validation Improvement for
Locally Assigned IPv6 Addresses" [RFC6620]; and "Optimistic Duplicate
Address Detection" [RFC4429] prior to this specification for a clear
understanding of the art in ND-proxying and binding.
Additionally, this document uses terminology from [I-D.ietf-roll-
terminology], and reuses or introduces the following terminology:
6LoWPAN Router (6LR): Please refer to [RFC6775].
6LoWPAN Border Router (6LBR): Please refer to [RFC6775].
DAR and DAC messages: Please refer to [RFC6775].
Multi-link subnet: Please refer to [I-D.ietf-ipv6-multilink-
subnets].
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 4]
Internet-Draft WiND-SAIL October 2013
Backbone: A link that forms the core of a multi-link subnet. All ARs
and legacy devices are connected to the Backbone and classical
ND operation ensure connectivity over that link.
attached link: An abstract link in a multi-link subnet other than the
backbone. That link is classically not implemented as a fixed
wire, and may only provide non-continuous connectivity, in
particular with support for mobility. An attached link may be
for instance a classical WiFi (IEEE802.11) link, a link in a
wireless mesh network, or an overlay tunnel.
attached node: A device in a multi-link subnet that is not directly
connected to the Backbone but reachable via an attached link.
Backbone Router (BBR): A BBR is an IPv6 router that connects attached
links to a Backbone link and enables the connectivity of an
attached node by proxying IPv6 NDP over the Backbone for that
node, either with the node MAC address, or its own. The BBR is
a 6SME that can obtain attachment states from attached nodes by
different methods, for instance by snooping IPv6 NDP or DHCPv6,
by learning host routes acting as a RPL root, by accepting ND
registrations acting as an AR or an IR.
Stateful Address Identification and Location (SAIL): As opposed to a
cache entry, a SAIL state is Stateful in that it is obtained
and maintained through a (secured) registration mechanism. A
SAIL state may include for instance a secured identification of
the owner of the address (e.g. a trusted token, a public key
or a certificate), the position of the IPv6 address in the
network (e.g. VLAN, Access Switch or Access Point), or the
mapping of the IPv6 address with a MAC address. Some of this
information may be stable, for instance a owner Identification,
while other may be transient, for instance the Access Point
identifier in a mobility scenario or the MAC address mapping in
the case of NDP proxy operations.
State Maintaining Entity (SME): An entity that hold SAIL
information. SMEs are implemented in devices such as security
appliances such as Network Access Controllers (NACs), SAVI
switches that protect the ownership of an IPv6 address and
control the ingress of the network, Wireless LAN Controllers
(WLCs) that terminate a CAPWAP tunnel and must rapidly re-
enable reachability for a mobile device both at layer 2 and
layer 3, as well as overlay terminators such as used for
network virtualization (NVO3). Overlay termination may operate
both at layer 2 or layer 3, and may be found in data centers
and enterprise networks to support mobility or extend the layer
2 fabric over a Layer 3 infrastructure, as well as in Service
Provider networks to support IPv6 mobility.
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 5]
Internet-Draft WiND-SAIL October 2013
Binding: The association of an IPv6 address with some SAIL state. A
registrar maintains a binding table to store and query such
associations.
Registering Node (RN): An IPv6 node that obtains and retains
ownership of an IPv6 address through the process of IPv6 ND
registration.
Authoritative Registrar (AR): A 6SME that stores authoritative
information about a registration. An AR is the reference for
address and SAIL state binding within its domain of authority,
e.g. a specific subset of addresses within a subnet. There
can be multiple ARs in a subnet and domains may overlap for
redundancy and balancing.
Intermediate Registrar (IR): A 6SME that stores information about a
registration as part of the registration flow. IRs form a
directed acyclic graph (DAG) that is directed towards ARs. A
registration from an RN will be addressed to an IR and will
follow the IR DAG till it reaches a node that can grant the
ownership, typically a AR.
Registration Interface (RIF): The interface between an RN and an IR.
The RIF is typically implemented using Wireless ND, but can
also be implicitely implemented by snooping IPv6 ND, e.g. as
suggested by SAVI.
Validation Interface (VIF): The interface between a child IR and a
parent IR or AR. The VIF is typically implemented using this
specification which extends the DAR and DAC messages as defined
in [RFC6775].
Determination Interface (DIF): The interface between ARs. It can be
implemented using LISP, routing protocol extensions, or using
IPv6 ND proxy extensions such as suggested by [I-D.thubert-
6lowpan-backbone-router] .
3. Overview
The scope of this draft is a potentially large and potentially multi-
link subnet [I-D.ietf-ipv6-multilink-subnets] formed by a high speed
Backbone that federates additional links of heterogeneous MAC/PHY
types, for instance an Ethernet switched fabric federating a Route-
Over mesh that may interconnect thousands of LLN devices over
multiple wireless hops.
In order to avoid floods of multicast packets inherent to a reactive
discovery, a node - referred to as a Registering Node (RN) - needs to
claim its addresses proactively, binding them with its location in
the network and a Lower Layer Address (LLA), over confirmed exchanges
with a neighborhood Intermediate Registrar (IR).
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 6]
Internet-Draft WiND-SAIL October 2013
+-----+ +-----+
| | AR | | AR
| | | | ND proxy
+-----+ +-----+
| |
| Backbone Link |
+--------------------+------------------+
| legacy + proxy | + registration |
| mixed | ND operations |
+-----+ +-----+ +-----+
| |IR | |IR | | IR + AR
| |ND proxy | | | | ND proxy
+-----+ +-----+ +-----+
| routing over attached links |
| registration ND operations only |
+-----+ +-----+ +-----+
| |IR | |IR | | IR
| |--------------| |------------| |
+-----+ +-----+ +-----+
The IR may confirm the claim with an Authoritative Registrar (AR),
eventually over a graph of other IRs. If the ownership is granted,
the RN may use the address for a lifetime that is associated with the
grant, at which point it will need to reconfirm the address by
registering again.
In the case of a meshed 6LoWPAN [RFC6282] [RFC6775] LLN topology ,
the neighborhood IR is a 6LoWPAN Router (6LR) and the AR is a 6LoWPAN
Border Router (6LBR). When the topology grows, the IPv6 ND
registration model as described in [RFC6775], with a single AR (the
6LBR), may not scale.
With this draft, all registrars maintain an abstract Binding Table of
their registered addresses. The Binding Table operates as a
distributed database of information related to addresses whether the
address owner reside on the attached links or on the Backbone. ARs
use extensions to the Neighbor Discovery Protocol to exchange that
information across the Backbone either in the classical ND reactive
fashion, or through a new pub/sub mechanism that is introduced by
this specification.
With this specification, multiple IRs and one AR can be deployed so
as to scale the IPv6 ND registration model yet avoiding any broadcast
beyond one Layer-2 hop; IRs cover the whole multi-link subnet in a
fashion that any node in the network has at least one neighborhood IR
one Layer-2 hop away so it may perform an NDP registration with that
IR using link local addresses regardless of the link type, wired or
wireless.
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 7]
Internet-Draft WiND-SAIL October 2013
+-----+
| | -----.
| RN | RIF | +-----+ +-----+ +-----+
+-----+ .-> | | ----> | | ----> | |
.-> | IR | VIF | IR | VIF | AR |
+-----+ RIF | +-----+ +-----+ +-----+
| | -----. ^
| RN | DIF
+-----+ v
+-----+ +-----+ +-----+
... | | VIF | | VIF | |
+-----+ .-> | IR | ----> | IR | ----> | AR |
| | RIF | +-----+ +-----+ +-----+
| RN | -----.
+-----+
IRs and ARs form a DAG directed towards the AR(s); but how this DAG
is set up is out of scope for this specification.
If more than one AR is deployed, a strategy (e.g. a distributed hash
table (DHT) or a DNS-like hierarchy) and a method to distribute and
synchronize the individual domains of authority between ARs, must be
put in place. Such method is out of scope for this document. In the
case where an overlap of domain is acceptable, a protocol must be put
in place between ARs so as to resolve conflicts, and clean up stale
states. Such a protocol is out of scope for this document.
4. General Context
4.1. Efficient ND
[I-D.chakrabarti-nordmark-6man-efficient-nd] updates the
specification of the RIF interface between the RN and the IR, that
was initially defined in [RFC6775] for 6LoWPAN devices. The draft
details the operation of a IPv6 ND-efficiency-aware Router(NEAR),
that is the neighborhood IR to which an RN, which is called a
Efficiency-Aware Host (EAH), registers. A NEAR is also an AR as it
has the exclusive authority on the bindings for its registered EAHs.
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 8]
Internet-Draft WiND-SAIL October 2013
+-----+ +-----+
|NEAR | IR |NEAR | IR
| | AR | | AR <--.
+-----+ +-----+ |
| | new NDP
| Backbone Link | registration
+--------------------+------------------+ |
| legacy + efficient | ND operations | |
| | |
+-------+ +-------+ +-------+
|legacy | |legacy | | EAH | RN
| host | |router | | |
+-------+ +-------+ +-------+
In the case of a WIFI connection, the NEAR is a BBR for the wireless
device, and may be collocated with a standalone AP or a Wireless LAN
Controller.
+-----+ +-----+
|NEAR | IR |NEAR | IR
| | AR |WLC | AR <--.
+-----+ +-----+ |||
| | new NDP
| Backbone Link | registration
+--------------------+------------------+ |||
| | legacy + proxy | | ND operations |||
| | | | |||
o +-----+ o o +-----+ o o +-----+ o
o | AP | o o | AP | o o | AP | o
o +-----+ o o +-----+ o o +-----+ o
o o o o o o
wireless attached links EAH o RN
This specification extends [I-D.chakrabarti-nordmark-6man-efficient-
nd], by allowing the separation of IR and AR functions, which are
collapsed inside the NEAR. This draft introduces the VIF interface
between IRs, and between IRs and ARs, as well as the DIF interface
between ARs with potentially overlapping domain, and other 6SMEs.
For the purpose of the new NDP registration, [I-D.chakrabarti-
nordmark-6man-efficient-nd] defines an extended ARO option that is
advertised by an EAH. The new ARO option includes a sequence counter
called TID that enables a short term freshness assertion between
rapid re-registrations of a mobile device, and a unique ID that is
used for the Duplicate Address Detection (DAD).
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 9]
Internet-Draft WiND-SAIL October 2013
A 6SME may maintain a state for a longer time than covered by the ARO
TID, so a coarse age information is be needed to compare old state
information over the VIF and DIF interfaces. Additionally, the 6SME
may qualify information with additional metadata to help resolve
conflicts. For instance, in the case of a duplicated IPv6 address,
additional meta information such as the protocol that was used to
establish the state (SLAAC vs. DHCPv6), a device type (trusted
server vs. unknown host), or a Secure ND cryptographic address
ownership validation ([RFC3971], [RFC3972]) can help protect the
address where it is assigned in a more trusted fashion even if a
rogue managed to grab the address while the more trusted owner was
not able to defend it.
This specification proposes a new ND option that contains such
information and complements the information in the ARO option for use
on the VIF and DIF interfaces.
4.2. Proxying classical ND
A 6SME such as an IR, a AR or a BBR may proxy classical IPv6 NDP
[RFC4861] on behalf of a virtual, a wireless, or a low power device
so as to offload the device, to dampen the network load such as
induced by the multicast operations of the proxied protocol, or
simply to attract over the backbone and then relay its traffic to the
mobile or sleeping device even if the device is not reachable at that
particular time.
Backbone (Home) Link
+--------------------+------------------+
| legacy + proxy | ND operations |
| | |
+-----+ +-----+ +-----+
|MIP/ |IR + |MIP/ |IR + |MIP/ |IR <-.
|HA |AR |NEMO |AR |NEMO |AR |
+-----+ +-----+ +-----+ Binding
// | | \\ // | | \\ // | | \\ Update
// | | \\ // | | MN MR MN \\ |
MN MN \\ // MR MN --.
MN MN tunnel-based attached links
The 6SME may perform the proxy operation on behalf of an original
device using the original device LLA, or may proxy the Layer-2
information with their own LLA and either rewrite it later in the
packets, or route the packet again over an attached link, as
examplified by a MIPv6 [RFC6275] or a NEMO [RFC3963] Home Agent
(HA).
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 10]
Internet-Draft WiND-SAIL October 2013
The HA is authoritative for any Mobile Node (MN) that successfully
registers to it through a Binding Update/Ack flow and its domain of
authority is the subnet(s) on the Home Link, potentially overlapping
with other HAs. ND proxy operations are used over the Home Link to
resolve collisions.
The MN is thus an RN and the HA cumulates IR, AR and proxy
functionalities. With NEMO [RFC3963], the model is conserved but
the RN is now a Mobile Router that registers a prefix together with
its own address, so the operation in the Backbone link is a mix of ND
proxy and routing. Network Mobility Home Network Models [RFC3963]
provides more information on that model.
4.3. Federating Large LLNs
In the case of a large multi-link subnet, this specification expects
that a Backbone link is deployed to interconnect all the ARs and
legacy NDP devices. Each interconnected attached link, whether it is
a WIFI access, a mesh network, a 6LoWPAN/RPL LLN or an overlaid
tunnel, is anchored to the Backbone at a Backbone Router (BBR). The
BBRs interconnect the multi-link subnet over the Backbone Link at
layer 3, enabling connectivity within the subnet over IP.
+-----+ +-----+
| | AR | | AR
| | | |
+-----+ +-----+
| |
| Backbone Link |
+--------------------+------------------+
| legacy + proxy | + registration |
| mixed | ND operations |
+-----+ +-----+ +-----+
| RPL | BBR | RPL | BBR | RPL | BBR
|root | ND proxy |root | ND proxy |root | ND proxy
+-----+ +-----+ +-----+
IR o o IR o o IR o o o IR o
o o IR o o o IR o IR o o IR o IR
o IR o IR o IR o o o o o o o o o
o IR o o IR o IR
o o o o LLN attached links
If the LLN uses a Route-Over model based on RPL [RFC6550], the
Backbone Router (BBR) that connects the LLN to the Backbone is the
root for the RPL LLN. The BBR proxies the ND protocol over the
backbone for the addresses that it has learnt through RPL as host
routes, using its own LLA and location to attract traffic for the
attached nodes and route it over the LLN.
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 11]
Internet-Draft WiND-SAIL October 2013
Over the Backbone, this setup implements the "simple scenario" in
[I-D.ietf-ipv6-multilink-subnets] whereby the router acts "as an
asymmetric Neighbor Discovery proxy"; over the RPL-based LLN mesh,
the setup implements the more "complex scenario" whereby "an
arbitrary topology exists, and routers within the subnet communicate
using some means of exchanging host routes".
[I-D.thubert-6lowpan-backbone-router] describes this mixed model, and
how a Backbone Router perform ND proxy operation for their attached
nodes over the The Backbone Link regardless of the mode of
registration for the attached nodes. The operation described in the
draft is compatible with that of a MIPv6 [RFC6275] Home Agent. This
enables mobility support for wireless attached nodes that would move
outside of the network delimited by the Backbone link and back. In
any case, it is expected that the registration provides a sequence
counter, a lifetime and a unique identifier of the attached nodes in
such a fashion that they can be matched or compared across protocols.
This specifications indicates how the new ND option can be used in
conjunction with ND proxy techniques over the Backbone to implement
the DIF interface.
5. New types and formats
This section introduces message formats for all messages used in this
specification.
The specification expects that the protocol running on the LLN can
provide a sequence number called Transaction ID (TID) that is
associated to the registration. When a node registers to multiple
registrars (IRs or ARs), it is expected that the same TID is used, to
enable the registrar to correlate the registrations as being a single
one, and differentiate that situation from a movement. Otherwise,
the resolution makes it so that only the most recent registration was
perceived from the highest TID is kept.
The specification expects that the protocol running on the LLN can
provide a unique ID for the owner of the address that is being
registered. The Owner Unique ID enables to differentiate a duplicate
registration from a double registration. In case of a duplicate, the
last registration looses. The Owner Unique ID can be as simple as a
EUI-64 burnin address, if the device manufacturor is convinced that
there can not be a manuf error that would cause duplicate EUI64
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 12]
Internet-Draft WiND-SAIL October 2013
addresses. Alternatively, the unique ID can be a hash of supposedly
unique information from multiple orthogonal sources, for instance:
o Burn in address.
o configured address, id, security keys...
o (pseudo) Random number, radio link metrics ...
In any fashion, it is recommended that the device stores the unique
ID in persistent memory. Otherwise, it will be prevented to re-
register after a reboot that would cause a loss of memory until the
Backbone Router times out the registration.
The unique ID and the sequence number are placed in a new ND option
that is used by the Backbone Routers over the Backbone link to detect
duplicates and movements. The option format is as follows:
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 | Length = 2 |R| rsv |origin | trust |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|N| rsv | TID | Registration age (10 sec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ALI +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Fields
Type: 8-bit identifier of the type of option.
Length: 2
R: One bit flag. Set if the sender is relaying the option received
from a downstream node, whether a RN or an IR.
origin : 4-bit unsigned integer. Indicates the origin of the entry.
0 - SLACC: Address was auto-configured on the RN [RF4862]
1 - DHCP: Address was assigned to the RN by DHCP
2 - LOCAL: Address was manually configured on the RN
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 13]
Internet-Draft WiND-SAIL October 2013
3 - STATIC: Address was manually configured on the IR as a
downstream address, i.e. an address assigned to a downstream
node
4 - DATA: Address was gleaned on the first IR as the source of a
data packet
trust : 4-bit unsigned integer. Indicates the level of trust the
attaching node place in the entry
0 - NO_TRUST: No particular trust associated with the entry
1 - L2L3_MATCH: The layer-2 source MAC and Link-layer-Address
claimed in the registration match
2 - TRUSTED_BY_POLICY: The address is trusted by policy on the
attaching node
3 - AUTHENTICATED The address has been authenticated by a
cryptographic protocol (CGA, etc.)>
T: One bit flag. Set if the next octet is a used as a TID following
follow section 7 of RPL [RFC6550] for sequence counters. If the
bit is not set, a unsigned char is expected.
N: One bit flag. Set if the device moved. If not set, the router
will refrain from sending gratuitous NA(O) over the backbone, for
instance after the DAD operation upon entry creation.
rsv: This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
TID: 1-byte integer; a transaction id that is maintained by the
device and incremented with each transaction. it is recommended
that the device maintains the TID in a persistent storage. The
TID is incremented at each registration.
Registration Age: 2-byte integer; the duration since the last update
of TID in units of 10 seconds.
Attaching Location Identifier: A locally unique identifier for the IR
interface attaching the registering host.
6. Validation Interface Operations
The Validation Interface (VIF) is the interface between a child
Intermediate Registrar (IR) and a parent registrar, whether an
Intermediate Registrar or Authoritative Registrar (AR). An IR parent
or upstream chain is defined as the set of IRs along the DAG starting
from this IR, directed to (and including) the AR. An IR child or
downstream chain is defined as the set of IRs from this IR an entry
was learnt from including the IR attaching to the RN. The goal of VIF
is to perform one or several of the followings:
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 14]
Internet-Draft WiND-SAIL October 2013
o Validate a new registration along the parent chain
o Record a registration along the parent chain
o Update a registration along the parent chain
o Cancel a registration along the parent chain
o Delete a record along the parent chain
o Delete a record along the child chain
6.1. Child to Parent Operations
The first IR in the chain (attached to the RN) initiates validation
and registration of an address registered by the RN or snooped on the
interface attaching the RN to the node, by building a DAR message,
including a SLLA and a SAIL option where:
o Source of the DAR is an IP address of the IR interface to the next
IR in the chain.
o Destination of the DAR is an IP address of the next IR.
o R bit set to zero. If the IR acts as an RN, the the bit is set to
1
o Origin can take any of the values defined, based on how the
address was assigned
o If the registration was received from the RN (or gleaned) on an IR
interface administratively trusted, the field "trust" is set to
TRUSTED_BY_POLICY. Otherwise, if the registration carried CGA
[RFC3971] credential that the IR successfully verified, the field
"trust" is set to AUTHENTICATED. Otherwise, if the source mac of
the registration message received by the IR is identical to the
Link-Layer Address provided by the message in the SLLA option, the
trust field is set to L2L3_MATCH. Otherwise, it is set to
NO_TRUST.
o An SLLA option MUST be included in the DAR message along with the
SAIL option, that contains the Link-Layer address bound to the IP
address bein registered.
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 15]
Internet-Draft WiND-SAIL October 2013
While waiting for a response, a TENTATIVE entry is created on the IR.
Several attributes are stored next to the entry: the EUI64 provided
by the RN, Link Layer Address provided in the SLLA option, the origin
and trust values (computed by the IR, based on the registration, and
local policies), the ALI the registration was received from, the
lifetime. In the absence of a DAC response, DAR messages sent in the
context of VIF fron the IR are retransmitted after 250ms
[DAR_INTERVAL], up to 2 times [MAX_DAR_RETRANSMIT]. Upon receiving a
negative response (duplicate address status) or when the maximum
retransmit is exhausted, the entry is removed from the IR.
The IR can also initiate update and delete operations. An update is
no different from an address validation: the DAR will carry the same
address and EUI-64 as the one provided in a previous validation,
while any other attribute such as SLLA option, Lifetime, Origin,
Trust or ALI will eventually be different from the value previously
provided
In order to cancel a registration, a DAR is sent, with a lifetime set
to zero. It should carry a SAIL option to allow the receiving IR or
AR to validate the delete.
6.2. Parent to Child Operations
6.2.1. Address validation and registration
Upon receiving a DAR message with a SAIL option, an IR will lookup in
the local table to verify whether the address already exist.
If it does not exist, two cases arise.
1. The IR is not an AR. It creates the entry as "TENTATIVE",
together with attributes such as EUI64, IR address it came from,
origin and trust values. It then builds and sends a DAR message
sourced with one address of its interface to the next IR, set
destination address to the next IR address, sets the R bit to 1
and copies all other fields from the received DAR. It also
starts a 250ms TENTATIVE_TIMER timer ot 250ms [DAR_INTERVAL].
Should this timer expire, the DAR is re-transmitted up to 2
times, then the entry is deleted. If a negative response (DAC
with status 1) is received, a DAC with status 1 is sent to the
downstream IR, and the TENTATIVE entry is deleted. If a positive
response (DAC with status 0) is received, the timer
TENTATIVE_TIMER is stopped, the entry state moved to REACHABLE
and a DAC with status 0 is sent to downstream IR.
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 16]
Internet-Draft WiND-SAIL October 2013
2. The IR is also the AR: it queries other ARs over the DIF
interface. While waiting for a response, it may create the entry
in "TENTATIVE" state. Upon confirmation from another AR that the
entry exist elsewhere, the entry in TENTATIVE is deleted, and a
DAC message is sent back to the source of the DAR message
(previous IR), with a status set to 1 (Duplicate address). Upon
receiving this DAC, each downstream IR deletes its own TENTATIVE
entry, and sends a DAC, status 1, to the next child IR until it
reaches the IR attaching the RN, which builds an NA with ARO
option, and status set to duplicate address. If the DIF
interface returns no conflict on the address, the entry state is
moved to REACHABLE, and a DAC with status 0 is sent to the
downstream IRs which move their TENTATIVE entry to REACHABLE.
When the DAC reaches the attaching IR, it send an NA with ARO
option, status 0 to the RN.
If the same address carried in the DAR exist on one of the IR or the
AR, with a different EUI-64 interface identifier, the two entries
attributes are compared. A trustlevel value is computed for each
entry (as a function of the trust value, the origin and the R bit).
The two trustlevel values are compared numerically as follows:
1. If the trustlevel of the existing entry is bigger or equal than
the one carried by the DAR, the DAR is not propagated, and a DAC
with status 1 (duplicate address) is sent back to downstream IR,
up to the attaching IR which sends a NA with an ARO option,
status 1 to the RN.
2. If the trustlevel of the existing entry is strictly smaller that
the one carried by the DAR, it replaces it, and the DAR is
propagated towards the upstream IR up to the AR. Again, DAR
follow the rule of hop-by-hop retransmission and acknowledgment
already described.
3. At the same time, if the entry being replaced was associated with
a different IR than the one this DAR came from, another DAR, with
the previous EUI64 value, and a lifetime set to zero is sent to
downstream IR the previous registration came from. This message
causes the downstream IR to remove the entry, provided that the
EUI64 match, to build and send a DAR to the next IR, and to
acknowledge the deletion with a DAC, status 0. If the EUI64 don't
match, it means the entry has already been replaced, and the DAR
need not to be propagated from this IR. DAR retransmission
follow the same pattern already described. DAC are not
propagated. Upon receiving the DAR with lifetime set to zero,
the attaching IR sends an unsolicited NA to the RN with an ARO
option, status 1 (duplicate address).
6.2.2. Registration update
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 17]
Internet-Draft WiND-SAIL October 2013
An update message is a DAR that carries an address and EUI64
interface identifier matching an IR or AR table entry, and at least
one of the following field different from the previously registered
value: LifeTime, Origin, trust, ALI or IR child. Upon receiving an
update, the IR or AR updates its entry and propagate to the upstream
IR or AR. The AR will in return send a DAC message with a status of 0
to acknowledge the update.
If the attribute being updated is the IR address the DAR is coming
from (child IR), the host has moved to a different downstream IR
chain, and the entry along the previous chain must be cleaned up. A
DAR message, with a lifetime set to zero is sent (and retried if not
acknowledged) to the old downstream IR. This message causes the
downstream IR to remove the entry. The downstream IR should
propagate the DAR to the next IR in chain, and acknowledge it with a
DAC.
6.3. Registration deletion
A registration deletion can come from the IR attaching to the RN,
because the RN left the link, from any IR as the result of an
administrative action, or from the AR because the lifetime has
expired or again following an administrative action. In all cases, a
DAR message with a lifetime set to zero is sent either upstream or
downstream, retried and acknowledged at each hop along the chain, if
necessary. When the deletion is initiated on the IR attaching to the
RN, a SAIL option MUST be provided to enable any upstream registrar
to verify that the deletion is coming from the location the RN was
attached to. For deletion following the parent chain, the ALI value
carried in the SAIL option is compared with the ALI value registered
for this address, and entry is deleted is the two match. For
deletion following the child chain, this check is not required. Upon
deleting the entry, the IR builds and sends a DAC to acknowledge the
deletion, then build and send a DAR to propagate the deletion,
downstream or upstream.
7. Security Considerations
This specification expects that the link layer is sufficiently
protected, either by means of physical or IP security for the
Backbone Link or MAC sublayer cryptography. In particular, it is
expected that the LLN MAC provides secure unicast to/from the
Backbone Router and secure BBRoadcast from the Backbone Router in a
way that prevents tempering with or replaying the RA messages.
The use of EUI-64 for forming the Interface ID in the link local
address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
address privacy techniques. Considering the envisioned deployments
and the MAC layer security applied, this is not considered an issue
at this time.
8. IANA Considerations
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 18]
Internet-Draft WiND-SAIL October 2013
A new type is requested for an ND option.
9. Acknowledgments
TBD
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.
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.
[RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 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.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP. and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6620] Nordmark, E., Bagnulo, M. and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC
6620, May 2012.
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 19]
Internet-Draft WiND-SAIL October 2013
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012.
10.2. Informative References
[I-D.chakrabarti-nordmark-6man-efficient-nd]
Chakrabarti, S., Nordmark, E. and M. Wasserman,
"Efficiency aware IPv6 Neighbor Discovery Optimizations",
Internet-Draft draft-chakrabarti-nordmark-6man-efficient-
nd-01, November 2012.
[I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", Internet-Draft draft-ietf-ipv6-multilink-
subnets-00, July 2002.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", Internet-Draft draft-ietf-roll-terminology-12,
March 2013.
[I-D.thubert-6lowpan-backbone-router]
Thubert, P., "6LoWPAN Backbone Router", Internet-Draft
draft-thubert-6lowpan-backbone-router-03, February 2013.
[RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-
Specific Extensions", RFC 3115, April 2001.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4887] Thubert, P., Wakikawa, R. and V. Devarapalli, "Network
Mobility Home Network Models", RFC 4887, July 2007.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June
2007.
[RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC
4919, August 2007.
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 20]
Internet-Draft WiND-SAIL October 2013
[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
Authors' Addresses
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis, 06410
FRANCE
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Eric Levy-Abegnoli
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis, 06410
FRANCE
Phone: +33 4 97 23 26 34
Email: elevyabe@cisco.com
Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 21]
