Appendix A. Changes from RFC 6434 There have been many editorial clarifications as well as significant additions and updates. While this section highlights some of the changes, readers should not rely on this section for a comprehensive list of all changes. 1. Restructured sections. 2. Added 6LoWPAN to link layers as it has some deployment. 3. Removed the Downstream-on-Demand (DoD) IPv6 Profile as it hasn't been updated. 4. Updated MLDv2 support to a MUST since nodes are restricted if MLDv1 is used. 5. Required DNS RA options so SLAAC-only devices can get DNS; RFC 8106 is a MUST. 6. Required RFC 3646 DNS Options for DHCPv6 implementations. 7. Added RESTCONF and NETCONF as possible options to network management. 8. Added a section on constrained devices. 9. Added text on RFC 7934 to address availability to hosts (SHOULD). 10. Added text on RFC 7844 for anonymity profiles for DHCPv6 clients. 11. Added mDNS and DNS-SD as updated service discovery. 12. Added RFC 8028 as a SHOULD as a method for solving a multi- prefix network. 13. Added ECN RFC 3168 as a SHOULD. 14. Added reference to RFC 7123 for security over IPv4-only networks. 15. Removed Jumbograms (RFC 2675) as they aren't deployed. 16. Updated obsoleted RFCs to the new version of the RFC, including RFCs 2460, 1981, 7321, and 4307.
17. Added RFC 7772 for power consumptions considerations. 18. Added why /64 boundaries for more detail -- RFC 7421. 19. Added a unique IPv6 prefix per host to support currently deployed IPv6 networks. 20. Clarified RFC 7066 was a snapshot for 3GPP. 21. Updated RFC 4191 as a MUST and the Type C Host as a SHOULD as they help solve multi-prefix problems. 22. Removed IPv6 over ATM since there aren't many deployments. 23. Added a note in Section 6.6 for Rule 5.5 from RFC 6724. 24. Added MUST for BCP 198 for forwarding IPv6 packets. 25. Added a reference to RFC 8064 for stable address creation. 26. Added text on the protection from excessive extension header options. 27. Added text on the dangers of 1280 MTU UDP, especially with regard to DNS traffic. 28. Added text to clarify RFC 8200 behavior for unrecognized extension headers or unrecognized ULPs. 29. Removed dated email addresses from design team acknowledgements for [RFC4294]. Appendix B. Changes from RFC 4294 to RFC 6434 There have been many editorial clarifications as well as significant additions and updates. While this section highlights some of the changes, readers should not rely on this section for a comprehensive list of all changes. 1. Updated the Introduction to indicate that this document is an applicability statement and is aimed at general nodes. 2. Significantly updated the section on mobility protocols; added references and downgraded previous SHOULDs to MAYs. 3. Changed the Sub-IP Layer section to just list relevant RFCs, and added some more RFCs.
4. Added a section on SEND (it is a MAY). 5. Revised the section on Privacy Extensions [RFC4941] to add more nuance to the recommendation. 6. Completely revised the IPsec/IKEv2 section, downgrading the overall recommendation to a SHOULD. 7. Upgraded recommendation of DHCPv6 to a SHOULD. 8. Added a background section on DHCP versus RA options, added a SHOULD recommendation for DNS configuration via RAs (RFC 6106), and cleaned up the DHCP recommendations. 9. Added the recommendation that routers implement Sections 7.3 and 7.5 of [RFC6275]. 10. Added a pointer to subnet clarification document [RFC5942]. 11. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] SHOULD be implemented. 12. Added reference to [RFC5722] (Overlapping Fragments), and made it a MUST to implement. 13. Made "A Recommendation for IPv6 Address Text Representation" [RFC5952] a SHOULD. 14. Removed the mention of delegation name (DNAME) from the discussion about [RFC3363]. 15. Numerous updates to reflect newer versions of IPv6 documents, including [RFC3596], [RFC4213], [RFC4291], and [RFC4443]. 16. Removed discussion of "Managed" and "Other" flags in RAs. There is no consensus at present on how to process these flags, and discussion of their semantics was removed in the most recent update of Stateless Address Autoconfiguration [RFC4862]. 17. Added many more references to optional IPv6 documents. 18. Made "A Recommendation for IPv6 Address Text Representation" [RFC5952] a SHOULD. 19. Updated the MLD section to include reference to Lightweight MLD [RFC5790].
20. Added a SHOULD recommendation for "Default Router Preferences and More-Specific Routes" [RFC4191]. 21. Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD. Acknowledgments o Acknowledgments (Current Document) The authors would like to thank Brian Carpenter, Dave Thaler, Tom Herbert, Erik Kline, Mohamed Boucadair, and Michayla Newcombe for their contributions and many members of the 6man WG for the inputs they gave. o Authors and Acknowledgments from RFC 6434 RFC 6434 was authored by Ed Jankiewicz, John Loughney, and Thomas Narten. The authors of RFC 6434 thank Hitoshi Asaeda, Brian Carpenter, Tim Chown, Ralph Droms, Sheila Frankel, Sam Hartman, Bob Hinden, Paul Hoffman, Pekka Savola, Yaron Sheffer, and Dave Thaler for their comments. In addition, the authors thank Mark Andrews for comments and corrections on DNS text and Alfred Hoenes for tracking the updates to various RFCs. o Authors and Acknowledgments from RFC 4294 RFC 4294 was written by the IPv6 Node Requirements design team, which had the following members: Jari Arkko, Marc Blanchet, Samita Chakrabarti, Alain Durand, Gerard Gastaud, Jun-ichiro Itojun Hagino, Atsushi Inoue, Masahiro Ishiyama, John Loughney, Rajiv Raghunarayan, Shoichi Sakane, Dave Thaler, and Juha Wiljakka. The authors of RFC 4294 thank Ran Atkinson, Jim Bound, Brian Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, Juha Ollila, and Pekka Savola for their comments.
Authors' Addresses Tim Chown Jisc Lumen House, Library Avenue Harwell Oxford, Didcot OX11 0SG United Kingdom Email: email@example.com John Loughney Intel Santa Clara, CA United States of America Email: firstname.lastname@example.org Timothy Winters University of New Hampshire, Interoperability Lab (UNH-IOL) Durham, NH United States of America Email: email@example.com