Subject: [v6ops] Opinion from an operator that as deployed 6to4 relays (draft-ietf-v6ops-6to4-to-historic)

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 11 Nov 2014 21:15:00 +0000

Comcast deployed 6to4 relays several years ago, our relays remain active
today.  Over the years traffic has decreased significantly.  I will see if
I can dig up traffic trends over the past couple of years.  If I can I
will send them to the list.

We intend to operate these relays until there is little to no 6to4 traffic
on our network.  The relays were deployed largely to ensure that customers
using 6to4, either on purpose or by accident, have a reasonable
experience.  We by no means want our customers to use 6to4, in fact, we
would prefer that they not use IPv6 at all if 6to4 is their only option.

Throughout this year there were some edge cases related to 6to4 that
required our attention, meaning issues were reported related to the use of
6to4.  This is not an ideal use of engineering time and energy.  I agree
with a statement that Mikael Abrahamsson made at the microphone during
IETF91, we should strive to entirely retire the use of 6to4 and I see no
value in replacing 6to4.  This again is from the perspective of an
operator that has an extensive native IPv6 deployment and actively
deployed 6to4 relays.

If pressed to do something I would sooner prefer that 6to4 be replaced
with 6rd.  Finally, I just do not see the value in expending v6ops WG time
and energy on the topic of replacing 6to4.  We have plenty of forward
looking work to pursue.

John

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 11 Nov 2014 22:20:16 +0100

> operator that has an extensive native IPv6 deployment and actively

I'll add my note to that too.

Indeed, 6to4 served it's purpose.

> with 6rd.

They have a completely different target group and 6rd properly stands on
it's own.

Hence, IMHO, just marking the end of 6to4 is a good thing.

> Finally, I just do not see the value in expending v6ops WG time

Fully agree.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Nov 2014 10:52:51 +1300

John,

I don't see any inconsistency between what you write and what the
draft says. Please correct me if I'm wrong.

Regards
   Brian

On 12/11/2014 10:15, Brzozowski, John wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: James Woodyatt <[email-masked]>
Date: Tue, 11 Nov 2014 13:44:23 -1000

John,

What about the return relays?  Did you deploy return relays?  If you did,
then 1) have you ever encountered any problems related to your deployment
of return relays? and 2) do you have data concerning how much usage those
return relays are seeing?

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Nov 2014 00:59:37 +0100 (CET)

On Tue, 11 Nov 2014, James Woodyatt wrote:

> What about the return relays?  Did you deploy return relays?  If you 
> did, then 1) have you ever encountered any problems related to your 
> deployment of return relays? and 2) do you have data concerning how much 
> usage those return relays are seeing?

Most people I know of that say they deploy "6to4 relays" mean they're 
doing bidirectional relaying. Talking operationally, it doesn't make much 
sense to do just one direction.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Nov 2014 13:26:56 +1300

On 12/11/2014 12:59, Mikael Abrahamsson wrote:
>> deployment of return relays? and 2) do you have data concerning how
>> much usage those return relays are seeing?
> 
> doing bidirectional relaying. Talking operationally, it doesn't make
> much sense to do just one direction.

Well, it does make sense for content providers who want to provide a good
return relay service but have no interest in attracting clients to the anycast
address. And I think that James Woodyatt's alongside-NAT64 case makes sense
for an IPv6-only provider. (Except that this is a dying protocol, not
a growth area.)

    Brian

---

From: James Woodyatt <[email-masked]>
Date: Tue, 11 Nov 2014 14:40:31 -1000

RFC 6343 recommends transit providers and content providers to have a
working 6to4 return relay, but it leaves consumer and enterprise network
operators without such guidance. If you're an enterprise network or a
residential retail network, and your transit operators are failing to
comply with RFC 6343, then I would say it's your problem that packets sent
from your IPv6-only customers are not getting delivered properly to the
2002::/16 prefix.

Because RFC 3056 is still Standards Track and the Sun is still shining on
IPv4 from very high in the sky.

If you are a consumer ISP or an enterprise network without a 6to4 return
path, then you can fix your problem by finding a transit provider that
succeeds at RFC 6343, or you can fix it by installing a 6to4 relay
yourself, but I would say that Best Current Practice is definitely to fix
it.

I would prefer that Best Current Practice not include leaving it broken and
blaming the victim.  That's all I'm trying to say.

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 12 Nov 2014 02:11:45 +0000

Agreed, thanks Brian.

=========================================
John Jason Brzozowski
Comcast Cable
m) 609-377-6594
o) 484-962-0060
w) www.comcast6.net
e) [email-masked]
=========================================

-----Original Message-----
From: Brian Carpenter <[email-masked]>
Organization: University of Auckland
Date: Tuesday, November 11, 2014 at 11:52
To: John Brzozowski <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] Opinion from an operator that as deployed 6to4 relays
(draft-ietf-v6ops-6to4-to-historic)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 Nov 2014 16:32:06 -1000

On 11 Nov 2014, at 13:59, Mikael Abrahamsson <[email-masked]> wrote:

> Most people I know of that say they deploy "6to4 relays" mean they're doing bidirectional relaying. Talking operationally, it doesn't make much sense to do just one direction.

Hm, I have the following on my server:

stf0: flags=1<UP> mtu 1280
	inet6 2002:5395:4101::1 prefixlen 16

This means that if a 6to4 user visits my website at its (native) IPv6 address, I tunnel the responses back directly to that user without having to go through a public relay.

Running a relay in the other direction only makes sense if you have 6to4 users that you are willing to provide this service for, i.e., only when you are an ISP or are prepared to run a public relay.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 12 Nov 2014 08:17:59 +0100

On 2014-11-12 03:32, Iljitsch van Beijnum wrote:
>> Most people I know of that say they deploy "6to4 relays" mean
>> they're doing bidirectional relaying. Talking operationally, it
>> doesn't make much sense to do just one direction.
> 
> stf0: flags=1<UP> mtu 1280 inet6 2002:5395:4101::1 prefixlen 16
> 
> This means that if a 6to4 user visits my website at its (native) IPv6
> address, I tunnel the responses back directly to that user without
> having to go through a public relay.

The fun with that one is, if the state tracking on the source host (thus
the one who contacted your native address), is accepting that 6to4
packet which comes in directly instead of through that relay they
previously talked to.

Hence, it might just cause broken behavior.

Greets,
 Jeroen

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Nov 2014 20:03:44 +1100

> Hence, it might just cause broken behavior.

6to4 always has asymetric routing unless you are *very* lucky.  The
way to avoid that is to have *exactly* *one* gateway in the world
or to start injecting more specifics when you know your client
population.

6to4 + state tracking is known not to work.  This is why we worked
on HE for those people who are behind such firewalls or firewalls
that block proto 41 outright.

Adding more relay points (either direction) will not hurt 6to4 users
which have working 6to4 today.  They will already be handling the
asymetry.

What hurts 6to4 is broken relays and firewalls blocking the traffic.

What the purists don't like is symetric routing and that it is not
native.

Mark

-- 
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: Wed, 12 Nov 2014 20:23:18 +0100 (CET)

> What hurts 6to4 is broken relays and firewalls blocking the traffic.

Correct. There is nothing wrong with 6to4 as a protocol, apart from the 
fact that human nature (or whatever) makes it not work in reality. Thus we 
need to get rid of it, and make sure people are running IPv6 natively. 
Operationally, tunneling is hard to get working, asymmetric tunneling is 
worse than the managed tunnels (point to point) or tunnels that are 
managed by a single entity (6RD), because when they break it's harder to 
fault find.

> What the purists don't like is symetric routing and that it is not

I guess you meany "asymmetric"?