Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic (yet again)

From: Ronald Bonica <[email-masked]>
Date: Tue, 26 Jul 2011 16:51:27 -0400

Tom,

Sorry. I meant to copy both lists. They are both copied now.

                                Ron

> -----Original Message-----
> From: t.petch [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2011 2:36 PM
> To: Ronald Bonica; [email-masked]
> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
> 
> It seems strange that this e-mail is not copied to the v6ops list.
> 
> I would have expected this first to have been hammered out on the v6ops
> list
> and, if and only if consensus was reached there, the new text be then
> brought to
> the
> IETF list.
> 
> I realise that, as you spell out, you are seeking IETF consensus but
> what is
> that if the
> WG is dead set against it?
> 
> Tom Petch
> 
> 
> ----- Original Message -----
> From: "Ronald Bonica" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, July 25, 2011 4:30 PM
> 
> > After some discussion, the IESG is attempting to determine whether
> there is
> IETF consensus to do the following:
> >
> > - add a new section to draft-ietf-v6ops-6to4-to-historic
> > - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> >
> > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
> and convert
> their status to HISTORIC. It will also contain a new section describing
> what it
> means for RFCs 3056 and 3068 to be classified as HISTORIC. The new
> section will
> say that:
> >
> > - 6-to-4 should not be configured by default on any implementation
> (hosts, cpe
> routers, other)
> > - vendors will decide whether/when 6-to-4 will be removed from
> implementations. Likewise, operators will decide whether/when 6-to-4
> relays will
> be removed from their networks. The status of RFCs 3056 and 3068 should
> not be
> interpreted as a recommendation to remove 6-to-4 at any particular
> time.
> >
> >
> > draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
> clarifies
> the meaning of "HISTORIC" in this particular case, it does not set a
> precedent
> for any future case.
> >
> > Please post your views on this course of action by August 8, 2011.
> >
> >
> >
> Ron Bonica
> >
> <speaking
> as OPS Area AD>
> > _______________________________________________
> > Ietf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jul 2011 10:49:53 +1200

Alex,

Since 6to4 is a transition mechanism it has no long term future
*by definition*. Even if someone chooses to design a v2, who is going to
implement it?

If you have a reason to install and enable 6to4, why would the nominal
status of a couple of RFCs make you do anything different?

Of course, if implementors choose to drop the code you might not be
able to upgrade software versions - but hopefully by that time you
will have native IPv6 service anyway.

Regards
   Brian Carpenter

On 2011-07-27 03:37, Alexandru Petrescu wrote:
> I jump in the midle of discussion and lazy to dissect emails:
> 
> Is there a replacement for historic 6to4?  What should I now install in
> the lab, without interaction to some admin or web page of some core server?
> 
> Thanks,
> 
> Alex
> 
> 
> Le 26/07/2011 15:47, Ronald Bonica a écrit :
>> Brian,
>>
>> Does the following text work for you?
>>
>>                           Ron
>>
>>
>> N. Meaning of HISTORIC
>>
>> For the purposes of this document, the term HISTORIC means:
>>
>> (host, cpe router, other)
>>
>> - Vendors will decide which future versions of their products will
>> support 6-to-4. It is assumed that vendors will continue to support
>> 6-to-4 until a) they are no longer economically incented to do so and
>> b) they are economically incented to remove unused features from their
>> products.
>>
>> - Operators will decide when to decommission 6-to-4 relays, if ever.
>> It is assumed that operators will continue to operate 6-to-4 relays as
>> long as they are economically incented to do so. When 6-to-4 traffic
>> levels reach zero, operators will probably begin to consider
>> decommissioning.
>>
>> The status of RFCs 3056 and 3068 should not be interpreted as a
>> recommendation to remove 6-to-4 at any particular time.
>>
>>
>>> From: Brian E Carpenter [mailto:[email-masked]]
>>> Sent: Monday, July 25, 2011 11:09 PM
>>> To: Ronald Bonica
>>> Cc: [email-masked]
>>> To be clear, I'd like to see exact proposed text before expressing
>>> support for the proposal. The trick is to get 6to4 disabled by default
>>> at the user end, without disabling it for users who are getting good
>>> service from it.
>>>
>>> Regards
>>>     Brian
>>>
>>> On 2011-07-26 09:49, Brian E Carpenter wrote:
>>>>>   Likewise, operators will decide whether/when 6-to-4 relays will be
>>> removed from their networks.
>>>>
>>>> This is, of course, an undeniable statement of fact (as it is for any
>>> other feature
>>>> of the Internet). However, it needs to be made clear that doing so
>>> *prematurely*
>>>> would penalise existing successful users of those relays, and
>>> therefore it should
>>>> only be done when there is no successful traffic through them. Which
>>> is when any
>>>> operator would remove them anyway.
>>>>
>>>> Therefore, I don't see much value in this statement, and possible
>>> harm to users.
>>>> The ways to avoid such harm as far as possible are already in the RFC
>>> Editor
>>>> queue.
>>>>
>>>> Regards
>>>>     Brian Carpenter
>>>>
>>>> On 2011-07-26 02:30, Ronald Bonica wrote:
>>>>> Folks,
>>>>>
>>> there is IETF consensus to do the following:
>>>>>
>>> and convert their status to HISTORIC. It will also contain a new
>>> section describing what it means for RFCs 3056 and 3068 to be
>>> classified as HISTORIC. The new section will say that:
>>>>>
>>> (hosts, cpe routers, other)
>>> relays will be removed from their networks. The status of RFCs 3056 and
>>> 3068 should not be interpreted as a recommendation to remove 6-to-4 at
>>> any particular time.
>>>>>
>>>>>
>>> clarifies the meaning of "HISTORIC" in this particular case, it does
>>> not set a precedent for any future case.
>>>>>
>>> <speaking as OPS Area AD>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jul 2011 10:56:55 +1200

Ron,

The normal typography is 6to4, not 6-to-4. I assume the draft will
still refer to [I-D.ietf-v6ops-6to4-advisory]. Given that, I believe
the draft should proceed.

I definitely disagree with those who say this would be a misuse of
"Historic"; the words in RFC 2026 certainly cover this case
("for any other reason considered to be obsolete").

Regards
   Brian Carpenter

On 2011-07-27 01:47, Ronald Bonica wrote:
> - 6-to-4 should not be configured by default on any implementation (host, cpe router, other)
> 
> - Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products.
> 
> - Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning.
> 
> The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time.
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Jul 2011 12:38:33 +1000

> will have native IPv6 service anyway.

Which is exactly why HISTORIC is NOT appropriate. 
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Wed, 27 Jul 2011 10:32:19 +0200

>Which is exactly why HISTORIC is NOT appropriate. 

With rfc3484-revise and the documented brokenness of 6to4, it doesn't make
any sense for implementors to offer 6to4 anyhow. So I think it would be
quite weird to keep 6to4 at standards track just to prevent some vendors from
dropping 6to4 support.

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Jul 2011 07:09:47 -0400

On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:

> Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it?

Actually, I think one could argue pretty effectively that 6rd is 6to4-bis.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 27 Jul 2011 07:31:51 -0400

> Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. 

+1

- Mark

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 08:15:32 -0400

> Actually, I think one could argue pretty effectively that 6rd is 6to4-bis.

only if you're confused about the use cases for each.

Keith

---

From: "John Mann (ITS)" <[email-masked]>
Date: Wed, 27 Jul 2011 23:07:34 +1000

Hi,

On 27 July 2011 22:15, Keith Moore <[email-masked]> wrote:

> >> Since 6to4 is a transition mechanism it has no long term future *by
> definition*. Even if someone chooses to design a v2, who is going to
> implement it?
> >

In my opinion:

6to4 use case
- D.I.Y setup - no ISP involvement
- depend upon kindness of strangers to run the anycast relays
- some users have hard-to-solve reliability problems
- experimental / historic / not-recommended - should be off by default
- for users who would prefer "unreliable IPv6" to "no IPv6"

6rd use case
- configuration parameters set by ISP
- ISP runs the relays
- apparently production quality (see free.fr)
- for users who would prefer "no IPv6" to "unreliable Internet"

I agree that 6rd is not a replacement protocol for the 6to4 use case.

I will argue that the "6rd use case" is a replacement for the "6to4 use
case".
[ And that native dual-stack is a replacement for both. ]
We want normal users to move past "experimental IPv6" towards "production
IPv6".

Thanks,
    John

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 09:35:18 -0400

> - for users who would prefer "unreliable IPv6" to "no IPv6"

close, but no cigar.

the use case for 6to4 is when
- you have a public IPv4 address
- your ISP doesn't support any kind of IPv6 access
- there's no good native v6 tunnel endpoint near your host, or your host is mobile
- you have applications for IPv6 other than to access content that is also available via IPv4, OR your hosts are set up to prefer native IPv4 over 6to4 addresses

> I will argue that the "6rd use case" is a replacement for the "6to4 use case".

If you have 6rd or any kind of native IPv6 available to you, you'll almost certainly prefer it to 6to4, except perhaps when needing to communicate with other hosts using 6to4.

The problem is that native IPv6 is not widely available, and will not be universally available for maybe 10 years.  

(Or maybe, never, because the deployment model in many people's minds assumes that the only reason to use IPv6 is to "access content" that will continue to be available via IPv4 indefinitely.)

> We want normal users to move past "experimental IPv6" towards "production IPv6".

I want that too.   What I object to is a denial-of-service attack on people who find 6to4 useful, just because it doesn't work as well as IPv4 for services that support both IPv4 and IPv6.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jul 2011 14:20:11 +0000

This seems like an easy question to answer.   You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 27 Jul 2011 07:27:17 -0700

> > Actually, I think one could argue pretty effectively that 6rd is
6to4-bis.

+1 as well as 6in4 or native v6.

The full requirements of 6to4 are based on currently unrealistic
requirements for no-nat (apnic is post exhaust ) and service providers to
stand up relays without a reasonable business case

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 27 Jul 2011 07:37:22 -0700

On Jul 27, 2011 7:20 AM, "Ted Lemon" <[email-masked]> wrote:
> This seems like an easy question to answer.   You'd implement and use
6to4v2 because it works better than the historic 6to4 protocol.

It seems like there is this deep philosophical discussion about historic
status. From what I can tell, ietf sent nat-pt to historic well before nat64
came about. Many people were using nat-pt too ... but going to historic
forced things along. It was a good choice in hindsight.

Cb

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 01:08:32 +1000

In message <CAD6AjGTPjhD=[email-masked]>
> stand up relays without a reasonable business case
 
There are lots of things that require no-nat.  6to4 is just one of
them.  ISP will end up providing no-nat for those that need it the
same way as they provide unfiltered port 25 for those that need it
and it also shouldn't cost more.

Yet there are relays out there and there are business cases to run
them.

Mark

---

From: Erik Kline <[email-masked]>
Date: Wed, 27 Jul 2011 15:12:25 +0000

Moving 6to4 to historic does not in any way impact your ability to use
it as you wish.

6to4 support is not part of the IPv6 node requirements, as I
understand it.  Therefore I believe that any vendor (OS, router,
otherwise) could deleted 6to4 support in any release and be in
violation of anything, regardless of historic status.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 01:15:17 +1000

In message <[email-masked]>, Ted Lemon writes
> status of a couple of RFCs make you do anything different?

Because it will come down to "run 6to4 and be exposed to some bug"
or "not run 6to4 but be safe from the bug".  We already have vendors
saying they are thinking about pulling 6to4 from their code bases
if it becomes historic.

> This seems like an easy question to answer.   You'd implement and use 6to4v=
> 2 because it works better than the historic 6to4 protocol.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 27 Jul 2011 08:27:54 -0700

> saying they are thinking about pulling 6to4 from their code bases

You also have content owners that say no aaaa while 6to4 is tanking
reliability stats.

Pick your battles.

Cb
> > This seems like an easy question to answer.   You'd implement and use
6to4v=

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 27 Jul 2011 11:27:58 -0400

On Jul 27, 2011, at 10:37 AM, Cameron Byrne wrote:

> It seems like there is this deep philosophical discussion about historic status. From what I can tell, ietf sent nat-pt to historic well before nat64 came about. Many people were using nat-pt too ... but going to historic forced things along. It was a good choice in hindsight.
> 

And natpt implementations still exist and are used by consenting adults. At a previous employer we were considering the business case for an implementation well after it's historic status. better solutions came along.

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 Jul 2011 16:35:07 +0100

> saying they are thinking about pulling 6to4 from their code bases

I would note that RIPE-501 does not mention 6to4:
	http://www.ripe.net/ripe/docs/ripe-501
As far as I can see, it only mentions RFC4213.

I would ask what is the alternative if as Mark suggests the vendors begin removing 6to4 support?
a) use 6to4 anyway on an open platform like OpenWRT
b) use a tunnel broker - this works much better through NATs and with dynamic IPv4 addresses
c) use your $work VPN if it supports IPv6, which it could/should if your company values IPv6
d) get IPv6 from your ISP, or move to one that has it if yours does not

I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs?

Tim

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 02:03:31 +1000

> a) use 6to4 anyway on an open platform like OpenWRT

Which may or may not still have the code.  OpenWRT could remove
support just the same as another source could.  OpenWRT is also not
widely supported by CPE vendors.  i.e. you are own your own if
something goes wrong in most (not all) cases.

> b) use a tunnel broker - this works much better through NATs and with dynamic

For which there is only experimental / ad-hoc code.  Please name
CPE vendors that support tsp?  Please name CPE vendors that support
tunnel re-configuration on re-number.

> d) get IPv6 from your ISP, or move to one that has it if yours does not

Which is not always a viable option.

> I suspect, but have no proof, that the huge majority of 6to4 users don't use 
> it intentionally, and the content they are trying to reach is also available 
> over IPv4. But for people who want to develop and use new IPv6-specific apps,
> then either a broker or something like OpenWRT ought to meet their needs?
>
> Tim

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 02:25:34 +1000

In message <CAD6AjGThTpvH5HgGc8RbedOcJKZ=_JLR=[email-masked]>
> You also have content owners that say no aaaa while 6to4 is tanking

You have Google Chrome and Firefox already implementing HE.  You
have new address selection rules out there.  You have a dramatic
decrease in 6to4 traffic already as a result.  You have improved
throughput for the 80% of machines for which 6to4 does work.

We are yet to see the effects of Mac OS Lion both the 6to4 side
and the HE side.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 27 Jul 2011 18:28:37 +0200

On 2011-07-27 18:03 , Mark Andrews wrote:
[..]
> For which there is only experimental / ad-hoc code.

You call my code Experimental/ad-hoc? :)

Like a good whiskey it matured over the years and hopefully soon I will
be releasing the next edition of AICCU which solves, at least in that
implementation, a couple of quirks that we have encountered in the
recent years.

> Please name

I don't know about TSP, but for the combination of TIC/heartbeat + AYIYA
in some cases there are a variety of vendors, amongst which AVM
Fritz!Box, Draytek, ZyXel Motorola, and various others I tend to forget
;) I unfortunately do not have an exact list of devices/models as I had
nothing to do with them, we just get users saying that they have a
device which supports it ;)

The fun part though with CPEs is that they tend to sit on the public IP
address, which is also the reason why the Fritz!Box only does TIC/heartbeat.

And of course every self respecting distribtion has support for it too
by just adding AICCU, that includes the various WRTs, pfSense, m0nowall,
Astaro and many many others.

As you said, everybody can decide themselves what options they add ;)

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 Jul 2011 18:25:06 +0100

> something goes wrong in most (not all) cases.

In the event OpenWRT should remove 6to4 support, just get like-minded people together (if there are lots of people that consciously want to use 6to4 for application development and testing) and roll your own.

> tunnel re-configuration on re-number.

Jeroen has answered this, but I would point out, as an example of what can be done in short time, that I had a student last year who developed a mini-ITX Linux build with tunnel broker support, and IPv6 firewall and QoS support, using a web interface driving existing tools like iptables and tc.  He chose to use the HE broker, and it's a one-time registration after which it just works without further user intervention with HE.

It would be very interesting to see brokenness figures for well-known broker prefixes as against 6to4, if anyone is gathering such data.

> Which is not always a viable option.

It is in the UK, at least.

Tim

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 14:21:54 -0400

> I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to devel…

tunnel brokers suck if the tunnel endpoint isn't near your current network location.

there are currently no universally applicable, or even widely applicable, v6-over-v4 solutions.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 14:25:20 -0400

On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote:

> any sense for implementors to offer 6to4 anyhow.

False.  It makes even more sense to offer 6to4 because it significantly decreases the chance that it will cause a bad experience for users of services that provide both v4 and v6 addresses, while increasing the chance letting local hosts/users talk to v6-only services/hosts.

> So I think it would be

Vendors can drop 6to4 support, or for that matter any other feature, anytime they wish.  They don't need permission from IETF to do that.

Keith

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 27 Jul 2011 13:08:09 -0400

>> Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. 

+2

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Jul 2011 14:28:47 -0400

> Moving 6to4 to historic does not in any way impact your ability to use

False.  Moving 6to4 to Historic is inviting people to mount denial of service attacks on things that actually work for people today.  Moving 6to4 to Historic will also invite vendors to remove 6to4 support from future versions or updates of their products, forcing users to make difficult choices between using 6to4 on one hand and changing equipment or vendors on another.

There's no reason to cause that kind of collateral damage.   Denial of service attacks are completely inappropriate.

> violation of anything, regardless of historic status.

Nothing that IETF specifies requires 6to4.   Vendors can indeed delete it if they want to.  But IETF should not recommend that they do so, or imply that they should do so.

Keith

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 27 Jul 2011 20:51:42 +0200

> tunnel brokers suck if the tunnel endpoint isn't near your current network location.

Let me rewrite that sentence for you:

 "transition mechanisms suck if the tunnel endpoint isn't near your
current network location"

It does not matter much if that mechanism is static proto-41 (6in4),
6to4, AYIYA, TSP, PPTP, HTTP Proxies or whatever, there is going to be a
bit more latency if they are not directly next to you. Not much you can
do about except deploy more of them or

And this will always be the case unless you deploy enough of them in all
places possible. For SixXS we are at 48 boxes around the world,
Hurricane has 25 and Gogo6 has 4 of them of their own for Freenet6 and
then there are 4 others at other organizations and there are a couple of
other services out there which provide tunnels see:

 http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

> there are currently no universally applicable, or even widely applicable, v6-over-v4 solutions.

For your set of requirements maybe but especially Tunnel Brokers are
working very well for a lot of people and if one sees the traffic stats
on Teredo and 6to4 nodes due to this little thing called NNTP I would
state that those are doing quite fine too for giving access to what
people need to get to.

Your major requirement seems to involve latency though, thus as such,
there is only one thing to do, get one of those boxes deployed locally
to your endpoint.

Do note to yourself that the next issue you will run into that the
service you are actually contacting will be far away, and you suddenly
understand that you need that Akamai content box and a Google one and
various other closeby too ;)

If you want to solve your problem though, I guess for HE you'll have to
give them connectivity to their network and space in a rack for a box,
gogo6 will sell you a box and for SixXS you provide the box+connectivity
and we'll set up the software for free for you and handle the tunneling
completely.

Greets,
 Jeroen

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 27 Jul 2011 21:25:01 +0200

On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS) <[email-masked]> wrote:
<snip>
> We want normal users to move past "experimental IPv6" towards "production

Exactly, we should focus on doing production IPv6, not wasting our
time on something that run on top of something else, whatever it's
called (are way too many to choice from already and I will recommend
anyone that ask me to never walk down that road, never).

So, can we please stop this never ending SPAMMING with regards to 6to4?

It is a total waste of time, really Keith, please stop. pretty please stop.

-- 

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Jul 2011 18:26:43 -0400

>>>>> "Roger" == Roger Jørgensen <[email-masked]> writes:

    Roger> Exactly, we should focus on doing production IPv6, not wasting our
    Roger> time on something that run on top of something else, whatever
    Roger> it's

So, in your opinion, a production host will never have more than
one address?

This is the fundamental problem.  6to4 is just the thing shining the
light on the problem.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jul 2011 09:36:34 +1000

In message <[email-masked]>, Jeroen Massar writes:
> >> I suspect, but have no proof, that the huge majority of 6to4 users don't u
> se it intentionally, and the content they are trying to reach is also availab
> le over IPv4. But for people who want to develop and use new IPv6-specific ap
> ps, then either a broker or something like OpenWRT ought to meet their needs?
> > 

Is there *one* tunnel management protocol that they all support or
does a cpe vendor have to implement multiple ones to reach them
all?  I'm pretty sure I know the answer to this question but I'd
love to be proved wrong.

One of the advantages of 6to4 anycast is that it is just needs a
check box to turn on and off.  Everybody speaks the same thing.

Another advantage of 6to4 is it doesn't require manual intervention
on renumber events.  Manual tunnel don't pass muster.

Another advantage of 6to4 is you don't have to register.  For most of
the tunnel brokers you have to register.

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Jul 2011 21:56:51 -0400

On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote:
> 
> So I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. 

As one of those implementers-- as in, it will probably be *my* commit to the repository that does "rm $XNU/bsd/net/if_stf.c"—- I now feel compelled to reiterate that I would prefer a more controlled phase-out plan than, "equipment vendors and operators are free to commence the destruction of 6to4 at their individual convenience and without further warning to the user community."

In the absence of a coherent instruction from IETF for a phase-out plan, declaring this protocol historic under the current proposed language, will do precisely that.  Please please please, if IETF wants 6to4 to die, then publish a phase-out plan so that the current users of 6to4 can have fair warning before the relays go dark and forthcoming hardware/software upgrades rip the feature out from under them.

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Jul 2011 10:08:11 +0200

In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote:
> In the absence of a coherent instruction from IETF for a phase-out
> plan, declaring this protocol historic under the current proposed
> language, will do precisely that.  Please please please, if IETF
> wants 6to4 to die, then publish a phase-out plan so that the
> current users of 6to4 can have fair warning before the relays go
> dark and forthcoming hardware/software upgrades rip the feature
> out from under them.

I would hope that big companies like Apple would actually do an impact
analysis before removing a feature. 

Big content providers can measure how much 6to4 is enabled, so they can
probably say something about trends. But that doesn't say much about how many
users actually care about 6to4. Vendors seem to be best equiped to analyse 
the users' need for 6to4.

I don't think relay operators have expressed a desire for a specific cut off 
date. So I guess they just figure out for themselves when to switch off the
relays.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 28 Jul 2011 11:12:17 +0200

On 2011-07-28 01:36 , Mark Andrews wrote:
[..]
> all?  I'm pretty sure I know the answer to this question but I'd

There is no 'one' solution to the problems that they are solving.

As such there tend to be a combo of:
 - static proto-41 tunnel
 - 6to4
 - 6rd
 - TSP => dynamic NATted addresses
 - proto-41 + heartbeat + TIC => dynamic public addresses
 - AYIYA + TIC => dynamic NATted addresses

TSP conveys configurartion information inline with the UDP packets.
TIC is solely for configuration information and does not do tunneling
but can be used for all proto-41/heartbeat/AYIYA protocols (and for
instance AVM chose to only do proto-41 + heartbeat as their devices
always have public IPv4 IPs).

Teredo is only for a single host thus is not useful for CPEs and thus
not included in them.

> check box to turn on and off.  Everybody speaks the same thing.

Except that it does not work behind a NAT and most people do sit behind
a NAT.

Next to that those anycasts are even rarer around the world and on top
of that it is hard to figure out issues when they are there (although
some people have tricks to apparently debug them, the anycast on both
IPv4 and IPv6 requires one to contact a lot of folks).

The big advantage over a known tunnel endpoint is the known behavior of
that endpoint and the simple way of complaining when something is
broken. And people fortunately do complain when stuff is broken,
unfortunately not always with the proper details though, but I am to
blame for not finishing that program up...

> on renumber events.  Manual tunnel don't pass muster.

I guess you are one of the lucky people to get a public static IPv4
address prefix at home that never renumbers? Guess what, most of the
world does not have that luxury, they get 1 dynamic address and for
instance in Germany they get a disconnect/force-renumber every 24 hours
(according to the ISPs because of 'accounting' reasons...)

Do realize that when you have that public IPv4 address, when it changes
you are renumbering your 2002:<ipv4>::/48 prefix everywhere. Fun...
(I hope you also like asking 6to4.nro.net everytime to change your reverse)

The tunnels above all have ISP-supplied prefixes and tend to be static
(I think TSP anonymous tunnels rotate addresses, but the majority just
keeps on returning the same static allocation, in the case of SixXS you
really get a fixed address, much easier on the PoP side and we can do
whois and store it in the relevant RIR registry)

> the tunnel brokers you have to register.

I guess you also where able to anonymously sign up to your IPv4 ISP!? :)
Especially that static IPv4 address must be wonderful to get that way.

Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away.

Something with the amounts of abuse made us (SixXS) require that we
require valid address data. Next to that it is a RIPE requirement to
register /48 prefixes. Other Tunnelbrokers just started blocking things
like IRC and NNTP because there was too much abuse or traffic....
We kill off accounts of people when they abuse, google my name and you
will find various people who where caught in the act and are quite mad
that they can't have funny vhosts on IRC anymore and attract 500mbit
DoSses and other such nonsense which are not the goal of providing IPv6.

Also, the registration means that people can just type in their
username/password (and optionally which tunnel they want to use out of
the multiple tunnels they might have) in their CPE and the CPE then uses
TIC or TSP to fetch this configuration and set it all up, and it will
just work(tm).

As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg
and
http://www.sixxs.net/wiki/Fritz!Box_7270

Next to that knowing where the user is and more importantly their
endpoint allows one to select a proper PoP for that user close to their
endpoint causing low latency and generally high throughput.

With anycast you are just hoping that that all will work.

Greets,
 Jeroen

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 28 Jul 2011 08:04:17 -0700

> analysis before removing a feature.

Like how Apple does not support Flash in iOS?

Just one example where a visionary drops an inferior solution to force a
better one.

This is also known as cracking some eggs to make an omelet.

Cb

---

From: Mark Andrews <[email-masked]>
Date: Sat, 30 Jul 2011 11:06:25 +1000

>  - AYIYA + TIC => dynamic NATted addresses

I was more thinking about commonality with tunnel brokers.

6rd is not a replacement for 6to4 as it requires ISP involment or
someone to create a registry of 3rd party 6rd providers along with
associated parameters sets similar non anycast 6to4.  static proto-41
tunnel is also not a viable replacement as it doesn't handle address
reassignment at the CPE end.