Subject: [v6ops] Regarding 6to4-PMT

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 11 Nov 2010 10:22:52 +0800

WG,

Based on the response yesterday, I will be following up
draft-kuarsingh-6to4-provider-managed-tunnel with a version homing in
specifically on the use case of broken 6to4 in CGN/NAT444 environments using
non-RFC1918 address space.

As a second point,  we will report back (aiming for Prague) on the trial
data using this option (level of impact of NAT66 on flows/apps etc).

As noted, PMT (utilizing PT66/NAT66) is not as optimal as the transparency
offered in normal 6to4 (noting that a sub-optimal return path may exist) but
it¹s better then broken 6to4.

Regards,

Victor Kuarsingh

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 15:38:23 +1300

Nevertheless, unbreaking 6to4 would be even better. Anyone here
interested in working on a BCP-ish draft addressed to ISPs about how to
unbreak the 6to4 return path?

Regards
   Brian Carpenter

On 2010-11-11 15:22, Victor Kuarsingh wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Nov 2010 18:43:31 -0800

> unbreak the 6to4 return path?

yes.

---

From: "Peng Wu" <[email-masked]>
Date: Thu, 11 Nov 2010 10:46:18 +0800

Hi guys,
  quick question about this draft, why not just 6rd? Is there differences in the effect of the two mechanisms? Or just because there's 6to4 router implementations already and no 6rd yet?

------------------				 
Peng Wu
2010-11-11

-------------------------------------------------------------
From：Brian E Carpenter
Date：2010-11-11 10:39:01
To：Victor Kuarsingh
CC：v6ops
Title：Re: [v6ops] Regarding 6to4-PMT

---

From: <[email-masked]>
Date: Wed, 10 Nov 2010 21:47:22 -0500

Not just ISPs. We need to include content providers as well as they typically are the return path.

Jason

On 11/10/10 9:38 PM, "Brian E Carpenter" wrote:

Regards
   Brian Carpenter

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 11 Nov 2010 10:53:52 +0800

Brian,

I would be interested. (as this was the original intent)

regards,

Victor

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 11 Nov 2010 11:07:20 +0800

On 11/11/10 10:46 AM, Peng Wu wrote:
> Hi guys, quick question about this draft, why not just 6rd? Is there
> differences in the effect of the two mechanisms? Or just because
> there's 6to4 router implementations already and no 6rd yet?

has more to do with the cpe and hosts with 6to4 support which has been
cooked in for some time.

6to4 router implementations have been cooked in for like a decade.

joel

> ------------------ Peng Wu 2010-11-11
> 
> From：Brian E Carpenter Date：2010-11-11 10:39:01 To：Victor Kuarsingh 
> CC：v6ops Title：Re: [v6ops] Regarding 6to4-PMT
> 
>> interested in working on a BCP-ish draft addressed to ISPs about
>> how to unbreak the 6to4 return path?
>> 
>> Regards Brian Carpenter
>> 
>>> draft-kuarsingh-6to4-provider-managed-tunnel with a version
>>> homing in specifically on the use case of broken 6to4 in
>>> CGN/NAT444 environments using non-RFC1918 address space.
>>> 
>>> As a second point,  we will report back (aiming for Prague) on
>>> the trial data using this option (level of impact of NAT66 on
>>> flows/apps etc).
>>> 
>>> As noted, PMT (utilizing PT66/NAT66) is not as optimal as the
>>> transparency offered in normal 6to4 (noting that a sub-optimal
>>> return path may exist) but it¹s better then broken 6to4.
>>> 
>>> Regards,
>>> 
>>> Victor Kuarsingh
>>> 
>>> 
>>> 
>>> v6ops mailing list [email-masked] 
>> _______________________________________________ v6ops mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Thu, 11 Nov 2010 03:08:12 +0000

Because 6rd requires changes to CPE that may not be owned, and 6to4 is
already running on devices that the SP may not have control over.

Providing a non-unique address that is not part of RFC1918 as the external
address (as in NAT444) will break those existing 6to4 uses and this is a
way to fix it. It's a corner case, but it is a valid one.

Victor, you might want to include an informative reference to
http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-02
in your next draft since it details the problem you're referencing here.

Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peng Wu
Sent: Thursday, November 11, 2010 10:46 AM
To: Brian E Carpenter; Victor Kuarsingh
Cc: v6ops
Subject: Re: [v6ops] Regarding 6to4-PMT

Hi guys,
  quick question about this draft, why not just 6rd? Is there differences
in the effect of the two mechanisms? Or just because there's 6to4 router
implementations already and no 6rd yet?

------------------				 
Peng Wu
2010-11-11

>> As a second point,  we will report back (aiming for Prague) on the 
>> trial data using this option (level of impact of NAT66 on flows/apps
etc).
>> transparency offered in normal 6to4 (noting that a sub-optimal return 
>> path may exist) but it¹s better then broken 6to4.
>> 
>> Regards,
>> 
>> Victor Kuarsingh
>> 
>> 
>>

---

From: Rémi Després <[email-masked]>
Date: Thu, 11 Nov 2010 11:16:02 +0800

> unbreak the 6to4 return path?

In my understanding, the best advice to be given is:
- If you use 6to4 today, continue only if:
 . your ISP doesn't offer native IPv6
 . you have identified reasons for needing 6to4 IPv6 now, despite 6to4 limitations.
- If you don't use IPv4 today, don't start.

Completely unbreaking 6to4 would be nice, but... if it would be possible.
Those who understand that it is impossible should IMHO make it clear to others.
Would you agree on this?

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 16:18:09 +1300

Sure, a content provider could operate their own instance
of 2002::/16 if their ISP doesn't do so.

Regards
   Brian Carpenter

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Thu, 11 Nov 2010 03:24:05 +0000

-----Original Message-----
from: [email-masked] [mailto:[email-masked]] On Behalf Of
Rémi Després
Sent: Thursday, November 11, 2010 11:16 AM
To: Brian E Carpenter
Cc: [email-masked]
Subject: Re: [v6ops] Regarding 6to4-PMT

 . you have identified reasons for needing 6to4 IPv6 now, despite 6to4
limitations.

Completely unbreaking 6to4 would be nice, but... if it would be possible.
Those who understand that it is impossible should IMHO make it clear to
others.
Would you agree on this?

[Wes]
You miss the point. This is not written to end users using 6to4. If they're
savvy enough to read drafts, they'll figure that out on their own.

This is written to ISPs and Content providers under the assumption that 1)
there are a non-trivial but minority number of people using 6to4 today,
either knowingly or unknowlingly 2) IPv6 native is preferable but does not
necessarily preclude #1 3) deploying local 6to4 relays are relatively cheap
and if enough are deployed at the right places, significantly improves
6to4's performance 4) 6to4 will continue to reduce in popularity as more
native is available, so this is a short-term problem.

Wes

etc).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 16:26:07 +1300

Peng,

We need to be crisp about the problem statement. In a nutshell, the
problem is when a client has found an anycast (192.88.99.1) 6to4 relay
and can thereby send an IPv6 SYN packet to the content server, but the server
has no route to 2002::/16 so cannot send the SYN/ACK back.

(Alternatively, it does have a route to 2002::/16 but it balck holes.)

6rd is a fix for the client's ISP but only works when the ISP controls
the CPE software. It cannot fix the problem at the content server end
or for legacy CPEs that cannot be updated to 6rd, or for legacy ISPs
that don't choose to run 6rd.

Regards
   Brian Carpenter

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Nov 2010 12:33:20 +0900

> (Alternatively, it does have a route to 2002::/16 but it balck holes.)

Right.  I don't think 6to4 implementations validate with probing
traffic to see if the tunnel is usable (possibly firewalled, or
blackholed for other reasons).  If it were, return path would only add
some latency, but generally be non-fatal.

And then there's PathMTU discovery to be diagnosed if the 6to4 RAs
don't contain a properly shortened MTU (safest IMHO would be to just
force 1280).

All more reasons that 6to4 PMT won't help.  Latency we might be able
to accept.  Blackholing: not so much.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 11 Nov 2010 12:05:51 -0500

> some latency, but generally be non-fatal.

What kind of probing do you have in mind?

Success with a given destination wouldn't guarantee success with another 
since the return path could be different.

Unless you're talking ICE/happy-eyeballs style of probing, in which case 
this is done at the application level, not at the 6to4 level, and is not 
specific to 6to4.

> don't contain a properly shortened MTU (safest IMHO would be to just

Now that would be a bug in the 6to4 implementation, wouldn't it?

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Nov 2010 14:09:47 +0900

> What kind of probing do you have in mind?

Difficult at best, and another reason not use 6to4.

But some silly things come to mind.  Why not send an ICMPv6 echo
request to something like 2002:: [or 2002:c058:6301:: or some other
instantly unreachable destination address] inside the tunnel?  If you
get an ICMPv6 error packet back inside the tunnel then at least you
know that proto41 is not firewalled somewhere in between.  Otherwise,
you can't be sure your local 192.88.99.1 received anything.

N.B.: I haven't spent any time thinking about how to make 6to4 more
reliable.  I'm aware that certain operational modes might just want to
drop these kinds of queries on the floor or something else.  But if
someone is going to draft a "make 6to4 suck less" operational guide
then some basic feedback mechanism for the client-side of the tunnel
to know that it has even a faint hope of working seems warranted to me
(along with configurable timers for re-checking).

> since the return path could be different.

Yay, another reason not to use 6to4.

Seriously though, are there people advertising 2002::/16 and /not/
doing encapsulation for all IPv4 destinations (i.e. some
more-than-just-bogon-related filtering)?  If so, there's another thing
for the "make 6to4 suck less" guide.  Otherwise I would think, from
the server's perspective, it's binary:  either it has a return
2002::/16 or it does not.

FWIW, the brokenness we've seen is /with/ what I believe to be a fully
functional 2002::/16 return route.  I strongly suspect that attacking
return path issues only affects latency, not overall reachability.

> this is done at the application level, not at the 6to4 level, and is not

I wholeheartedly support improved application-level intelligence.  The
application level is really the only layer at which connections can be
appropriately timed out, or simultaneous connections attempted, or ...
 Only the application can know that an HTTP GET request for, say, a
web chat application is supposed to "hang" while it waits for data
(assuming the absence of websockets, of course).  Otherwise, such a
"hang" might be because of pMTUd failures; but only the application
has a prayer of knowing what to expect (and sometimes it really can't,
but perhaps things like TCP keepalives with a really short timer could
help tell the difference; I haven't thought too much about this yet).

> Now that would be a bug in the 6to4 implementation, wouldn't it?

You're right.  What was I thinking?!  ;-)

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Nov 2010 13:14:50 +0800

> you can't be sure your local 192.88.99.1 received anything.

you could do as 6rd proposes (5969, section 8). send a ping to yourself with the outer address being the relay. IPv6 SA = DA = own 6to4 address, IPv4 DA = 6to4 relay.

cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Thu, 11 Nov 2010 14:21:23 +0900

> you could do as 6rd proposes (5969, section 8). send a ping to yourself with the outer address being the relay. IPv6 SA = DA = own 6to4 address, IPv4 DA = 6to4 relay.

Cute!

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 18:33:22 +1300

>> you could do as 6rd proposes (5969, section 8). send a ping to yourself with the outer address being the relay. IPv6 SA = DA = own 6to4 address, IPv4 DA = 6to4 relay.

I'm sorry. There is nothing we can do at the client end, and please note
that we are talking almost exclusively about clients that implement
RFC 3068. That is toothpaste that is out of the tube, and the IETF is
not in the business of reversing the 2nd law of thermodynamics.

It's the content providers that are losing clients that we can perhaps
help. Let's make DNS AAAA whitelisting unnecessary.

    Brian

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 11 Nov 2010 13:42:39 +0800

On 11/11/10 1:33 PM, "Brian E Carpenter" <[email-masked]>
wrote:

>>> you could do as 6rd proposes (5969, section 8). send a ping to yourself with
>>> the outer address being the relay. IPv6 SA = DA = own 6to4 address, IPv4 DA
>>> = 6to4 relay.
>> 
>> Cute!
> 
Agreed.  6to4 is in the network already, we need to deal with it.

Victor

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Nov 2010 13:48:28 +0800

Brian,

> not in the business of reversing the 2nd law of thermodynamics.

I disagree. there are two main problems with 6to4, black-holing and reverse-path.
we continue to ship 'client' implementations that suffer from the black-holing issue. thereby continuing to make the problem worse. the reachability check may help in resolving that.

> help. Let's make DNS AAAA whitelisting unnecessary.

for the forward direction every ISP should deploy a 6to4 relay.
for the reverse direction we have:

1) 6to4-PMT
2) announce longer prefixes than 2002::/16 into BGP
3) 'content' providers use 6to4 addresses (as well as global)
4) every content provider / every ISP has a 6to4 relay
5) deprecate 6to4 / stop shipping nodes with 6to4 on by default

6to4's main problem as it is deployed now is that there isn't any incentive for the ISP / content provider to deploy relays. has that changed?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 11 Nov 2010 13:50:22 +0800

> Agreed.  6to4 is in the network already, we need to deal with it.

IPv4 exhaustion -> CGN -> RFC1918 space to customers -> 6to4 goes away.

Ole

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 11 Nov 2010 14:00:56 +0800

Ole,

I would suggest that there are three use cases (at least)..

IPv4 Ex -> CGN -> RFC1918 Space to CPE -> 6to4 should stop (well except for
broken implementations)

IPv4 Ex -> CGN -> Non-RFC1918 to CPE -> 6to4 broken

IPv4 Ex -> Legacy Customers with Global IP -> 6to4 still working with
sub-optimal path

Use Case 2 and 3 are likely to be my common issues.  Use case 1 is not
likely since RFC1918 on CPEs is not possible in my Network

Victor

---

From: Tore Anderson <[email-masked]>
Date: Thu, 11 Nov 2010 07:27:26 +0100

* Ole Troan

> Brian,
> 
>> I'm sorry. There is nothing we can do at the client end, and please
>> note that we are talking almost exclusively about clients that
>> implement RFC 3068. That is toothpaste that is out of the tube, and
>> the IETF is not in the business of reversing the 2nd law of
>> thermodynamics.
> 

Sub-optimal reverse paths is a trivial problem for content providers to
handle, but as Erik has pointed out, it does not help at all.

Black-holing/firewalling of the proto-41 packets is the real problem,
combined with RFC 3068 implementations that are way too eager to enable
themselves by default and announce themselves to the local network using
RAs.

> we continue to ship 'client' implementations that suffer from the
> black-holing issue. thereby continuing to make the problem worse. the
> reachability check may help in resolving that.

Yes, a reachability test will probably help.  However I'd much rather
see all 6to4 implementations become disabled by default.

> for the forward direction every ISP should deploy a 6to4 relay.

Might help somewhat, but won't solve the problem completely as there's
too many rogue relays and firewalls that sits closer to the users that
will cancel out any positive effect.

> 2) announce longer prefixes than 2002::/16 into BGP

Ugh and ugh.  The toothpaste is out of the tube already, let's try to
clean it away rather than pick it back up from the floor and continue
using it..

> 3) 'content' providers use 6to4 addresses (as well as global)

I've tried, it just makes things significantly worse (more than 10x).
Clients that earlier would prefer IPv4 (thanks to RFC 3484) will start
preferring 6to4 and run into blackholes and latency issues.

> 4) every content provider / every ISP has a 6to4 relay

Every (IPv6-enabled) content provider:  Check.

_Every_ ISP (and enterprise and governmental network and educational
network and so on) (and regardless of whether or not they have any
native IPv6 anywhere in their network):  Not realistic.  Besides, it
won't solve the problem completely.

> 5) deprecate 6to4 / stop shipping nodes with 6to4 on by default

Absolutely.  This is in my opinion the only way to go.  No content
provider in their right mind wants to serve content over 6to4.  With the
current levels of 6to4-related brokenness, we prefer serving content
IPv4-only rather than IPv4+IPv6+6to4.

Getting vendors to fix it is the only thing I've seen actually help.
When Opera released version 10.50 in spring, the amount of brokenness I
observe halved within weeks.  Mac OS X 10.6.5 was released yesterday and
I'm optimistic about it having a similar effect.

I'll continue to pursue the vendors to kill (anycasted) 6to4 no matter
what, but if it was officially deprecated by the IETF the job of
convincing them might get much easier.

> 6to4's main problem as it is deployed now is that there isn't any
> incentive for the ISP / content provider to deploy relays. has that
> changed?

There's plenty of incentive for a content provider that is already
publishing AAAAs to deploy a return relay.  But there's no incentive for
a IPv4-only network to deploy relays that I can see.

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 11 Nov 2010 15:47:54 +0800

> quick question about this draft, why not just 6rd?

why not ipv6?

oh, that wasn't the question, was it.

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 08:54:46 +0100 (CET)

> incentive for the ISP / content provider to deploy relays. has that 

There is an incentive, there is lack of understanding of this incentive 
though.

Also, the problem with 6to4 isn't that there are a too few well-run ones, 
it's that there are too many badly run relays. So the message shouldn't be 
"everybody should run one", but instead "run them well or don't do it at 
all".

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 21:27:28 +1300

Tore,

On 2010-11-11 19:27, Tore Anderson wrote:

...
> a IPv4-only network to deploy relays that I can see.

Exactly. That has always been the problem with the RFC 3068 model -
no incentive to do a good job of placing anycast relays.
Easier for their outsourced help desk to say 'switch off IPv6 please'.

The best I can see is for IPv6-capable exchange points and transit
providers to provide anycast relays as an act of public service,
but I can't see an economic incentive for that.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 09:46:25 +0100 (CET)

On Thu, 11 Nov 2010, Brian E Carpenter wrote:

> providers to provide anycast relays as an act of public service, but I 
> can't see an economic incentive for that.

We've been doing that for 2 years now. 6to4 traffic through our relays 
have been going down, teredo is slightly up. My guess is that there are 
more 6to4 relays going up and that's why we see less traffic.

There are good relays available from enough people on the Internet 
(globally available) that it would be better for everybody if the people 
running bad relays just shut them off.

---

From: "Martin Millnert" <[email-masked]>
Date: Thu, 11 Nov 2010 09:57:04 +0100 (CET)

> unbreak the 6to4 return path?

Yes.

Cheers,
--
Martin Millnert

>> transparency
>> itÂ¹s better then broken 6to4.
>>
>> Regards,
>>
>> Victor Kuarsingh
>>
>>
>>

-- 
Martin Millnert <[email-masked]>

---

From: "Martin Millnert" <[email-masked]>
Date: Thu, 11 Nov 2010 10:27:10 +0100 (CET)

> more 6to4 relays going up and that's why we see less traffic.

Personal analysis on that, from having announced a 6to4 and Teredo-relay
into DFZ during a brief period of time:
  1) $bit-torrent-client ships with IPv6-support, includes enabling of
Teredo function where necessary (which is on a _vast_ amount of internet
users, due to host-address from RFC1918-space)
  2) IPv6-peers start showing up in torrent-swarms: (forgive my extremely
rough bittorrent-knowledge here) DHT/updated BT protocol takes care of
spreading reachability info of said IPv6 peers into the swarms, even in
the absence of a tracker running on IPv6
  3) various cable networks and similar, who have very well-functioning
torrent-limiters for IPv4-traffic, miss the Teredo-tunneled IPv6-traffic
  4) A very moderate amount of Teredo clients, due to 3, make up for a lot
more traffic in IPv6, even with Teredo, than in IPv4. I have,
un-scientifically, noted a factor of 30x.
  5) A current popular opensource Teredo implementation, Miredo, chokes on
these swarms of traffic (performance scales inversely vs number of
clients - stateful) , and operators have a hard time understanding that
they are actually choked.
  6) The result is that throughput is actually limited.
  7) >95% of the Teredo traffic is going to or coming from 6to4-IPv6.  A
relay running 6to4 and Teredo basically becomes an automatic
IPv4/UDP<->IPv4 tunnel brokerer.

I met with Martin Levy of HE this summer, and he very quickly convinced me
on what Mikael also mentioned:  Don't run the relays badly.
One way to run them badly, by some measure, is to announce into DFZ from
only 1 continent, pretty much.  Very weird things happen if you do (I know
:) )

> running bad relays just shut them off.

For the stateless 6to4, +/- poor latency, sure.
Teredo OTOH, I'd say is heavily performance-limited in the relays atm. 
Teredo doesn't need fixing though, by reading Tore's published brokeness
data ( http://www.fud.no/ipv6/ ):
------------
Client loss:                        0.043%
Overall IPv6 dualstack preference:  0.265%
- of which are 6to4:                25.823%
- of which are Teredo:              0.112%
- of which are other/native:        74.065%
------------

---

From: Gert Doering <[email-masked]>
Date: Thu, 11 Nov 2010 16:22:04 +0100

Hi,

> some latency, but generally be non-fatal.

Even if the tunnel might work for the probed destinations, it might
break in intersting ways for other destinations.  "Anycast relay".

6to4+anycast needs to die.

Gert Doering
        -- NetMaster
-- 
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: Pekka Savola <[email-masked]>
Date: Thu, 11 Nov 2010 17:40:13 +0200 (EET)

> you can't be sure your local 192.88.99.1 received anything.

I have not followed this thread, so I may be missing something, but 
this is exactly what Windows implementations have been doing for at 
least 5 years.

See Section 4.1 of:

Savola, P., Observations of IPv6 Traffic on a 6to4 Relay, on ACM 
SIGCOMM CCR "Internet Vital Signs" special issue on January 2005, 
http://netcore.fi/pekkas/6to4.pdf

The method may have evolved slightly since, but I think the main 
thing is still there.

-- 
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: Gert Doering <[email-masked]>
Date: Thu, 11 Nov 2010 16:43:53 +0100

Hi,

> 5) deprecate 6to4 / stop shipping nodes with 6to4 on by default

Please.  Then go discuss more interesting things.

Gert Doering
        -- NetMaster