draft-ietf-6lo-backbone-router-05.txt   draft-ietf-6lo-backbone-router-06.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Intended status: Standards Track January 9, 2018 Intended status: Standards Track February 23, 2018
Expires: July 13, 2018 Expires: August 27, 2018
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-05 draft-ietf-6lo-backbone-router-06
Abstract Abstract
This specification proposes proxy operations for IPv6 Neighbor This specification proposes proxy operations for IPv6 Neighbor
Discovery on behalf of devices located on broadcast-inefficient Discovery on behalf of devices located on broadcast-inefficient
wireless networks. A broadcast-efficient backbone running classical wireless networks. A broadcast-efficient backbone running classical
IPv6 Neighbor Discovery federates multiple wireless links to form a IPv6 Neighbor Discovery federates multiple wireless links to form a
large MultiLink Subnet, but the broadcast domain does not need to large MultiLink Subnet, but the broadcast domain does not need to
extend to the wireless links for the purpose of ND operation. extend to the wireless links for the purpose of ND operation.
Backbone Routers placed at the wireless edge of the backbone proxy Backbone Routers placed at the wireless edge of the backbone proxy
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 July 13, 2018. This Internet-Draft will expire on August 27, 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 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability and Requirements Served . . . . . . . . . . . . 4 2. Applicability and Requirements Served . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Backbone Router Routing Operations . . . . . . . . . . . . . 9 5. Backbone Router Routing Operations . . . . . . . . . . . . . 9
5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 10 5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 10
5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 11 5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 11
6. BackBone Router Proxy Operations . . . . . . . . . . . . . . 13 6. BackBone Router Proxy Operations . . . . . . . . . . . . . . 13
6.1. Registration and Binding State Creation . . . . . . . . . 15 6.1. Registration and Binding State Creation . . . . . . . . . 15
6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 16 6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 18 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20
11.3. External Informative References . . . . . . . . . . . . 23 11.3. External Informative References . . . . . . . . . . . . 23
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 24
A.1. Requirements Related to Mobility . . . . . . . . . . . . 24 A.1. Requirements Related to Mobility . . . . . . . . . . . . 24
A.2. Requirements Related to Routing Protocols . . . . . . . . 25 A.2. Requirements Related to Routing Protocols . . . . . . . . 25
A.3. Requirements Related to the Variety of Low-Power Link A.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 26 types . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.4. Requirements Related to Proxy Operations . . . . . . . . 26 A.4. Requirements Related to Proxy Operations . . . . . . . . 26
skipping to change at page 8, line 35 skipping to change at page 8, line 35
Figure 1: Backbone Link and Backbone Routers Figure 1: Backbone Link and Backbone Routers
The Backbone Routers maintain an abstract Binding Table of their The Backbone Routers maintain an abstract Binding Table of their
Registered Nodes. The Binding Table operates as a distributed Registered Nodes. The Binding Table operates as a distributed
database of all the wireless Nodes whether they reside on the LLNs or database of all the wireless Nodes whether they reside on the LLNs or
on the backbone, and use an extension to the Neighbor Discovery on the backbone, and use an extension to the Neighbor Discovery
Protocol to exchange that information across the Backbone in the Protocol to exchange that information across the Backbone in the
classical ND reactive fashion. classical ND reactive fashion.
The Extended Address Registration Option (ARO) defined in The Extended Address Registration Option (EARO) defined in
[I-D.ietf-6lo-rfc6775-update] is used to enable the registration for [I-D.ietf-6lo-rfc6775-update] is used to enable the registration for
routing and proxy Neighbor Discovery operations by the 6BBR, and the routing and proxy option is included in the ND exchanges over the
Extended ARO (EARO) option is included in the ND exchanges over the
backbone between the 6BBRs to sort out duplication from movement. backbone between the 6BBRs to sort out duplication from movement.
Address duplication is sorted out with the Owner Unique-ID field in Address duplication is sorted out with the Owner Unique-ID field in
the EARO, which is a generalization of the EUI-64 that allows the EARO, which is a generalization of the EUI-64 that allows
different types of unique IDs beyond the name space derived from the different types of unique IDs beyond the name space derived from the
MAC addresses. First-Come First-Serve rules apply, whether the MAC addresses. First-Come First-Serve rules apply, whether the
duplication happens between LLN nodes as represented by their duplication happens between LLN nodes as represented by their
respective 6BBRs, or between an LLN node and a classical node that respective 6BBRs, or between an LLN node and a classical node that
defends its address over the backbone with classical ND and does not defends its address over the backbone with classical ND and does not
include the EARO option. include the EARO option.
skipping to change at page 9, line 5 skipping to change at page 9, line 4
different types of unique IDs beyond the name space derived from the different types of unique IDs beyond the name space derived from the
MAC addresses. First-Come First-Serve rules apply, whether the MAC addresses. First-Come First-Serve rules apply, whether the
duplication happens between LLN nodes as represented by their duplication happens between LLN nodes as represented by their
respective 6BBRs, or between an LLN node and a classical node that respective 6BBRs, or between an LLN node and a classical node that
defends its address over the backbone with classical ND and does not defends its address over the backbone with classical ND and does not
include the EARO option. include the EARO option.
In case of conflicting registrations to multiple 6BBRs from a same In case of conflicting registrations to multiple 6BBRs from a same
node, a sequence counter called Transaction ID (TID) in the EARO node, a sequence counter called Transaction ID (TID) in the EARO
enables 6BBRs to sort out the latest anchor for that node. enables 6BBRs to sort out the latest anchor for that node.
Registrations with a same TID are compatible and maintained, but, in Registrations with a same TID are compatible and maintained, but, in
case of different TIDs, only the freshest registration is maintained case of different TIDs, only the freshest registration is maintained
and the stale state is eliminated. and the stale state is eliminated. The EARO also transports a 'R'
flag to be used by a 6LN when registering, to indicate that this 6LN
is not a router and that it will not handle its own reachability.
With this specification, Backbone Routers perform ND proxy over the With this specification, Backbone Routers perform a ND proxy
Backbone Link on behalf of their Registered Nodes. The Backbone operation over the Backbone Link on behalf of their Registered Nodes.
Router operation is essentially similar to that of a Mobile IPv6 The registration to the proxy service is done with a NS/NA(EARO)
(MIPv6) [RFC6275] Home Agent. This enables mobility support for LLN exchange. The EARO option with a 'R' flag is used in this
nodes that would move outside of the network delimited by the specification to indicate to the 6BBR that it is expected to perform
Backbone link attach to a Home Agent from that point on. This also this proxy operation. The Backbone Router operation is essentially
enables collocation of Home Agent functionality within Backbone similar to that of a Mobile IPv6 (MIPv6) [RFC6275] Home Agent. This
Router functionality on the same backbone interface of a router. enables mobility support for LLN nodes that would move outside of the
Further specification may extend this be allowing the 6BBR to network delimited by the Backbone link attach to a Home Agent from
redistribute host routes in routing protocols that would operate over that point on. This also enables collocation of Home Agent
the backbone, or in MIPv6 or the Locator/ID Separation Protocol functionality within Backbone Router functionality on the same
(LISP) [RFC6830] to support mobility on behalf of the nodes, etc... backbone interface of a router. Further specification may extend
this be allowing the 6BBR to redistribute host routes in routing
protocols that would operate over the backbone, or in MIPv6 or the
Locator/ID Separation Protocol (LISP) [RFC6830] to support mobility
on behalf of the nodes, etc...
The Optimistic Duplicate Address Detection [RFC4429] (ODAD) The Optimistic Duplicate Address Detection [RFC4429] (ODAD)
specification details how an address can be used before a Duplicate specification details how an address can be used before a Duplicate
Address Detection (DAD) is complete, and insists that an address that Address Detection (DAD) is complete, and insists that an address that
is TENTATIVE should not be associated to a Source Link-Layer Address is TENTATIVE should not be associated to a Source Link-Layer Address
Option in a Neighbor Solicitation message. This specification Option in a Neighbor Solicitation message. This specification
leverages ODAD to create a temporary proxy state in the 6BBR till DAD leverages ODAD to create a temporary proxy state in the 6BBR till DAD
is completed over the backbone. This way, the specification enables is completed over the backbone. This way, the specification enables
to distribute proxy states across multiple 6BBR and co-exist with to distribute proxy states across multiple 6BBR and co-exist with
classical ND over the backbone. classical ND over the backbone.
skipping to change at page 11, line 6 skipping to change at page 11, line 6
much as possible on the backbone as well. Unless configured much as possible on the backbone as well. Unless configured
otherwise, the Backbone Router MUST echo the MTU that it learns in otherwise, the Backbone Router MUST echo the MTU that it learns in
RAs over the backbone in the RAs that it sends towards the LLN links. RAs over the backbone in the RAs that it sends towards the LLN links.
As a router, the Backbone Router behaves like any other IPv6 router As a router, the Backbone Router behaves like any other IPv6 router
on the backbone side. It has a connected route installed towards the on the backbone side. It has a connected route installed towards the
backbone for the prefixes that are present on that backbone and that backbone for the prefixes that are present on that backbone and that
it proxies for on the LLN interfaces. it proxies for on the LLN interfaces.
As a proxy, the 6BBR uses an EARO option in the NS-DAD and the As a proxy, the 6BBR uses an EARO option in the NS-DAD and the
multicast NA messages that it generates on behalf of a Registered multicast NA messages that it generates over the Backbone Link on
Node, and it places an EARO in its unicast NA messages if and only if behalf of a Registered Node, and it places an EARO in its unicast NA
the NS/NA that stimulates it had an EARO in it. messages, if and only if the NS/NA that stimulates it had an EARO in
it and the 'R' bit set.
When possible, the 6BBR SHOULD use unicast or solicited-node When possible, the 6BBR SHOULD use unicast or solicited-node
multicast address (SNMA) [RFC4291] to defend its Registered Addresses multicast address (SNMA) [RFC4291] to defend its Registered Addresses
over the backbone. In particular, the 6BBR MUST join the SNMA group over the backbone. In particular, the 6BBR MUST join the SNMA group
that corresponds to a Registered Address as soon as it creates an that corresponds to a Registered Address as soon as it creates an
entry for that address and as long as it maintains that entry, entry for that address and as long as it maintains that entry,
whatever the state of the entry. The expectation is that it is whatever the state of the entry. The expectation is that it is
possible to get a message delivered to all the nodes on the backbone possible to get a message delivered to all the nodes on the backbone
that listen to a particular address and support this specification - that listen to a particular address and support this specification -
which includes all the 6BBRs in the MultiLink Subnet - by sending a which includes all the 6BBRs in the MultiLink Subnet - by sending a
skipping to change at page 12, line 8 skipping to change at page 12, line 9
As a router, the Nodes and Backbone Router operation on the LLN As a router, the Nodes and Backbone Router operation on the LLN
follows [RFC6775]. Per that specification, LLN Hosts generally do follows [RFC6775]. Per that specification, LLN Hosts generally do
not depend on multicast RAs to discover routers. It is still not depend on multicast RAs to discover routers. It is still
generally required for LLN nodes to accept multicast RAs [RFC7772], generally required for LLN nodes to accept multicast RAs [RFC7772],
but those are rare on the LLN link. Nodes are expected to follow the but those are rare on the LLN link. Nodes are expected to follow the
Simple Procedures for Detecting Network Attachment in IPv6 [RFC6059] Simple Procedures for Detecting Network Attachment in IPv6 [RFC6059]
(DNA procedures) to assert movements, and to support the Packet-Loss (DNA procedures) to assert movements, and to support the Packet-Loss
Resiliency for Router Solicitations [RFC7559] to make the unicast RS Resiliency for Router Solicitations [RFC7559] to make the unicast RS
more reliable. more reliable.
The Backbone Router acquires its states about the addresses on the An LLN node signals that it requires IPv6 ND proxy services from a
LLN side through a registration process from either the nodes 6BBR by registering the corresponding IPv6 Address with an NS(EARO)
themselves, or from a node such as a RPL root / 6LBR (the Registering message with the 'R' flag set. The LLN node that performs the
Node) that performs the registration on behalf of the address owner registration (the Registering Node) may be the owner of the IPv6
(the Registered Node). Address (the Registered Node) or a 6LBR that performs the
registration on its behalf.
When operating as a Routing Proxy, the router installs hosts routes When operating as a Routing Proxy, the router installs hosts routes
(/128) to the Registered Addresses over the LLN links, via the (/128) to the Registered Addresses over the LLN links, via the
Registering Node as identified by the Source Address and the SLLAO Registering Node as identified by the Source Address and the SLLAO
option in the NS(EARO) messages. option in the NS(EARO) messages.
In that mode, the 6BBR handles the ND protocol over the backbone on In that mode, the 6BBR handles the ND protocol over the backbone on
behalf of the Registered Nodes, using its own MAC address in the TLLA behalf of the Registered Nodes, using its own MAC address in the TLLA
and SLLA options in proxyed NS and NA messages. It results that for and SLLA options in proxyed NS and NA messages. It results that for
each Registered Address, a number of peer Nodes on the backbone have each Registered Address, a number of peer Nodes on the backbone have
skipping to change at page 13, line 49 skipping to change at page 14, line 4
messages. messages.
o Forwarding packets from the LLN over the backbone, and the other o Forwarding packets from the LLN over the backbone, and the other
way around. way around.
o Eventually triggering a liveliness verification of a stale o Eventually triggering a liveliness verification of a stale
registration. registration.
A 6BBR may act as a Sleeping Proxy only if the state of the binding A 6BBR may act as a Sleeping Proxy only if the state of the binding
entry is REACHABLE, or TENTATIVE in which case the answer is delayed. entry is REACHABLE, or TENTATIVE in which case the answer is delayed.
In any other state, the Sleeping Proxy operates as a Unicasting In any other state, the Sleeping Proxy operates as a Unicasting
Proxy. Proxy.
As a Unicasting Proxy, the 6BBR forwards NS messages to the As a Unicasting Proxy, the 6BBR forwards NS lookup messages to the
Registering Node, transforming Layer-2 multicast into unicast Registering Node, transforming Layer-2 multicast into unicast
whenever possible. This is not possible in UNREACHABLE state, so the whenever possible. This is not possible in UNREACHABLE state, so the
NS messages are multicasted, and rate-limited to protect the medium NS messages are multicasted, and rate-limited to protect the medium
with an exponential back-off. In other states, The messages are with an exponential back-off. In other states, The messages are
forwarded to the Registering Node as unicast Layer-2 messages. In forwarded to the Registering Node as unicast Layer-2 messages. In
TENTATIVE state, the NS message is either held till DAD completes, or TENTATIVE state, the NS message is either held till DAD completes, or
dropped. dropped.
The draft introduces the optional concept of primary and secondary The draft introduces the optional concept of primary and secondary
BBRs. The primary is the backbone router that has the highest EUI-64 BBRs. The primary is the backbone router that has the highest EUI-64
skipping to change at page 15, line 48 skipping to change at page 15, line 49
identical and older registrations (not-newer TID, same OUID) from identical and older registrations (not-newer TID, same OUID) from
a different Registering Node are responded immediately with a a different Registering Node are responded immediately with a
status of 3 (moved); this may be rate limited to protect the status of 3 (moved); this may be rate limited to protect the
medium; medium;
and any registration for a different Registered Node (different and any registration for a different Registered Node (different
OUID) are responded immediately with a status of 1 (duplicate). OUID) are responded immediately with a status of 1 (duplicate).
6.1. Registration and Binding State Creation 6.1. Registration and Binding State Creation
Upon a registration for a new address with an NS(EARO), the 6BBR Upon a registration for a new address with an NS(EARO) with the 'R'
performs a DAD operation over the backbone placing the new address as bit set, the 6BBR performs a DAD operation over the backbone placing
target in the NS-DAD message. The EARO from the registration MUST be the new address as target in the NS-DAD message. The EARO from the
placed unchanged in the NS-DAD message, and an entry is created in registration MUST be placed unchanged in the NS-DAD message, and an
TENTATIVE state for a duration of TENTATIVE_DURATION. The NS-DAD entry is created in TENTATIVE state for a duration of
message is sent multicast over the backbone to the SNMA address TENTATIVE_DURATION. The NS-DAD message is sent multicast over the
associated with the registered address. If that operation is known backbone to the SNMA address associated with the registered address.
to be costly, and the 6BBR has an indication from another source If that operation is known to be costly, and the 6BBR has an
(such as a NCE) that the Registered Address was present on the indication from another source (such as a NCE) that the Registered
backbone, that information may be leveraged to send the NS-DAD Address was present on the backbone, that information may be
message as a Layer-2 unicast to the MAC that was associated with the leveraged to send the NS-DAD message as a Layer-2 unicast to the MAC
Registered Address. that was associated with the Registered Address.
In TENTATIVE state: In TENTATIVE state:
o the entry is removed if an NA is received over the backbone for o the entry is removed if an NA is received over the backbone for
the Registered Address with no EARO option, or with an EARO option the Registered Address with no EARO option, or with an EARO option
with a status of 1 (duplicate) that indicates an existing with a status of 1 (duplicate) that indicates an existing
registration for another LLN node. The OUID and TID fields in the registration for another LLN node. The OUID and TID fields in the
EARO option received over the backbone are ignored. A status of 1 EARO option received over the backbone are ignored. A status of 1
is returned in the EARO option of the NA back to the Registering is returned in the EARO option of the NA back to the Registering
Node; Node;
skipping to change at page 17, line 5 skipping to change at page 17, line 9
entry goes to REACHABLE state for the Registration Lifetime; the entry goes to REACHABLE state for the Registration Lifetime; the
DAD process is successful and the 6BBR MUST send a multicast DAD process is successful and the 6BBR MUST send a multicast
NA(EARO) to the SNMA associated to the Registered Address over the NA(EARO) to the SNMA associated to the Registered Address over the
backbone with the Override bit set so as to take over the binding backbone with the Override bit set so as to take over the binding
from other 6BBRs. from other 6BBRs.
6.2. Defending Addresses 6.2. Defending Addresses
If a 6BBR has an entry in REACHABLE state for a Registered Address: If a 6BBR has an entry in REACHABLE state for a Registered Address:
o If the 6BBR is primary, or does not support the concept, it MUST o If the 6BBR is primary, or does not support the function of
defend that address over the backbone upon an incoming NS-DAD, primary, it MUST defend that address over the backbone upon an
either if the NS does not carry an EARO, or if an EARO is present incoming NS-DAD, either if the NS does not carry an EARO, or if an
that indicates a different Registering Node (different OUID). The EARO is present that indicates a different Registering Node
6BBR sends a NA message with the Override bit set and the NA (different OUID). The 6BBR sends a NA message with the Override
carries an EARO option if and only if the NS-DAD did so. When bit set and the NA carries an EARO option if and only if the NS-
present, the EARO in the NA(O) that is sent in response to the NS- DAD did so. When present, the EARO in the NA(O) that is sent in
DAD(EARO) carries a status of 1 (duplicate), and the OUID and TID response to the NS-DAD(EARO) carries a status of 1 (duplicate),
fields in the EARO option are obfuscated with null or random and the OUID and TID fields in the EARO option are obfuscated with
values to avoid network scanning and impersonation attacks. null or random values to avoid network scanning and impersonation
attacks.
o If the 6BBR receives an NS-DAD(EARO) that reflect a newer o If the 6BBR receives an NS-DAD(EARO) that reflect a newer
registration, the 6BBR updates the entry and the routing state to registration, the 6BBR updates the entry and the routing state to
forward packets to the new 6BBR, but keeps the entry REACHABLE. forward packets to the new 6BBR, but keeps the entry REACHABLE.
In that phase, it MAY use REDIRECT messages to reroute traffic for In that phase, it MAY use REDIRECT messages to reroute traffic for
the Registered Address to the new 6BBR. the Registered Address to the new 6BBR.
o If the 6BBR receives an NA(EARO) that reflect a newer o If the 6BBR receives an NA(EARO) that reflect a newer
registration, the 6BBR removes its entry and sends a NA(AERO) with registration, the 6BBR removes its entry and sends a NA(AERO) with
a status of 3 (moved) to the Registering Node, if the Registering a status of 3 (moved) to the Registering Node, if the Registering
skipping to change at page 18, line 4 skipping to change at page 18, line 9
In STALE state: In STALE state:
o If the Registered Address is claimed by another node on the o If the Registered Address is claimed by another node on the
backbone, with an NS-DAD or an NA, the 6BBR does not defend the backbone, with an NS-DAD or an NA, the 6BBR does not defend the
address. Upon an NA(O), or the stale time elapses, the 6BBR address. Upon an NA(O), or the stale time elapses, the 6BBR
removes its entry and sends a NA(AERO) with a status of 4 removes its entry and sends a NA(AERO) with a status of 4
(removed) to the Registering Node. (removed) to the Registering Node.
o If the 6BBR received a NS(LOOKUP) for a Registered Address, the o If the 6BBR received a NS(LOOKUP) for a Registered Address, the
6BBR MUST send an NS(NUD) following rules in [RFC7048] to the 6BBR MUST send an NS(NUD) following rules in [RFC7048] to the
registering Node targeting the Registered Address prior to Registering Node targeting the Registered Address prior to
answering. If the NUD succeeds, the operation in REACHABLE state answering. If the NUD succeeds, the operation in REACHABLE state
applies. If the NUD fails, the 6BBR refrains from answering the applies. If the NUD fails, the 6BBR refrains from answering the
lookup. The NUD expected to be mapped by the Registering Node lookup. The NUD expected to be mapped by the Registering Node
into a liveliness validation of the Registered Node if they are in into a liveliness validation of the Registered Node if they are in
fact different nodes. fact different nodes.
7. Security Considerations 7. Security Considerations
This specification expects that the link layer is sufficiently This specification expects that the link layer is sufficiently
protected, either by means of physical or IP security for the protected, either by means of physical or IP security for the
skipping to change at page 19, line 12 skipping to change at page 19, line 17
Kudos to Eric Levy-Abegnoli who designed the First Hop Security Kudos to Eric Levy-Abegnoli who designed the First Hop Security
infrastructure at Cisco. infrastructure at Cisco.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-6lo-rfc6775-update] [I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., Chakrabarti, S., and C. Thubert, P., Nordmark, E., Chakrabarti, S., and C.
Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo- Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo-
rfc6775-update-11 (work in progress), December 2017. rfc6775-update-13 (work in progress), February 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
Wasserman, "IPv6 Neighbor Discovery Optimizations for Wasserman, "IPv6 Neighbor Discovery Optimizations for
Wired and Wireless Networks", draft-chakrabarti-nordmark- Wired and Wireless Networks", draft-chakrabarti-nordmark-
6man-efficient-nd-07 (work in progress), February 2015. 6man-efficient-nd-07 (work in progress), February 2015.
[I-D.delcarpio-6lo-wlanah] [I-D.delcarpio-6lo-wlanah]
Vega, L., Robles, I., and R. Morabito, "IPv6 over Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Sarikaya, B., Thubert, P., and M. Sethi, "Address Thubert, P., Sarikaya, B., and M. Sethi, "Address
Protected Neighbor Discovery for Low-power and Lossy Protected Neighbor Discovery for Low-power and Lossy
Networks", draft-ietf-6lo-ap-nd-04 (work in progress), Networks", draft-ietf-6lo-ap-nd-06 (work in progress),
November 2017. February 2018.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
"Transmission of IPv6 Packets over Near Field "Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-09 (work in progress), Communication", draft-ietf-6lo-nfc-09 (work in progress),
January 2018. January 2018.
[I-D.ietf-6man-rs-refresh] [I-D.ietf-6man-rs-refresh]
Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6
Neighbor Discovery Optional RS/RA Refresh", draft-ietf- Neighbor Discovery Optional RS/RA Refresh", draft-ietf-
 End of changes. 20 change blocks. 
58 lines changed or deleted 68 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/