Subject: [BEHAVE] review of draft-ietf-behave-v6v4-xlate-10

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Mar 2010 08:50:39 -0400

Hi,

I reviewed draft-ietf-behave-v6v4-xlate-10 as an individual
contributor and have comments.

The framework refers to this document as the description of stateless
translation, but this discusses both stateless and stateful
tranlation. I think this document should only discuss stateless. More
comments on this below.

section 1.1
s/model is consists of/model consists of/

Figure 1 shows the translation function as "XLATE"; the framework
document shows the translation function as "XLAT". Please be
consistent with the framework.

The framework discusses scenarios; this document discusses the
translation model. This appears to be mostly just different wording
for the same concept. Please make this document consistent with the
terminology and definitions and figures in the framework document, to
help reduce ambiguity.

Figure 1 mentions DNS64 and DNS46; these should have references, or be
deleted. I don't see any reason to discuss the AAAA translation in
this document, which does not deal with DNS translation.

section 1.2

s/algorithms itself/algorithms/

OLD:
"The implementation of IPv4/IPv6
   translation SHOULD also refer to [I-D.ietf-behave-v6v4-framework],
   [I-D.ietf-behave-address-format] and
   [I-D.ietf-behave-v6v4-xlate-stateful], etc."
NEW:
"Readers of this document are expected to have read and understood the
framework described in [I-D.ietf-behave-v6v4-framework].
Implementations of this IPv4/IPv6 translation specification MUST also
support the header translation algorithms in
[I-D.ietf-behave-address-format]. Implementations MAY also support
Stateful translation [I-D.ietf-behave-v6v4-xlate-stateful]."

OLD:
   The issues and algorithms in the translation of datagrams
containing
   TCP segments are described in [RFC5382].  The considerations of
that
   document are applicable in this case as well.
NEW:
   The issues and algorithms in the translation of datagrams
containing
   TCP segments are described in [RFC5382]. 

"   IPv4 multicast addresses [RFC3171] cannot be mapped to IPv6
multicast
   addresses [RFC3307] based on the unicast mapping rule.  However, if
a
   multicast address mapping mechanism is defined, the IP/ICMP header
   translation aspect of this document works."
How do you know it works if you don't know how things will be defined?
I think it 
would be more appropriate to say the IP/ICMP header translation
specified in this document is consistent with requirements of
multicast IP/ICMP headers [add reference here]. However IPv4 multicast
addresses [RFC3171] cannot be mapped to IPv6 multicast addresses
[RFC3307] based on the unicast mapping rule [reference?].

s/   Translator SHOULD make sure/   Translators SHOULD make sure/

section 1.3

Isn't this document about stateless? Why do we need to describe
stateful in this document? All we should need is a discussion of what
stateless means.

I find the comparison between stateless and stateful not parallel,
which makes it harder to understand the distinction. The stateless
mode is described as using a specific address range; The stateful mode
is described as using a specific address range **but the IPv6 system
may use any addresses except in that range**. This reads as if that is
a distinction between the two types, but isn't it true that, in the
stateless approach, the IPv6 system can use any addresses except in
that range? 

Isn't the distinction that the stateless algorithm uses special
prefixes during translation, while the stateful algorithm uses a
mapping table for translation?

section 1.4

"The reassembling of
   fragmented packets in the stateful translator is discussed in
   [I-D.ietf-behave-v6v4-xlate-stateful], since it requires state
   maintenance in the translator."
Why is this document discussing what is discussed in the other
document? Just focus on what this document is about.

section 3

OLD:
"if the address mapping algorithm is not checksum-neutral,"
NEW:
if the address translation algorithm is not checksum-neutral,

OLD:
   One of the differences between IPv4 and IPv6, is that in IPv6, path
   MTU discovery is mandatory but it is optional in IPv4.   This
implies
   that IPv6 routers will never fragment a packet - only the sender
can
   do fragmentation.
NEW:
   Path MTU discovery is mandatory in IPv6 but it is optional in IPv4.
IPv6 routers never fragment a packet - only the sender can do
fragmentation.

s/has to/MUST/

"the actual translation of the packet header consists of a
   simple mapping as defined below"
It would be good to reserve the term "mapping" for use when discussing
stateful translations.

section 3.1

OLD:
An implementation of a translator SHOULD
      provide the ability to ignore the IPv4 TOS and always set the
IPv6
      traffic class (TC) to zero.
NEW:
An implementation of a translator SHOULD support an
administratively-configurable option to ignore the IPv4 TOS and always
set the IPv6 traffic class (TC) to zero.

"In the stateful mode, which is to say "
Why is this document discussing stateful mode?

s/which is to say that if
      the IPv4 destination address is within a range of configured
IPv4
      stateless translation prefix,//

OLD:
   If any IPv4 options are present in the IPv4 packet, the IPv4
options
   MUST be ignored (i.e., there is no attempt to translate the
options)
   and the packet translated normally.
NEW:
   If any IPv4 options are present in the IPv4 packet, the IPv4
options
   MUST be ignored and the packet translated normally; there is no
attempt to translate the options.

s/MUST instead be discarded/MUST be discarded/

OLD:
            Code 6,7:  Set Code value to 0 (No route to destination).
            Code 8:  Set Code value to 0 (No route to destination).
NEW:
            Code 6,7,8:  Set Code value to 0 (No route to
destination).

"The translation of the inner IP header can be done by invoking the
   function that translated the outer IP headers.  This process SHOULD
   stop at the first embedded header and drop the packet if it
contains
   more."
The document should explain when it is acceptable to not follow this
process. (i.e., why this is a SHOULD rather than a MUST)

section 3.5
Why is this document discussing stateful mode?

section 3.6

capitalization of section title inconsistent

   Protocol:  For ICMPv6 (58) changed to ICMPv4 (1), otherwise Next
      Header field copied from IPv6 header.
I don't understand the (non-)sentence. Please rewrite as a sentence.

Source Address:
	why are we discussing stateful mode in this document?

"However, the Total
   Length field and the Protocol field is adjusted to "skip" these
   extension headers."
s/is/are/

s/If translated packet/If the translated packet/
s/then translator/then the translator/
s/drop packet/drop the packet/
s/send ICMPv6/send the ICMPv6/

s/all ICMP packets need to/all ICMP packets MUST/
s/the included IP header also needs translation/the included IP header
MUST be translated/
s/represented of/representing/
s/needs to be/MUST be/

OLD:
The translation of this "packet in
   error" is likely to change the length of the datagram thus the
Total
   Length field in the outer IPv4 header might need to be updated.
NEW:
   If the translation of this "packet in error" changes the length of
the datagram, the Total
   Length field in the outer IPv4 header MUST be updated.
(similar text elsewhere in the document should be updated to use RFC
2119 terms.)

s/This process SHOULD stop at first embedded header/This process
SHOULD stop at the first embedded header/

What conditions are acceptable to not stop at the first embedded
header?
i.e., why is this a SHOULD rather than a MUST?

section References:

I am concerned about including citations to email list messages. This
is a standards document, not an academic research paper. I think it is
inappropriate to cite such messages in a standards document. I think
the citations and references for Miller, Dongjin, and Stasiewicz
should be removed from the document.

David Harrington
[email-masked]
[email-masked]
[email-masked]