Subject: [BEHAVE] 2nd WGLC, draft-ietf-behave-v6v4-xlate-stateful-08

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Feb 2010 11:17:39 -0800

** We need at least 5 reviewers to tell us this document is ready 
** for submission to IESG.  Please email [email-masked] 
** with a subject line containing the document name, and "ready 
** to submit to IESG" or "not ready to submit to IESG" in the 
** message body.  If not ready to submit, please propose new text.

This email starts the 2nd WGLC for draft-ietf-behave-v6v4-xlate-stateful-08,
ending in one week (Friday, February 19).  For reference, the first WGLC was
for draft-ietf-behave-v6v4-xlate-stateful-07.

Differences between 07 (first WGLC) and 08 (2nd WGLC) are:

http://tools.ietf.org/rfcdiff?url1=draft-ietf-behave-v6v4-xlate-stateful-07&ur
l2=draft-ietf-behave-v6v4-xlate-stateful-08.txt

-d

---

From: Dave Thaler <[email-masked]>
Date: Mon, 15 Feb 2010 20:07:19 +0000

Just some editorial nits...

Section 1.2.1:
> Using DNS64, an IPv6 client obtains an IPv6 address that embeds the

Since stateful NAT64 has no hard dependency on DNS64, suggest:

> Using a mechanism such as DNS64, an IPv6 client obtains an IPv6 address that embeds the
        ^^^^^^^^^^^^^^^^^^^

Point being that if some other mechanism is used rather than DNS,
NAT64 will still work.  The last paragraph of Section 1.2.2 is
good, which already makes this point.

Section 1.2.2:
> uses the Well-Know Prefix 64:FF9B::/96 defined
                ^^^^
> local name server uses the Well-Know prefix 64:FF9B::/96 to create
                                  ^^^^

s/Know/Known/

Section 1.2.3:
> packets are not specific to the NAT64 and therefore is not described
                                                      ^^
s/is/are/

Section 2:
> pair.  Used to translate the addresses and ports/Query Identifiers

s/Query/ICMP/

Section 3:
> implementations are free use different data structures but they MUST

s/free use/free to use/

Section 3.5.1:
> The NAT64 sets (or resets) the timer in the Session Table Entry to  
> maximum session lifetime.  
 ^

Insert "the"

Section 3.5.1.1:
> (this behavior is  
> recommended in REQ 3-a of [RFC4787])

s/this/This/
Add period before ")"

Section 3.5.2.1:
> and forwards packet in both directions for a short period of time

s/packet/packets/

Section 5.1:
> Any protocols that protect IP header information is essentially

Either s/protocols/protocol/
Or s/is/are/

Section 5.2:
> targeting the internal network.  To avoid these type of abuse, some  
> NAT64 MAY keep track the sequence number of TCP packets in order to

Replace "these type" with either "this type" or "these types".
s/some NAT64/a NAT64/
Replace "keep track" with either "track" or "keep track of"

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Wing
> Sent: Friday, February 12, 2010 11:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] 2nd WGLC, draft-ietf-behave-v6v4-xlate-stateful-08
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Kentaro Ebisawa <[email-masked]>
Date: Sun, 21 Feb 2010 19:38:11 +0900

Hi,

I've reviewed the draft and here's some comments.
Most of them are editorial nits and other part of the doc seems good to me.

* Section 1.2.2.
192.0.2.1. should be 192.0.2.1 (don't need the last period) in 3 places.
[Page 9]
>          address in the packet and (192.0.2.1.,80) as destination
[Page 10]
>       transport address (203.0.113.1,2000) and source transport address
>       (192.0.2.1.,80).
[Page 10]
>          transport address in the packet.  Note that 192.0.2.1. is

* Section 2.
[Page 12]
>   Filtering, Endpoint-Independent:  The NAT64 filters out only incoming
>      IPv4 packets not destined to a transport address for which there
>      is not state in the NAT64, regardless of the source IPv4 transport
          ^^^
s/not/no/

>      communicate using sessions that hairpin through the NAT.  Hairpin
>      packets packets can be either TCP or UDP.  More detailed
       ^^^^^^^^^^^^^^^
delete extra "packets"

* Section 3.5.2.2. *** ESTABLISHED ***
[Page 30]
>   If the lifetime expires then the NAT64 SHOULD send a probe packet (as
>   defined next) to al least one of the endpoints of the TCP connection.
                     ^^
s/al/at/

* Section 3.5.2.3.
[Page 31]
>      If there exists some other BIB entry containing S' as the IPv6
>      address and mapping it to some IPv4 address T, then use SHOULD T
>      as the IPv4 address.  Otherwise, use any IPv4 address of the IPv4
I think "then use SHOULD T as the IPv4 address."  should be
"then T SHOULD be used as the IPv4 address."

* Section 3.5.3.
[Page 33]
>      does not exist, the packet is dropped.  An ICMP error message MAY
>      be sent to the original sender of the packet, unless the discarded
>      packet is itself an ICMP error message.  The ICMP error message,

Since this part is talking about how to process incoming ICMPv4 Query packet,
I think "unless the discarded packet is itself an ICMP error message."
is redundant and can be deleted.

[Page 34]
>      discarded.  If the packet is discarded, then an ICMP message MAY
>      be sent to the original sender of the packet, unless the discarded
>      packet is itself an ICMP message.  The ICMP message, if sent, has

As mentioned above, "unless the discarded packet is itself an ICMP message"
can be deleted.

Also, "The ICMP message, if sent," should be "The ICMP error message, if sent,".

* Section 3.5.4.
[Page 35]
>         If we note n the length of the prefix Pref64::/n, then n MUST
>         the less or equal than 96.  If a Pref64::/n is configured
          ^^^^^^^^
s/the less or equal than 96/be less than or equal to 96/

* Section 3.8.
>   If the destination IP address is an IPv4 address assigned to the
>   NAT64 itself then the packet is a hairpin packet.  Hairpin packets

Just to be more clear, I think we should explicitly mention this is
talking about IPv4 address of the translated packet. For example,

 If the destination IP address of the translated packet is an IPv4 address assigned to the ...

-- 
Kentaro Ebisawa <[email-masked]>

On Fri, 12 Feb 2010 11:17:39 -0800

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 21 Feb 2010 13:03:20 +0100

thanks for the review.

I don't see any difficutly incorporating all the proposed changes.

I will include them in the next version

Regards, marcelo