| < draft-ietf-6lo-backbone-router-19.txt | draft-ietf-6lo-backbone-router-20.txt > | |||
|---|---|---|---|---|
| 6lo P. Thubert, Ed. | 6lo P. Thubert, Ed. | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Updates: 6775, 8505 (if approved) C.E. Perkins | Updates: 6775, 8505 (if approved) C.E. Perkins | |||
| Intended status: Standards Track Blue Meadow Networking | Intended status: Standards Track Blue Meadow Networking | |||
| Expires: 4 September 2020 E. Levy-Abegnoli | Expires: 24 September 2020 E. Levy-Abegnoli | |||
| Cisco Systems | Cisco Systems | |||
| 3 March 2020 | 23 March 2020 | |||
| IPv6 Backbone Router | IPv6 Backbone Router | |||
| draft-ietf-6lo-backbone-router-19 | draft-ietf-6lo-backbone-router-20 | |||
| Abstract | Abstract | |||
| This document updates RFC 6775 and RFC 8505 in order to enable proxy | This document updates RFC 6775 and RFC 8505 in order to enable proxy | |||
| services for IPv6 Neighbor Discovery by Routing Registrars called | services for IPv6 Neighbor Discovery by Routing Registrars called | |||
| Backbone Routers. Backbone Routers are placed along the wireless | Backbone Routers. Backbone Routers are placed along the wireless | |||
| edge of a Backbone, and federate multiple wireless links to form a | edge of a Backbone, and federate multiple wireless links to form a | |||
| single Multi-Link Subnet. | single Multi-Link Subnet. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
| 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 4 September 2020. | This Internet-Draft will expire on 24 September 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 33 ¶ | skipping to change at page 2, line 33 ¶ | |||
| 5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 17 | 5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 17 | |||
| 6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 18 | 6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 18 | |||
| 7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 20 | 7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 20 | |||
| 8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 21 | 8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 21 | |||
| 9. Creating and Maintaining a Binding . . . . . . . . . . . . . 22 | 9. Creating and Maintaining a Binding . . . . . . . . . . . . . 22 | |||
| 9.1. Operations on a Binding in Tentative State . . . . . . . 23 | 9.1. Operations on a Binding in Tentative State . . . . . . . 23 | |||
| 9.2. Operations on a Binding in Reachable State . . . . . . . 24 | 9.2. Operations on a Binding in Reachable State . . . . . . . 24 | |||
| 9.3. Operations on a Binding in Stale State . . . . . . . . . 25 | 9.3. Operations on a Binding in Stale State . . . . . . . . . 25 | |||
| 10. Registering Node Considerations . . . . . . . . . . . . . . . 26 | 10. Registering Node Considerations . . . . . . . . . . . . . . . 26 | |||
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
| 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 29 | 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 | 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 | 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 15. Normative References . . . . . . . . . . . . . . . . . . . . 30 | 15. Normative References . . . . . . . . . . . . . . . . . . . . 30 | |||
| 16. Informative References . . . . . . . . . . . . . . . . . . . 31 | 16. Informative References . . . . . . . . . . . . . . . . . . . 32 | |||
| Appendix A. Possible Future Extensions . . . . . . . . . . . . . 34 | Appendix A. Possible Future Extensions . . . . . . . . . . . . . 34 | |||
| Appendix B. Applicability and Requirements Served . . . . . . . 35 | Appendix B. Applicability and Requirements Served . . . . . . . 35 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| 1. Introduction | 1. Introduction | |||
| IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient | IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient | |||
| and reliable broadcast service for wired networks; applications and | and reliable broadcast service for wired networks; applications and | |||
| protocols have been built that heavily depend on that feature for | protocols have been built that heavily depend on that feature for | |||
| their core operation. Unfortunately, Low-Power Lossy Networks (LLNs) | their core operation. Unfortunately, Low-Power Lossy Networks (LLNs) | |||
| and local wireless networks generally do not provide the broadcast | and local wireless networks generally do not provide the broadcast | |||
| capabilities of Ethernet Bridging in an economical fashion. | capabilities of Ethernet Bridging in an economical fashion. | |||
| skipping to change at page 7, line 37 ¶ | skipping to change at page 7, line 37 ¶ | |||
| "IPv6 Stateless Address Autoconfiguration" [RFC4862] and | "IPv6 Stateless Address Autoconfiguration" [RFC4862] and | |||
| "Optimistic Duplicate Address Detection" [RFC4429], | "Optimistic Duplicate Address Detection" [RFC4429], | |||
| IPv6 ND over multiple links: "Neighbor Discovery Proxies (proxy-ND)" | IPv6 ND over multiple links: "Neighbor Discovery Proxies (proxy-ND)" | |||
| [RFC4389] and "Multi-Link Subnet Issues" [RFC4903], | [RFC4389] and "Multi-Link Subnet Issues" [RFC4903], | |||
| 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power | 6LoWPAN: "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 | |||
| 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy | 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy | |||
| Networks [RFC6775] and "Registration Extensions for 6LoWPAN | Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor | |||
| Neighbor Discovery" [RFC8505]. | Discovery" [RFC8505], and " Address Protected Neighbor Discovery | |||
| for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd]. | ||||
| 3. Overview | 3. Overview | |||
| This section and its subsections present a non-normative high level | This section and its subsections present a non-normative high level | |||
| view of the operation of the 6BBR. The following sections cover the | view of the operation of the 6BBR. The following sections cover the | |||
| normative part. Figure 1 illustrates a backbone link that federates | normative part. | |||
| a collection of LLNs as a single IPv6 Subnet, with a number of 6BBRs | ||||
| providing proxy-ND services to their attached LLNs. | Figure 1 illustrates a backbone link that federates a collection of | |||
| LLNs as a single IPv6 Subnet, with a number of 6BBRs providing proxy- | ||||
| ND services to their attached LLNs. | ||||
| | | | | |||
| +-----+ +-----+ +-----+ IPv6 | +-----+ +-----+ +-----+ IPv6 | |||
| (default) | | (Optional) | | | | Node | (default) | | (Optional) | | | | Node | |||
| Router | | 6LBR | | | | or | Router | | 6LBR | | | | or | |||
| +-----+ +-----+ +-----+ 6LN | +-----+ +-----+ +-----+ 6LN | |||
| | Backbone side | | | | Backbone side | | | |||
| ----+-------+-----------------+---+-------------+----+----- | ----+-------+-----------------+---+-------------+----+----- | |||
| | | | | | | | | |||
| +------+ +------+ +------+ | +------+ +------+ +------+ | |||
| skipping to change at page 27, line 19 ¶ | skipping to change at page 27, line 19 ¶ | |||
| The Registering Node SHOULD also follow BCP 202 [RFC7772] in order to | The Registering Node SHOULD also follow BCP 202 [RFC7772] in order to | |||
| limit the use of multicast RAs. It SHOULD also implement Simple | limit the use of multicast RAs. It SHOULD also implement Simple | |||
| Procedures for Detecting Network Attachment in IPv6 [RFC6059] (DNA | Procedures for Detecting Network Attachment in IPv6 [RFC6059] (DNA | |||
| procedures) to detect movements, and support Packet-Loss Resiliency | procedures) to detect movements, and support Packet-Loss Resiliency | |||
| for Router Solicitations [RFC7559] in order to improve reliability | for Router Solicitations [RFC7559] in order to improve reliability | |||
| for the unicast RS messages. | for the unicast RS messages. | |||
| 11. Security Considerations | 11. Security Considerations | |||
| The procedures in this document modify the mechanisms used for IPv6 | ||||
| ND and DAD and should not affect other aspects of IPv6 or higher- | ||||
| level-protocol operation. As such, the main classes of attacks that | ||||
| are in play are those which week to block neighbor discovery or to | ||||
| forcibly claim an address that another node is attempting to use. In | ||||
| the absence of cryptographic protection at higher layers, the latter | ||||
| class of attacks can have significant consequences, with the attacker | ||||
| being able to read all the "stolen" traffic that was directed to the | ||||
| target of the attack. | ||||
| This specification applies to LLNs and a backbone in which the | This specification applies to LLNs and a backbone in which the | |||
| individual links are protected against rogue access, by | individual links are protected against rogue access, on the LLN by | |||
| authenticating a node that attaches to the network and encrypting at | authenticating a node that attaches to the network and encrypting at | |||
| the MAC layer the transmissions so packets may neither be overheard | the MAC layer the transmissions, and on the backbone side using the | |||
| or nor forged. In particular, the LLN MAC is required to provide | physical security and access control measures that are typically | |||
| secure unicast to/from the Backbone Router and secure broadcast from | applied there, so packets may neither be forged or nor overheard. | |||
| the routers in a way that prevents tampering with or replaying the ND | ||||
| messages. | In particular, the LLN MAC is required to provide secure unicast to/ | |||
| from the Backbone Router and secure broadcast from the routers in a | ||||
| way that prevents tampering with or replaying the ND messages. | ||||
| For the IPv6 ND operation over the backbone, and unless the classical | For the IPv6 ND operation over the backbone, and unless the classical | |||
| ND is disabled (e.g., by configuration), the classical ND messages | ND is disabled (e.g., by configuration), the classical ND messages | |||
| are interpreted as emitted by the address owner and have precedence | are interpreted as emitted by the address owner and have precedence | |||
| over the 6BBR that is only a proxy. It results that the security | over the 6BBR that is only a proxy. | |||
| threats that are detailed in section 11.1 of [RFC4861] fully apply to | ||||
| this specification as well. In very short: | It results that the security threats that are detailed in section | |||
| 11.1 of [RFC4861] fully apply to this specification as well. In very | ||||
| short: | ||||
| * Any node that can send a packet on the backbone can take over any | * Any node that can send a packet on the backbone can take over any | |||
| address including addresses of LLN nodes by claiming it with an NA | address including addresses of LLN nodes by claiming it with an NA | |||
| message and the Override bit set. This means that the real owner | message and the Override bit set. This means that the real owner | |||
| will stop receiving its packets. | will stop receiving its packets. | |||
| * Any node that can send a packet on the backbone can forge traffic | * Any node that can send a packet on the backbone can forge traffic | |||
| and pretend it is issued from a address that it does not own, even | and pretend it is issued from a address that it does not own, even | |||
| if it did not claim the address using ND. | if it did not claim the address using ND. | |||
| skipping to change at page 28, line 11 ¶ | skipping to change at page 28, line 24 ¶ | |||
| * If the rogue can receive a packet from the backbone it can also | * If the rogue can receive a packet from the backbone it can also | |||
| snoop all the intercepted traffic, be it by stealing an address or | snoop all the intercepted traffic, be it by stealing an address or | |||
| the role of a router. | the role of a router. | |||
| This means that any rogue access to the backbone must be prevented at | This means that any rogue access to the backbone must be prevented at | |||
| all times, and that nodes that are attached to the backbone must be | all times, and that nodes that are attached to the backbone must be | |||
| fully trusted / never compromised. | fully trusted / never compromised. | |||
| Using address registration as the sole ND mechanism on a link and | Using address registration as the sole ND mechanism on a link and | |||
| coupling it with [I-D.ietf-6lo-ap-nd] guarantees the ownership of a | coupling it with [I-D.ietf-6lo-ap-nd] guarantees the ownership of a | |||
| registered address within that link. The protection is based on a | registered address within that link. | |||
| proof-of-ownership encoded in the ROVR field and protects against | ||||
| address theft and impersonation by a 6LN, because the 6LR can | ||||
| challenge the Registered Node for a proof-of-ownership. | ||||
| The protection extends to the full LLN in the case of an LLN Link, | * The protection is based on a proof-of-ownership encoded in the | |||
| but does not extend over the backbone since the 6BBR cannot provide | ROVR field and protects against address theft and impersonation by | |||
| the proof-of-ownership when it defends the address. | a 6LN, because the 6LR can challenge the Registered Node for a | |||
| proof-of-ownership. | ||||
| * The protection extends to the full LLN in the case of an LLN Link, | ||||
| but does not extend over the backbone since the 6BBR cannot | ||||
| provide the proof-of-ownership when it defends the address. | ||||
| A possible attack over the backbone can be done by sending an NS with | A possible attack over the backbone can be done by sending an NS with | |||
| an EARO and expecting the NA(EARO) back to contain the TID and ROVR | an EARO and expecting the NA(EARO) back to contain the TID and ROVR | |||
| fields of the existing state. With that information, the attacker | fields of the existing state. With that information, the attacker | |||
| can easily increase the TID and take over the Binding. | can easily increase the TID and take over the Binding. | |||
| If the classical ND is disabled on the backbone and the use of | If the classical ND is disabled on the backbone and the use of | |||
| [I-D.ietf-6lo-ap-nd] and a 6LBR are mandated, the network will | [I-D.ietf-6lo-ap-nd] and a 6LBR are mandated, the network will | |||
| benefit from the following new advantages: | benefit from the following new advantages: | |||
| skipping to change at page 29, line 15 ¶ | skipping to change at page 29, line 30 ¶ | |||
| Less Layer-2 churn on the backbone: Using the Routing Proxy | Less Layer-2 churn on the backbone: Using the Routing Proxy | |||
| approach, the Link-Layer address of the LLN devices and their | approach, the Link-Layer address of the LLN devices and their | |||
| mobility are not visible in the backbone; only the Link-Layer | mobility are not visible in the backbone; only the Link-Layer | |||
| addresses of the 6BBR and backbone nodes are visible at Layer 2 on | addresses of the 6BBR and backbone nodes are visible at Layer 2 on | |||
| the backbone. This is mandatory for LLNs that cannot be bridged | the backbone. This is mandatory for LLNs that cannot be bridged | |||
| on the backbone, and useful in any case to scale down, stabilize | on the backbone, and useful in any case to scale down, stabilize | |||
| the forwarding tables at Layer 2 and avoid the gratuitous frames | the forwarding tables at Layer 2 and avoid the gratuitous frames | |||
| that are typically broadcasted to fix the transparent bridging | that are typically broadcasted to fix the transparent bridging | |||
| tables when a wireless node roams from an AP to the next. | tables when a wireless node roams from an AP to the next. | |||
| This specification introduce a 6BBR that is a router on the path of | This specification introduces a 6BBR that is a router on the path of | |||
| the LLN traffic and a 6LBR that is used for the lookup. They could | the LLN traffic and a 6LBR that is used for the lookup. They could | |||
| be interesting targets for an attacker, but not more than a default | be interesting targets for an attacker. A compromised 6BBR can | |||
| router and a DHCP server, respectively, which already exist in | accept a registration but block the traffic, or refrain from | |||
| classical networks, and can be defended using the same methods. | proxying. A compromised 6LBR may accept unduly the transfer of | |||
| ownership of an address, or block a new comer by faking that its | ||||
| address is a duplicate. But those attacks are possible in a | ||||
| classical network from a compromised default router and a DHCP | ||||
| server, respectively, and can be prevented using the same methods. | ||||
| A possible attack over the LLN can still be done by compromising a | A possible attack over the LLN can still be done by compromising a | |||
| 6LR. A compromised 6LR may modify the ROVR of EDAR messages in | 6LR. A compromised 6LR may modify the ROVR of EDAR messages in | |||
| flight and transfer the ownership of the Registered Address to itself | flight and transfer the ownership of the Registered Address to itself | |||
| or a tier. It may also claim that a ROVR was validated when it | or a tier. It may also claim that a ROVR was validated when it | |||
| really wasn't, and reattribute an address to self or to an attached | really wasn't, and reattribute an address to self or to an attached | |||
| 6LN. This means that 6LRs, as well as 6LBRs and 6BBRS must still be | 6LN. This means that 6LRs, as well as 6LBRs and 6BBRS must still be | |||
| fully trusted / never compromised. | fully trusted / never compromised. | |||
| This specification mandates to check on the 6LBR on the backbone | This specification mandates to check on the 6LBR on the backbone | |||
| skipping to change at page 30, line 15 ¶ | skipping to change at page 30, line 31 ¶ | |||
| 13. IANA Considerations | 13. IANA Considerations | |||
| This document has no request to IANA. | This document has no request to IANA. | |||
| 14. Acknowledgments | 14. Acknowledgments | |||
| Many thanks to Dorothy Stanley, Thomas Watteyne and Jerome Henry for | Many thanks to Dorothy Stanley, Thomas Watteyne and Jerome Henry for | |||
| their various contributions. Also many thanks to Timothy Winters and | their various contributions. Also many thanks to Timothy Winters and | |||
| Erik Nordmark for their help, review and support in preparation to | Erik Nordmark for their help, review and support in preparation to | |||
| the IESG cycle, and to Kyle Rose, Elwyn Davies, Barry Leiba, Mirja | the IESG cycle, and to Kyle Rose, Elwyn Davies, Barry Leiba, Mirja | |||
| Kühlewind, Alvaro Retana, Roman Danyliw and very especially | Kuhlewind, Alvaro Retana, Roman Danyliw and very especially Dominique | |||
| Dominique Barthel and Benjamin Kaduk for their useful contributions | Barthel and Benjamin Kaduk for their useful contributions through the | |||
| through the IETF last call and IESG process. | IETF last call and IESG process. | |||
| 15. Normative References | 15. Normative References | |||
| [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 | |||
| skipping to change at page 33, line 18 ¶ | skipping to change at page 33, line 34 ¶ | |||
| Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 | Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 | |||
| Neighbor Discovery Optional RS/RA Refresh", Work in | Neighbor Discovery Optional RS/RA Refresh", Work in | |||
| Progress, Internet-Draft, draft-ietf-6man-rs-refresh-02, | Progress, Internet-Draft, draft-ietf-6man-rs-refresh-02, | |||
| 31 October 2016, <https://tools.ietf.org/html/draft-ietf- | 31 October 2016, <https://tools.ietf.org/html/draft-ietf- | |||
| 6man-rs-refresh-02>. | 6man-rs-refresh-02>. | |||
| [I-D.ietf-6lo-ap-nd] | [I-D.ietf-6lo-ap-nd] | |||
| Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, | Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, | |||
| "Address Protected Neighbor Discovery for Low-power and | "Address Protected Neighbor Discovery for Low-power and | |||
| Lossy Networks", Work in Progress, Internet-Draft, draft- | Lossy Networks", Work in Progress, Internet-Draft, draft- | |||
| ietf-6lo-ap-nd-19, 6 February 2020, | ietf-6lo-ap-nd-20, 9 March 2020, | |||
| <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-19>. | <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-20>. | |||
| [I-D.ietf-6tisch-architecture] | [I-D.ietf-6tisch-architecture] | |||
| Thubert, P., "An Architecture for IPv6 over the TSCH mode | Thubert, P., "An Architecture for IPv6 over the TSCH mode | |||
| of IEEE 802.15.4", Work in Progress, Internet-Draft, | of IEEE 802.15.4", Work in Progress, Internet-Draft, | |||
| draft-ietf-6tisch-architecture-28, 29 October 2019, | draft-ietf-6tisch-architecture-28, 29 October 2019, | |||
| <https://tools.ietf.org/html/draft-ietf-6tisch- | <https://tools.ietf.org/html/draft-ietf-6tisch- | |||
| architecture-28>. | architecture-28>. | |||
| [I-D.ietf-mboned-ieee802-mcast-problems] | [I-D.ietf-mboned-ieee802-mcast-problems] | |||
| Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. | Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. | |||
| End of changes. 19 change blocks. | ||||
| 37 lines changed or deleted | 60 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/ | ||||