Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@xxxxxxxx if you reply to or forward this review. SUMMARY ------- This draft is on the right track but has open issues, described in the review. TECHNICAL --------- * The document mentions two possible implementation alternatives, and recommends one of them. However, lacks a discussion of the pros/cons of each alternative, and the applicability of each of them. * Section 2.2, page 8: > To avoid unnecessary fragmentation, the host's IPv4 module should be > configured with a small enough MTU (IPv6 link MTU - 20 bytes). Is the "IPv6 link MTU" the MTU of the link the host is attached to, or are you referring to the "Minimum IPv6 MTU" of 1280 bytes? * Section 2.3, page 8: > In either implementation option, if there is a real IPv4 address > available, the ENR SHOULD NOT synthesize IPv4 addresses. By default > an ENR implementation MUST NOT synthesize IPv4 addresses when real > IPv4 addresses exist. What are the reasons for which one would sinthesize IPv4 addresses when real IPv4 addresses exist? -- If there are not any, then make this a MUST (rather than a SHOULD). * Section 2.3.2, page 9: > The ENR may support DNSSEC. Should you s/may/MAY/? * Section 2.4, page 10: > (2) When the extension name resolver gets both IPv4 and IPv6 > addresses, but the IPv4 addresses contain only excluded IPv4 > addresses (e.g., 127.0.0.1). The behavior will follow case (1). Does this mean that BIH will be employed if I do "ping6 localhost"? * Section 2.4, pages 10-11: > (3) When the function mapper gets a socket API function call > triggered by a received IPv6 packet and there is no existing mapping > entry for the IPv6 source address (for example, the client sent a > UDP request to an anycast address but a response was received from a > unicast address). While I understand the scenario you're describing, it seems the description is incorrect. In the scenario you describe, it is the *user* (and not the packet) that triggers the socket API function call (e.g., a "read()) -- maybe you should be saying "when the function mapper is triggered by a received IPv6 packet..." instead?. * Page 14, Figure 6: > |<=======|<=========================| An IPv4 Socket function call. This is incorrect. You should probably say something along the lines of "Return from the IPv4 function call" -- unless you're assuming asynchronous I/O, which I'd bet you're not. * Section 4.3, page 16: > 4.3. ICMP Message Handling > > When an application needs ICMP messages values (e.g., Type, Code, > etc.) sent from the network layer, ICMPv4 message values MAY be > translated into ICMPv6 message values based on SIIT [RFC6145], and > vice versa. What do you exactly mean by "needs ICMP message values"? Do you mean "if an application needs to receive ICMP error messages.."? -- If so, shouldn't this be a "SHOULD" rather than a "MAY"? * Section 7.3, page 22: > In order to allow the BIH to defend against such attacks, the BIH > implementation MAY choose not to extend the session entry lifetime > for a specific entry upon the reception of packets for that entry > through the external interface. You should probably note that this would kill session entries for one-way communication instances. * Section 7.4, page 22: > BIH operates in combination with the DNS, and is therefore subject > to whatever security considerations are appropriate to the DNS mode > in which the BIH is operating (i.e., authoritative, recursive, or > stub- resolver mode). I don't follow why BIH could be operating in authoritative mode. Could you clarify this? * Appendix A, page 27: > Appendix A. API list intercepted by BIH > > The following informational list includes API functions that would > be appropriate to intercept by BIH module when implemented at socket > layer. Since API function call interceptions are key for this mechanism to work, I believe the contents of this section should be normative (unless you're thinking of this document as a "framework". Additionally, the list *should* be exhaustive. * Appendix A While the initial contents seem mostly informative, at the end of the Appendix there are some normative requirements. IMHO, they should be moved to the body of the document, rather than being left out in an appendix. EDITORIAL --------- *Abstract: > This draft obsoletes RFC 2767 and RFC 3338. s/draft/document/ * Section 1, page 4: > The supported class of applications includes those that use DNS for > IP address resolution and that do not embed IP address literals in > protocol payloads. s/protocol payloads/application-protocol payloads/ * Section 1, page 4: > >> BIH includes two major implementation options: a protocol >> translator between the IPv4 and the IPv6 stacks of a host, or an >> API translator between the IPv4 socket API module and the TCP/IP >> module. > > s/options/alternatives/ * Section 1.1, page 5: > which similarly provide a dual stack host means to communicate with > other IPv6 hosts using existing IPv4 applications. I'd rephrase to "which similarly provides IPv4-only applications on dual-stack hosts the means to operate over IPv6", or the like. * Section 2, page 7: > The proposed hosts in this document have an API or network-layer > translator to allow existing IPv4 applications to communicate with > IPv6-only peers. s/existing/legacy/? * Section 2, page 7: >> For example, the Extension Name Resolver may reside in the socket >> API while protocol translation takes place at the networking layer > > s/networking/network/ * Page 15, Figure 7: > | | | | | <<Reply with an IPv6 packet to.>> Should you remove the "to."? * Section 4.4, page 16: > When address mapping table clean-up is required the BIH may utilize > techniques used by network address translators, such as described in > [RFC2663], [RFC5382], and [RFC5508]. Please insert a comma between "required" and "the BIH". * Page 19: > 5. Considerations due ALG requirements Shouldn't this be "5. Considerations about ALG requirements" or "5. ALG requirements considerations", instead? * Section 7.3, page 22: > If the number of fragments is high enough, the memory of the host > could be exhausted. s/high/large/ ? * Section 7.3, page 22: > BIN implementations MUST implement proper protection against such > attacks, for instance, allocating a limited amount of memory for > fragmented packet storage. You're probably referring to one of the implementation alternatives of BIH. But since you don't use "BIN" for referring to such implementation alternative throughout the document, you shouldn't use it here, either. i.e., please rephrase. Thanks! Best regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf