draft-ietf-6lo-rfc6775-update-20.txt   draft-ietf-6lo-rfc6775-update-21.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Updates: 6775 (if approved) E. Nordmark Updates: 6775 (if approved) E. Nordmark
Intended status: Standards Track Zededa Intended status: Standards Track Zededa
Expires: December 8, 2018 S. Chakrabarti Expires: December 21, 2018 S. Chakrabarti
Verizon Verizon
C. Perkins C. Perkins
Futurewei Futurewei
June 6, 2018 June 19, 2018
Registration Extensions for 6LoWPAN Neighbor Discovery Registration Extensions for 6LoWPAN Neighbor Discovery
draft-ietf-6lo-rfc6775-update-20 draft-ietf-6lo-rfc6775-update-21
Abstract Abstract
This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
clarify the role of the protocol as a registration technique, clarify the role of the protocol as a registration technique,
simplify the registration operation in 6LoWPAN routers, as well as to simplify the registration operation in 6LoWPAN routers, as well as to
provide enhancements to the registration capabilities and mobility provide enhancements to the registration capabilities and mobility
detection for different network topologies including the backbone detection for different network topologies including the Routing
routers performing proxy Neighbor Discovery in a low power network. Registrars performing routing for host routes and/or proxy Neighbor
Discovery in a low power network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2018. This Internet-Draft will expire on December 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 18
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Acronym Definitions . . . . . . . . . . . . . . . . . . . 4
2.4. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 5 2.4. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability of Address Registration Options . . . . . . . . 6 3. Applicability of Address Registration Options . . . . . . . . 6
4. Extended ND Options and Messages . . . . . . . . . . . . . . 7 4. Extended Neighbor Discovery Options and Messages . . . . . . 7
4.1. Extended Address Registration Option (EARO) . . . . . . . 7 4.1. Extended Address Registration Option (EARO) . . . . . . . 7
4.2. Extended Duplicate Address Message Formats . . . . . . . 11 4.2. Extended Duplicate Address Message Formats . . . . . . . 11
4.3. New 6LoWPAN Capability Bits in the Capability Indication 4.3. Extensions to the Capability Indication Option . . . . . 12
Option . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 13 5. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Extending the Address Registration Option . . . . . . . . 14 5.1. Extending the Address Registration Option . . . . . . . . 14
5.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 15 5.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Comparing TID values . . . . . . . . . . . . . . . . 15 5.2.1. Comparing TID values . . . . . . . . . . . . . . . . 16
5.3. Registration Ownership Verifier (ROVR) . . . . . . . . . 17 5.3. Registration Ownership Verifier (ROVR) . . . . . . . . . 17
5.4. Extended Duplicate Address Messages . . . . . . . . . . . 18 5.4. Extended Duplicate Address Messages . . . . . . . . . . . 19
5.5. Registering the Target Address . . . . . . . . . . . . . 18 5.5. Registering the Target Address . . . . . . . . . . . . . 19
5.6. Link-Local Addresses and Registration . . . . . . . . . . 19 5.6. Link-Local Addresses and Registration . . . . . . . . . . 20
5.7. Maintaining the Registration States . . . . . . . . . . . 20 5.7. Maintaining the Registration States . . . . . . . . . . . 21
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 22 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 23
6.1. Signaling EARO Capability Support . . . . . . . . . . . . 23 6.1. Signaling EARO Support . . . . . . . . . . . . . . . . . 23
6.2. RFC6775-only 6LN . . . . . . . . . . . . . . . . . . . . 23 6.2. RFC6775-only 6LN . . . . . . . . . . . . . . . . . . . . 24
6.3. RFC6775-only 6LR . . . . . . . . . . . . . . . . . . . . 23 6.3. RFC6775-only 6LR . . . . . . . . . . . . . . . . . . . . 24
6.4. RFC6775-only 6LBR . . . . . . . . . . . . . . . . . . . . 24 6.4. RFC6775-only 6LBR . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. EARO I-Field . . . . . . . . . . . . . . . . . . . . . . 28
9.3. New ARO Status values . . . . . . . . . . . . . . . . . . 29 9.3. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 28
9.4. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . . 29 9.4. New ARO Status values . . . . . . . . . . . . . . . . . . 29
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9.5. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.2. Terminology Related References . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Terminology Related References . . . . . . . . . . . . . 32
11.3. Informative References . . . . . . . . . . . . . . . . . 32 11.3. Informative References . . . . . . . . . . . . . . . . . 32
11.4. External Informative References . . . . . . . . . . . . 35 11.4. External Informative References . . . . . . . . . . . . 35
Appendix A. Applicability and Requirements Served (Not Appendix A. Applicability and Requirements Served (Not
Normative) . . . . . . . . . . . . . . . . . . . . . 35 Normative) . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Requirements (Not Normative) . . . . . . . . . . . . 36 Appendix B. Requirements (Not Normative) . . . . . . . . . . . . 37
B.1. Requirements Related to Mobility . . . . . . . . . . . . 36 B.1. Requirements Related to Mobility . . . . . . . . . . . . 37
B.2. Requirements Related to Routing Protocols . . . . . . . . 37 B.2. Requirements Related to Routing Protocols . . . . . . . . 38
B.3. Requirements Related to the Variety of Low-Power Link B.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 38 types . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.4. Requirements Related to Proxy Operations . . . . . . . . 39 B.4. Requirements Related to Proxy Operations . . . . . . . . 40
B.5. Requirements Related to Security . . . . . . . . . . . . 39 B.5. Requirements Related to Security . . . . . . . . . . . . 40
B.6. Requirements Related to Scalability . . . . . . . . . . . 41 B.6. Requirements Related to Scalability . . . . . . . . . . . 42
B.7. Requirements Related to Operations and Management . . . . 41 B.7. Requirements Related to Operations and Management . . . . 42
B.8. Matching Requirements with Specifications . . . . . . . . 42 B.8. Matching Requirements with Specifications . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
IPv6 Low-Power Lossy Networks (LLNs) support star and mesh IPv6 Low-Power Lossy Networks (LLNs) support star and mesh
topologies. For such networks, "Neighbor Discovery Optimization for topologies. For such networks, "Neighbor Discovery Optimization for
IPv6 over Low-Power Wireless Personal Area Networks" (6LoWPAN ND) IPv6 over Low-Power Wireless Personal Area Networks" (6LoWPAN ND)
[RFC6775] defines a registration mechanism and a central registrar to [RFC6775] defines a registration mechanism and a central IPv6 ND
assure unique addresses. The 6LoWPAN ND mechanism reduces the Registrar to assure unique addresses. The 6LoWPAN ND mechanism
dependency of the IPv6 Neighbor Discovery Protocol (IPv6 ND) reduces the dependency of the IPv6 Neighbor Discovery Protocol (IPv6
[RFC4861][RFC4862] on network-layer multicast and link-layer ND) [RFC4861][RFC4862] on network-layer multicast and link-layer
broadcast operations. broadcast operations.
This specification updates 6LoWPAN ND to simplify and generalize This specification updates 6LoWPAN ND to simplify and generalizes
registration in 6LoWPAN routers (6LRs). In particular, this registration in 6LoWPAN routers (6LRs). In particular, this
specification modifies and extends the behavior and protocol elements specification modifies and extends the behavior and protocol elements
of 6LoWPAN ND to enable the following actions: of 6LoWPAN ND to enable the following actions:
o Determine the freshest location in case of node mobility o Determine the most recent location in case of node mobility
o Simplify the registration flow for Link-Local Addresses o Simplify the registration flow for Link-Local Addresses
o Support of a Leaf Node in a Route-Over network o Support a routing-unaware Leaf Node in a Route-Over network
o Proxy registration in a Route-Over network o Proxy registration in a Route-Over network
o Associate the registration with a variable-length Registration o Enable verification for the registration, using the Registration
Ownership Verifier (ROVR) Ownership Verifier (ROVR)
o Registration via an IPv6 ND proxy over a Backbone Link (6BBR) o Registration to an IPv6 ND proxy (e.g., a Routing Registrar)
o Better support for privacy and temporary addresses o Better support for privacy and temporary addresses
These features satisfy requirements as listed in Appendix B. These features satisfy requirements as listed in Appendix B.
2. Terminology 2. Terminology
2.1. BCP 14 2.1. BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. References 2.2. References
In this document, readers will encounter terms and concepts that are In this document, readers will encounter terms and concepts that are
discussed in the following documents: discussed in the following documents:
o "Cryptographically Generated Addresses (CGA)" [RFC3972],
o "Neighbor Discovery for IP version 6" [RFC4861], o "Neighbor Discovery for IP version 6" [RFC4861],
o "IPv6 Stateless Address Autoconfiguration" [RFC4862], o "IPv6 Stateless Address Autoconfiguration" [RFC4862],
o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919], Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
o "Problem Statement and Requirements for IPv6 over Low-Power o "Problem Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and
o "Neighbor Discovery Optimization for Low-power and Lossy Networks" o "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775], [RFC6775],
2.3. New Terms 2.3. Acronym Definitions
Backbone Link: An IPv6 transit link that interconnects two or more
Backbone Routers.
Backbone Router (6BBR): A logical network function in an IPv6 router
that proxies the 6LoWPAN ND operations specified in this
document to assure address uniqueness and other functions
required so that multiple LLNs can operate as a single IPv6
network.
Binding: The association between an IP address, a MAC address, and
other information about the node that owns the IP Address.
Registration: The process by which a 6LN registers an IPv6 Address
with a 6LR in order to establish connectivity to the LLN. In a
Route-Over network, a 6LBR may register the 6LN to the 6BBR.
Registered Node: The 6LN for which the registration is performed,
and which owns the fields in the Extended ARO option.
Registering Node: The node that performs the registration; either
the Registered Node or a proxy.
Registered Address: An address registered for the Registered Node.
RFC6775-only: An implementation, a type of node, or a message that
behaves only as specified by [RFC6775], as opposed to the
behavior specified in this document.
Route-Over network: A network for which connectivity provided at the
IP layer.
updated: A 6LN, a 6LR, or a 6LBR that supports this specification,
in contrast to an RFC6775-only device.
2.4. Subset of a 6LoWPAN Glossary
This document often uses the following acronyms: This document uses the following acronyms:
6BBR: 6LoWPAN Backbone Router 6BBR: 6LoWPAN Backbone Router
6LBR: 6LoWPAN Border Router 6LBR: 6LoWPAN Border Router
6LN: 6LoWPAN Node 6LN: 6LoWPAN Node
6LR: 6LoWPAN Router 6LR: 6LoWPAN Router
6CIO: Capability Indication Option 6CIO: Capability Indication Option
skipping to change at page 6, line 20 skipping to change at page 5, line 30
ROVR: Registration Ownership Verifier (pronounced rover) ROVR: Registration Ownership Verifier (pronounced rover)
RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) [RFC6550] RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) [RFC6550]
RA: Router Advertisement RA: Router Advertisement
RS: Router Solicitation RS: Router Solicitation
TID: Transaction ID (a sequence counter in the EARO) TID: Transaction ID (a sequence counter in the EARO)
2.4. New Terms
Backbone Link: An IPv6 transit link that interconnects two or more
Backbone Routers.
Binding: The association between an IP address, a MAC address, and
other information about the node that owns the IP Address.
Registration: The process by which a 6LN registers an IPv6 Address
with a 6LR in order to establish connectivity to the LLN.
Registered Node: The 6LN for which the registration is performed,
according to the fields in the Extended ARO option.
Registering Node: The node that performs the registration; either
the Registered Node or a proxy.
IPv6 ND Registrar: A node that can process a registration in either
NS(EARO) or EDAR messages, and consequently respond with an NA
or EDAC message containing the EARO and appropriate status for
the registration.
Registered Address: An address registered for the Registered Node.
RFC6775-only: An implementation, a type of node, or a message that
behaves only as specified by [RFC6775], as opposed to the
behavior specified in this document.
Route-Over network: A network for which connectivity provided at the
IP layer.
Routing Registrar: An IPv6 ND Registrar that also provides
reachability services for the Registered Address, including
Duplicate Address Detection and proxy Neighbor Advertisement.
Backbone Router (6BBR): A Routing Registrar that proxies the 6LoWPAN
ND operations specified in this document to assure that
multiple LLNs federated by a backbone link operate as a single
IPv6 subnetwork.
updated: A 6LN, a 6LR, or a 6LBR that supports this specification,
in contrast to an RFC6775-only device.
3. Applicability of Address Registration Options 3. Applicability of Address Registration Options
The Address Registration Option (ARO) in [RFC6775] facilitates The Address Registration Option (ARO) in [RFC6775] facilitates
Duplicate Address Detection (DAD) for hosts and populates Neighbor Duplicate Address Detection (DAD) for hosts and populates Neighbor
Cache Entries (NCEs) [RFC4861] in the routers. This reduces the Cache Entries (NCEs) [RFC4861] in the routers. This reduces the
reliance on multicast operations, which are often as intrusive as reliance on multicast operations, which are often as intrusive as
broadcast, in IPv6 ND operations (see broadcast, in IPv6 ND operations (see
[I-D.ietf-mboned-ieee802-mcast-problems]). [I-D.ietf-mboned-ieee802-mcast-problems]).
With this specification, a failed or useless registration can be This document specifies new status codes for registrations rejected
rejected by a 6LR or a 6LBR for reasons other than address by a 6LR or a 6LBR for reasons other than address duplication.
duplication. Examples include: Examples include:
o the router having run out of space; o the router running out of space;
o a registration bearing a stale sequence number perhaps denoting a o a registration bearing a stale sequence number which could happen
movement of the host after the registration was placed; if the host moves after the registration was placed;
o a host misbehaving and attempting to register an invalid address o a host misbehaving and attempting to register an invalid address
such as the unspecified address [RFC4291]; such as the unspecified address [RFC4291];
o a host using an address that is not topologically correct on that o a host using an address that is not topologically correct on that
link. link.
In such cases the host will receive an error to help diagnose the In such cases the host will receive an error to help diagnose the
issue and may retry, possibly with a different address, and possibly issue and may retry, possibly with a different address, and possibly
registering to a different router, depending on the returned error. registering to a different router, depending on the returned error.
skipping to change at page 7, line 22 skipping to change at page 7, line 28
regardless of whether or not they are actively communicating. The regardless of whether or not they are actively communicating. The
number of registrations supported by a 6LoWPAN Router (6LR) or number of registrations supported by a 6LoWPAN Router (6LR) or
6LoWPAN Border Router (6LBR) MUST be clearly documented by the vendor 6LoWPAN Border Router (6LBR) MUST be clearly documented by the vendor
and the dynamic use of associated resources SHOULD be made available and the dynamic use of associated resources SHOULD be made available
to the network operator, e.g., to a management console. Network to the network operator, e.g., to a management console. Network
administrators need to ensure that 6LR/6LBRs in their network support administrators need to ensure that 6LR/6LBRs in their network support
the number and type of devices that can register to them, based on the number and type of devices that can register to them, based on
the number of IPv6 addresses that those devices require and their the number of IPv6 addresses that those devices require and their
address renewal rate and behavior. address renewal rate and behavior.
4. Extended ND Options and Messages 4. Extended Neighbor Discovery Options and Messages
This specification does not introduce new options; it modifies This specification does not introduce new options; it modifies
existing options and updates the associated behaviors. existing options and updates the associated behaviors.
4.1. Extended Address Registration Option (EARO) 4.1. Extended Address Registration Option (EARO)
The Address Registration Option (ARO) is defined in section 4.1 of The Address Registration Option (ARO) is defined in section 4.1 of
[RFC6775]. [RFC6775].
This specification introduces the Extended Address Registration This specification introduces the Extended Address Registration
Option (EARO) based on the ARO for use in NS and NA messages. The Option (EARO) based on the ARO for use in NS and NA messages. The
EARO includes a sequence counter called Transaction ID (TID) that is EARO includes a sequence counter called Transaction ID (TID) that is
used to determine the latest location of a registering mobile device. used to determine the latest location of a registering mobile device.
A new 'T' flag indicates the presence of the TID field is populated A new 'T' flag indicates the presence of the TID field is populated
and that the option is an EARO. A 6LN requests routing or proxy and that the option is an EARO. A 6LN requests routing or proxy
services from a 6LR using a new 'R' flag in the EARO. services from a 6LR using a new 'R' flag in the EARO.
The EUI-64 field is redefined and renamed ROVR in order to carry The EUI-64 field is redefined and renamed ROVR in order to carry
different types of information, e.g., cryptographic information of different types of information, e.g., cryptographic information of
variable size. A larger ROVR size MAY be used if and only if variable size. A larger ROVR size MAY be used if and only if
backward compatibility is not an issue in the particular deployment. backward compatibility is not an issue in the particular LLN. The
The length of the ROVR field expressed in units of 8 bytes is the length of the ROVR field expressed in units of 8 bytes is the Length
Length of the option minus 1. of the option minus 1.
Section 5.1 discusses those changes in depth. Section 5.1 discusses those changes in depth.
The format of the EARO is shown in Figure 1: The format of the EARO is shown in Figure 1:
0 1 2 3 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 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 | Status | Opaque | | Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime | | Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EARO Option Format Figure 1: EARO Option Format
Option Fields: Option Fields:
Type: 33 Type: 33
Length: 8-bit unsigned integer. The length of the option in Length: 8-bit unsigned integer. The length of the option in
skipping to change at page 8, line 48 skipping to change at page 9, line 6
I: Two-bit Integer: A value of zero indicates that the I: Two-bit Integer: A value of zero indicates that the
Opaque field carries an abstract index that is used Opaque field carries an abstract index that is used
to decide in which routing topology the address is to decide in which routing topology the address is
expected to be injected. In that case, the Opaque expected to be injected. In that case, the Opaque
field is passed to a routing process with the field is passed to a routing process with the
indication that it carries topology information, and indication that it carries topology information, and
the value of 0 indicates default. All other values the value of 0 indicates default. All other values
of "I" are reserved and MUST NOT be used. of "I" are reserved and MUST NOT be used.
R: The Registering Node sets the 'R' flag to request R: The Registering Node sets the 'R' flag to request
reachability for the registered address, e.g., by reachability services for the registered address from
advertising the address in a Route-Over routing a Routing Registrar.
protocol or proxying ND over a Backbone Link.
T: One-bit flag. Set if the next octet is used as a T: One-bit flag. Set if the next octet is used as a
TID. TID.
TID: One-byte integer; a Transaction ID that is maintained TID: One-byte unsigned integer; a Transaction ID that is
by the node and incremented with each transaction of maintained by the node and incremented with each
one or more registrations performed at the same time transaction of one or more registrations performed at
to one or more respective 6LRs. This field MUST be the same time to one or more 6LRs. This field MUST
ignored if the 'T' flag is not set. be ignored if the 'T' flag is not set.
Registration Lifetime: 16-bit integer; expressed in minutes. A Registration Lifetime: 16-bit integer; expressed in minutes. A
value of 0 indicates that the registration has ended value of 0 indicates that the registration has ended
and that the associated state MUST be removed. and that the associated state MUST be removed.
Registration Ownership Verifier (ROVR): Enables the correlation Registration Ownership Verifier (ROVR): Enables the correlation
between multiple attempts to register a same IPv6 between multiple attempts to register a same IPv6
Address. The ROVR size MUST be 64 bits when backward Address. The ROVR size MUST be 64 bits when backward
compatibility is needed; otherwise the size MAY be compatibility is needed; otherwise the size MAY be
128, 192, or 256 bits. 128, 192, or 256 bits.
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Description | | Value | Description |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 0..2 | As defined in [RFC6775]. Note: a Status of 1 ("Duplicate | | 0..2 | As defined in [RFC6775]. Note: a Status of 1 ("Duplicate |
| | Address") applies to the Registered Address. If the | | | Address") applies to the Registered Address. If the |
| | Source Address conflicts with an existing registration, | | | Source Address conflicts with an existing registration, |
| | "Duplicate Source Address" MUST be used. | | | "Duplicate Source Address" MUST be used. |
| | | | | |
| 3 | Moved: The registration failed because it is not the | | 3 | Moved: The registration failed because it is not the most |
| | freshest. This Status indicates that the registration is | | | recent. This Status indicates that the registration is |
| | rejected because another more recent registration was | | | rejected because another more recent registration was |
| | done, as indicated by a same ROVR and a more recent TID. | | | done, as indicated by a same ROVR and a more recent TID. |
| | One possible cause is a stale registration that has | | | One possible cause is a stale registration that has |
| | progressed slowly in the network and was passed by a more | | | progressed slowly in the network and was passed by a more |
| | recent one. It could also indicate a ROVR collision. | | | recent one. It could also indicate a ROVR collision. |
| | | | | |
| 4 | Removed: The binding state was removed. This status MAY | | 4 | Removed: The binding state was removed. This status MAY |
| | be placed in an NA(EARO) message that is sent as the | | | be placed in an NA(EARO) message that is sent as the |
| | rejection of a proxy registration to a Backbone Router, | | | rejection of a proxy registration to an IPv6 ND |
| | or in an asynchronous NA(EARO) at any time. | | | Registrar, or in an asynchronous NA(EARO) at any time. |
| | | | | |
| 5 | Validation Requested: The Registering Node is challenged | | 5 | Validation Requested: The Registering Node is challenged |
| | for owning the Registered Address or for being an | | | for owning the Registered Address or for being an |
| | acceptable proxy for the registration. A registrar (6LR, | | | acceptable proxy for the registration. An IPv6 ND |
| | 6LBR, 6BBR) MAY place this Status in asynchronous DAC or | | | Registrar MAY place this Status in asynchronous DAC or NA |
| | NA messages. | | | messages. |
| | | | | |
| 6 | Duplicate Source Address: The address used as source of | | 6 | Duplicate Source Address: The address used as source of |
| | the NS(EARO) conflicts with an existing registration. | | | the NS(EARO) conflicts with an existing registration. |
| | | | | |
| 7 | Invalid Source Address: The address used as source of the | | 7 | Invalid Source Address: The address used as source of the |
| | NS(EARO) is not a Link-Local Address. | | | NS(EARO) is not a Link-Local Address. |
| | | | | |
| 8 | Registered Address topologically incorrect: The address | | 8 | Registered Address topologically incorrect: The address |
| | being registered is not usable on this link. | | | being registered is not usable on this link. |
| | | | | |
skipping to change at page 11, line 20 skipping to change at page 11, line 20
extended as shown in Figure 2: extended as shown in Figure 2:
0 1 2 3 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 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 |CodePfx|CodeSfx| Checksum | | Type |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TID | Registration Lifetime | | Status | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Registered Address + + Registered Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 10 skipping to change at page 12, line 10
TID: 1-byte integer; same definition and processing as the TID: 1-byte integer; same definition and processing as the
TID in the EARO as defined in Section 4.1. This TID in the EARO as defined in Section 4.1. This
field MUST be ignored if the ICMP Code is null. field MUST be ignored if the ICMP Code is null.
Registration Ownership Verifier (ROVR): The size of the ROVR is Registration Ownership Verifier (ROVR): The size of the ROVR is
known from the ICMP Code Suffix. This field has the known from the ICMP Code Suffix. This field has the
same definition and processing as the ROVR in the same definition and processing as the ROVR in the
EARO option as defined in Section 4.1. EARO option as defined in Section 4.1.
4.3. New 6LoWPAN Capability Bits in the Capability Indication Option 4.3. Extensions to the Capability Indication Option
This specification defines 5 new capability bits for use in the 6CIO, This specification defines 5 new capability bits for use in the 6CIO,
defined by [RFC7400] for use in IPv6 ND messages. defined by [RFC7400] for use in IPv6 ND messages.
The "E" flag indicates that EARO can be used in a registration. A The "E" flag indicates that EARO can be used in a registration. A
6LR that supports this specification MUST set the "E" flag. 6LR that supports this specification MUST set the "E" flag.
The "D" flag indicates that the 6LBR supports EDA Messages. A 6LR The "D" flag indicates that the 6LBR supports EDAR and EDAC messages.
that learns the "D" flag from advertisements can then exchange EDAR A 6LR that learns the "D" flag from advertisements can then exchange
and EDAC messages with the 6LBR, and it also sets the "D" flag as EDAR and EDAC messages with the 6LBR, and it also sets the "D" flag
well as the "L" flag in the 6CIO in its own advertisements. In this as well as the "L" flag in the 6CIO in its own advertisements. In
way, 6LNs will be able to prefer registration with a 6LR that can this way, 6LNs will be able to prefer registration with a 6LR that
make use of new 6LBR features. can make use of new 6LBR features.
The new "L", "B", and "P" flags, indicate whether a router is capable The new "L", "B", and "P" flags, indicate whether a router is capable
of acting as 6LR, 6LBR, and 6BBR, respectively. These flags are not of acting as 6LR, 6LBR, and Routing Registrar (e.g., 6BBR),
mutually exclusive; an updated node can advertise multiple collocated respectively. These flags are not mutually exclusive; an updated
functions. node can advertise multiple collocated functions.
0 1 2 3 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 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 = 1 | Reserved |D|L|B|P|E|G| | Type | Length = 1 | Reserved |D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: New Capability Bits in the 6CIO Figure 3: New Capability Bits in the 6CIO
Option Fields: Option Fields:
Type: 36 Type: 36
L: Node is a 6LR. L: Node is a 6LR.
B: Node is a 6LBR. B: Node is a 6LBR.
P: Node is a 6BBR. P: Node is a Routing Registrar.
E: Node supports registrations based on EARO. E: Node is an IPv6 ND Registrar -- i.e., it supports registrations
based on EARO.
D: 6LBR supports EDA messages. D: 6LBR supports EDAR and EDAC messages.
5. Updating RFC 6775 5. Updating RFC 6775
The Extended Address Registration Option (EARO) (see Section 4.1) The Extended Address Registration Option (EARO) (see Section 4.1)
updates the ARO used within Neighbor Discovery NS and NA messages updates the ARO used within NS and NA messages between a 6LN and a
between a 6LN and its 6LR. Similarly, EDAR and EDAC update the DAR 6LR. The update enables a registration to a Routing Registrar in
and DAC messages so as to transport the new information between 6LRs order to obtain additional services, such as return routability to
and 6LBRs across an LLN mesh. the Registered Address by such means as routing and/or proxy Neighbor
Discovery, as illustrated in Figure 4.
The extensions to the ARO option are the Duplicate Address Request
(DAR) and Duplicate Address Confirmation (DAC), used in the Duplicate
Address messages. They convey the additional information all the way
to the 6LBR. In turn the 6LBR may proxy the registration using IPv6
ND over a Backbone Link as illustrated in Figure 4. This
specification avoids the Duplicate Address message flow for Link-
Local Addresses in a Route-Over [RFC6606] topology (see Section 5.6).
6LN 6LR 6LBR 6BBR Routing
| | | | 6LN Registrar
| NS(EARO) | | | | |
|--------------->| | | | NS(EARO) |
| | Extended DAR | | |--------------->|
| |-------------->| | | |
| | | | | | Inject / Maintain
| | | proxy NS(EARO) | | | Host Route or
| | |--------------->| | | IPv6 ND proxy state
| | | | NS(DAD) | | <----------------->
| | | | ------> | NA(EARO) |
| | | | <wait> |<---------------|
| | | | | |
| | | proxy NA(EARO) |
| | |<---------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |
Figure 4: (Re-)Registration Flow Figure 4: (Re-)Registration Flow
Similarly, EDAR and EDAC update the DAR and DAC messages so as to
transport the new information between 6LRs and 6LBRs across an LLN
mesh. The extensions to the ARO option are the Duplicate Address
Request (DAR) and Duplicate Address Confirmation (DAC), used in the
Duplicate Address messages. They convey the additional information
all the way to the 6LBR.
In turn the 6LBR may proxy the registration to obtain reachability
services from a Routing Registrar such as a 6BBR, as illustrated in
Figure 5. This specification avoids the Duplicate Address message
flow for Link-Local Addresses in a Route-Over [RFC6606] topology (see
Section 5.6).
Routing
6LN 6LR 6LBR Registrar
| | | |
|<Link-local>| <Routed> |<Link-local>|
| | | |
| NS(EARO) | | |
|----------->| | |
| | Extended DAR | |
| |------------->| |
| | | proxy |
| | | NS(EARO) |
| | |----------->|
| | | | Inject / maintain
| | | | Host Route or
| | | | IPv6 ND proxy state
| | | | <----------------->
| | | proxy |
| | | NA(EARO) |
| | Extended DAC |<-----------|
| |<-------------| |
| NA(EARO) | | |
|<-----------| | |
| | | |
Figure 5: (Re-)Registration Flow
This specification allows multiple registrations, including for This specification allows multiple registrations, including for
privacy / temporary addresses and provides a mechanism to help clean privacy / temporary addresses and provides a mechanism to help clean
up stale registration state as soon as possible, e.g., after a up stale registration state as soon as possible, e.g., after a
movement (see Section 7). movement (see Section 7).
Section 5 of [RFC6775] specifies how a 6LN bootstraps an interface Section 5 of [RFC6775] specifies how a 6LN bootstraps an interface
and locates available 6LRs. A Registering Node SHOULD register to a and locates available 6LRs. A Registering Node SHOULD register to a
6LR that supports this specification if one is found, as discussed in 6LR that supports this specification if one is found, as discussed in
Section 6.1, instead of registering to an RFC6775-only one; otherwise Section 6.1, instead of registering to an RFC6775-only one; otherwise
the Registering Node operates in a backward-compatible fashion when the Registering Node operates in a backward-compatible fashion when
skipping to change at page 14, line 21 skipping to change at page 15, line 8
The Extended ARO (EARO) updates the ARO and is backward compatible The Extended ARO (EARO) updates the ARO and is backward compatible
with the ARO if and only if the Length of the option is set to 2. with the ARO if and only if the Length of the option is set to 2.
Its format is presented in Section 4.1. More details on backward Its format is presented in Section 4.1. More details on backward
compatibility can be found in Section 6. compatibility can be found in Section 6.
The Neighbor Solicitation (NS) and the ARO are modified as follows: The Neighbor Solicitation (NS) and the ARO are modified as follows:
o The Target Address in the NS containing the EARO is now the field o The Target Address in the NS containing the EARO is now the field
that indicates the address that is being registered, as opposed to that indicates the address that is being registered, as opposed to
the Source Address field as specified in [RFC6775] (see the Source Address field as specified in [RFC6775] (see
Section 5.5). This change enables a 6LBR to use one of its Section 5.5). This change enables a 6LBR to send a proxy
addresses as source of the proxy-registration of an address that registration for a 6LN's address to a Routing Registrar, and also
belongs to a LLN Node to a 6BBR. This change also avoids in most avoids in most cases the use of an address as source address
cases the use of an address as source address before it is before it is registered.
registered.
o The EUI-64 field in the ARO Option is renamed Registration o The EUI-64 field in the ARO Option is renamed Registration
Ownership Verifier (ROVR) and is not required to be derived from a Ownership Verifier (ROVR) and is not required to be derived from a
MAC address (see Section 5.3). MAC address (see Section 5.3).
o The option Length MAY be different than 2 and take a value between o The option Length MAY be different than 2 and take a value between
3 and 5, in which case the EARO is not backward compatible with an 3 and 5, in which case the EARO is not backward compatible with an
ARO. The increase of size corresponds to a larger ROVR field, so ARO. The increase of size corresponds to a larger ROVR field, so
the size of the ROVR is inferred from the option Length. the size of the ROVR is inferred from the option Length.
skipping to change at page 15, line 23 skipping to change at page 16, line 8
A 6LN that acts only as a host, when registering, MUST set the 'R' A 6LN that acts only as a host, when registering, MUST set the 'R'
flag to indicate that it is not a router and that it will not handle flag to indicate that it is not a router and that it will not handle
its own reachability. A 6LR that manages its reachability SHOULD NOT its own reachability. A 6LR that manages its reachability SHOULD NOT
set the 'R' flag; if it does, routes towards this router may be set the 'R' flag; if it does, routes towards this router may be
installed on its behalf and may interfere with those it advertises. installed on its behalf and may interfere with those it advertises.
5.2. Transaction ID 5.2. Transaction ID
The TID is a sequence number that is incremented by the 6LN with each The TID is a sequence number that is incremented by the 6LN with each
re-registration to a 6LR. The TID is used to determine the freshness re-registration to a 6LR. The TID is used to determine the recency
of the registration request. The network uses the most recent TID to of the registration request. The network uses the most recent TID to
determine the current (most recent known) location(s) of a moving determine the most recent known location(s) of a moving 6LN. When a
6LN. When a Registered Node is registered with multiple 6LRs in Registered Node is registered with multiple 6LRs in parallel, the
parallel, the same TID MUST be used. This enables the 6LBRs and/or same TID MUST be used. This enables the 6LBRs and/or Routing
6BBRs to determine whether the registrations are the same, and to Registrars to determine whether the registrations are identical, and
distinguish that situation from a movement (see section 4 of to distinguish that situation from a movement (for example, see
[I-D.ietf-6lo-backbone-router] and Section 5.7 below). Appendix A and Section 5.7).
5.2.1. Comparing TID values 5.2.1. Comparing TID values
The operation of the TID is fully compatible with that of the RPL The operation of the TID is fully compatible with that of the RPL
Path Sequence counter as described in the "Sequence Counter Path Sequence counter as described in the "Sequence Counter
Operation" section of the "IPv6 Routing Protocol for Low-Power and Operation" section of the "IPv6 Routing Protocol for Low-Power and
Lossy Networks" [RFC6550] specification. Lossy Networks" [RFC6550] specification.
A TID is deemed to be fresher than another when its value is greater A TID is deemed to be more recent than another when its value is
as determined by the operations detailed in this section. greater as determined by the operations detailed in this section.
The TID range is subdivided in a 'lollipop' fashion ([Perlman83]), The TID range is subdivided in a 'lollipop' fashion ([Perlman83]),
where the values from 128 and greater are used as a linear sequence where the values from 128 and greater are used as a linear sequence
to indicate a restart and bootstrap the counter, and the values less to indicate a restart and bootstrap the counter, and the values less
than or equal to 127 used as a circular sequence number space of size than or equal to 127 used as a circular sequence number space of size
128 as in [RFC1982]. Consideration is given to the mode of operation 128 as in [RFC1982]. Consideration is given to the mode of operation
when transitioning from the linear region to the circular region. when transitioning from the linear region to the circular region.
Finally, when operating in the circular region, if sequence numbers Finally, when operating in the circular region, if sequence numbers
are determined to be too far apart then they are not comparable, as are determined to be too far apart then they are not comparable, as
detailed below. detailed below.
skipping to change at page 18, line 28 skipping to change at page 19, line 11
same address could be impossible until the 6LRs and the 6LBR time out same address could be impossible until the 6LRs and the 6LBR time out
the previous registration, or a management action is taken to clear the previous registration, or a management action is taken to clear
the relevant state in the network. the relevant state in the network.
5.4. Extended Duplicate Address Messages 5.4. Extended Duplicate Address Messages
In order to map the new EARO content in the Extended Duplicate In order to map the new EARO content in the Extended Duplicate
Address (EDA) messages, a new TID field is added to the Extended DAR Address (EDA) messages, a new TID field is added to the Extended DAR
(EDAR) and the Extended DAC (EDAC) messages as a replacement of the (EDAR) and the Extended DAC (EDAC) messages as a replacement of the
Reserved field, and a non-null value of the ICMP Code indicates Reserved field, and a non-null value of the ICMP Code indicates
support for this specification. The format of the EDA messages is support for this specification. The format of the EDAR and EDAC
presented in Section 4.2. messages is presented in Section 4.2.
As with the EARO, the Extended Duplicate Address messages are As with the EARO, the Extended Duplicate Address messages are
backward compatible with the RFC6775-only versions as long as the backward compatible with the RFC6775-only versions as long as the
ROVR field is 64 bits long. Remarks concerning backwards ROVR field is 64 bits long. Remarks concerning backwards
compatibility for the protocol between the 6LN and the 6LR apply compatibility for the protocol between the 6LN and the 6LR apply
similarly between a 6LR and a 6LBR. similarly between a 6LR and a 6LBR.
5.5. Registering the Target Address 5.5. Registering the Target Address
An NS message with an EARO is a registration if and only if it also An NS message with an EARO is a registration if and only if it also
carries an SLLA Option [RFC6775]. The EARO is also used in NS and NA carries an SLLA Option [RFC6775]. The EARO can also be used in NS
messages between Backbone Routers [I-D.ietf-6lo-backbone-router] over and NA messages between Routing Registrars to determine the
the Backbone Link to sort out the distributed registration state; in distributed registration state; in that case, it does not carry the
that case, it does not carry the SLLA Option and is not confused with SLLA Option and is not confused with a registration.
a registration.
The Registering Node is the node that performs the registration to The Registering Node is the node that performs the registration to
the 6BBR. As in [RFC6775], it may be the Registered Node as well, in the Routing Registrar. As in [RFC6775], it may be the Registered
which case it registers one of its own addresses and indicates its Node as well, in which case it registers one of its own addresses and
own MAC Address as Source Link Layer Address (SLLA) in the NS(EARO). indicates its own MAC Address as Source Link Layer Address (SLLA) in
the NS(EARO).
This specification adds the capability to proxy the registration This specification adds the capability to proxy the registration
operation on behalf of a Registered Node that is reachable over an operation on behalf of a Registered Node that is reachable over an
LLN mesh. In that case, if the Registered Node is reachable from the LLN mesh. In that case, if the Registered Node is reachable from the
6BBR over a Mesh-Under mesh, the Registering Node indicates the MAC Routing Registrar via a Mesh-Under mesh, the Registering Node
Address of the Registered Node as the SLLA in the NS(EARO). If the indicates the MAC Address of the Registered Node as the SLLA in the
Registered Node is reachable over a Route-Over mesh from the NS(EARO). If the Registered Node is reachable over a Route-Over mesh
Registering Node, the SLLA in the NS(ARO) is that of the Registering from the Registering Node, the SLLA in the NS(ARO) is that of the
Node. This enables the Registering Node to attract the packets from Registering Node. This enables the Registering Node to attract the
the 6BBR and route them over the LLN to the Registered Node. packets from the Routing Registrar and route them over the LLN to the
Registered Node.
In order to enable the latter operation, this specification changes In order to enable the latter operation, this specification changes
the behavior of the 6LN and the 6LR so that the Registered Address is the behavior of the 6LN and the 6LR so that the Registered Address is
found in the Target Address field of the NS and NA messages as found in the Target Address field of the NS and NA messages as
opposed to the Source Address field. With this convention, a TLLA opposed to the Source Address field. With this convention, a TLLA
option indicates the link-layer address of the 6LN that owns the option indicates the link-layer address of the 6LN that owns the
address. address.
A Registering Node (e.g., a 6LBR also acting as RPL Root) that A Registering Node (e.g., a 6LBR also acting as RPL Root) that
advertises reachability for the 6LN MUST place its own Link Layer advertises reachability for the 6LN MUST place its own Link Layer
skipping to change at page 20, line 5 skipping to change at page 20, line 35
Address to a 6LR in order to obtain further reachability by way of Address to a 6LR in order to obtain further reachability by way of
that 6LR, and in particular to use the Link-Local Address as source that 6LR, and in particular to use the Link-Local Address as source
address to register other addresses, e.g., global addresses. address to register other addresses, e.g., global addresses.
If there is no collision with a previously registered address, then If there is no collision with a previously registered address, then
the Link-Local Address is unique from the standpoint of this 6LR and the Link-Local Address is unique from the standpoint of this 6LR and
the registration is not a duplicate. Two different 6LRs might claim the registration is not a duplicate. Two different 6LRs might claim
the same Link-Local Address but different link-layer addresses. In the same Link-Local Address but different link-layer addresses. In
that case, a 6LN MUST only interact with at most one of the 6LRs. that case, a 6LN MUST only interact with at most one of the 6LRs.
The exchange of EDA messages between the 6LR and a 6LBR, which The exchange of EDAR and EDAC messages between the 6LR and a 6LBR,
ensures that an address is unique across the domain covered by the which ensures that an address is unique across the domain covered by
6LBR, does not need to take place for Link-Local Addresses. the 6LBR, does not need to take place for Link-Local Addresses.
When sending an NS(EARO) to a 6LR, a 6LN MUST use a Link-Local When sending an NS(EARO) to a 6LR, a 6LN MUST use a Link-Local
Address as the source address of the registration, whatever the type Address as the source address of the registration, whatever the type
of IPv6 address that is being registered. That Link-Local Address of IPv6 address that is being registered. That Link-Local Address
MUST be either an address that is already registered to the 6LR, or MUST be either an address that is already registered to the 6LR, or
the address that is being registered. the address that is being registered.
When a 6LN starts up, it typically multicasts a RS and receives one When a 6LN starts up, it typically multicasts a RS and receives one
or more unicast RA messages from 6LRs. If the 6LR can process EARO or more unicast RA messages from 6LRs. If the 6LR can process EARO
messages, then it places a 6CIO in its RA message with the "E" Flag messages, then it places a 6CIO in its RA message with the "E" Flag
skipping to change at page 20, line 31 skipping to change at page 21, line 12
it MUST register a Link-Local Address, using it as both the Source it MUST register a Link-Local Address, using it as both the Source
and the Target Address of an NS(EARO) message. In that case, it is and the Target Address of an NS(EARO) message. In that case, it is
RECOMMENDED to use an address for which DAD is not required (see RECOMMENDED to use an address for which DAD is not required (see
[RFC6775]), e.g., derived from a globally unique EUI-64 address; [RFC6775]), e.g., derived from a globally unique EUI-64 address;
using the SLLA Option in the NS is consistent with existing ND using the SLLA Option in the NS is consistent with existing ND
specifications such as the "Optimistic Duplicate Address Detection specifications such as the "Optimistic Duplicate Address Detection
(ODAD) for IPv6" [RFC4429]. The 6LN MAY then use that address to (ODAD) for IPv6" [RFC4429]. The 6LN MAY then use that address to
register one or more other addresses. register one or more other addresses.
A 6LR that supports this specification replies with an NA(EARO), A 6LR that supports this specification replies with an NA(EARO),
setting the appropriate status. Since there is no exchange of EDA setting the appropriate status. Since there is no exchange of EDAR
messages for Link-Local Addresses, the 6LR may answer immediately to or EDAC messages for Link-Local Addresses, the 6LR may answer
the registration of a Link-Local Address, based solely on its immediately to the registration of a Link-Local Address, based solely
existing state and the Source Link-Layer Option that is placed in the on its existing state and the Source Link-Layer Option that is placed
NS(EARO) message as required in [RFC6775]. in the NS(EARO) message as required in [RFC6775].
A node registers its IPv6 Global Unicast Addresses (GUAs) to a 6LR in A node registers its IPv6 Global Unicast Addresses (GUAs) to a 6LR in
order to establish global reachability for these addresses via that order to establish global reachability for these addresses via that
6LR. When registering with an updated 6LR, a Registering Node does 6LR. When registering with an updated 6LR, a Registering Node does
not use a GUA as Source Address, in contrast to a node that complies not use a GUA as Source Address, in contrast to a node that complies
to [RFC6775]. For non-Link-Local Addresses, the exchange of EDA to [RFC6775]. For non-Link-Local Addresses, the exchange of EDAR and
messages MUST conform to [RFC6775], but the extended formats EDAC messages MUST conform to [RFC6775], but the extended formats
described in this specification for the DAR and the DAC are used to described in this specification for the DAR and the DAC are used to
relay the extended information in the case of an EARO. relay the extended information in the case of an EARO.
5.7. Maintaining the Registration States 5.7. Maintaining the Registration States
This section discusses protocol actions that involve the Registering This section discusses protocol actions that involve the Registering
Node, the 6LR, and the 6LBR. It must be noted that the portion that Node, the 6LR, and the 6LBR. It must be noted that the portion that
deals with a 6LBR only applies to those addresses that are registered deals with a 6LBR only applies to those addresses that are registered
to it; as discussed in Section 5.6, this is not the case for Link- to it; as discussed in Section 5.6, this is not the case for Link-
Local Addresses. The registration state includes all data that is Local Addresses. The registration state includes all data that is
stored in the router relative to that registration, in particular, stored in the router relative to that registration, in particular,
but not limited to, an NCE. 6LBRs and 6BBRs may store additional but not limited to, an NCE. 6LBRs and Routing Registrars may store
registration information and use synchronization protocols that are additional registration information and use synchronization protocols
out of scope of this document. that are out of scope of this document.
A 6LR cannot accept a new registration when its registration storage A 6LR cannot accept a new registration when its registration storage
space is exhausted. In that situation, the EARO is returned in an NA space is exhausted. In that situation, the EARO is returned in an NA
message with a Status Code of "Neighbor Cache Full" (Table 1), and message with a Status Code of "Neighbor Cache Full" (Table 1), and
the Registering Node may attempt to register to another 6LR. the Registering Node may attempt to register to another 6LR.
If the registry in the 6LBR is full, then the 6LBR cannot decide If the registry in the 6LBR is full, then the 6LBR cannot decide
whether a registration for a new address is a duplicate. In that whether a registration for a new address is a duplicate. In that
case, the 6LBR replies to an EDAR message with an EDAC message that case, the 6LBR replies to an EDAR message with an EDAC message that
carries a new Status Code indicating "6LBR Registry Saturated" carries a new Status Code indicating "6LBR Registry Saturated"
skipping to change at page 21, line 46 skipping to change at page 22, line 28
resources become saturated, even if they are correctly planned to resources become saturated, even if they are correctly planned to
start with. The 6LR may then take defensive measures that may start with. The 6LR may then take defensive measures that may
prevent this node or some other nodes from owning as many addresses prevent this node or some other nodes from owning as many addresses
as they request (see Section 7). as they request (see Section 7).
A node that moves away from a particular 6LR SHOULD attempt to de- A node that moves away from a particular 6LR SHOULD attempt to de-
register all of its addresses registered to that 6LR and register to register all of its addresses registered to that 6LR and register to
a new 6LR with an incremented TID. When/if the node appears a new 6LR with an incremented TID. When/if the node appears
elsewhere, an asynchronous NA(EARO) or EDAC message with a Status elsewhere, an asynchronous NA(EARO) or EDAC message with a Status
Code of "Moved" SHOULD be used to clean up the state in the previous Code of "Moved" SHOULD be used to clean up the state in the previous
location. As described in [I-D.ietf-6lo-backbone-router], the location. The "Moved" status can be used by a Routing Registrar in
"Moved" status can be used by a 6BBR in an NA(EARO) message to an NA(EARO) message to indicate that the ownership of the proxy state
indicate that the ownership of the proxy state on the Backbone Link was transferred to another Routing Registrar due to movement of the
was transferred to another 6BBR as the consequence of a movement of device. If the receiver of the message has registration state
the device. If the receiver of the message has registration state
corresponding to the related address, it SHOULD propagate the status corresponding to the related address, it SHOULD propagate the status
down the forwarding path to the Registered node (e.g., reversing an down the forwarding path to the Registered Node (e.g., reversing an
existing RPL [RFC6550] path as prescribed in existing RPL [RFC6550] path as prescribed in
[I-D.ietf-roll-efficient-npdao]). Whether it could do so or not, the [I-D.ietf-roll-efficient-npdao]). Whether it could do so or not, the
receiver MUST clean up said state. receiver MUST clean up said state.
Upon receiving an NS(EARO) message with a Registration Lifetime of 0 Upon receiving an NS(EARO) message with a Registration Lifetime of 0
and determining that this EARO is the freshest for a given NCE (see and determining that this EARO is the most recent for a given NCE
Section 5.2), a 6LR cleans up its NCE. If the address was registered (see Section 5.2), a 6LR cleans up its NCE. If the address was
to the 6LBR, then the 6LR MUST report to the 6LBR, through a registered to the 6LBR, then the 6LR MUST report to the 6LBR, through
Duplicate Address exchange with the 6LBR, indicating the null a Duplicate Address exchange with the 6LBR, indicating the null
Registration Lifetime and the latest TID that this 6LR is aware of. Registration Lifetime and the latest TID that this 6LR is aware of.
Upon receiving the EDAR message, the 6LBR evaluates if this is the Upon receiving the EDAR message, the 6LBR evaluates if this is the
most recent TID it has received for that particular registry entry. most recent TID it has received for that particular registry entry.
If so, then the EDAR is answered with an EDAC message bearing a If so, then the EDAR is answered with an EDAC message bearing a
Status of "Success" and the entry is scheduled to be removed. Status of "Success" and the entry is scheduled to be removed.
Otherwise, a Status Code of "Moved" is returned instead, and the Otherwise, a Status Code of "Moved" is returned instead, and the
existing entry is maintained. existing entry is maintained.
When an address is scheduled to be removed, the 6LBR SHOULD keep its When an address is scheduled to be removed, the 6LBR SHOULD keep its
skipping to change at page 23, line 5 skipping to change at page 23, line 31
A 6LN that supports this specification MUST always use an EARO as a A 6LN that supports this specification MUST always use an EARO as a
replacement for an ARO in its registration to a router. This is replacement for an ARO in its registration to a router. This is
backward-compatible since the 'T' flag and TID field are reserved in backward-compatible since the 'T' flag and TID field are reserved in
[RFC6775], and are ignored by an RFC6775-only router. A router that [RFC6775], and are ignored by an RFC6775-only router. A router that
supports this specification MUST answer an NS(ARO) and an NS(EARO) supports this specification MUST answer an NS(ARO) and an NS(EARO)
with an NA(EARO). A router that does not support this specification with an NA(EARO). A router that does not support this specification
will consider the ROVR as an EUI-64 address and treat it the same, will consider the ROVR as an EUI-64 address and treat it the same,
which has no consequence if the Registered Addresses are different. which has no consequence if the Registered Addresses are different.
6.1. Signaling EARO Capability Support 6.1. Signaling EARO Support
"Generic Header Compression for IPv6 over 6LoWPANs" [RFC7400] "Generic Header Compression for IPv6 over 6LoWPANs" [RFC7400]
specifies the 6LoWPAN Capability Indication Option (6CIO) to indicate specifies the 6LoWPAN Capability Indication Option (6CIO) to indicate
a node's capabilities to its peers. The 6CIO MUST be present in both a node's capabilities to its peers. The 6CIO MUST be present in both
Router Solicitation (RS) and Router Advertisement (RA) messages, Router Solicitation (RS) and Router Advertisement (RA) messages,
unless the 6CIO information was already shared in recent exchanges, unless the 6CIO information was already shared in recent exchanges,
or pre-configured in all nodes in a network. In any case, a 6CIO or pre-configured in all nodes in a network. In any case, a 6CIO
MUST be placed in an RA message that is sent in response to an RS MUST be placed in an RA message that is sent in response to an RS
with a 6CIO. with a 6CIO.
Section 4.3 defines a new flag for the 6CIO to signal support for Section 4.3 defines a new flag for the 6CIO to signal support for
EARO by the issuer of the message. New flags are also added to the EARO by the issuer of the message. New flags are also added to the
6CIO to signal the sender's capability to act as a 6LR, 6LBR, and 6CIO to signal the sender's capability to act as a 6LR, 6LBR, and
6BBR (see Section 4.3). Routing Registrar (see Section 4.3).
Section 4.3 also defines a new flag that indicates the support of EDA Section 4.3 also defines a new flag that indicates the support of
messages by the 6LBR. This flag is valid in RA messages but not in EDAR and EDAC messages by the 6LBR. This flag is valid in RA
RS messages. More information on the 6LBR is found in a separate messages but not in RS messages. More information on the 6LBR is
Authoritative Border Router Option (ABRO). The ABRO is placed in RA found in a separate Authoritative Border Router Option (ABRO). The
messages as prescribed by [RFC6775]; in particular, it MUST be placed ABRO is placed in RA messages as prescribed by [RFC6775]; in
in an RA message that is sent in response to an RS with a 6CIO particular, it MUST be placed in an RA message that is sent in
indicating the capability to act as a 6LR, since the RA propagates response to an RS with a 6CIO indicating the capability to act as a
information between routers. 6LR, since the RA propagates information between routers.
6.2. RFC6775-only 6LN 6.2. RFC6775-only 6LN
An RFC6775-only 6LN will use the Registered Address as the source An RFC6775-only 6LN will use the Registered Address as the source
address of the NS message and will not use an EARO. An updated 6LR address of the NS message and will not use an EARO. An updated 6LR
MUST accept that registration if it is valid per [RFC6775], and it MUST accept that registration if it is valid per [RFC6775], and it
MUST manage the binding cache accordingly. The updated 6LR MUST then MUST manage the binding cache accordingly. The updated 6LR MUST then
use the RFC6775-only DAR and DAC messages as specified in [RFC6775] use the RFC6775-only DAR and DAC messages as specified in [RFC6775]
to indicate to the 6LBR that the TID is not present in the messages. to indicate to the 6LBR that the TID is not present in the messages.
The main difference from [RFC6775] is that the exchange of EDA The main difference from [RFC6775] is that the exchange of DAR and
messages for the purpose of DAD is avoided for Link-Local Addresses. DAC messages for the purpose of DAD is avoided for Link-Local
In any case, the 6LR MUST use an EARO in the reply, and can use any Addresses. In any case, the 6LR MUST use an EARO in the reply, and
of the Status codes defined in this specification. can use any of the Status codes defined in this specification.
6.3. RFC6775-only 6LR 6.3. RFC6775-only 6LR
An updated 6LN discovers the capabilities of the 6LR in the 6CIO in An updated 6LN discovers the capabilities of the 6LR in the 6CIO in
RA messages from that 6LR; if the 6CIO was not present in the RA, RA messages from that 6LR; if the 6CIO was not present in the RA,
then the 6LR is assumed to be a RFC6775-only 6LR. then the 6LR is assumed to be a RFC6775-only 6LR.
An updated 6LN MUST use an EARO in the request regardless of the type An updated 6LN MUST use an EARO in the request regardless of the type
of 6LR, RFC6775-only or updated, which implies that the 'T' flag is of 6LR, RFC6775-only or updated, which implies that the 'T' flag is
set. It MUST use a ROVR of 64 bits if the 6LR is an RFC6775-only set. It MUST use a ROVR of 64 bits if the 6LR is an RFC6775-only
6LR. 6LR.
If an updated 6LN moves from an updated 6LR to an RFC6775-only 6LR, If an updated 6LN moves from an updated 6LR to an RFC6775-only 6LR,
the RFC6775-only 6LR will send an RFC6775-only DAR message, which the RFC6775-only 6LR will send an RFC6775-only DAR message, which
cannot be compared with an updated one for freshness. Allowing cannot be compared with an updated one for recency. Allowing
RFC6775-only DAR messages to update a state established by the RFC6775-only DAR messages to update a state established by the
updated protocol in the 6LBR would be an attack vector and that updated protocol in the 6LBR would be an attack vector and that
cannot be the default behavior. But if RFC6775-only and updated 6LRs cannot be the default behavior. But if RFC6775-only and updated 6LRs
coexist temporarily in a network, then it makes sense for an coexist temporarily in a network, then it makes sense for an
administrator to install a policy that allows this, using some method administrator to install a policy that allows this, using some method
out of scope for this document. out of scope for this document.
6.4. RFC6775-only 6LBR 6.4. RFC6775-only 6LBR
With this specification, the Duplicate Address messages are extended With this specification, the Duplicate Address messages are extended
to transport the EARO information. Similarly to the NS/NA exchange, to transport the EARO information. As with the NS/NA exchange, an
an updated 6LBR MUST always use the EDA messages. updated 6LBR MUST always use the EDAR and EDAC messages.
Note that an RFC6775-only 6LBR will accept and process an EDAR Note that an RFC6775-only 6LBR will accept and process an EDAR
message as if it were an RFC6775-only DAR, as long as the ROVR is 64 message as if it were an RFC6775-only DAR, as long as the ROVR is 64
bits long. An updated 6LR discovers the capabilities of the 6LBR in bits long. An updated 6LR discovers the capabilities of the 6LBR in
the 6CIO in RA messages from the 6LR; if the 6CIO was not present in the 6CIO in RA messages from the 6LR; if the 6CIO was not present in
any RA, then the 6LBR is assumed to be a RFC6775-only 6LBR. any RA, then the 6LBR is assumed to be a RFC6775-only 6LBR.
If the 6LBR is RFC6775-only, the 6LR MUST use only the 64 leftmost If the 6LBR is RFC6775-only, the 6LR MUST use only the 64 leftmost
bits of the ROVR, and place the result in the EDAR message to bits of the ROVR, and place the result in the EDAR message to
maintain compatibility. This way, the support of DAD is preserved. maintain compatibility. This way, the support of DAD is preserved.
7. Security Considerations 7. Security Considerations
This specification extends [RFC6775], and the security section of This specification extends [RFC6775], and the security section of
that document also applies to this document. In particular, the link that document also applies to this document. In particular, the link
layer SHOULD be sufficiently protected to prevent rogue access. layer SHOULD be sufficiently protected to prevent rogue access.
[RFC6775] does not protect the content of its messages and expects a [RFC6775] does not protect the content of its messages and expects a
lower layer encryption to defeat potential attacks. This lower layer encryption to defeat potential attacks. This
specification requires the LLN MAC to provide secure unicast to/from specification requires the LLN MAC to provide secure unicast to/from
the Backbone Router and secure Broadcast or Multicast from the a Routing Registrar and secure Broadcast or Multicast from the
Backbone Router in a way that prevents tampering with or replaying Routing Registrar in a way that prevents tampering with or replaying
the Neighbor Discovery messages. the Neighbor Discovery messages.
This specification recommends using privacy techniques (see This specification recommends using privacy techniques (see
Section 8), and protecting against address theft by methods outside Section 8), and protecting against address theft by methods outside
the scope of this document. For instance, "Address Protected the scope of this document. As an example, "Address Protected
Neighbor Discovery for Low-power and Lossy Networks" Neighbor Discovery for Low-power and Lossy Networks"
[I-D.ietf-6lo-ap-nd] guarantees the ownership of the Registered [I-D.ietf-6lo-ap-nd] guarantees the ownership of the Registered
Address using a cryptographic ROVR. Address using a cryptographic ROVR.
The registration mechanism may be used by a rogue node to attack the The registration mechanism may be used by a rogue node to attack the
6LR or the 6LBR with a Denial-of-Service attack against the registry. 6LR or the 6LBR with a Denial-of-Service attack against the registry.
It may also happen that the registry of a 6LR or a 6LBR is saturated It may also happen that the registry of a 6LR or a 6LBR is saturated
and cannot take any more registrations, which effectively denies the and cannot take any more registrations, which effectively denies the
requesting node the capability to use a new address. In order to requesting node the capability to use a new address. In order to
alleviate those concerns, Section 5.7 provides a number of alleviate those concerns, Section 5.7 provides a number of
skipping to change at page 25, line 51 skipping to change at page 26, line 29
stability can be determined, e.g., because they are used over a stability can be determined, e.g., because they are used over a
much longer time span than other (privacy, shorter-lived) much longer time span than other (privacy, shorter-lived)
addresses. addresses.
o In order to avoid denial of registration for the lack of o In order to avoid denial of registration for the lack of
resources, administrators should take great care to deploy resources, administrators should take great care to deploy
adequate numbers of 6LRs to cover the needs of the nodes in their adequate numbers of 6LRs to cover the needs of the nodes in their
range, so as to avoid a situation of starving nodes. It is range, so as to avoid a situation of starving nodes. It is
expected that the 6LBR that serves an LLN is a more capable node expected that the 6LBR that serves an LLN is a more capable node
than the average 6LR, but in a network condition where it may than the average 6LR, but in a network condition where it may
become saturated, a particular deployment should distribute the become saturated, a particular LLN should distribute the 6LBR
6LBR functionality, for instance by leveraging a high speed functionality, for instance by leveraging a high speed Backbone
Backbone Link and Backbone Routers to aggregate multiple LLNs into Link and Routing Registrars to aggregate multiple LLNs into a
a larger subnet. larger subnet.
The LLN nodes depend on the 6LBR and the 6BBR for their operation. A The LLN nodes depend on a 6LBR and may use the services of a routing
trust model MUST be put in place to ensure that only authorized Registrar for their operation. A trust model MUST be put in place to
devices are acting in these roles so as to avoid threats such as ensure that only authorized devices are acting in these roles so as
black-holing or bombing attack whereby an impersonated 6LBR would to avoid threats such as black-holing or bombing attack whereby an
destroy state in the network by using the "Removed" Status code. impersonated 6LBR would destroy state in the network by using the
This trust model could be at a minimum based on a Layer-2 access "Removed" Status code. This trust model could be at a minimum based
control, or could provide role validation as well (see Req5.1 in on a Layer-2 access control, or could provide role validation as well
Appendix B.5). (see Req5.1 in Appendix B.5).
8. Privacy Considerations 8. Privacy Considerations
As indicated in Section 3, this protocol does not limit the number of As indicated in Section 3, this protocol does not limit the number of
IPv6 addresses that each device can form. However, to mitigate IPv6 addresses that each device can form. However, to mitigate
denial-of-service attacks, it can be useful as a protective measure denial-of-service attacks, it can be useful as a protective measure
to have a limit that is high enough not to interfere with the normal to have a limit that is high enough not to interfere with the normal
behavior of devices in the network. A host should be able to form behavior of devices in the network. A host should be able to form
and register any address that is topologically correct in the and register any address that is topologically correct in the
subnet(s) advertised by the 6LR/6LBR. subnet(s) advertised by the 6LR/6LBR.
skipping to change at page 27, line 19 skipping to change at page 27, line 43
once it is allocated. once it is allocated.
IANA is requested to make a number of changes under the "Internet IANA is requested to make a number of changes under the "Internet
Control Message Protocol version 6 (ICMPv6) Parameters" registry, as Control Message Protocol version 6 (ICMPv6) Parameters" registry, as
follows. follows.
9.1. ARO Flags 9.1. ARO Flags
IANA is requested to create a new subregistry for "ARO Flags" under IANA is requested to create a new subregistry for "ARO Flags" under
the "Internet Control Message Protocol version 6 (ICMPv6) [RFC4443] the "Internet Control Message Protocol version 6 (ICMPv6) [RFC4443]
Parameters". This specification defines 8 positions, bit 0 to bit 7, Parameters".
and assigns bit 6 for the 'R' flag and bit 7 for the 'T' flag (see
Section 4.1). The policy is "IETF Review" or "IESG Approval"
[RFC8126]. The initial content of the registry is as shown in
Table 2.
New subregistry for ARO Flags This specification defines 8 positions, bit 0 to bit 7, and assigns
bit 6 for the 'R' flag and bit 7 for the 'T' flag (see Section 4.1).
The policy is "IETF Review" or "IESG Approval" [RFC8126].
The initial content of the registry is as shown in Table 2.
+-------------+--------------+-----------+ +-------------+--------------+-----------+
| ARO Status | Description | Document | | ARO Status | Description | Document |
+-------------+--------------+-----------+ +-------------+--------------+-----------+
| 0..5 | Unassigned | | | 0..5 | Unassigned | |
| | | | | | | |
| 6 | 'R' Flag | This RFC | | 6 | 'R' Flag | This RFC |
| | | | | | | |
| 7 | 'T' Flag | This RFC | | 7 | 'T' Flag | This RFC |
+-------------+--------------+-----------+ +-------------+--------------+-----------+
Table 2: New ARO Flags Table 2: New ARO Flags
9.2. ICMP Codes 9.2. EARO I-Field
IANA is requested to create a new subregistry for "ARO Flags" under
the "Internet Control Message Protocol version 6 (ICMPv6) [RFC4443]
Parameters".
This specification defines 4 integer values from 0 to 3, and assigns
value 0 (see Section 4.1). The policy is "IETF Review" or "IESG
Approval" [RFC8126].
The initial content of the registry is as shown in Table 3.
+--------+---------------------------------------+------------+
| Value | Meaning | Reference |
+--------+---------------------------------------+------------+
| 0 | Abstract Index for Topology Selection | This RFC |
| | | |
| 1..3 | Unassigned | |
+--------+---------------------------------------+------------+
Table 3: New subregistry for the EARO "I" Field
9.3. ICMP Codes
IANA is requested to create 2 new subregistries of the ICMPv6 "Code" IANA is requested to create 2 new subregistries of the ICMPv6 "Code"
Fields registry, which itself is a subregistry of the Internet Fields registry, which itself is a subregistry of the Internet
Control Message Protocol version 6 (ICMPv6) Parameters for the ICMP Control Message Protocol version 6 (ICMPv6) Parameters for the ICMP
codes. The new subregistries relate to the ICMP type 157, Duplicate codes.
Address Request (shown in Table 3), and 158, Duplicate Address
Confirmation (shown in Table 4), respectively. For those ICMP types,
the ICMP Code field is split in 2 subfields, the "Code Prefix" and
the "Code Suffix". The new subregistries relate to the "Code Suffix"
portion of the ICMP Code. The range of "Code Suffix" is 0..15 in all
cases. The policy is "IETF Review" or "IESG Approval" [RFC8126] for
both subregistries. The new subregistries are to be initialized as
follows:
New Code Suffixes for ICMP types 157 DAR message The new subregistries relate to the ICMP type 157, Duplicate Address
Request (shown in Table 4), and 158, Duplicate Address Confirmation
(shown in Table 5), respectively. For those two ICMP types, the ICMP
Code field is split into 2 subfields, the "Code Prefix" and the "Code
Suffix". The new subregistries relate to the "Code Suffix" portion
of the ICMP Code. The range of "Code Suffix" is 0..15 in all cases.
+--------------+---------------------------------------+------------+ The policy is "IETF Review" or "IESG Approval" [RFC8126] for both
| Code Suffix | Meaning | Reference | subregistries.
+--------------+---------------------------------------+------------+
| 0 | RFC6775 DAR message | RFC 6775 |
| | | |
| 1 | EDAR message with 64bits-long ROVR | This RFC |
| | field | |
| | | |
| 2 | EDAR message with 128bits-long ROVR | This RFC |
| | field | |
| | | |
| 3 | EDAR message with 192bits-long ROVR | This RFC |
| | field | |
| | | |
| 4 | EDAR message with 256bits-long ROVR | This RFC |
| | field | |
| | | |
| 5...15 | Unassigned | |
+--------------+---------------------------------------+------------+
Table 3: New Code Suffixes for the DAR message The new subregistries are to be initialized as follows:
New Code Suffixes for ICMP types 158 DAC message +--------------+--------------------------------------+------------+
| Code Suffix | Meaning | Reference |
+--------------+--------------------------------------+------------+
| 0 | RFC6775 DAR message | RFC 6775 |
| | | |
| 1 | EDAR message with 64-bit ROVR field | This RFC |
| | | |
| 2 | EDAR message with 128-bit ROVR field | This RFC |
| | | |
| 3 | EDAR message with 192-bit ROVR field | This RFC |
| | | |
| 4 | EDAR message with 256-bit ROVR field | This RFC |
| | | |
| 5...15 | Unassigned | |
+--------------+--------------------------------------+------------+
+-------------+----------------------------------------+------------+ Table 4: New Code Suffixes for ICMP type 157 DAR message
| Code Suffix | Meaning | Reference |
+-------------+----------------------------------------+------------+
| 0 | RFC6775 DAC message | RFC 6775 |
| | | |
| 1 | EDAC message with 64bits-long ROVR | This RFC |
| | field | |
| | | |
| 2 | EDAC message with 128bits-long ROVR | This RFC |
| | field | |
| | | |
| 3 | EDAC message with 192bits-long ROVR | This RFC |
| | field | |
| | | |
| 4 | EDAC message with 256bits-long ROVR | This RFC |
| | field | |
| | | |
| 5...15 | Unassigned | |
+-------------+----------------------------------------+------------+
Table 4: New Code Suffixes for the DAC message +--------------+--------------------------------------+------------+
| Code Suffix | Meaning | Reference |
+--------------+--------------------------------------+------------+
| 0 | RFC6775 DAC message | RFC 6775 |
| | | |
| 1 | EDAC message with 64-bit ROVR field | This RFC |
| | | |
| 2 | EDAC message with 128-bit ROVR field | This RFC |
| | | |
| 3 | EDAC message with 192-bit ROVR field | This RFC |
| | | |
| 4 | EDAC message with 256-bit ROVR field | This RFC |
| | | |
| 5...15 | Unassigned | |
+--------------+--------------------------------------+------------+
9.3. New ARO Status values Table 5: New Code Suffixes for ICMP type 158 DAC message
9.4. New ARO Status values
IANA is requested to make additions to the Address Registration IANA is requested to make additions to the Address Registration
Option Status Values Registry as follows: Option Status Values Registry as follows:
Address Registration Option Status Values Registry
+-------------+-----------------------------------------+-----------+ +-------------+-----------------------------------------+-----------+
| ARO Status | Description | Document | | ARO Status | Description | Document |
+-------------+-----------------------------------------+-----------+ +-------------+-----------------------------------------+-----------+
| 3 | Moved | This RFC | | 3 | Moved | This RFC |
| | | | | | | |
| 4 | Removed | This RFC | | 4 | Removed | This RFC |
| | | | | | | |
| 5 | Validation Requested | This RFC | | 5 | Validation Requested | This RFC |
| | | | | | | |
| 6 | Duplicate Source Address | This RFC | | 6 | Duplicate Source Address | This RFC |
skipping to change at page 29, line 33 skipping to change at page 30, line 26
| 7 | Invalid Source Address | This RFC | | 7 | Invalid Source Address | This RFC |
| | | | | | | |
| 8 | Registered Address topologically | This RFC | | 8 | Registered Address topologically | This RFC |
| | incorrect | | | | incorrect | |
| | | | | | | |
| 9 | 6LBR Registry saturated | This RFC | | 9 | 6LBR Registry saturated | This RFC |
| | | | | | | |
| 10 | Validation Failed | This RFC | | 10 | Validation Failed | This RFC |
+-------------+-----------------------------------------+-----------+ +-------------+-----------------------------------------+-----------+
Table 5: New ARO Status values Table 6: New ARO Status values
9.4. New 6LoWPAN Capability Bits 9.5. New 6LoWPAN Capability Bits
IANA is requested to make additions to the Subregistry for "6LoWPAN IANA is requested to make additions to the Subregistry for "6LoWPAN
Capability Bits" as follows: Capability Bits" as follows:
Subregistry for "6LoWPAN Capability Bits" under the "Internet Control +-----------------+---------------------------+-----------+
Message Protocol version 6 (ICMPv6) Parameters" | Capability Bit | Description | Document |
+-----------------+---------------------------+-----------+
+-----------------+----------------------+-----------+ | 10 | EDA Support (D bit) | This RFC |
| Capability Bit | Description | Document | | | | |
+-----------------+----------------------+-----------+ | 11 | 6LR capable (L bit) | This RFC |
| 10 | EDA Support (D bit) | This RFC | | | | |
| | | | | 12 | 6LBR capable (B bit) | This RFC |
| 11 | 6LR capable (L bit) | This RFC | | | | |
| | | | | 13 | Routing Registrar (P bit) | This RFC |
| 12 | 6LBR capable (B bit) | This RFC | | | | |
| | | | | 14 | EARO support (E bit) | This RFC |
| 13 | 6BBR capable (P bit) | This RFC | +-----------------+---------------------------+-----------+
| | | |
| 14 | EARO support (E bit) | This RFC |
+-----------------+----------------------+-----------+
Table 6: New 6LoWPAN Capability Bits Table 7: New 6LoWPAN Capability Bits
10. Acknowledgments 10. Acknowledgments
Kudos to Eric Levy-Abegnoli who designed the First Hop Security Kudos to Eric Levy-Abegnoli who designed the First Hop Security
infrastructure upon which the first backbone router was implemented. infrastructure upon which the first backbone router was implemented.
Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen
Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee, Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee,
Warren Kumari, Benjamin Kaduk, Mirja Kuhlewind, Ben Campbell, Eric Warren Kumari, Benjamin Kaduk, Mirja Kuhlewind, Ben Campbell, Eric
Rescorla, and Lorenzo Colitti for their various contributions and Rescorla, and Lorenzo Colitti for their various contributions and
reviews. Also, many thanks to Thomas Watteyne for the world first reviews. Also, many thanks to Thomas Watteyne for the world first
skipping to change at page 35, line 41 skipping to change at page 36, line 16
Perlman, R., "Fault-Tolerant Broadcast of Routing Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", North-Holland Computer Networks 7: 395-405, Information", North-Holland Computer Networks 7: 395-405,
1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/ 1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/
readings/p83.pdf>. readings/p83.pdf>.
Appendix A. Applicability and Requirements Served (Not Normative) Appendix A. Applicability and Requirements Served (Not Normative)
This specification extends 6LoWPAN ND to provide a sequence number to This specification extends 6LoWPAN ND to provide a sequence number to
the registration and serves the requirements expressed in the registration and serves the requirements expressed in
Appendix B.1 by enabling the mobility of devices from one LLN to the Appendix B.1 by enabling the mobility of devices from one LLN to the
next based on the complementary work in the "IPv6 Backbone Router" next. A full specification for enabling mobility based on the use of
[I-D.ietf-6lo-backbone-router] specification. the EARO and the registration procedures defined in this document can
be found in a companion document "IPv6 Backbone Router"
[I-D.ietf-6lo-backbone-router]. The 6BBR is an example of a Routing
Registrar that acts as an IPv6 ND proxy over a Backbone Link that
federates multiple LLNs as well as the Backbone Link intself into a
single IPv6 subnet. The expected registration flow in that case is
illustrated in Figure 6, noting that any combination of 6LR, 6LBR and
6BBR may be collocated.
6LN 6LR 6LBR 6BBR
| | | |
| NS(EARO) | | |
|--------------->| | |
| | Extended DAR | |
| |-------------->| |
| | | |
| | | proxy NS(EARO) |
| | |--------------->|
| | | | NS(DAD)
| | | | ------>
| | | | <wait>
| | | |
| | | proxy NA(EARO) |
| | |<---------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |
Figure 6: (Re-)Registration Flow
"6TiSCH architecture" [I-D.ietf-6tisch-architecture] describes how a "6TiSCH architecture" [I-D.ietf-6tisch-architecture] describes how a
6LoWPAN ND host using the Timeslotted Channel Hopping (TSCH) mode of 6LoWPAN ND host using the Timeslotted Channel Hopping (TSCH) mode of
IEEE Std. 802.15.4 [IEEEstd802154] can connect to the Internet via a IEEE Std. 802.15.4 [IEEEstd802154] can connect to the Internet via a
RPL mesh network. Doing so requires additions to the 6LoWPAN ND RPL mesh network. Doing so requires additions to the 6LoWPAN ND
protocol to support mobility and reachability in a secure and protocol to support mobility and reachability in a secure and
manageable network environment. This document specifies those new manageable network environment. This document specifies those new
operations, and fulfills the requirements listed in Appendix B.2. operations, and fulfills the requirements listed in Appendix B.2.
The term LLN is used loosely in this document, and intended to cover The term LLN is used loosely in this document, and intended to cover
multiple types of WLANs and WPANs, including Low-Power IEEE Std. multiple types of WLANs and WPANs, including Low-Power IEEE Std.
802.11 networking, Bluetooth Low Energy, IEEE Std. 802.11ah, and IEEE 802.11 networking, Bluetooth Low Energy, IEEE Std. 802.11ah, and IEEE
Std. 802.15.4 wireless meshes, so as to address the requirements Std. 802.15.4 wireless meshes, so as to address the requirements
discussed in Appendix B.3. discussed in Appendix B.3.
This specification can be used by any wireless node to associate at This specification can be used by any wireless node to register its
Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing IPv6 addresses with a Routing Registrar and to obtain routing
services including proxy-ND operations over a Backbone Link, services including proxy-ND operations over a Backbone Link. This
effectively providing a solution to the requirements expressed in satisfies the the requirements expressed in Appendix B.4.
Appendix B.4.
This specification is extended by "Address Protected Neighbor This specification is extended by "Address Protected Neighbor
Discovery for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd] to Discovery for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd] to
providing a solution to some of the security-related requirements provide a solution to some of the security-related requirements
expressed in Appendix B.5. expressed in Appendix B.5.
"Efficiency aware IPv6 Neighbor Discovery Optimizations" "Efficiency aware IPv6 Neighbor Discovery Optimizations"
[I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND
[RFC6775] can be extended to other types of links beyond IEEE Std. [RFC6775] can be extended to other types of links beyond IEEE Std.
802.15.4 for which it was defined. The registration technique is 802.15.4 for which it was defined. The registration technique is
beneficial when the Link-Layer technique used to carry IPv6 multicast beneficial when the Link-Layer technique used to carry IPv6 multicast
packets is not sufficiently efficient in terms of delivery ratio or packets is not sufficiently efficient in terms of delivery ratio or
energy consumption in the end devices, in particular to enable energy consumption in the end devices, in particular to enable
energy-constrained sleeping nodes. The value of such extension is energy-constrained sleeping nodes. The value of such extension is
skipping to change at page 38, line 24 skipping to change at page 39, line 24
using the selected routing protocol. using the selected routing protocol.
Req2.2: Considering RPL, the Address Registration Option that is used Req2.2: Considering RPL, the Address Registration Option that is used
in the ND registration SHOULD be extended to carry enough information in the ND registration SHOULD be extended to carry enough information
to generate a DAO message as specified in section 6.4 of [RFC6550], to generate a DAO message as specified in section 6.4 of [RFC6550],
in particular the capability to compute a Path Sequence and, as an in particular the capability to compute a Path Sequence and, as an
option, a RPLInstanceID. option, a RPLInstanceID.
Req2.3: Multicast operations SHOULD be supported and optimized, for Req2.3: Multicast operations SHOULD be supported and optimized, for
instance, using BIER or MPL. Whether ND is appropriate for the instance, using BIER or MPL. Whether ND is appropriate for the
registration to the 6BBR is to be defined, considering the additional registration to the Routing Registrar is to be defined, considering
burden of supporting the Multicast Listener Discovery Version 2 the additional burden of supporting the Multicast Listener Discovery
[RFC3810] (MLDv2) for IPv6. Version 2 [RFC3810] (MLDv2) for IPv6.
B.3. Requirements Related to the Variety of Low-Power Link types B.3. Requirements Related to the Variety of Low-Power Link types
6LoWPAN ND [RFC6775] was defined with a focus on IEEE Std.802.15.4 6LoWPAN ND [RFC6775] was defined with a focus on IEEE Std.802.15.4
and in particular the capability to derive a unique identifier from a and in particular the capability to derive a unique identifier from a
globally unique EUI-64 address. At this point, the 6lo Working Group globally unique EUI-64 address. At this point, the 6lo Working Group
is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique
to other link types including ITU-T G.9959 [RFC7428], Master-Slave/ to other link types including ITU-T G.9959 [RFC7428], Master-Slave/
Token-Passing [RFC8163], DECT Ultra Low Energy [RFC8105], Near Field Token-Passing [RFC8163], DECT Ultra Low Energy [RFC8105], Near Field
Communication [I-D.ietf-6lo-nfc], IEEE Std. 802.11ah Communication [I-D.ietf-6lo-nfc], IEEE Std. 802.11ah
skipping to change at page 39, line 14 skipping to change at page 40, line 14
Req3.3: The Address Registration Option used in the ND registration Req3.3: The Address Registration Option used in the ND registration
SHOULD be extended to carry the relevant forms of unique Identifier. SHOULD be extended to carry the relevant forms of unique Identifier.
Req3.4: The Neighbor Discovery should specify the formation of a Req3.4: The Neighbor Discovery should specify the formation of a
site-local address that follows the security recommendations from site-local address that follows the security recommendations from
[RFC7217]. [RFC7217].
B.4. Requirements Related to Proxy Operations B.4. Requirements Related to Proxy Operations
Duty-cycled devices may not be able to answer themselves to a lookup Duty-cycled devices may not be awake to answer a lookup from a node
from a node that uses IPv6 ND on a Backbone Link and may need a that uses IPv6 ND and may need a proxy. Additionally, the duty-
proxy. Additionally, the duty-cycled device may need to rely on the cycled device may rely on the 6LBR to perform registration to the
6LBR to perform registration to the 6BBR. Routing Registrar.
The ND registration method SHOULD defend the addresses of duty-cycled The ND registration method SHOULD defend the addresses of duty-cycled
devices that are sleeping most of the time and not capable to defend devices that are sleeping most of the time and not capable to defend
their own addresses. their own addresses.
Related requirements are: Related requirements are:
Req4.1: The registration mechanism SHOULD enable a third party to Req4.1: The registration mechanism SHOULD enable a third party to
proxy register an address on behalf of a 6LoWPAN node that may be proxy register an address on behalf of a 6LoWPAN node that may be
sleeping or located deeper in an LLN mesh. sleeping or located deeper in an LLN mesh.
Req4.2: The registration mechanism SHOULD be applicable to a duty- Req4.2: The registration mechanism SHOULD be applicable to a duty-
cycled device regardless of the link type and SHOULD enable a 6BBR to cycled device regardless of the link type and SHOULD enable a Routing
operate as a proxy to defend the Registered Addresses on its behalf. Registrar to operate as a proxy to defend the Registered Addresses on
its behalf.
Req4.3: The registration mechanism SHOULD enable long sleep Req4.3: The registration mechanism SHOULD enable long sleep
durations, on the order of multiple days to a month. durations, on the order of multiple days to a month.
B.5. Requirements Related to Security B.5. Requirements Related to Security
In order to guarantee the operations of the 6LoWPAN ND flows, the In order to guarantee the operations of the 6LoWPAN ND flows,
spoofing of the 6LR, 6LBR, and 6BBRs roles should be avoided. Once a spoofing the roles of the 6LR, 6LBR, and Routing Registrar should be
node successfully registers an address, 6LoWPAN ND should provide avoided. Once a node successfully registers an address, 6LoWPAN ND
energy-efficient means for the 6LBR to protect that ownership even should provide energy-efficient means for the 6LBR to protect that
when the node that registered the address is sleeping. ownership even when the node that registered the address is sleeping.
In particular, the 6LR and the 6LBR then should be able to verify In particular, the 6LR and the 6LBR then should be able to verify
whether a subsequent registration for a given address comes from the whether a subsequent registration for a given address comes from the
original node. original node.
In an LLN it makes sense to base security on Layer-2 security. In an LLN it makes sense to base security on Layer-2 security.
During bootstrap of the LLN, nodes join the network after During bootstrap of the LLN, nodes join the network after
authorization by a Joining Assistant (JA) or a Commissioning Tool authorization by a Joining Assistant (JA) or a Commissioning Tool
(CT). After joining, nodes communicate with each other via secured (CT). After joining, nodes communicate with each other via secured
links. The keys for the Layer-2 security are distributed by the JA/ links. The keys for the Layer-2 security are distributed by the JA/
CT. The JA/CT can be part of the LLN or be outside the LLN. In both CT. The JA/CT can be part of the LLN or be outside the LLN. In both
cases it is needed that packets are routed between JA/CT and the cases it is needed that packets are routed between JA/CT and the
joining node. joining node.
Related requirements are: Related requirements are:
Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
the 6LR, 6LBR, and 6BBR to authenticate and authorize one another for the 6LR, 6LBR, and Routing Registrar to authenticate and authorize
their respective roles, as well as with the 6LoWPAN Node for the role one another for their respective roles, as well as with the 6LoWPAN
of 6LR. Node for the role of 6LR.
Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
the 6LR and the 6LBR to validate new registration of authorized the 6LR and the 6LBR to validate new registration of authorized
nodes. Joining of unauthorized nodes MUST be prevented. nodes. Joining of unauthorized nodes MUST be prevented.
Req5.3: 6LoWPAN ND security mechanisms SHOULD NOT lead to large Req5.3: 6LoWPAN ND security mechanisms SHOULD NOT lead to large
packet sizes. In particular, the NS, NA, DAR, and DAC messages for a packet sizes. In particular, the NS, NA, DAR, and DAC messages for a
re-registration flow SHOULD NOT exceed 80 octets so as to fit in a re-registration flow SHOULD NOT exceed 80 octets so as to fit in a
secured IEEE Std.802.15.4 [IEEEstd802154] frame. secured IEEE Std.802.15.4 [IEEEstd802154] frame.
skipping to change at page 41, line 37 skipping to change at page 42, line 37
options and parameters should be configured or negotiated dynamically options and parameters should be configured or negotiated dynamically
rather than manually". This is especially true in LLNs where the rather than manually". This is especially true in LLNs where the
number of devices may be large and manual configuration is number of devices may be large and manual configuration is
infeasible. Capabilities for a dynamic configuration of LLN devices infeasible. Capabilities for a dynamic configuration of LLN devices
can also be constrained by the network and power limitation. can also be constrained by the network and power limitation.
A Network Administrator should be able to validate that the network A Network Administrator should be able to validate that the network
is operating within capacity, and that in particular a 6LBR does not is operating within capacity, and that in particular a 6LBR does not
get overloaded with an excessive amount of registration, so the get overloaded with an excessive amount of registration, so the
administrator can take actions such as adding a Backbone Link with administrator can take actions such as adding a Backbone Link with
additional 6LBRs and 6BBRs to the network. additional 6LBRs and Routing Registrars to the network.
Related requirements are: Related requirements are:
Req7.1: A management model SHOULD be provided that enables access to Req7.1: A management model SHOULD be provided that enables access to
the 6LBR, monitor its usage vs. capacity, and alert in case of the 6LBR, monitor its usage vs. capacity, and alert in case of
congestion. It is recommended that the 6LBR be reachable over a non- congestion. It is recommended that the 6LBR be reachable over a non-
LLN link. LLN link.
Req7.2: A management model SHOULD be provided that enables access to Req7.2: A management model SHOULD be provided that enables access to
the 6LR and its capacity to host additional NCE. This management the 6LR and its capacity to host additional NCE. This management
skipping to change at page 43, line 31 skipping to change at page 44, line 31
| | | | | |
| Req7.1 | | | Req7.1 | |
| | | | | |
| Req7.2 | | | Req7.2 | |
| | | | | |
| Req7.3 | | | Req7.3 | |
| | | | | |
| Req7.4 | | | Req7.4 | |
+-------------+-----------------------------------------+ +-------------+-----------------------------------------+
Table 7: Work Addressing requirements Table 8: Work Addressing requirements
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D (Regus) 45 Allee des Ormes Building D (Regus) 45 Allee des Ormes
Mougins - Sophia Antipolis Mougins - Sophia Antipolis
France France
Phone: +33 4 97 23 26 34 Phone: +33 4 97 23 26 34
 End of changes. 97 change blocks. 
354 lines changed or deleted 422 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/