Thank you Fernando for your review. Comments are inline: > -----Original Message----- > From: Fernando Gont [mailto:fernando.gont.netbook.win@xxxxxxxxx] On > Behalf Of ext Fernando Gont > Sent: 15. syyskuuta 2011 06:05 > To: draft-ietf-behave-v4v6-bih@xxxxxxxxxxxxxx > Cc: TSV Dir; 'ietf@xxxxxxxx'; tsv-ads@xxxxxxxx; Behave WG > Subject: tsv-dir review of draft-ietf-behave-v4v6-bih-06 > * 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. I believe the pros/cons are included here and there in the document, but I guess we could write a small section that summarizes the pros/cons of both approaches. > * 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? MTU of the link the host is attached to. We can clarify. > * 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). One would synthesize IPv4 address, if the real IPv4 address was excluded (see section 2.3.1). > * Section 2.3.2, page 9: > > The ENR may support DNSSEC. > > Should you s/may/MAY/? I think MAY is fine, SHOULD may be too strong as of currently. > * 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"? If the "localhost" has both IPv4 and IPv6 addresses, then the ping6 would use IPv6.. and if it has only IPv4 name, then how could the BIH map any synthesized name to IPv6 address (that is not there)? So I don’t think BIH would be employed The bigger question maybe is that does the exclusion set include only addresses received over wire, or also addresses configured in hosts-file.. Maybe the exclusion should not exclude addresses that are locally configured. > * 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?. Agree, the proposed text is better. > * 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. That is directly from RFC3338. If you think first arrow as “send()”-call and the quoted one as “recv()”-call, would those arrows then make sense? > * 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"? Maybe that should be even MUST, as why the translator would not pass on ICMP information? > * 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. Like NATs usually do… but a note of this can be added. > * 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? Copy paste bug from RFC6147, will remove “authoritative”. > * 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. The list is just informational and non-exhaustive, as it depends on implementation what API functions there are – and implementation may not even utilize POSIX API conventions. Hence we did not want to have this normative. That reasoning could be added of course. > * 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. The appendix is informative, so the keywords will be removed. > EDITORIAL > --------- These were ok, will be handled. > * 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. Typo, that should be BIH, but maybe better could be “network layer implementation of option of BIH” as there probably are no fragments on socket level implementation.. Best regards, Teemu
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf