Thank you Fernando for your review. Comments are inline:
-----Original Message-----
From: Fernando Gont
[mailto:fernando(_dot_)gont(_dot_)netbook(_dot_)win(_at_)gmail(_dot_)com] On
Behalf Of ext Fernando Gont
Sent: 15. syyskuuta 2011 06:05
To: draft-ietf-behave-v4v6-bih(_at_)tools(_dot_)ietf(_dot_)org
Cc: TSV Dir; 'ietf(_at_)ietf(_dot_)org'; tsv-ads(_at_)ietf(_dot_)org; 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf