rfc8928v6.txt   rfc8928.txt 
skipping to change at line 913 skipping to change at line 913
network may form many addresses and register them using AP-ND. network may form many addresses and register them using AP-ND.
The perimeter of the attack is all the 6LRs in range of the The perimeter of the attack is all the 6LRs in range of the
attacker. The 6LR MUST protect itself against overflows and attacker. The 6LR MUST protect itself against overflows and
reject excessive registration with a status code of 2 "Neighbor reject excessive registration with a status code of 2 "Neighbor
Cache Full". This effectively blocks another (honest) 6LN from Cache Full". This effectively blocks another (honest) 6LN from
registering to the same 6LR, but the 6LN may register to other registering to the same 6LR, but the 6LN may register to other
6LRs that are in its range but not in that of the attacker. 6LRs that are in its range but not in that of the attacker.
7.3. Related to 6LoWPAN ND 7.3. Related to 6LoWPAN ND
The threats and mediations discussed in 6LoWPAN ND [RFC6775] The threats and mitigations discussed in 6LoWPAN ND [RFC6775]
[RFC8505] also apply here, in particular, denial-of-service (DoS) [RFC8505] also apply here, in particular, denial-of-service (DoS)
attacks against the registry at the 6LR or 6LBR. attacks against the registry at the 6LR or 6LBR.
Secure ND [RFC3971] forces the IPv6 address to be cryptographic since Secure ND [RFC3971] forces the IPv6 address to be cryptographic since
it integrates the CGA as the IID in the IPv6 address. In contrast, it integrates the CGA as the IID in the IPv6 address. In contrast,
this specification saves about 1 KB in every NS/NA message. Also, this specification saves about 1 KB in every NS/NA message. Also,
this specification separates the cryptographic identifier from the this specification separates the cryptographic identifier from the
registered IPv6 address so that a node can have more than one IPv6 registered IPv6 address so that a node can have more than one IPv6
address protected by the same cryptographic identifier. address protected by the same cryptographic identifier.
skipping to change at line 1224 skipping to change at line 1224
[breaking-ed25519] [breaking-ed25519]
Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R.
Susella, "Breaking Ed25519 in WolfSSL", Topics in Susella, "Breaking Ed25519 in WolfSSL", Topics in
Cryptology - CT-RSA, pp. 1-20, March 2018, Cryptology - CT-RSA, pp. 1-20, March 2018,
<https://link.springer.com/ <https://link.springer.com/
chapter/10.1007/978-3-319-76953-0_1>. chapter/10.1007/978-3-319-76953-0_1>.
[CURVE-REPR] [CURVE-REPR]
Struik, R., "Alternative Elliptic Curve Representations", Struik, R., "Alternative Elliptic Curve Representations",
Work in Progress, Internet-Draft, draft-ietf-lwig-curve- Work in Progress, Internet-Draft, draft-ietf-lwig-curve-
representations-13, 2 November 2020, representations-14, 15 November 2020,
<https://tools.ietf.org/html/draft-ietf-lwig-curve- <https://tools.ietf.org/html/draft-ietf-lwig-curve-
representations-13>. representations-14>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[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>.
skipping to change at line 1478 skipping to change at line 1478
(=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2 (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2
7eced3d9) 7eced3d9)
Acknowledgments 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. The authors are also especially grateful constructive suggestions. The authors are also especially grateful
to Robert Moskowitz and Benjamin Kaduk for their comments and to Robert Moskowitz and Benjamin Kaduk for their comments and
discussions that led to many improvements. The authors wish to also discussions that led to many improvements. The authors wish to also
thank Shwetha Bhandari for actively shepherding this document and thank Shwetha Bhandari for actively shepherding this document and
Roman Danyliw, Alissa Cooper, Mirja Kuehlewind, Eric Vyncke, Vijay Roman Danyliw, Alissa Cooper, Mirja Kühlewind, Éric Vyncke, Vijay
Gurbani, Al Morton, and Adam Montville for their constructive reviews Gurbani, Al Morton, and Adam Montville for their constructive reviews
during the IESG process. Finally, many thanks to our INT area ADs, during the IESG process. Finally, many thanks to our INT area ADs,
Suresh Krishnan and Erik Kline, who supported us along the whole Suresh Krishnan and Erik Kline, who supported us along the whole
process. process.
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Building D Building D
 End of changes. 4 change blocks. 
4 lines changed or deleted 4 lines changed or added

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