Subject: (ngtrans) comments on NATPT 04

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 21 Jan 1999 00:54:26 +0900

Here are our comments on NATPT 04:

(1) The figures

The figures in the draft are a little bit ambiguous.

                           ^
                           |
                  [IPv6-B]-+
                           |                  +==============+
                  [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
                                |             +==============+
                         (pool of v4 addresses)

- If "IPv4 network" refers to "IPv4 Internet", it should be modified so.

- What does "^" mean? We think this is not necessary.
            "|"

(2) Early or late?

If our understanding is correct, the draft is discussing the early
stage of the transition(not the late stage). Anyway, this should be
clarified.

(3) UDP checksum 0

NATPT has the same problem as SIIT as we reported on this
list. Addressing the problem is probably a SIIT's job and is outside
the scope of NATPT.

--Kazu and Sumikawa

---

From: [email-masked] (Pyda Srisuresh)
Date: Thu, 21 Jan 1999 07:30:51 -0800 (PST)

> The figures in the draft are a little bit ambiguous.
Not necessarily. I believe, the diagram is fine in that regard.

> - What does "^" mean? We think this is not necessary.

OK. No problem.

> stage of the transition(not the late stage). Anyway, this should be

Why is it necessary to state that? NAT-PT is simply a transition tool
that may be applicable at any point in time. (Ref: Section 7.0 - 
Applicability Statement)

> list. Addressing the problem is probably a SIIT's job and is outside

Note, We do state (in section 5.3) that NAT-PT should re-evaluate 
UDP checksum due to changes in V6 and V4 addresses. NAT-PT is stateful 
and should be able to reassemble fragments.

> --Kazu and Sumikawa

cheers,
suresh

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 22 Jan 1999 14:54:31 +0900

From: [email-masked] (Pyda Srisuresh)
Subject: Re: (ngtrans) comments on NATPT 04
Date: Thu, 21 Jan 1999 07:30:51 -0800 (PST)

> that may be applicable at any point in time. (Ref: Section 7.0 - 

I missed section 7, sorry. I like to move this section onto the head
(e.g. between 1 and 2). If you do so, the figures will become
unambiguous.

> and should be able to reassemble fragments.

I re-read it but I think this section is not easy-to-understand. You
refers to NAT's adjustment algorithm. 

NAT's algorithm is certainly *adjustment*, not re-calculate. It's fine
for NAT, since UDP checksum 0 is UDP checksum 0 in IPv4-to-IPv4
conversion.

However, in IPv4-to-IPv6 conversion, UDP checksum 0 is a special case.
Adjustment doesn't work.

Our points for readability are:
	- You should carefully define "re-calculate" and "adjustment".
        - Explicitly state the special case of UDP checksum 0.

--Kazu

---

From: [email-masked] (Pyda Srisuresh)
Date: Fri, 22 Jan 1999 06:28:09 -0800 (PST)

> (e.g. between 1 and 2). If you do so, the figures will become

We left the applicability statement at the end because we felt that
the reader would be able to better appreciate the statement after
reviewing the proposal.

However, we could make reference to the applicability statement in the 
"Introduction" section.

> However, in IPv4-to-IPv6 conversion, UDP checksum 0 is a special case.
Good Point.

>         - Explicitly state the special case of UDP checksum 0.
OK.

cheers,
suresh