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(_at_)ietf(_dot_)org 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(_at_)gont(_dot_)com(_dot_)ar || fgont(_at_)acm(_dot_)org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf