I would be happy to see this published as-is, but I did notice a few points.
I think the Introduction needs a general warning something like: This document reflects the state of IPv6 standards at a particular moment. Subsequent standards work and operational experience may require changes to the recommendations in this document. Also in the Introduction: > As it is not always possible for an implementer to know the exact > usage of IPv6 in a node, an overriding requirement for IPv6 nodes is > that they should adhere to Jon Postel's Robustness Principle: > > Be conservative in what you do, be liberal in what you accept from > others [RFC0793]. Note that this is also present in RFC 1958, by which time Jon had reformulated it slightly as: > Be strict when sending and tolerant when receiving. In 4. Sub-IP Layer > In addition to traditional physical link-layers, it is also possible > to tunnel IPv6 over other protocols. Examples include: Should we mention that basic v6/v4 tunnels are specified in [RFC4213]? And the examples > - Teredo: Tunneling IPv6 over UDP through Network Address > Translations (NATs) [RFC4380] > - Transmission of IPv6 over IPv4 Domains without Explicit Tunnels > [RFC2529] may not be so well chosen. Teredo is not loved by operators, and RFC 2529 is essentially unused today. Maybe 6rd (RFC 5969)and hub-and-spoke (RFC 5571) would be better examples. Two topics are not mentioned. 1. The flow label and RFC 3697. I think that is probably wise until we produce 3697bis. 2. DNSSEC. I don't recall whether we discussed that. If we did, I'm sorry to raise it again. However, I suspect we will get pushback in security review if it is not mentioned. Nit: there should be a Replaces: 4294 header. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
