Subject: Re: draft-satapati-v6ops-natpt-applicability-00

From: Suresh K Satapati <[email-masked]>
Date: Fri, 7 Nov 2003 10:29:02 -0800 (PST)

Pekka,

Lets not mislead the WG here.

From the thread:
http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html

I disagree with:

 2 b) only a more limited set of IPv6-only networks
    in the applicability statement.  These scenarios, may be
    counterproductive in the face of dual-stack deployment.

 3. The recommendation of the specific scenarios.  In the body of the
    text, some applicability was identified in two kinds of networks: the
    legacy IPv4 equipment and 3GPP.  There was no full consensus that
    going down that deployment path (the point above) would
    necessarily make sense.

As I see it, there was infact a consensus among the DT on the scenarios.
The above are more of your opinions on the draft. Pls do not represent the
DT on the above.

I did not see a major disagreement on the applicable scenarios, except
from you (as in 2b and 3) . The slight opposition was on the IMS media
translation in 3GPP scenario. Others can speak for themselves on this.

--
Suresh

On Fri, 7 Nov 2003, Pekka Savola wrote:

> Hi,
>
> On Fri, 7 Nov 2003, Brian E Carpenter wrote:
> > I think this is very useful draft and it's in good shape.
> > I'd like to see the section on 3GPP2 completed, but otherwise
> > the sooner we get this analysis published, the better.
>
> Thanks Brian.  Just in case, did you have a look at the "NAT-PT
> applicability considerations" thread, at:
>
> http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html
>
> .. which tried to provoke thoughts on several subjects relating to the
> document which might be unanimous.
>
> Do you have any further comments to make based on these?
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 11 Nov 2003 09:38:36 -0800 (PST)

Below are my comments on the draft. Overall, the document seems well done, even
though I donot agree with some of the summary conclusions as stated. 

First, I woudl like to respond to Pekka's comments (ref: 
http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html) on the draft.

1. As for definition of NAT-PT, I agree with the notion that no ALGs are
required for the basic NAT-PT operation. As such, the definition of NAT-PT
shoudl not include these ALGs. Use of DNS-ALG for address assignment is
desirable when dealing with hosts by name. FTP-ALG was included in the RFC as
an example ALG for a commonly-known application. DNS-ALG and FTP-ALG are merely
two ALGs that would be useful.

I believe, the updated version of the RFC could be explicit about the
definition.

2. pekkas comments in item 2 (in 
http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01271.html)
seem rather opinionated - not keeping transition scenarios in mind.

Specifically, what prompts you to make comments like, "These scenarios, may be
counterproductive in the face of dual-stack deployment."? The next sentence
reads, "if the deployment of IPv6-only networks were decreed out of scope, some
felt that no NAT-PT applicability statement would need to be published in the
first place as it would not be applicable anywhere". This is yet another note
that seems to be espousing religion. Who is decreeing that deploment of
IPv6-only networks to be out of scope? Is it out of scope for this WG or for
the Ipv6 deployers? The charter of the WG reads otherwise.

3. The item 3 - What are the issue you see with the deployment path for the
scenarios discussed?

------------------------------------------------------------------------------

Below are my initial comments on the draft.

1. I believe, the RFC shoudl be updated and advanced to be a draft standard.
teh updated RFC should include a) precise definition of NAT-PT, b) the
applicability  scenarios, c) Recent NAT and IPsec documents (NAT-MIB,
MIDCOM-MIB, NAT-Traversal etc.) that augment NAT-PT 
d)deployment/inter-oprability experience from vendors. In other words, I
believe, tis document itself should be a section of the DS update of the RFC
2766.

2. Section 3.1 - You should refer Midcom work here. ALGs can be moved out of
the NAT-PT with the support of Midcom protocol. 

3. Section 3.2 - Scalability - There are proposals that do address the
scalability issue (refer Park's draft kere). 

4. section 4.2.1 - proxying will require Client applications to change in
several cases. Several applications do not have proxy servers. Most Proxy
servers are for TCP based apps only. All in all, this seened like hand-waving
to me, without a detailed coverage of limitaton of requiring/using proxies.

5. Summary - The sentence "In no case should NAT-PT be viewed as a generic
   solution for IPv6/IPv4 transition in an IPv6-only network." seemed totally
out of place and a non-sequitor to the rest of the document.

More later...

regards,
suresh

> translation in 3GPP scenario. Others can speak for themselves on this.

=====

---

From: Suresh Satapati <[email-masked]>
Date: Tue, 11 Nov 2003 12:00:48 -0800 (PST)

Suresh,

My responses inline, only to comments on the draft.

a) needs discussion and consensus of WG. I agree with the intention.

> believe, tis document itself should be a section of the DS update of the RFC

Same as above.

> the NAT-PT with the support of Midcom protocol.

I agree in principle. But I felt this is beyond the scope of this
document.

> scalability issue (refer Park's draft kere).

Out of scope. We are not solving problems in this document.

> to me, without a detailed coverage of limitaton of requiring/using proxies.

Agreed. We could use a little more wording here.

> out of place and a non-sequitor to the rest of the document.

This comes from the general agreement within the v6ops WG that dual-stack
deployment is the way to go as long as you want to talk v4.