Subject: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00

From: Ole Troan <[email-masked]>
Date: Mon, 7 Feb 2011 16:17:48 +0100

I just posted the following draft suggesting that we move the 6to4 documents to historic.

cheers,
Ole

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: February 7, 2011 16:14:30 GMT+01:00
> To: [email-masked]
> Subject: New Version Notification for draft-troan-v6ops-6to4-to-historic-00 
> 
> 
> A new version of I-D, draft-troan-v6ops-6to4-to-historic-00.txt has been successfully submitted by Ole Troan and posted to the IETF repository.
> 
> Filename:	 draft-troan-v6ops-6to4-to-historic
> Revision:	 00
> Title:		 Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status
> Creation_date:	 2011-02-07
> WG ID:		 Independent Submission
> Number_of_pages: 11
> 
> Abstract:
> Experience with the "Connection of IPv6 Domains via IPv4 Clouds
> (6to4)" IPv6 transitioning mechanism has shown that the mechanism is
> unsuitable for widespread deployment and use in the Internet.  This
> document requests that RFC3056 [RFC3056] is moved to historic status.
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: Tore Anderson <[email-masked]>
Date: Mon, 7 Feb 2011 17:43:28 +0100 (CET)

* Ole Troan

> I just posted the following draft suggesting that we move the 6to4

Ole,

I agree fully. Thank you for writing the draft.

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

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 7 Feb 2011 18:23:46 +0100

> > document requests that RFC3056 [RFC3056] is moved to historic status.

Fully agreed, I support this request.

Best regards,
Daniel

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 12:47:25 -0500

> I agree fully. Thank you for writing the draft.

I strongly disagree.  You're trying to kill the most widely deployed v6 transition mechanism that we have, without there being anything like a suitable replacement.

The fix for 6to4's problems is proper network configuration.

Keith

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 7 Feb 2011 18:56:24 +0100

On Mon, Feb 07, 2011 at 12:47:25PM -0500, Keith Moore wrote:
> I strongly disagree.  You're trying to kill the most widely deployed
> v6 transition mechanism that we have, without there being anything
> like a suitable replacement.

6RD.

Best regards,
Daniel

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 12:57:49 -0500

>> like a suitable replacement.

6rd is great for ISPs.  It doesn't solve the problem for individual users.

Keith

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Feb 2011 10:04:08 -0800

> 6RD.

Why not something better? Why not IRON:

http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt

Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Feb 2011 13:10:30 -0500

> Why not something better? Why not IRON:

I'm not deeply familiar with the protocol, but at first glance it seems to be a system for balkanizing the Internet.   In what respect is this "something better?"   Am I misunderstanding what the protocol does?

---

From: james woodyatt <[email-masked]>
Date: Mon, 07 Feb 2011 10:21:08 -0800

>> document requests that RFC3056 [RFC3056] is moved to historic status.

Objection: it's too soon to move this protocol to historic.

The 6to4 protocol is still in widespread use, despite its suboptimality for promoting IPv6 transition, particularly in residential IPv4/NAT gateways.  I don't even think it's yet time to move RFC 3068 to Historic status, which would arguably be slightly more sane to contemplate, but moving RFC 3056 to Historic at this point would be far too aggressive.

All that said, I further worry that moving RFC 3056 to Historic status would conflict with the very worthy recommendations concerning deployments of 6to4 relay routers in I-D.carpenter-v6ops-6to4-teredo-advisory.  This is probably the best reason not to move RFC 3056 to Historic status at this time.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Feb 2011 10:22:14 -0800

Hi Ted,

You'll have to educate me on what you mean by "balkanizing"
the Internet, because the concept is totally foreign to me
at least within the context of IRON?

As to how IRON is better, do you want an exhaustive list
or just a few for-instances? I'll give you a few for-
instances for now, and you can tell me if you'd like
me to expand on it:

1) Supports use of a single, stable IP address/prefix
   across multiple provider connections

2) Natural incremental IPv6 deployment w/o need for
   IPv4-embedded IPv6 address formats

3) Natural support for NAT traversal 

4) No need to upgrage/replace CPE routers

5) Mobility management as an in-built feature of the
   architecture.

6) Solves tunnel path MTU interactions

7) list continues on from here...

Thanks - Fred

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Monday, February 07, 2011 10:11 AM
> To: Templin, Fred L
> Cc: Daniel Roesen; [email-masked]
> Subject: Re: [v6ops] Fwd: New Version Notificationfor 
> draft-troan-v6ops-6to4-to-historic-00
> 
> I'm not deeply familiar with the protocol, but at first 
> glance it seems to be a system for balkanizing the Internet.  
>  In what respect is this "something better?"   Am I 
> misunderstanding what the protocol does?
> 
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Feb 2011 19:24:27 +0100

Hi,

> 6rd is great for ISPs.  It doesn't solve the problem for individual users.

Neither does 6to4 with badly deployed anycast relays.

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: Gert Doering <[email-masked]>
Date: Mon, 7 Feb 2011 19:28:07 +0100

Hi,

> I just posted the following draft suggesting that we move the 6to4 documents to historic.

I think 3056 is harmless enough as it is, provided connectivity to
"non-6to4" IPv6 is not happening (not *at all*, since you can't control
the return path even if the outgoig relay is sane).

3068 is where the breakage comes from.

3056 with "only used for packets going to 2002: addresses, sourced from
2002: addresses" is useful.

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 13:30:42 -0500

> Neither does 6to4 with badly deployed anycast relays.

so fix the anycast relays.  it's easier to do that than to get either 6rd or pure v6 everywhere.

Keith

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 7 Feb 2011 19:33:19 +0100

> 6rd is great for ISPs.  It doesn't solve the problem for individual users.

And who does an individual user contact if "Internet doesn't work" due
to 6to4? Correct, the ISP. Unfortunately the ISP has only a limited
chance to "make it work" - 6RD at least facilitates that.

Anycast 6to4 is a promise which won't be delivered in a globally working
manner anymore. The operational community has realized that. 6RD is the
variant which has a chance to be supportable yet lightweight (it just
still needs RIPE RIR policy fixes to be really easily deployable).

Best regards,
Daniel

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Feb 2011 10:36:57 -0800

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Keith Moore
> Sent: Monday, February 07, 2011 10:31 AM
> To: Gert Doering
> Cc: [email-masked]; Daniel Roesen
> Subject: Re: [v6ops] Fwd: New Version Notification 
> fordraft-troan-v6ops-6to4-to-historic-00
> 

IRON also uses anycast relays. IRON service providers
will naturally ensure well-managed deployments so as
to provide a high-quality service to their customers.

Fred

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

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 7 Feb 2011 19:37:48 +0100

> Why not something better? Why not IRON:

Find a significant base of cheap CPE vendors supporting it, and an
ecosystem for the ISP-side systems. All ready to deploy within the next
few months in ~production quality, CPEs shipping in the numbers with many
zeros (6+), and an residential customer market compatible price point
(no, Cisco ISRs don't fit that).

All that for something that is needed for only a very few years until
access networks are dual-stack ready.

Too late.

Best regards,
Daniel

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 13:41:22 -0500

> to provide a high-quality service to their customers.

I'll take a look at IRON.  But the salient question is whether it's easier to fix 6to4 than to deploy IRON in a way that works better than 6to4.  It doesn't matter if IRON would work better if it were deployed than 6to4 happens to work now.   You have to consider both deployment hurdles and operational issues for both cases, and you have to consider that conditions will change by the time anything new would be deployed.

Keith

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Feb 2011 10:46:09 -0800

Hi Daniel,

- Although a CPE would be a logical platform for IRON
  client functionality, there is no requirement to touch
  the CPEs. See also the other advantages I listed to Ted
  a few messages back, and let me know if you would like
  me to expand on them.
- IRON is not a short- nor even mid-term solution; it
  is a once-and-done solution for the long term.

Thanks - Fred

> On Behalf Of Daniel Roesen
> Sent: Monday, February 07, 2011 10:38 AM
> To: [email-masked]
> Subject: Re: [v6ops] Fwd: New VersionNotificationfor

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Feb 2011 19:55:47 +0100

Hi,

On Mon, Feb 07, 2011 at 01:30:42PM -0500, Keith Moore wrote:
> so fix the anycast relays.  

Which one, exactly?  If you can't answer that question, it cannot be done.

> it's easier to do that than to get either 6rd or pure v6 everywhere.

There's no way to fix every single anycast relay out there, and since
you can't pick which relay you want to use, some paths will always
broken.  technology fail.

Gert Doering
        -- NetMaster

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 13:04:49 -0600

> you can't pick which relay you want to use, some paths will always

Which is why 6to4 anycast really only semi-works if you use NPTv6. It's 
by no means any more desirable than NAT444, but it does allow limited 
IPv6 connectivity where IPv4 connectivity doesn't exist.

Jack

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 14:05:10 -0500

> Which one, exactly?  If you can't answer that question, it cannot be done.

that's the problem with anycast in general, isn't it?

> broken. 

doesn't follow.  what does follow is that there needs to be a way to identify broken anycast relays and either get them fixed or filter them from routing advertisements.

Keith

---

From: Fred Baker <[email-masked]>
Date: Mon, 7 Feb 2011 11:11:43 -0800

> Why not something better? Why not IRON:

"Better" is a value judgement, a comparison of a proposed solution with a set of requirements, and is often somewhat in the eye of the beholder.

I think it would be fair to say that the objective of v6ops is to deploy, operate, and maintain a ubiquitous IPv6 network comparable to the IPv4 network of today and independent of any underlying infrastructure. There may well be underlying infrastructure of various kinds - ATM, MPLS, various WAN technologies, or "Ethernet" in whatever form it may appear at the moment. However, the networks that the operators on this list operate are not networks in which one expects hosts to dynamically place circuits on an infrastructure of a different kind to provide service, but to operate as a ubiquitous and stable service. 

It may be fair to ask each type of technology to describe its relationship to that kind of service, and to carefully consider the operational implications of running it. That's where Ole is coming from in suggesting that RFC 3056 be retired; it depends on an underlying infrastructure (IPv4 addressing and anycast servers), and has been a source of problems for ISPs trying to deploy native IPv6 service as noted in RFCs 3964 and 4472, and in the drafts draft-ietf-v6ops-tunnel-loops, draft-ietf-v6ops-tunnel-security-concerns, draft-kuarsingh-v6ops-6to4-provider-managed-tunnel, and draft-vandevelde-v6ops-harmful-tunnels. That is also at least in part where questions of other overlay networks like Teredo come in.

If I can summarize Keith's concern with 6rd, it is not that it doesn't deploy an IPv6-capable service; it is that the service has a smaller Path MTU than the native MTU of links he uses, often has a broken PMTU implementation due to ICMPv6 filtering, and is not native. If I can summarize the views of those using it (such as a Dutch provider I spoke with Wednesday in London), it's not that they don't want or expect to deploy a native IPv6 service, it's that they want to deploy an IPv6 service now and have infrastructure that they can't immediately upgrade (such as, in the Dutch case I mentioned, a service network that they have to use that is IPv4-only for the foreseeable future).

Similar exchanges can be described around dIVI, 4rd, and ds-lite. Fundamentally, if my bread and butter today is IPv4 and my shiny new IPv6 network will in the nature of the case require some time to harden, why would I disrupt my bread and butter to deploy the new, and while doing so make my present business model dependent on the not-yet-hardened network? They are very reasonable ways to remove IPv4 from a dual stack network, but from the perspective of risk an odd way to deploy the IPv6 network.

If you want to make the case that IRON is "better" than something else, I think the thing to do is write the applicability statement. The networks on this list operate as a ubiquitous and stable service comparable to the present IPv4 network and independent of any underlying infrastructure; anything else needs to help them move toward that goal, and needs by nature to be effortlessly removed from the network as native IPv6 deployment settles in. What is the applicability of IRON to such a network?

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 14:12:41 -0500

On Feb 7, 2011, at 2:04 PM, Jack Bates wrote:

> Which is why 6to4 anycast really only semi-works if you use NPTv6. It's by no means any more desirable than NAT444, but it does allow limited IPv6 connectivity where IPv4 connectivity doesn't exist.

NPTv6 is completely irrelevant here.   And whether 6to4 is more desirable than NAT444, or vice versa, depends on what your specific needs are at the moment.   Really it's a false dichotomy.  Users need both v6 and v4 connectivity at the same time, and they need both of them to work from everywhere (or at least, from any connection mechanism that we currently use to support mobility). 

Keith

---

From: Fred Baker <[email-masked]>
Date: Mon, 7 Feb 2011 11:15:49 -0800

> 6rd is great for ISPs.  It doesn't solve the problem for individual users.

The folks in this working group are mostly ISPs, and are mostly working on the problems of ISPs...

I recognize the issues of individual users; ipv6.juniper.org is essentially unusable from my home because of path MTU issues, to name one. At some point, it might be more useful to write an internet draft describing the problems you're concerned about and help us work out solutions or requirements for solutions, rather than simply barraging the list with "I don't like it".

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Feb 2011 20:16:55 +0100

Hi,

> that's the problem with anycast in general, isn't it?

With anycast of the sort deployed here, with no way the client can
failover to a different relay if the route back from the server is 
broken, yes.

Other sorts of anycast provide fallback mechanisms (like "multiple 
different anycast clouds" and "it's up to the client ONLY to choose 
a given 'anycast thing'").

> doesn't follow.  what does follow is that there needs to be a way 
> to identify broken anycast relays and either get them fixed or filter 
> them from routing advertisements.

And how exactly are you going to do that?  You type "www.importantsite.com" 
into your browser, the packet leaves via the 6to4 relay nearest to you 
(which is nice, dandy, and working) and you do not get a response back.  
Or you get a response with horrible latency, and packet loss.

Responsible relay operators are not the problem here.

(6to4 between consenting endpoints, both on 6to4 addresses, with no
relays in between, is a nice hack.  The anycast relays in theory also
are a very nice thing.  Experience over the last 5 or so years shows
that the practical side of things isn't - and now 6to4 is used by
hosting providers to actually delay their IPv6 rollout "due to breakage".
This is BAD.)

Gert Doering
        -- NetMaster

---

From: Fred Baker <[email-masked]>
Date: Mon, 7 Feb 2011 11:20:31 -0800

> Which is why 6to4 anycast really only semi-works if you use NPTv6. It's by no means any more desirable than NAT444, but it does allow limited IPv6 connectivity where IPv4 connectivity doesn't exist.

I'm very confused. If you are using NPTv6, you have native IPv6 service. If you have native IPv6 service, why on earth would you be using 6to4?

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 13:23:35 -0600

On 2/7/2011 1:12 PM, Keith Moore wrote:
> NPTv6 is completely irrelevant here.   And whether 6to4 is more
> desirable than NAT444, or vice versa, depends on what your specific
> needs are at the moment.   Really it's a false dichotomy.  Users need
> both v6 and v4 connectivity at the same time, and they need both of them
> to work from everywhere (or at least, from any connection mechanism that
> we currently use to support mobility).
>

No. NPTv6 combined with 6to4 anycast removes the return anycast server 
requirement. The problem is, it also does NAT66.

I agree with your sentiments of what it should be. If we'd actually 
started the mad rush to IPv6 a decade ago, we'd be happily playing on 
our IPv6 networks and not have had any issues. 6to4 wasn't designed with 
the mindset that we'd actually run out of IPv4 before starting the IPv6 
migrations.

IPv4 peer to peer will break for some/many customers. CGN is coming. We 
waited too long. 6to4 peer to peer capabilities will break with CGN, 
even using anycast (as with CGN, 6to4 anycast requires NAT66). While 
ISPs are now pushing vendors for implementations at the last minute, 
many corporations still believe there will be IPv4 forever and IPv6 is 
unnecessary.

Jack

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 14:23:59 -0500

> The folks in this working group are mostly ISPs, and are mostly working on the problems of ISPs...

Well, that's a problem, isn't it?  Not that there's a ready solution...but it does help to acknowledge the limited view of this group and the potential consequences from that.

> I recognize the issues of individual users; ipv6.juniper.org is essentially unusable from my home because of path MTU issues, to name one. At some point, it might be more useful to write an interne…

Since when were arguments of the form "this will break things that people need" out of scope?

Also it seems like writing an I-D is not a good substitute for confronting the differences head on.  All too often, I-Ds have become a way to let people talk past each other and avoid trying to resolve the tussles. 

Though I don't have an objection to writing an I-D once the issues become a bit clearer.

Keith

p.s. have you tried path MTU clamping on your home router?

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 13:26:05 -0600

On 2/7/2011 1:20 PM, Fred Baker wrote:
>
> I'm very confused. If you are using NPTv6, you have native IPv6
> service. If you have native IPv6 service, why on earth would you be
> using 6to4?

I can NAT66 from 2002:: prefixes to my native prefixes (I have native 
IPv6 at all ISP 6to4 relays). I'd be using 6to4 in any scenario where a 
customer did not support any other IPv6 mechanism (ie, no 6rd support, 
no native support).

Jack

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 7 Feb 2011 11:29:13 -0800

> Neither does 6to4 with badly deployed anycast relays.

+1

I already null route the anycast address because it cause a mess in my
CGN/NAT tables ... since i use bogon space to  my users they think
6to4 might work.

Yes... I am the face of the future internet.

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 13:33:35 -0600

> people need" out of scope?

When it's already been recognized that those things will break and no 
one is providing a good solution, or people ignore the already existing 
solutions.

Given implementation time frames, the best v6ops can hope for is to 
clarify on current problems and currently implemented available 
solutions to make things as interoperable as possible; accepting that 
there are some problems we just can't fix (as some are IPv4 problems 
which happen to effect some of the IPv6 transition tools).

Jack

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 14:33:58 -0500

> failover to a different relay if the route back from the server is 

That's part of the problem.  The other part is that when a bunch of things all answer to the same address (and/or source things from the same address), it's more difficult to identify the ones that are broken and hold them accountable.  Not impossible, but more difficult.

Ideally hosts would be able to route around broken relays.  Maybe such a mechanism can be devised.  But if there were a way to track down broken relays and neutralize them, I think that would be sufficient.  

(Note also that 6to4 is separate from anycast relays.  If there were a means to keep 6to4 working but improve on the current anycast relays as a way to gateway between native and 6to4, it would be worth considering.  A different kind of relay might still be easier to deploy than 6rd, configured tunnels, or some other proposal which would replace 6to4 entirely)

> Or you get a response with horrible latency, and packet loss.

I don't have an immediate answer.   Whatever the solution is, it's not likely to be something that end users can use directly.   Which is of no great consequence, as users are in a lousy position to get network problems fixed anyway.

Brian's draft identifies several failure modes, so it's important to test for each of those.

> hosting providers to actually delay their IPv6 rollout "due to breakage".

Certainly agree that it's BAD and needs to be fixed.  But let's try not to overreact.

Keith

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 13:34:46 -0600

> CGN/NAT tables ... since i use bogon space to  my users they think

Do you have NAT66 support yet that you could possibly deploy on anycast 
relays to convert the 2002:: addresses to your own IPv6 addresses?

Jack

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 7 Feb 2011 11:44:18 -0800

> relays to convert the 2002:: addresses to your own IPv6 addresses?

Nope, and not interested since customers don't care about this 6to4
service.  The only people that care are network admins that have to
deal when it breaks the user or the network.  Customers care that
facebook and google and pandora work ... they are generally not
interested in these transport messes, and that is why IPv6 is still
not deployed in MOST place.

For customers that know what IPv6 is, i have a solution for them,
native IPv6 access, 200 million+ covered people in the USA.

http://groups.google.com/group/tmoipv6beta

The days of figuring out transition mechanisms is over.  IPv4 is
really exhausted, people need to think about things that are real and
production scale.  6to4 is neither, its more of a hobby than an
infrastructure and the major content players cite 6to4 as a roadblock.
 Nobody's fault, just the way it is.

Your efforts are better spent on rolling out native IPv6 now than
trying to fix something that was built on some pretty naive
assumptions (20-20 hind sight), like that fact that BOGONs would not
be used and IPv4 at the end user would be available in the "IPv4
end-times".

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 07 Feb 2011 15:39:11 -0500

Jack,

There is code we are now testing which implements 6to4 with NAT66.  This
will translate 2002::/16 to provider block. (Based
draft-kuarsingh-v6ops-6to4-provider-managed-tunnel)

Testing and characterization underway.  We will let the group know how
well this will work.

Victor K

---

From: Mark Smith <[email-masked]>
Date: Tue, 8 Feb 2011 07:03:48 +1030

On Mon, 7 Feb 2011 19:28:07 +0100

> 3068 is where the breakage comes from.

I struggle to believe this when people say it. I've been using 6to4
connectivity for years, and haven't had any real issues. Maybe I've
mostly been lucky with the 6to4 anycast relays I've been using. On one
occasion I did end up using a broken one, however I was able to
identify who ran it using IPv4 traceroute and whois. I didn't even get
around to emailing them, as the problem disappeared fairly quickly.

On purpose I've configured the 6to4 tunnel MTU to 1472 (derived from
PPPoE MTU of 1492), rather than leaving it at 1280, so that I would more
likely encounter PMTU issues if there were issues with them. I don't
seem to have experienced those. Fred mentioned having trouble
ipv6.juniper.org (or is it ipv6.juniper.net, ipv6.juniper.org seems
to be domain squatter site?) - in either case, I'm not having trouble
(I've just checked to make sure I'm accessing it over IPv6, which I
am, and that includes my end announcing an MSS of 1412 (1472 - 40 -
20)). The only other thing that might be mitigating any problems is
that my 6to4 end-point desktop PC (i.e. this one) is directly attached
to the Internet, rather than being behind a NAT or firewalling CPE. For
a while I was having trouble with IPv6 not being preferred when IPv4
and IPv6 were available, however I realised that was related to source
address selection and native IPv4 being preferred over tunnelled IPv6.
I changed that more than a year ago and still can't seem to fault it.

Sure native connectivity is far better. However, I'd be disappointed if
6to4 went away, as it has been a good option for me. Perhaps an RFC on
how to operate a 6to4 relay properly might be more useful to overcome
some of the issues with them that others seem to have seen. Part of
that advice could be that ISPs are encouraged to operate their on 6to4
relays as soon as they get native IPv6 transit, and for them to
consider the 6to4 relay another production level service, so that they
consider it's availability requirements to be the same as their DNS,
mail etc. As long as they do a proper job of it, I think deploying a
6to4 relay is a relatively easy first step for an ISP to start
presenting some IPv6 services to their customers.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Feb 2011 10:21:46 +1300

> 2002: addresses" is useful.

Yes, and this why (when someone first proposed solving this problem
by telling people to STOP DOING THAT when they don't even know they're
doing it) I started work on the draft-carpenter-v6ops-6to4-teredo-advisory
draft. I strongly believe that's a much better use of IETF time and
money than reclassifying RFC 3068 to Historic. And there is no reason
to reclassify RFC 3056, because it isn't the one causing problems.

So, this draft is
(a) technically wrong, because it reclassifies RFC 3056, and the one that
does harm is RFC 3068;
(b) wrong process-wise (RFC 2026 section 4.2.4), because it hasn't been
superseded and is in widespread use so cannot be called obsolete;
(c) not constructive, because it doesn't offer solutions;
(d) distracting us from useful work.

Note that I am *not* trying to unnaturally prolong the life of 6to4 or
Anycast 6to4. A good way to get rid of them is for all ISPs to deploy IPv6,
for example.

    Brian

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 15:42:35 -0600

> not deployed in MOST place.

Ahh, if you have real IPv6 connectivity, then I agree that supporting 
6to4 is unwarranted in any form.

The only place I consider it a concern is for isolated areas of ISP 
networks that must use CGN but cannot offer IPv6 native (or other better 
migration mechanisms).

Jack

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 7 Feb 2011 22:31:40 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, February 07, 2011 4:22 PM
To: Gert Doering
Cc: IPv6 Operations
Subject: Re: [v6ops] Fwd: New Version Notification for draft-troan-v6ops-6to4-to-historic-00

>Yes, and this why (when someone first proposed solving this problem by telling people to STOP DOING
THAT when they don't even >know they're doing it) I started work on the
draft-carpenter-v6ops-6to4-teredo-advisory
>draft. I strongly believe that's a much better use of IETF time and money than reclassifying RFC
3068 to Historic. And there is no  >reason to reclassify RFC 3056, because it isn't the one causing
problems.

>So, this draft is
>a) technically wrong, because it reclassifies RFC 3056, and the one that does harm is RFC 3068;
>(b) wrong process-wise (RFC 2026 section 4.2.4), because it hasn't been superseded and is in
widespread use so cannot be called obsolete;
>(d) distracting us from useful work.

[WEG] 
+1
Before we call 6to4 dead, I'd like to see results from things like World IPv6 day to see how things
actually worked without all of the whitelists and URL hacks in the way, especially if some providers
begin taking the recommendations in draft-Carpenter seriously to improve 6to4's performance over the
coming months. I note that several larger providers have deployed 6to4 relays because they realize
that the traffic exists whether they like it or not, and they'd rather it work more reliably for
their customers. There are lots of people fond of saying "just abandon 6to4; it doesn't work" when
most of the reasons it doesn't work are manageable given some proper recommendations.
We need to think very carefully about making recommendations to abandon protocols that are still in
use. We want people to deploy IPv6, but we seem content to ignore valid transition techniques *that
are already deployed* as "not really IPv6" not because they are technically flawed, but because we
didn't provide enough guidance to implement them in a way that makes them consistently functional. 
And then we wonder why people look at the IETF as confused, inconsistent, disconnected from reality,
etc.
Does it make sense for new devices to support 6to4 as their *only* IPv6 support? Absolutely not! But
like IPv4, we're stuck with what's already out there, and as an operator, I'd rather make it work
properly than ignore it, because I can't control when it goes away. And if it makes a few more
devices IPv6-capable before dual-stack is there, that's a win in my mind.

Wes George

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Feb 2011 14:46:29 -0800

Hi Fred, 

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Monday, February 07, 2011 11:12 AM
> To: Templin, Fred L
> Cc: IPv6 Operations
> "Better" is a value judgement, a comparison of a proposed 
> solution with a set of requirements, and is often somewhat in 
> the eye of the beholder.

My (partial) set of requirements that IRON satisfies includes:

1) IPv6 rollout - must support fast incremental deployment
   of IPv6 as IPv4 address depletion escalates

2) NAT traversal - must work through NATs w/o being unduly
   dependent on NAT state stability  

3) Routing Scaling - scaling to large numbers of end systems
   and networks using IPv6 must not adversely impact routing
   scaling in the core

4) Mobility management - must maintain generally shortest path
   routing for mobile end systems and networks without producing
   undue routing churn in the core

5) Multihoming - must support simultaneous connections through
   multiple providers

6) Traffic engineering - must allow customer to dynamically
   manage both in-bound and out-bound traffic classification,
   i.e., even if the link paths are asymmetric in the forward
   and reverse directions. (For example, send packets out via
   a 3G link and receive packets back via a DOCSIS link.) 

7) Provider (In)dependence - end systems and networks should
   be able to use a single, stable IPv6 address or prefix via
   multiple provider connections.

> I think it would be fair to say that the objective of v6ops 
> is to deploy, operate, and maintain a ubiquitous IPv6 network 
> comparable to the IPv4 network of today and independent of 
> any underlying infrastructure. There may well be underlying 
> infrastructure of various kinds - ATM, MPLS, various WAN 
> technologies, or "Ethernet" in whatever form it may appear at 
> the moment. However, the networks that the operators on this 
> list operate are not networks in which one expects hosts to 
> dynamically place circuits on an infrastructure of a 
> different kind to provide service, but to operate as a 
> ubiquitous and stable service. 
> 
> It may be fair to ask each type of technology to describe its 
> relationship to that kind of service, and to carefully 
> consider the operational implications of running it. That's 
> where Ole is coming from in suggesting that RFC 3056 be 
> retired; it depends on an underlying infrastructure (IPv4 
> addressing and anycast servers), and has been a source of 
> problems for ISPs trying to deploy native IPv6 service as 
> noted in RFCs 3964 and 4472, and in the drafts 
> draft-ietf-v6ops-tunnel-loops, 
> draft-ietf-v6ops-tunnel-security-concerns, 
> draft-kuarsingh-v6ops-6to4-provider-managed-tunnel, and 
> draft-vandevelde-v6ops-harmful-tunnels. That is also at least 
> in part where questions of other overlay networks like Teredo come in.

The class of services you are referring to above have in
common that they embed an IPv4 address within the IPv6
address and later extract such IPv4 addresses for stateless
tunnel endpoint discovery. IRON does not share this property.
 
> If I can summarize Keith's concern with 6rd, it is not that 
> it doesn't deploy an IPv6-capable service; it is that the 
> service has a smaller Path MTU than the native MTU of links 
> he uses, often has a broken PMTU implementation due to ICMPv6 
> filtering, and is not native. If I can summarize the views of 
> those using it (such as a Dutch provider I spoke with 
> Wednesday in London), it's not that they don't want or expect 
> to deploy a native IPv6 service, it's that they want to 
> deploy an IPv6 service now and have infrastructure that they 
> can't immediately upgrade (such as, in the Dutch case I 
> mentioned, a service network that they have to use that is 
> IPv4-only for the foreseeable future).
> 
> Similar exchanges can be described around dIVI, 4rd, and 
> ds-lite. Fundamentally, if my bread and butter today is IPv4 
> and my shiny new IPv6 network will in the nature of the case 
> require some time to harden, why would I disrupt my bread and 
> butter to deploy the new, and while doing so make my present 
> business model dependent on the not-yet-hardened network? 
> They are very reasonable ways to remove IPv4 from a dual 
> stack network, but from the perspective of risk an odd way to 
> deploy the IPv6 network.
> 
> If you want to make the case that IRON is "better" than 
> something else, I think the thing to do is write the 
> applicability statement.

We already have one of these in the RFC editor queue:

http://www.rfc-editor.org/internet-drafts/draft-russert-rangers-05.txt

Section 6 of that document in particular provides a problem
statement for which IRON is the proposed solution.

> The networks on this list operate as 
> a ubiquitous and stable service comparable to the present 
> IPv4 network and independent of any underlying 
> infrastructure; anything else needs to help them move toward 
> that goal, and needs by nature to be effortlessly removed 
> from the network as native IPv6 deployment settles in. What 
> is the applicability of IRON to such a network?

I don't agree with the "needs to be effortlessly removed"
comment - even if and when a native IPv6 deployment settles
in - since IRON runs just fine over either IPv4 or IPv6
networks. Although IRON does offer a fast-path incremental
deployment of a tunneled IPv6 service for the near term,
that service will still be attractive to customers for the
long term due to its support for mobility, multihoming,
traffic engineering and provider (in)dependence.

The reason I write it as "provider (in)dependence" is that
IRON requires someone to stand up an affordable service; see:

http://tools.ietf.org/html/draft-templin-iron-pm

To prospective IRON network operators, what is required
is strategic deployment of a few IRON relays (maybe O(10)
of these) and a number of IRON servers (maybe O(100) to
O(1000) of these). The IRON relays are full-fledged routers
that run eBGP externally and iBGP internally. The IRON
servers are low-cost commodity devices that can be purchased
at your local computer wholesaler. Performance can therefore
be tuned by ensuring that the IRON relays are well-deployed
(much in the same way as for responsibly-deployed 6rd/6to4
relays) and/or by adding additional low-cost servers in
regions where server load may become substantial.

Again, IRON is about fast transition today with a service
customers will find attractive continuing into the long
term - a once-and-done alternative.

Thanks - Fred

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 17:26:39 -0600

> draft-kuarsingh-v6ops-6to4-provider-managed-tunnel)

Thanks. I believe this is a great benefit to 6to4 anycast in regards to 
CGN networks that must still support 6to4. I theoretically would solve 
the no return path problem, but I'm worried about the NAT66 in a general 
case.

Jack

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 18:14:21 -0600

On 2/7/2011 2:33 PM, Mark Smith wrote:
> Part of

We established a HE tunnel specifically to handle a 6to4 relay years 
ago. Sprint was advertising one via BGP and it had several IPv6 
connectivity issues. Offering it ourselves allowed for easier support 
and better customer experience.

Jack

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 00:20:34 -0500

On Feb 7, 2011, at 2:26 PM, Jack Bates wrote:

> I can NAT66 from 2002:: prefixes to my native prefixes (I have native IPv6 at all ISP 6to4 relays).

yes, but then you're providing v6 service that's about as broken as v4 service with CGN.  please don't do that.  v6 should be NAT free.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 00:22:10 -0500

> Yes... I am the face of the future internet.

if you're bent on breaking standard transition mechanisms you should expect to lose all of your customers as well as your peers.   and good riddance.

make no mistake, what you are doing is completely unacceptable.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 00:23:39 -0500

On Feb 7, 2011, at 2:33 PM, Jack Bates wrote:

> When it's already been recognized that those things will break and no one is providing a good solution, or people ignore the already existing solutions.
> 
> Given implementation time frames, the best v6ops can hope for is to clarify on current problems and currently implemented available solutions to make things as interoperable as possible; accepting that there are some problems we just can't fix (as some are IPv4 problems which happen to effect some of the IPv6 transition tools).

strongly disagree.

there's a very real risk that CGN will thwart the ability to transition to IPv6.   it may need a mercy killing.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 00:44:41 -0500

> If I can summarize Keith's concern with 6rd, it is not that it doesn't deploy an IPv6-capable service; it is that the service has a smaller Path MTU than the native MTU of links he uses, often has…

If by "Keith" you mean me, I can acknowledge all of those concerns, but overall I like 6rd (for the reasons you cite).  My problem with 6rd is that it's not something than an individual user who needs IPv6 can deploy independently of support from his ISP.  6to4 is such a mechanism, and that's it's great virtue.   

Of course, as IPv4 becomes more and more broken, 6to4 can be expected to work less and less well, just like the rest of the IPv4 internet.   That's inevitable.   Really I see two major problems:

1. ISPs that want to impose CGNs on their customers before providing them any way to use v6 at all. The CGN breaks 6to4 and there is no suitable replacement.
2. Users connect to the Internet via a wide variety of means - local Ethernet, wireless WAN, cell modem, hotel networks, Starbucks, etc., and typically they get those services from a variety of providers.  So just because an ISP provides a means to allow its customers to use v6 doesn't mean that customer's problems are solved.  The customer needs a predictable way to get to "the (IPv6) net" via all of these, or at least most of them.  (though I do find that with a good cell modem, I need to connect to random networks much less frequently than before...)

Regarding IRON, I expect that it's biggest problem is that it's way behind on the deployment curve.   That doesn't mean it's not worth considering of course, though one wonders how many of the myriad different possible transition mechanisms we need to implement.

Keith

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 7 Feb 2011 21:56:43 -0800

On Feb 7, 2011 9:22 PM, "Keith Moore" <[email-masked]> wrote:
> if you're bent on breaking standard transition mechanisms you should
expect to lose all of your customers as well as your peers.   and good
riddance.
> make no mistake, what you are doing is completely unacceptable.

Interesting statement.

Cb

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 07 Feb 2011 22:22:16 -0800

> make no mistake, what you are doing is completely unacceptable.

I think we can slightly elevate the civility of this thread. Ad hominem
does not have a place in the dicussion of the merits or lack thereof of
transition methods or the decisions of individual actors.

thanks
joel

---

From: Martin Millnert <[email-masked]>
Date: Tue, 08 Feb 2011 01:24:35 -0500

> be used and IPv4 at the end user would be available in the "IPv4

Cameron,

I like what you do at TMO.  However I can't wrap my head around the
logic in what you write here.  (If you are null-routing 192.88.99.0/24
for users who are not offered native v6 you are quite possibly part of
Google et als brokeness, btw! )

"Content providers think 6to4 is a roadblock to providing IPv6"
"Stop trying to make the roadblock go away"
"[Having a fully natively enabled IPv6 network for your customers, ...]
Your time is better spent playing Sim City than trying to let 6to4 die
gently"  (my interpretation -- when will sc5 arrive? :)  )

I think we agree that the quicker 6to4 can disappear the better, but the
way for it to do so is by being replaced by [what the end-users' hosts
believe is] native IPv6.  I fully agree any operator who has not
deployed IPv6 native to all customers yet should not spend time on this
draft.  But there are those who have, and those who are not operators.

Again, 6to4 as a crappy transition mechanism dies by the sword of native
IPv6; believing anything else is to not understand the situation IMHO.
Presumably, had 6to4 not caused problems/existed, there'd be more
content available on IPv6 already, which in theory will drive more IPv6
deployment, which will kill 6to4 even more.. (loop)

This draft is a good thing <TM>.

Cheers,
Martin

---

From: Fred Baker <[email-masked]>
Date: Mon, 7 Feb 2011 22:30:23 -0800

Agreed. Believe me, I have my opinions on all of the issues. But I'm not certain that today's slugfest accomplished much in any direction.

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 07 Feb 2011 22:35:59 -0800

> Google et als brokeness, btw! )

Actually it's pretty simple t-mobile USA's internal nats are using
public space(other people's no less) , so your device thinks it actually
can use 6to4 if it supports it when in fact that space is somewhere else...

my phone currently has the v4 address 26.192.216.111

it doesn't take a genius to figure out whose space that really is...

bad idea?  definitely. did it seem less bad 10 years ago? probably to
someone who doesn't have to live with the consequences... does this have
an impact on 6to4? yes it does.

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 01:38:01 -0500

> This draft is a good thing <TM>.

I'll be happy for 6to4 to be declared Historic as soon as IPv4 is declared Historic and native v6 is universally available.  I'll be the first one to toast its demise.
Having 6to4 be obsoleted by better service is exactly what success looks like.
Until then, declaring 6to4 Historic is premature.   There are still many valid use cases for it.  Sure, some ISPs and content providers don't like it, but there's no transition scheme that everybody likes.
And deliberate denial of service attacks on 6to4 are completely out of line.

Keith

---

From: Martin Millnert <[email-masked]>
Date: Tue, 08 Feb 2011 01:51:15 -0500

> an impact on 6to4? yes it does.

Right.  A gigantic source of brokenness for content providers
unfortunately.  Try accessing a dual-stacked http-server from a Win7 box
connected with a TMO dongle with the above configuration. I expect it to
not work very well at all.  How many users were behind this
configuration, again?

I acknowledge that more networks of TMO's size or greater doing this
will start pushing OS vendors towards "6to4.default=disabled", because
it's an immensely large source of brokenness.  If it accomplishes the
goal of "6to4.default=disabled" (via Windows Update, etc), great!  If it
further delays the deployment of IPv6, not as great.

I believe MS/Apple has commented on reverting a function in an
already-released product, an update in light of this might be of
value... James,  Christopher?

Future IPv4's going to rock. :D

Cheers,
Martin

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 01:57:32 -0500

On Feb 8, 2011, at 1:51 AM, Martin Millnert wrote:
> it's an immensely large source of brokenness.  

This is a really bizarre statement.  An ISP deliberately gives out addresses to its customers that aren't assigned to said ISP, and when that breaks things you want to blame the resulting breakage on 6to4?  

6to4 is not the problem; the problem is breaking fundamental design assumptions in IP.  It's not like 6to4 is the only thing in the v4 Internet that expects globally scoped addresses to be uniquely assigned to hosts.

> If it accomplishes the goal of "6to4.default=disabled" (via Windows Update, etc), great!  

How is this statement anything other than promoting a denial of service attack?

Keith

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 07 Feb 2011 23:12:20 -0800

> not work very well at all.  How many users were behind this

that's "are behind" it. T-mobile is not the only one by far e.g. there's
no point in singling them out. it's fairly common to find mobile
carriers and indeed wireline operators squating on US DOD or uk MOD
space. As Fred Baker quipped about the distribution of ipv4 assignments
during the bejing ietf, there's a big chunk of the world where users are
already living behind huge nats.  we can extend that to "and a lot of
those nats are aren't in private scope address ranges."

The fact of the matter is we ran out of ipv4 addresses a long time ago,
and operating assumptions predicated on the assumption of the
availability have a tenuous association with the situation as deployed
in many cases.

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 08:31:26 +0100

On Tue, Feb 08, 2011 at 12:44:41AM -0500, Keith Moore wrote:
> My problem with 6rd is that it's not something than an individual
> user who needs IPv6 can deploy independently of support from his ISP.
> 6to4 is such a mechanism, and that's it's great virtue.   

That's an illusion. In contrast to 6RD, anycast 6to4 requires the
cooperation of both the ISP of the individual user (either to operate a
reliable and capacity-wise sufficiently scaled 6to4 relay or make sure
there is one reachable for his customers, as well as the cooperation of
each and any remote communication partner in the very same way, for the
reverse path. And have the cooperation from both to troubleshoot and
solve problems found.

6RD requires only the ISP who has to bridge a v4-only capable access
network and troubleshoot any problems arising from the use of 6RD within
their only bailiwick.

> 1. ISPs that want to impose CGNs on their customers before providing
> them any way to use v6 at all.

Replace "want to" by "need to". Any fast growing residential ISP is
forced to use LSN ("carrier grade" is marketing b.s. term not having any
good place in "engineering" circles) as there are no more addresses to
support the "one IP per customer connection" model.

Best regards,
Daniel

---

From: Ole Troan <[email-masked]>
Date: Tue, 8 Feb 2011 10:14:39 +0100

Brian,

> (a) technically wrong, because it reclassifies RFC 3056, and the one that

6to4 model 1 is not (and has never been) deployed (basically recreates the 6bone).
6to4 model 2, even with a consenting forward relay suffers the same issues on the reverse path.
in my view 6to4 is not salvageable. 

> superseded and is in widespread use so cannot be called obsolete;

from the same paragraph: "or is for any other reason considered to be obsolete is
                          assigned to the "Historic" level."

I think we can equate deprecating 6to4 to deprecating NAT-PT. it is harmful to IPv6 deployment.

> (c) not constructive, because it doesn't offer solutions;

the draft requests 6to4 to be deprecated, it is not the place to offer solutions.
I think the "problem" 6to4 solves is miniscule. it provides a mechanism for us techies to play with IPv6.
the solution is that the end user's service provider enables IPv6. Internet wide tunneling technologies specifically designed to bypass the underlaying infrastructure are hard to make work. I can't think of a single example where we have technology that makes that work well, supporting all the requirements that Fred listed.

> (d) distracting us from useful work.

6to4 is what is distracting us. having to fix brokenness triggered by 6to4.

> Anycast 6to4. A good way to get rid of them is for all ISPs to deploy IPv6,

and until that happens (SP deploys IPv6), IPv6 deployment will not happen. 6to4 does not in any way accelerate IPv6 deployment.

if the draft can achieve that:
 - CPE and hosts vendors stop enabling 6to4 by default
 - no-one advertises 6to4 AAAA records in DNS
 - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS algorithms.
 - people stop considering 6to4 as a valid transitioning mechanism; there are too many choices already.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 8 Feb 2011 10:48:26 +0100

Keith,

> The fix for 6to4's problems is proper network configuration.

proper network configuration of every network on the planet?
I just can't see how 'sane' 6to4 can be deployed...
 - no blocking of protocol 41 anywhere
 - no bogons, no CGNs
 - no MTU issues, no blocking of ICMPv4 or ICMPv6. all IPv4 routers upgraded to provide full packet in ICMPv4
 - all IPv6 content providers have a 6to4 address available
 - every IPv4 only network run a forward relay
 - every IPv6 network run a reverse relay

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 11:27:56 +0100

Le 7 févr. 2011 à 20:11, Fred Baker a écrit :
> ...
> If I can summarize Keith's concern with 6rd, it is not that it doesn't deploy an IPv6-capable service; it is that

> the service has a smaller Path MTU than the native MTU of links he uses,

A negligible concern compared to the lack of deployed native-IPv6 addresses, and to the complexity of problems that have to be faced with 6to4.
As long as PMTUD isn't considered reliable, site-to-site IPv6 is safer with MTU = 1280 than with any other choice.

> often has a broken PMTU implementation due to ICMPv6 filtering

AFAIK, broken PMTUD isn't due to 6rd, but more data on this subject are welcome.
Anyway, that's the reason to stay with 1280 (still permitting application-layer datagrams to be much larger).

> , and is not native.

Not natively routed in the ISP network, that's true.
But::
- Hosts can't even notice it
- Addresses are as native as those natively routed by ISPs.

> If I can summarize the views of those using it (such as a Dutch provider I spoke with Wednesday in London), it's not that they don't want or expect to deploy a native IPv6 service, it's that they want to deploy an IPv6 service now and have infrastructure that they can't immediately upgrade (such as, in the Dutch case I mentioned, a service network that they have to use that is IPv4-only for the foreseeable future).

That's exactly the scope of 6rd, and why it is useful.

Regards,
RD

---

From: Martin Millnert <[email-masked]>
Date: Tue, 08 Feb 2011 05:59:11 -0500

Ole,

> there are too many choices already.

The first (and maybe 3rd) point seems to be the most potent ones to me,
because of the relative few orgs who have some form of ability of making
this happen on a lot of hosts at the same time.

But the important thing to figure out at this point, IMO, is: would they
disable it on running hosts?  Eg, would host stack vendors flip 6to4
default off on running hosts today (there are a few) given this drafts
existence?  My support of this draft must follow the answer to that
question.

(I seem to remember DNS to well-known addresses being deprecated but
still used by one of the vendors.)

Regards,
Martin

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Feb 2011 04:24:50 -0800

> ago.

satan has a tail and horns

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 08:07:22 -0500

> - no blocking of protocol 41 anywhere

what's wrong with that?  you act like it's somehow bizarre to expect IP packets to get through the network unchanged. 

> - no bogons, no CGNs

admit it, bogons and CGNs are pretty broken.  maybe they're unavoidable given the lack of v4 space.  but what I'm saying is not to get rid of them, I'm saying those guys need to offer native v6 on the same ports ASAP.

> - no MTU issues, no blocking of ICMPv4 or ICMPv6. all IPv4 routers upgraded to provide full packet in ICMPv4

YMMV, but I found MTU clamping to work pretty well for me. 
yeah, general blocking of ICMP is pretty brain damaged.   though carefully chosen blocking can work.

> - all IPv6 content providers have a 6to4 address available

not necessary.

> - every IPv6 network run a reverse relay

nor these.

why is it unreasonable to expect network operators to move packets across the net intact?  isn't that their job?

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 08:30:08 -0500

> 6to4 model 1 is not (and has never been) deployed (basically recreates the 6bone).

Incorrect on both counts.

> in my view 6to4 is not salvageable. 

Perhaps that's because you haven't tried to identify solutions?  it is possible, for instance, to identify and marginalize broken relay routers.

> I think we can equate deprecating 6to4 to deprecating NAT-PT. it is harmful to IPv6 deployment.

6to4 is not harmful to IPv6 deployment.  ISPs that break IPv4 are harmful to IPv6 deployment.

> I think the "problem" 6to4 solves is miniscule. it provides a mechanism for us techies to play with IPv6.

6to4 provides a way for anyone with any properly working IPv4 connect to connect to any IPv6 host.   That's a huge win.  It eliminates one of the barriers toward IPv6 acceptance by providing a means for universal access to IPv6 over any properly working IPv4 connection.

> 6to4 is what is distracting us. having to fix brokenness triggered by 6to4.

No, 6to4 is not broken.   6to4 is just sending IP packets and expecting them to get to the hosts associated with their destination addresses intact.

The network is broken because of many brain damaged practices in place for other reasons, and 6to4 is one of many things suffering because of it.  

(I sometimes suspect that 6to4 is also suffering because some operators see it as an end-run around them, so they don't mind implementing measures that penalize it.   But that's not a problem with 6to4....)

> and until that happens (SP deploys IPv6), IPv6 deployment will not happen. 6to4 does not in any way accelerate IPv6 deployment.

Completely incorrect.   See above.

I think the statement in a nutshell is this: as long as operators insist on seeing 6to4 as a 'problem' rather than a way to provide their customers good service and a useful transition tool, they're going to keep sabotaging it.  By doing so they're actually impairing deployment of IPv6.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 08:40:24 -0500

> reverse path. And have the cooperation from both to troubleshoot and

I get what I think is your point, which is that in order for 6to4 to work, operators actually have to make sure that their IP networks work properly (deliver packets intact to their specified destinations), and they either have to 
a) operate their own properly working anycast relays, or 
b) do some QA on any advertisements of anycast relays that they receive from peers and filter out those that don't work well, or
c) just get lucky at having peers with working anycast relays

...but I've also successfully used 6to4 on/through many networks that didn't have any explicit operator support for it.   

Also, I don't think that any of the above should be onerous.  e.g. regarding route advertisements, don't operators have to do some amount of QA and filtering for route advertisements anyway?  Can operators really get away with blindly trusting their peers to advertise reasonable BGP routes in general?

> network and troubleshoot any problems arising from the use of 6RD within

If operators prefer either 6rd or pure v6 to 6to4, I have no problem with that.  Just don't break 6to4 before implementing something better.

> Replace "want to" by "need to".

I don't really buy "need to".  There are lots of ways to better allocate existing IPv4 addresses that are probably applicable to most networks.   What I accept is that CGN is the current fad.

Keith

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 07:51:26 -0600

> there's a very real risk that CGN will thwart the ability to transition to IPv6.   it may need a mercy killing.

Errr, not at all. You try doing all the things users want to do with 
CGN. No ISP wants to do it.

Jack

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 07:56:30 -0600

On 2/8/2011 12:38 AM, Keith Moore wrote:
> Sure, some ISPs and content providers don't like it, but there's no transition scheme that everybody likes.

I think both of you missed Cameron's point. His IPv4 is CGN, so 6to4 
breaks. The only way he could revive any 6to4 functionality would be 
NPTv6 on 6to4 relay, which he prefers to just offer the IPv6 native 
trial over doing that.

Jack

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 08:59:42 -0500

On Feb 8, 2011, at 8:51 AM, Jack Bates wrote:

> Errr, not at all. You try doing all the things users want to do with CGN. No ISP wants to do it.

Well, it seems to me that 6to4 is yet another thing that users want to do with CGN, and the operator outcry against 6to4 is that somehow the operators think that people don't want/need a way to do 6to4..or at least some other form of IPv6 that works without explicit setup on the user's part.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 09:04:15 -0500

On Feb 8, 2011, at 8:56 AM, Jack Bates wrote:

> I think both of you missed Cameron's point. His IPv4 is CGN, so 6to4 breaks. The only way he could revive any 6to4 functionality would be NPTv6 on 6to4 relay, which he prefers to just offer the IPv6 native trial over doing that.

I think that's fine... the main thing is that a host connecting via CGN should also see v6 RAs on the same link, so it will automagically enable v6 that way and won't need to enable 6to4.  

Though I do think there's a huge problem with CGNs reusing space that is not already known to be private space... host OSes have no indication that they should not enable 6to4 on those stacks.  
(Blocking port 41 is a poor solution; returning ICMP unreachable is not much better...do you really want to break ALL IP-in-IP tunnels?)

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 08:05:19 -0600

> satan has a tail and horns

You crack me up, Randy.

Had to maintain QOS until I could roll out native IPv6. I don't like the 
tunnel for mass production traffic, so I've had to wait on native 
connectivity. I just recently managed to get the L3 native v6 circuit. 
Better than nothing, I guess.

Jack

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 08:07:25 -0600

On 2/8/2011 8:04 AM, Keith Moore wrote:
> I think that's fine... the main thing is that a host connecting via 
> CGN should also see v6 RAs on the same link, so it will automagically 
> enable v6 that way and won't need to enable 6to4.
>
> Though I do think there's a huge problem with CGNs reusing space that 
> is not already known to be private space... host OSes have no 
> indication that they should not enable 6to4 on those stacks.
> (Blocking port 41 is a poor solution; returning ICMP unreachable is 
> not much better...do you really want to break ALL IP-in-IP tunnels?)
>

Doesn't happen, though. You have to sign up for IPv6 from them. 
Otherwise, it's still a v4 world; for now.

Jack

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 08:09:47 -0600

> Well, it seems to me that 6to4 is yet another thing that users want to do with CGN, and the operator outcry against 6to4 is that somehow the operators think that people don't want/need a way to do…

Hey, I even gave one idea for a semi broken 6to4 anycast mechanism 
behind CGN. Sorry, but CGN breaks things. That's the way it will be. If 
native IPv6 isn't to every location, they'll be behind the broken net.

FYI, CGN is the best thing for IPv6. It's an IPv4 killer app. :)

Jack

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 09:11:19 -0500

On Feb 8, 2011, at 9:09 AM, Jack Bates wrote:

> Hey, I even gave one idea for a semi broken 6to4 anycast mechanism behind CGN. Sorry, but CGN breaks things. That's the way it will be. If native IPv6 isn't to every location, they'll be behind the broken net.
> 

unfortunately, it might end up killing v6 also.

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 15:15:09 +0100

Le 7 févr. 2011 à 20:26, Jack Bates a écrit :

> I can NAT66 from 2002:: prefixes to my native prefixes (I have native IPv6 at all ISP 6to4 relays). I'd be using 6to4 in any scenario where a customer did not support any other IPv6 mechanism (ie, no 6rd support, no native support).

The problem is that, doing that, e2e address transparency, which was available between two 6to4 addresses, is now broken!
New solutions should first avoid breaking uses that already exist. 

Besides, restored e2e transparency is one of the important new features of IPv6.

Regards,
RD

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 09:17:15 -0500

> unfortunately, it might end up killing v6 also.

It seems to me that the premise behind this assertion is that you think that killing 6to4 will kill IPv6.   It makes sense that you want 6to4 for your particular application, but it doesn't make sense to say that killing 6to4 will kill IPv6.   I don't think it adds to the discussion to overdramatize.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 08:17:32 -0600

> New solutions should first avoid breaking uses that already exist.
I'm up for you providing a solution for CGN + 6to4. Until then, we 
either break 6to4 completely or we provide a little packet mangling. At 
least it's only 1:1 NAT.

Jack

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Feb 2011 06:24:58 -0800

> Anyway, that's the reason to stay with 1280 (still permitting application-layer datagrams to be much larger).

I think we're agreeing on that. I suggested that PMTUD is often broken when folks filter ICMPv6, and ICMPv6 Destination Unreachables often happen when a datagram hits a tunnel. In my case, the tunnel has something to do with Hurricane Electric; in the 6rd case, it's an IPv6/IPv4 encapsulation. Either way, if the sender of the datagram can't receive the signal to reduce its datagram size, it won't, and the receiver won't get its datagrams.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 09:31:13 -0500

On Feb 8, 2011, at 9:17 AM, Jack Bates wrote:
> I'm up for you providing a solution for CGN + 6to4. Until then, we either break 6to4 completely or we provide a little packet mangling. At least it's only 1:1 NAT.

A replacement that doesn't deliver the functionality that the thing it replaces delivers is not a replacement.   The right solution to the problem is the one Keith describes: don't deploy CGN without v6.   Of course, v6ops is not in a position to mandate this, and indeed I suspect that there is no consensus in the working group that this even matters.   But let us at least agree on what we are talking about, and not pretend that non-solutions are solutions.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 09:03:29 -0600

On 2/8/2011 12:57 AM, Keith Moore wrote:
> 6to4 is not the problem; the problem is breaking fundamental design
> assumptions in IP.  It's not like 6to4 is the only thing in the v4
> Internet that expects globally scoped addresses to be uniquely
> assigned to hosts.

Except that ARIN is proposing a /10 for this specific purpose (since it 
failed the IETF). It will be just as broken with 6to4; as 6to4 uses a 
hack to disable (RFC-1918 awareness) and using RFC-1918 for a CGN is 
even worse than breaking 6to4.

Failed protocol. Someone should have set a flag for an ISP to specify 
support or no support for 6to4, even a simple dns query would have done. 
Too late now, operators will just break it.

I realize their IPv6 trial doesn't help the thousands of clueless 
windows 7 users, which is why the easiest hack is for t-mobile to 
support 6to4 anycast + NAT66, but I doubt they have an implementation 
for that yet.

Now, here's the import part. Rolling out pure IPv6 to everyone will 
create it's own brokenness (6to4 policy is less used than pure IPv6 
policy). It will happen soon, but we aren't quite to that point yet and 
there is a LOT of isolation issues.

Jack

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 09:06:16 -0600

I allocate IP addresses at 95%+ utilization. What optimizations?

Jack

On 2/8/2011 7:40 AM, Keith Moore wrote:
> I don't really buy "need to".  There are lots of ways to better
> allocate existing IPv4 addresses that are probably applicable to most
> networks.   What I accept is that CGN is the current fad.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 09:19:03 -0600

On 2/8/2011 8:31 AM, Ted Lemon wrote:
> A replacement that doesn't deliver the functionality that the thing
> it replaces delivers is not a replacement.   The right solution to
> the problem is the one Keith describes: don't deploy CGN without v6.
> Of course, v6ops is not in a position to mandate this, and indeed I
> suspect that there is no consensus in the working group that this
> even matters.   But let us at least agree on what we are talking
> about, and not pretend that non-solutions are solutions.
>

Deploying native IPv6 with the LSN still isn't effective. Currently, in 
some cases, it will cause more breakage than breaking 6to4. With native 
IPv6, AAAA is almost ALWAYS preferred over A, where as 6to4 only uses 
AAAA when there is no A or if there is a 6to4 AAAA.

Don't get me wrong, we are getting there, but just throwing users on a 
broken IPv6 network is not cost effective.

Not deploying LSN is not an option. When you are out of space, you are 
out of space. LSN actually breaks less for the majority of customers 
than deploying native IPv6 has. This is slowly changing as IPv6 
isolation and pathing is resolved and the networks upgrade. Until core 
networks fix themselves, it will still be a mess for edges and content 
providers.

Jack

---

From: Tore Anderson <[email-masked]>
Date: Tue, 08 Feb 2011 16:36:04 +0100

Hi,

* Keith Moore

> harmful to IPv6 deployment.

6to4 was the major reason why I had to delay deploying AAAAs for the
sites I host. Instead of being able to deploy, I had to run around for
more than a year begging hardware and OS vendors to turn it off.

So yes, 6to4 is very harmful to people wanting to deploy IPv6. Why do
you think «World IPv6 Day» is seen as necessary?

>> 6to4 is what is distracting us. having to fix brokenness triggered

Precisely.

> I think the statement in a nutshell is this: as long as operators
> insist on seeing 6to4 as a 'problem' rather than a way to provide
> their customers good service and a useful transition tool, they're
> going to keep sabotaging it.  By doing so they're actually impairing
> deployment of IPv6.

Reverse 6to4 relays deployed close to the content? Check.

That doesn't fix the problem, though. There's nothing I, or any other
individual network operator, can do to fix it. In order for 6to4 to work
reliably, *everyone* must play along. And that's simply not going to happen.

6to4 was a fun little toy for people who wanted to experiment with IPv6.
It is completely unsuitable to be Mr. John Q. Public's generic IPv6
internet connectivity. At this point in time, *real* IPv6 deployments is
necessary, and 6to4 is just getting in the way. It's time to shelve it.

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 10:40:34 -0500

On Feb 8, 2011, at 10:19 AM, Jack Bates wrote:
> Deploying native IPv6 with the LSN still isn't effective. Currently, in some cases, it will cause more breakage than breaking 6to4. With native IPv6, AAAA is almost ALWAYS preferred over A, where as 6to4 only uses AAAA when there is no A or if there is a 6to4 AAAA.

I'm not following your argument here.   Presumably if you get a AAAA, and you have v6 connectivity, you will connect successfully.   If you get an A and an AAAA, you will still connect successfully.   And if you get an A, you *might* connect successfully, if the LSN isn't overloaded, and if the NAT doesn't break something simply because it modified the packets in transit.   Where's the case where adding working v6 makes things worse?

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 09:45:38 -0600

On 2/8/2011 9:40 AM, Ted Lemon wrote:
> I'm not following your argument here.   Presumably if you get a AAAA,
> and you have v6 connectivity, you will connect successfully.   If you
> get an A and an AAAA, you will still connect successfully.   And if
> you get an A, you *might* connect successfully, if the LSN isn't
> overloaded, and if the NAT doesn't break something simply because it
> modified the packets in transit.   Where's the case where adding
> working v6 makes things worse?
>

Grandma goes to some website that has AAAA advertised and their IPv6 
address isn't on my Internet.

Grandma hits a DNS load balancer that responds to AAAA with nxdomain.

For every customer I turn up on IPv6, I find more brokenness.

Jack

---

From: Ole Troan <[email-masked]>
Date: Tue, 8 Feb 2011 17:00:35 +0100

Keith,

> Incorrect on both counts.

examples please.

> Perhaps that's because you haven't tried to identify solutions?  it is possible, for instance, to identify and marginalize broken relay routers.

how?
the problem with relays routers are that they depend on charity by 3rd parties. it is difficult to see the motivation for anyone to run a relay router in the first place.
if I thought 6to4 could be fixed I would have suggested the fixes. you seem so convinced that there are fixes, can you please share those?

[...]

> 6to4 provides a way for anyone with any properly working IPv4 connect to connect to any IPv6 host.   That's a huge win.  It eliminates one of the barriers toward IPv6 acceptance by providing a mean…

unfortunately that's not the end-user experience that has been shown.

http://www.google.com/trends?q=disable+ipv6,+enable+ipv6
(;-))
http://readonly.labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really

[...]

> (I sometimes suspect that 6to4 is also suffering because some operators see it as an end-run around them, so they don't mind implementing measures that penalize it.   But that's not a problem with…

I have seen no evidence that operators are actively blocking 6to4.
6to4 depends on the charity of others. unfortunately that's not a realistic deployment model.

> I think the statement in a nutshell is this: as long as operators insist on seeing 6to4 as a 'problem' rather than a way to provide their customers good service and a useful transition tool, they'r…

I have seen no evidence of sabotage.
all the brokenness I have seen have been caused by "this is how the 6to4/Internet works". your nearest relay is on a different continent, one of the relays on the path are overloaded, ICMP messages are blackholed, ICMP messages are blocked, bogus addresses are used, the 6to4 relay is behind some Enterprise firewall... and so on...

I just don't understand how we can get the whole IPv4 Internet fixed, plus get 6to4 deployed with relays in such a fashion that it works on reasonably equal terms with IPv4.

as you appear to have very strong opinions that 6to4 has a right of life... can you please explain how we can make it a successful protocol. where successful is almost equal to deployable.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 17:24:46 +0100

Le 8 févr. 2011 à 15:17, Jack Bates a écrit :

> I'm up for you providing a solution for CGN + 6to4.

If you look for 6to4 to be operational behind a CGN, i.e. where there is no public IPv4 address, I believe you won't find one.

If you look for 6to4 clients to have connectivity with all native-IPv6-address servers without breaking e2e address transparency, I believe you will find no solution that is incrementally deployable, i.e. you won't find any real solution.

If you look for 6to4 clients to have such connectivity with all native IPv6 addresses that e2e connectivity is broken, I believe customers should be advised to avoid ISPs that do that.

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 Feb 2011 08:32:27 -0800

> necessary, and 6to4 is just getting in the way. It's time to shelve it.

This is the conclusion i believe you will hear from all network
operators that are really doing IPv6 now.  I am not sure what it is
about tunneled IPv6 access that makes their creators so adamant about
it ... It's really native v4/v4v6/v6 or nothing on the real internet.
Why? Because people don't care about IP versions, and a tunnel is
never worth it.  They care that facebook works.  Everything else is
just pedantry.

Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 Feb 2011 08:45:06 -0800

> http://readonly.labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really

For real network operators, these above links from Ole are the death
knell for 6to4, and a strong call to support to make 6to4 historic so
OS vendors will get the clue to turn it off by default for good.

Short link just to make it real easy http://bit.ly/hl3w0n

Cameron

---

From: [email-masked]
Date: Tue, 8 Feb 2011 18:47:40 +0200

[email-masked] wrote on 08-02-2011 18:32:27:

> From: Cameron Byrne <[email-masked]>
> To: Tore Anderson <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>, Keith Moore 
<[email-masked]>
> Date: 08-02-11 18:32
> Sent by: [email-masked]
> 

> never worth it.  They care that facebook works.  Everything else is

+1 to what Tore and Cameron say

I am running a private 6to4 relay for my customers only. This indeed makes 
the service much better. However, as long as the return path is out of my 
control, it is not near as good as the native IPv6 I have and is just a 
hobby, not nearly a real service I can offer support for. And no, I don't 
have the issues Cameron currently has with the address space, in which 
situation 6to4 becomes the worst thing you could ever imagine. In a year 
from now, the 6to4 will become a dead end.
To be frank, as long as their is a solution that in any way stops the 
content providers to serve AAAAs, it is bad. At this critical time, we 
should not get distracted with any hacks. Forget tunneling, put time in 
native IPv6, commit to content owners to have them doing it as well, and 
as soon as a large part of Alexa 1M is on IPv6, the things will start 
sorting themselves out.

Best,
Roman

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 11:55:01 -0500

> you think «World IPv6 Day» is seen as necessary?

6to4 wasn't the reason - the reason was broken IPv4 networks.  But yes, since 6to4 relies on IPv4 working, when the IPv4 network breaks, 6to4 also breaks.  The problem is caused by ISPs who act as if a few applications (e.g. HTTP and SMTP) are the only ones that matter.

>>> 6to4 is what is distracting us. having to fix brokenness triggered

6to4 didn't trigger the brokenness; 6to4 merely exposed the brokenness.

Still, I'll readily grant that if people's early experience of "IPv6" is 6to4 over broken IPv4 networks, they'll have a poor impression of IPv6.  

(If memory serves, I actually pointed this out to IESG over ten years ago.  It's not like this is a new problem, though the degree of IPv4 brokenness has increased.)

> reliably, *everyone* must play along. And that's simply not going to happen.

In order for IPv4 to work reliably, *everyone* must play along.  If that can't happen anymore, neither can IPv6 be made to work reliably.

> necessary, and 6to4 is just getting in the way. It's time to shelve it.

Meanwhile lots of people are getting real work done with 6to4, and you're trying to sabotage their work in favor of a better solution that doesn't exist yet.

Keith

---

From: james woodyatt <[email-masked]>
Date: Tue, 08 Feb 2011 09:00:36 -0800

On Feb 8, 2011, at 07:36, Tore Anderson wrote:
> 
> At this point in time, *real* IPv6 deployments is necessary, and 6to4 is just getting in the way. It's time to shelve it.

Agreed.  When it's all packed up and reposing gently on a shelf somewhere-- and *not* widely used on the public IPv4 anymore-- then I will agree that moving 6to4-anycast to Historic is proper use of IETF time.  Not yet.

Operators can make 6to4 go away according to its natural evolution by deploying native IPv6 service and following the recommendations in I-D.carpenter-v6ops-6to4-teredo-advisory.  When 6to4 relays aren't needed anymore, then we should move RFC 3068 to Historic and let RFC 3056 ride off into the sunset with the rest of IPv4.

---

From: Gert Doering <[email-masked]>
Date: Tue, 8 Feb 2011 18:02:27 +0100

Hi,

> Meanwhile lots of people are getting real work done with 6to4, and you're trying to sabotage their work in favor of a better solution that doesn't exist yet.

Nobody will take away your ability to run 6to4 on *your* devices, 
communicating between *your* endpoints in any matter you like.  

"Consenting adults", and such.

It's just that for the large mass of people out there, the very existance
of 6to4 is stopping content providers from enabling IPv6, and that's *bad*,
so "6to4-on-by-default" for unsuspecting users needs to be stopped.

Do what you want with your machines, but don't insist that your solution
is any good for those that actually have researched the impact of 6to4
very thoroughly, like Tore did.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 8 Feb 2011 18:04:21 +0100

Hi,

> Agreed.  When it's all packed up and reposing gently on a shelf somewhere-- and *not* widely used on the public IPv4 anymore-- then I will agree that moving 6to4-anycast to Historic is proper use o…

Well, what would you see as necessary to make vendors disable 6to4 in
their default configuration?  Apple already did, as far as I'm aware,
and that's great :-) - so now we just need to convince the rest...

Declaring 6to4 "historic" might just be the message to send to vendors.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 09:12:11 -0800

Hi Keith,

> Regarding IRON, I expect that it's biggest problem is that 
> it's way behind on the deployment curve.   That doesn't mean 
> it's not worth considering of course, though one wonders how 
> many of the myriad different possible transition mechanisms 
> we need to implement.

Minor correction - IRON is not intended as only a transition
mechanism. IRON is tunnels-done-right, and there are many
reasons why tunnels are desireable beyond just a fast-path
to deployment of IPv6.

About deployment, there is an initial implementation of
IRON, and I am currently coding a v1.4 update:

  http://isatap.com/iron/iron-1.3.tgz

I am not a full-time linux kernel networking software
developer, but it should be easy for someone with those
skills to see that there is no rocket science behind
this. As I recall, the 6rd linux implementation went up
in a matter of days. There is no reason the full-up IRON
development profile could not progress along a similar
timeline.

Thanks - Fred

---

From: james woodyatt <[email-masked]>
Date: Tue, 08 Feb 2011 09:14:50 -0800

> Declaring 6to4 "historic" might just be the message to send to vendors.

Equipment makers that are still enabling 6to4 by default are unlikely to notice that IETF has published an RFC that moves 6to4 to Historic status.  I think World IPv6 Day will cut through the noise a lot better than this draft ever will.

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 12:16:53 -0500

On Feb 8, 2011, at 12:02 PM, Gert Doering wrote:

> Nobody will take away your ability to run 6to4 on *your* devices,  communicating between *your* endpoints in any matter you like.  

Not clear.  People are talking about blocking protocol 41, for example.

> so "6to4-on-by-default" for unsuspecting users needs to be stopped.

This is a misstatement of the problem.  It's not the existence of 6to4 that's stopping content providers from enabling v6.  It's broken networks and relay routers that are stopping content providers from enabling v6.

That said, I'm all for having a push to implement something better if we can get consensus among operators to do that.  Just don't break 6to4 until there's a widely available alternative that doesn't require explicit user setup.

> very thoroughly, like Tore did.

I've been using 6to4 ever since the RFC was published.  (I believe in eating my own dog food.)   I have observed firsthand every anomaly documented in Brian's draft.   And yet, somehow, 6to4 still works for me and my customers most of the time.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 12:17:02 -0500

On Feb 8, 2011, at 10:45 AM, Jack Bates wrote:

> Grandma goes to some website that has AAAA advertised and their IPv6 address isn't on my Internet.
> 

Well, sure.  There are lots of things in the net, like interception proxies, that are IPv6 naive.  

Of course, this should serve as a lesson: don't put those things into the network!  They don't belong there.  *Anything* that intercepts traffic and tries to interpret it on behalf of its destination has a good chance of biting you back someday.

But sadly, instead of those things being removed, what will probably have to happen is that those things get chased down and "fixed", one by one.  Just like anycast relays.

Again, it's not reasonable to blame IPv6 or 6to4 because they happen to explore brokenness that already exists in the IPv4 network.  The blame lies squarely with the operators and equipment vendors.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 12:18:58 -0500

On Feb 8, 2011, at 11:32 AM, Cameron Byrne wrote:
>> veryone* must play along. And that's simply not going to happen.
>> 

That is of course, completely false.  And operators who persist in believing that are the source of the problem. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 12:32:50 -0500

>> Incorrect on both counts.

I don't know how to give you examples.  But 6to4 never has been like the 6bone in any way other than using IP tunneling.

> the problem with relays routers are that they depend on charity by 3rd parties.

No more than the Internet depends on charity by 3rd parties to route traffic.

> it is difficult to see the motivation for anyone to run a relay router in the first place.

To provide better service to their customers?   Nah, no provider would want to do that...

> if I thought 6to4 could be fixed I would have suggested the fixes. you seem so convinced that there are fixes, can you please share those?

Best fix I see offhand is for operators to

a) implement correctly working relay routers, and/or
b) actively test whether any relay routers advertised from their peers work properly, and if not, filter their advertisements

I'm sure this can be improved on, but this is a start.

> 6to4 depends on the charity of others. unfortunately that's not a realistic deployment model.

That's also what they said about IP, once upon a time. 

> I have seen no evidence of sabotage.

Blocking proto 41 is an example of sabotage.   Blocking traffic to relay routers is an example of sabotage.   Imposing DNS interception proxies that return NXDOMAIN in response to AAAA queries is an example of sabotage.  Blocking ICMP messages is an example of sabotage.   There are several others.

None of these solutions would ever have been remotely considered acceptable had ISPs been doing their jobs in the first place - which is to route packets intact to their destinations.

> I just don't understand how we can get the whole IPv4 Internet fixed, plus get 6to4 deployed with relays in such a fashion that it works on reasonably equal terms with IPv4.

Ironically, if you could fix the v4 Internet, 6to4 would work just fine.  But you can't fix the v4 Internet.  So what you have to do is try to hold it together long enough to get native v6 deployed and get the bugs worked out of it.

> as you appear to have very strong opinions that 6to4 has a right of life... can you please explain how we can make it a successful protocol. where successful is almost equal to deployable.

I think 6to4 needs to be on life support until we can arrange for a transplant to native v6.  Operators need to stop treating 6to4 as a problem, and start treating it as something that their customers need and have a right to expect.   If they want to stop supporting it ASAP, they have my complete encouragement to do so as soon as something that's clearly better is widely available.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 12:37:34 -0500

> [email-masked]

6to4 support has shipped with Windows, *BSD, MacOS, Linux for several years now.   Even if IRON is the best thing since sliced bread, I don't see how it can compete with that any time soon.  It takes time for people to upgrade their OSes.

I don't want to discourage a potentially good long-term solution for using IPv6 in overlay networks...but realistically I don't think IRON can replace 6to4 before 6to4 reaches its natural EOL, which I hope is within 2-4 years.

Keith

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 18:44:03 +0100

Brian,

I find Ole's proposal interesting *for the new phase we are entering*, i.e. one where:
- native IPv6 adresses are progressively deployed
- 6to4, that has been extensively use despite its limitations, should now recede

Le 8 févr. 2011 à 10:14, Ole Troan a écrit :
> ... 6to4 does not in any way accelerate IPv6 deployment.
> 

+1 

> - no-one advertises 6to4 AAAA records in DNS

Except maybe where 6to4 is the only available incoming connectivity, but that's minor.

> - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS algorithms.

Ideally, RFC 3484bis would do it.

> - people stop considering 6to4 as a valid transitioning mechanism; there are too many choices already.

At least not a mechanism to be considered for new deployments.

Regards,
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 09:44:23 -0800

Hi Keith, 

> From: Keith Moore [mailto:[email-masked]] 
> Sent: Tuesday, February 08, 2011 9:38 AM
> To: Templin, Fred L
> Cc: Fred Baker; IPv6 Operations
> 6to4 support has shipped with Windows, *BSD, MacOS, Linux for 
> several years now.   Even if IRON is the best thing since 
> sliced bread, I don't see how it can compete with that any 
> time soon.  It takes time for people to upgrade their OSes.

Sure, ISATAP is there in wide deployment too. But, in
the case of IRON it is not necessary that all nor even
most platforms support it. All it needs is for one or
a few platforms within an IRON End User Network (EUN)
to implement the IRON client function, and then all
other devices within the EUN get to use native IPv6!
(Or ISATAP if they have no other choice.)

So, that means that IRON would only have to touch one
or a couple of popular platforms in order to enable
widespread deployment. And, linux seems like a good
place to start...

Thanks - Fred

> I don't want to discourage a potentially good long-term 
> solution for using IPv6 in overlay networks...but 
> realistically I don't think IRON can replace 6to4 before 6to4 
> reaches its natural EOL, which I hope is within 2-4 years.
> 
> Keith
> 
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 12:46:55 -0500

> widespread deployment. And, linux seems like a good

that's great for corner cases, but it doesn't make for a general solution.  at least, not in the short term.

Keith

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 11:50:00 -0600

On 2/8/2011 11:17 AM, Keith Moore wrote:
>>> I'm not following your argument here.   Presumably if you get a
>>> AAAA, and you have v6 connectivity, you will connect
>>> successfully.   If you get an A and an AAAA, you will still
>>> connect successfully.   And if you get an A, you *might* connect
>>> successfully, if the LSN isn't overloaded, and if the NAT doesn't
>>> break something simply because it modified the packets in
>>> transit.   Where's the case where adding working v6 makes things
>>> worse?
>>>
>>

I think you missed my point.

1) There are isolations in the core network. Baking cakes hasn't fixed 
them yet.

2) There are DNS servers which nxdomain AAAA records (which means 
fallback to A isn't an option).

This has nothing to do with things in the middle that are intercepting 
and causing havoc (doesn't matter if the DNS is answered by a load 
balancer or an auth server, if it responds poorly to AAAA, it fails).

> Again, it's not reasonable to blame IPv6 or 6to4 because they happen
> to explore brokenness that already exists in the IPv4 network.  The
> blame lies squarely with the operators and equipment vendors.

The IPv6 network is broken until core networks fix pathing and peering 
issues. End of story. Until that occurs, putting average joe on IPv6 is 
asking them to have a horrible experience.

Jack

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 09:52:05 -0800

Keith,

> that's great for corner cases, but it doesn't make for a general solution.  at least, not in the short term.

Not at all. For the price of a small S/W engineering investment, an
IRON service provider can offer a downloadable module for an existing
Windows, *BSD, MacOS, etc. platform as part of the arrangement
with the customer. It is then just a point-and-click operation away,
and the customer's EUN is up and running.

Thanks - Fred

________________________________
From: Keith Moore [mailto:[email-masked]]
Sent: Tuesday, February 08, 2011 9:47 AM
To: Templin, Fred L
Cc: Fred Baker; IPv6 Operations
Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 12:53:56 -0500

> It seems to me that the premise behind this assertion is that you think that killing 6to4 will kill IPv6.   It makes sense that you want 6to4 for your particular application, but it doesn't make se…

I don't think it's being overdramatic.    The reason that I think that CGN is a threat to IPv6, and also the reason that I think 6to4 is fairly essential, is that people don't just need to access the Internet from one place.   They need to be able to get to it from anywhere, using what ever service is available where they happen to be.  So they really need a v6 access solution that works from anywhere and doesn't require much if any explicit configuration.

That solution doesn't inherently have to be 6to4, of course.  But other than native v6, 6to4 is by far the solution that is most widely deployed.  Any other solution could require several years to catch up.

So I think there's a huge benefit in leveraging the 6to4 support that already exists in most hosts.  But hey, native v6 is even better.

Keith

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 18:56:31 +0100

Hi Daniel,

> I don't really buy "need to".  There are lots of ways to better allocate existing IPv4 addresses that are probably applicable to most networks.  

E.g. 4rd (described in tools.ietf.org/id/draft-despres-softwire-4rd-00, intended to be deployed by 4 Japanese ISPs)

Regards,
RD

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 8 Feb 2011 18:56:27 +0100 (CET)

On Tue, 8 Feb 2011, Jack Bates wrote:

> 1) There are isolations in the core network. Baking cakes hasn't fixed them 
> yet.
>
>
> 2) There are DNS servers which nxdomain AAAA records (which means fallback to 
> A isn't an option).
>
> This has nothing to do with things in the middle that are intercepting and 
> causing havoc (doesn't matter if the DNS is answered by a load balancer or an 
> auth server, if it responds poorly to AAAA, it fails).

Fix the DNS servers.

> asking them to have a horrible experience.

Can you list pathing and peering issues.... If these problems did not 
fixed, then users will stop using that provider....

Best Regards,
 		Janos Mohacsi

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 12:03:50 -0600

> fixed, then users will stop using that provider....

Read NANOG archives. There's a long list. Just to hit a big one, No 
level3 customer can reach any HE customer (or google for that matter). I 
believe Cogent and HE are still divided. There are more, though I'm 
still waiting on NSP PE support for v6 from my other transits.

Jack

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 12:05:49 -0600

> Fix the DNS servers.

They are not my DNS servers to fix. In addition, customers often won't 
recognize the problem and just sit at home grumbling about how crappy 
our service is.

Jack

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 10:05:57 -0800

Time out.

There is an aspect of this discussion that is being
(I think unintentionally) glossed over, but that needs
a deeper analysis. That being, when is it beneficial
to tunnel vs. when to go native?

Tunneling is useful for much more than just incremental
deployment of IPv6 over IPv4 networks. Tunneling is
useful for mobility management, multihoming, traffic
engineering, security (e.g., VPNs), and more.

But that said, no one is saying nor should it be
advocated that there is no place for native IPv6.
To the contrary, there are many instances in which
native IPv6 makes far more sense than tunneled. For
instance, major Internet service presences like google,
yahoo, facebook, etc. (just to name a few) have no
reason to tunnel. They aren't going anywhere, their
services don't require strong encryption, and they're
big enough that they can get their (multiple?) ISPs to
advertise their PI IPv6 prefixes into the native IPv6
DFZ. Large enterprise networks fit the same description.

However, small- to medium-sized end user networks (EUNs)
may not be big enough to pump their PI prefixes into
their providers' routing systems, yet they may want to
multi-home, to move around, to perform both out-bound
and in-bound traffic engineering, to VPN into their home
offices, etc.

The small- to mid-sized EUNs are therefore the realm
where tunneling makes sense as a long-term solution.

Thanks - Fred

> On Behalf Of [email-masked]
> Sent: Tuesday, February 08, 2011 8:48 AM
> To: Cameron Byrne
> Cc: [email-masked]; IPv6 Operations; Keith Moore
> > > you think <World IPv6 Day> is seen as necessary?
> > >
> > >>> 6to4 is what is distracting us. having to fix 
> brokenness triggered
> > >>> by 6to4.
> > >
> > > Precisely.
> > >
> > > individual network operator, can do to fix it. In order 
> for 6to4 to 
> work
> > > reliably, *everyone* must play along. And that's simply 
> not going to 
> happen.
> > >
> > > 6to4 was a fun little toy for people who wanted to 
> experiment with 
> IPv6.
> > > internet connectivity. At this point in time, *real* IPv6 
> deployments 
> is
> > > necessary, and 6to4 is just getting in the way. It's time 
> to shelve 
> it.
> > >
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 13:09:49 -0500

On Feb 8, 2011, at 12:50 PM, Jack Bates wrote:

> 1) There are isolations in the core network. Baking cakes hasn't fixed them yet.

yeah, I get that.  those things need to be hunted down and fixed.

> 2) There are DNS servers which nxdomain AAAA records (which means fallback to A isn't an option).
> 
> This has nothing to do with things in the middle that are intercepting and causing havoc (doesn't matter if the DNS is answered by a load balancer or an auth server, if it responds poorly to AAAA, it fails).

ah, I'm conflating several things here, probably because I've been stuck before with an ISP that insists on intercepting traffic to port 43 regardless of its destination, and imposing its own DNS server. 

a) authoritative DNS servers that are broken.  any domain offering AAAA records should make sure that AAAA queries work.  I think they probably already do, for the most part.
b) caching DNS servers that are broken.  the operators of such servers need to test to make sure that AAAA queries work properly.  it's not that hard.
c) DNS interception proxies.  really, those should be removed.... but I assume the operators will refuse to remove them.  so they need to be fixed also.

> The IPv6 network is broken until core networks fix pathing and peering issues. End of story. Until that occurs, putting average joe on IPv6 is asking them to have a horrible experience.

So, in summary:

a) IPv4 is broken both because of address scarcity and because there's a large body of bad practice out there
b) because IPv4 is broken, 6to4 is broken
c) IPv6 is broken because it hasn't been well shaken down yet.

It does look like some sort of triage is in order.

Keith

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 12:11:27 -0600

> where tunneling makes sense as a long-term solution.

I completely agree. 6to4 isn't the appropriate tunnel mechanism for 
that, though. Nor is it good for an ISP to look at such tunnels as a 
permanent solution for generic users.

IRON has it's place, but I don't believe the ISP is it.

Jack

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 13:12:25 -0500

> and the customer's EUN is up and running.

The number of service providers that currently offer any kind of software support for other than windows and maybe mac is very small.
And yet, customers need to use platforms other than windows and maybe mac.
What makes you think that providers are going to suddenly start supporting software for lots of platforms?
What makes you think that their customers will be willing to trust them enough to install their software?

The reason we have protocol standards is so that we don't have to rely on "running the right software" as the basis for interoperability.

Keith

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 19:15:08 +0100

Le 8 févr. 2011 à 17:47, [email-masked] a écrit :

> should not get distracted with any hacks.

> Forget tunneling, put time in 
> native IPv6,

Well 6rd, although it is a "tunneling" mechanism, permits rapid deployment of native IPv6 addresses where, for some reason, natively routing IPv6 in access networks is difficult.
Where native routing of IPv6 is easy, it is a better solution than 6rd but, where it isn't easy, I would rather call 6rd a "solution" than a hack.
It has been working fine on a multi-million customer network, for several years now.

Regards,
RD

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 12:25:48 -0600

> It does look like some sort of triage is in order.

Exactly, and most of this is due to,

a) lack of market pressure (so things didn't move as early as they 
should have)

b) ideas such as happy eyeballs should have been developed 10+ years ago

c) Some implementations out right broke RFC standards

Because of this,

a) IPv4 will be broken much more than was necessary if market pressure 
had been 5+ years earlier

b) Many transition tools are almost useless at this point

c) The world is waiting on core networks to fix pathing issues (which 
they are rapidly doing due to market pressures). As soon as they do, the 
edge networks will light up like christmas trees (as many are just 
waiting on core networks). At which point content providers will happily 
turn on AAAA (as qos should be the same or better than IPv4 at that 
point). Those with broken implementations will just have to fix them.

Jack

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 13:26:03 -0500

On Feb 8, 2011, at 10:03 AM, Jack Bates wrote:

> Except that ARIN is proposing a /10 for this specific purpose (since it failed the IETF). It will be just as broken with 6to4; as 6to4 uses a hack to disable (RFC-1918 awareness) and using RFC-1918 for a CGN is even worse than breaking 6to4.

6to4 implementations will learn to recognize that /10 in addition to RFC 1918 prefixes.

> Failed protocol. Someone should have set a flag for an ISP to specify support or no support for 6to4, even a simple dns query would have done. Too late now, operators will just break it.

Ah yes, the "6to4 should have anticipated brain damage to be invented a decade in the future" argument.  Wrong.  It's incumbent on CGN to support everything people need out of IPv4, and that includes 6to4 or at least v6.

It was not at all unreasonable to expect IP service providers to support the IP protocol.  An fundamental characteristic of the IP protocol is that addresses are uniquely assigned to hosts.

> I realize their IPv6 trial doesn't help the thousands of clueless windows 7 users, which is why the easiest hack is for t-mobile to support 6to4 anycast + NAT66, but I doubt they have an implementation for that yet.
> 
> Now, here's the import part. Rolling out pure IPv6 to everyone will create it's own brokenness (6to4 policy is less used than pure IPv6 policy). It will happen soon, but we aren't quite to that point yet and there is a LOT of isolation issues.

So there might be cases where 6to4 works better than native v6 even when native v6 is provided.  Interesting.  I suppose someone will propose deprecating native v6 for that reason. 

Keith

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 12:28:41 -0600

On 2/8/2011 12:15 PM, Rémi Després wrote:
> Well 6rd, although it is a "tunneling" mechanism, permits rapid
> deployment of native IPv6 addresses where, for some reason, natively
> routing IPv6 in access networks is difficult. Where native routing of
> IPv6 is easy, it is a better solution than 6rd but, where it isn't
> easy, I would rather call 6rd a "solution" than a hack. It has been
> working fine on a multi-million customer network, for several years
> now.

6rd, like PPPoX has the benefit of being localized tunneling. As such, 
it falls into a different category than internetwork tunneling.

Jack

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 19:33:15 +0100

> Declaring 6to4 "historic" might just be the message to send to vendors.

IMHO:
- 6to4 disabled by default is a clear and *necessary* message.
- Declaring that 6to4 is "historic" is debatable, confusing, and *not necessary".

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 Feb 2011 10:33:27 -0800

> c) IPv6 is broken because it hasn't been well shaken down yet.

You forgot that 6to4 is broken and therefore slows down IPv6 content
deployment and drives up ISP helpdesk calls.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 12:34:45 -0600

On 2/8/2011 12:26 PM, Keith Moore wrote:
> It was not at all unreasonable to expect IP service providers to
> support the IP protocol.  An fundamental characteristic of the IP
> protocol is that addresses are uniquely assigned to hosts.
>

That ship sailed with the invention of NAT. LSN breaks many of the 
workaround designed for NAT. It will happily break 6to4 as well. While a 
very weird ALG could be built for 6to4, it would require NAT of the 6to4 
addressing.

Why won't IPv4 hang around forever on the public Internet? It's not cost 
effective to support it and LSN will be the final breakage of it.

on issues.
> So there might be cases where 6to4 works better than native v6 even
> when native v6 is provided.  Interesting.  I suppose someone will
> propose deprecating native v6 for that reason.

Only because 6to4 anycast isn't used if an A record exists. Once core 
routing is resolved, pure IPv6 will be the way to go (6rd for localized 
tunneling if necessary).

Jack

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 Feb 2011 10:35:17 -0800

> - 6to4 disabled by default is a clear and *necessary* message.

I agree with this.  Good work RD.

> - Declaring that 6to4 is "historic" is debatable, confusing, and *not necessary".

Either way.  I just don't want unknowing users being broke because
6to4 is on by default.

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 19:35:52 +0100

On Tue, Feb 08, 2011 at 04:36:04PM +0100, Tore Anderson wrote:
> At this point in time, *real* IPv6 deployments is

Cannot agree more.

And it would make our support folks job MUCH easier if there won't be
all that 6to4/Teredo/ISATAP/GreatIdeaOfTheDay in Windows boxes of end
users when having to troubleshoot "Internet problems" customers. We
don't only need to train them about Dual Stack operations (with all the
nitty gritty details where and how things can go wrong there), we'll
also need to educate them about all the problems introduced by those
"automatic transition technologies". Nightmare. :-(

Best regards,
Daniel (who had to explain someone who thought to "have IPv6" what 6to4
is just last week)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 13:37:19 -0500

> So I think there's a huge benefit in leveraging the 6to4 support that already exists in most hosts.  But hey, native v6 is even better.

Unfortunately I think the number of people for whom this matters is quite small, because it requires expertise to make it work.   Like it or not, the people we want to be using IPv6 are people like my mom and dad, not people like you and me.   Obviously you and I want to use it too, but we aren't the customer whose needs are blocking widespread deployment at the moment.

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 19:40:49 +0100

Le 8 févr. 2011 à 18:12, Templin, Fred L a écrit :
> ... IRON is not intended as only a transition
> mechanism. IRON is tunnels-done-right,

This seems to imply that 6rd tunnels wouldn't be done right.
For rapid deployment of native IPv6 addresses where access network aren't ready for IPv6 native routing, 6rd is AFAIK both done right AND sufficient.

Regards,
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 10:41:14 -0800

Hi Jack,

> IRON has it's place, but I don't believe the ISP is it.

The ISP provides an Internet connectivity service to
its customers. But, there is nothing an ISP can do to
stop its customers from also obtaining alernate Internet
connectivity services through other providers. Couple
that with the fact that multi-access end systems are
common today, and will only become moreso going into
the future.

For example, take a hypothetical cellular operator "FOO"
that provides a pay-as-you-go 3G/4G Internet connectivity
service to its customers but knows full well that the
customers will prefer to use WiFi whenever they are in
range of an open-access for-free WiFi network. There is
nothing the operator can do to stop that, but if they
were to offer an IRON service to the customer then the
ISP would still be involved even when the customer is
not using the 3G/4G link, and the customers would be
happy to have seamless multi-access capabilities.

So, the benevolent ISP would be doing both themselves
and their customers a favor by allowing open multi-
access but possibly taking a small fee for the service.
Sort of like how major banks allow their customers to
use their competitors' ATM machines, only in a way
that the customer doesn't get unduly over-charged.
And, what better way to inspire customer loyalty?

Fred

> From: Templin, Fred L 
> Sent: Tuesday, February 08, 2011 10:06 AM
> To: [email-masked]'; Cameron Byrne
> Subject: when to tunnel vs. when to go native (was: RE: 
> [v6ops] Fwd: New Version Notificationfor 
> draft-troan-v6ops-6to4-to-historic-00)
> 
> Time out.
>

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 19:50:49 +0100

On Tue, Feb 08, 2011 at 08:59:42AM -0500, Keith Moore wrote:
> Well, it seems to me that 6to4 is yet another thing that users want to do with CGN,

The amount of users who "want to do 6to4" you can search for with a
magnifier glass.

If anything, people want to "have IPv6". And 6to4 brokeness and thus
IPv6 brokeness will skyrocket as soon as fast growing residential ISP
will start to deploy LSN. Which WILL happen in my universe because
it's unavoidable.

What will be the rainbow IT press partyline: "disable IPv6, that fixes
it". Great.

Global anycast 6to4 is a problem, not a solution.

Best regards,
Daniel

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 11:01:40 -0800

Keith,
 
The parts of IRON that need to function according to
open specifications are already covered under the core
mechanisms known as VET and SEAL:

http://tools.ietf.org/html/draft-templin-intarea-vet
http://tools.ietf.org/html/draft-templin-intarea-seal

That said, the piece of IRON that need not be standardized
is the client-to-server tunnel setup negotiations. There
is no reason for that to be part of the standard.

Thanks - Fred

(RTF has made this difficult to annotate. Everyone else
uses plaintext. Can we switch back to plaintext, please?)

	From: Keith Moore [mailto:[email-masked]] 
	Sent: Tuesday, February 08, 2011 10:12 AM
	To: Templin, Fred L
	Cc: Fred Baker; IPv6 Operations
	Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-troan-v6ops-6to4-to-historic-00

		Keith,

	Keith

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 12:46:08 -0600

> common today, and will only become moreso going into

I don't disagree that it's a value added service. It's just that, 
though. Value added and for a subset of consumers.

For basic connectivity needs, IRON is not needed and would be problematic.

Jack

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 20:03:02 +0100

On Tue, Feb 08, 2011 at 07:40:49PM +0100, Rémi Després wrote:
> For rapid deployment of native IPv6 addresses where access network
> aren't ready for IPv6 native routing, 6rd is AFAIK both done right AND sufficient.

It's done as "right" as possible, indeed. Well, it could use some
keepalive check to the 6RD BR, but that's my only gripe about it at the
moment. :-)

Any tunneling mechanisms HAS to be symmetrically in the hands of the ISP
providing it in order to be supportable. 6RD is, anycast 6to4 isn't.
Story told.

Best regards,
Daniel

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 11:14:52 -0800

Hi Jack, 

> For basic connectivity needs, IRON is not needed and would be 

The ISP provides basic connectivity, yes. For an agreed
price matched against a service level agreement, yes.

But the ISPs cannot and should not dictate a sole
provider lock-in to their customers. IRON is therefore
*not* problematic, but rather a playing field leveler
that promotes a healthy customer/provider inter-dependence
instead of an unhealthy customer enslavement.

Thanks - Fred

PS Please stop cutting out the meat of my messages; its not
   nice. And if someone is cooking this list, shame on you
   and please cut that out, too.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 13:22:07 -0600

> instead of an unhealthy customer enslavement.

I agree. However, I'm only interested in an ISP deployment model, which 
is when to tunnel and when to go native. From an ISP perspective, Native 
is preferred and 6rd is second best. IRON isn't the appropriate solution 
to feed thousands/millions of home users their IPv6 access.

What they do after I provide them basic connectivity is up to them.

>     and please cut that out, too.

I always trim what I'm not referring to. Why duplicate what you have in 
another message if my response doesn't deal with it?

Jack

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 14:25:34 -0500

On Feb 8, 2011, at 1:33 PM, Cameron Byrne wrote:

>>> work is broken until core networks fix pathing and peering issues. End of story. Until that occurs, putting average joe on IPv6 is asking them to have a horrible experience.
>> 
>> So, in summary:
>> 

The IPv4 network is broken.  Calls to ISP helpdesks about 6to4 not working are a symptom of this brokenness.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 14:30:50 -0500

On Feb 8, 2011, at 1:37 PM, Ted Lemon wrote:

> Unfortunately I think the number of people for whom this matters is quite small, because it requires expertise to make it work.  

It requires ISPs to do their jobs.  It doesn't require expertise on the part of the end users.  

I have customers running applications that expect to be able to get to network nodes using IPv6.  Those customers are ordinary users, not experts.  

>  Like it or not, the people we want to be using IPv6 are people like my mom and dad, not people like you and me.   

Who is this "we" you're referring to?

The Internet is a tremendously diverse place.  I don't know that I believe in any notion of a typical user.  Even if there were one today, two years from now it would be different.

Keith

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 11:35:47 -0800

Hi Jack, 

> From: Jack Bates [mailto:[email-masked]] 
> Sent: Tuesday, February 08, 2011 11:22 AM
> To: Templin, Fred L
> Cc: IPv6 Operations; [email-masked]
> Subject: Re: [v6ops] when to tunnel vs. when to go native
> 
> 
> 

I have already laid out the requirements that IRON
satisfies and that others like 6rd do not begin to
address. There are other aspects that I haven't even
touched on, including tunnel path MTU assurance.
Therefore, I question and disagree with your statement
that 6rd is second-best.

IRON is also beneficial to the customers even if an ISP
network were to go to native IPv6; IRON tunnels over
native IPv6 networks just as readily as it tunnels over
native IPv4 networks.

A third alternative is that the ISP network could do
nothing at all and allow some 3rd party to stand up an
IRON service that reaches through to the ISP's customers.
In that case, the ISP incurs no costs whatsoever, but
surrenders a control point that it could otherwise
have exercised.

Thanks - Fred

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 8 Feb 2011 21:04:40 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel Jaeggli
Sent: Tuesday, February 08, 2011 1:36 AM

>> I already null route the anycast address because it cause a mess in 
>> my CGN/NAT tables ... since i use bogon space to  my users they think
>> 6to4 might work
[WEG] So I think that one of the things in Brian's draft (or it was recommended on list and not
integrated yet) is a recommendation to respond with unreachables to anything directed at the 6to4
Anycast block if you are blocking protocol 41 or otherwise doing something that would break 6to4, to
at least give things trying to use 6to4 a fighting chance of realizing that it's broken and
disabling it. Depending on your vendor and your config, you either will or will not respond with
unreachables when you null route. I agree that we shouldn't expect you to make it work through NAT +
bogons, but I think it's fair to expect that it doesn't fail silently, because then it contributes
to that brokenness that everyone is worried about when they enable IPv6. 

>> service.  
[WEG] Well, I distinctly remember threads on NANOG calling out more than one US mobile provider for
blocking protocol 41 last year, whether they were doing it accidentally or on purpose... 
Clearly an exception and not the rule, but I don't buy "no one is using/cares". The same (customers
don't care) could be said for IPv6 - as you said, customers care about Facebook, etc, not which
protocol they use to get to it. 
Native IPv6 will eliminate the need for 6to4, but unfortunately we're not there yet, and there are
too many cases where you can't control if your users turn on 6to4, either unconsciously because
their *existing* device enables it by default, or consciously in order to compensate for the fact
that real IPv6 isn't there yet. So right now, we need to make sure we contain the brokenness where
it's not possible to support it, and eliminate the brokenness where it's possible to do so with
relatively low effort, not simply ignore until Native IPv6 makes it go away. Deprecating or making
6to4 Historic might help in a tiny way with future devices (in the same way that draft-george might
help improve IPv6 support), but it mostly changes nothing about existing installed base, which is
coincidentally where the brokenness is most likely to exist.

Wes George

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 16:12:36 -0500

> to that brokenness that everyone is worried about when they enable IPv6. 

Blocking 41 breaks more than 6to4.    If an operator really needs to break 6to4, say because it is using CGN, I agree that returning ICMP unreachable is probably the right thing to do.   But the filter should look deeper into the packet than the protocol number so that it only filters 6to4-style tunneling and not configured tunnels.  And breaking 6to4 should be considered a nuclear option.    It's far better to fix it.

>  Deprecating or making

It's also a Bad Idea to change existing practice, even for newly shipped software/devices, without there being a suitable replacement.  Granted that several problems exist with 6to4, but at least they're identified, and they can be addresses via various means.  If you discard 6to4 in favor of some other transition mechanism, you get to discover a new set of problems with that mechanism and deal with those - putting operators and users even further behind the curve than they are now.

Keith

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 08 Feb 2011 16:25:26 -0500

Ole,

In general, I do not agree with the principle of deprecating 6to4 until
such time as the alternative is more widely deployed (I.e. native IPv6 or
other options which provide end customer access to IPv6).

I think in general, although there are many issues, it's still viable for
some form of IPv6 connectivity.

Comments have been made on the list that suggest that we should wait a bit
longer until we consider this action to move 6to4 to historic.  Data
points after World IPv6 Day may bring to light on how this performs.

My other concern is that even if this is done, by the time deployed
hardware/software (in homes now) actually get replace and/or updated to
remove 6to4 operation it will be a long way off.  I would rather spend the
time fixing and/or helping 6to4 to run it's course (since it already out
there) by making it work as best as possible while concentrating on
getting native IPv6 to homes.

Also as note, I agree with list comments that suggest we would more
appropriately be targeting RFC3068 versus RFC3056.

Regards,

Victor K

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Feb 2011 10:25:56 +1300

I hesitate to make this thread longer, especially since I'm deleting
most of it unread, but this one is nice and technical, so...

>>  - CPE and hosts vendors stop enabling 6to4 by default

Although my own draft isn't directed at vendors, I have added
this point.

>>  - no-one advertises 6to4 AAAA records in DNS

As others have said, there may be cases where an AAAA is OK, but my
draft will contain a strong warning about this.

>>  - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS

This belongs in the 3484bis discussion over in 6man.

>>  - people stop considering 6to4 as a valid transitioning mechanism;

I've always hated the word "transition" anyway - we had to use it
in RFC 3056 because we were in the ngTRANS working group. So I agree,
but I can't control what people consider...

>> there are too many choices already.
> 

Given the number of places where 1.1.1.0/24 is in active use, I think we
know the power of IETF documents to control reality :-(

    Brian

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 22:28:21 +0100

On Tue, Feb 08, 2011 at 04:12:36PM -0500, Keith Moore wrote:
> If an operator really needs to break 6to4, say because it is using CGN,
> I agree that returning ICMP unreachable is probably the right thing to do.

Wow, we finally agree on something. :-)

> But the filter should look deeper into the packet

Which is something that might have legal implications.

> than the protocol number so that it only filters 6to4-style tunneling
> and not configured tunnels.

The scenario which is our (residential ISPs forced to deploy some form
of LSN) focus would be packets sourced by customers egress towards 6to4
anycast relays. Those packets should be easily recognizable by checking
for destination IP 192.88.99.1. Any packet destined to that IP should
trigger an ICMP unreachable message back to the sender, no matter what
protocol is used (we want to avoid "alive" checks going false positive).

> And breaking 6to4 should be considered a nuclear option.

It breaks anyway. We just look for ways to break it more gracefully,
read: don't have blackholing but give the 6to4 endpoint a chance to
notice that 6to4 won't work.

> It's far better to fix it.

Too late. IPv4 depletion is right here. Not that I like it as an
engineer, but we have to face operational realities. Sticking the head
into the sand, ignoring the problems ahead, is exactly what has put us
into this position in the first place.

Best regards,
Daniel

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 16:28:54 -0500

On Feb 8, 2011, at 1:33 PM, Rémi Després wrote:

> IMHO:
> - 6to4 disabled by default is a clear and *necessary* message

I'm not at all convinced of its necessity.  I still think it's a dubious idea, because it will break compatibility with things that currently work.

Keith

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 22:32:01 +0100

> (a) technically wrong, because it reclassifies RFC 3056, and the one that

Agreed.

Best regards,
Daniel

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 16:35:07 -0500

On Feb 8, 2011, at 1:50 PM, Daniel Roesen wrote:

> If anything, people want to "have IPv6".

Most people don't understand their requirements in terms of "want to do 6to4" or "want IPv6".  They want their applications to work well.  They want to be able to talk to the hosts which they need to talk to, regardless of whether those hosts speak v4, v6, or both.  There's a huge variety of different specific wants and needs under that description, nearly all of which can be met by "please send my packets intact to the addresses I specify, and please deliver packets addressed to my hosts".  If you start trying to justify some users' needs as more important than others, you end up in a rat hole very quickly. 

> Global anycast 6to4 is a problem, not a solution.

That mentality is the problem.

I think the message needs to go out very clearly to users is this:

If your IPv6 access doesn't work, it's probably because your ISP (a) didn't plan ahead for v6 deployment and instead (b) imposed CGN on you.  You should find another ISP.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Feb 2011 10:40:57 +1300

> Incorrect on both counts.

Keith, I agree that this does not recreate the 6bone, although I do see
why Ole says that. But can you cite specific examples of managed non-unicast
deployment of 6to4?

>> 6to4 model 2, even with a consenting forward relay suffers the same issues on the reverse path.

Of course. That's one reason that I wrote my draft.

>> in my view 6to4 is not salvageable. 

But who's trying to salvage it? We have to *live* with anycast 6to4, probably for
some years to come. That's the main reason I wrote my draft - not to boost
anycast 6to4, but to make it tolerable.

> Perhaps that's because you haven't tried to identify solutions?  it is possible, for instance, to identify and marginalize broken relay routers.

To be honest, that's hard - unless you want to start a major project, with
probes installed all around the world, to detect, name and shame broken
relays. My hope is that we can publish advice that will cause ISPs to do
the right thing; that isn't a golden bullet, but at least it's a finite
job.

Also - don't lose my point that the problem here is RFC 3068 and if we're
going to deprecate anything, it should be that.

>> I think we can equate deprecating 6to4 to deprecating NAT-PT. it is harmful to IPv6 deployment.

There's a big difference - at the time NAT-PT was deprecated, it wasn't in any
signifcant use and could be considered a sleeping RFC with no operational
impact. RFC 3068 isn't sleeping and I don't see how something so widely
deployed can be deemed osbolete. Problematic, yes, but we don't have
a "Problematic" status

> 6to4 is not harmful to IPv6 deployment.  ISPs that break IPv4 are harmful to IPv6 deployment.

Oh, let's not have that argument.

>> I think the "problem" 6to4 solves is miniscule. it provides a mechanism for us techies to play with IPv6.

That's not quite what I meant. To be constructive, we need to advise operators
to deal with reality: there's a lot of RFC 3068 out there.

>> the solution is that the end user's service provider enables IPv6. 

100% agree, of course, but that is another topic entirely.

> Internet wide tunneling technologies specifically designed to bypass the underlaying infrastructure are hard to make work. I can't think of a single example where we have technology that makes that work well, supporting all the requirements that Fred listed.

True. 6to4 has always been described as an interim solution.

>> 6to4 is what is distracting us. having to fix brokenness triggered by 6to4.

Operators have to do that anyway. Passing a law against 6to4 won't change
that; giving advice to operators may help them.

That's why I plan to focus on my draft instead of Ole's...

EOT

    Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 17:27:29 -0500

> Although my own draft isn't directed at vendors, I have added

I think it's premature to stop enabling 6to4 by default.  

The appropriate date to start disabling 6to4 by default is approximately the date at which operators' groups commit to lighting up native v6 and providing it to their customers over the same interfaces/links over which they currently provide v4.

If operators' groups would commit on behalf of their members to a date for doing that, I would support publishing that date in an RFC and recommending that implementations shipped after that date disable 6to4 by default.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 17:36:49 -0500

> Which is something that might have legal implications.

Fine.  Don't look deeper into the packet.  Instead, route the packet to a 6to4 "relay router" that forwards the traffic to a v6 "router" that drops all packets, issues returns ICMPv6 responses for them, and routes those ICMPv6 responses back through an opposite direction "relay router" to the appropriate IPv4 source address.    That will suffice.

(Of course nothing says that both "relay routers" and the v6 "router" can't all be in the same box.)

> protocol is used (we want to avoid "alive" checks going false positive).

I haven't tried it, but I suspect that doing an ICMPv6 response encapsulated in a v4 packet, will work better than an ICMP response for the original outer v4 packet.

> into this position in the first place.

(I have to wonder if widespread adoption of CGN isn't yet another product of "head in the sand" thinking.)

Is your plan to deny EVERYBODY a properly working IPv4 address, or will you make special cases for those whose apps break in the presence of CGN?

Keith

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 16:45:32 -0600

Sorry for adding you back on Brian. :)

On 2/8/2011 4:36 PM, Keith Moore wrote:
> I haven't tried it, but I suspect that doing an ICMPv6 response
> encapsulated in a v4 packet, will work better than an ICMP response
> for the original outer v4 packet.

Actually, it depends on the implementation. ICMP to the outer v4 packet 
can possibly disable 6to4 all together. ICMPv6 to the 6to4 node will 
stop that one connection.

Ideally, you would do both, but that would be a custom implementation. 
I'm not completely sure it doesn't belong in Brian's draft as a 
suggestion (support for LSN systems to send both ICMP unreachable to v4 
hosts using protocol 41 and ICMPv6 unreachable messages sent to the 
internal IPv6 hosts in protocol 41 packets).

However, that is a vendor suggestion, not an operator one, and it's 
unclear which mechanism would be most effective in todays environment 
(since the dual method isn't implemented yet).

Jack

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 17:50:34 -0500

On Feb 8, 2011, at 5:45 PM, Jack Bates wrote:

> Actually, it depends on the implementation. ICMP to the outer v4 packet can possibly disable 6to4 all together. ICMPv6 to the 6to4 node will stop that one connection.

disabling all 6to4 is clearly broken.  at most you want to disable 6to4 that goes through your particular router.

what I'm thinking is that ICMPv6 is more likely to get delivered to the application and thus permit some sort of error message to get sent to the user, logged, or whatever.

Keith

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 16:54:10 -0600

On 2/8/2011 4:50 PM, Keith Moore wrote:
> disabling all 6to4 is clearly broken.  at most you want to disable
> 6to4 that goes through your particular router.
>
> what I'm thinking is that ICMPv6 is more likely to get delivered to
> the application and thus permit some sort of error message to get
> sent to the user, logged, or whatever.

Yes, ICMPv6 is probably more likely to do that, though some 6to4 
implementations will still do that (router to node behind it) and at the 
same time recognize that the 6to4 address isn't valid. If that happens 
to be the anycast address, it stops the cpe from continually trying to 
reach a 6to4 anycast.

It's very implementation specific. Doing both at the same time would be 
cooler.

Jack

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 17:55:47 -0500

On Feb 8, 2011, at 5:54 PM, Jack Bates wrote:

> Yes, ICMPv6 is probably more likely to do that, though some 6to4 implementations will still do that (router to node behind it) and at the same time recognize that the 6to4 address isn't valid. If that happens to be the anycast address, it stops the cpe from continually trying to reach a 6to4 anycast.
> 
> It's very implementation specific. Doing both at the same time would be cooler.

strongly disagree, for a number of reasons.  e.g. just because your network is broken w.r.t. 6to4 doesn't mean that the host doesn't have other connections available.

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 23:57:06 +0100

On Tue, Feb 08, 2011 at 05:27:29PM -0500, Keith Moore wrote:
> The appropriate date to start disabling 6to4 by default is
> approximately the date at which operators' groups commit to lighting
> up native v6 and providing it to their customers over the same
> interfaces/links over which they currently provide v4.

You will see exactly that happing within the next two years en masse,
at least on the customer demarc (CPE LAN interface). Wether the WAN side
will be native or tunnelled (6RD) will vary but from the user's
perspective (and that's ~all that counts) it's dual-stack service
being delivered.

I took the industry actually facing IPv4 depletion to get moving.

> If operators' groups would commit on behalf of their members to a
> date for doing that, I would support publishing that date in an RFC and
> recommending that implementations shipped after that date disable 6to4
> by default.

Too late. You have a largish delay between "asking from something" and
"getting it out of the door in mass". This is why we operators ask to
advocate deprecating 6to4 _now_ so that it will hopefully have gained
some traction when LSNs will get deployed at large - which I expect to
happen in EU in the later 2011 and certainly in 2012.

Best regards,
Daniel

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 16:59:16 -0600

On 2/8/2011 4:55 PM, Keith Moore wrote:
>>> disabling all 6to4 is clearly broken.  at most you want to
>>> disable 6to4 that goes through your particular router.
>>>
>>> what I'm thinking is that ICMPv6 is more likely to get delivered
>>> to the application and thus permit some sort of error message to
>>> get sent to the user, logged, or whatever.
>>
>> implementations will still do that (router to node behind it) and
>> at the same time recognize that the 6to4 address isn't valid. If
>> that happens to be the anycast address, it stops the cpe from
>> continually trying to reach a 6to4 anycast.
>>
> strongly disagree, for a number of reasons.  e.g. just because your
> network is broken w.r.t. 6to4 doesn't mean that the host doesn't have
> other connections available.
>

Ummm, if the host has other connections available, it shouldn't be 
sending to my anycast address.

Also, sending an ICMPv6 to the application isn't going to use another 
host either. Your argument doesn't make sense.

I didn't say it disables the gateway. I said it could keep it from 
constantly trying a futile act. I suspect that if it connects to another 
IPv4 address or is configured differently, it can send just fine to 
someone else's anycast.

Jack

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 8 Feb 2011 23:06:33 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Tuesday, February 08, 2011 4:35 PM

>If your IPv6 access doesn't work, it's probably because your ISP (a) didn't plan ahead for v6
deployment and instead (b) imposed CGN >on you.  You should find another ISP.

[WEG] This is a really serious oversimplification of the situation, and IMO is harmful to the
overall discussion, because it makes us look like we're more concerned with ideology than with
practical and operational realities. 
Fact - Most users don't have enough IPv6 capable devices to move to using primarily IPv6 (let alone
IPv6-only) anytime soon
Fact - Most content isn't available on IPv6 (World IPv6 day will be interesting, but it doesn't
solve the problem by a long shot)
Fact - IPv4 is exhausted.
Fact - Customers *will* find another ISP if their existing services quit working
Defensible Theory - Customers are very likely to find a new ISP if their current one tells them that
they have to replace all of the devices in their home/business that aren't IPv6-capable in order to
keep their service working
	Example: Gaming box, Internet-capable A/V receiver or TV, etc.
Corollary - CGN for IPv4 is virtually a requirement to make existing services keep working, assuming
any growth at all.
So, stop vilifying people who respond to that business reality. We're no happier about it than you
are, and we *are* deploying IPv6, but we like to make sure our paychecks don't bounce.

That said... ISPs *are* behind on IPv6 deployment. 
However, many ISPs don't control the end user's gear, and even if they were able to magically roll
out network-wide support today, and assuming that the content problem is magically solved, a large
majority of their customers wouldn't be able to take advantage of it either because of their CPE
router or because the gear behind that router doesn't speak IPv6. There are many reasons that IPv6
isn't where we'd all like it to be, but pointing blame solely on the big, bad ISPs who are
implementing CGN so that they don't have to do IPv6 is to miss a lot of the overall story.

Wes George

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 00:14:51 +0100

On Tue, Feb 08, 2011 at 05:36:49PM -0500, Keith Moore wrote:
> Fine.  Don't look deeper into the packet.  Instead, route the packet
> to a 6to4 "relay router" that forwards the traffic to a v6 "router"
> that drops all packets, issues returns ICMPv6 responses for them,
> and routes those ICMPv6 responses back through an opposite direction
> "relay router" to the appropriate IPv4 source address.

Not really possible in some LSN scenarios, as there is no router between
the CPE and the LSN. E.g. DS-Lite. One would have to request that
special handling of 6to4 packets from the LSN implementation. How
feasibly that is depends on the implementation's architecture.

> can't all be in the same box.)

Yup.

> product of "head in the sand" thinking.)

Of course. Widespread adoption of LSN is a sign of failure of the whole
Internet industry. Pretending it won't happen doesn't get us anywhere.

We've already jumped out of the airplane. Time to find some emergency
chutes to reduce impact velocity as far as possible.

> Is your plan to deny EVERYBODY a properly working IPv4 address, or
> will you make special cases for those whose apps break in the presence
> of CGN?

Do you really think that I'm entitled to disclose strategy details in
the context of seriously disruptive changes in the residential ISP
world? C'mon. :-)

But as we all know, IPv6 is _the_ solution to any IPv4 breakage, so that
will quickly become a non-issue anyway! :-P

Best regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 00:23:28 +0100

> practical and operational realities. 

Indeed. And those kind of comments are exactly why "us operators" shy
away from taking part in IETF WGs. Brian Carpenters FYI postings on
ipv6-ops (an operator's mailing list) motivated me to invest time (my
free time, not paid time) to contribute to frequently requested
"operator's point of view".

And frankly I have to admit that I considered to pull out of IETF
discussions again today after seeing how this thread evolves, with
so much outright denial of realities and subsequent time+energy
wasted on that instead of focussing about how to properly deal with the
realities (which is to - my understanding - v6ops' goal).

Best regards,
Daniel

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Feb 2011 15:26:05 -0800

On Feb 8, 2011, at 3:23 PM, Daniel Roesen wrote:

> And frankly I have to admit that I considered to pull out of IETF discussions again today after seeing how this thread evolves, with so much outright denial of realities and subsequent time+energy wasted on that instead of focussing about how to properly deal with the realities (which is to - my understanding - v6ops' goal).

Please don't confuse "Keith Moore" with "The IETF".

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 18:34:11 -0500

> practical and operational realities. 

I certainly get that impression from many of the participants here.  There's definitely an ideology that use of 6to4 is somehow not legitimate and that it's therefore acceptable to sabotage it rather than to try to fix it.

(and I do realize that you can't really fix 6to4 over a link that is CGN impaired, precisely because there is no explicit link setup for 6to4, unlike say PPPoE.)

> Fact - Most users don't have enough IPv6 capable devices to move to using primarily IPv6 (let alone

Really?   All of the major OS vendors have been shipping IPv6 support for several years now.  Sure, there are still a few people running Win 2k, me, 98, or even 95, but not many.

> solve the problem by a long shot)

The idea that the internet's only purpose is for users to get "content" has always struck me as bizarre.   

> keep their service working

yeah, that much sounds right.

> Corollary - CGN for IPv4 is virtually a requirement to make existing services keep working, assuming

CGN is also going to make existing services break, likely causing users to switch ISPs.

> are, and we *are* deploying IPv6, but we like to make sure our paychecks don't bounce.

The damage has already been done by not ramping up MUCH sooner on native v6.  Many ISPs are now in a position that they cannot help but break things for their customers in a number of different ways, regardless of whether the customer is using 6to4 or not.  If customers interpret that breakage as a sign that their ISP isn't doing its job, and switches ISPs until things start working well again, they won't be far wrong. 

If ISPs are paranoid about this, well, I guess I'm not surprised.

My purpose here is not to bash network operators.  Nor do I really want to encourage users to riot.    

But when operators start blaming 6to4 on problems that were actually caused by operators, it's hard to see how they can find suitable solutions.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 18:45:57 -0500

> I took the industry actually facing IPv4 depletion to get moving.

I'm happy to hear that, though I'll be happier if the industry can put a stake in the ground and commit to a date.

> happen in EU in the later 2011 and certainly in 2012.

Well, sure.  We ask _now_ for 6to4 to be disabled by default starting _at a particular date_.  That way, vendors get plenty of lead time.   

But part of the message needs to be that the industry commits to delivering native v6 by that date.  That informs users of the timeframe and migration path.  It also tells content providers when they can stop trying to work around 6to4-related issues.  

Keith

---

From: james woodyatt <[email-masked]>
Date: Tue, 08 Feb 2011 15:53:03 -0800

On Feb 8, 2011, at 14:57, Daniel Roesen wrote:

> This is why we operators ask to advocate deprecating 6to4 _now_ so that it will hopefully have gained some traction when LSNs will get deployed at large - which I expect to happen in EU in the later 2011 and certainly in 2012.

Speaking as an individual with experience in the residential gateway equipment maker community, let me address the operational community as a whole on this topic...

p1. Moving RFC 3056 to Historic status won't fix any broken 6to4 anycast relays.

p2. Moving RFC 3056 to Historic status won't force residential gateway equipment makers to do any of the following in their future products:

  + Remove the 6to4 tunneled routing feature.

  + Make the 6to4 tunneled routing feature an opt-in configuration.

  + Make the 6to4 tunneled routing feature continually probe the anycast relay to make sure it's functioning properly before forwarding packets to it.  (Many relays silently drop such probes while otherwise functioning properly.)

  + Make the 6to4 tunneled routing feature respond to receipt of an ICMPv6 error packet by shutting down all forwarding to the 6to4 relay.  (Sounds like a denial of service attack opportunity to me.)

  + Update the firmware in already deployed products in the field to do any of the above.

p3. Moving RFC 3056 to Historic status won't force residential gateway equipment makers to stop selling gear that can tunnel 6to4 to anycast relay routers.

I appreciate that residential gateways with 6to4 tunneled routing features pose transition problems for service providers and other members of the operational community, but my advice is to stop considering them to be a "problem" and start treating them like a Terrain Feature.

They're not going away.  Equipment makers aren't even going to stop selling new ones.

A significant fraction of customers are like Mr. Keith Moore here on the V6OPS list, and they like the 6to4 routing feature, because it lets them get better-than-nothing IPv6 service in the face of incumbent oligopolist service providers that can't or won't offer them native IPv6 service.

Any hope you might have that turning RFC 3056 to Historic status will change the basic terrain in which you're operating is badly misplaced.

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

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 00:56:15 +0100

> CGN is also going to make existing services break, likely causing

Those will have a hard time finding an alternate ISP _not_ using LSN in
the near future.

Differentiation will not be "is or is not doing LSN", but the exact way
of doing LSN and making it as painless as possible. Finding a workaround
to the 6to4 problems arising of LSNs (in addition to the "natural"
problems of anycast 6to4) is part of that equation. And part of why I'm
here in the first place. To work on aggregated "wisdom" on how to tackle
the dirty details which we can then take as internal and external (to
vendors) reference.

Best regards,
Daniel

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 19:06:30 -0500

On Feb 8, 2011, at 6:23 PM, Daniel Roesen wrote:

> away from taking part in IETF WGs.

Look, I didn't jump into this discussion with the purpose of pointing fingers at operators.    

But when people here start blaming 6to4 for problems that are caused by various kinds of brain-damage inside the network, and trying to kill 6to4 for that reason and before there's a suitable replacement, I think it's fair to point out that the actual culpability lies elsewhere.  Not because I want to have a big argument about it, but because I don't see how any problem can be solved by people who insist on blaming the symptom.

Meanwhile, I've also been trying to contribute to discussions about how to (a) gracefully phase out 6to4 in favor of native v6, and (b) allow 6to4 to continue working until that happens.    I think it's much more appropriate to devote attention to those topics than to "who is to blame".  But it's hard to do that while people are still trying to kill 6to4 prematurely.

> realities (which is to - my understanding - v6ops' goal).

Properly dealing with the realities is my concern also.  (and I'm not getting paid for my contribution to this discussion, either).

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Feb 2011 19:07:03 -0500

Fred, I'll ask that you please refrain from ad hominem attacks.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 9 Feb 2011 01:08:13 +0100

Sometimes we, or others, publish documents that cause action to occur. Other times the documents are simply ignored. Predicting which is which at time of publication is often difficult. 

I know of at least a few manufacturers who incorporated 6to4 into their products due to a very specific "logo" requirement that recommended it. It wasn't directly due to an IETF document in this case, but certainly the requirement pointed to an IETF document.

It's not precisely the same thing,  but I've seen on numerous product documents, presentations, etc. that "NAT-PT" was bad because the "IETF deprecated it", even if the IETF turned around and chartered work to solve the same problem in Behave just after (even if the vast majority of the reasons identified in the deprecation of NAT-PT are also applicable to the Behave work) . Sometimes you just don't know what the world is going to latch onto. 

I think it's time to move on from 6to4. Sure, moving it to Historic won't necessarily have an affect, but it might. At least the logo programs out there that point to 6to4 might be triggered to update a pointer and in the process consider whether or not to remove the requirement altogether. 

- Mark

On Feb 9, 2011, at 12:53 AM, james woody

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Feb 2011 13:42:34 +1300

Mark,

> I think it's time to move on from 6to4. Sure, moving it to Historic won't necessarily have an affect, but it might. At least the logo programs out there that point to 6to4 might be triggered to upd…

Are you saying that there are *requirements* lists including RFC 3068?

I just checked the old and new IETF node requirements and neither of them
mention it (nor RFC 3056).

I don't have current NIST or DoD profiles to hand, but I can find no trace
of 6to4 in the old versions that I do have (and the DoD says that Teredo
"is strongly discouraged, and will be prohibited in some DoD networks").

So which profiles require 6to4?

     Brian

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 08 Feb 2011 19:34:09 -0800

> "operator's point of view".

Two of three working group chairs are network operators, the third is I
think fairly sensitive to the needs of his customers. Inclusive of the
participants, v6ops actually has fairly rich operational representation,
which is worth remembering. Not all operators speak with one voice
however. The important part is not to foster an us vs them mentality
Whomever them is, there is only us.

> realities (which is to - my understanding - v6ops' goal).

The reality is that disputes occur, cooling off some points of
contention is required before they can be touched again, and ultimately
as individual contributors we have to do what's right in our opinion or
for our organizations. We're more effective if we produce consensus, but
not all outcomes produce or require that.

joel

---

From: Rémi Després <[email-masked]>
Date: Wed, 9 Feb 2011 09:33:11 +0100

Le 8 févr. 2011 à 23:57, Daniel Roesen a écrit :
> ... hy we operators ask to

Do you make a difference between
(a) 6to4 "disabled by default" (a behavior to be recommended from now on)
(b) 6to4 "deprecated" (banned use of 6to4, even if consciously enabled where it is found useful)

In my understanding, (a) is sufficient.
Insisting for (b) wouldn't be useful..

Regards,
RD

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Feb 2011 09:49:56 +0100 (CET)

On Tue, 8 Feb 2011, Jack Bates wrote:

> recognize the problem and just sit at home grumbling about how crappy our 
> service is.

Yes the DNS server is not yours, but you have knowledgable technician 
at the helpdesk who can reproduce the problem and report to the operator 
of the remote DNS server.
We need:
- Educated helpdesk people
- coopaeration to resolve th problem

There was an initiative (v6fix) few years ago to resolve IPv6 deployment 
problems: http://v6fix.net/index.html
See the publications:
http://v6fix.net/bib.html.en

We need urgently extend this work....

Best Regards,
 		Janos Mohacsi

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Feb 2011 09:52:24 +0100 (CET)

On Tue, 8 Feb 2011, Jack Bates wrote:

> Read NANOG archives. There's a long list. Just to hit a big one, No level3 
> customer can reach any HE customer (or google for that matter). I believe 
> Cogent and HE are still divided. There are more, though I'm still waiting on 
> NSP PE support for v6 from my other transits.

Shame on these providers if they don't treat IPv6 as important as IPv4. We 
reached a point where IPv6 unavoidable. If some provider supports IPv6 
poorly, their users will complain and probably change to another one.

Best Regards,
 		Janos Mohacsi

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 10:25:19 +0100

Hi,

> In my understanding, (a) is sufficient.

Correct, and that's what I'm looking for.

Agreed.

Best regards,
Daniel

---

From: Rémi Després <[email-masked]>
Date: Wed, 9 Feb 2011 10:57:28 +0100

Le 9 févr. 2011 à 00:34, Keith Moore a écrit :

> ...  There's definitely an ideology that use of 6to4 is somehow not legitimate and that it's therefore acceptable to sabotage it rather than to try to fix it.

Would you accept a recommendation that, from now on, 6to4 should be disabled by default.

Thus:  
- Users who know what they do, and keep or turn 6to4 on, won't feel criticized by IETF
- The message being clear enough, completely deprecating 6to4 would become an unnecessary overreaction.

This, I hope, could contribute to bring this discussion to an end.

Regards,
RD

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 11:06:20 +0100

On Wed, Feb 09, 2011 at 09:52:24AM +0100, Mohacsi Janos wrote:
>> Cogent and HE are still divided. There are more, though I'm still waiting 
>> on NSP PE support for v6 from my other transits.
>
> Shame on these providers if they don't treat IPv6 as important as IPv4.

They do, this is why those effects show up.

<observations without insider knowledge about those matters>
HE is on a crusade trying to become "tier 1" in IPv6 world (guess why
they offer free transit to everyone not quick enough to escape - there
ain't such a thing as a free lunch). Level 3 is "tier 1" in IPv4 world
and has any intention to maintain that status in IPv6 too, so their
peering policies apply to IPv6 just as they do for IPv4. Cogent - is
Cogent. They of cause try to maintain their wannabe-"tier 1" status in
IPv6 too, so have their interesting disputes with real "tier 1"s every
now and then, just like in IPv4. My guess is that L3 doesn't want to
have SFI peering with Cogent but Cogent trying to knee-jerk attain that
by refusing to buy transit somewhere.
</observations>

All those battling for maintaining or achieving "tier 1" status in IPv6
world will not take a full feed from anyone else so things remain
partioned until IPv6 peering landscape has converged to the IPv4
picture.

What is being described above IS actually happening BECAUSE those ISPs
take IPv6 as serious as IPv4.

Best regards,
Daniel

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Feb 2011 13:17:31 +0200 (EET)

On Tue, 8 Feb 2011, Daniel Roesen wrote:
> And 6to4 brokeness and thus IPv6 brokeness will skyrocket as soon as 
> fast growing residential ISP will start to deploy LSN.

That will certainly happen if the ISP is natting between two public 
address spaces.  But I don't think LSN would do that by definition?

If the ISP switches the user to use a private IP space, 6to4 usage 
will just stop but it won't break.  Let's keep these two cases clearly 
distinct.

Otherwise, let's drop this "IPv6 breaks when residential ISP deploys 
LSN".

Am I missing something?

-- 
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: Mohsen Souissi <[email-masked]>
Date: Wed, 9 Feb 2011 12:28:25 +0100

I agree with Rémi's comments below.

Let's get rid of 6to4 in order to get a cleaner IPv6 deployment, even
taking the risk of breaking some (poorly) working connections.

Regards,

Mohsen.

 On 08 Feb, Rémi Després wrote:
 | Brian,
 | 
 | I find Ole's proposal interesting *for the new phase we are entering*, i.e. one where:
 | - native IPv6 adresses are progressively deployed
 | - 6to4, that has been extensively use despite its limitations, should now recede
 |  
 | 
 | Le 8 févr. 2011 à 10:14, Ole Troan a écrit :
 | > ... 6to4 does not in any way accelerate IPv6 deployment.
 | > 
 | > if the draft can achieve that:
 | > - CPE and hosts vendors stop enabling 6to4 by default
 | 
 | +1 
 | 
 | > - no-one advertises 6to4 AAAA records in DNS
 | 
 | Except maybe where 6to4 is the only available incoming connectivity, but that's minor.
 | 
 | > - 6to4 is put at the absolute bottom (with Teredo) in the SAS/DAS algorithms.
 | 
 | Ideally, RFC 3484bis would do it.
 | 
 | > - people stop considering 6to4 as a valid transitioning mechanism; there are too many choices already.
 | 
 | At least not a mechanism to be considered for new deployments.
 | 
 | Regards,
 | RD

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 09 Feb 2011 08:07:45 -0500

Pekka,

> address spaces.  But I don't think LSN would do that by definition?

I don't there there is a "default" position among how various operators will
implement CGN/LSN.  Most seem to have their own strategies (which many don't
talk about).

> will just stop but it won't break.  Let's keep these two cases clearly

I don't think private address space is viable for all operators.  Many have
already used up this address space and others seem to have challenges using
is for other reasons (i.e. Home network overlap etc)
> Otherwise, let's drop this "IPv6 breaks when residential ISP deploys

I do see a need to discuss and understand how the community will deal with
6to4 brokenness related to LSN (since this is likely to proliferate soon and
after IPv4 exhaustion in operator networks).

Victor K

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Feb 2011 15:13:45 +0200 (EET)

> after IPv4 exhaustion in operator networks).

In order to conduct technical discussion, we will need to know how LSN 
is implemented.

Some facts that I've gleaned:

- TMO's approach of hijacking public address space for inner addresses
   indeed "breaks" 6to4.

- When LSN is deployed with private inner addresses, 6to4 does not
   break.

Is the rest just speculation?

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 08:32:15 -0500

> Would you accept a recommendation that, from now on, 6to4 should be disabled by default.

no.  I think this is very premature.

What I do accept is that if an ISP imposes NAT on its customers, there should be some well-defined mechanism to signal that to hosts using 6to4, so that those hosts can (a) stop trying to use 6to4 on that link, and (b) provide a useful error message to their users.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 08:39:39 -0500

On Feb 9, 2011, at 6:17 AM, Pekka Savola wrote:

>> And 6to4 brokeness and thus IPv6 brokeness will skyrocket as soon as fast growing residential ISP will start to deploy LSN.
> 
> That will certainly happen if the ISP is natting between two public address spaces.  But I don't think LSN would do that by definition?
> 
> If the ISP switches the user to use a private IP space, 6to4 usage will just stop but it won't break.  Let's keep these two cases clearly distinct.
> 
> Otherwise, let's drop this "IPv6 breaks when residential ISP deploys LSN".
> 
> Am I missing something?

It seems to me that if an ISP starts giving RFC 1918 addresses to its customers, that's going to cause breakage too.  It's going to break different things than if it had assigned those customers addresses belonging to someone else.  I'm not entirely sure which is worse, but intuitively the former seems worse to me.

And while I agree that the two cases are distinct, using any kind of NAT breaks 6to4.  And if that's the only means of v6 access available to the customer, the effect of LSN _is_ to break IPv6.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 08:42:15 -0500

> - When LSN is deployed with private inner addresses, 6to4 does not

Incorrect.  6to4 is disabled in this circumstance.  Arguably it's cleaner than having it "break" by being assigned IPv4 addresses that aren't reachable from elsewhere, but the ability to use IPv6 is lost in either case.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Feb 2011 15:51:28 +0200 (EET)

> to use IPv6 is lost in either case.

Let's stop using the word "break" then.  It doesn't appear to be 
useful in technical discussion.  One could for example say that 6to4 
is either "blackholed" or "turned off".

I agree it's unfortunate that 6to4 would get turned off, but 6to4 
implementations will get disabled with private IPv4 addresses. This is 
MUCH better than IPv6 blackholing when 6to4 is enabled on end-systems 
but blocked in the network.  Systems that end up behind LSN and 
private addresses also have the option of starting to use Teredo or 
another transition mechanism that can punch through LSN.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Feb 2011 05:56:39 -0800

Hi Pekka, 

> On Behalf Of Pekka Savola
> Sent: Wednesday, February 09, 2011 5:51 AM
> To: Keith Moore
> Subject: Re: [v6ops] LSN breaking 6to4
> 
> > Incorrect.  6to4 is disabled in this circumstance.  
> Arguably it's cleaner than having it "break" by being 
> assigned IPv4 addresses that aren't reachable from elsewhere, 
> but the ability
> > to use IPv6 is lost in either case.
> 

IRON qualifies as "another mechanism that can punch through
LSN", but it is more than just a transition tool:

IRON enables entire IPv6 networks behind LSNs, and not just
individual hosts.

Thanks - Fred

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Wed, 9 Feb 2011 14:00:10 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Wednesday, February 09, 2011 8:42 AM

>Incorrect.  6to4 is disabled in this circumstance.  Arguably it's cleaner than having it "break" by
being assigned IPv4 addresses that >aren't reachable from elsewhere, but the ability to use IPv6 is
lost in either case.

[WEG] as much as I’d love for some majority (or even a non-trivial minority) of my customers to
notice that 6to4 is broken or has disabled itself due to being behind a CGN/NAT444 instance (because
it would mean that I have the same non-trivial minority *using* IPv6), I’m pretty sure that’s going
to be the least of my problems.
As much as I want to see us not break or otherwise prevent 6to4 from being used, I do not believe
that the fact that 6to4 breaks will be a reason for any carrier to deviate from deploying CGN if it
is necessary for the continued function of the rest of the IPv4 applications that their customers
need to use day to day. 
Much has already been said about the fact that CGN is not a great solution, there are even drafts
(donley) that cover some testing that's been done regarding just how bad it might be. We already
have a draft focused on ways to make 6to4 suck less. Perhaps instead of rehashing the “CGN’s are
bad, m’kay?” argument for the umpteenth time, we could acknowledge, move on, and focus on improving
said draft to limit the collateral damage?

Wes George

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 09:03:10 -0500

On Feb 9, 2011, at 8:51 AM, Pekka Savola wrote:

> Let's stop using the word "break" then.  It doesn't appear to be useful in technical discussion.  One could for example say that 6to4 is either "blackholed" or "turned off".
> 
> I agree it's unfortunate that 6to4 would get turned off, but 6to4 implementations will get disabled with private IPv4 addresses. This is MUCH better than IPv6 blackholing when 6to4 is enabled on end-systems but blocked in the network.

It's better if the only thing that you're considering is the effect of this decision (private vs. non-routable public addresses) on 6to4.  It's not clear that it's better overall.

>  Systems that end up behind LSN and private addresses also have the option of starting to use Teredo or another transition mechanism that can punch through LSN.

None of these systems are as widely deployed, or as easily available, as 6to4.

Keith

---

From: Rémi Després <[email-masked]>
Date: Wed, 9 Feb 2011 15:08:03 +0100

> What I do accept is that if an ISP imposes NAT on its customers, there should be some well-defined mechanism to signal that to hosts using 6to4, so that those hosts can (a) stop trying to use 6to4…

You propose deployment of a new mechanism whose only purpose is to mitigate problems that ordinary users who have 6to4 disabled don't experience.
This doesn't seem realistic to me.

And you ask not only to be free to enable 6to4 for your applications, but you also insist that some other users, who don't care about these applications, have to endure some broken connectivities.

I can't agree with this approach.
Sorry.
RD

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 09:11:52 -0500

> is necessary for the continued function of the rest of the IPv4 applications that their customers

Nor I.  Nor would I even suggest that they do so.   As bad as CGN is, it's far better than no IPv4 access at all.  And clearly it's important to continue providing access to at least the IPv4 services that can manage to work over NAT.  (I've said for years that the web and email would be the _last_ services to migrate to v6, because they are so entrenched, and because they more-or-less work fine even over NAT.  So in my estimation, CGN will be needed for many years to come....though I'd love to be proven wrong.)

But I do believe that because it breaks 6to4, that CGN can have a chilling effect on IPv6 deployment, and I don't think that's a good thing.  Which is why I think that operators need to be trying very hard to get native v6 lit up for their customers at the same time as, or ideally before, they're forced to impose CGN. 

(And I don't doubt that most operators are now working on rolling out v6 in addition to CGN, but it's not clear to me whether they see a need to coordinate those two.)

> said draft to limit the collateral damage?

I actually think we are moving on, it's just that a lot of emails have been exchanged and it takes some time for people to get around to reading them and noticing the change.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 09:18:36 -0500

> This doesn't seem realistic to me.

Well, I'm hoping that ICMP is sufficient, and that mere configuration of existing hardware is enough to implement the new mechanism on the provider side.   

> And you ask not only to be free to enable 6to4 for your applications, but you also insist that some other users, who don't care about these applications, have to endure some broken connectivities.

It seems to me that you're the one asking for things to be broken.  Given that a number of platforms have been automatically enabling 6to4 for awhile now, to me it seems reasonable to expect that there are applications and users that depend on this.  Is it really reasonable to expect those users to have to know to explicitly turn on 6to4 from here on out?

I think a host should be able to determine what kinds of network access are available to it, and enable those kinds of access, without explicit configuration by the user or administrator.  

Keith

---

From: Jack Bates <[email-masked]>
Date: Wed, 09 Feb 2011 10:19:29 -0600

On 2/9/2011 8:18 AM, Keith Moore wrote:
> Is it really reasonable to expect those users to have to know to
> explicitly turn on 6to4 from here on out?
>

Yes. 6to4 can hurt the user's experience if they are not aware of it and 
the implications of using it. A knowledgeable user can activate 6to4 and 
has an understanding of the implications when things do not work 
appropriately.

On the other hand, most users who understand 6to4 and require it for 
functionality could probably benefit even more from IRON, which may not 
be in the OS by default but could be setup to work in a large variety of 
cases for those wanting private networking, reachability, or perhaps to 
link to an IPv6 Internet even through LSN. In many cases, IRON appears 
to be like 6to4 in that a single device can act as the tunnel device to 
interconnect the local network to the larger network.

The only questions, which I haven't looked up, is if IRON supports 
win32, so a traveler could hook up their laptop and connect to the IPv6 
network (or the home network) via IRON and available service terminators 
of IRON with native IPv6 connectivity. However, in a public scenario, a 
mixture of IRON (from say the home) and 6to4 (from a remote location 
that supports it) or native, would give more options for end to end 
connectivity.

> I think a host should be able to determine what kinds of network
> access are available to it, and enable those kinds of access, without
> explicit configuration by the user or administrator.

I agree. Unfortunately, 6to4 connectivity detection wasn't built into 
6to4. As such, it often tries to use 6to4 when there is no 6to4 
availability. It should be turned off by default and perhaps an easy 
mechanism for enabling it (click check box).

Jack (honestly, can anything more be said without rehashing a thread 
which I posted waaaaay too much to?)

---

From: Rémi Després <[email-masked]>
Date: Wed, 9 Feb 2011 17:21:32 +0100

Le 9 févr. 2011 à 15:18, Keith Moore a écrit :

> Well, I'm hoping that ICMP is sufficient,

ICMP isn't a "new mechanism", fair enough.
But as we know it is unfortunately filtered in a significant part of the real world.

> and that mere configuration of existing hardware is enough to implement the new mechanism on the provider side.

Existing hardware, I suppose so, all existing software, I can't be sure.
In any case still a configuration that, if not already done today, may not be easy to obtain.

> It seems to me that you're the one asking for things to be broken.  

Until some sort of happy eyeballs is deployed and connection that fails is much worse, for ordinary users, than a connection in IPv4 although a 6to4 address could have been available.
For Grandma's applications, IPv4, even if across one or several NATs, isn't that bad after all.
She can wait for native IPv6 addresses to be available, and used without her having to know it.

> Given that a number of platforms have been automatically enabling 6to4 for awhile now, to me it seems reasonable to expect that there are applications and users that depend on this.

IMHO, applications that "depend" on IPv6 should better be used in sites that have ISP provided IPv6, or in sites operated by someone who understands 6to4 enough to deal with its limitations.

>  Is it really reasonable to expect those users to have to know to explicitly turn on 6to4 from here on out?

Alternatively, if they want applications that depend on IPv6, they can switch to an ISP that offers native IPv6 addresses (be it with 6rd if native IPv6 routing is difficult in its access network).

> I think a host should be able to determine what kinds of network access are available to it, and enable those kinds of access, without explicit configuration by the user or administrator.

Agreed, but only for network accesses that don't have intrinsic limitations that can be detrimental to user experience.
Especially if this poor experience risks to be unduly imputed to IPv6 in general.

Regards,
RD

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 09 Feb 2011 09:29:34 -0800

On 2/9/11 5:32 AM, Keith Moore wrote:
>>> ...  There's definitely an ideology that use of 6to4 is somehow
>>> not legitimate and that it's therefore acceptable to sabotage it
>>> rather than to try to fix it.
>> 
> What I do accept is that if an ISP imposes NAT on its customers,
> there should be some well-defined mechanism to signal that to hosts
> using 6to4, so that those hosts can (a) stop trying to use 6to4 on
> that link, and (b) provide a useful error message to their users.

No stack changes are going to percolate to a big chunk of the installed
base. It would be more fruitful to consider what can be done without any
additional signaling.

The signal that works (for the most part, there are exceptions) is to
assign an rfc 1918 scope address to the host or cpe. This is among other
reasons why I thought the proposal for a new private scope address range
for ISPs was a bad idea.

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 13:18:40 -0500

On Feb 9, 2011, at 11:19 AM, Jack Bates wrote:

> Yes. 6to4 can hurt the user's experience if they are not aware of it and the implications of using it. A knowledgeable user can activate 6to4 and has an understanding of the implications when things do not work appropriately.

In case it's not clear that I realize this, I do want to acknowledge that the user's experience with 6to4 enabled can be worse than the user's experience with 6to4 disabled.  I've seen this firsthand for years...  The user's experience can also be better with 6to4, but right now it's probably worse for most people and applications.

However, I think it's dangerous to make assumptions that a user's experience will be better in the future without 6to4.   Conditions keep changing.  On one hand we expect wider adoption of IPv6 in both the network and applications, which might favor increased use of 6to4.   On the other hand we also expect carrier-imposed NAT to start becoming more and more common, which would contraindicate 6to4 if the host can't recognize the condition and disable its use.  

I also think that IETF backpedaling on 6to4 would send a confusing message to the public and to developers, one that might impede adoption of IPv6.  I think the message we want to send is that we have IPv6 solutions that work today, that more efficient solutions are coming, and that the host support for both the near-term and the long-term solutions is already widely deployed.  We all know that this is a somewhat rosy portrayal and that things could be better than they are, but we all - operators, content providers, software developers, etc. - need to dedicate ourselves toward making the best we can do with the solutions that we have deployed in hosts now.    

We have had 15+ years to tweak IPv6 and the ways to carry it.   Now is the time to make IPv6 work with the solutions that we have.  That doesn't mean we can't work on even better ways to carry IPv6 traffic, but it does mean that we can't wait until we have better solutions in place before we start carrying IPv6 traffic.   Any means of carrying IPv6 that's not already being shipped by OS and equipment vendors today, is not going to be generally usable within the next several years.

In that sense, 6to4 is a lot like CGN - both are ugly, both could really use improvement, but we don't have the luxury of waiting around for something better.  (Yes, it's really unfortunate that the two conflict with each other.)

I'll believe that 6to4 is no longer needed when I can see that anybody can get a stable connection using IPv6 space at a reasonable price.  As it happens, I was just last week shopping for internet access at my home.  Every provider that served my area was willing to give me a static IPv4 address, or even a /29, for a small fee over the cost of business rate IP service.   I was able to find providers that could assure me they wouldn't block IP tunneling (most didn't have a clue as to what I was talking about).  But not a single one of those providers could offer me any kind of IPv6 service.   I'd even settle for a configured tunnel as long as it terminated somewhere nearby.  Not available.

I think ISPs need to realize that 6to4 is a well-established standard for transmitting v6 over the public v4 Internet, it's widely supported in hosts, it is going to be used, and the network needs to support it too.  For networks that can't support use of 6to4 addresses by their customers (e.g. because of CGN), the best solution - really the only viable solution that I can see - is for them to offer native IPv6 - ideally, in a way that doesn't require the customer to do anything different.   And even those networks may need to provide and maintain 6to4 relay routers so that their customers using native v6 can reliably talk to hosts with 6to4 addresses.

Back to the question of whether hosts should enable 6to4 by default.  I'm very leery of expecting users to know what 6to4 means and whether to enable it.  I'm also very leery of expecting users to deal with arbitrary changes in the way their platforms deal with the network.    I think it's incumbent on the CGN people to define a simple and standard way to signal to hosts that 6to4 can't possibly work for them.  And if IETF's going to recommend a change to host behavior, it should be to support that means of signaling, rather than to tell them to disable 6to4 by default.

Having said that, it seems that OS vendors are always tweaking their autoconfiguration code anyway.  I think they're probably in a better position to know what works for their customers than IETF is.

As for the other problems with 6to4 that Brian identified, these are problems in the network, and it's the network's job to address them.   Regardless of what we decide here, 6to4 is not going away until native v6 becomes ubiquitous.

Keith

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 09 Feb 2011 10:37:17 -0800

On 2/9/11 5:51 AM, Pekka Savola wrote:
> implementations will get disabled with private IPv4 addresses.

3056 is pretty unequivocal as to what to do with a private ip address...
there are exceptions in that a few of which lorenzo found will use them
anyway.

> This is
> but blocked in the network.  Systems that end up behind LSN and private
> addresses also have the option of starting to use Teredo or another
> transition mechanism that can punch through LSN.
> 
> 
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 13:40:45 -0500

> But as we know it is unfortunately filtered in a significant part of the real world.

Presumably the networks that implement CGN are in a position to arrange that ICMP not be filtered between their routers and their customers, which is all that matters for this case.

> Until some sort of happy eyeballs is deployed and connection that fails is much worse, for ordinary users, than a connection in IPv4 although a 6to4 address could have been available.

I understand that native v6 doesn't work very well right now either.  The solution in both cases - 6to4 and native v6 - is for the network operators to work out the kinks.   Of course, the sooner they work out the kinks with native v6, the fewer problems they'll see with 6to4.

(Happy eyeballs, BTW, is nothing new.  I was researching and implementing similar things, and pointing out that address selection rules could never work well, at least as far back as 2005.  The reactions I got from both IETF people and funding agencies at the time ranged from indifference to hostility.  So I'm glad to see that these issues are finally getting the attention they deserve.)

> She can wait for native IPv6 addresses to be available, and used without her having to know it.

I totally do not believe analyses that only consider the case of the hypothetical Grandma.  The Internet and the needs of its users are much more diverse than Grandma.

> IMHO, applications that "depend" on IPv6 should better be used in sites that have ISP provided IPv6, or in sites operated by someone who understands 6to4 enough to deal with its limitations.

You can believe that if you want, but the very purpose of 6to4 was to enable v6 without ISPs having to explicitly provide for it.    I suppose the irony there is that because of the potential for flaky relay routers, ISPs have to deal with it anyway.  If 6to4 has provided them extra incentive to get native v6 working, so much the better (not that I don't think anyone seriously is trying to avoid that any more, but it was a problem until recently).

> Alternatively, if they want applications that depend on IPv6, they can switch to an ISP that offers native IPv6 addresses (be it with 6rd if native IPv6 routing is difficult in its access network).

Those ISPs appear to be quite rare at present.    

> Agreed, but only for network accesses that don't have intrinsic limitations that can be detrimental to user experience.

Then they definitely shouldn't enable NATted IPv4 by default.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 13:45:05 -0500

> base. It would be more fruitful to consider what can be done without any

Is it really significantly easier to get a change to default configuration than a change to the stack code?  Seems to me like about the same amount of coding, documentation, and QA in both cases.  If anything, the change for configuration seems a bit worse because it more directly affects the user experience.

> reasons why I thought the proposal for a new private scope address range

If ISPs that use NAT can make this work for them and their customers, I'm certainly happy that it happens to disable 6to4.  But I understand if ISPs find that on balance using RFC 1918 addresses causes more problems than it solves.

Keith

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 19:50:25 +0100

> there are exceptions in that a few of which lorenzo found will use them

Is there any quantification of "a few"? I was under the impression that
"a few" are actually "quite many". Unfortunately I have no sources to
cite, but that's indeed a good item to check in CPE testing for.

I've just checked CentOS 5 - the IPv6 init scripts take care that 6to4
ain't enabled when the "outside" interface doesn't have a global IP.
Given that it's an init script thing and not a kernel thing, I fear that
CPE router vendors using Linux are not necessarily as attentive.

Perhaps the problem is really only a real problem when non-RFC1918 is
being used for the WAN interface.

Customer end hosts don't make me worry - CPE routers implementing 6to4
do.

Best regards,
Daniel

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Feb 2011 11:04:38 -0800

Hi,

There seems to be sufficient interest in IRON that I
thought it might be helpful to post a bibliography in
one place rather than expect folks to glean all of the
pieces that are scattered throughout the list archives.
IRON itself is actually a conglomerate of architectural
constructs and functional specifications that also
includes RANGER, VET and SEAL. The big-picture can be
understood by just looking at the IRON core document:

but if you want to dig deeper the full set of
constituent documents are here:

  http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt
  http://www.rfc-editor.org/rfc/rfc5720.txt
  http://tools.ietf.org/html/draft-templin-intarea-vet
  http://tools.ietf.org/html/draft-templin-intarea-seal

And, if you get that far you might also want to take
a look at the related use case analysis documents, which
includes operational considerations of interest not only
to ISPs but also to any other prospective IPv6 domains
of applicability:

  http://www.rfc-editor.org/internet-drafts/draft-russert-rangers-05.txt
  http://tools.ietf.org/html/draft-templin-iron-pm-00.html
  http://tools.ietf.org/html/draft-templin-ironmike-00 

Finally, a first-version implementation is available here:

I am working on an updated version of the implementation
and hope to release that within the next several days.

As always, I am open to your comments and questions.

Thanks - Fred

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 20:06:45 +0100

On Wed, Feb 09, 2011 at 08:39:39AM -0500, Keith Moore wrote:
> It seems to me that if an ISP starts giving RFC 1918 addresses to its
> customers, that's going to cause breakage too.

Indeed. Pick your poison. There are a variety of reasons why operators
might reallyreally want/need to avoid assigning RFC1918 addresses to
untrusted customer devices [hint embedded].

Some operators are trying to avoid NAT444 altogether because of all the
landmines associated with it (read: e.g. DS-Lite - which will deliver
native IPv6 proper as a "side product" as well).

> And while I agree that the two cases are distinct, using any kind of
> NAT breaks 6to4.  And if that's the only means of v6 access available
> to the customer, the effect of LSN _is_ to break IPv6.

Looking from flight level 850, most couldn't care less, as long it
doesn't lead to blackholing and thus longish timeouts on application
level => impaired IPv4 Internet experience.

As long as there is no (relevant!) IPv6-only content, delivering IPv6
to eyeballs is not a matter of immediate(!) business continuity. So
while it might be that a few techies don't get their funky 6to4 anymore
to watch the dancing turtle, it doesn't really matter as long as we
saved the "Internet experience" for the other 99,999*% paying customers
not even able to spell Aiy Pee Wii Sixxx.

<randy>I fully encourage all our competitors to introduce LSN and _not_
work on urgent native IPv6 access deployment as well</randy> :-)

Best regards,
Daniel (now going to search for the soap bar to wash his mouth)

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 20:10:51 +0100

On Wed, Feb 09, 2011 at 01:17:31PM +0200, Pekka Savola wrote:
> That will certainly happen if the ISP is natting between two public address 
> spaces.  But I don't think LSN would do that by definition?

What's the definition of "LSN"?

In my book it means:
- NAT device
- supporting lotsa sessions and Gigabits
- operated by the ISP (that's already a stretch)

No less, and certainly no more.

> If the ISP switches the user to use a private IP space, 6to4 usage will 
> just stop but it won't break.

In an ideal world, it would. 

> Let's keep these two cases clearly distinct.

While it's indeed a good idea to make that clear distinction, in the net
effect it's about quantity. Folks doing NAT444 with privat IPs on CPE
WAN side will see far less 6to4 problems than ISPs doing NAT444 with
global IPs on CPE WAN side, granted. But still both have the same
problem as not all implementation "behave".

Best regards,
Daniel

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 9 Feb 2011 11:29:05 -0800

> Customer end hosts don't make me worry - CPE routers implementing 6to4

So i just did some quick testing of my own on my network, LSN + BOGON.
 I did not see any breakage with dual-stack web sites.  So what really
breaks to the customer .

Setup:
Current Windows 7 Netbook from Dell
Current browsers Opera (11.01), Firefox (3.6.11), IE (8.0.76), and
Chrome (9.0.597)
nslookup result in both A and AAAA records for dual-stack domains
BOGON IPv4 address on PC via 3G
Null route of 6to4 anycast in network
6to4 address shows up in "ipconfig"
No special changes to the OS or host config, this system generally
works fine and is "normal"

Results:  All websites loaded without any noticeable delay

Chrome:  www.ucla.edu, www.arin.net

IE: www.he.net, www.brocade.com

Opera: www.ietf.org, www.sixy.ch

Firefox: www.ripe.net, ip6.me, www.comcast6.net

So, where do we find the bad user experience in this to joe sixpack
that does not care or know about IPv6?  How does this impact world
ipv6 day?

Thanks,

Cameron

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 20:46:48 +0100

> BOGON IPv4 address on PC via 3G

What is a "BOGON" address in that specific case? RFC1918?

Best regards,
Daniel

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 9 Feb 2011 13:26:33 -0800

> What is a "BOGON" address in that specific case? RFC1918?

UK military  range

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Feb 2011 10:39:13 +1300

>> What is a "BOGON" address in that specific case? RFC1918?

As far as 6to4 is concerned, any non-RFC1918 address that in reality
is not connected directly to the global Internet is a bogon.
It really doesn't matter where the ISP has "borrowed" it from.

And before anyone asks, we can't solve this with a globally
defined blacklist to be added to RFC 1918, because any ISP
operating a CGN can "borrow" any address range they decide to.

    Brian

---

From: Jack Bates <[email-masked]>
Date: Wed, 09 Feb 2011 15:44:48 -0600

> operating a CGN can "borrow" any address range they decide to.

Or just mirror their own allocated space 100 times.

Jack

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Feb 2011 10:44:45 +1300

> - The message being clear enough, completely deprecating 6to4 would become an unnecessary overreaction.

Despite Keith's counter arguments, from what I've read here and on other
lists, I am going this way in my draft.

Certainly, ICMP 'destination unreachable' should be returned but it seems that
most 6to4 implementations don't react appropriately to this, and I think it's too
late to expect those code bases to be updated.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Feb 2011 16:48:13 -0500

> late to expect those code bases to be updated.

but somehow it's not too late to expect the same code bases to be updated to disable 6to4 by default?

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Feb 2011 10:57:16 +1300

> but somehow it's not too late to expect the same code bases to be updated to disable 6to4 by default?

That isn't in the code base - at least in Windoze, I suspect it's a registry
setting, which appears as a default
  netsh interface ipv6 6to4 set state state=enabled
(at least in XP; I haven't modernised:)

    Brian

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 9 Feb 2011 23:09:09 +0100

> > What is a "BOGON" address in that specific case? RFC1918?

OK, so something that every heuristic considers a "globally unique IPv4
address" in the sense of RFC3056 requesting that as a prerequisite.

Given that Windows 7 won't use 6to4 unless talking to another 6to4
remote system OR a v6-only remote system without any other IPv6
transport means, your results are just as expected. RFC3484.

End hosts not implementing RFC3484 policy are of concern, especially
when the CPE router is the one actually implementing 6to4. The simple
end host logic "don't use my local 6to4 tunnel functionality in case my
IPv4 address is RFC1918" won't cut it. The end host learns the
6to4-derrived IPv6 address from the CPE router and might prefer that
6to4 IPv6 (non-)connectivity over IPv4.

So the problem probably boils down to what OSses properly implement
RFC3484?

BTW while we're talking Win7+6to4 (just stumbled over that):
http://ryanvictory.com/posts/automating-6to4-adapter-removal-in-windows/
http://news.softpedia.com/news/Windows-7-Can-Create-New-6to4-Adapters-on-Every-Reboot-135518.shtml
http://support.microsoft.com/kb/980486/

Best regards,
Daniel

---

From: Nathan Ward <[email-masked]>
Date: Thu, 10 Feb 2011 11:18:31 +1300

>> What is a "BOGON" address in that specific case? RFC1918?

What 6to4 "client" software did you use?

In San Francisco I talked about a 6to4 qualification mechanism which would send several 6to4 packets to ensure that the "client" had a non-NATted publicly reachable IPv4 address with protocol 41 open.
Someone at MS - I forget who - stated that their 6to4 implementation sends a test 6to4 message to check that the relay is reachable. I believe Apple said they do a similar thing in their 6to4 CPE devices (James?). I have not observed (or tried to observe) either of these mechanisms personally. While not a complete solution to test 6to4 health, this might be why you do not see a poor user experience.

In addition, as Daniel Rosen mentions, RFC3484 probably plays a large part, if your end host IPv6 stack implements RFC3484 and has a line in there for 6to4.

--
Nathan Ward

---

From: Jack Bates <[email-masked]>
Date: Wed, 09 Feb 2011 16:44:35 -0600

On 2/9/2011 4:09 PM, Daniel Roesen wrote:
> when the CPE router is the one actually implementing 6to4.

Keep in mind, Cameron is using a 3G network. CPE routers are less likely 
to appear, and even less that support 6to4.

You are right on his results with RFC3484, but that's the point of the 
test. "A typical user connecting via 3G browsing dual stacked hosts."

What works for 3G doesn't apply to landline.

Jack

---

From: [email-masked]
Date: Thu, 10 Feb 2011 00:59:24 +0200

>Really?   All of the major OS vendors have been shipping IPv6 support
>for several years now.  Sure, there are still a few people running
>Win 2k, me, 98, or even 95, but not many.

Really? IPv6 service on our mobile network is available today! Have you heard of any USB sticks that would play nicely with it?
So, you are definitely wrong! The situation is very different from an ISP to another, but for mobile today, I can give service, but there is almost no one to be able to get it. It's amazing how many people can't still figure it out.

Best,
Roman

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 10 Feb 2011 00:03:48 +0100

On Wed, Feb 09, 2011 at 04:44:35PM -0600, Jack Bates wrote:
> Keep in mind, Cameron is using a 3G network. CPE routers are less likely to 
> appear, and even less that support 6to4.
>

Indeed, in networks where users attach without a router directly to "the
net" will probably have no significant issues as long as the hosts
implement RFC3484. No matter wether that access network is 3G or e.g.
DOCSIS with host directly connected to the cable modem, WiFi hotspots,
etc.

Best regards,
Daniel

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 09 Feb 2011 15:15:01 -0800

On 2/9/11 2:59 PM, [email-masked] wrote:
>>> Fact - Most users don't have enough IPv6 capable devices to move
>>> to
>> using primarily IPv6 (let alone
>>> IPv6-only) anytime soon
>> 
>> Really?   All of the major OS vendors have been shipping IPv6
>> support for several years now.  Sure, there are still a few people
>> running Win 2k, me, 98, or even 95, but not many.
> 
> Really? IPv6 service on our mobile network is available today! Have
> you heard of any USB sticks that would play nicely with it? So, you
> are definitely wrong! The situation is very different from an ISP to
> another, but for mobile today, I can give service, but there is
> almost no one to be able to get it. It's amazing how many people
> can't still figure it out.

lg and huawei both now have products that fit that particular
requirement... As with most carrier supported/launched mobile products,
they build to their customer requirements... And you know as well as
anyone where chipset supports stands.

as to other members of the choir, the OSes already support it, legacy
baseband radio controllers not so much. That's fine it's in their
roadmaps and by the time you've got a v6 supporting mobile network
widely deployed you'll presumably have products to put on it.

> Best, Roman _______________________________________________ v6ops
> mailing list [email-masked]

---

From: [email-masked]
Date: Thu, 10 Feb 2011 01:37:28 +0200

>widely deployed you'll presumably have products to put on it.

the time for IPv6 was unfortunately yesterday, and today, the "presumably" is simply not good enough.
Otherwise, thanks for being optimistic :)

Best,
Roman

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 09 Feb 2011 16:06:58 -0800

> Otherwise, thanks for being optimistic :)

I shouldn't talk about specifics with other manufacturers but my
employer has a lovely white paper on using ipv6 with our devices on
forum nokia, some devices in the porfolio have supported it since 2005.
your NSN account rep can probably cover the details of deployment better
than I can.

---

From: Martin Millnert <[email-masked]>
Date: Wed, 09 Feb 2011 20:59:27 -0500

Daniel, list,

On Wed, 2011-02-09 at 23:09 +0100, Daniel Roesen wrote:
> The end host learns the

While programming bugs are inevitable, I don't see why this should
happen.  Given 6to4:s overall operational status, 1918 IPv4 should be
preferred over 2002::/16. Are you saying it's not in some
configurations? 
Put differently, 2002::/16 source addresses should obviously be used
when it's the only global-scoped v6 source address available, when
connecting to a global-scoped v6-only destination.  Please tell me this
is already the case! :) (can't test this now)

> So the problem probably boils down to what OSses properly implement

Yes.  And those that don't should get updated, frankly. It's important.
The future depends on it. (and so on)  If it is in fact only broken 3484
implementations causing all the 6to4 breakage we hear about, we should
find a way to make this prioritized highly enough that OS:es not yet
passed end-of-support receives an update.  Though I'd be surprised if
this wasn't mentioned by someone else at least 5 years ago though, and
nobody listened...

It'd be a very cool way for Microsoft and Apple to participate in World
IPv6 day for sure! (Seriously.)

> http://support.microsoft.com/kb/980486/ 

I've seen this myself, "adapter #56". (There are other
implementation/programming bugs in Win7's stack as well, I emailed
either v6ops or ipv6-ops with this last year. ) 

/M

---

From: [email-masked]
Date: Thu, 10 Feb 2011 08:06:06 +0200

>your NSN account rep can probably cover the details of deployment

I am well aware of your employers support of IPv6 in both core and handsets. Thanks to the former, people who have ever deployed things in the mobile core, were as well able to take it out of pure theory and test it. It is really appreciated.
The scope of my message was to point out to some of the folks on the list that are so eagerly talking about pervasive IPv6 support that for some businesses the current technical model does not imply plugging in an Ethernet cable and rely on OS support alone. This makes it a huge deal breaker.

For the rest of this huge thread, I agree with Remi conclusions. 6to4 should be shut down by default. Even putting it to the bottom by a policy alone does not save it from issues with bogon space. Otherwise, as a mechanism, it might be there as a last resort for tech savvy customers.
On the other hand I can't agree more with James Woodyatt. Manufacturers will not modify the existing state of art if we deprecate 6to4. As well as I am not gonna shut down the 6to4 anycast relay. The point is just to make sure manufacturers don't put as many resources in maintaining 6to4, and would rather focus on a better support of IPv6 stack, management over IPv6 etc.

Best,
Roman

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Feb 2011 01:39:33 -0500

> (at least in XP; I haven't modernised:)

maybe so.  and Windows is the single biggest variable, of course. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Feb 2011 01:43:50 -0500

> Really? IPv6 service on our mobile network is available today! Have you heard of any USB sticks that would play nicely with it?

I'm not sufficiently familiar with either your network or USB sticks that might work with your network, to know one way or the other.

(I have to wonder, why would a USB stick care whether it's sending v4 or v6?  Shouldn't it be operating at L2?  Is it really the USB stick that's the problem, or the host device driver?)

Keith

---

From: [email-masked]
Date: Thu, 10 Feb 2011 08:58:14 +0200

Keith Moore <[email-masked]> wrote on 10-02-2011 08:43:50:

> From: Keith Moore <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Date: 10-02-11 08:44

> > Really? IPv6 service on our mobile network is available today! 
> Have you heard of any USB sticks that would play nicely with it?

> I'm not sufficiently familiar with either your network or USB sticks
> that might work with your network, to know one way or the other.

> (I have to wonder, why would a USB stick care whether it's sending 
> v4 or v6?  Shouldn't it be operating at L2?  Is it really the USB 
> stick that's the problem, or the host device driver?)

The radio controllers are the issue. The entire worldwide user base is not 
upgradeable to IPv6 as a result. I know, this is very weird. And it is not 
only about USB sticks, but about mobile phones as well. Exception are 2 
manufacturers.

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Feb 2011 01:59:15 -0500

> late to expect those code bases to be updated.

FWIW, I'm going to stop arguing against this.   I'm now persuaded that the soon-to-come wide deployment of carrier-provided NATs is going to relegate 6to4's usefulness to corner cases.  That doesn't make it useless, and I think ISPs and content providers will still have to deal with making sure that relay routers are working for some time to come.   But it does keep 6to4 from serving as a general-purpose way to use IPv6 over a vanilla IPv4 connection.  

I think it's a huge loss, and it will make v6 harder to deploy, but nothing can be done about it.  There's no way to make 6to4 work over a bogon network without introducing NAT into IPv6, and that's a much worse thing to do than forcing NAT onto v4.

I'm also persuaded that - mostly due to CPE brain-damage - it's not feasible to have a general mechanism for the network to tell end systems to disable 6to4.  

So on balance, I now think it makes sense to expect the users in those corner cases to have to explicitly enable 6to4.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Feb 2011 02:07:21 -0500

On Feb 9, 2011, at 8:59 PM, Martin Millnert wrote:

> preferred over 2002::/16.

disagree.  there are situations where 6to4 will break.  there are also a lot of situations where NATs will break applications.  whether to prefer a NATted v4 connection over a 6to4 connection is application specific.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Feb 2011 02:12:26 -0500

> only about USB sticks, but about mobile phones as well. Exception are 2 

maybe there need to be DHCPv4 and/or PPP options that tell hosts/CPEs how to configure their end of a v6-over-v4 tunnel, with the other end of the tunnel provided by the network.

it's probably too late for such a mechanism to be of general use across all v4 networks, but for specific network layers it might be useful.

Keith

---

From: <[email-masked]>
Date: Thu, 10 Feb 2011 12:57:59 +0000

Keith,

> (I have to wonder, why would a USB stick care whether it's sending v4
> or v6?  Shouldn't it be operating at L2?  Is it really the USB stick
> that's the problem, or the host device driver?)

In 3GPP architecture the L2 is actually aware of IPv4 and IPv6, as draft-korhonen-v6ops-3gpp-eps-06.txt points out.

Hence the requirement for USB stick to support IPv6 on L2.

Best regards,

Teemu

---

From: Gert Doering <[email-masked]>
Date: Sat, 12 Feb 2011 14:09:14 +0100

Hi,

On Tue, Feb 08, 2011 at 06:34:11PM -0500, Keith Moore wrote:
> I certainly get that impression from many of the participants
> here.  There's definitely an ideology that use of 6to4 is somehow

This is completely missing the point.

6to4 is already today frequently not working in a way that's not
possible to fix, because there's no way to figure out for a user 
who's 6to4 relay is breaking his *return* packets.  If there were 
a central Internet authority that could order ISPs to properly run
their 6to4 relays, this might change, but there isn't.

Furthermore, 6to4 brokenness will go up due to the inevitable addition 
of CGN/LSNs due to IPv4 run-out.  

The point therefore is: if we cannot *fix* 6to4, due to the way the
reality is, can we remove it from the list of things that will cause 
breakage in the transition to native IPv6, for example by having it
"disabled-by-default" in client OSes and CPE OSes?

Nobody is advocating to go out and "filter proto 41, just for the sake
of it" or "mandate that Microsoft will remove 6to4 support from their
stacks" ("default-off" and "remove completely" are very much different
things for those that know what they want).

[..]
> The idea that the internet's only purpose is for users to get "content" has always struck me as bizarre.   

It wasn't built that way, but that's what it is today.  Not its only purpose,
but that's where most of the money required to make it work is coming from.

[..]
> CGN is also going to make existing services break, likely causing users to switch ISPs.

If "lots of users" are going to switch ISP to a new ISP without CGN - what's
that ISP going to do, if all these new customers burn up his IPv4 space?  
Cough up new IPv4 /8s, to keep "offering IPv4 Internet without CGN"?

[..]
> But when operators start blaming 6to4 on problems that were actually caused by operators, it's hard to see how they can find suitable solutions.

Maybe you should remember that there's some 45.000 different companies 
out there running "The Internet" (just counting active AS numbers).

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Sat, 12 Feb 2011 08:42:39 -0500

> their 6to4 relays, this might change, but there isn't.

It's not really my wish to keep arguing about this.  I've already conceded that it's reasonable for implementations to disable 6to4 by default.   However, to respond to your points:

There is no central Internet authority than can order ISPs to properly run their v4 or v6 routers either.    Somehow, (most) ISPs seem to try to do that anyway.

> of CGN/LSNs due to IPv4 run-out.  

That much I concede.

If anything I think that 6to4 has two fatal flaws.  One is that it was intended to be a mechanism that would work without explicit ISP involvement.  This is, or should be, true for traffic going from one v4 site to another (both ends using 2002: prefixes).  But it's definitely not true for traffic that requires use of relay routers.  In hindsight it's clear that ISPs throughout the network have to either maintain relay routers themselves, or test their peers' relay routers to determine whether the work and filter routes for those that don't.  If ISPs felt like 6to4 was part of their operational responsibility, I think they could manage to do those things.  But given that 6to4 wasn't intended or designed to be part of their operational responsibility (for instance, management of relay routers wasn't addressed), it's hard to blame them for not wanting to fool with it. 

The second flaw is that 6to4 simply wasn't designed to handle a scenario where v4 addresses are extremely scarce and NATs are almost universally required.  The assumption was that any site needing to use 6to4 could at least get one stable and global IPv4 address, until such a time as native v6 service were widely available.

> things for those that know what they want).

Apparently some are filtering proto 41, some are filtering traffic to relay router anycast addresses, and people have talked about "deprecating" 6to4.  "Default off" is less drastic than these, but it's not the only idea that's been floated.

> but that's where most of the money required to make it work is coming from.

I sometimes get the impression that operators often think in terms of "how much money will it cost us (in support costs and lost customers) if we break X"?   I can see why they might think that way.  But I don't think this is an appropriate kind of analysis in an engineering discussion, say, about what kind of technical mechanism should the Internet use to address a particular problem.   The reason is that the effect of breaking some feature of the Internet isn't limited to the network that broke it and its customers/users.   For example, even when only a relatively small percentage of networks were NATted, the existence of NAT had a profound effect on applications throughout the whole network.

I also think that it's very difficult even for an operator, or anybody really, to know what the effect will be of breaking some feature that people are already using.  An operator might have a good idea of how many of its customers are using it, today.  But it doesn't know how valuable that feature is to those customers, nor how many customers are planning to use something that requires that feature.   (Even the customers might not know those things, if they're not aware that their applications are using the feature.)

> Cough up new IPv4 /8s, to keep "offering IPv4 Internet without CGN"?

right... I think the result will be a lot of customer churn, at least until it's widely understood that there are simply no more v4 addresses to be had.

> out there running "The Internet" (just counting active AS numbers).

of course I'm aware of that.  

Keith

---

From: Jack Bates <[email-masked]>
Date: Sat, 12 Feb 2011 09:58:58 -0600

On 2/12/2011 7:42 AM, Keith Moore wrote:
> I sometimes get the impression that operators often think in terms of "how much money will it cost us (in support costs and lost customers) if we break X"?   I can see why they might think that way.  But I don't think this is an appropriate kind of analysis in an engineering discussion, say, about what kind of technical mechanism should the Internet use to address a particular problem.

I think you'll find it more common for operators to think in realistic 
terms of what happens within the scope of the networks they control. I 
don't argue that there is something for the purity of overall 
engineering and making things work extremely well in a perfect plan. 
However, such engineering often discounts the scope of the operators and 
the individual problems faced by each in the real world environments.

Networks aren't perfect (most protocol specifications aren't either, 
implementations even less so), most operators must make concessions to 
design based on the purchasing decisions or desires of others. We 
literally are given a bunch of gear (if lucky, we get to give input on 
what gear) and told to make it work. ISP networks are completely 
different environments from corporate networks (or educational), yet 
even within a class of network, the vendors, implementations, 
requirements, and designs are vastly different.

If a technical mechanism won't be utilized by networks in the wild, or 
worse, networks will hurt such mechanisms, these are things to consider 
in an engineering scope. That is not to say such mechanisms aren't 
needed. If .01% is able to utilize 6to4 for some specific purpose that 
meets their needs (despite the problems), then the protocol 
specification was still needed. However, operators have to make 
appropriate decisions to keep the networks running with the tools they 
have, praying better tools are developed, and limit the damage caused by 
decisions which can't be avoided.

<snip really long post since I'm only on 2nd cup of coffee, and ended up 
writing more again>

Jack

---

From: Keith Moore <[email-masked]>
Date: Sat, 12 Feb 2011 11:13:35 -0500

On Feb 12, 2011, at 10:58 AM, Jack Bates wrote:

> I think you'll find it more common for operators to think in realistic terms of what happens within the scope of the networks they control. I don't argue that there is something for the purity of overall engineering and making things work extremely well in a perfect plan. However, such engineering often discounts the scope of the operators and the individual problems faced by each in the real world environments.

Well, most of my experience is as an applications developer and user.  So when I see things that operators have done (usually after having spent a few days trying to diagnose the problem), I often find myself asking "what the #$#@ were they thinking?".  I can (and usually do) try to imagine myself in their shoes, and sometimes I get an idea of why they might have done what they did.  But even then, it often seems that they didn't really think about the consequences, or try to find a fix for their problem that would minimize its adverse impact.  

OTOH, I certainly agree that quite often, probably most of the time, the design of network protocols doesn't really take operators' needs into account.

Keith

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 14 Feb 2011 12:38:36 +0100

Would you have Data-points on this Keith?

There are data-points on the brokenness of 6to4.
(and yes, i am working with Brian also on making 6to4 experience better)

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Keith Moore
Sent: 08 February 2011 18:19
To: Cameron Byrne
Cc: IPv6 Operations
Subject: Re: [v6ops] Fwd: New Version Notification
fordraft-troan-v6ops-6to4-to-historic-00

> never worth it.  They care that facebook works.  Everything else is

That is of course, completely false.  And operators who persist in
believing that are the source of the problem. 

Keith

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 14 Feb 2011 12:40:12 +0100

> it is difficult to see the motivation for anyone to run a relay router
in the first place.

To provide better service to their customers?   Nah, no provider would
want to do that...

GV> :-) ... oversimplification here. There are providing 'better'
service to people 'NOT' being their customer.

G/

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 14 Feb 2011 12:53:32 +0100

<>start<>
Meanwhile, I've also been trying to contribute to discussions about how
to (a) gracefully phase out 6to4 in favor of native v6, and (b) allow
6to4 to continue working until that happens.    I think it's much more
appropriate to devote attention to those topics than to "who is to
blame".  But it's hard to do that while people are still trying to kill
6to4 prematurely.
<>end<>

It is not a question of who or what is to blame. Its a matter of getting
the best Internet experience for the users of the environment.

G/

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 14 Feb 2011 13:08:10 +0100

<>start snip<>

That much I concede.

If anything I think that 6to4 has two fatal flaws.  One is that it was
intended to be a mechanism that would work without explicit ISP
involvement.  This is, or should be, true for traffic going from one v4
site to another (both ends using 2002: prefixes).  But it's definitely
not true for traffic that requires use of relay routers.  In hindsight
it's clear that ISPs throughout the network have to either maintain
relay routers themselves, or test their peers' relay routers to
determine whether the work and filter routes for those that don't.  If
ISPs felt like 6to4 was part of their operational responsibility, I
think they could manage to do those things.  But given that 6to4 wasn't
intended or designed to be part of their operational responsibility (for
instance, management of relay routers wasn't addressed), it's hard to
blame them for not wanting to fool with it. 

The second flaw is that 6to4 simply wasn't designed to handle a scenario
where v4 addresses are extremely scarce and NATs are almost universally
required.  The assumption was that any site needing to use 6to4 could at
least get one stable and global IPv4 address, until such a time as
native v6 service were widely available.

<>end snip<>

GV> They are not flaws, it are attributes to the 6to4 technology that
influence the usability of the technology for the quality of the users
Internet  experience.

<>start snip<>

> things for those that know what they want).

Apparently some are filtering proto 41, some are filtering traffic to
relay router anycast addresses, and people have talked about
"deprecating" 6to4.  "Default off" is less drastic than these, but it's
not the only idea that's been floated.
<>end snip<>

GV> We should do the right thing to improve the user experience on the
Internet and not be religious to a single technology.

G/

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 14 Feb 2011 13:21:25 +0100

Keith,

<>start snip<>
My problem with 6rd is that it's not something than an individual user
who needs IPv6 can deploy independently of support from his ISP.  
<>end snip<>

Actually users could use that technology ...for example, if the 6rd ISP
provider receives a /24 IPv6 prefix from his registry... then 
the IPv4 address of the end-user can be added  (24 + 32 = 56) then the
end-user still has 8 bits available for subnetting.

Its a case of use-case and implementation of the technology.

G/

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Feb 2011 09:11:02 -0500

> end-user still has 8 bits available for subnetting.

You're missing the point I was trying to make, which is that, unlike 6to4, users can't make use of 6rd without the ISP having explicit support for it.

I was aware that an ISP could give the user a /56 using 6rd.  Not as good as a /48, of course, but way better than a /64.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Feb 2011 09:33:39 -0500

> Internet and not be religious to a single technology.

I certainly agree about not being religious to a single technology.   

I also agree in principle with the idea of improving the user experience of the Internet.   But there are several problems with interpreting that idea.  Probably the biggest one is that something that improves the user's experience in the short term may do harm to the user's experience in the long term.  NAT, for example, allowed users to run more than one computer from the same connection, but also crippled the Internet's ability to run certain kinds of applications, and thereby impaired the users' ability to experience those applications.   Another problem is that many Internet applications don't exist to enhance a "user's experience" as they're not aimed at end users, but they can still be quite valuable.  A third is that thinking only in terms of "improving the user's experience" can encourage the "all users are alike" mentality, and/or the "the Internet will always be like it is now" mentality, both of which lead to incorrect analysis.

I'm pretty convinced that the best way to improve users' experience of the Internet in the long term is to keep the Internet flexible enough to handle a wide variety of applications, so that it can serve a wide variety of users, and bring a wide variety of new applications to users.  

Keith

p.s.  What originally motivated me to work on IPv6 in general, 10+ years ago when I was an Applications Area Director, was the realization that NATs were crippling the IPv4 network and limiting the kinds of applications that users could run.  6to4 was just a mechanism that I hoped would further this goal.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 14 Feb 2011 15:34:02 +0100

> You're missing the point I was trying to make, which is that, unlike 6to4, users can't make use of 6rd without the ISP having explicit support for it.

It's a point that you can get rather quickly from the first sentence in the abstract of RFC 5969, and the following sentence in second paragraph of the introduction:

   "This document specifies an automatic tunneling mechanism tailored to
   advance deployment of IPv6 to end users via a service provider's IPv4
   network infrastructure." 

   "By using the SP's IPv6 prefix, the operational domain of 6rd is limited to the SP
   network and is under its direct control."

6rd uses technology that looks like 6to4, but in no way is it intended for you or any other user to make use of without some ISP supporting it. It's a lot like native IPv6 in that regard.

- Mark

---

From: Ole Troan <[email-masked]>
Date: Mon, 14 Feb 2011 15:40:57 +0100

[...]

(assuming we are talking about residential users here)

> I was aware that an ISP could give the user a /56 using 6rd.  Not as good as a /48, of course, but way better than a /64.

does that imply that a /40 or a /32 is even better? (and a /0 is the best of all. ;-))
why is a /48 better than a /56? if this were to be true it would force SPs into competing on whom could give users the most amount of (wasted) address space...

cheers,
Ole

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Feb 2011 10:13:39 -0500

> does that imply that a /40 or a /32 is even better? (and a /0 is the best of all. ;-))

of course not.   

> why is a /48 better than a /56? if this were to be true it would force SPs into competing on whom could give users the most amount of (wasted) address space...

For the vast majority of residential users, a /56 is as good as a /48.  Even a /64 would probably be good enough, assuming that the market would produce clever routers that could handle hosts on each of multiple links within a single /64 and implement a ND proxy to let the hosts talk to each other.  (It appears that there will be multiple L2 technologies used in home automation networks.)

However, if an ISP relies on 6rd as its mechanism for routing v6 internally through much of its network, so that it can only offer a /56 to its "commodity service" customers, that's going to impair the ability of some of those customers to use the Internet.  And that might lead to a demand for NAT in IPv6, and that (as we know from experience) would do a great deal of harm.    I can understand why an ISP might want to cripple "residential" service in hopes of getting those customers to pay for more expensive service (like the salesman who tried to sell me a T1 line to my house last week because they couldn't offer me DSL without port blocking).  But many valuable organizations are going to be stuck with "residential" service only and are going to need to subnet.

Keith

p.s. Personally I think that allocating 64 bits to an interface identifier, and wiring that into the v6 architecture, were very shortsighted.  I think there will be a number of important cases where sites will need to subnet past /64.  I'm also one of those people who wishes that the IPng people had tried harder to find a way to make variable length addresses work.  But those are water under the bridge.

---

From: Ole Troan <[email-masked]>
Date: Mon, 14 Feb 2011 16:25:31 +0100

Keith,

> However, if an ISP relies on 6rd as its mechanism for routing v6 internally through much of its network, so that it can only offer a /56 to its "commodity service" customers, that's going to impair…

all the mechanisms that depend on encoding the tunnel endpoint address in the IPv6 address suffers to some degree of limitations of what end user network prefix can be used.

you can of course deliver a "native" IPv6 prefix over any of these mechanisms too. e.g. running DHCPv6 PD on top of 6rd or 6to4.

we are no longer talking about networks that 6rd or 6to4 was designed for.
/48 or /56 in these cases are the difference between infinity or infinity + 1.

> p.s. Personally I think that allocating 64 bits to an interface identifier, and wiring that into the v6 architecture, were very shortsighted.  I think there will be a number of important cases wher…

indeed. technically it is little problem changing (already works with DHCPv6). but, this is largely politically motivated. design IPv6 so that end-users get at least a /64 and aren't forced to do NAT.

cheers,
Ole

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Feb 2011 10:35:27 -0500

> all the mechanisms that depend on encoding the tunnel endpoint address in the IPv6 address suffers to some degree of limitations of what end user network prefix can be used.

Agree.

> you can of course deliver a "native" IPv6 prefix over any of these mechanisms too. e.g. running DHCPv6 PD on top of 6rd or 6to4.

DHCPv6 doesn't let you route a longer prefix to a customer over 6rd.  

> /48 or /56 in these cases are the difference between infinity or infinity + 1.

Not so.  It's not like the customer really gets to have 2^(128-prefix_length) hosts or anywhere close to that.   As long as we're still stuck with subnetting on bit boundaries, a lot of space will continue be wasted.  And there are a number of places where the assumption of max_prefix_length == 64 is wired into IPv6 protocols and code.

> indeed. technically it is little problem changing (already works with DHCPv6). but, this is largely politically motivated. design IPv6 so that end-users get at least a /64 and aren't forced to do N…

One person's "political motivations" are another person's "making the net work well" and another person's "business need".  

Keith

---

From: Ole Troan <[email-masked]>
Date: Mon, 14 Feb 2011 16:44:00 +0100

> DHCPv6 doesn't let you route a longer prefix to a customer over 6rd.  

you run DHCPv6 PD on top of the automatic tunnel and delegate native prefixes. in that case {6rd,ISATAP,6to4} is just used for  transport. can't remember if Fred Templin ever documented this mode or not.

> Not so.  It's not like the customer really gets to have 2^(128-prefix_length) hosts or anywhere close to that.   As long as we're still stuck with subnetting on bit boundaries, a lot of space will…

no, but the user would be able to get 2^8 links or 2^8-1 if the CPE took one for itself.
I would have thought that an end user requiring more than 2^8-1 number of links, with room for 2^64 number of hosts each, would have to "talk" to his ISP anyway...

> One person's "political motivations" are another person's "making the net work well" and another person's "business need".

indeed.

in any case I don't think the fact that 6to4 guarantees a /48 (but with patchy connectivity ;-)), justifies that mechanism with all its shortcomings over IPv6 access (6rd or native) which may give the user a /56. or whatever the SP decides for its default, vanilla service. (I would much rather have multi-homing than larger than /56 in my home).

cheers,
Ole

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Feb 2011 11:02:51 -0500

> I would have thought that an end user requiring more than 2^8-1 number of links, with room for 2^64 number of hosts each, would have to "talk" to his ISP anyway...

And that's why I agree that for most users /56 is as good as /48.

Though I keep thinking of situations where somebody needs to string together a lot of hosts on short notice and/or a tight budget.  Disaster relief is one such scenario; conferences are another.   They're rare situations, but it's nice if the network can support them without having to get people at an ISP explicitly involved.

> in any case I don't think the fact that 6to4 guarantees a /48 (but with patchy connectivity ;-)), justifies that mechanism with all its shortcomings over IPv6 access (6rd or native) which may give…

The point I was making was that 6to4 and 6rd serve different use cases.  Neither one subsumes the need for the other.

Keith

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 14 Feb 2011 17:32:36 +0100

On Mon, Feb 14, 2011 at 10:13:39AM -0500, Keith Moore wrote:
> Even a /64 would probably be good enough, assuming that the market
> would produce clever routers that could handle hosts on each of
> multiple links within a single /64 and implement a ND proxy to let
> the hosts talk to each other.

That's not clever, that's an ugly hack we certainly want to avoid.

Best regards,
Daniel

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Feb 2011 08:49:08 -0800

Hi Ole,

> On Behalf Of Ole Troan
> Sent: Monday, February 14, 2011 7:44 AM
> To: Keith Moore
> Cc: IPv6 Operations
> Subject: Re: [v6ops] Fwd: New 
> VersionNotificationfordraft-troan-v6ops-6to4-to-historic-00
> 
> >> you can of course deliver a "native" IPv6 prefix over any 
> of these mechanisms too. e.g. running DHCPv6 PD on top of 6rd or 6to4.
> > 
> you run DHCPv6 PD on top of the automatic tunnel and delegate 
> native prefixes. in that case {6rd,ISATAP,6to4} is just used 
> for  transport. can't remember if Fred Templin ever 
> documented this mode or not.

But of course:

https://datatracker.ietf.org/doc/draft-templin-intarea-vet/

In terms of plain-old ISATAP, RFC4861 tells that DHCPv6
is available when the M flag is set in RAs, and RFC5214
states that RAs are processed as specificed in RFC4861.

Thanks - Fred

> > Not so.  It's not like the customer really gets to have 
> 2^(128-prefix_length) hosts or anywhere close to that.   As 
> long as we're still stuck with subnetting on bit boundaries, 
> a lot of space will continue be wasted.  And there are a 
> number of places where the assumption of max_prefix_length == 
> 64 is wired into IPv6 protocols and code.
> 
> I would have thought that an end user requiring more than 
> 2^8-1 number of links, with room for 2^64 number of hosts 
> each, would have to "talk" to his ISP anyway...
> 
> >>> p.s. Personally I think that allocating 64 bits to an 
> interface identifier, and wiring that into the v6 
> architecture, were very shortsighted.  I think there will be 
> a number of important cases where sites will need to subnet 
> past /64.  I'm also one of those people who wishes that the 
> IPng people had tried harder to find a way to make variable 
> length addresses work.  But those are water under the bridge.
> >> 
> >> indeed. technically it is little problem changing (already 
> works with DHCPv6). but, this is largely politically 
> motivated. design IPv6 so that end-users get at least a /64 
> and aren't forced to do NAT.
> > 
> > One person's "political motivations" are another person's 
> "making the net work well" and another person's "business need".
> 
> indeed.
> 
> in any case I don't think the fact that 6to4 guarantees a /48 
> (but with patchy connectivity ;-)), justifies that mechanism 
> with all its shortcomings over IPv6 access (6rd or native) 
> which may give the user a /56. or whatever the SP decides for 
> its default, vanilla service. (I would much rather have 
> multi-homing than larger than /56 in my home).
> 
> cheers,
> Ole
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Feb 2011 12:36:02 -0500

> That's not clever, that's an ugly hack we certainly want to avoid.

This is one case where I don't understand how such mechanisms would adversely impact anyone, as long as it weren't done on too large a scale at any particular site.

Keith

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 14 Feb 2011 19:50:30 +0100

On Mon, Feb 14, 2011 at 12:36:02PM -0500, Keith Moore wrote:
> This is one case where I don't understand how such mechanisms would
> adversely impact anyone,

Try to explain the average customer support agent how to diagnose and
troubleshoot those kind of setups.

ARP is hard. IPv6 ND is much harder. Proxy-ND: good luck.

Best regards,
Daniel

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Feb 2011 13:53:17 -0500

> ARP is hard. IPv6 ND is much harder. Proxy-ND: good luck.

I'm assuming that there would be products explicitly designed to support that, whether by bridging or proxy ND or whatever.  Certainly agree that it's difficult to set up those things with ordinary routers.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Feb 2011 09:42:33 +1300

> service to people 'NOT' being their customer.

Actually that's not right. Most operators will gain from making 6to4
work better, even if they have no direct subscribers using it. See
draft-carpenter-v6ops-6to4-teredo-advisory for details.

And this remains true as long as some subscribers are using it,
regardless of whether the IETF deprecates RFC 3068.

   Brian

---

From: Rémi Després <[email-masked]>
Date: Tue, 15 Feb 2011 17:52:47 +0100

> I was aware that an ISP could give the user a /56 using 6rd.  Not as good as a /48, of course, but way better than a /64.

And a /64 is way better than no ISP-provided IPv6 prefix.
As a user, I am glad to know that I now have in my home office a prefix shorter than the /64 I initially had, but this hasn't changed in anything my user experience.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 15 Feb 2011 18:09:40 +0100

> 
> 
> p.s. Personally I think that allocating 64 bits to an interface identifier, and wiring that into the v6 architecture, were very shortsighted.  

> I think there will be a number of important cases where sites will need to subnet past /64.  

I agree that permitting link prefixes longer than /64 opens a number of useful opportunities, in particular to avoid the use of NATs in IPv6, and thus preserve e2e address transparency.
There are various ways to permit such long prefixes without sacrificing backward compatibility, but this is another story.
IMHO, priority is to accelerate a generalized deployment of native IPv6 addresses.

Regards,
RD

> I'm also one of those people who wishes that the IPng people had tried harder to find a way to make variable length addresses work.  But those are water under the bridge.
>