Subject: 6to4 vs forwarding IP proto41 in NAT

From: Alain Durand <[email-masked]>
Date: Tue, 15 Jul 2003 08:01:45 -0700

A NAT box could do the following when receiving an IPv6 packet
encapsulated in IPv4 with proto 41:

If IPv6 dst does not belong to the local 6to4 /48 prefix, forward 
internally,
else decapsulate.

Why will will not work?

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Tue, 15 Jul 2003 16:08:50 +0100

The advantage for plain proto41 forwarding is that you don't have to
decapsulate for it to work - just pass it on :)  The NAT web config
screen can just have a checkbox to forward proto41 and a field to
specify the RFC1918 address to forward it to.

But agreed if the vendor is implementing 6to4, there is no reason why they
couldn't choose to do this.

I wouldn't like to lose the ability to run a tunnel broker client inside my
network (for a host or network broker client) because of 6to4 support on
the router (which I applaud - and I'd be interested to know which vendors
are implementing it... Christian?)

Of course ideally we want IPv6 natively, but...

Tim

---

From: Marcin Michalak <[email-masked]>
Date: Tue, 15 Jul 2003 17:30:53 +0200

Hello,
 Forgive me if this is already done: It seems to me that we need to 
have clear recommendations with priorities what solutions are to be 
used. Something like Margaret was saying: native IPv6, then ...

 What also I see that many things are becoming obvious for us, but 
may not be so obvious for the others. So in my opinion it should be 
clearly stated in all transition documents that native IPv6 is the 
best and recommended solution.
 Have a good time in Vienna (or somewhere else :-)),
  Marcin

----------------------------------------------------------
Marcin Michalak		Research Engineer
Mobile: +41 79 330 83 51	Telscom AG

---

From: Carlos Friacas <[email-masked]>
Date: Tue, 15 Jul 2003 16:45:08 +0100 (WEST)

>  Have a good time in Vienna (or somewhere else :-)),

I also strongly second this view.
This discussion is about easying SOHO and HOME deployment, but it seems to
me that the quality involved with using this mechanism might turn users
against IPv6 usage.
The focus should be to:
a) ISPs requesting addresses
b) getting the BGP sessions up and running
c) ISPs going dual-stack on their backbone
d) ISPs extending native IPv6 to their customers "door" (SOHO *and* HOME)

Again -- you All -- have a good time in Vienna.

Regards,

./Carlos                                                "Networking is fun!"
--------------         [http://www.ip6.fccn.pt]           http://www.fccn.pt
<[email-masked]>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup
F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167
                [ See me @ h323:videoconf05.fccn.pt]
  "Internet is just routes (125953/461), naming (millions) and... people!"

---

From: Tim Chown <[email-masked]>
Date: Tue, 15 Jul 2003 16:47:29 +0100

That's the ISP scenarios document, not unmanaged :)

Tim

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 15 Jul 2003 23:58:59 +0200

Agree, it should work.

Regards,
Jordi

----- Original Message ----- 
From: "Alain Durand" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 15, 2003 5:01 PM
Subject: 6to4 vs forwarding IP proto41 in NAT

> If IPv6 dst does not belong to the local 6to4 /48 prefix, forward 

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

---

From: HELENA RUTE SOFIA <[email-masked]>
Date: Wed, 16 Jul 2003 03:19:40 -0400 (EDT)

One thing that is really puzzling me about this draft is: do we really
need this?? There are currently two options that have "more" priority in
terms of implementation, i.e., v6 and 6to4...so why try to create a
document on something that is currently assumed to work, and that is only
used as a "hack", when one of the other two is not working?? Why do we
need a document on this?

Rute

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 16 Jul 2003 09:40:33 +0200

This is exactly what I already reflected in the new version of the draft.

I will wait for more inputs before publish it.

Regards,
Jordi

---

From: "Rute C. Sofia" <[email-masked]>
Date: Wed, 16 Jul 2003 07:41:41 -0400 (EDT)

Jordi,

> I will wait for more inputs before publish it.

I understand the point of your document, but really do not see a place for
it... It's not so much a question of the "mechanism" (it is here; it is
used
sometimes), but really, a question of the purpose of the document.
There has to be a clear purpose (and maybe I'm missing it), otherwise,
we just end up adding more entropy...Can you please answer clearly the
following questions:

1) does the document introduce a *significant* contribution to current
deployment status?
2) if something should be forced to vendors, that should be either ipv6 or
6to4 ;-). Why impose a third option, given that only a subset of scenarios
will *possibly* gain with it ??

And, a bit out of scope in technical terms...out of curiosity, if you
already have an "updated" version of the draft (updated in which sense??),
why didn't you present it yesterday?

thanks,
rute

---

From: Tim Chown <[email-masked]>
Date: Wed, 16 Jul 2003 12:53:29 +0100

There are two uses for the document:

1.  To alert people to the (to some obvious) protocol41 "trick" to carry an
    IPv6 tunnel into a NAT network.   This is very handy for early adoptors
    (the IPv6 geeks).    It is not a long-term solution.

2.  To alert NAT vendors to the fact that if they make what should be a
    simple mod to their formware - *if* they are not already supporting IPv6
    in some other way e.g. 6to4 or better - they can enable their geek
    customers to use IPv6 at home.

I think it's a useful informational document, so long as the "trick" is
just seen as an early adoptor/last resort mechanism.

It is a mechanism we use a lot btw.

tim

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 16 Jul 2003 14:02:27 +0200

Rute,

1) I don't think the purpose of the IETF documents/work is only for *significant* contributions to current deployment status, and I
explained this in the yesterday session. The work describes the situation that isn't documented (but used).
2) If the vendors don't want to use native or 6to4, and we don't have a backup option, we miss the chance to help the people to
connect to IPv6 in a way that we know is possible. My survey show that the subset of "scenarios" is big enough to be very relevant.

The update has been done yesterday night, with the inputs received during the meeting, and I will wait some more days for additional
inputs before an "official" publication.

Regards,
Jordi

---

From: Carlos Friacas <[email-masked]>
Date: Wed, 16 Jul 2003 13:35:28 +0100 (WEST)

>     (the IPv6 geeks).    It is not a long-term solution.

If it is documented (approved), it might be considered a long-term
solution by some people... because it would classify as an "hack"
documented by the ietf!

And moreover, some ipv6 projects/sites already document this. Euro6ix is
an example.

>     customers to use IPv6 at home.

Again, focusing on "geek customers" will not take IPv6 usage anywhere.
IPv6 deployment (and usage) will only rely on *everybody* using it
(sometimes), without having to know IPv6 is there.

Vendors work based on demand: if you have 5 or 50 geeks sending emails,
they do nothing, if some big enterprise requests it, they will try
to comply promptly.

> It is a mechanism we use a lot btw.

...but certainly wish not having to do it... ;-)))

Regards,

---

From: "Rute C. Sofia" <[email-masked]>
Date: Wed, 16 Jul 2003 08:44:55 -0400 (EDT)

Tim,

> It is a mechanism we use a lot btw.

I completely agree with the sentence above, and that was stated in my
previous mail.

But, Point 2. above says it all: "*if* they are not already supporting
IPv6 in some other way e.g. 6to4 or better..."...

Given that the solution that it's trying to be "imposed" is a temporary
solution, not compatible with the other possible ones, I do not see a
point in creating a document about it. I do understand that it's in use
;-P, but an individual draft about this does not seem really useful, in
my viewpoint. Much less a WG document on this...
Maybe I'm completely wrong here, but again, what I'm
transmitting is that I don't
see the need to document a temporary solution, simply arguing with the
purpose that vendors should give this third option...which is already in
use...there is so much work to be done regarding v6ops, that my fear is
that this document just ends up in simply adding entropy...

Rute

---

From: "Rute C. Sofia" <[email-masked]>
Date: Wed, 16 Jul 2003 08:53:47 -0400 (EDT)

Jordi,

> connect to IPv6 in a way that we know is possible. My survey show that the subset of "scenarios" is big enough to be very relevant.

please notice that I am not against the solution you are describing. I see
a draft (if within the goals of a WG) as a document that will help all of
"us" somehow. It might open path for future exploration on some issues,
present an analysis, or describe some experimental situation that could
help a significant bunch of people . This is what I mean by a significant
contribution :-). it can be a minor thing, but significant somehow ;-)

Your draft presents a hack/trick (whatever you'd like to name it, but I'm
avoiding the word mechanism) that is a temporary solution; there are two
other possible ways that vendors should follow *before* simply deciding on
following the draft. But, let's look at the hypothetical scenario, where
the trick was imposed, given that by default it was there (what you're
saying above). the only people benefiting from it would be a small subset
of people! So it is here that I really don't see the purpose in creating
another draft ...

Rute