Subject: draft-huitema-v6ops-teredo-03.txt

From: Margaret Wasserman <[email-masked]>
Date: Sun, 5 Dec 2004 10:47:09 -0500

Hi Eric, Henrik, Karen, Francis, Markku and Jonathan,

There is a new version of the Teredo draft available at:

http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-03.txt

Could you check whether this version addresses the issues that you 
raised during IETF LC?  It would be best if you could review this 
document and return any feedback by this Thursday, 9-Dec-04.

If there are no further objections, I will place this draft on the 
IESG agenda for consideration on our 16-Dec-04 telechat.

Thanks!

Margaret

---

From: "EricLKlein" <[email-masked]>
Date: Sun, 5 Dec 2004 18:11:06 +0200

Margaret,

I am still a little uncomfortable about the fact that there is no explicit
statement that "teredo is needed because NAT was deprecated in IPv6 so
teredo is needed to allow IPv6 nodes to communicate with IPv4 nodes in a
domain that utilizes NAT."

This is still true in section 3.2.4 Automatic sunset.
Some how this whole section scares me as it seems to imply that there is a
way to turn an IPv4 NAT into an IPv6 Router while maintaining the NAT like
functionality. As stated above, NAT is not part of IPv6 (NAP is but is still
not mentioned in this document).

Eric
----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>
Cc: <[email-masked]>
Sent: 05 December, 2004 5:47 PM
Subject: draft-huitema-v6ops-teredo-03.txt

---

From: Alain Durand <[email-masked]>
Date: Sun, 05 Dec 2004 21:52:05 -0800

On Dec 5, 2004, at 8:11 AM, EricLKlein wrote:

> statement that "teredo is needed because NAT was deprecated in IPv6

I have never seen any such statement in any RFC defining IPv6.

>  so

3 points:

a) nothing will ever prevent anyone from inventing/using IPv6 NAT one 
day

b) when the v4 NAT gets upgraded to do also v6, it still does v4 NAT...
      this functionality does not go away...

c) The only (minor) point I have with section 3.2.4 is with the 
sentence:
"upgrading the
    Internet connection used by the NAT to a native IPv6 service,"

If the 'upgraded' NAT provides v6 connectivity via a configured tunnel
(maybe using the tunnel set up protocol we want to design in v6tc)
teredo will also detect it (by seeing a native RA on the internal 
network)
and turn itself off.

So I would suggest to simply remove the work 'native' from the above 
sentence.

	- Alain,

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 6 Dec 2004 10:21:10 +0200

From Alain

> I have never seen any such statement in any RFC defining IPv6.
The very conecpt of unique addressable addresses negates NAT. As it is there
will be problems created as people try to use the 10 net addresses fro
mtheir IPv4 network on the IPv6 network as those addresses going to pop up
in lots of places. Also, there was a large discussion on depreciating NAT
last year. I was against depreciating as too many people would resist. This
was why draft-vandevelde-v6ops-nap-01_draft1.txt was written.

> a) nothing will ever prevent anyone from inventing/using IPv6 NAT one
You are correct, explicit RFCs stating that NAT is not permitted will have a
limited effect, and as you said these have not been published. RFC 3879
Deprecating Site Local Addresses  explains why private addresses (like the
10 net) are not good and why they should not be used.

>       this functionality does not go away...

That is correct, the concept goes away. Unique addressable addresses and NAT
are mutually exclusive concepts.

> So I would suggest to simply remove the work 'native' from the above

The point is that "native IPv4" vs "native IPv6" was added because of the
working group's decision to do away with NAT. We had a defined "private"
address space in the original IPv6 RFCs, but this was removed in RFC 3879
Deprecating Site Local Addresses. Given this the WG has been working towards
preventing IPv6 NAT.

Eric

---

From: Vincent Jardin <[email-masked]>
Date: Mon, 06 Dec 2004 12:51:31 +0100

About the workaround for the symetric NATs:

>5.2.10 Working around symmetric NAT
>   
>[...]   
>   In many cases, it is possible to work around the limitations of
>   these NAT by explicitly reserving a UDP port for Teredo service on a
>   client, using a function often called "DMZ" in the NAT's manual.
>   This port will become the "service port" used by the Teredo hosts.
>   The implementers of Teredo functions in hosts must make sure that
>   the value of the service port can be explicitly provisioned, so that
>   user can provision the same value in the host and in the NAT.
>   
>   The reservation procedure guarantees that the port mapping will
>   remain the same for all destinations. After the explicit
>   reservation, the qualification algorithm in section 5.2.1 will
>   succeed, and the Teredo client will behave as if behind a "cone
>   NAT".
>
We have been testing this for a long time, see the last section from
  http://www-rp.lip6.fr/teredo/
It is just a workaround, but it is not enough for many reasons.

In fact, the proper solution would be to allow Teredo traffic even when 
a symmetric NAT is detected by the client.
Then, all these Teredo packets, that are sent to the hosts behind the 
symmetric NAT, must be forwarded thru their Teredo relay.
I understand that it will lead to a lot of traffic, but it should not be 
so much (about 24 % of the NAT do not support hole punching) because 
there are few symmetric NATs, however it is a simple solution that helps 
Teredo to be fully reliable.

Best regards,
  Vincent

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 6 Dec 2004 07:16:21 -0500

Hi Eric,

I am not quite sure how to respond to your post, because I am not 
sure that parts of it are applicable to Teredo at all...

>domain that utilizes NAT."

While we can certainly hope that IPv6<=>IPv6 NAT is never necessary, 
it is not possible for the IETF to "deprecate NAT in IPv6".  If 
administrators ever have a reason to use NAT in IPv6, there is 
nothing we can do to stop them.

Or are you talking about NAT-PT (Network Address Translation with 
Protocol Translation) that translates between IPv4 and IPv6?

If you are talking about NAT-PT, then I still don't understand your 
point.  Teredo allows access to the IPv6 Internet for IPv6-capable 
nodes that are located behind an IPv4 NAT on networks where their ISP 
does not provide native IPv6 service.  Those nodes cannot tunnel to 
the IPv6 Internet using other defined methods (i.e. 6to4) because 
those methods don't work through an IPv4 NAT.  Teredo is merely a 
mechanism to set-up the tunnel through an IPv4 NAT, so that IPv6 
connectivity can be obtained.

Teredo really doesn't have anything to do with IPv6<=>IPv6 NAT or NAT-PT.

>not mentioned in this document).

In time, I actually expect that there will be home gateways that 
provide IPv4 NAT and IPv6 routing with a stateful firewall for 
protection.  At least, I hope so.  If I have a router like that _AND_ 
my ISP offers native IPv6 connectivity, then I won't need Teredo. 
That's what the sunset clause is all about... Why is that scary?

Margaret

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 6 Dec 2004 14:37:10 +0200

Margaret,

My concerns are based on the out come of one of the IETF meetings last year
when it was decided by the working group, and then confirmed by the mailing
list, that privet addresses (FEC0 etc) were "a bad thing" and were removed
from IPv6.

At the time I argued that private addresses would need to be used or we
would have another case of address space being co-opted like was eventually
done in RFC 1918. This long discussion on the list resulted after I
responded to a request for those private addresses during the meeting (which
I had not attended). After the flame war ended there was a vote in the WG
mailing list to depreciate private address spaces.

Eventually this lead to the various drafts about doing away with NAT (for
example draft-vandevelde-v6ops-nap-01).

My concerns with this teredo document is that it seems to indicate that
there may be a way to provide NAT on a private address space in IPv6. All I
am asking for is wording that shows that the NAT is still IPv4 and is not
IPv6 after the router is "upgraded" and not that there is a transition from
IPv4 to IPv6. My understanding is that this is a work around to connect IPv6
hosts to IPv4 hosts that "NATted". This is fine. It makes sense to me as
there are going to be IPv4 networks around for quite a while and the
interconnection is necessary. But please don't create false impressions that
private address spaces or NAT will exist in the IPv6 space, or change the WG
ruling and put private addresses and NAT back. I am sure that there are
people who would prefer it that way (mostly network administrators) and
those who don't want to bring them back (mostly hardware and software
developers).

All I want is a consistent message to go out from this WG as to the status
of private addresses and NAT.

Eric

----- Original Message ----- 
From: "Margaret Wasserman"

---

From: Tim Chown <[email-masked]>
Date: Mon, 6 Dec 2004 12:56:23 +0000

> of private addresses and NAT.

I'm confused from what you write Eric.

Private addresses exist in IPv6, as ULAs or CA ULAs.  "Site locals" were
deprecated, but ULAs are different (reducing the ambiguity issue) and
CA ULAs different again (in theory removing the ambiguity issue).

NAT could be used for IPv6, but anyone doing so is shooting themselves in the
foot and should just stick with IPv4+NAT.

Many sites will use IPv4+NAT alongside IPv6 (without NAT).  They can then
use IPv6 for more advanced p2p and inter-site applications, and use IPv4
for legacy apps like mail and web browsing.

Tim

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 6 Dec 2004 15:20:03 +0200

Tim,
> CA ULAs different again (in theory removing the ambiguity issue).

A ULA is not truly the same as private addresses. Private addresses are
those "un-routable" addresses codified in RFC 1918 for IPv4 and were
originally defined as FEC0:: through FEC8:: in IPv6. These were basically
removed because they were not unique. ULAs by defination are unique (hence
that first U).

> foot and should just stick with IPv4+NAT.

Agreed, not to mention that they would be going against the spirit of unique
addressable.

> for legacy apps like mail and web browsing.
I agree with this and I anticipate that it will remain this way for may
years to come.
Eric

---

From: Tim Chown <[email-masked]>
Date: Mon, 6 Dec 2004 13:27:35 +0000

> removed because they were not unique. ULAs by defination are unique (hence

So why do we then have CA ULAs?  ;)

ULA space is just private address space where bets are off on ambiguity,
but mainly if your "random"" number generator throws up 40 or 41 zeroes...
as many will.

Tim

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 7 Dec 2004 11:42:02 +0200

From: "Rémi Després"
>  2. NAT definition
>
> The document neither includes a definition of NATs, nor refers to a
document
> which does it.
>
> It would help if the scope of NATs considered in the document would be
> concisely delimited, e.g. with the definition:
>
> "NATs referred to in this document are the IPv4-only mechanism which, at
> least for some restricted applications, provide access to the IPv4 global
> address space from IPv4 private address spaces, and which use for this
> stateful address translation and possibly stateful port number
translation."
This text would resolve my concerns as well.

Eric

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Dec 2004 19:52:41 +0100

Hi,

Three points:

1. Teredo Client definition
  The current definition "A node that has some access to the IPv4 Internet
and wants to gain access to the IPv6 Internet" is IMHO much too large.
  It could advantageously be become something like:
  "A node that has some access to the IPv4 Internet via an IPv4-only node
where NAT is operational, and that wants to gain access to the IPv6
Internet"

 2. NAT definition
  The document neither includes a definition of NATs, nor refers to a
document which does it.
  It would help if the scope of NATs considered in the document would be
concisely delimited, e.g. with a definition like:  "NATs referred to in this
document are IPv4-only mechanisms which, at least for some restricted
applications, provide access to the IPv4 global address space from some IPv4
private address spaces. They use for this stateful translation of addresses
and possibly of port numbers ."

 3. Page numbers.
  In the table of contents page numbers exceed by 1 the appropriate values.
Fixing it would improve the document.

Rémi
(These points were made in a mail already answered by Eric Klein but, sent
from an unregistered address, didn't appear in  the mailin list.)

----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
Sent: Sunday, December 05, 2004 4:47 PM