< draft-ietf-6lo-ap-nd-08.txt   draft-ietf-6lo-ap-nd-09.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Updates: 6775 (if approved) B. Sarikaya Updates: 6775 (if approved) M. Sethi
Intended status: Standards Track Intended status: Standards Track Ericsson
Expires: April 21, 2019 M. Sethi Expires: June 16, 2019 R. Struik
Ericsson
R. Struik
Struik Security Consultancy Struik Security Consultancy
October 18, 2018 B. Sarikaya
December 13, 2018
Address Protected Neighbor Discovery for Low-power and Lossy Networks Address Protected Neighbor Discovery for Low-power and Lossy Networks
draft-ietf-6lo-ap-nd-08 draft-ietf-6lo-ap-nd-09
Abstract Abstract
This document specifies an extension to 6LoWPAN Neighbor Discovery This document specifies an extension to 6LoWPAN Neighbor Discovery
(ND) defined in RFC6775 and updated in [I-D.ietf-6lo-rfc6775-update]. (ND) defined in RFC6775 and updated in [I-D.ietf-6lo-rfc6775-update].
The new extension is called Address Protected Neighbor Discovery (AP- The new extension is called Address Protected Neighbor Discovery (AP-
ND) and it protects the owner of an address against address theft and ND) and it protects the owner of an address against address theft and
impersonation attacks in a low-power and lossy network (LLN). Nodes impersonation attacks in a low-power and lossy network (LLN). Nodes
supporting this extension compute a cryptographic identifier (Crypto- supporting this extension compute a cryptographic identifier (Crypto-
ID) and use it with one or more of their Registered Addresses. The ID) and use it with one or more of their Registered Addresses. The
skipping to change at page 1, line 47 skipping to change at page 1, line 46
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 April 21, 2019. This Internet-Draft will expire on June 16, 2019.
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 42 skipping to change at page 2, line 42
4.5. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 4.5. NDP Signature Option . . . . . . . . . . . . . . . . . . 9
5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 10 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 11 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 11
6.2. NDPSO generation and verficiation . . . . . . . . . . . . 13 6.2. NDPSO generation and verficiation . . . . . . . . . . . . 13
6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 14 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 16 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 16
7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 17 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 17
7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 17 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 17
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 17
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 17 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
8.2. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 17 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative references . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Requirements Addressed in this Document . . . . . . 21 10.2. Informative references . . . . . . . . . . . . . . . . . 20
Appendix A. Requirements Addressed in this Document . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775] Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775]
(6LoWPAN ND) adapts the original IPv6 neighbor discovery (NDv6) (6LoWPAN ND) adapts the original IPv6 neighbor discovery (NDv6)
protocols defined in [RFC4861] and [RFC4862] for constrained low- protocols defined in [RFC4861] and [RFC4862] for constrained low-
power and lossy network (LLN). In particular, 6LoWPAN ND introduces power and lossy network (LLN). In particular, 6LoWPAN ND introduces
a unicast host address registration mechanism that reduces the use of a unicast host address registration mechanism that reduces the use of
multicast. 6LoWPAN ND defines a new Address Registration Option (ARO) multicast. 6LoWPAN ND defines a new Address Registration Option (ARO)
skipping to change at page 8, line 13 skipping to change at page 8, line 13
defined. defined.
4.3. Crypto-ID Parameters Option 4.3. Crypto-ID Parameters Option
This specification defines the Crypto-ID Parameters Option (CIPO), as This specification defines the Crypto-ID Parameters Option (CIPO), as
a variation of the CGA Option that carries the parameters used to a variation of the CGA Option that carries the parameters used to
form a Crypto-ID. In order to provide cryptographic agility form a Crypto-ID. In order to provide cryptographic agility
[RFC7696], AP-ND supports two possible elliptic curves, indicated by [RFC7696], AP-ND supports two possible elliptic curves, indicated by
a Crypto-Type field. NIST P-256 [FIPS186-4] MUST be supported by all a Crypto-Type field. NIST P-256 [FIPS186-4] MUST be supported by all
implementations. The Edwards-Curve Digital Signature Algorithm implementations. The Edwards-Curve Digital Signature Algorithm
(EdDSA) curve Ed25519ph (pre-hashing) [RFC8032] MAY be supported as (EdDSA) curve Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an
an alternate. alternate.
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 | Pad Length | Reserved | | Type | Length | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Type | Modifier | Reserved | | Crypto-Type | Modifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
skipping to change at page 9, line 5 skipping to change at page 9, line 5
units of 8 octets. units of 8 octets.
Modifier: 8-bit unsigned integer. Modifier: 8-bit unsigned integer.
Pad Length: 8-bit unsigned integer. The length of the Padding Pad Length: 8-bit unsigned integer. The length of the Padding
field. field.
Crypto-Type: The type of cryptographic algorithm used in Crypto-Type: The type of cryptographic algorithm used in
calculation Crypto-ID. A value of 0 indicates NIST calculation Crypto-ID. A value of 0 indicates NIST
P-256, with SHA-256 as the hash algorithm. A value P-256, with SHA-256 as the hash algorithm. A value
of 1 is assigned for Ed25519ph, with SHA-512 as the of 1 is assigned for Ed25519 (PureEdDSA), with
hash algorithm. SHA-512 as the hash algorithm.
Public Key: JWK-Encoded Public Key [RFC7517]. Public Key: JWK-Encoded Public Key [RFC7517].
Padding: A variable-length field making the option length a Padding: A variable-length field making the option length a
multiple of 8, containing as many octets as specified multiple of 8, containing as many octets as specified
in the Pad Length field. in the Pad Length field.
4.4. Nonce Option 4.4. Nonce Option
This document reuses the Nonce Option defined in section 5.3.2. of This document reuses the Nonce Option defined in section 5.3.2. of
skipping to change at page 14, line 7 skipping to change at page 14, line 7
Crypto-ID that was sent. Crypto-ID that was sent.
7. 1-byte (in network byte order) Crypto-Type value sent in the 7. 1-byte (in network byte order) Crypto-Type value sent in the
CIPO option. CIPO option.
o Depending on the Crypto-Type (see Section 8.2) chosen by the node o Depending on the Crypto-Type (see Section 8.2) chosen by the node
(6LN), apply the hash function on this concatenation. (6LN), apply the hash function on this concatenation.
o Depending on the Crypto-Type (see Section 8.2) chosen by the node o Depending on the Crypto-Type (see Section 8.2) chosen by the node
(6LN), sign the hash output with ECDSA (if curve P-256 is used) or (6LN), sign the hash output with ECDSA (if curve P-256 is used) or
sign the hash with EdDSA (if curve EdDSA25519ph). sign the hash with EdDSA (if curve Ed25519 (PureEdDSA)).
The 6LR on receiving the NDPSO and CIPO options first hashes the JWK The 6LR on receiving the NDPSO and CIPO options first hashes the JWK
encoded public-key in the CIPO option to make sure that the leftmost encoded public-key in the CIPO option to make sure that the leftmost
bits up to the size of the ROVR match. Only if the check is bits up to the size of the ROVR match. Only if the check is
successful, it tries to verify the signature in the NDPSO option successful, it tries to verify the signature in the NDPSO option
using the following. using the following.
o Concatenate the following in the order listed: o Concatenate the following in the order listed:
1. 128-bit type tag (in network byte order) 1. 128-bit type tag (in network byte order)
skipping to change at page 17, line 38 skipping to change at page 17, line 38
Moreover, the collision is only relevant when this happens within one Moreover, the collision is only relevant when this happens within one
stub network (6LBR). In the case of such a collision, an attacker stub network (6LBR). In the case of such a collision, an attacker
may be able to claim the registered address of an another legitimate may be able to claim the registered address of an another legitimate
node. However for this to happen, the attacker would also need to node. However for this to happen, the attacker would also need to
know the address which was registered by the legitimate node. This know the address which was registered by the legitimate node. This
registered address is never broadcasted on the network and therefore registered address is never broadcasted on the network and therefore
providing an additional 64-bits that an attacker must correctly providing an additional 64-bits that an attacker must correctly
guess. To prevent address disclosure, it is RECOMMENDED that nodes guess. To prevent address disclosure, it is RECOMMENDED that nodes
derive the address being registered independently of the ROVR. derive the address being registered independently of the ROVR.
7.4. Implementation Attacks
The signature schemes referenced in this specification comply with
NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards
[RFC8032] and offer strong algorithmic security at roughly 128-bit
security level. These signature schemes use elliptic curves that
were either specifically designed with exception-free and constant-
time arithmetic in mind [RFC7748], or then we have extensive
implementation experience of resistance to timing attacks
[FIPS186-4]. However, careless implementations of the signing
operations could nevertheless leak information on private keys. For
example, there are micro-architectural side channel attacks that
implementors should be aware of [breaking-ed25519]. Implementors
should be particularly aware that a secure implementation of Ed25519
requires a protected implementation of the hash function SHA-512,
whereas this is not required with implementations of SHA-256 used
with ECDSA.
8. IANA considerations 8. IANA considerations
8.1. CGA Message Type 8.1. CGA Message Type
This document defines a new 128-bit value under the CGA Message Type This document defines a new 128-bit value under the CGA Message Type
[RFC3972] namespace, 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. [RFC3972] namespace, 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.
8.2. Crypto-Type Subregistry 8.2. Crypto-Type Subregistry
IANA is requested to create a new subregistry "Crypto-Type IANA is requested to create a new subregistry "Crypto-Type
skipping to change at page 18, line 11 skipping to change at page 18, line 29
and contains a Signature Algorithm and a Hash Function as shown in and contains a Signature Algorithm and a Hash Function as shown in
Table 1. The following Crypto-Type values are defined in this Table 1. The following Crypto-Type values are defined in this
document: document:
+--------------+-----------------+---------------+------------------+ +--------------+-----------------+---------------+------------------+
| Crypto-Type | Signature | Hash Function | Defining | | Crypto-Type | Signature | Hash Function | Defining |
| value | Algorithm | | Specification | | value | Algorithm | | Specification |
+--------------+-----------------+---------------+------------------+ +--------------+-----------------+---------------+------------------+
| 0 | NIST P-256 | SHA-256 | RFC THIS | | 0 | NIST P-256 | SHA-256 | RFC THIS |
| | [FIPS186-4] | [RFC6234] | | | | [FIPS186-4] | [RFC6234] | |
| 1 | Ed25519ph | SHA-512 | RFC THIS | | 1 | Ed25519 | SHA-512 | RFC THIS |
| | [RFC8032] | [RFC6234] | | | | [RFC8032] | [RFC6234] | |
+--------------+-----------------+---------------+------------------+ +--------------+-----------------+---------------+------------------+
Table 1: Crypto-Types Table 1: Crypto-Types
As is evident from the table above, although the two curves provide As is evident from the table above, although the two curves provide
similar security, they however rely on different hash functions. similar security, they however rely on different hash functions.
Supporting multiple hash functions on constrained devices is not Supporting multiple hash functions on constrained devices is not
ideal. [I-D.struik-lwig-curve-representations] provides information ideal. [I-D.struik-lwig-curve-representations] provides information
on how to represent Montgomery curves and (twisted) Edwards curves as on how to represent Montgomery curves and (twisted) Edwards curves as
skipping to change at page 18, line 36 skipping to change at page 19, line 9
similar or better security (with less code) can be defined in future. similar or better security (with less code) can be defined in future.
Assignment of new values for new Crypto-Type MUST be done through Assignment of new values for new Crypto-Type MUST be done through
IANA with "Specification Required" and "IESG Approval" as defined in IANA with "Specification Required" and "IESG Approval" as defined in
[RFC8126]. [RFC8126].
9. Acknowledgments 9. Acknowledgments
Many thanks to Charlie Perkins for his in-depth review and Many thanks to Charlie Perkins for his in-depth review and
constructive suggestions. We are also especially grateful to Robert constructive suggestions. We are also especially grateful to Robert
Moskowitz for his comments that lead to many improvements. Moskowitz for his comments that led to many improvements.
10. References 10. References
10.1. Normative References 10.1. Normative References
[FIPS186-4] [FIPS186-4]
FIPS 186-4, "Digital Signature Standard (DSS), Federal FIPS 186-4, "Digital Signature Standard (DSS), Federal
Information Processing Standards Publication 186-4", US Information Processing Standards Publication 186-4", US
Department of Commerce/National Institute of Standards and Department of Commerce/National Institute of Standards and
Technology Gaithersburg, MD, July 2013. Technology , July 2013.
[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, "Registration Extensions for 6LoWPAN Neighbor Perkins, "Registration Extensions for 6LoWPAN Neighbor
Discovery", draft-ietf-6lo-rfc6775-update-21 (work in Discovery", draft-ietf-6lo-rfc6775-update-21 (work in
progress), June 2018. progress), June 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,
skipping to change at page 19, line 29 skipping to change at page 20, line 5
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
10.2. Informative references 10.2. Informative references
[breaking-ed25519]
Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R.
Susella, "Breaking Ed25519 in WolfSSL", Cryptographers'
Track at the RSA Conference , 2018,
<https://link.springer.com/
chapter/10.1007/978-3-319-76953-0_1>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P. and C. Perkins, "IPv6 Backbone Router", draft- Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
ietf-6lo-backbone-router-07 (work in progress), September Backbone Router", draft-ietf-6lo-backbone-router-09 (work
2018. in progress), December 2018.
[I-D.struik-lwig-curve-representations] [I-D.struik-lwig-curve-representations]
Struik, R., "Alternative Elliptic Curve Representations", Struik, R., "Alternative Elliptic Curve Representations",
draft-struik-lwig-curve-representations-02 (work in draft-struik-lwig-curve-representations-02 (work in
progress), July 2018. progress), July 2018.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
skipping to change at page 20, line 26 skipping to change at page 21, line 20
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework", "Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013, RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>. <https://www.rfc-editor.org/info/rfc7039>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 22, line 20 skipping to change at page 23, line 4
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis 06254
FRANCE FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Behcet Sarikaya
Plano, TX
USA
Email: sarikaya@ieee.org
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: mohit@piuha.net Email: mohit@piuha.net
Rene Struik Rene Struik
Struik Security Consultancy Struik Security Consultancy
Email: rstruik.ext@gmail.com Email: rstruik.ext@gmail.com
Behcet Sarikaya
Plano, TX
USA
Email: sarikaya@ieee.org
 End of changes. 21 change blocks. 
45 lines changed or deleted 67 lines changed or added

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