[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-satapati-v6ops-natpt-applicability-00
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
--- Suresh K Satapati <satapati@cisco.com> wrote:
> 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
> >
> >
> >
>
=====