Subject: compromise on the 6to4->Historic debate

From: Keith Moore <[email-masked]>
Date: Wed, 8 Jun 2011 16:48:24 -0400

I really think that the right answer is to write an applicability statement for 6to4 that:

- refers to the existing documents about 6to4 problems
- points out use cases for 6to4 which work well, and others that work less well
- emphasizes that 6to4 is a short-term solution and was always intended to be such

Deprecating 6to4 and declaring it Historic are premature and overkill, but an applicability statement seems entirely appropriate to me.

Beyond that, the question of anycast advertisement for 6to4 relay routers (RFC 3068) is a tough one.  I'd like to find a way to be able to keep them, because there's a huge utility in being able to automatically configure such things.  But everybody acknowledges the problems that are caused when relay routers are advertised in BGP that don't actually get the traffic there.   If there's not a way to weed out the bad ones that is easy for operators to implement, maybe RFC 3068 really should be deprecated.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Jun 2011 13:35:09 +1000

In message <[email-masked]>, Keith M
oore writes:
> Deprecating 6to4 and declaring it Historic are premature and overkill, but an
>  applicability statement seems entirely appropriate to me.
> 
> Beyond that, the question of anycast advertisement for 6to4 relay routers (RF
> C 3068) is a tough one.  I'd like to find a way to be able to keep them, beca
> use there's a huge utility in being able to automatically configure such thin
> gs.  But everybody acknowledges the problems that are caused when relay route
> rs are advertised in BGP that don't actually get the traffic there.   If ther
> e's not a way to weed out the bad ones that is easy for operators to implemen
> t, maybe RFC 3068 really should be deprecated.
> 
> Keith

Have broken 6to4 relays is *good* for the long term health of the
Internet.  Applications should cope well with one address of a
multi-homed server being unreachable.  Billions of dollars have
been wasted because this has not been seen as a basic requirement
for applications.  It really isn't any harder in most cases to do
this right.

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 8 Jun 2011 23:45:46 -0400

> for applications.  It really isn't any harder in most cases to do

Not that I disagree with the idea that applications should be able to fail over from one address to another, but ... why do you assume that the server is multihomed?  

The problem with the broken 6to4 relay on an anycast address is that the application (or user, or site) doesn't get to choose a different relay.  

Keith

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Jun 2011 18:03:52 +1000

In message <[email-masked]>, Keith M
oore writes:
> Not that I disagree with the idea that applications should be able to
> fail over from one address to another, but ... why do you assume that
> the server is multihomed?

Yes, that is a assumption which isn't always true but mostly is now.  It's
definitely true for the content providers complaining that 6to4 is stopping
them deploying IPv6.

> The problem with the broken 6to4 relay on an anycast address is that the
> application (or user, or site) doesn't get to choose a different relay.

The site can always pick a differnet relay as long as they know the IPv4
address of one.  There used to be lists of them.  The anycast address is
or should be just a convenience function.

I have suggested that ISP's could advertise 6to4 relay routers to customers
via DHCP draft-andrews-v6ops-6to4-router-option, this can also be used to
turn off 6to4 when it is known not to work (e.g. firewall, behind a NAT) or
there is working IPv6.

But rather than make the transition mechanism work there is this mind set
that 6to4 needs to be killed.

Mark

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 09:25:39 -0400

> definitely true for the content providers complaining that 6to4 is stopping

I get the latter part.   It's the "mostly is now" part that I wonder about.  Sure, I use the web a lot.  But I never think of the Internet as being only, or primarily, about a small number of applications that users on the outside use to get to content in the center.  To me it's about this huge variety of applications, that have all kinds of different traffic patterns.

> or should be just a convenience function.

It's *very* convenient.  The existence of the anycast service means that there can be a simple check box that says "enable 6to4" or that it can be enabled by default when no native connectivity is available.    Which ought to be a great thing.  

The problems with that appear to be:
Too many people have decided to "help out" without really understanding what is required of a relay router that is advertised via anycast...along with a lack of recommended practices for management of such routers.   (Yay that there's still some sense of Internet community.  But of course there is a learning curve associated with anything new.)
Default address selection rules that favor 6to4-to-nativev6 or even 6to4-to-6to4, over IPv4-to-IPv4.

(Then again there are rumors of some transit networks filtering protocol 41...which strikes me as more malicious.)

> that 6to4 needs to be killed.

Indeed.   And really, I'd be okay with killing it if native v6 were universally available.  But that might take another five or ten years.

Keith