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

From: "David Harrington" <[email-masked]>
Date: Tue, 23 Mar 2010 18:05:53 -0700

Hi,

I have reviewed portions of draft-ietf-behave-v6v4-xlate-stateful-09
and have comments.

s/a IPv6/an IPv6/

"the normal NAT manner" - is there a normal NAT manner?

"Due to IPv4 address depletion, it is likely that in the future, many
IPv6-only clients will want to connect to IPv4-only servers."
While this implies that IPv6 clients will be needed, it doesn't
mention why servers would still be ipv4.

section 2

Wouldn't it make sense to define the terminology before the
Introduction that uses it? i.e., should section 2 precede section 1?

"      Each NAT64 has three BIBs, one for TCP, one for UDP and one for
ICMP Queries."
	Is this necessarily true? Will this still be true when NAT64
for SCTP is added? 

"The NAT64 filters out only incoming IPv4 packets not destined to a
transport address for which there is no state in the NAT64, regardless
of the source IPv4 transport address. "
The double negative makes this difficult to parse; I think this
definition is actually incorrect or at least inconsistent with the
text in section 1.2.3; can this be rewritten to be easier to
understand?

Filtering, Address-Dependent. ditto.

Mapping or Binding: It would be good to have one term rather than two
to describe this concept. I find using two terms leads to ambiguities.
The term mapping is used in xlate to describe the corresponding fields
in an address translation, which seems slightly different than
binding, which seems to apply to addresses in a a BIB entry. and, the
definition of BIB talks about mappings rather than bindings:
BIB:  Binding Information Base.  A table of mappings; isn't it a table
of bindings?
and for 
Stateful NAT64: The NAT64 uses binding state 

"   Session:  A TCP, UDP or ICMP Query session. "
UDP doesn't have sessions. NAT64 has sessions. I recommend:
   Session:  the bi-directional flow of packets between two different
hosts. The packets may be TCP, UDP or ICMP.

I think throughout this document, the statement that "XXX might be
TCP, UDP, or ICMP" does not permit future support for other protocols,
such as SCTP.
OLD:
Each NAT64 has three session tables, one for TCP, one for UDP and one
for ICMP Queries.
NEW:
Each NAT64 has a session table for each translated protocol. An
implementation compliant to this document would have a session table
for TCP, one for UDP and one for ICMP Queries. Additional session
tables would be added to support other protocols, such as SCTP.

Stateful NAT64: In this document we also refer
      to stateful NAT64 simply as NAT64.
Is NAT64 ever used to refer to another type of NAT64? or is NAT64
always the same as stateful nat64? If it is always the same, then why
define two terms for the same concept?

dbh: Transport address: (192.0.2.15,8001) - I am accustomed to seeing
transport addresses specified as 192.0.2.15:8001; I don't know if this
a common format or just common in my experience. Is there a common way
to express transport addresses that is different than what is used
here? (I'm on a plane and don't have access to check this myself)

dbh: The "externally visible outcome" - does this document discuss
management visibility?

The convention describe in section 3 of using upper and lower case and
primes, should probably be in the terminology section.

OLD:
   A NAT64 has  
NEW:
   This specification defines 
e.g., This specification defines three Binding Information Bases

"This implementation of the BIBs" - we don't do implementation; this
is a specification. 
"ensures Endpoint-Independent Mappings in the NAT64" - no it does not;
it may ensure that Endpoint-Indepednent Mappings can be implemented,
but the fact that we specify it does ensure a non-compliant
implementation will have this.

throughout this text, "This implementation" would seem to be wrong. We
don't specify implementations; we specify specifications.

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