Subject: Re: draft-palet-v6ops-proto41-nat-01.txt

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 20 Oct 2003 12:47:24 +0800

Hi Rute,

Finally I've got some time to update this document. I'm posting a new draft in a couple of hours.

I've tried to reply to your comments (also in-line in your email, but you need to look into the new draft to match them).

Regards,
Jordi

----- Original Message ----- 
From: "Rute C. Sofia" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 19, 2003 1:37 AM
Subject: Re: draft-palet-v6ops-proto41-nat-01.txt

> Hi Jordi,
>
> comments on the draft:
>
> - abstract, 3rd paragraph "this behavior provides a big
> opportunity...when is not possible to offer native IPv6 or 6to4"
> *Suggestion: change this paragraph to something such as" this is a
> fallback option only to be used either when there
> is
> no possibility of offering native IPv6, or 6to4 (reference here)"

This reference is there already.

>
> - Introduction
> * the first 2 paragraphs are a copy of the abstract. My suggestion would
> be to take them out, and re-write this section...however, I believe that
> the abstract should contemplate some info presented such as: not only that
> this is a temporary fallback solution (as stated), but also, that this is
> only aplicable to the subset of NATs that allow protocol 41.

I rewrite it in part. As the number of boxes that support it seems quite high, I think is more relevant in the Applicability
section.

>
> - section 3., NAT types.
> *This section is a bit confusing; I believe that you are following the
> nomenclature
> presented in rfc 2766; Basic is the "Traditional" type, right? Basic is
> confusing, given that NAPT-PT (I believe that's what you mean in section
> 3.2) is a form of the traditional NAT-PT;
> * Also, in 3.2. , you say "...This can also be combined with basic NAT".
> So I'm lost here.
> * Isn't 3.4 a subset of 3.3?

No, as indicated in the document, it comes from RFC2663.

>
> - Section 4., Applicability
> *1st paragraph states a problem with NAT, not IPv6+NAT. Now, the paragraph
> seems to imply that this is due to IPv6 and NAT.

I think now is more clear.

> * 5th paragraph, "This configuration can be a default one...". Even though
> you speak of private addresses, this option is a bit limiting, isn't it?
>

No, a lot of NAT boxes, come with a default configuration, so why not proto41 also ?

> *6th,7th paragraph are out of context in this section; should be moved to
> the intro.

I agree un part only ;-)

>
> - Section 5.
> * you say that most vendors support proto-41. How many were checked? which
> percentage support ip proto-41 and how many provided bidirectionality?
> This would be interesting data to be include.

I put some numbers, but we need to understand that the survey we did is not an "universal" one, that's why I thought is better don't
put the figures initially. Anyway, considering that some big manufacturers replied, and that they have a big portion of the market
...

> * 3rd paragraph. It is a fact that 6to4 and proto-41 can coexist in the
> same box. But the question is? Why would they, when you claim that the
> current solution is simply a "temporary fallback" one, when there is
> either no 6to4 or native support? This paragraph contradicts the abstract,
> the intro and the previous one.

No, isn't contradictory, and it was requested by somebody in Vienna. To clarify it, I put an example with mobile users.

>
> Rute
>
>
>
>
>
>
>
> On Sun, 3 Aug 2003, JORDI PALET MARTINEZ wrote:
>
> > Hi all,
> >
> > The revision of the document indicated in the subject, has been published a few days ago, as indicated below.
> >
> > I will be happy to get new comments from the WG.
> >
> > Regards,
> > Jordi
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> > Title : Forwarding Protocol 41 in NAT Boxes
> > Author(s) : J. Palet et al.
> > Filename : draft-palet-v6ops-proto41-nat-01.txt
> > Pages : 12
> > Date : 2003-7-31
> >
> > Some NAT boxes/routers allow the establishment of IPv6 tunnels from
> > systems in the private LAN (using private IPv4 addresses) to routers
> > or tunnel servers in the public Internet.
> > As far as we know this is not a common way of use IPv6 tunnels; the
> > usual way is to finish the tunnel directly in a device with an IPv4
> > public address.
> > This behavior provides a big opportunity to rapidly deploy a huge
> > number of IPv6 nodes and networks, without the need of new transition
> > mechanism. This option is very important to facilitate the IPv6
> > deployment.
> > This document describes this behavior and provides hints that should
> > be applied in the NAT boxes and tunnel brokers to facilitate it.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt
> >
> >
> > *****************************
> > Madrid 2003 Global IPv6 Summit
> > Presentations and videos on-line at:
> > http://www.ipv6-es.com
> >
> >
> >
>

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.