Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"

From: james woodyatt <[email-masked]>
Date: Sun, 01 May 2011 15:06:09 -0700

On Apr 27, 2011, at 1:17 PM, Fred Baker wrote:

>> -------------------
>>  - Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should
>>    not published in its current form because it sets no standard for network operations without 6to4.
>>    A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft.
>> 
>> Action: None.

Having failed to persuade anyone that a phaseout plan is necessary for this draft to be meaningful, I have refined my position on this point.

I could support this draft if it were amended to make an explicit statement that operators are REQUIRED to route the 2002::/16 prefix and protocol 41 on the 192.88.99/24 prefixes to/from the default free zone so long as IPv4 remains in widespread use.  Operating 6to4 relays is RECOMMENDED.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 May 2011 10:32:41 +1200

On 2011-05-02 10:06, james woodyatt wrote:
>>> ------------------- - Now that we have an official WGLC,
>>> I'm going to repeat what I wrote in a previous thread:
>>> this draft should not published in its current form
>>> because it sets no standard for network operations
>>> without 6to4. A phaseout plan for RFC 3056 and RFC 3068
>>> would be required before I could drop my objections to
>>> this draft.
>>> 
>>> Action: None.
> 
> Having failed to persuade anyone that a phaseout plan is
> necessary for this draft to be meaningful, I have refined my
> position on this point.
> 
> I could support this draft if it were amended to make an
> explicit statement that operators are REQUIRED to route the
> 2002::/16 prefix and protocol 41 on the 192.88.99/24 prefixes
> to/from the default free zone so long as IPv4 remains in
> widespread use.  

Please no.

The advice is much more subtle than that and depends on which
operator and what their objective is. Since I wrote a whole
draft about it, I will stop there.

> Operating 6to4 relays is RECOMMENDED.

Again, it's more subtle than that, depending on the operator.

   Brian

> 
> 
> -- james woodyatt <[email-masked]> member of technical staff,
> core os networking
> 
> 
> 
> _______________________________________________ v6ops mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: james woodyatt <[email-masked]>
Date: Sun, 01 May 2011 17:51:24 -0700

On May 1, 2011, at 3:32 PM, Brian E Carpenter wrote:
> 
> Since I wrote a whole draft about it, I will stop there.

I would be very happy with just that whole other draft.  It's *this* draft that I'm all spun up about.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 2 May 2011 09:13:25 -0700

On Sun, May 1, 2011 at 3:06 PM, james woodyatt <[email-masked]> wrote:

> Having failed to persuade anyone that a phaseout plan is necessary for this
> draft to be meaningful, I have refined my position on this point.
>

I like the idea of a phase-out plan, but what form would it take? Requesting
that IANA declare 2002::/16 to be reserved? Saying that implementations
should not use 2002::/16 to autoconfigure addresses?

---

From: Erik Kline <[email-masked]>
Date: Tue, 3 May 2011 01:18:17 +0900

Can we take this two separate steps:

    [1] Move it to historic in this doc.

    [2] Propose a phase-out plan, timeline, and other mechanics in a
2nd follow-on doc (which will obviously refer to #1).

Reasonable?

On 3 May 2011 01:13, Lorenzo Colitti <[email-masked]> wrote:
>> Having failed to persuade anyone that a phaseout plan is necessary for
>> this draft to be meaningful, I have refined my position on this point.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Mon, 02 May 2011 09:57:41 -0700

On May 2, 2011, at 9:13 AM, Lorenzo Colitti wrote:
> I like the idea of a phase-out plan, but what form would it take? Requesting that IANA declare 2002::/16 to be reserved? Saying that implementations should not use 2002::/16 to autoconfigure addresses?

As an outline, I would like to see at least *all* of the following requirements in any standards action for this purpose:

+ A specific date, soon, e.g. this November, on which operators are REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes in their respective default free zones.  I can imagine a tweak that directs ICANN (or something like that) to operate the distinguished autonomous system for those prefixes that returns ICMP and ICMPv6 errors for packets sent into the default free zones with those destinations.

+ An amendment to IPv6 node requirements to say that hosts MUST NOT use stateless autoconfiguration to self-assign interface addresses with 2002::/16 prefixes, i.e. when processing router advertisements with prefix information options that have A=1 and contain prefixes in the 2002::/16 range, the A bit MUST be ignored and the prefix treated as if A=0.

+ A revision to <http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis> to specify that routers MUST NOT advertise prefixes in the 2002::/16 range, with A=1, even when delegated with DHCPv6 prefix delegation.

+ A revision to <http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis> to specify that routers MUST NOT forward any packets with IPv4 protocol 41 with an inner IPv6 header containing a 2002::/16 address to or from the WAN interface.  Replies with ICMP error RECOMMENDED.

That seems like a good start to me.  Can you think of any additional requirements?

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 May 2011 10:19:38 -0700

> 2nd follow-on doc (which will obviously refer to #1).

I think it is very reasonable. I personally question the wisdom of a documented phase-out plan, for the reasons Brian has mentioned. But in any event, I would like to decouple that question from the more basic question addressed in this document, which is the fundamental trajectory of the technology. Since there are demonstrated issues with 6to4, and the industry is moving out of the experimental phase it was designed for into a full deployment phase, this document says "let's consider 6to4 an evolutionary dead end". That statement we seem to generally agree with, modulo Keith and Jordi. 

I would encourage James, if he wants to take that route, to propose a phase-out plan in a separate document.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 02 May 2011 13:46:01 -0400

> + A specific date, soon, e.g. this November, on which operators are
>  REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes
>  in their respective default free zones.

Please save your breath. This sort of a mandate is way out-of-scope
for the IETF. Really!

Operators will do what they want. We have to *persuade* them to do
things via compelling arguments. The IETF is not, and has never been,
the protocol police.

> + An amendment to IPv6 node requirements to say that hosts MUST NOT
>  use stateless autoconfiguration to self-assign interface addresses
>  with 2002::/16 prefixes, i.e. when processing router advertisements
>  with prefix information options that have A=1 and contain prefixes
>  in the 2002::/16 range, the A bit MUST be ignored and the prefix
>  treated as if A=0.

This would take years before it actually resulted in a meaningful
fraction of nodes supporting this behavior. Waste of time. And, I'd be
opposed to special-casing that prefix in generic IPv6 host/node,
especially since they today do not have to do *anything* special with
that prefix to start with.

> + A revision to
>  <http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis>
>  to specify that routers MUST NOT forward any packets with IPv4
>  protocol 41 with an inner IPv6 header containing a 2002::/16
>  address to or from the WAN interface.  Replies with ICMP error
>  RECOMMENDED.

So, every router will now be required to inspect the inner contents of
tunneled packets they are forwarding in order to find these rogue
packets? Will never happen. Way too big of a performance hit. Good
example of a "wishful thinking" requirement.

Me thinks you are being way too draconian and unrealistic in what is
achievable in practice.

Thomas

---

From: Wes Beebee <[email-masked]>
Date: Mon, 02 May 2011 17:35:53 -0400

> example of a "wishful thinking" requirement.

And they already implement a full stateful firewall capable of supporting a
multitude of ALG's that inspect every packet already.  This requirement is
not really that much of a performance hog compared to a firewall.

- Wes

---

From: Thomas Narten <[email-masked]>
Date: Mon, 02 May 2011 17:42:49 -0400

> not really that much of a performance hog compared to a firewall.

Huh? Every single router, including those in the DFZ/core are
firewalls inspecting every packet? And of course doing this at line
rates...

News to me.... :-)

Thomas

---

From: Graham Beneke <[email-masked]>
Date: Mon, 02 May 2011 23:43:05 +0200

> + A specific date, soon, e.g. this November, on which operators are REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes in their respective default free zones.  I can imagine a twe…

While I accept that there are grave concerns about 6to4, I feel that 
completely scrapping it leaves us with the following problem: How to 
IPv4-only hosts reach IPv6-only content?

'IPv6-only' has up to now only been something that I've seen discussed 
in experimental environments but with the APNIC address pool exhaustion 
it is quickly becoming a reality. If we remove 6to4 from the protocol 
bouquet then what do we point users to with this predicament?

-- 
Graham Beneke

---

From: james woodyatt <[email-masked]>
Date: Mon, 02 May 2011 14:47:51 -0700

I see what you did there.  The original context of this idea was this:

>> + A revision to <http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis> to specify that routers MUST NOT forward...

Did the ambit of that document expand to include DFZ/core routers while I wasn't paying attention?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 May 2011 09:55:06 +1200

+1

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 May 2011 09:58:52 +1200

> not really that much of a performance hog compared to a firewall.

Sure, but you don't put firewalls on 40Gb lines, which is what "every router"
includes.

Enterprise firewalls are already capable of stopping IPv6-in-IPv4 tunnels
of any kind. There's little point in adding cruft for this elsewhere,
since it would damage at least as many users as it would help.

As Fred said - let's just stop debating this until there is a draft
to debate.

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Mon, 02 May 2011 18:02:25 -0400

> >>     to specify that routers MUST NOT forward...

>  while I wasn't paying attention?

Ah, my bad. Sorry 'bout that.

You are scoping the MUST NOT to just the CPE routers. That's more
bearable. (Maybe.)

But I'm not sure why you want to do that.

I.e., why would CPEs be *forwarding* such packets? Aren't they the
6to4 Border Routers that participate in the encap/decap of 6to4? I.e,
so if you want to stop them from doing Bad Things w.r.t. to 6to4,
isn't the key thing that they shouldn't enable it by default?

If they are *forwarding* such packets, the problem is elsewhere, not
on the CPE.

Thomas

---

From: Martin Millnert <[email-masked]>
Date: Mon, 02 May 2011 18:17:56 -0400

Graham,

> bouquet then what do we point users to with this predicament?

I think part of the rationale for removing unsuccessful v4->v6
transition mechanisms is an idea that it will increase market demand for
proper native IPv6.

Having that said, there are a few best-effort tunnel-providers out
there.

Cheers,
Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 May 2011 10:19:24 +1200

> If they are *forwarding* such packets, the problem is elsewhere, not

Or there is no problem at all because they are successfully using 6to4.

This whole phase-out discussion fails to take account of the fact that
according to the published measurements, at least 80% of connections
using 6to4 are successful. We have every reason to try to get rid of
the 20% that fail, but we have no reason and no right to damage the
successful use.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 May 2011 10:29:23 +1200

I'm sorry to repeat myself, but...

The advice is much more subtle than that and depends on which
operator and what their objective is. In any case, the concept of
the DFZ is so fuzzy that I have no idea what such a practice would
mean.

What operators should do (now, not in November) is verify that if
they are accepting routes to 2002::/16 and 192.88.99.0/24, those
routes lead to working relays. If not, they should reject those
routes. Actually, they should have been doing this for ever.

> + An amendment to IPv6 node requirements to say that hosts MUST NOT use stateless autoconfiguration to self-assign interface addresses with 2002::/16 prefixes, i.e. when processing router advertise…

That would be totally wrong because it would break successful use of 6to4.
It is not the IETF's job to break stuff.

> + A revision to <http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis> to specify that routers MUST NOT advertise prefixes in the 2002::/16 range, with A=1, even when delegated with DHCP…

Equally wrong for the same reason.

> + A revision to <http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis> to specify that routers MUST NOT forward any packets with IPv4 protocol 41 with an inner IPv6 header containing a 2…

Equally wrong for the same reason.

   Brian

---

From: "John Mann (ITS)" <[email-masked]>
Date: Tue, 3 May 2011 09:05:52 +1000

Hi,

On 3 May 2011 07:43, Graham Beneke <[email-masked]> wrote:

>> REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes in
>> their respective default free zones.  I can imagine a tweak that directs
>> ICANN (or something like that) to operate the distinguished autonomous
>> system for those prefixes that returns ICMP and ICMPv6 errors for packets
>> sent into the default free zones with those destinations.
>
>
I am for deprecating IPv6, but am against breaking it where it is working.

> 'IPv6-only' has up to now only been something that I've seen discussed in
> experimental environments but with the APNIC address pool exhaustion it is
> quickly becoming a reality. If we remove 6to4 from the protocol bouquet then
> what do we point users to with this predicament?
>

I think the key messages in our advice to IPv4-only users should be
- don't use un-managed tunnels, and
- "no IPv6" is better than "flaky IPv6".

For example recommend:
If they are within an enterprise, use ISATAP or VPN.
If they have a lone/roaming device, use Teredo.
If they want a /64 or /48 for redistribution, use a tunnel broker, or get
their ISP to support 6rd.

I acknowledge that my suggestions above aren't things that a user can just
configure in isolation, like they can just tick "enable 6to4 gateway",
but I think that raising the bar is a small and necessary price to pay for a
more-reliable IPv6 service.

And once users/admins have spent some time/money/effort for a working but
not optimal tunneled IPv6 service, they may be prepared to do a little bit
more for a native service.

Thanks,
    John

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 May 2011 10:34:20 +1000

I actually thinks declaring 6to4 historic is way too early and that
6to4 traffic is yet to peak.  Most of the current problems with
6to4 are really minor annoyances that will be corrected as more
IPv6 services become available.

There are very few cases where when you are connecting to a dual
stack service you won't fall back eventually to IPv4 and any client
that does not fallback is not RFC 1123 compliant.

We are yet to see any significant amounts of IPv6 only services.
When these start to appear in reasonable numbers then IPv6 connectivity
will be required and in many cases the only viable solution will
be to deploy 6to4 and it will be deployed properly as people will
have a incentive to test it.

If we don't want this to occur we need to encourage alternate
deployment of alternate solutions.  We need to get 6rd added to the
OS's and CPE devices that currently support 6to4 as part of their
maintenance programs.  Yes, this has development costs associated
with it that will not be recovered but in many cases this will just
be a back port of what is added to the new products so only it ends
up only being the porting costs.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Graham Beneke <[email-masked]>
Date: Tue, 03 May 2011 07:51:24 +0200

Martin,

> transition mechanisms is an idea that it will increase market demand for

I would argue the opposite. The use of a transition mechanism makes the 
path to native IPv6 far less daunting.

> Having that said, there are a few best-effort tunnel-providers out

There are. I would say that I have had (on average) the same amount of 
pain and suffering using tunnel brokers as I have had with 6to4 tunnels. 
I think that I have used all the major ones and there have been sign-up 
problems, technical challenges and broken infrastructure at some stage 
with all of them.

-- 
Graham Beneke
[email-masked]   | Apolix Internet Services
Tel : +27-87-550-1010 | http://www.apolix.co.za/
Cell: +27-82-432-1873 | PO Box 1120
Skype: grbeneke       | Melville, 2109

---

From: Graham Beneke <[email-masked]>
Date: Tue, 03 May 2011 08:05:04 +0200

> IPv6 services become available.

I agree. The failure rates are far to high but this is an operational 
issue. IPv6 has for a long time been considered the bastard child of the 
Internet and been ignored as both a native and a tunnelled protocol.

We are yet to see the critical mass. When this happens there will be 
'real customers' shouting real loud at a NOC near you to get these 
things fixed. In much the same way they do when they can reach their 
favourite IPv4 service.

> have a incentive to test it.

When the next important cloud based business application arrives as IPv6 
only, we are not going to see people patiently waiting for their 
provider to roll out native IPv6.

-- 
Graham Beneke

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 May 2011 16:41:46 +1000

> problems, technical challenges and broken infrastructure at some stage 

But none of these are automatically established.  The problem isn't
so much with 6to4, which works fine once you get it working.  The
problem is equipement using 6to4 without explictly being told to
use it.

Mark

---

From: Philip Homburg <[email-masked]>
Date: Tue, 03 May 2011 09:54:29 +0200

>provider to roll out native IPv6.

There are a couple of alternatives you may want to consider:
- Teredo. This has the advantage that it runs over UDP and actively probes
  NAT. The disadvantages of anycast routing are still there. And it seems to
  be as unreliable as 6to4. But it is essentially a drop-in replacement for
  6to4. 
- Alternatively, there is 6rd. Works a lot like 6to4 but doesn't rely on
  anycast addresses and doesn't need global IPv4 address, so it much more
  compatible with carrier grade NAT. 6rd has be provided by your ISP, but
  I guess that by the time IPv6 becomes essential, all ISPs will do some
  kind of IPv6.

And of course, you can get tunnels from HE or SIXXS now.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 May 2011 10:07:31 +0200

> what do we point users to with this predicament?

I don't think this is a concern.

First, there is no real problem to solve at the moment. Before reachability
to IPv6-only hosts can become a problem, IPv6 deployment needs to be well on
its way, and as long as 6to4 is around we can't get IPv6 deployment well on
its way.

Second, even when it becomes a problem to solve, 6to4 is not an useful
solution, given that it simply fails 10-20% of the time.

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 3 May 2011 10:22:02 +0200 (CEST)

>  be as unreliable as 6to4. But it is essentially a drop-in replacement for

According to the analysis of Geoff Huston Teredo is stranger and similarly 
unreliable protocol to 6to4:

http://labs.ripe.net/Members/gih/testing-teredo

while in 6to4 you can attribute the most of failure to 41 protocol 
filtering and broken routing, in Teredo you cannot distinguish broken 
NATs, filtering, or broken implementation.

I agree with Geoff Huston: Teredo must be off by default. If someone want 
to experiement  he or she will switch on.

>  I guess that by the time IPv6 becomes essential, all ISPs will do some

6rd is basically a 6to4 relying on a IPv4 autotunnel with a ISP managed 
IPv4 infrastructure. Not much difference. The key advantage is here, that 
ISP is taking care of the tunnel.

I think that providing services with carrier grade NAT will not be easy: 
Will you put in your service aggremeent, that your user can not use your 
favourite private address space used in CGN e.g. 10.0.0.0/8? If you 
customer is using same portion of this address, will you assist 
renumbering their network? Why not assist to deploy IPv6?

Biggest problem of 6rd deployment however, lack of widespread 6rd 
implementation in CPEs. Much less implemenetation than 6to4.

> And of course, you can get tunnels from HE or SIXXS now.

Yes, the managed tunnels is the most reliable approach.
 	Best Regards,
 			Janos Mohacsi

---

From: Philip Homburg <[email-masked]>
Date: Tue, 03 May 2011 11:53:38 +0200

>to experiement  he or she will switch on.

An unmanaged protocol that is essentially unused, no wonder it doesn't work.

But yes, making sure it is turned off by default is important.

>ISP is taking care of the tunnel.

I think that is a very important difference. Certainly when the CPE is also
provided by the ISP, there is a much greater chance that it will actually work.

>renumbering their network? Why not assist to deploy IPv6?

Most setups I have seen in recent years default to 192.168.0.0/16. Assuming
CGN will be used for new connections, then the ISP will have no problems
telling customers to just avoid 10.0.0.0/8 or get a modem that can handle
this. I guess that if the customer uses 10.a.b.0/24 and the ISP advertises
provides the customer with 10.x.y.z/24 then it should not be hard for the modem
to keep those ranges apart.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 3 May 2011 12:01:46 +0200

Hi,

> But yes, making sure it is turned off by default is important.

I don't really like Teredo, but: why? The end-node uses Teredo only when it is IPv4-only and it needs to reach an IPv6-only destination. Without Teredo it will certainly not work. With Teredo enabled it might work. It's not perfect, but better than certain failure...

> provided by the ISP, there is a much greater chance that it will actually work.

Usually the ISP offers this as a service, and will make sure it works. Their support center will suffer otherwise, which costs money :)

- Sander

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 3 May 2011 12:18:45 +0200 (CEST)

> provided by the ISP, there is a much greater chance that it will actually work.

In the actual 6rd deployments yes. But it should be designed to be 
universal - where users will buy the CPEs. I see only one vendor claiming 
to support 6rd, but they working on it and actually will be rather 
unversal:

http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011

> this.

192.168.0.0/16 used mostly only in off the shelf SOHO routers for home 
users. But CGN is not only for these customers, but enterprise customers 
also: Most of the enterprise users I meet using at least two of RFC 1918 
address space  - two address sapce for two purpose...

> I guess that if the customer uses 10.a.b.0/24 and the ISP advertises

Uh!ohh! Are your really able to keep up to date thousands of such an 
address space? Good luck!
 		Best Regards,
 			Janos Mohacsi

---

From: Philip Homburg <[email-masked]>
Date: Tue, 03 May 2011 12:57:34 +0200

In your letter dated Tue, 3 May 2011 12:01:46 +0200 you wrote:
>I don't really like Teredo, but: why? The end-node uses Teredo only when =
>it is IPv4-only and it needs to reach an IPv6-only destination. Without =
>Teredo it will certainly not work. With Teredo enabled it might work. =
>It's not perfect, but better than certain failure...

Is it that simple? There are lots of protocols that embed IP addresses. 
For example, peer to peer or sip. Do you want to patch all software to avoid
teredo addresses? 

The Internet is complex enough, and with CGN and IPv6 it only gets way more
complex. If you also tunneling protocols often don't work, then it may just
become an unmanagable chaos.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 03 May 2011 13:16:44 +0200

>address space  - two address sapce for two purpose...

In most markets, enterprise customers pay enough that you can pay somebody
to figure out the best solution. I don't think there is any technical
limitation why you would not be able to NAT between two identical netblocks.
Alternatively, there are many other netblocks that can be hijacked if you
make sure the fact that you do it doesn't leak out.

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 May 2011 13:20:25 +0200

I take the latest discussions in the 6to4-historic threads to indicate that there are no further comments on the revision-02
text?

cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Tue, 3 May 2011 14:19:56 +0200

Hi,

> For example, peer to peer or sip. Do you want to patch all software to avoid

So: if a protocol embeds an IPv6 address and you don't have Teredo then the address will be useless and the protocol won't work for certain... If you use name/DNS based references then the OS shouldn't use Teredo as long as there is another way to connect.

If Teredo/Miredo is deployed/implemented in a different way then I agree with you: that will cause more harm than it's worth...
Sander

---

From: Wes Beebee <[email-masked]>
Date: Tue, 03 May 2011 08:30:46 -0400

> firewalls inspecting every packet? And of course doing this at line

I was under the impression that this was a *CPE router* requirement...

- Wes

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 3 May 2011 13:46:16 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Graham Beneke
Sent: Monday, May 02, 2011 5:43 PM
To: [email-masked]
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"

While I accept that there are grave concerns about 6to4, I feel that completely scrapping it leaves us with the following problem:
How to IPv4-only hosts reach IPv6-only content?
____________
[WEG] Perhaps I'm being overly literal in my interpretation of your comment, but I hope that you realize that 6to4 is not a method
to interwork IPv4-only *hosts* and IPv6-only *hosts*. An IPv4-only host by definition cannot even use 6to4. 6to4 is simply a way to
tunnel IPv6 traffic from an IPv6-capable (usually dual-stack) host across some amount of IPv4 only *network* elements to another
IPv6-capable host. It's a transition technology, but it's for transitioning your transport, not your applications. 

'IPv6-only' has up to now only been something that I've seen discussed in experimental environments but with the APNIC address pool
exhaustion it is quickly becoming a reality. If we remove 6to4 from the protocol bouquet then what do we point users to with this
predicament?
____________
[WEG] well, at first, the onus is going to be on those who have IPv6-only networks/hosts to put in the proper app layer
gateway/translation devices (such as NAT64) if they want their IPv6-only stuff to be able to talk to IPv4. At some point, enough of
the planet is dual-stack, then it switches and the gateway moves to sit in front of the pockets of IPv4-only devices still
remaining.

Wes George

---

From: Gert Doering <[email-masked]>
Date: Tue, 3 May 2011 16:20:35 +0200

Hi,

> IPv4-only hosts reach IPv6-only content?

Have you seen any IPv6-only content recently?

Seriously: content will need to be available on IPv4 for a very long time,
so I don't expect to see IPv6-only content in the next years.

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: Graham Beneke <[email-masked]>
Date: Tue, 03 May 2011 16:33:19 +0200

> the planet is dual-stack, then it switches and the gateway moves to sit in front of the pockets of IPv4-only devices still

NAT64 only provides a mechanism for clients on IPv6-only clouds to 
connect to services on IPv4-only clouds. It does not provide translation 
in the other direction.

v6 aware/v4 connected clients need a way of reaching the IPv6-only 
services when these become more prevalent.

-- 
Graham Beneke

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 May 2011 16:34:27 +0200

On Mon, May 2, 2011 at 7:19 PM, Fred Baker <[email-masked]> wrote:

> I think it is very reasonable. I personally question the wisdom of a
> documented phase-out plan, for the reasons Brian has mentioned.
>

How about changing "existing implementations and deployments MAY continue to
use 6to4" from MAY to something that says "SHOULD not"?

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 3 May 2011 17:12:52 +0200

> I don't really like Teredo, but: why? The end-node uses Teredo only
when it is IPv4-only and it needs to reach an
> IPv6-only destination. Without Teredo it will certainly not work. With
Teredo enabled it might work. It's not 
> perfect, but better than certain failure...

I think from an individual home-user that may be what one wants and
could be acceptable, however if I am an Enterprise IT manager, that is
not what I want as I do not want to see tunneled traffic that bypasses
my firewall.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sander Steffann
Sent: 03 May 2011 03:02
To: Philip Homburg
Cc: [email-masked]
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"

Hi,

> But yes, making sure it is turned off by default is important.

I don't really like Teredo, but: why? The end-node uses Teredo only when
it is IPv4-only and it needs to reach an IPv6-only destination. Without
Teredo it will certainly not work. With Teredo enabled it might work.
It's not perfect, but better than certain failure...

> provided by the ISP, there is a much greater chance that it will
actually work.

Usually the ISP offers this as a service, and will make sure it works.
Their support center will suffer otherwise, which costs money :)

- Sander

---

From: james woodyatt <[email-masked]>
Date: Tue, 03 May 2011 10:09:50 -0700

On May 2, 2011, at 17:34 , Mark Andrews wrote:
> 
> I actually think declaring 6to4 historic is way too early and that 6to4 traffic is yet to peak.

For the record, I believe this too.

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 3 May 2011 21:13:44 +0200

> Please save your breath. This sort of a mandate is way out-of-scope

For reference, that's the lingo used in RFC3701 (6bone phase-out):

   Thus after the 6bone phaseout date June 6, 2006, it is the intent
   that no 6bone 3FFE prefixes, of any size/length, be used on the
   Internet in any form.  Network operators may filter 3FFE prefixes on
   their borders to ensure these prefixes are not misused.

Best regards,
Daniel

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

---

From: "John Mann (ITS)" <[email-masked]>
Date: Wed, 4 May 2011 11:41:00 +1000

Hi,

> not what I want as I do not want to see tunneled traffic that bypasses

So, if you had an user on an IPv4-only subnet trying to get to an IPv6-only
destination,
you would dictate that they not get there v. use a lowest-preference Teredo
tunnel.

An Enterprise IT Manager can prevent tunneled Teredo traffic bypassing the
firewall by
- blocking Teredo UDP port 3544 at the firewall, or
- pushing a AD Group Policy to disable Teredo (and other tunnel things), or
- enabling native IPv6 inside the enterprise so clients prefer that instead
of Teredo
- ? run a Teredo relay inside the enterprise to de-encapsulate Teredo ?

If you want to stop all tunnels, then
- block UDP 500, protocol 51(IPSEC)
- discover and block other VPN protocols
- discover and block other wormholes like IP-over-DNS
- block HTTPS to stop Microsoft DirectAccess and SSL VPNs ;-) ;-)

Some tunnels are _designed_ to work around NAT or firewalls.
Some are easier to block than others. Security v. Convenience v. Cost.

    John

---

From: Martin Millnert <[email-masked]>
Date: Tue, 03 May 2011 22:40:13 -0400

(Ole - ack on discussion having left point 4 - phase out plan a while
ago.)

John,

On Wed, 2011-05-04 at 11:41 +1000, John Mann (ITS) wrote:

> An Enterprise IT Manager can prevent tunneled Teredo traffic bypassing
> the firewall by
Managed Teredo tunnels can be pointed at servers using a different port
- but relays will remain a bit arbitrary, ie depending on which one you
happen to use for a specific connection. Relays, too, can run on other
ports.

> - pushing a AD Group Policy to disable Teredo (and other tunnel
I can imagine this would work (don't know AD Group Policies).

> - enabling native IPv6 inside the enterprise so clients prefer that
> instead of Teredo
Yes, this would definitely work.

> - ? run a Teredo relay inside the enterprise to de-encapsulate
Not very effective - Teredo connections in modes of operations involving
relays "land" on the relay closest to the non-Teredo address endpoint of
the v6 connection (ie, follow the path from this end-point towards
2001:0::/32, and where that leads the connection will land).

Regards,
Martin

---

From: Sander Steffann <[email-masked]>
Date: Wed, 4 May 2011 07:45:26 +0200

Hi,

> - pushing a AD Group Policy to disable Teredo (and other tunnel things), or

You don't even need to do this. Teredo is automatically disabled in a managed/AD environment. 

-Sander

---

From: Torbjörn Eklöv <[email-masked]>
Date: Wed, 4 May 2011 10:27:21 +0000

Hi, my first post to this list.
Teredo is not turned on if a Windows Vista/7 is connected to an enterprise network. If a Windows Vista/7 who is in a managed/AD environment for example is connected to a home network Teredo is enabled if an application want's to use it. 
And some good examples is torrent programs or Microsoft Direct Access so It's a good idea to disable it with GPO.

Mvh, Torbjörn Eklöv
Interlan Gefle AB
mobil: 070 - 683 51 75
http://test-ipv6.se
- Did you enable IPv6 on something today?

> -----Ursprungligt meddelande-----
> Från: [email-masked] [mailto:[email-masked]] För Sander
> Steffann
> Skickat: den 4 maj 2011 07:45
> Till: John Mann (ITS)
> Kopia: [email-masked]
> Ämne: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
> 
> Hi,
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 May 2011 08:31:17 -0400

>    their borders to ensure these prefixes are not misused.

I disagree.

The quoted text does not say "MUST NOT advertise ...". Rather, it
says, "it is the intent". Very different words.

Also, the 6bone example is not a good analogy, IMO. The 6bone was
created as an temporary experiment of sorts to get around the problem
that RIRs were not allocating IPv6 addresses. Once that problem got
fixed, sites were expected to transition over to using proper IPv6
prefixes -- the need for continuing to operate the 6bone was
gone. There was no deprecation of "technology" or deprecating
"brokenness".

Thomas

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 5 May 2011 02:21:50 +0200

> says, "it is the intent". Very different words.

Thomas, I wasn't trying to disprove your point at all. I was just
throwing the verbiage used in another phase-out IETF publication into
the discussion. "additional data point". :-)

Best regards,
Daniel

---

From: "Williams, Marcus (Contractor)" <[email-masked]>
Date: Thu, 5 May 2011 08:25:49 -0500

> Of Thomas Narten
> Sent: Wednesday, May 04, 2011 8:31 AM
> To: [email-masked]

> gone. There was no deprecation of "technology" or deprecating

There was in fact brokeness caused by 6bone.  Operators filtered 6bone 3FFE routes while a v6 exchange continued to use it for peering.   Those v6 routers at the exchange would send PMTU sourced in 3ffe . . .   This sort of focused shakeout improves the integrity of v6 instead of allowing problems to fester.

Marcus Williams

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 May 2011 10:39:12 +1000

In message <[email-masked]>, "W
illiams, Marcus (Contractor)" writes:
> There was in fact brokeness caused by 6bone.  Operators filtered 6bone 3FFE r
> outes while a v6 exchange continued to use it for peering.   Those v6 routers
>  at the exchange would send PMTU sourced in 3ffe . . .   This sort of focused
>  shakeout improves the integrity of v6 instead of allowing problems to fester
> .

Most of the 6to4 problems would go away if the 6to4 CPE routers
did dead router detection.  6rd already has a description of how
to do this in its specification.

Mark

---

From: George Michaelson <[email-masked]>
Date: Fri, 6 May 2011 10:45:55 +1000

> to do this in its specification.

I want to repeat my take on something Alain Durand said to me in RIPE Tallin a few years back.

Any investment in the IPv4 stack inside CPE has consequences for the supply chain dynamics facing IPv6. Asking for codework on IPv4 causes massive delay to work on IPv6. It takes months to alter supply chain dynamics, and you really really want to know this, if you think something you are doing is a 'good idea' because the law of unintended consequences is going to come into effect.

[this was in the context of the 240/4 draft I was involved in]

So Mark: do you think suggesting CPE developers make changes in 6rd, 6to4 and other tunnelling methods is good investment of their time, facing other choices in their IP stack? If you did this, what would you be prepared to see delayed in the native IPv6 stack?

Because for me, I think fixing the various issues around DHCPv6, the L2 bindings into the ADSL and Cable technology, making better choices around subnet masking, use of privacy mode addresses, etc all might take a higher priority than a 6to4 fix.

-G

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 May 2011 11:24:07 +1000

In message <[email-masked]>, George Michaelson 
writes:
> Any investment in the IPv4 stack inside CPE has consequences for the supply c
> hain dynamics facing IPv6. Asking for codework on IPv4 causes massive delay t
> o work on IPv6. It takes months to alter supply chain dynamics, and you reall
> y really want to know this, if you think something you are doing is a 'good i
> dea' because the law of unintended consequences is going to come into effect.
> 
> So Mark: do you think suggesting CPE developers make changes in 6rd, 6to4 and
> other tunnelling methods is good investment of their time, facing other choi
> ces in their IP stack? If you did this, what would you be prepared to see del
> ayed in the native IPv6 stack?

Yes.  6rd already requires dead router detection.  Adding it to
6to4 would put it on the same level.  The router would send back
ICMPv6 unreachables to internal clients which helps everyone.

It also only requires CPE code changes so there is no co-ordination
required.

It could have been implemented many times over in the amount of time
we have discussed 6to4-historic.

> Because for me, I think fixing the various issues around DHCPv6, the L2 bindi
> ngs into the ADSL and Cable technology, making better choices around subnet m
> asking, use of privacy mode addresses, etc all might take a higher priority t
> han a 6to4 fix.
> 
> -G
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 May 2011 03:27:11 +0200

> ICMPv6 unreachables to internal clients which helps everyone.

No, it doesn't help Windows (it ignores them) and only marginally helps mac.

> It also only requires CPE code changes so there is no co-ordination

Upgrading the code on any significant fraction of CPEs that have been sold
and are now in users' homes is not realistic. Better to do it in the hosts,
which have better upgrade mechanisms.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 May 2011 11:52:12 +1000

In message <[email-masked]>, Lorenzo Colitt
> No, it doesn't help Windows (it ignores them) and only marginally helps mac.

So Windows is broken.  Complain to Microsoft who do have a working
update program.  Apple also has a working update program.
 
> and are now in users' homes is not realistic.

Only because people WILL NOT TRY to do it.  People used to say the
same thing about Windows.  We now have a community that are used
to having their equipement updated to fix problems, whether it is
their PC, phone, printer, Kindle ....  The update processes do work.
They are NOT too hard for the average user.  You just have to tell
them they need to do it.

> Better to do it in the hosts, which have better upgrade mechanisms.

And a lot of the problem 6to4 CPE routers are *hosts* with ICS enabled.
Put dead router detection on them.
 
Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 May 2011 08:25:15 +0200

> update program.  Apple also has a working update program.

Nope, ICMP unreachables are soft errors.

> They are NOT too hard for the average user.  You just have to tell

Sure. So a vendor who licensed some code five years ago from a third-party
manufacturer that maybe no longer exists needs to see a business case to
reopen the code base for a product that's not shipping any more, spend
engineering cycles to fix it, and release it. And users need to hear about
it, download it, and upgrade it successfully. Good luck with that.

> Put dead router detection on them.

Yes, it needs to be in the host. But dead router detection? Why? That's like
saying "I'm going to enable this service that is unreliable and
high-latency, but it's OK, because if it happens not to work (in the only
direction) I can measure I'm going to disable again". Why enable it in the
first place then?

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 May 2011 10:08:52 +0200

Mark,

[...]

> ICMPv6 unreachables to internal clients which helps everyone.

incorrect.

> we have discussed 6to4-historic.

but it wouldn't have solved 'the problem'.

from the draft, I leave it as an exercise for the reader to figure out which ones would be resolved by adding forward relay liveness detection on the 6to4 router / host.

   List of some of the known issues with 6to4:

   o  Use of relays. 6to4 depends on an unknown third- party to operate
      the relays between the 6to4 cloud and the native IPv6 Internet.
   o  The placement of the relay can lead to increased latency, and in
      the case the relay is overloaded packet loss.
   o  There is generally no customer relationship or even a way for the
      end-user to know who the relay operator is, so no support is
      possible.
   o  In case of the reverse path 6to4 relay and the anycast forward
      6to4 relay, these have to be open for any address.  Only limited
      by the scope of the routing advertisement. 6to4 relays can be used
      to anonymize traffic and inject attacks into IPv6 that are very
      difficult to trace.
   o  6to4 may black hole traffic in the case where protocol (41) is
      blocked in intermediate firewalls.  Even if a firewall sent an
      ICMP message unreachable back, an IPv4 ICMP message rarely
      contains enough of the original IPv6 packet so that it can be
      relayed back to the IPv6 sender.  That makes this problem hard to
      detect and react upon by the sender of the packet.
   o  As 6to4 tunnels across the Internet, the IPv4 addresses used must
      be globally reachable.  RFC3056 states that a private address
      [RFC1918] MUST NOT be used. 6to4 will not work in networks that
      employ other addresses with limited topological span.

cheers,
Ole

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 6 May 2011 08:32:29 -0700

> Yes, it needs to be in the host. But dead router detection? Why? That's
like saying "I'm going to enable this service that is unreliable and
high-latency, but it's OK, because if it happens not to work (in the only
direction) I can measure I'm going to disable again". Why enable it in the
first place then?

Agreed.  It's yet another layer of duct tape. I really wish we can move on
and leave 6to4 behind.

At the end of the day 6to4 cannot succeed without the service providers
running relays .... and there is no business case for that since there is no
v6only content.

Cb