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

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

Hi,

I have reviewed portions of draft-ietf-behave-v6v4-xlate-stateful-09
and have comments.
(as individual contributor)

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?

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.

Hope this helps,

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 25 Mar 2010 02:46:14 +0100

Hi David,

thanks for the review, please see replies below...

> (as individual contributor)
done

> "the normal NAT manner" - is there a normal NAT manner?
i have added a reference to RFC3022 where napt is described.

> mention why servers would still be ipv4.

rephrased as:

Due to IPv4 address depletion, it is likely that in the future, the new
clients will be IPv6-only and they will want to connect to the existent IPv4-only servers.

> Introduction that uses it? i.e., should section 2 precede section 1?
right, we had this debate in the WG several times and the conclusion is 
that the terminology section clearly divides the informational part from 
the normative part of the document, hence its location.

> 	Is this necessarily true? Will this still be true when NAT64

BIBs are conceptual data structures, so, an implementation can do this 
in a different way. This is refelcted in the following text:

The actual division of the information into six tables is done in order 
to ease the description of the NAT64 behaviour. NAT64 implementations 
are free to use different data structures but they MUST store all the 
required information and the externally visible outcome MUST be the same 
as the one described in this document.
> text in section 1.2.3; can this be rewritten to be easier to
right, the double negation is wrong.
rephrased as:

<t hangText="Filtering, Endpoint-Independent:"> The NAT64 only filters
          incoming IPv4 packets destined to a transport address for
          which there is no state in the NAT64, regardless of the source
          IPv4 transport address. The NAT forwards any packets destined to
          any transport address for which it has state.
          In other words, having state for a given transport address is 
sufficient
          to allow any packets back to the internal endpoint. See <xref
          target="RFC4787"></xref> for the definition of the different types
          of filtering in IPv4-to-IPv4 NATs.</t>

> Filtering, Address-Dependent. ditto.
done

> binding, which seems to apply to addresses in a a BIB entry.
right, but otoh, the behave terminology has used mappings, and that is 
why we end up with these two terms used. We use mapping to refer to the 
well know terminology defined in behave, such as endpoint independet 
mapping and we use binding when we refer to the state stored in the nat64

>   and, the

right, changed that
> Stateful NAT64: The NAT64 uses binding state
this is correct, right?

> "   Session:  A TCP, UDP or ICMP Query session."
ok, i have changed to this text, but removed the bidirectional, as per 
Magnus comment that UDP sessions don't have to be bidirectional, ok?

> tables would be added to support other protocols, such as SCTP.
done

> define two terms for the same concept?

NAT64 is defined in the framework document as the general translation of 
sesions initiated from the v6 side and stateful nat64 is a particular 
instance of that, that requires state for that. for ease the reading we 
avoid to use the stateful in front of nat64 all the time.
> The "externally visible outcome" - does this document discuss
no, it doesn't afaict. i guess that the mib for the nat64 device should 
be defined later on (if that is your question, but i am not very well 
versed in mibs)

> primes, should probably be in the terminology section.
mmm, i am uncertain about this one, it is more notation than termonilogy 
to me, so i am not sure

> e.g., This specification defines three Binding Information Bases

don't understand this one, could you clarify?
> "This implementation of the BIBs" - we don't do implementation; this

changed

> implementation will have this.
right, rephrased as

If the BIBs are implemented as specified in this document, it results in 
Endpoint-Independent Mappings in the NAT64.

> don't specify implementations; we specify specifications.
went through the instances of implementation and verified its proper 
usage (changed some of them)

Regards, marcelo

> Hope this helps,
>
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>