|
Continuing the review from page 17 to about page 27: Technical: This document clarifies the word "consistent" above as follows. The IPv6 payload length is "consistent" with the length of the UDP datagram if the IPv6 packet length (i.e., the Payload Length value in the IPv6 header plus the IPv6 header size) is less than or equal to the UDP payload length (i.e., the Length value in the UDP header minus the UDP header size). This allows the use of trailers after the IPv6 packet, which are defined in the following sections. I think it would be more honest to say that this updates or extends the rule from RFC 4380. Consequently, maybe the document needs an "Updates: RFC 4380" header: IPv6 Operations Working Group D. Thaler 8. IANA Considerations I do not understand how this can be. The document introduces new formats and new fields, e.g., DiscoveryType field in Section 4.4. How are new values allocated? Editorial: Complex sentence. Maybe you should say "... in addition to an IPv6 Neighbor Advertisement ([RFC4861] section 4.4). This allows packets to be sent without having to relay them through a Teredo server."The Neighbor Discovery Option Trailer is used by the Server Load Reduction Extension because it allows direct bubbles to encode an IPv6 Neighbor Solicitation ([RFC4861] section 4.3), in addition to an IPv6 Neighbor Advertisement ([RFC4861] section 4.4), which prevents packets from being relayed indirectly through a Teredo server. This sentence would benefit from a more exact reference to a section in RFC 4380. Or at least when I read it as someone who has not had much to do with Teredo before, I had trouble knowing where to look for.In addition to the events specified in [RFC4380], packets equivalent to those sent for a peer the first time a connection is being established MAY be generated at other implementation-specific times. Both here and in the above text excerpt it would be useful to understand why an implementation might want to do this.This document refines the behavior as follows. A Teredo client MAY choose to send additional router solicitation messages to the server at other implementation-specific times. Section 5.1: This document refines the behavior as follows. A Teredo client MAY choose to send additional router solicitation messages to the server at other implementation-specific times. Section 5.1.1: This document refines the behavior as follows. A Teredo client MAY choose to send additional router solicitation messages to the server at other implementation-specific times. This text and the quoted text from RFC 4380 appears to be duplicated. Jari |