Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 17 Apr 2011 11:00:07 -0700

This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-to-historic. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 17 Apr 2011 20:27:14 +0200

Hi Fred,

I think this is not correct.

My recall from the discussions in the last meeting and the mailing list is
that there is no a general agreement (so no consensus), that this is the
correct way.

Furthermore, is not true the text in the document that indicates that this
mechanism is unsuitable for widespread deployment and the same applies to
"has rarely if ever been deployed".

Measurements show that there is a lot of 6to4 usage in the network,
probably 40% of the IPv6 traffic is that way. If the wrong think is people
using filtering then we should also deprecate PMTU because many folks
filter ICMP ? Should, because filtering deprecate any kind of tunnelling
because proto-41 filtering ? What about GRE filtering ?

There are several alternatives to this and we should discuss all them to
reach consensus, not moving one ahead of the others.

I could agree on deprecating RFC3068 and let the people use 6to4 end to
end, or with manually configured relays, but not definitively RFC3056.

Regards,
Jordi

-----Mensaje original-----
De: Fred Baker <[email-masked]>
Responder a: <[email-masked]>
Fecha: Sun, 17 Apr 2011 11:00:07 -0700
Para: <[email-masked]>
CC: <[email-masked]>, Ron Bonica <[email-masked]>
Asunto: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

>This is to initiate a two week working group last call of
>draft-ietf-v6ops-6to4-to-historic. Please read it now. If you find nits
>(spelling errors, minor suggested wording changes, etc), comment to the
>authors; if you find greater issues, such as disagreeing with a statement
>or finding additional issues that need to be addressed, please post your
>comments to the list.
>
>We are looking specifically for comments on the importance of the
>document as well as its content. If you have read the document and
>believe it to be of operational utility, that is also an important
>comment to make.
> 
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

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.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 17 Apr 2011 20:41:29 +0200 (CEST)

> end, or with manually configured relays, but not definitively RFC3056.

Do you oppose the new advise to recommend against having 6to4 default on?

I think that's the major point I'm after anyway. It should be a concious 
decision to run 6to4, not something that is enabled by default.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 17 Apr 2011 20:47:33 +0200

I oppose to a deprecation of 6to4.

It is already the last resort, and I will be happy if the anycast is by
default configured off. This way, 6to4 is still useful peer-to-peer.

Otherwise, we need to follow the same approach for 6over4, ISATAP, Teredo
(I mean deprecating them), and for many many many other transition mechs.

Regards,
Jordi

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 17 Apr 2011 20:52:08 +0200 (CEST)

> default configured off. This way, 6to4 is still useful peer-to-peer.

I don't want p2p 6to4 default on either.

> (I mean deprecating them), and for many many many other transition mechs.

Why? They're not causing as much trouble as 6to4 is right now. Teredo 
doesn't have the "silent fail" that 6to4 has.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 17 Apr 2011 20:56:21 +0200

I don't agree, the problem is not the "silent fail", but folks
missconfiguring filters, and the filters create the same trouble for any
protocol using proto-41 (so tunnel brokers, ISATAP, 6over4, etc.).

But same that folks filter proto-41, others filter other protocols, so
again, should we kill all them ?

Regards,
Jordi

---

From: [email-masked]
Date: Sun, 17 Apr 2011 21:02:53 +0200 (CEST)

> again, should we kill all them ?

We should make sure that any use of 6to4 is a conscious decision, and
that 6to4 should not default to on.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 17 Apr 2011 21:08:54 +0200 (CEST)

> protocol using proto-41 (so tunnel brokers, ISATAP, 6over4, etc.).

TCP is resilient to ICMP filtering by means of MSS blackhole detection 
<http://www.ietf.org/rfc/rfc4821.txt>. The problems with ICMP filters was 
noticed and a detection method was deviced to workaround the problem.

> again, should we kill all them ?

If we're going to keep 6to4 we need to make it more robust, so either we 
make is historic or we put in the effort to try to make it work better by 
means of it being able to detect problems. I think we should spend our 
time on better things, thus I support moving it to historic.

<http://www.apps.ietf.org/content/candidates-historic-status>

Moving it to historic doesn't mean people have to stop using it, it just 
means we don't think it's a good idea to use it. I agree with that 
statement.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 17 Apr 2011 21:09:15 +0200

There are two ways of doing this:

1) Killing all the protocols that may not work because some operators
don't know how to configure filters

2) Making sure that protocols are better, for example by means of ensuring
mechanisms such as "happy eyeballs" make a smart decision about what to use

Choice 1) means we lose IPv6 connectivity until IPv6 is globally deployed.

Choice 2) means we facilitate automatic transition if possible, until IPv6
is globally deployed, making this automatic transition more efficient and
not being tried by apps when it doesn't work. The failure rate will drop
with the time as many operators learn about IPv6 and better ways to do
filtering.

Regards,
Jordi

---

From: Fred Baker <[email-masked]>
Date: Sun, 17 Apr 2011 13:07:51 -0700

> (I mean deprecating them), and for many many many other transition mechs.

</chair>

If by 6over4 you mean explicit tunnels, I think they are already something someone does consciously.

From my perspective, so-called "transition mechanisms" are poorly named; they are in fact "coexistence" mechanisms (mechanisms that help IPv6 be an equal player in an otherwise-IPv4 network) or "prototyping" mechanisms that enable us to gain IPv6 experience in an otherwise IPv4 network.

Again from my perspective, we have entered a new phase. In this new phase, IPv6 and IPv4 are essentially equal players, and the objective is to develop and harden that deployment. There will be a turndown phase for IPv4 at some point in the future; that will be driven by business requirements. People with old equipment will continue to run it, which will mean that IPv4-only printers will continue to be used on people's desks and so on. But at the point that the vast majority of people, equipment, and applications are just as happy with either IPv4 or IPv6, folks will wonder why they need both and start turning IPv4 off. Solutions like ds-lite and 4rd are best thought of as in support of that; I can run IPv4 as an overlay on an otherwise IPv6-only network at some point.

But in this phase, to my way of thinking, the objective is to harden and stabilize the IPv6 infrastructure. Solutions that are primarily useful for prototyping at best have a limited role in that; anything that depends on IPv4 should either be operated by the network administration for a specific purpose, such as for example using 6rd as a way of working around equipment that is difficult or expensive to upgrade at the time the rest of the network is. If you heard Geoff Huston's talk at IETF-80, yes, there's a lot of 6to4 and Teredo in the network; he finds a lot of each in his dark nets, demonstrating that people that use it are often experiencing a degraded IPv6 service as a result of using it. That doesn't sound like "hardening and stabilizing".

I would agree with the point that things people are doing should be things they consciously decide to do, and can easily decide to not do.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 17 Apr 2011 22:16:21 +0200

However, we have heard also different views than the one presented by
Geoff. My own experience, using an average of 30 different networks every
year, while traveling, during the last 10 years, is that it fails to me
less than 1% of the times.

This clearly means that is not "so broken" as Geoff measurements seems to
indicate, so may be not so many network is filtering it. I don't know the
reason for such a difference, but it is statistically impossible that my
situation of not "so much" broken, is just good luck, specially when is a
view shared by others.

And by the way, it still seems to be a better approach than killing
protocols, making sure that they are used smartly, as said before for
example with "happy eyeballs".

Regards,
Jordi

-----Mensaje original-----
De: Fred Baker <[email-masked]>
Responder a: <[email-masked]>
Fecha: Sun, 17 Apr 2011 13:07:51 -0700
Para: Jordi Palet Martinez <[email-masked]>
CC: <[email-masked]>, Ron Bonica <[email-masked]>
Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

>From my perspective, so-called "transition mechanisms" are poorly named;
>they are in fact "coexistence" mechanisms (mechanisms that help IPv6 be
>an equal player in an otherwise-IPv4 network) or "prototyping" mechanisms
>that enable us to gain IPv6 experience in an otherwise IPv4 network.
>
>Again from my perspective, we have entered a new phase. In this new
>phase, IPv6 and IPv4 are essentially equal players, and the objective is
>to develop and harden that deployment. There will be a turndown phase for
>IPv4 at some point in the future; that will be driven by business
>requirements. People with old equipment will continue to run it, which
>will mean that IPv4-only printers will continue to be used on people's
>desks and so on. But at the point that the vast majority of people,
>equipment, and applications are just as happy with either IPv4 or IPv6,
>folks will wonder why they need both and start turning IPv4 off.
>Solutions like ds-lite and 4rd are best thought of as in support of that;
>I can run IPv4 as an overlay on an otherwise IPv6-only network at some
>point.
>
>But in this phase, to my way of thinking, the objective is to harden and
>stabilize the IPv6 infrastructure. Solutions that are primarily useful
>for prototyping at best have a limited role in that; anything that
>depends on IPv4 should either be operated by the network administration
>for a specific purpose, such as for example using 6rd as a way of working
>around equipment that is difficult or expensive to upgrade at the time
>the rest of the network is. If you heard Geoff Huston's talk at IETF-80,
>yes, there's a lot of 6to4 and Teredo in the network; he finds a lot of
>each in his dark nets, demonstrating that people that use it are often
>experiencing a degraded IPv6 service as a result of using it. That
>doesn't sound like "hardening and stabilizing".
>
>I would agree with the point that things people are doing should be
>things they consciously decide to do, and can easily decide to not do.

---

From: Dmitry Anipko <[email-masked]>
Date: Sun, 17 Apr 2011 15:49:54 -0700

The draft proposes to move both RFC 3056 and RFC 3068 to historic status on the following grounds:

1. A statement that 6to4 has rarely if ever been deployed.

2. A list of specific issues related to 6to4.

I couldn't find a reference in the draft which would support statement (1). If there has been some study showing that 6to4 deployment, by some quantifiable metric, is indeed many times lower than deployment of other tunnels (for example, Teredo), then I think having a reference to such data would make statement (1) more justified. 

In the list of issues related to 6to4, the first 4 of the issues are related to relay and, in my opinion, moving RFC 3068 (+ potentially anything related to relays in RFC 3056) to historic status is a possible solution to those issues, however those issues don't seem to be relevant to moving to historic status RFC 3056 in general.

The remaining two issues are: A) filtering of protocol 41 in intermediate firewalls and PMTUD/ICMP not working correctly, and B) 6to4 not able to work in networks where non-RFC-1918 addressing is used.

Specifically, the issue (A) states that "6to4 has no specified mechanism to handle the case where protocol 41 is blocked...". Do other tunneling mechanisms using protocol 41 have such mechanism? If they don't, then should usage of protocol 41 be moved to historic, because the stated filtering/PMTUD problems are then not specific to RFC 3056? If they do, then having a brief overview of those and how/why they don't apply to 6to4 would help to strengthen the statement.

The issue (B), if I understand correctly, it is essentially about usage of non-RFC1918 addresses in networks, connected to Internet e.g. using a NAT. There are existing mitigations to this problem (e.g. Windows implementation will not configure 6to4 interface if there is other IPv6 connectivity in the network; depending on particular implementation, in managed environments administrators may have control whether to enable or disable 6to4 on hosts). But even leaving those mitigations aside, it seems that the de-prioritization of 6to4 in prefix policy table below IPv4 in the proposed RFC 3484 revision would take care of this issue, and moving RFC 3056 is a much stronger measure, which doesn't seem to be necessary, as far as the issue (B) is concerned. With the revised RFC 3484, 6to4 will be one of the "last resort" mechanisms, which will essentially be used only if nothing else can, so it won't be harmful.

So to summarize, in my opinion, in the current draft there seem to be sufficient arguments to move RFC 3068 to historic, but not RFC 3056. There may be such arguments for RFC 3056, but if there are, I think they are not sufficiently reflected in the draft. 

Thank you,
Dmitry

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Sunday, April 17, 2011 11:00 AM
To: [email-masked]
Cc: [email-masked]; Ron Bonica
Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 18 Apr 2011 01:08:57 +0200

Agree, and by the way, proto-41 also works behind many NAT boxes with
private addresses, as studied long time ago:

http://tools.ietf.org/html/draft-palet-v6ops-proto41-nat-03

So this should not be one more excuse for making this historic, otherwise,
all the other proto-41 transition mechanism will be in the same situation
as well.

Regards,
Jordi

-----Mensaje original-----
De: Dmitry Anipko <[email-masked]>
Responder a: <[email-masked]>
Fecha: Sun, 17 Apr 2011 15:49:54 -0700
Para: Fred Baker <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Ron
Bonica <[email-masked]>

>I couldn't find a reference in the draft which would support statement
>(1). If there has been some study showing that 6to4 deployment, by some
>quantifiable metric, is indeed many times lower than deployment of other
>tunnels (for example, Teredo), then I think having a reference to such
>data would make statement (1) more justified.
>
>In the list of issues related to 6to4, the first 4 of the issues are
>related to relay and, in my opinion, moving RFC 3068 (+ potentially
>anything related to relays in RFC 3056) to historic status is a possible
>solution to those issues, however those issues don't seem to be relevant
>to moving to historic status RFC 3056 in general.
>
>The remaining two issues are: A) filtering of protocol 41 in intermediate
>firewalls and PMTUD/ICMP not working correctly, and B) 6to4 not able to
>work in networks where non-RFC-1918 addressing is used.
>
>Specifically, the issue (A) states that "6to4 has no specified mechanism
>to handle the case where protocol 41 is blocked...". Do other tunneling
>mechanisms using protocol 41 have such mechanism? If they don't, then
>should usage of protocol 41 be moved to historic, because the stated
>filtering/PMTUD problems are then not specific to RFC 3056? If they do,
>then having a brief overview of those and how/why they don't apply to
>6to4 would help to strengthen the statement.
>
>The issue (B), if I understand correctly, it is essentially about usage
>of non-RFC1918 addresses in networks, connected to Internet e.g. using a
>NAT. There are existing mitigations to this problem (e.g. Windows
>implementation will not configure 6to4 interface if there is other IPv6
>connectivity in the network; depending on particular implementation, in
>managed environments administrators may have control whether to enable or
>disable 6to4 on hosts). But even leaving those mitigations aside, it
>seems that the de-prioritization of 6to4 in prefix policy table below
>IPv4 in the proposed RFC 3484 revision would take care of this issue, and
>moving RFC 3056 is a much stronger measure, which doesn't seem to be
>necessary, as far as the issue (B) is concerned. With the revised RFC
>3484, 6to4 will be one of the "last resort" mechanisms, which will
>essentially be used only if nothing else can, so it won't be harmful.
>
>So to summarize, in my opinion, in the current draft there seem to be
>sufficient arguments to move RFC 3068 to historic, but not RFC 3056.
>There may be such arguments for RFC 3056, but if there are, I think they
>are not sufficiently reflected in the draft.
>
>Thank you,
>Dmitry
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Apr 2011 08:35:00 +0900

> draft-ietf-v6ops-6to4-to-historic.
> ...
> document 

it is important to get rid of this bad kludge.  it was a bad design on
day one, and has proven to be *really* bad in operation.

deprecation is far too mild.

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 17 Apr 2011 18:54:09 -0700

On 4/17/11 11:52 AM, Mikael Abrahamsson wrote:
>> It is already the last resort, and I will be happy if the anycast is
>> by default configured off. This way, 6to4 is still useful peer-to-peer.
> 

by all accounts teredo just induces really bad performance... I'm not
willingto call that a win

---

From: Martin Millnert <[email-masked]>
Date: Sun, 17 Apr 2011 22:55:36 -0400

> > doesn't have the "silent fail" that 6to4 has.

The primary reason Teredo "doesn't fail" is that it isn't used when
hitting A+AAAA or AAAA records from browsers. And even though the tunnel
modes *are* different, had Teredo been prioritized higher, we'd had
another "co-exist" mechanism to scratch our heads about today.
Thankfully, we get off easy on this one.

> willingto call that a win

There is, to my knowledge, no "default on" implementation of Teredo
which does not do sufficiently proper source- and destination address
selection (and more). Thus, the only result from any default mode
operating Teredo implementation is that you are able to connect to IPv6
addresses, which you otherwise would not be.
  I don't agree with you that zero v6-connectivity is better than some
connectivity that also does not hurt in any of the scenarios where 6to4
is hurting today.  In fact, I'm wondering how you came about your
conclusion.

Regards,
Martin

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 17 Apr 2011 22:03:20 -0700

>From my vantage point you're misreading the outcome of the dicussion. I
have observed general consensus on  the question of the usage of 6to4
being harmful to user's experience.

you should demonstrate otherwise if you're going to pursue this line of
reasoning.

---

From: Dmitry Anipko <[email-masked]>
Date: Sun, 17 Apr 2011 22:56:29 -0700

Hello Joel,

from the notes of the Prague meeting you've sent out earlier it seems that a few people expressed their concerns regarding moving RFC 3056 to historic (and suggestions to move only RFC 3068 to historic). That was followed by voting: "fred b - calling the question, this is my summary is this the recommedation we want to make? Do you believe that in general this is the way that we want to go. Hum, generally in favor, some opposition noted...".  From the notes it is not clear to me - did the "recommendation in general" refer to adopt the draft as a framework and continue work on it (which implies further discussion and changes are possible) or it referred to the approval of the draft as it was at that time?

>>I have observed general consensus on  the question of the usage of 6to4 being harmful to user's experience. you should demonstrate otherwise if you're going to pursue this line of reasoning.

If the supporters of moving RFC 3056 to historic feel there is firm evidence why RFC 3056 is harmful, it should not be difficult to elaborate on that in the draft, and explain why alternative mitigations (such as changing RFC 3484 prefix policy) would not be sufficient - that would help address concerns regarding moving RFC 3056 to historic. If there is no such evidence however, then to me it seems reasonable to remove such recommendation for RFC 3056, rather than postulating that RFC 3056 is harmful and requiring others to prove otherwise.

Thank you,
Dmitry

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joel Jaeggli [[email-masked]]
Sent: Sunday, April 17, 2011 10:03 PM
To: [email-masked]
Cc: [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

---

From: james woodyatt <[email-masked]>
Date: Sun, 17 Apr 2011 23:19:56 -0700

On Apr 17, 2011, at 11:00 AM, Fred Baker wrote:
> 
> if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should not published in its current form because it sets no standard for network operations without 6to4.  A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Apr 2011 15:34:05 +0900

> this draft should not published in its current form because it sets no
> standard for network operations without 6to4.

try ipv6

randy

---

From: Tore Anderson <[email-masked]>
Date: Mon, 18 Apr 2011 08:40:24 +0200

* Dmitry Anipko

> If the supporters of moving RFC 3056 to historic feel there is firm
> evidence why RFC 3056 is harmful, it should not be difficult to
> elaborate on that in the draft, and explain why alternative
> mitigations (such as changing RFC 3484 prefix policy) would not be
> sufficient - that would help address concerns regarding moving RFC
> 3056 to historic. If there is no such evidence however, then to me it
> seems reasonable to remove such recommendation for RFC 3056, rather
> than postulating that RFC 3056 is harmful and requiring others to
> prove otherwise.

Dmitry,

6to4 connectivity is at its most harmful when it's being shared from a
router-like device (including, but certainly not limited to, ICS) to a
number of other devices that possibly do not implement RFC 3484 or
something similar.

In this situation, the devices behind the 6to4 router will have:

1) A globally-scoped unicast IPv6 address, and
2) a default route to the IPv6 internet.

In the 3056+3068 case, this has an up to 85% chance of actually working
for internet-bound traffic [Aben, Huston].

In the 3056-only case, it has a _0%_ chance of actually working.

In other words: Removing the 3068 functionality, while leaving 3056
intact, will only aggravate the 6to4-problems that network/content
operators struggle with today.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 17 Apr 2011 23:42:55 -0700

> than postulating that RFC 3056 is harmful and requiring others to

on the contrary support for the document as a whole to advance has been
very much in evidence, hence it's status as a wg document and the
decision to WGLC it, if the inclusion of 3056 is a problem that should
be demonstrated as you are doing now.

As Brian carpenter noted and I think I captured. "I don't think 3056 is
broken, nobody deployed it."

> Thank you, Dmitry

---

From: Tore Anderson <[email-masked]>
Date: Mon, 18 Apr 2011 09:02:24 +0200

* Fred Baker

> draft-ietf-v6ops-6to4-to-historic. Please read it now. If you find
> nits (spelling errors, minor suggested wording changes, etc), comment
> to the authors; if you find greater issues, such as disagreeing with
> a statement or finding additional issues that need to be addressed,
> please post your comments to the list.
> 

I really hope this document will in the medium- to long-term really help
out limiting the 6to4-related performance/reliability problems that the
IPv6 internet currently suffers from. I therefore support it emphatically.

6to4 is often labelled a «transition technique», suggesting that it is
helping internet community deploy native IPv6. Perhaps that was true to
begin with. Today's operational reality, however, is exactly the
opposite - 6to4's ubiquity combined with its unreliability is a major
obstacle to IPv6 deployment; it caused my own customers to push back
their native IPv6 deployments for about 14 months while attempting to
minimize the problems in every imaginable way.

It is high time we retire 6to4 and start focusing on real IPv6
deployments instead.

Best regards,

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 Apr 2011 09:34:28 +0200

Dmitry,

> I couldn't find a reference in the draft which would support statement (1). If there has been some study showing that 6to4 deployment, by some quantifiable metric, is indeed many times lower than d…

the "non deployed" reference is with regards to this RFC3056 deployment model:
RFC3056, section 5.2:

   2.2 An IPv6 exterior routing protocol is used.  The set of 6to4
   routers using a given relay router obtain native IPv6 routes from the
   relay router using a routing protocol such as BGP4+ [RFC 2283,
   BGP4+].  The relay router will advertise whatever native IPv6 routing
   prefixes are appropriate on its 6to4 pseudo-interface.  These
   prefixes will indicate the regions of native IPv6 topology that the
   relay router is willing to relay to.  Their choice is a matter of
   routing policy.  It is necessary for network operators to carefully
   consider desirable traffic patterns and topology when choosing the
   scope of such routing advertisements.  The relay router will
   establish BGP peering only with specific 6to4 routers whose traffic
   it is willing to accept.

I have never heard nor seen this model having been deployed. anyone?

> In the list of issues related to 6to4, the first 4 of the issues are related to relay and, in my opinion, moving RFC 3068 (+ potentially anything related to relays in RFC 3056) to historic status i…

in this model:

RFC3056, section 5.2:
   2.1 No IPv6 exterior routing protocol is used.  The 6to4 routers
   using a given relay router each have a default IPv6 route pointing to
   the relay router.  The relay router MAY apply source address based
   filters to accept traffic only from  specific 6to4 routers.

6to4 does not work without relays. RFC3056 works with a known relay in the forward direction and a remote relay in the reverse direction. the only difference between 3068 and 3056's use of relays is that in the 3056 case the forward relay is configured with an IPv4 unicast address as opposed to a well known IPv4 anycast address. all the other relay related issues still remain in 3056.

are you suggesting to create a version of 6to4, where 6to4 nodes can only reach other 6to4 nodes? i.e. no relays whatsoever?

> So to summarize, in my opinion, in the current draft there seem to be sufficient arguments to move RFC 3068 to historic, but not RFC 3056. There may be such arguments for RFC 3056, but if there are…

if RFC3056 was 6to4 node to 6to4 node communication only, I would agree with you. but 3056 uses relays in the same fashion as 3068. unless you deploy it the way Brian intended originally.

cheers,
Ole

---

From: [email-masked]
Date: Mon, 18 Apr 2011 13:26:28 +0200 (CEST)

> IPv6 internet currently suffers from. I therefore support it emphatically.

Support from an operator here.

---

From: Gert Doering <[email-masked]>
Date: Mon, 18 Apr 2011 13:27:45 +0200

Hi,

> draft-ietf-v6ops-6to4-to-historic. 

Support.

Gert Doering
        -- Operator
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Mon, 18 Apr 2011 12:47:58 +0000

Support. I believe that the document is an acceptable compromise between acknowledging that 6to4 has fatal flaws that make it a
liability and the fact that people are still using it with some degree of success.

Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Sunday, April 17, 2011 2:00 PM
To: [email-masked]
Cc: [email-masked]; Ron Bonica
Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

This is to initiate a two week working group last call of draft-ietf-v6ops-6to4-to-historic. Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing
with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important comment to make.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 18 Apr 2011 14:52:50 +0200

On Sun, Apr 17, 2011 at 8:00 PM, Fred Baker <[email-masked]> wrote:
> authors; if you find greater issues, such as disagreeing with a statement or
> finding additional issues that need to be addressed, please post your
> comments to the list.
> We are looking specifically for comments on the importance of the document
> as well as its content. If you have read the document and believe it to be
> of operational utility, that is also an important comment to make.

Same with this document, another small step in the process of making
IPv6 internet more reliable and stable, more userfriendly:)

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Mon, 18 Apr 2011 13:10:30 +0000

James , every network is going to be different in terms of the amount of 6to4 traffic present on it and when it makes sense to stop
supporting it. As CGN becomes prevalent, especially if providers choose to squat on non-1918 space for their internal NAT pools,
it's going to break anyway.
I don't believe that we gain much value in declaring a flag day when all of the 6to4 relays get turned off, or the anycast blocks
get null-routed everywhere.

The draft already recommends turning it off by default or ceasing implementation in hosts, and recommends that operators should
continue providing relays until traffic levels have dropped to the point that they feel that there will be negligible impact.
It might be useful to write a companion draft recommending a standard way to intercept 6to4 traffic to notify people that it's about
to stop working, but that's about as much of a phaseout plan as I can see adding value. What else would you want to see in a
phaseout plan?

Also, what do you actually mean by "sets no standard for network operations without 6to4"?

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Monday, April 18, 2011 2:20 AM
To: IPv6 Ops WG
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

> if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please
post your comments to the list.

Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should not published in its
current form because it sets no standard for network operations without 6to4.  A phaseout plan for RFC 3056 and RFC 3068 would be
required before I could drop my objections to this draft.

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 18 Apr 2011 15:17:41 +0200

> IPv6 internet currently suffers from. I therefore support it emphatically.

Support, from an operator.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 18 Apr 2011 14:56:59 +0100

On 18/04/2011 07:19, james woodyatt wrote:
> Now that we have an official WGLC, I'm going to repeat what I wrote in a
> previous thread: this draft should not published in its current form
> because it sets no standard for network operations without 6to4.  A
> phaseout plan for RFC 3056 and RFC 3068 would be required before I could
> drop my objections to this draft.

James: if this document were to explicitly set a phaseout date for 
2002::/16 some time in the future, would this work for you?

ID Authors: would you view such an addition as within scope for this 
document, or do you see an explicit end-game definition as work for a 
future ID?

Nick

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Mon, 18 Apr 2011 13:57:23 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Sunday, April 17, 2011 3:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

1) Killing all the protocols that may not work because some operators don't know how to configure filters
______
[WEG] Gross oversimplification. This isn't just about filters, and it certainly isn't just about operators' filters. Even at best,
6to4 is degraded because of all of the other things discussed in draft-ietf-v6ops-6to4-advisory

2) Making sure that protocols are better, for example by means of ensuring mechanisms such as "happy eyeballs" make a smart decision
about what to use
______
[WEG] So... assuming we get critical mass on implementing happy eyeballs in a reasonable timeframe (which in and of itself is a
stretch), it tests, confirms what we already know, which is that 6to4 is not really a viable option for a large portion of the users
when compared with IPv4 or with native IPv6, and it never or almost never uses 6to4. Exactly how does that improve the situation and
justify keeping 6to4 alive?

Wes George

---

From: Martin Millnert <[email-masked]>
Date: Mon, 18 Apr 2011 10:12:06 -0400

On Sun, 2011-04-17 at 11:00 -0700, Fred Baker wrote:
> to the authors; if you find greater issues, such as disagreeing with a
> statement or finding additional issues that need to be addressed,

I support the document wrt. the logic below (copying from ipv6-ops):

On Mon, 2011-04-18 at 11:38 +0100, Nick Hilliard wrote:
> The approach that's most likely to get widespread support is:
> 
> 1. make it not be on by default
> 2. make noise about it being A Bad Thing
> 3. deprioritise 2002::/16 addresses in resolver libs
> 4. then make the option hard to find on operating systems / CPEs
> 5. then remove the option on operating systems
> 6. then slowly decommission 6to4 relays over many years
> 
> draft-ietf-v6ops-6to4-to-historic deals with steps 1-3. 

I do think it would be useful to elaborate on the arguments Tore just
provided to Dmitry for deprecation of 3056 in the draft, as a form of
history writing for the archives.

Regards,
Martin

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 18 Apr 2011 07:46:42 -0700

> 2002::/16 some time in the future, would this work for you?

the worked for the 6bone trial more or less, that said it's actual
property of gone-ness has a lot to do with the existence of devices
which still have it enabled, and relays which still exist.

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Mon, 18 Apr 2011 14:53:45 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Sunday, April 17, 2011 2:48 PM
To: [email-masked]
Cc: Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

I oppose to a deprecation of 6to4.
It is already the last resort, and I will be happy if the anycast is by default configured off. This way, 6to4 is still useful
peer-to-peer.
_______
[WEG] Please explain what value having peer to peer 6to4 would provide that makes you keen to try to preserve it - actual use cases,
please. If the idea is to use 6to4 as a method to deploy IPv6 more widely when the provider of the upstream network is not doing so,
peer to peer 6to4 buys us...what, exactly? Not connectivity to the IPv6 internet, that's for sure. 
And as I've said at the mic and in other emails, it's simply not valid to assume that 6to4 is going to keep working anyway.
draft-kuarsingh-v6ops-6to4-provider-managed-tunnel (and Cameron Byrne's previous message that they're already null-routing this
traffic on their network) is evidence of two common breakage cases that are only going to get more common.

Otherwise, we need to follow the same approach for 6over4, ISATAP, Teredo (I mean deprecating them), and for many many many other
transition mechs.
_______
[WEG] I don't buy the extension of the argument that if we deprecate 6to4 (or Teredo) that we also need to deprecate 6over4 and
other less automatic transition mechanisms. It's hyperbole.
However, there was more than one comment (list or Mic, or both, don't remember) that recommended exactly that - a companion draft
deprecating Teredo too, for much the same reason - significantly degraded service that is not going to be easy to solve, especially
when weighed against the competing priority of deploying IPv6 for real. For a lot of implementations, I think it's binary - they can
either work on buffing the turd some more, or they can work on implementing IPv6, not both.

<from a different message from Jordi>
However, we have heard also different views than the one presented by Geoff. My own experience, using an average of 30 different
networks every year, while traveling, during the last 10 years, is that it fails to me less than 1% of the times.
This clearly means that is not "so broken" as Geoff measurements seems to indicate, so may be not so many network is filtering it. I
don't know the reason for such a difference, but it is statistically impossible that my situation of not "so much" broken, is just
good luck, specially when is a view shared by others.
_______
[WEG] This example leaves me unconvinced. We in the IETF are the exception when it comes to deploying things, not in any way
representative of the general populace. We routinely test things in our own networks that are limited deployment and "not ready for
primetime" because we're interested in them. We're also more likely to be able to fix things when they're broken, and tolerate
service degradation (our own) during that testing. Since we're trying to get to IPv6 service that is as good as or better than IPv4,
this needs to be less about "I personally use 6to4 and I don't want it to break" and more about why the larger populace needs 6to4,
if in fact they do. Personally, I think that the only folks who have consciously enabled 6to4 are either testing it, have something
to prove by using IPv6 (because they want IPv6 deployment to increase), or (marginally) because their P2P client let them click a
button to potentially bypass ISP P2P interference by moving the traffic to IPv6. You will have trouble convincing me that 6to4 is
necessary assuming IPv4 is working, and I can't see too many average folks choosing a degraded service over one that is not. 
Continuing to support this protocol in the face of this limited of a deployment and the obvious tradeoffs is really more about
ideology than operational considerations.

Wes George

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 18 Apr 2011 18:32:43 +0200

> It is high time we retire 6to4 and start focusing on real IPv6

I'm a bit surprised with some of the argument against this and the other
document in the queue right now, why are people _still_ focused on tunnels
over IPv4 to get IPv6 running? 6to4 is one of them.

Wasn't that something we did like 10 years ago when there was not so many
other real options?

Shouldn't the focus now being on real IPv6 deployment as Tore say?

-- 

Roger Jorgensen           |

---

From: Philip Homburg <[email-masked]>
Date: Mon, 18 Apr 2011 19:08:18 +0200

>over IPv4 to get IPv6 running? 6to4 is one of them.

That depends on your role. From ISP perspective, 6to4 doesn't make a lot of
sense. But for end users, sometimes a tunnel is all you can get. Sometimes, 
tunnels offer even a more complete IPv6 experience than native.

I can imagine that if you are now using 6to4, you don't want the next firmware
upgrade of your router to remove that feature completely.

>Shouldn't the focus now being on real IPv6 deployment as Tore say?

If you are an ISP, certainly yes.

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 18 Apr 2011 12:33:44 -0500

> over IPv4 to get IPv6 running? 6to4 is one of them.

This aligns with my thoughts.  6to4 is quite broken, which is supported
by evidence for a variety of situations.  Sure, we could spend time
fixing it, but it would be best to spend that effort working on real
IPv6 deployments.  The time for 6to4 was the last 10 years.

We need to set 6to4 to historic and move on.

Dale

---

From: james woodyatt <[email-masked]>
Date: Mon, 18 Apr 2011 10:45:25 -0700

On Apr 17, 2011, at 23:34 , Randy Bush wrote:
> [I wrote:]

That's not a phaseout plan for 6to4.  I've written before about what a proper phaseout plan for 6to4 should look like.  You seem to be in favor of having a proper phaseout plan in the draft... perhaps you could propose a plan that would make sense for operators.  I look forward to seeing it.

---

From: james woodyatt <[email-masked]>
Date: Mon, 18 Apr 2011 10:56:07 -0700

On Apr 18, 2011, at 06:56 , Nick Hilliard wrote:
> 
> James: if this document were to explicitly set a phaseout date for 2002::/16 some time in the future, would this work for you?

Yes.  I cannot support this draft unless it has an explicit phaseout plan for 2002::/16 included.  If you want to send a signal to equipment makers that they should remove 6to4 routing functions from their future product plans, then you need to include a phaseout plan for it.  Otherwise, you are engaging in a pointless exercise, and it won't happen.

Am I making myself clear?  Because I really can't be more explicit than that.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 18 Apr 2011 20:03:04 +0200

> Am I making myself clear?  Because I really can't be more explicit than that.

I suggested 4.June 2016 a couple of weeks ago....

-- 

Roger Jorgensen           |

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 18 Apr 2011 20:04:16 +0200 (CEST)

On Mon, 18 Apr 2011, james woodyatt wrote:

> Yes.  I cannot support this draft unless it has an explicit phaseout 
> plan for 2002::/16 included.  If you want to send a signal to equipment 
> makers that they should remove 6to4 routing functions from their future 
> product plans, then you need to include a phaseout plan for it. 
> Otherwise, you are engaging in a pointless exercise, and it won't 
> happen.

Could you please elaborate as to why? Not working for an equipment vendor, 
I don't get why there needs to be a firm phaseout plan. I never saw a 
phaseout plan for RIPv1.

---

From: yannis nikolopoulos <[email-masked]>
Date: Mon, 18 Apr 2011 21:14:52 +0300

> Support, from an operator.
 
+1 (from an operator also)

regards,
Yannis

-- 
Yannis Nikolopoulos		OTE Hellenic Telecommunications Organization
e-mail: [email-masked]	IP Network Planning
----------------------------------------------------------------------------
()  ASCII Ribbon Campaign - against HTML email & vCards
/\

---

From: james woodyatt <[email-masked]>
Date: Mon, 18 Apr 2011 11:20:41 -0700

On Apr 18, 2011, at 11:04 , Mikael Abrahamsson wrote:
> 
> Could you please elaborate as to why?

Too many service providers today have not announced any IPv6 transition plans, leaving our customers with only 6to4 as their only hope for acquiring even marginally acceptable IPv6 services with a reasonable level of configuration human interface burden.  Until this changes, I doubt Apple and other equipment makers will stop supporting 6to4 routing in their products, and people will continue to use it despite the IETF deprecation, and IPv6 brokenness related to 6to4 will probably remain at the unacceptable levels that operators and content providers hope to address with the publication of this draft.

On the other hand, if IETF publishes a standards track document with phaseout plan for 2002::/16, then product managers can know with reasonable certainty when their 6to4 routing feature will no longer be useful to any of their customers, and they can plan accordingly.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 18 Apr 2011 20:31:59 +0200 (CEST)

On Mon, 18 Apr 2011, james woodyatt wrote:

> On the other hand, if IETF publishes a standards track document with 
> phaseout plan for 2002::/16, then product managers can know with 
> reasonable certainty when their 6to4 routing feature will no longer be 
> useful to any of their customers, and they can plan accordingly.

How agressive does the phaseout plan need to be?

I'm looking at 6bone <http://tools.ietf.org/html/rfc3701>, it gave 2.5 
years to remove it from the Internet.

It's just that won't allowing ISPs to filter the anycast prefixes for 6to4 
just make the problem worse? How would a phase-out be structured to cause 
the users the least amount of problems? By 2014-01-01 people should start 
sending unreachables for any traffic for 192.88.99.1 ?

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 Apr 2011 20:49:09 +0200

James,

> Too many service providers today have not announced any IPv6 transition plans, leaving our customers with only 6to4 as their only hope for acquiring even marginally acceptable IPv6 services with a…

people who have made an informed choice to use 6to4 will continue to do so, regardless of the IETF or what equipment makers do in upgraded products. giving those users a different solution or forcing them to stop using 6to4 is not the purpose of this draft.

the problem is when equipment vendors decide on their users behalf, that they should have 6to4 IPv6 access, wether they want it or not. this document provides a stable reference for both vendors and perhaps more importantly those who buy equipment.

I see 6to4-historic and 6to4-advisory as complimentary. you should implement the suggestions in section 4.1.
I would like to see a reachability check for the 6to4 relay in there too.

> On the other hand, if IETF publishes a standards track document with phaseout plan for 2002::/16, then product managers can know with reasonable certainty when their 6to4 routing feature will no lo…

I don't see that logical implication.

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Mon, 18 Apr 2011 12:01:15 -0700

> How agressive does the phaseout plan need to be?

Not for me to say.

I would estimate that if product managers were to see a standards track phaseout plan that says 2002::/16 MUST NOT appear in the default-free zone after $DATE, then they might feel confident at ${DATE - 2 years} making the 6to4 routing feature a hidden and marginally-supported feature for customers upgrading from previous models, and that new products released after ${DATE - 3 months} could dispense entirely with the 6to4 routing feature, and firmware updates for existing products could actively disable 6to4 in deployed configurations.  At least, that's the recommendation I would make to my product managers.

Or you could decide not to mark an explicit date for phaseout, and I would recommend they continue supporting 6to4 until the last major Internet service provider stops providing IPv4-only service in the public address realm.

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 18 Apr 2011 13:21:16 -0700

Hello Ole,

>> I have never heard nor seen this model having been deployed. anyone?

RFC 3056 has other scenarios, such as e.g. in section 5.1 and 5.4. While the statement in the draft-ietf-v6ops-6to4-to-historic that " IPv6 transition mechanism... has rarely if ever been deployed" refers to the whole RFC, and not to the specific section you're referring to. If the scenarios relying on BGP haven't been deployed, should not that be stated as such, instead of referring to the whole RFC?

>>6to4 does not work without relays. 

I'm not suggesting to create anything that doesn't already exist - such "version" is essentially already documented in the RFC 3056, in section 5.1. What I'm trying to understand is why those scenarios should be moved to historic - in my opinion, draft-ietf-v6ops-6to4-to-historic doesn't explain that to a sufficient extent.

>> if RFC3056 was 6to4 node to 6to4 node communication only, I would agree with you. but 3056 uses relays in the same fashion as 3068.

There are parts which mention relays, and parts which don't. I think draft-ietf-v6ops-6to4-to-historic fairly well explains what's wrong with relays, but it doesn't address what's wrong with 6to4-6to4 communication. And if there is not much wrong with 6to4-6to4 scenario (either between the nodes or between nodes and islands), why should that part be moved to historic.

Thank you,
Dmitry

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, April 18, 2011 12:34 AM
To: Dmitry Anipko
Cc: Fred Baker; [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Dmitry,

in this model:

RFC3056, section 5.2:

cheers,
Ole

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 18 Apr 2011 13:38:11 -0700

Hello Tore,

>> other devices that possibly do not implement RFC 3484 or something similar.

This is a problem on its own, that should be fixed in those devices and software due to other reasons, not related to 6to4.

That said, it seems to me (let me know if I misunderstood) you're assuming a configuration where 6to4 router advertises a default route (while it itself doesn't have any or working default route to the IPv6 Internet). I agree that that is a misconfiguration that should be avoided. However there is no requirement for a 6to4 router to advertise the default route on the network to support a scenario described in RFC 3056 section 5.1, instead the 6to4 router can advertise a specific route option for 6to4 well known prefix. 

Thank you,
Dmitry

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: Sunday, April 17, 2011 11:40 PM
To: Dmitry Anipko
Cc: Joel Jaeggli; [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

* Dmitry Anipko

Dmitry,

Best regards,

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 18 Apr 2011 13:51:53 -0700

Hello Joel,

I think it is useful to separate evidence of fact and evidence of opinion. 

For the future readers of the standard, should draft-ietf-v6ops-6to4-to-historic become one, I don't believe it is not going to be very useful if the standard says that 6to4 is moved to historic because that was a clear evidence that that was the majority opinion.

On the other hand, I think it would be useful, if the reasons (evidence of facts), based on which that majority opinion was reached, were explained (as the draft does for the relays issue) and an average reasonable engineer after reading the standard would arrive to the same opinion as what the majority reached.

>> if the inclusion of 3056 is a problem that should be demonstrated as you are doing now.

Specifically, so far I fail to see reasons sufficiently explained in the draft why peer-to-peer 6to4 scenarios need to be moved to historic, and with the current text I do not support moving to historic RFC 3056 as a whole.

Thank you,
Dmitry

---

From: Fred Baker <[email-masked]>
Date: Mon, 18 Apr 2011 14:36:46 -0700

On Apr 18, 2011, at 6:56 AM, Nick Hilliard wrote:

> ID Authors: would you view such an addition as within scope for this document, or do you see an explicit end-game definition as work for a future ID?

I'm wearing my "chair" hat here, but I don't have it pulled on too tight. This is as much my personal opinion as it is chair-ness.

To my way of thinking, turn-off dates are as much a business issue as a technology issue. Telling vendors that we wish they would turn 6to4 off by default is useful guidance to them; I have no delusions that it means that they will have done so in new products they produce or (by way of patches) have updated a significant subset of their field deployment by any date certain. I might expect operators to look at the traffic in their networks and make decisions about their own need to null-route anycast addresses or implement 6to4 relays, and to include these two drafts in their lines of reasoning. But I can just as easily imagine one operator deciding that it has no business requirement to cater to 6to4 traffic while the next one finds an overwhelming need. My suggestion to the first would not be about 6to4; it would be to deploy IPv6 natively to all of its customers and in so doing make the point irrelevant. My suggestion to the second would be the same, albeit for different reasons. 

I don't think turn-off dates, whether now for 6to4 or a few years hence for IPv4, are the IETF's purview. I do think technical advice we give can be helpful.

---

From: james woodyatt <[email-masked]>
Date: Mon, 18 Apr 2011 16:03:07 -0700

On Apr 18, 2011, at 14:36 , Fred Baker wrote:
> 
> I don't think turn-off dates, whether now for 6to4 or a few years hence for IPv4, are the IETF's purview.

That's not how I see it.  IETF created 6to4 by issuing a Proposed Standard that defined the special-purpose usage of the 2002::/16 prefix.  It is therefore perfectly within IETF's ambit to issue a new Proposed Standard that obsoletes the previous standard and redefines the usage of the 2002::/16 prefix as not for use on the public Internet.

Shorter james: clearly, IETF *may* do this; the question before us is whether we *shall* do it.

---

From: Fred Baker <[email-masked]>
Date: Mon, 18 Apr 2011 16:15:47 -0700

> That's not how I see it.  IETF created 6to4 by issuing a Proposed Standard that defined the special-purpose usage of the 2002::/16 prefix.  It is therefore perfectly within IETF's ambit to issue a…

Or to simply declare the old RFC historic, which is what we're discussing.

That's significantly different than an operational turn-off date.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Apr 2011 14:10:39 +1200

After a fair amount of thought, I have decided that I support
this document without reservation.

I support the recommendation that RFC 3068 support should be off
by default in CPEs and end-user hosts; the reasons for this are
clear enough in my companion draft. Specifically, I support the
choice of "SHOULD NOT enable" (rather than MUST NOT) because it
leaves open the option for a CPE or host vendor to enable RFC
3068 by default if there is a sound reason to do so for a
specific product.

I support the recommendation to reclassify RFC 3056 as Historic,
because its time is past. The reason for inventing 6to4 in the
first place was for the benefit of customers whose ISPs could
not deploy IPv6. There is now no reason or excuse for a consumer
ISP to fail to deploy IPv6 for customers, so it is entirely
reasonable to consider the technique as Historic.

I see no point in declaring a notional sunset date for the
2002::/16 prefix. On the contrary, as the companion draft
indicates, relays advertising this prefix are needed as long as
there is residual 6to4 traffic in the network. The question of
2002:: addresses in AAAA records is covered in the companion draft.

Regards
   Brian Carpenter (co-author of RFC 3056)

On 2011-04-18 06:00, Fred Baker wrote:
> ------------------------------------------------------------------------
>

---

From: George Michaelson <[email-masked]>
Date: Tue, 19 Apr 2011 12:26:40 +1000

There are ancillary services associated with 2.0.0.2.ip6.arpa which are provided by APNIC under the auspices of RFC5158.

I just want to confirm to people that irrespective of this proposed change, APNIC intends to continue to provide reverse-DNS delegation, until its clear the community at large doesn't require the service.

Should de-delegation of the space be intended, can I please suggest that this is done via an instruction in dnsop which re-delegates to the AS112 service, since there exists a substantial volume of reverse-DNS in 6to4 already, and having it delegated removes this NXDOMAIN load from the root.

This traffic exists as a consequence of packets being seen to come from 2002::/16 source IP. It is not actually necessary for a complete end-to-end exchange to run to completion for the DNS lookup to happen (consider firewall/ACL rules with logging) And so will continue even if the protocol itself is deprecated, for some time.

-George

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Apr 2011 13:32:36 +0900

> I'm a bit surprised with some of the argument against this and the
> other document in the queue right now, why are people _still_ focused
> on tunnels over IPv4 to get IPv6 running? 6to4 is one of them.

i am less surprised.  after all, over in idr they are rediscovering
slip.

> Wasn't that something we did like 10 years ago when there was not so
> many other real options?
> 

+1

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 19 Apr 2011 16:04:13 +0200

Jordi>

GV> If it is v6 you want over v4 in a dynamic 'managed' tunnel
infrastructure, then go to your favourite vendor and ask them about
this. I am sure they have a solution for that. No need to have 6to4 for
this at all.

G/

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 19 Apr 2011 16:47:59 +0200

<>start Jordi snip<>

<>end snip<>

GV> 6to4 is to die anyway when native is deployed, not sure that is for
the other technologies you mentioned. And right now it causes more
damage then it is bringing and fixing will cost more resources then its
worth.

G/

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 19 Apr 2011 08:10:09 -0700

> don't know how to configure filters

There's always the case that protocol 41 filtering was done deliberately...

we still break those users.

joel

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Tue, 19 Apr 2011 11:10:31 -0400 (EDT)

On Tue, 19 Apr 2011, George Michaelson wrote:

> Should de-delegation of the space be intended, can I please suggest 
> that this is done via an instruction in dnsop which re-delegates to the 
> AS112 service, since there exists a substantial volume of reverse-DNS in 
> 6to4 already, and having it delegated removes this NXDOMAIN load from the 
> root.

I agree with this, since we would need to capture such traffic at AS112. 
Perhaps the draft should have a modified IANA Considerations section to 
include a note about reverse delegation when the time comes.

wfms

---

From: james woodyatt <[email-masked]>
Date: Tue, 19 Apr 2011 08:47:45 -0700

On Apr 18, 2011, at 7:10 PM, Brian E Carpenter wrote:
> 
> There is now no reason or excuse for a consumer ISP to fail to deploy IPv6 for customers...

I wonder if the operator community shares this assessment of their situation.

Every major consumer ISP serving my metropolitan area today has one very good reason for not deploying native IPv6 yet, i.e. there is negligible market demand for it, because there is no content to speak of that requires it, and there won't be any such content until more enterprises are shut out of IPv4 by address exhaustion at the RIRs.

Also, most consumer ISPs have the excuse that too many of their provider-provisioned CPE gateways do not support native IPv6 routing.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 Apr 2011 18:19:34 +0200 (CEST)

On Tue, 19 Apr 2011, james woodyatt wrote:

> Every major consumer ISP serving my metropolitan area today has one very 
> good reason for not deploying native IPv6 yet, i.e. there is negligible 
> market demand for it, because there is no content to speak of that 
> requires it, and there won't be any such content until more enterprises 
> are shut out of IPv4 by address exhaustion at the RIRs.

... or Microsoft customers actually start to use DA instead of their 
current VPNs.

It's my personal belief that as a lot of enterprise is letting XP die and 
go for Windows 7, they will want IPv6 for some of the new functionality.

Also, I belive customer demand might pick up quickly when services like 
Google Talk, Skype and perhaps Facetime supports IPv6 and all of a sudden 
people discover this and tell their friends that a lot of their former 
trouble from both parties sitting behind NAT is solved by getting IPv6.

I will personally tell my mom to switch to an IPv6 enabled ISP when the 
things in the last paragraph happens.

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Apr 2011 19:39:45 +0200

George,

> This traffic exists as a consequence of packets being seen to come from 2002::/16 source IP. It is not actually necessary for a complete end-to-end exchange to run to completion for the DNS lookup…

6to4-historic has the following in the IANA considerations section:

   IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as
   "deprecated", pointing to this document.  Redelegation of the domain
   for any usage requires justification via an IETF Standards Action
   [RFC5226].

are you happy with that text or would you rather that the document was silent on the issue of the 6to4 reverse zone?

cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Apr 2011 11:12:42 -0700

</chair>

To my way of thinking, it makes a lot of sense to tell people that 6to4 has problems and probably isn't a great thing to use, and to recommend that products disable it by default. I worry about playing too quickly with the prefix. My biggest worry is that it will get put into a filter somewhere and then get re-delegated for some other use. If you have watched the behavior of reputation services ("address <> appears to do bad things, we suggest you filter it") and people's antics getting off them, you can imagine the scenarios I envision.

I think pointing to the prefix as "deprecated" makes sense. I seriously hope it is never re-delegated.

---

From: Ole Troan <[email-masked]>
Date: Tue, 19 Apr 2011 20:18:21 +0200

Fred,

> I think pointing to the prefix as "deprecated" makes sense. I seriously hope it is never re-delegated.

indeed, and as the proposed says that would require IETF standards action.

cheers,
Ole

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Tue, 19 Apr 2011 18:22:38 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, April 19, 2011 11:48 AM
To: IPv6 Ops WG
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

I wonder if the operator community shares this assessment of their situation.
______
[WEG] The premise that providers aren't deploying IPv6 (especially due to lack of content) is a faulty one. I believe that you'll
find nearly every operator represented here is in the process of deploying IPv6 within the capabilities of their infrastructure and
limits of their capital budgets. May not be rapid enough for your liking, but it is definitely happening.

Every major consumer ISP serving my metropolitan area today has one very good reason for not deploying native IPv6 yet, i.e. there
is negligible market demand for it, because there is no content to speak of that requires it, and there won't be any such content
until more enterprises are shut out of IPv4 by address exhaustion at the RIRs.
______
[WEG] Keeping 6to4 around actually makes this worse, not better. It's not as much lack of content as it is that content providers
are reluctant to enable IPv6 without a url hack or a whitelist because of concerns over customer experience due to evident
brokenness. 6to4 (and teredo) is a major item that they blame for such. Several major content providers who do support IPv6 have
explicitly said that they will continue to blacklist 6to4 because it has such a non-deterministic and mostly poor customer
experience. Any application that requires IPv6 is extremely unlikely to hang that upon something as unreliable as 6to4. Regarding
whether there is market demand for IPv6 in the consumer space, as I said above, most providers are deploying IPv6 whether there are
demands or not because IPv4 is exhausting. Customers don't care what protocol is used to deliver their bits, they care that it
works. So if we wait for consumers to ask for IPv6, we're waiting for Godot.

Also, most consumer ISPs have the excuse that too many of their provider-provisioned CPE gateways do not support native IPv6
routing.
______
[WEG] There is a solution for that, and it's not 6to4. 6rd is one option if it's actually the provider's CPE infra (modems,
DSLAM/CMTS) that doesn't support IPv6. If it's the CPE router (which may be customer-owned) that doesn't support IPv6, the solution
is for the CPE gateway vendors to provide software updates with IPv6 support to ALL of their hardware regardless of age unless it's
technically impossible on a given device, so that operators aren't limited to the single option of "sorry, you'll have to replace
your equipment" in order to roll out IPv6 widely. This is *especially* true for devices which support 6to4 but not native IPv6
today. 

Wes George

---

From: Michael Newbery <[email-masked]>
Date: Wed, 20 Apr 2011 09:30:40 +1200

> your equipment" in order to roll out IPv6 widely. This is *especially* true for devices which support 6to4 but not native IPv6

My discussions with vendors however indicate that in general it IS technically impossible. Certainly there is a large amount of gear out there that has no IPv6 support, not even 6to4. This is generally made very cheaply, usually based on a reference design or chipset and using firmware and operating system provided by the chipset manufacturer. The OEM adds a little value, but mostly they have no ability to add significant extra functionality. It is likely for instance that there is just insufficient memory to add native IPv6 support. At the low end, only very recent equipment has sufficient capacity. I know of one low end CPE vendor that is adding all the right stuff, and their most recent gateway CAN be upgraded. But their previous model simply lacks the ability (in their opinion).

Furthermore, getting most CPE gateway vendors to expend the considerable effort---and money---to enable native IPv6 support on their already sold hardware would bring them in how much revenue?

The CPE situation may be shameful, and one might be justifiably grumpy with (most of) the CPE vendors for not having shipped suitable equipment for YEARS now, but dealing with the world as it is, I don't see any realistic alternative for most customers who own their own RGs apart from having to buy new ones. 

Where the provider supplies the gateway, it is the provider who is faced with the prospect of physically replacing hundreds of thousands of pieces of equipment. Apart from the cost of the equipment, the cost of the truck rolls will cause the CFO to go pale. Again, the provider SHOULD have chosen better equipment, assuming that it was in fact available (in practice, it wasn't, because enough of the SPs didn't insist on it, so the CPE manufacturers didn't do it), but regardless, this is the situation faced by many providers. We can argue about how we got into this situation: I'm only interested in figuring out how we get out of it.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Apr 2011 09:33:34 +1200

Others have answered, so I will only add a few remarks:

On 2011-04-20 03:47, james woodyatt wrote:
> Every major consumer ISP serving my metropolitan area today
> has one very good reason for not deploying native IPv6 yet,
> i.e. there is negligible market demand for it, because there
> is no content to speak of that requires it, and there won't
> be any such content until more enterprises are shut out of
> IPv4 by address exhaustion at the RIRs.

Yes, short term thinking will cause you long term business
problems every time. ISPs have been ignoring this problem for 15
years, but the time when that was in their shareholders' long
term interests is clearly past.

> Also, most consumer ISPs have the excuse that too many of
> their provider-provisioned CPE gateways do not support native
> IPv6 routing.

That excuse is on the way out, however.

   Brian

> 
> 
> -- james woodyatt <[email-masked]> member of technical staff,
> core os networking
> 
> 
> 
> _______________________________________________ v6ops mailing
> list [email-masked]

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 19 Apr 2011 23:57:35 +0200

On Tue, Apr 19, 2011 at 11:30 PM, Michael Newbery <[email-masked]> wrote:
<snip>
> Furthermore, getting most CPE gateway vendors to expend the considerable effort---and money---to enable native IPv6 support on their already sold hardware would bring them in how much revenue?

Think you are forgetting that people actual likely is going to buy new
equipment _if_ there is something in it for them. Like a complete new
series of CPEs out late 2011 or early 2012 which enable them to access
something they can't today, like a new "version" of Internet or
however you can put it.

.... other thing that can trigger people to replace "old" equipment is
thing like the new equipment also will be more eco-friendly, more
greenish...

In short, don't underestimate that people might replace their "old"
(even only 1-2 years) equipment if there is something in it for them.

-- 

Roger Jorgensen           |

---

From: Michael Newbery <[email-masked]>
Date: Wed, 20 Apr 2011 10:15:12 +1200

On 20/04/2011, at 9:57 AM, Roger Jørgensen wrote:

> equipment _if_ there is something in it for them.

Not at all. Getting people to upgrade is obviously attractive to the CPE vendors. I was responding to the suggestion that these vendors would upgrade EXISTING equipment, even if they could, and pointing out that there doesn't seem to be any obvious financial incentive for the CPE vendors to do so.

Certainly over the next few years we can hope that new equipment will do the right thing. Having said which, if you were to go out to the store RIGHT NOW and buy a residential gateway that does native IPv6, how easy would that be?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Apr 2011 00:34:27 +0200 (CEST)

On Wed, 20 Apr 2011, Michael Newbery wrote:

> Certainly over the next few years we can hope that new equipment will do 
> the right thing. Having said which, if you were to go out to the store 
> RIGHT NOW and buy a residential gateway that does native IPv6, how easy 
> would that be?

Not very, but there are those that work fairly well. D-link 815 is one 
example. D-link is actually doing a fairly good job with some of their 
series, but one has to watch out very carefully for what hw revisions one 
gets.

The 815 and 655 rev B1 does 6RD, DHCPv6-PD, SLAAC etc. It also does 6to4, 
but all IPv6 is off by default. I have tried 6RD, DHCPv6-PD and SLAAC and 
there are rough edges to smoothen, but the basic function is there.

I have high hopes that we'll see more vendors release well working code 
during the year (first revisions seem to be understandably rough but basic 
functions ar ethere).

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Apr 2011 00:36:02 +0200

Hi Gunter,

Is not what I want is what is already there and we better provide better
support to it, instead of killing it, because unfortunately, the ideal
situation (the one I will like, native IPv6 tomorrow) will not be there
soon. If we kill 6to4, instead of provide guidance about hot to fix it,
then we will have more delays for the IPv6 deployment.

You could tell me to use 6rd, however, is LESS supported than 6to4, and we
can't ask ISP to replace the CPEs to go to 6rd, in that case native IPv6
is the way forward, the investment is the same. 6rd will avoid native IPv6
deployment at least for some time.

By the way, read the recent message form Comcast in NANOG mail exploder:
http://mailman.nanog.org/pipermail/nanog/2011-April/035380.html

May be the problem is that some of people trying to kill 6to4 has not
actively deployed by themselves 6to4 and 6to4 relays ?

I think there has been enough examples and discussions not to accept the
Last Call at least in the current version of this document, which clearly
has, at least, text to be updated to reflect a better reality. Consensus
can't be declared in this situation, when the draft is broken, at least in
some parts of the text.

If we believe that 6to4 is the last resort, then make it clear that way:
Make mandatory the use of RFC3484 (default address selection), drop the
6to4 anycast, but don't kill 6to4 itself. This document send the wrong
signal to the market. If we want to signal the market and the ISPs that
6to4 is a temporary measure, say it should be implemented in conjunction
with RFC3484, and even state a time frame for dropping it.

Regards,
Jordi

-----Mensaje original-----
De: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Responder a: <[email-masked]>
Fecha: Tue, 19 Apr 2011 16:04:13 +0200
Para: "George, Wes E IV [NTK]" <[email-masked]>, Jordi Palet
Martinez <[email-masked]>, <[email-masked]>
CC: Ron Bonica <[email-masked]>
Asunto: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Apr 2011 00:40:20 +0200 (CEST)

> actively deployed by themselves 6to4 and 6to4 relays ?

My employer has run globally reachable 6to4 and teredo relays for the last 
2+ years. I want it to go away asap.

Right now it causes more problems than it solves. It was nice to get 
initial testing for IPv6 but just like 6bone it should go away.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Apr 2011 00:40:23 +0200

Ok, so let's go for the draft-ietf-v6ops-6to4-advisory, as we seem to have
agreement on that, but not on 6to4-to-historic.

In my context and the context of my customers, where 6to4 works much
better than what is being reported, having some IPv6 support is much
better than not having it.

Regards,
Jordi

-----Mensaje original-----
De: "George, Wes E IV [NTK]" <[email-masked]>
Responder a: <[email-masked]>
Fecha: Mon, 18 Apr 2011 13:57:23 +0000
Para: Jordi Palet Martinez <[email-masked]>, "[email-masked]"
<[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

>[WEG] Gross oversimplification. This isn't just about filters, and it
>certainly isn't just about operators' filters. Even at best,
>2) Making sure that protocols are better, for example by means of
>ensuring mechanisms such as "happy eyeballs" make a smart decision
>about what to use
>______
>[WEG] So... assuming we get critical mass on implementing happy eyeballs
>in a reasonable timeframe (which in and of itself is a
>stretch), it tests, confirms what we already know, which is that 6to4 is
>not really a viable option for a large portion of the users
>when compared with IPv4 or with native IPv6, and it never or almost never
>uses 6to4. Exactly how does that improve the situation and

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Apr 2011 00:47:40 +0200

And like 6bone, then stamp a phase-out plan, which has been suggested
already.

Regards,
Jordi

---

From: George Michaelson <[email-masked]>
Date: Wed, 20 Apr 2011 08:47:08 +1000

> are you happy with that text or would you rather that the document was silent on the issue of the 6to4 reverse zone?

I should learn to read better. 

I am happy with that text. I think it covers the situation pretty well exactly.

-george

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 19 Apr 2011 15:54:22 -0700

> agreement on that, but not on 6to4-to-historic.

This is your opinion.

Articulating the sense of the group is not your responsibility. we have
2418/3934 to instruct us for that, the WGLC ends 5/1/2011.

I think we can be assured that the chairs will attempt to account for
the diversity of opinions that have and have yet to be expressed on this
issue.

thanks
joel

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Tue, 19 Apr 2011 23:18:57 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Newbery
Sent: Tuesday, April 19, 2011 5:31 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

My discussions with vendors however indicate that in general it IS technically impossible. Certainly there is a large amount of gear
out there that has no IPv6 support, not even 6to4. This is generally made very cheaply, usually based on a reference design or
chipset and using firmware and operating system provided by the chipset manufacturer. The OEM adds a little value, but mostly they
have no ability to add significant extra functionality. It is likely for instance that there is just insufficient memory to add
native IPv6 support. At the low end, only very recent equipment has sufficient capacity. I know of one low end CPE vendor that is
adding all the right stuff, and their most recent gateway CAN be upgraded. But their previous model simply lacks the ability (in
their opinion).

[WEG] 5 letters... DDWRT. It shows as proof positive that there is a MUCH wider variety of hardware that CAN support IPv6 that
DOESN'T due to a specific choice on the part of the OEM vendor. Yes, there are going to be some that actually can't, and "support"
means different things on different hardware, but assuming that most of the ones that don't is due to hardware limitations is being
quite generous. 

Furthermore, getting most CPE gateway vendors to expend the considerable effort---and money---to enable native IPv6 support on their
already sold hardware would bring them in how much revenue?
[WEG] Absolutely true. Doesn't make it any less the right thing to do. 
I've said before that perhaps it's time for the hardware vendors to embrace the open source market to continue support for devices
that they no longer can/want to write software updates for themselves. Not just pointing to the DD-WRT page and saying "have fun"
but actually pulling an image and supporting it - in other words, just saving yourself the code work, not necessarily the
certification.

The CPE situation may be shameful, and one might be justifiably grumpy with (most of) the CPE vendors for not having shipped
suitable equipment for YEARS now, but dealing with the world as it is, I don't see any realistic alternative for most customers who
own their own RGs apart from having to buy new ones. 
[WEG] Also true. Doesn't make it suck any less. Another commenter implied that people would be willing to buy new gear if there's
something in it for them - if we could have convinced people that there was something in it for them with IPv6, we would have done
it years ago. As it is, the best chance we have is that CGN/NAT444 will suck so much that moving to IPv6 will actually represent
"something in it for them"

Wes George

---

From: Michael Newbery <[email-masked]>
Date: Wed, 20 Apr 2011 11:50:56 +1200

> means different things on different hardware, but assuming that most of the ones that don't is due to hardware limitations is being

DDWRT runs on a relatively high end piece of equipment, namely a 802.11 router. There are a lot of plain old WAN-LAN routers though, especially in the xDSL world. It was to them that I was referring. I estimate that the majority of our xDSL customers have gateways that are incapable of being firmware upgraded to IPv6. Even if they have a DDWRT capable router at home that does them no good if the WAN/LAN router can't do IPv6 native.
 
Cable is slightly different, with the cable modem typically being (mostly) layer 2. I estimate that about 50% of our cable customers run some sort of RG and that the other 50% currently have a single PC directly connected. Of the 50% that have RGs, I would estimate that the majority are not capable of being firmware upgraded to IPv6 native. Fortunately, the 50% that have directly connected PCs *are* mostly capable, via an OS upgrade.

And lest anyone misunderstand, I am trying as hard as I can, as fast as I can, to roll out native IPv6 support. I consider tunnels a stopgap and LSN an ineffective abomination (to which I fortunately don't have to resort.)

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Apr 2011 17:12:40 -0700

On Apr 19, 2011, at 11:22 AM, George, Wes E IV [NTK] wrote:

> [WEG] The premise that providers aren't deploying IPv6 (especially due to lack of content) is a faulty one. I believe that you'll find nearly every operator represented here is in the process of deploying IPv6 within the capabilities of their infrastructure and limits of their capital budgets. May not be rapid enough for your liking, but it is definitely happening.

I think there are two sides to that question, both valid.

I'll refer you to comments on this list, and to the year-old OECD report at http://www.oecd.org/dataoecd/48/8/44961688.pdf, and specifically slide 16 of that report. Any statement that service providers are not implementing IPv6 certainly isn't reflected in the statistics, nor is it representative in the statements of the operators.

What I think was being asked was not whether the operators are deploying the technology, but to what extent it was available to their customers - the general public. Comcast has been fairly forward about their trials with the public, but that's not universal. I suspect that we have three issues between us and wide-scale IPv6 usage:
  - content provider capabilities, including folks like Google, Akamai, and Youtube, but also including your favorite bank, your church, and other web sites you use.
  - CPE router deployment, which today is almost universally IPv4-only and acts as a diode preventing general IPv6 access.
  - enterprise/smb network deployment, which is generally throttled by business case questions - "I understand why <> needs to deploy it, but I have enough addresses for my own use for the immediate future".

What I think Brian is looking for is for the industry to overcome those issues, and as a result give the end user a felt need to deploy. Not just a "Fred Baker would be happier if you did" or "Wes George would be happier if you did" kind of reason, but a "You will be happier if you deploy" kind of reason.

    ftp://ftpeng.cisco.com/fred/v6ops/Nightmare.pdf

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 20 Apr 2011 10:08:58 +0200

GV> I guess you are speaking for the simple home-user. In that case what limits a user from obtaining a managed commercial service for IPv6? That way he gets at least SLA like commitments from his favourite services provider.

GV> If its an enterprise there are better solutions out there that deliver managed tunneling services.. pick your preferred vendor and they will give you some options.

G/

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 20 Apr 2011 10:11:57 +0200

I think that a signal like '6to4' is now historical is a quite clear
headliner... why keep a technology, which gives grief for the Internet
due to bad connectivity alive?

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: 18 April 2011 19:56
To: Nick Hilliard
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Am I making myself clear?  Because I really can't be more explicit than
that.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 20 Apr 2011 10:15:51 +0200

James,

<>start snip<>
Too many service providers today have not announced any IPv6 transition
plans, leaving our customers with only 6to4 as their only hope for
acquiring even marginally acceptable IPv6 services with a reasonable
level of configuration human interface burden.  Until this changes, I
doubt Apple and other equipment makers will stop supporting 6to4 routing
in their products, and people will continue to use it despite the IETF
deprecation, and IPv6 brokenness related to 6to4 will probably remain at
the unacceptable levels that operators and content providers hope to
address with the publication of this draft.
<> end snip<>

It will be apple choice to follow RFC or not. It would not be the first
time a big user OS does not follow an RFC intentionally.
It would be pitty and provide some bad karma for people and
organizations indeed, however, as mentioned it wouldn't be the first
time

G/

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 20 Apr 2011 10:36:20 +0200 (CEST)

On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote:

> GV> I guess you are speaking for the simple home-user. In that case what 
> limits a user from obtaining a managed commercial service for IPv6? That 
> way he gets at least SLA like commitments from his favourite services 
> provider.
>
> GV> If its an enterprise there are better solutions out there that 
> deliver managed tunneling services.. pick your preferred vendor and they 
> will give you some options.

In reality the situation slightly worse, let me cite our example:

1. NIIF/Hungarnet started to provide native IPv6 DSL service around 2008 - 
we wanted to do it earlier, but due to a bug in DSLAM equipment stopped us 
to provide it. Our LNS equipment was capable of handling DHCPv6-PD. We had 
to wait the telecom operator (1.5 years) to fix the problem. As an interim 
solution we started experimenting with 6to4 and Teredo. It was working 
reasonably well.

2. After fixing the DSLAM bug in the provider network and deployment of 
native IPv6 DSL service we considered switching 6to4 relay off. But there 
was a demand from administrators of our users (Universities, Research 
Institutes, Libraries) to let it run for further experimenting: There is 
only one other provider started provide native IPv6 DSL. The two big DSL 
player in Hungary is still testing and piloting their (for at least another 
year) IPv6 DSL services.

In my opinion tend to be similar to Jordi's. 6to4 is good for 
experimenting with IPv6. If you need IPv6 service use native solution. But 
if there no solution on the market what to do?

According to our policy our 6to4 relay is only for experimenting with IPv6 
technology..... What about 6to4 relabeled to experimental?

Best Regards,
 		Janos Mohacsi

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 20 Apr 2011 10:39:41 +0200

For experiments, why not use IPv6 over IPsec, or manual tunnels or DMVPN or....
All managed solutions, that work pretty well and none have the downside negative side-impacts of 6to4.

G/

-----Original Message-----
From: Mohacsi Janos [mailto:[email-masked]] 
Sent: 20 April 2011 10:36
To: Gunter Van de Velde (gvandeve)
Cc: Philip Homburg; Roger Jørgensen; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Best Regards,
 		Janos Mohacsi

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 20 Apr 2011 10:57:30 +0200 (CEST)

> All managed solutions, that work pretty well and none have the downside negative side-impacts of 6to4.

Dear Gunter,
 	All the methods, you mentioned is requires some form of management 
on providers side.
 	Can you list the devices/softwares supporting the methods you have 
mentioned?
 	Best Regards,
 			Janos Mohacsi

> Cc: Philip Homburg; Roger J?rgensen; [email-masked]

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 20 Apr 2011 11:04:38 +0200

Management on SP side? Not really as they do go end-2-end.

Manual tunnels can be used when deploying a tunnel broker for example which can be 
semi automated, IPvx over IPsec is the base of some other dynamic tunnel mechanisms 
like DMVPN, which can cary v6 over a v4 infrastructure for enterprise customers (DMVPN is 
a Cisco solution, but I am sure there are others more open like openVPN I believe).

Having an unmanaged service will ofcours require less management then a managed solution.

G/

-----Original Message-----
From: Mohacsi Janos [mailto:[email-masked]] 
Sent: 20 April 2011 10:58
To: Gunter Van de Velde (gvandeve)
Cc: Philip Homburg; Roger Jørgensen; [email-masked]
Subject: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Dear Gunter,

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Apr 2011 10:36:22 +0100

> due to bad connectivity alive?

No-one's disputing the intent.  What's at issue here is whether vendors 
will act on a generic recommendation to deprecate the protocol (which is 
what's being proposed), or whether they need a concrete plan for service 
termination before they will pull support from their routing stacks (which 
is what at least one vendor is suggesting).

Problem is, if some sort of compromise isn't reached, then in a couple of 
years time, the v6ops WG is going to stick its hand up and say honestly, 
"we've deprecated 6to4", and the vendors are going to stick their hands up 
and say honestly, "we're fully compliant with all the relevant RFCs".  Both 
will be technically correct, and the end result will be that 6to4 will 
never, ever die.  Meanwhile, operators will froth at the mouth and 
end-users will wonder why their v6 connectivity is broken.

It's not really in anyone's interest to have an argument about due process 
which ends up with Internet end-users getting the bum deal.  As an end-user 
and operator, I'm sick and tired of being at the receiving end of this sort 
of thing from vendors due to internal political wrangling.

I suggest that if Ole feels that a formal end-date for removal of 2002::/16 
and 192.88.99.0/24 is out of scope for this draft, that we create a very 
small new ID which explicitly states a date on which IANA formally 
deregisters both prefixes and requests that operators filter them from the 
DFZ.  It's not a biggie, but if it's what's needed to get vendors to ditch 
support, then let's just be pragmatic and do it.

You can count this as a formal offer to write a very short draft specifying 
an specific end-date for 6to4, if this isn't going to appear in 
draft-ietf-v6ops-6to4-to-historic.

Nick

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Apr 2011 12:56:56 +0200

Nick,

> No-one's disputing the intent.  What's at issue here is whether vendors will act on a generic recommendation to deprecate the protocol (which is what's being proposed), or whether they need a concrete plan for service termination before they will pull support from their routing stacks (which is what at least one vendor is suggesting).
> 
> Problem is, if some sort of compromise isn't reached, then in a couple of years time, the v6ops WG is going to stick its hand up and say honestly, "we've deprecated 6to4", and the vendors are going to stick their hands up and say honestly, "we're fully compliant with all the relevant RFCs".  Both will be technically correct, and the end result will be that 6to4 will never, ever die.  Meanwhile, operators will froth at the mouth and end-users will wonder why their v6 connectivity is broken.
> 
> It's not really in anyone's interest to have an argument about due process which ends up with Internet end-users getting the bum deal.  As an end-user and operator, I'm sick and tired of being at the receiving end of this sort of thing from vendors due to internal political wrangling.
> 
> I suggest that if Ole feels that a formal end-date for removal of 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we create a very small new ID which explicitly states a date on which IANA formally deregisters both prefixes and requests that operators filter them from the DFZ.  It's not a biggie, but if it's what's needed to get vendors to ditch support, then let's just be pragmatic and do it.
> 
> You can count this as a formal offer to write a very short draft specifying an specific end-date for 6to4, if this isn't going to appear in draft-ietf-v6ops-6to4-to-historic.

I'd rather not specify an end date.

I don't think the goal here is to make vendors remove the 6to4 code from their implementations. and it isn't like we need to recycle the 2002::/16 prefix any time soon.

I personally don't think an end date would make any difference from a vendor perspective. it isn't like we can upgrade all hardware and software in the field anyway.

what I hope this document can be used is as a strong encouragement to vendors to not enable it by default, and at least make it break less. by implementing RFC3484bis, implementing a reachability check for the default gateway, not enable it if the IPv4 address is rfc1918 and I'm sure a few more. (and yes, the fruity machine I'm sitting on right now doesn't implement any of these). 

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Apr 2011 14:08:23 +0200

Hi,

> agreement on that, but not on 6to4-to-historic.

We have rough consensus for 6to4-to-historic.

> better than not having it.

Feel free to leave it enabled on your machines, nobody is yanking out
the code from your implementations.

But *listen* to folks like Tore who have had serious problems enabling 
content on IPv6 (and I assume this is what you also want to see!) 
*because* of 6to4.

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Apr 2011 14:13:59 +0200

Hi Gert,

I agree in the goal, we want IPv6 native being deployed and making sure to
avoid failures, but not the way we are doing with this document.

I think there has been enough voices in favour but also many against, so I
don't think this is consensus.

There have been major objections, such as some text in the draft which is
not true or clear enough. This should be corrected at least, despite you
still think there is consensus, we can't have consensus in a document that
has inconsistencies such as "hasn't been deployed" (it reads as 6to4
itself, not a specific way to use it), which is not true, right ?

Regards,
Jordi

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Apr 2011 21:16:33 +0900

+1

I, for one, really don't see us adding networks to the Google over
IPv6 program that have a large 6to4-preferring population.

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 20 Apr 2011 10:37:32 -0700

Hi Ole,

I personally don't think an end date would make any difference from a vendor perspective. it isn't like we can upgrade all hardware and software in the field anyway.
what I hope this document can be used is as a strong encouragement to vendors to not enable it by default, and at least make it break less. by implementing RFC3484bis, implementing a reachability check for the default gateway, not enable it if the IPv4 address is rfc1918 and I'm sure a few more.

Shouldn't the focus then be on those specific recommendations which address the specific known problems, rather than blanket deprecation, which enjoys broad support of operators but doesn't have a clear meaning to vendors, as you indicate above?

I completely agree that all the example recommendations you listed are addressing specific problems (RFC 3484bis regarding 6to4, reachability check for gateway, not enabling 6to4 for RFC 1918 addresses) and vendors should follow them, if they aren't already. But once they (and any other specific recommendations, if there are any) are followed, from the current draft it is not clear to me what the move to historic for RFC 3056 is trying to achieve or why it is necessary.

Thank you,
Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, April 20, 2011 3:57 AM
To: Nick Hilliard
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Nick,

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Apr 2011 19:46:20 +0200

Hi,

On Wed, Apr 20, 2011 at 10:37:32AM -0700, Dmitry Anipko wrote:
> it is not clear to me what the move to historic for RFC 3056 is trying to achieve or why it is necessary.

What do you hope to achieve by *not* moving RFC 3056 to historic?

Gert Doering
        -- NetMaster

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 20 Apr 2011 10:55:15 -0700

Hi Gert,

To answer your question - avoid breaking those end users for whom 6to4 currently works and is the only available option for IPv6 connectivity, since it was stated on these WGLC threads that while many ISPs have deployment efforts under way, not that many ISPs already have *today* IPv6 offering to the end users.

Thank you,
Dmitry

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Wednesday, April 20, 2011 10:46 AM
To: Dmitry Anipko
Cc: Ole Troan; Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Hi,

Gert Doering
        -- NetMaster

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Apr 2011 20:13:22 +0200

Jordi,

> itself, not a specific way to use it), which is not true, right ?

is the text in question this:
  "The managed IPv6 transition mechanism "Connection of IPv6 Domains via
   IPv4 Clouds (6to4)" described in [RFC3056] has rarely if ever been
   deployed."

from the introduction?
note that it reads "_managed_".

then later in the document (section 3.) it has:

   "One model of 6to4 deployment as described in section 5.2, RFC3056,
   suggests that a 6to4 router should have a set of managed connections
   (via BGP connections) to a set of 6to4 relay routers.  While this
   makes the forward path more controlled, it does not guarantee a
   functional reverse path.  In any case this model has the same
   operational burden has manually configured tunnels and has seen no
   deployment in the public Internet."

I think perhaps the confusion happens, because this deployment model of 6to4 is so unfamiliar.
the idea was for the 6to4 router to run BGP with a set of relay routers, where each relay router would only advertise prefixes that it was willing to relay for.

if the introduction and the paragraph in section 3 isn't clear enough, please provide improvements.

what other major objections are you referring to?

cheers,
Ole

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Wed, 20 Apr 2011 18:15:32 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dmitry Anipko
Sent: Wednesday, April 20, 2011 1:55 PM
To: Gert Doering
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

To answer your question - avoid breaking those end users for whom 6to4 currently works and is the only available option for IPv6
connectivity, since it was stated on these WGLC threads that while many ISPs have deployment efforts under way, not that many ISPs
already have *today* IPv6 offering to the end users.

[WEG] Then I'd encourage you to reread the draft. 

Specifically this: 
	It is expected that disabling 6to4 in the IPv6 Internet will take
  	some time.  The initial approach is to make the 6to4 a service of
   	"last resort" in host implementations, ensure that the 6to4 service
   	is disabled by default in 6to4 routers, and deploy native IPv6
   	service.  In order to limit the impact of end-users, it is
   	recommended that operators retain their existing 6to4 relay routers
   	and follow the recommendations found in
   	[I-D.ietf-v6ops-6to4-advisory].  When traffic levels diminish, these
   	routers can be decommissioned.

Then explain how this draft is going to break end users for whom 6to4 currently works.
You should be far more worried about CGN + non 1918 internal NAT pools as a means to break currently working 6to4 users. Further,
6to4 is almost *never* the only option for IPv6 connectivity, even if the upstream is a laggard in deploying IPv6.

Wes George

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Apr 2011 20:22:03 +0200

Dmitry,

[...]

> Shouldn't the focus then be on those specific recommendations which address the specific known problems, rather than blanket deprecation, which enjoys broad support of operators but doesn't have a…

I don't think we should take the users out of the equation either.
with my user hat on I have tried 6to4 on numerous occasions, I have _always_ been forced to turn it off.

isn't there a clear meaning to vendors? I wrote this document in the first place to be able to convince one part of our business that they must stop shipping products with 6to4 enabled by default.

> I completely agree that all the example recommendations you listed are addressing specific problems (RFC 3484bis regarding 6to4, reachability check for gateway, not enabling 6to4 for RFC 1918 addre…

sure, what does an IETF document ever achieve? ;-)
make a clear statement from the IETF, that it does not consider 6to4 as a valid mechanism to achieve IPv6 connectivity.
remove that particular option from the table when a user, operator or vendor is considering what should be deployed/implemented...

a lot of people have stated how 6to4 is slowing down and hindering IPv6 deployment rather than accelerating it. if this document can make vendors stop contributing to the problem by exposing innocent bystanders to a mechanism that doesn't work then a lot would be done. obviously consenting adults can do what they like.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Apr 2011 20:30:16 +0200

Dmitry,

> RFC 3056 has other scenarios, such as e.g. in section 5.1 and 5.4. While the statement in the draft-ietf-v6ops-6to4-to-historic that " IPv6 transition mechanism... has rarely if ever been deployed"…

interesting point.
6to4 has basically 3 modes.

1) 6to4 only. a 6to4 node can only reach other 6to4 node.
2) 6to4 with managed set of relays (with BGP routing protocol between 6to4 router and relays)
3) 6to4 with unmanaged relay and default route

2 has never seen deployment.

would 1 by itself have value? and for what?

cheers,
Ole

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 20 Apr 2011 12:16:36 -0700

Hello Ole,

>> would 1 by itself have value? and for what?

As far as I know - it does, for example, for peer to peer connectivity of applications which can work better with not translated IPv6 rather than translated IPv4 address.

In addition, in scenarios which rely on IPv6 and need IPV6 addressing, but do not necessarily need connectivity with the rest of IPv6 Internet (e.g. connectivity of remote clients to corporate networks via managed tunnels), ability to have a globally unique address range without support from ISP is also useful. For these scenarios, ULAs may also be used once 6to4 is retired at some point is future, but that would require renumbering of customer network from one temporary solution to another one (since in future they likely would migrate from ULA to ISP provided prefix).

Thanks,
Dmitry

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, April 20, 2011 11:30 AM
To: Dmitry Anipko
Cc: Fred Baker; [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Dmitry,

interesting point.

cheers,
Ole

---

From: Doug Barton <[email-masked]>
Date: Wed, 20 Apr 2011 12:30:25 -0700

On 04/20/2011 02:36, Nick Hilliard wrote:
> I suggest that if Ole feels that a formal end-date for removal of
> 2002::/16 and 192.88.99.0/24 is out of scope for this draft, that we
> create a very small new ID which explicitly states a date on which IANA
> formally deregisters both prefixes and requests that operators filter
> them from the DFZ.  It's not a biggie, but if it's what's needed to get
> vendors to ditch support, then let's just be pragmatic and do it.

I would be supportive of such a draft. As an OS implementor I would find 
it very useful to have a clean, bright line. I disagree with those who 
have said that setting a date is not in IETF's purview, there are plenty 
of examples of "flag days" in the past (most relevant is likely 6bone).

Meanwhile, in response to the argument that "We must preserve 6to4 at 
all costs because it may be some people's only access to IPv6" I say, 
"So what?" There is no IPv6-only content now, and in the short term 
there isn't going to be any. No content provider is going to risk 
cutting off 99.9% of the Internet from their content. Long before there 
is such a thing as "IPv6-only content" the transition to widely 
accessible native IPv6 will have been complete, so 6to4 will be 
irrelevant. For those tiny percentage of people who actually "need" IPv6 
for some reason (now, or in the future), other valid tunneling protocols 
already exist, and don't show any signs of going away.

To repeat myself (again), whatever benefits derive from 6to4 are so 
tiny, and the costs for keeping it around are so large, we should be 
doing everything we can to kill it off sooner rather than later.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 20 Apr 2011 12:40:53 -0700

Hello Ole,

I agree we should not take users out of the pictures, and I think no users would be hurt if the vendors implemented the kind of specific recommendations you mentioned.

>> isn't there a clear meaning to vendors? 

Let me quote James Woodyatt from Apple: " leaving our customers with only 6to4 as their only hope for acquiring even marginally acceptable IPv6 services with a reasonable level of configuration human interface burden. Until this changes, I doubt Apple and other equipment makers will stop supporting 6to4 routing in their products, and people will continue to use it despite the IETF deprecation, and IPv6 brokenness related to 6to4 will probably remain at the unacceptable levels that operators and content providers hope to address with the publication of this draft. On the other hand, if IETF publishes a standards track document with phaseout plan for 2002::/16, then product managers can know with reasonable certainty when their 6to4 routing feature will no longer be useful to any of their customers, and they can plan accordingly."

You also wrote " I don't think the goal here is to make vendors remove the 6to4 code from their implementations. ", while from the many messages on this topic from operators it seems to me that something like this would be ideal in their opinion.

>> I wrote this document in the first place to be able to convince one part of our business that they must stop shipping products with 6to4 enabled by default.
>> if this document can make vendors stop contributing to the problem by exposing innocent bystanders to a mechanism that doesn't work then a lot would be done.

I agree with the goal, but think essentially the same effect could be achieved by listing very specific recommendations to vendor implementations, such as the ones you mentioned.

>> remove that particular option from the table when a user, operator or vendor is considering what should be deployed/implemented...

I agree that once majority of customers indeed have a choice whether to subscribe to their ISP IPV6 offering, 6to4 will no longer be needed. But are we there yet? 

Thank you,
Dmitry

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, April 20, 2011 11:22 AM
To: Dmitry Anipko
Cc: Nick Hilliard; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Dmitry,

[...]

cheers,
Ole

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Wed, 20 Apr 2011 21:08:29 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dmitry Anipko
Sent: Wednesday, April 20, 2011 3:17 PM
To: Ole Troan
Cc: [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Hello Ole,

>> would 1 by itself have value? and for what?

As far as I know - it does, for example, for peer to peer connectivity of applications which can work better with not translated
IPv6 rather than translated IPv4 address.
[WEG] If there's address translation happening for IPv4, it's a tenuous assumption at best that 6to4 will work at all, let alone
better. 

In addition, in scenarios which rely on IPv6 and need IPV6 addressing, but do not necessarily need connectivity with the rest of
IPv6 Internet (e.g. connectivity of remote clients to corporate networks via managed tunnels), 
[WEG] You really think that corporate networks will rely on 6to4 for a business-critical application when we can't even get content
providers to serve IPv6 content via 6to4 due to concerns over a bad user experience? Even if you remove the relays from the picture,
you still have to contend with the other ways that 6to4 breaks.

Wes George

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 20 Apr 2011 14:22:29 -0700

Hello Wes,

Regarding corporate network scenarios: I think you may have missed "managed tunnels" in the scenario description (and those tunnels may or may not be 6to4), used together with 6to4 addressing - the managed tunnels alleviate the 6to4 tunnel QoS concerns in such deployments. 

Thanks,
Dmitry

-----Original Message-----
From: George, Wes E [NTK] [mailto:[email-masked]] 
Sent: Wednesday, April 20, 2011 2:08 PM
To: Dmitry Anipko; Ole Troan
Cc: [email-masked]; [email-masked]; Ron Bonica
Subject: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dmitry Anipko
Sent: Wednesday, April 20, 2011 3:17 PM
To: Ole Troan
Cc: [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Hello Ole,

Wes George

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Apr 2011 23:38:16 +0200

Dmitry,

> In addition, in scenarios which rely on IPv6 and need IPV6 addressing, but do not necessarily need connectivity with the rest of IPv6 Internet (e.g. connectivity of remote clients to corporate netw…

on second thought I don't think 1 is a true 6to4 mode. how would a 6to4 router function if it only had connectivity to the 6to4 network? if it advertised itself as an IPv6 default router it would end up blackholing any traffic to the native IPv6 Internet. it could use hacks like what we put in for ULAs in RFC6204, but these aren't described anywhere.

with regards to using the 6to4 prefix as a global unique address. given that is/will become a last resort in the SAS/DAS policy table, is that really what you want for a managed tunnel? yes, it does give a globally unique address, but one that is based on the public IPv4 address received from the ISP (without any NAT in between). 

using the 2002::/16 address space outside the remit of 6to4 sounds very dubious though...

splendid that this draft gets such a thorough review. I had this nagging doubt for a while that there was some use case for 6to4 somewhere, one that could only be solved with 6to4. that I haven't seen and I'm pretty confident that we aren't throwing out the baby with the bath water.

cheers,
Ole

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 20 Apr 2011 14:59:01 -0700

Hello Ole,

>> if it advertised itself as an IPv6 default router it would end up blackholing any traffic to the native IPv6 Internet. it could use hacks like what we put in for ULAs in RFC6204, but these aren't described anywhere.

I assume you're referring to G-4 in section 4.1 RFC 6204? If so, I'm not sure why that is called a hack. Per RFC 4861 an RA with router lifetime = 0, but more specific route lifetime != 0 is a valid RA as I understand. So, unless there is some reason why it would not be a valid RA, yes, it will work. I didn't test other OSes, but it does work fine for Windows.

>> given that is/will become a last resort in the SAS/DAS policy table, is that really what you want for a managed tunnel?

Yes, because these corporate scenarios don't work with e.g. RFC 1918 IPv4 addresses (or work much worse, than with IPv6 addresses, even if those are 6to4 based), popular in corporate networks.

>> I had this nagging doubt for a while that there was some use case for 6to4 somewhere, one that could only be solved with 6to4. that I haven't seen and I'm pretty confident that we aren't throwing out the baby with the bath water.

Good that we made it here :), because on the baby statement, actually there are DirectAccess customers who use 6to4 addressing in corporate scenarios, who will be affected by this. And as James pointed out that until ISPs actually provide IPv6 to consumers, 6to4 seems to be the only viable alternative for those.

Thank you,
Dmitry

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, April 20, 2011 2:38 PM
To: Dmitry Anipko
Cc: Fred Baker; [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Dmitry,

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Apr 2011 11:30:47 +1200

On 2011-04-20 21:36, Nick Hilliard wrote:
...
> vendors to ditch support, then let's just be pragmatic and do it.

It would be a biggie and I would oppose it very strongly. This would
break deployed systems and we should never, ever do that. It isn't the
point - the point is to get rid of unintentional 6to4 deployed by
default.

"First, do no harm." [Hippocrates, attrib.]

On 2011-04-21 06:30, Ole Troan wrote:
...
> would 1 by itself have value? and for what?

Any form of closed user group that is not subject to NAT44. It's not
for us to say whether that is a good or bad thing, but just as for
successful users of 3), it's not for us to break it either.

Hence, the current draft says exactly what should be said, and we
should say no more.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 20 Apr 2011 17:19:04 -0700

On Apr 20, 2011, at 4:30 PM, Brian E Carpenter wrote:
> It would be a biggie and I would oppose it very strongly. This would break deployed systems and we should never, ever do that.

Alas, despite notable voices of opposition, I suspect that consensus can be formed in IETF around the swift and merciless breaking of all the deployed and otherwise working 6to4 systems in exchange for facilitating the rollout of more commercially viable IPv6 services.

I plan to submit a draft soon that specifies a formal phaseout plan for 6to4, and we shall see how much opposition is really out there.  If consensus can emerge in IETF around a formal phaseout plan, then we will all save a lot of time and energy that we would otherwise spend maintaining and improving support for 6to4 in forthcoming host and router equipment regardless of whether I-D.ietf-v6ops-6to4-to-historic is published in the RFC series or not.

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 21 Apr 2011 10:04:37 +0200

On Wed, Apr 20, 2011 at 9:40 PM, Dmitry Anipko
<[email-masked]> wrote:
<snip>

> I agree that once majority of customers indeed have a choice whether to subscribe to their ISP IPV6 offering, 6to4 will no longer be needed. But are we there yet?

The interesting thing about this entire 6to4 discussing is that there
is pretty much two sides

* Those that wish 6to4 gone because it cause more problem than it
solve, they also consider it too costly to fix considering other
options.

* Then there is the "other" side that is interesting... that is MS and
Apple which want to give their customer IPv6 which is great, I can't
praise those companies enough for their effort on IPv6. Espesial
Microsoft and their efford over the last 10+ years.

But, isn't it time to move on, beyond IPv6 access for any cost and to
a place where we say either Good IPv6 access or none?

-- 

Roger Jorgensen           |

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 21 Apr 2011 11:06:28 +0200

Inline: GV>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: 21 April 2011 02:19
To: Brian E Carpenter
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

> It would be a biggie and I would oppose it very strongly. This would
break deployed systems and we should never, ever do that.

Alas, despite notable voices of opposition, I suspect that consensus can
be formed in IETF around the swift and merciless breaking of all the
deployed and otherwise working 6to4 systems in exchange for facilitating
the rollout of more commercially viable IPv6 services.

GV> making a technology historic doesn't break it. The guidelines in the
-advisory- draft is what make this not happen and actually improve the
quality of the user experience for the existing user base.

I plan to submit a draft soon that specifies a formal phaseout plan for
6to4, and we shall see how much opposition is really out there.  If
consensus can emerge in IETF around a formal phaseout plan, then we will
all save a lot of time and energy that we would otherwise spend
maintaining and improving support for 6to4 in forthcoming host and
router equipment regardless of whether I-D.ietf-v6ops-6to4-to-historic
is published in the RFC series or not.

GV> not sure a phase-out plan will bring additional value.

G/

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Apr 2011 14:17:22 +0300 (EEST)

On Sun, 17 Apr 2011, Fred Baker wrote:
> (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a
> statement or finding additional issues that need to be addressed, please post your comments to the list.
> 

I oppose this document and moving 6to4 to historic just yet.

No IETF document requires 6to4, and therefore there is nothing the 
IETF needs to do to allow vendors to turn it off.

"Deprecation by standardization body decree" when vendors still 
continue shipping it will cause a mismatch between operational reality 
and the IETF.  It's futile.  We should first convince the (major) 
vendors that this what they want to do, wait that they start to do it, 
and then begin the deprecation.

If we want to give advisories to the vendors or users, we can put 
those to the advisory draft.

I however do agree that the following subset deprecation described in 
Section 4 makes sense:

    1.  IPv6 nodes SHOULD treat 6to4 as a service of "last resort" as
        recommended in [I-D.ietf-6man-rfc3484-revise]
    2.  Implementations capable of acting as 6to4 routers SHOULD NOT
        enable 6to4 without explicit user configuration.  In particular,
        enabling IPv6 forwarding on a device, SHOULD NOT automatically
        enable 6to4.
    3.  If implemented in future products 6to4 SHOULD be disabled by
        default.

This is internally inconsistent with S 1: "Declaring the mechanism 
historic is not expected to have immediate product implications."

What's the point if the goal is not to have immediate product 
implications?

I'd say that the best approach is likely to just discontinue this 
document.  After we've gotten major vendors on board with the subset 
deprecation, we can start working on the rest.

Editorial:

Many things I object to, but listing these is not worth the effort. 
Some specifics though:
  - First sentence of S 1 is misleading as already discussed and should
    be removed/rephrased.  No need to even mention the BGP model.

-- 
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: Cameron Byrne <[email-masked]>
Date: Thu, 21 Apr 2011 07:40:47 -0700

On Apr 21, 2011 1:04 AM, "Roger Jørgensen" <[email-masked]> wrote:
> >>> remove that particular option from the table when a user, operator or
vendor is considering what should be deployed/implemented...
> >
> > I agree that once majority of customers indeed have a choice whether to
subscribe to their ISP IPV6 offering, 6to4 will no longer be needed. But are
we there yet?
> a place where we say either Good IPv6 access or none?

Interesting observation. I believe nearly all the folks who run eyeball
networks and content networks support the historic work since they staff
Helpdesk and have to earn the customer's business everyday by providing
reliable service.

If the value chain fails, we know the consequences.

It is an interesting perversion that you believe msft or apple are providing
ipv6 service. I don't believe they run 6to4 relays or even have ipv6 content
today.  Not to diminish the work they have done to advance v6 ...but let's
just be clear on who is providing the network services and who wants v6 to
move forward the most

Cb

---

From: Fred Baker <[email-masked]>
Date: Thu, 21 Apr 2011 07:41:37 -0700

On Apr 21, 2011, at 4:17 AM, Pekka Savola wrote:

> No IETF document requires 6to4, and therefore there is nothing the IETF needs to do to allow vendors to turn it off.
> 
> "Deprecation by standardization body decree" when vendors still continue shipping it will cause a mismatch between operational reality and the IETF.  It's futile.  We should first convince the (major) vendors that this what they want to do, wait that they start to do it, and then begin the deprecation.

I understand what you're trying to do, and that's fine, but... posting a document declaring the protocol to have been "declared historic" is our mechanism to do that. 

> If we want to give advisories to the vendors or users, we can put those to the advisory draft.
> 
> I however do agree that the following subset deprecation described in Section 4 makes sense:
> 
> This is internally inconsistent with S 1: "Declaring the mechanism historic is not expected to have immediate product implications."

It might make sense, if that statement is confusing, to remove the statement. I think the authors are trying to be pragmatic - "we understand that all software in the world isn't going to change overnight; as it changes, this is the direction we'd like it to go".

> What's the point if the goal is not to have immediate product implications?
> 
> I'd say that the best approach is likely to just discontinue this document.  After we've gotten major vendors on board with the subset deprecation, we can start working on the rest.

How do you plan to get the major vendors onboard without a specification for them to react to?

> Editorial:
> 
> Many things I object to, but listing these is not worth the effort. Some specifics though:
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings_______________________________________________
> v6ops mailing list
> [email-masked]

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 21 Apr 2011 08:08:47 -0700

On 4/21/11 7:40 AM, Cameron Byrne wrote:

> It is an interesting perversion that you believe msft or apple are
> providing ipv6 service. I don't believe they run 6to4 relays or even
> have ipv6 content today.  Not to diminish the work they have done to
> advance v6 ...but let's just be clear on who is providing the network
> services and who wants v6 to move forward the most

It can't possibly be overstated the importance of the inclusion of ipv6
in released consumer operating systems for close to the last decade.
Those systems perform just peachy when provided with native v6...

> Cb
> 
>>
>> --
>>
>> Roger Jorgensen           |
>> [email-masked] <mailto:[email-masked]>          | - IPv6 is The Key!
>> http://www.jorgensen.no   | [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Williams, Marcus (Contractor)" <[email-masked]>
Date: Thu, 21 Apr 2011 12:42:43 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Pekka Savola
> Sent: Thursday, April 21, 2011 7:17 AM
> To: [email-masked]

It seems ironic to be protecting the end user's control of the network.

Marcus Williams

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Apr 2011 21:01:38 +0300 (EEST)

On Thu, 21 Apr 2011, Fred Baker wrote:
> I understand what you're trying to do, and that's fine, but... 
> posting a document declaring the protocol to have been "declared 
> historic" is our mechanism to do that.

The IETF can certainly post documents if it wishes.
I'm saying that it is not a constructive thing to do unless we know 
that the major vendors are on board to follow that advice.

I'm saying that we should first get those vendors on board, not try to 
use "publish an RFC" as a hammer.

At best, the hammer makes them change their minds.
At worst, they laugh at the hammer and do nothing. The IETF looks 
silly, and the users who read RFCs get confused.

> It might make sense, if that statement is confusing, to remove the 
> statement. I think the authors are trying to be pragmatic - "we 
> understand that all software in the world isn't going to change 
> overnight; as it changes, this is the direction we'd like it to go".

Then what is the point of this document again?

James said it pretty well [1]

"When I briefed my managers about this draft, I told them that it 
currently requires us to do absolutely nothing in the foreseeable 
future, and it explicitly permits us to continue doing what we are 
doing today.  My reading of the document suggests that you can safely 
ignore its current form as well."

[1]
http://www.ietf.org/mail-archive/web/v6ops/current/msg08240.html

> specification for them to react to?

The major vendors who are the main target of this document are be 
already present on the mailing list.

Just as an observation:

People from Microsoft are arguing against it. James from Apple is 
arguing against it from a different angle.

Are you hoping that even if they don't change their opinion, they 
will conform to the RFC?

I don't.

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Apr 2011 11:18:14 -0700

On Apr 21, 2011, at 11:01 , Pekka Savola wrote:
> 
> Are you hoping that even if they don't change their opinion, they will conform to the RFC?

I'd like to note here that all of Apple's currently shipping products expressly require human intervention to enable 6to4 tunneling.

About three years ago, for a brief period of time, Apple sold a few hundred thousand AirPort Extreme base stations that enabled 6to4 tunneled IPv6 routing in their default configuration.  Apple didn't need an RFC to figure out precisely how and why this wasn't a very good idea, and changed the default configuration.

Until a few months ago, the only way it was possible for an Apple product to be configured into a 6to4 tunneling mode without express human intervention was by inadvertently importing a saved configuration from one of those older AirPort Extreme base stations into a newer AirPort product.  With the latest 7.5.2 release of AirPort/TimeCapsule firmware, even *that* isn't possible anymore.

Apple is already in absolute total conformance with the language in this draft.  I still oppose its publication for the reasons I've already stated, which have nothing to do with any implications of the recommendations it contains on Apple's business plans.

---

From: Fred Baker <[email-masked]>
Date: Thu, 21 Apr 2011 11:24:53 -0700

On Apr 21, 2011, at 11:01 AM, Pekka Savola wrote:

> I'm saying that it is not a constructive thing to do unless we know that the major vendors are on board to follow that advice.
> 
> I'm saying that we should first get those vendors on board, not try to use "publish an RFC" as a hammer.
> 
> At worst, they laugh at the hammer and do nothing. The IETF looks silly, and the users who read RFCs get confused.

So, rather than follow our own processes as described in RFC 2026 and specifically http://tools.ietf.org/html/rfc2026#section-4.2.4, as we did with RIPv1 and NAT-PT among other things, you would like us to do something undefined and different.

<quizzical look>

> "When I briefed my managers about this draft, I told them that it currently requires us to do absolutely nothing in the foreseeable future, and it explicitly permits us to continue doing what we are doing today.  My reading of the document suggests that you can safely ignore its current form as well."
> 
> [1]
> The major vendors who are the main target of this document are be already present on the mailing list.
> 
> Just as an observation:
> 
> People from Microsoft are arguing against it. James from Apple is arguing against it from a different angle.
>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Apr 2011 21:30:41 +0300 (EEST)

On Thu, 21 Apr 2011, Fred Baker wrote:
> So, rather than follow our own processes as described in RFC 2026 
> and specifically http://tools.ietf.org/html/rfc2026#section-4.2.4, 
> as we did with RIPv1 and NAT-PT among other things, you would like 
> us to do something undefined and different.
>
> <quizzical look>

NAT-PT deprecation could have been done better. It was done similarly 
as we're doing 6to4 deprecation.  There are still NAT-PT products out 
there, with no intention to remove the code.

Maybe it would a good time to learn something here.

I'm not saying 6to4 RFCs must never be made Historic.  I'm just saying 
doing it right now, without sufficiently solid consensus especially 
with those vendors who have shipped a hundred million implementations 
of it, is premature.

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 21 Apr 2011 11:38:18 -0700

Hi Fred,

The BCP section quoted below says:

" A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level."

The draft does not seem to say that there is a more recent specification superseding the standard. 

As to "any other reason" clause, I tried to communicate in my feedback, in my opinion, the draft doesn't state clearly the reasons which would require moving RFC 3056 to historic. It quotes 2 issues:

1. One is issue with protocol 41, and not RFC 3056 (so if it is an issue indeed, I think appropriate action could be deprecating protocol 41 - but interestingly no one seems to be arguing for that).

2. The other issue applies to implementations already not compliant with RFC 3056, or to networks where administrator usually have control to disable 6to4 if they choose to deploy public IPV4 addresses behind NATs.

So this doesn't look to me that the required conditions, per the BCP definition of historic, are met for move of RFC 3056 to historic.

Thank you,
Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Thursday, April 21, 2011 11:25 AM
To: Pekka Savola
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

<quizzical look>

---

From: Fred Baker <[email-masked]>
Date: Thu, 21 Apr 2011 11:40:14 -0700

On Apr 21, 2011, at 11:30 AM, Pekka Savola wrote:

> NAT-PT deprecation could have been done better. It was done similarly as we're doing 6to4 deprecation.  There are still NAT-PT products out there, with no intention to remove the code.

Yes, one of them comes from Cisco. The important point there isn't that NAT-PT isn't being removed, although I'd be in favor of that. It's that people that were using it and getting frustrated got an explanation that didn't involved vendor-bash-finger-point, and in response to operator demand the IETF started working on a viable replacement, which is now in active product in the field and in use in networks.

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Apr 2011 11:44:27 -0700

On Apr 21, 2011, at 11:18 AM, james woodyatt wrote:

> Apple sold a few hundred thousand AirPort Extreme base stations

I should correct myself immediately.  I actually don't know how many base stations were sold with firmware that enabled 6to4 tunneled routing by default.  They were the first draft-802.11n products Apple sold, so there was high demand, but they were on sale for less than six months before the firmware was changed at the factory.

---

From: Fred Baker <[email-masked]>
Date: Thu, 21 Apr 2011 11:51:47 -0700

> The draft does not seem to say that there is a more recent specification superseding the standard. 

Well, yes, it's not updating the standard. It's saying that the standard should be superseded by native deployment.

> So this doesn't look to me that the required conditions, per the BCP definition of historic, are met for move of RFC 3056 to historic.

<chair>
I'll leave that discussion to the authors and other commentators.

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 21 Apr 2011 12:30:26 -0700

Hello Fred,

>> Well, yes, it's not updating the standard. It's saying that the standard should be superseded by native deployment.

As far as I see you agree that that particular BCP wording doesn't apply there, since there is no superseding specification. So I fail to see how that wording can be used to support moving RFC 3056 to historic status. 

But even if that wording did apply, and native deployment could be considered as superseding 6to4 (and IPv6 offering apparently is not yet widely available to customers), then from that prospective I think native deployment would also supersede Teredo as well as other automatic IPv6 over IPv4 tunnels - but the draft doesn't propose that (perhaps there are other drafts I'm not aware of), and moving only 6to4 to historic would not be consistent.

Thank you,
Dmitry

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 11:52 AM
To: Dmitry Anipko
Cc: Pekka Savola; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

<chair>

---

From: Fred Baker <[email-masked]>
Date: Thu, 21 Apr 2011 12:38:20 -0700

> As far as I see you agree that that particular BCP wording doesn't apply there, since there is no superseding specification. So I fail to see how that wording can be used to support moving RFC 3056…

I'm hard pressed to see what "BCP" has to do with this. Are you referring to RFC 2026 as a BCP?

> But even if that wording did apply, and native deployment could be considered as superseding 6to4 (and IPv6 offering apparently is not yet widely available to customers), then from that prospective…

I personally would be very much in favor of making the same statement about Teredo. You might read http://www.potaroo.net/ispcol/2011-04/teredo.html, and specifically the portions on measuring Teredo behavior and performance. That said, I think it's a separate decision than the 6to4 decision. I wouldn't want to, for example, discover that there was consensus to take one to Historic and not the other, and as a result of having them in the same draft find that we couldn't do that which we actually had consensus to do.

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 21 Apr 2011 12:49:35 -0700

Hello Fred,

>> Are you referring to RFC 2026 as a BCP?

Yes, since it has category " Category: Best Current Practice". Sorry if this was confusing, I should have used RFC 2026 as a pointer.

>> I wouldn't want to, for example, discover that there was consensus to take one to Historic and not the other, and as a result of having them in the same draft find that we couldn't do that which we actually had consensus to do.

I don't know if there is consensus on moving 6to4 to historic, but to comment on your point: if one follows the justification you suggested (native supersedes tunnels), as I understand, that justification would equally apply to 6to4 and Teredo. And if that's not the case and there are some reasons why it doesn't apply to Teredo, I'd like to see analysis of why it doesn't, and whether those reasons apply to 6to4. 

That is what my feedback was - I think the current draft lacks listing of specific reasons what's wrong with RFC 3056 as a whole. Once such analysis is added, and the draft shows why those issues aren't mitigated by other proposals, which already exist (such as e.g. RFC 3484 revision), I think it would gain broader support.

Thank you,
Dmitry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Apr 2011 13:06:13 +1200

> " A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level."

I don't see any qualification of the word "any" in that sentence.

So, if the rough consensus here is that it's obsolete, because there
are now better ways of obtaining IPv6 connectivity, we could certainly
count that as a valid reason for historicisation.

As has been made clear, this doesn't cause existing deployments to stop
working.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Apr 2011 13:23:21 +1200

> the rollout of more commercially viable IPv6 services.

I think you will be surprised. However, I realised that we are arguing
about very little. From the very beginning of 6to4, it has been stated
that great care is needed in scoping announcements of 2002::/16 (i.e. the
route to a return relay). In fact, this in effect an anycast prefix.
I quote from RFC 3056:

   It is a matter of routing policy how
   far this routing advertisement of 2002::/16 is propagated in the
   native IPv6 routing system.  Since there will in general be multiple
   relay routers advertising it, network operators will require to
   filter it in a managed way.  Incorrect policy in this area will lead
   to potential unreachability or to perverse traffic patterns.

In other words, it has always been the case that 2002::/16 should not
be propagated blindly across the DFZ and should be filtered accordingly.
Nothing new here.

As far as a route to 192.88.99.1 goes, the same applies - as for
any anycast address, it should not be propagated blindly outside the
scope of its intended users. Anyone injecting it into the DFZ is
asking for trouble.

I hope that the guidance in -historic already makes this clear.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Apr 2011 14:23:35 +1200

Oops... silly mistake below:

> I hope that the guidance in -historic already makes this clear.

s/-historic/-advisory/

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 22 Apr 2011 11:25:51 +0200

There is indeed a plan to boil TEREDO in similar matter, but as its less
used at this point in time as 6to4 and mainly by particular OS's its of
slightly lower priority to write a draft about it. In general same rules
apply for both advisory and deprecation for TEREDO as is there for 6to4.
(Dave T. might disagree though as he mentioned something about that
during last IETF meeting) 

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dmitry Anipko
Sent: 21 April 2011 21:50
To: Fred Baker (fred)
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Hello Fred,

>> Are you referring to RFC 2026 as a BCP?

Yes, since it has category " Category: Best Current Practice". Sorry if
this was confusing, I should have used RFC 2026 as a pointer.

>> I wouldn't want to, for example, discover that there was consensus to
take one to Historic and not the other, and as a result of having them
in the same draft find that we couldn't do that which we actually had
consensus to do.

I don't know if there is consensus on moving 6to4 to historic, but to
comment on your point: if one follows the justification you suggested
(native supersedes tunnels), as I understand, that justification would
equally apply to 6to4 and Teredo. And if that's not the case and there
are some reasons why it doesn't apply to Teredo, I'd like to see
analysis of why it doesn't, and whether those reasons apply to 6to4. 

That is what my feedback was - I think the current draft lacks listing
of specific reasons what's wrong with RFC 3056 as a whole. Once such
analysis is added, and the draft shows why those issues aren't mitigated
by other proposals, which already exist (such as e.g. RFC 3484
revision), I think it would gain broader support.

Thank you,
Dmitry

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 12:38 PM
To: Dmitry Anipko
Cc: Pekka Savola; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

On Apr 21, 2011, at 12:30 PM, Dmitry Anipko wrote:

> Hello Fred,
> 
>>> Well, yes, it's not updating the standard. It's saying that the
standard should be superseded by native deployment.
> 
> As far as I see you agree that that particular BCP wording doesn't
apply there, since there is no superseding specification. So I fail to
see how that wording can be used to support moving RFC 3056 to historic
status. 

I'm hard pressed to see what "BCP" has to do with this. Are you
referring to RFC 2026 as a BCP?

> But even if that wording did apply, and native deployment could be
considered as superseding 6to4 (and IPv6 offering apparently is not yet
widely available to customers), then from that prospective I think
native deployment would also supersede Teredo as well as other automatic
IPv6 over IPv4 tunnels - but the draft doesn't propose that (perhaps
there are other drafts I'm not aware of), and moving only 6to4 to
historic would not be consistent.

I personally would be very much in favor of making the same statement
about Teredo. You might read
http://www.potaroo.net/ispcol/2011-04/teredo.html, and specifically the
portions on measuring Teredo behavior and performance. That said, I
think it's a separate decision than the 6to4 decision. I wouldn't want
to, for example, discover that there was consensus to take one to
Historic and not the other, and as a result of having them in the same
draft find that we couldn't do that which we actually had consensus to
do.

---

From: [email-masked]
Date: Sat, 23 Apr 2011 18:08:28 +0200 (CEST)

> ignore its current form as well."

The reference to James Woodyatt's statement has been used multiple
times as an argument for why this draft is unnecessary. Howeve, he
has also stated that current Apple products do *not* come with 6to4
enabled by default.

Both draft-ietf-v6ops-6to4-to-historic and -advisory say that 6to4
should not be enabled by default. Maybe a manufacturer shipping
products with 6to4 enabled by default would feel differently about
these documents than a manufacturer where the default is off?

In any case, I think it's quite clear that we need to get a document
out which says in no uncertain terms that 6to4 should not be enabled
by default.

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 23 Apr 2011 10:12:14 -0700

On 4/18/11 11:04 AM, Mikael Abrahamsson wrote:
>> plan for 2002::/16 included.  If you want to send a signal to
>> equipment makers that they should remove 6to4 routing functions from
>> their future product plans, then you need to include a phaseout plan
>> for it. Otherwise, you are engaging in a pointless exercise, and it
>> won't happen.
> 
> Could you please elaborate as to why? Not working for an equipment
> vendor, I don't get why there needs to be a firm phaseout plan. I never
> saw a phaseout plan for RIPv1.

The idea of a a point as which the numbering resources enter a different
state than the one that they currently have is plausible and perhaps
reasonable to stake out...

As with ripv1 to keep using that example however some set of devices
currently using it will continue to do so until they can't anymore...
That number may be vanishingly small ultimately (there are still devices
doing ripv1).

---

From: Doug Barton <[email-masked]>
Date: Sat, 23 Apr 2011 11:03:16 -0700

> That number may be vanishingly small ultimately (there are still devices

Isn't 6bone a better example?

--

---

From: james woodyatt <[email-masked]>
Date: Sat, 23 Apr 2011 15:48:07 -0700

> out which says in no uncertain terms that 6to4 should not be enabled

I thought 6to4-advisory already said that.  If it doesn't perhaps Brain could be persuaded to amend it.  It's good advice for all the reasons described in that document.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Apr 2011 11:07:51 +1200

On 2011-04-24 10:48, james woodyatt wrote:
> I thought 6to4-advisory already said that.  

Yes, but it's not a normative document and by its nature can't be.

In my experience, some product managers rely on formal normative
language rather than engaging their Brain.

  Brian

If it doesn't perhaps Brain could be persuaded to amend it.  It's good advice for all the reasons described in that document.

---

From: Martin Millnert <[email-masked]>
Date: Sat, 23 Apr 2011 19:14:46 -0400

Some short-circuiting below.

On Thu, 2011-04-14 at 19:30 +1200, Brian E Carpenter wrote:
> On 2011-04-14 08:48, Martin Millnert wrote:
> 
> <snip>
> 
> > 3. Disabling automatic 6to4-enabling on hosts would be good, too,
> > like you say (virtually everyone seems to agree about this?).
> > 
<snip>
> >   Brian, 4.1 in draft-ietf-v6ops-6to4-advisory-00: "This is bad
> >   practice - it should always be a conscious decision by a user to
> >   enable 6to4."
> > Would you have a comment on increasing the usage of 2119-wording in
> > the draft?  Is a change of the above "should" to "MUST"
> > inappropriate, the draft being a advisory text, and all?
> 
> Well, it will get published a lot quicker if it is kept as an
> Informational draft without formal language.
> 
> I think you should raise this comment against
> draft-ietf-v6ops-6to4-to-historic-00.txt, which says:
> 
> "2. Implementations capable of acting as 6to4 routers SHOULD NOT
>     enable 6to4 without explicit user configuration.
> ...
>     default"

Regards,
Martin

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 24 Apr 2011 14:01:03 -0700

On 4/19/11 3:15 PM, Michael Newbery wrote:
> 
> Not at all. Getting people to upgrade is obviously attractive to the
> CPE vendors. I was responding to the suggestion that these vendors
> would upgrade EXISTING equipment, even if they could, and pointing
> out that there doesn't seem to be any obvious financial incentive for
> the CPE vendors to do so.

The actual rate at which people upgrade the software on their cpe is
pretty much down in the weeds... Embedded devices are out of site /mind
and don't get attention until something is geniunely wrong with them...

if you're lucky the uptake on software updates is maybe 5% (speaking
from the experience of working for a mobile phone vendor) until you
deploy automated mechanisms that don't require much (or anything) in the
way of prompting, that has it's own perils of course (just ask microsoft
or nokia what happens when you brick some fraction of the devices in the
field)

> Certainly over the next few years we can hope that new equipment will
> do the right thing. Having said which, if you were to go out to the
> store RIGHT NOW and buy a residential gateway that does native IPv6,
> how easy would that be?

look for the logo... if you go to frys, you'll see a few, they aren't
the $49 one on the endcap, but there are other reasons to upgrade, e.g.
gigabit ethernet, 802.11n, print server, wap2 etc.

> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Michael Newbery <[email-masked]>
Date: Mon, 25 Apr 2011 11:05:53 +1200

> gigabit ethernet, 802.11n, print server, wap2 etc.

(Caution, the following may contain rhetoric...)

BUt, perhaps more importantly, how would you even know that it did IPv6? How would the average person know? Since IPv6 is essentially just network hygiene, most people are going to be unaware of it. If they know anything, they've heard that IPv4 is about to run out and they need an IPv6 address? Are they going to look for an "IPv6 Ready" sticker? Are they going to ask if the new router they purchased does IPv6---or can be upgraded to IPv6? Are they going to INSIST on support for TR-124, issue 2?

Yes, you can buy IPv6 capable routers right now, but it's not easy. And it should be.

Most people don't want IPv6. Most people don't want IPv4. They don't want Ethernet or RFC2882 or G.711. They want to connect to the Internet. And, RIGHT NOW, that includes IPv6. Oh, only a little bit. We can pretend that it doesn't really exist, that it's coming soon, but no need to worry yet. We can eke out the remaining IPv4 address space and point out that all IMPORTANT hosts have IPv4 addresses. Well NEARLY all. Mostly. At the moment... Stay calm citizens! There is no need to panic. But all the while, that tide of IPv6 only space is rising. In a very short amount of time we won't be able to ignore it, we won't be able to pretend that an IPv4 connection means connection to the Internet but acknowledge that it means connection to a sub-set of the Internet. How long was the last IPv4 allocation supposed to last APNIC? Now, do we really think we have plenty of time?

How do we enable our existing customers to access the IPv6 Internet?

Do we really tell them to throw out all their existing equipment and buy new stuff? How do we explain that for some strange reason THEIR equipment that used to work fine, strangely doesn't any more? (Doesn't work, as in no longer access the entire Internet). Yes, it's the Internet that has changed, not their equipment, but that won't lessen the blow. How do we explain to them that the equipment they bought YESTERDAY is unfit for purpose? I really don't want to have that conversation with my customers, or their lawyers.

Now, looking at this landscape, bleak though it may be, we note that there are quite a large number of 6to4 capable devices out there in our customers' hands. Experience has shown that 6to4 is flawed, hence draft-ietf-v6ops-6to4-to-historic, but it's probably still better than nothing (draft-ietf-v6ops-6to4-advisory).

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Apr 2011 10:50:38 +1000

> > the CPE vendors to do so.

I would pay a reasonable percentage of the original price to get a IPv6
image.
 
> and don't get attention until something is geniunely wrong with them...

Which there will be once the ISP starts deploying CGNs.  Adding 6rd
to a 6to4 image should be posssible.  Recieving a DHCP 6rd option
reponse should disable 6to4.

It would also help if CPE vendors actually updated there web sites
to have the latest images.  I've got CPE devices which have newer
images (as shipped) than those available on the web site.

> or nokia what happens when you brick some fraction of the devices in the

And my wife, who definitely meets the average user definition for this,
has upgraded her iPhone twice in the last year. iTunes nags.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 25 Apr 2011 06:42:45 +0200 (CEST)

On Mon, 25 Apr 2011, Michael Newbery wrote:

> Do we really tell them to throw out all their existing equipment and buy 
> new stuff? How do we explain that for some strange reason THEIR 
> equipment that used to work fine, strangely doesn't any more?

This happens all the time, and it seems to be fine. I have a color laser 
printer that worked fine in XP, but the vendor decided not to create 
drivers for Vista and Win7 (and installing the XP drivers doesn't work).

So I went from only being able to use it in Windows (because my Ubuntu 
laptop didn't support it) to only being able to use it in Ubuntu (because 
Windows stopped supporting it and Ubuntu started). Sometimes it's a 
strange world. Our users know it, this happens to them with a lot of 
devices (their cars need replacement parts over the lifecycle of the 
unit).

I know your opinion is very common, but when grandma hears that to view 
her grandchildren on that new video application that needs IPv6, she's 
needs to call her ISP and ask for it and they'll send her a new router, 
this is something that is going to happen.

I just wish the makers of these applications understood that :(

---

From: Ole Troan <[email-masked]>
Date: Tue, 26 Apr 2011 13:29:15 +0200

Pekka,

[...]

>   be removed/rephrased.  No need to even mention the BGP model.

why not? there seems to be a lot of confusion about this exact point and how 6to4 was originally intended to be deployed.

appreciated if you could list some of your other objections too.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 26 Apr 2011 13:44:28 +0200

> Are you hoping that even if they don't change their opinion, they will conform to the RFC?

<Randy hat>
this isn't the IVTF?
</Randy hat>

I think the vendors you mentioned above already comply with the draft.
this isn't meant as a hammer to force vendors to do anything by decree. the IETF has standardised a mechanism that has been shown to not work well in the Internet, it is our responsibility to clean up that particular mess.

with _my_ vendor hat on, I need this document to justify to our product people to not enable 6to4 by default. 

cheers,
Ole

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 26 Apr 2011 10:21:23 -0700

Hello Ole,

>> with _my_ vendor hat on, I need this document to justify to our product people to not enable 6to4 by default.

Why isn't http://www.ietf.org/id/draft-ietf-v6ops-6to4-advisory-01.txt sufficient for that? It seems to have a clear guidance to avoid unintentional deployment (and hence not to enable by default), and lists reasons for that. 

Thanks,
Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Tuesday, April 26, 2011 4:44 AM
To: Pekka Savola
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

<Randy hat>
this isn't the IVTF?
</Randy hat>

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Apr 2011 09:14:22 +0200

hi,

you haven't given me an easy job trying to summarize the 150+ mail thread the last call has generated so far. ;-)

I have tried to collect and itemize the issues with the draft raised on the thread. I have discarded the "support/no support" messages.

please let me know if there are issues I have missed and if you are happy with the proposed actions.

1. "has rarely if ever been deployed"
-------------------------------------
   - Furthermore, is not true the text in the document that indicates that this
     mechanism is unsuitable for widespread deployment and the same applies to
     "has rarely if ever been deployed".
   - I couldn't find a reference in the draft which would support statement (1). If there has been some
     study showing that   6to4 deployment, by some quantifiable metric, is indeed many times lower than
     deployment of other tunnels (for example, Teredo), then I think having a reference to such data would
     make statement (1) more justified. 

Action: clarify the text in the introduction to avoid impression that 6to4 as a whole has never been deployed.

2. "protocol 41"
----------------
   - Specifically, the issue (A) states that "6to4 has no specified mechanism to handle the case where
     protocol 41 is blocked...". Do other tunneling mechanisms using protocol 41 have such mechanism?
     If they don't, then should usage of protocol 41 be moved to historic, because the stated filtering/PMTUD
     problems are then not specific to RFC 3056? If they do, then having a brief overview of those and how/why
     they don't apply to 6to4 would help to strengthen the statement.

Action: None

3. "non-RFC1918 addresses"
--------------------------
   - The issue (B), if I understand correctly, it is essentially about usage of non-RFC1918 addresses in networks,
     connected to Internet e.g. using a NAT. There are existing mitigations to this problem
     (e.g. Windows implementation will not configure 6to4 interface if there is other IPv6 connectivity
     in the network; depending on particular implementation, in managed environments administrators may
     have control whether to enable or disable 6to4 on hosts). But even leaving those mitigations aside,
     it seems that the de-prioritization of 6to4 in prefix policy table below IPv4 in the proposed RFC 3484
     revision would take care of this issue, and moving RFC 3056 is a much stronger measure, which doesn't
     seem to be necessary, as far as the issue (B) is concerned. With the revised RFC 3484, 6to4 will be one
     of the "last resort" mechanisms, which will essentially be used only if nothing else can, so it won't
     be harmful.

Reply: with the introduction of CGNs non-RFC1918 addresses may have limited topological span making them
       unsuitable for 6to4.

     So to summarize, in my opinion, in the current draft there seem to be sufficient arguments to move RFC 3068
     to historic, but not RFC 3056. There may be such arguments for RFC 3056, but if there are, I think they
     are not sufficiently reflected in the draft. 

Reply: Current text states:
        - Not deployed
        - Same problems as 3068 for the reverse path
        - Same problem with filtering
        - Not working with non-1918 addresses with topologically limited span

Actions: Suggestions for text to make it even clearer why also 3056 needs to be deprecated?

4. "Phase out plan"
-------------------
   - Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should
     not published in its current form because it sets no standard for network operations without 6to4.
     A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft.

Action: None.

5. "Clarifications"
-------------------

Actions: Proposed text?

6. "Keep peer to peer 6to4"
---------------------------
   - There are parts which mention relays, and parts which don't. I think draft-ietf-v6ops-6to4-to-historic 
     fairly well explains what's wrong with relays, but it doesn't address what's wrong with 6to4-6to4
     communication. And if there is not much wrong with 6to4-6to4 scenario (either between the nodes or
     between nodes and islands), why should that part be moved to historic.

Action: Unsure. 6to4 is useful for e.g. BGP tunneling, as a way of getting "globally" scoped addresses without an
        ISP, can be used for IPv6 transport over other managed tunnels... none of these uses are described in
        3056, 3068. comments?

7. "2.0.0.2.ip6.arpa"

   - There are ancillary services associated with 2.0.0.2.ip6.arpa which are provided by APNIC under 
     the auspices of RFC5158.
   - I just want to confirm to people that irrespective of this proposed change, APNIC intends to continue 
     to provide reverse-DNS delegation, until its clear the community at large doesn't require the service.

Action: Issue closed.

8. "6to4 to experimental instead of historical"
-----------------------------------------------

   - In my opinion tend to be similar to Jordi's. 6to4 is good for experimenting with IPv6.
     If you need IPv6 service use native solution. But if there no solution on the market what to do?
   - According to our policy our 6to4 relay is only for experimenting with IPv6 technology.....
     What about 6to4 relabeled to experimental?

Reply: If we postulate that 6to4 is harmful to the deployment of IPv6 in the Internet then I don't see any
       other choice than deprecating it.

9. "why 6to4 is preventing 6to4 roll out"
-----------------------------------------
   - My opinion: There needs to be a clear motivation for why 6to4 is actively preventing 6to4 roll out.
     I think this clear motivation is somewhat lacking in the current text. The current focus, the way
     I read it, is on why 6to4 isn't a great protocol, rather a clear description of why 6to4 is actively
     preventing native IPv6 roll out. There also needs to be a clear end date for implementation of the
     deprecation, to avoid a transition on a transition. 

   - But I would suggest that the authors amend the text so that it:
     i) better motivates that use of 6to4 is actively preventing roll out of native IPv6
     ii) includes a clear date for full deprecation (perhaps immediately),
     iii) clarifies what it means to deprecate a protocol whilst still allowing it as a "last resort"
     (or indeed consider changing it to straight deprecation)

Action: I'll try to word smith some descriptive text. Appreciate some help Erik/Tore?

10. "This is internally inconsistent with S 1: "Declaring the mechanism historic is not expected to have
    immediate product implications.""
---------------------------------------------------------------------------------------------------------

   - What's the point if the goal is not to have immediate product implications?

   - It might make sense, if that statement is confusing, to remove the statement. I think the authors are trying
     to be pragmatic - "we understand that all software in the world isn't going to change overnight;
     as it changes, this is the direction we'd like it to go".

Action: Remove statement.

cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Apr 2011 13:16:18 -0700

> you haven't given me an easy job trying to summarize the 150+ mail thread the last call has generated so far. ;-)

No, it's not an easy job. The chairs will have a similar job next week sorting out consensus. What would be really nice would be if we could get these changes edited into the draft and then do a one-week extension of the WGLC next week; if the updated draft results in a clear consensus, it will be a lot more straightforward.

In the summary following, I take it that "Reply" or "Action" is your comment; the preceding statement or paragraph summarizes or reports a comment from the discussion thread. I'd appreciate comments on the mailer. In order to simplify sorting out the discussion threads and make sure each comes to closure, I'll repeat them as separate notes. 

PROCESS NOTE TO THE WORKING GROUP: I will assume that silence indicates consent. If Ole missed a point in this summary, please reply to this email indicting the additional point. If you disagree with a point in Ole's summary, please discuss in the thread "6to4-historic summary point N". That will help us sort out the differences of opinion quickly.