Subject: [v6ops] [Fwd: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Feb 2011 16:41:53 +1300

Hi,

This may be of interest. It's incomplete pending a co-author contribution
due soon, but there has been quite a bit of off-list discussion so
I though it was time to post the rough draft.

    Brian

-------- Original Message --------
Subject: I-D Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt
Date: Wed, 02 Feb 2011 19:30:01 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Advisory Guidelines for 6to4 and Teredo Deployment
	Author(s)       : B. Carpenter
	Filename        : draft-carpenter-v6ops-6to4-teredo-advisory-00.txt
	Pages           : 16
	Date            : 2011-02-02

This document provides advice to network operators about deployment
of two techniques for automatic tunneling of IPv6 over IPv4, namely
6to4 and Teredo.  It is principally addressed to Internet Service
Providers, including those that do not yet support IPv6, and to
Content Providers.  The intention of the advice is to minimise both
user dissatisfaction and help desk calls.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-6to4-teredo-advisory-00.txt

---

From: Ole Troan <[email-masked]>
Date: Thu, 3 Feb 2011 15:12:10 +0100

Brian,

> I though it was time to post the rough draft.

excellent draft and good recommendations.

do you only want recommendations to operators or also to vendors?
e.g. I would have liked:

 - 6to4 MUST not be enabled by default
 - 6to4 SHOULD use a periodic reachability test to the relay similar to what is specified in RFC5969
 - 6to4/Teredo MUST by default be at the least preferred option in SAS/DAS selection policy. i.e. prefer NATed IPv4 over 6to4/Teredo

 - for networks that want to stop 6to4/Teredo traffic. a captive portal could be used to make users aware that they are using Teredo/6to4 and be given instructions for how to turn it off.

cheers,
Ole

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

---

From: Sander Steffann <[email-masked]>
Date: Thu, 3 Feb 2011 15:36:38 +0100

Hi,

> - for networks that want to stop 6to4/Teredo traffic. a captive portal could be used to make users aware that they are using Teredo/6to4 and be given instructions for how to turn it off.

I agree with these suggestions. It would be good to include them.

Thanks,
Sander

---

From: Jack Bates <[email-masked]>
Date: Thu, 03 Feb 2011 09:51:22 -0600

>>  - 6to4 SHOULD use a periodic reachability test to the relay similar to what is specified in RFC5969

Wouldn't these be reversed? If you mandate a reachability test to make 
sure the 6to4 is valid, there's no problem with it enabled by default.

Jack

---

From: Sander Steffann <[email-masked]>
Date: Thu, 3 Feb 2011 16:54:35 +0100

Hi,

> Wouldn't these be reversed? If you mandate a reachability test to make sure the 6to4 is valid, there's no problem with it enabled by default.

I think not. I think enabling 6to4 should be a conscious decision. After enabling 6to4 it should still be monitored to avoid problems at a later time. So I think both suggestions are good.

- Sander

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Feb 2011 08:02:08 -0800

Brian,

> Two techniques for automatic tunneling of IPv6 over IPv4, intended
> for situations where a user may wish to access IPv6-based services
> via a network that does not support IPv6, were defined a number of
> years ago.  They are known as 6to4 [RFC3056], [RFC3068] and Teredo
> [RFC4380].

For completion, shouldn't this also list ISATAP?

Thanks - Fred
[email-masked]   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian E Carpenter
> Sent: Wednesday, February 02, 2011 7:42 PM
> To: IPv6 Operations
> Subject: [v6ops] [Fwd: 
> I-DAction:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt]
> 
> Hi,
> 
> 	Filename        : 
> draft-carpenter-v6ops-6to4-teredo-advisory-00.txt
> 	Pages           : 16
> 	Date            : 2011-02-02
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 3 Feb 2011 17:06:55 +0100

Fred,

> For completion, shouldn't this also list ISATAP?

you don't want to be with this crowd. ;-)

seriously ISATAP is another class of tunnel, intra-site and managed (even though that has lots of deployment issues too).

the issue this draft addresses is how to deal with tunnels going across the Internet, between if not non-consenting then unaware adults, depending on the charity of unknown entities relaying packets for you...

cheers,
Ole

---

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

On 2/3/2011 9:54 AM, Sander Steffann wrote:
> I think not. I think enabling 6to4 should be a conscious decision.
> After enabling 6to4 it should still be monitored to avoid problems at
> a later time. So I think both suggestions are good.
>

I think the problem is the advisory is pointed to ISPs, yet the enabled 
status of 6to4 is an end-host or CPE criteria.

However, from a CPE or end-host criteria, 6to4 enabled by default should 
be fine, so long as it is monitored. In most policies, it is only used 
in 2 conditions

1) We received an AAAA 6to4 address, so we use 6to4 based on prefix 
(there should be no problems with this as long as the 6to4 network isn't 
behind NAT, which most systems properly detect this).

2) There was no A record, and 6to4 is the only available mechanism to 
reach the AAAA address.

Most policies have to be changed for 6to4 to depend on anycast with the 
exception of #2, and if 6to4 is the only transport to reach the end 
node, it doesn't matter that we broke it.

Jack

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Feb 2011 11:20:29 -0500

> I think not. I think enabling 6to4 should be a conscious decision. After enabling 6to4 it should still be monitored to avoid problems at a later time. So I think both suggestions are good.

I don't see why enabling 6to4 should be any more of a conscious decision than enabling IPv4.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Feb 2011 08:26:05 -0800

> you don't want to be with this crowd. ;-)

Just checking... :^}

Fred 

> From: Ole Troan [mailto:[email-masked]] On Behalf Of 
> Ole Troan
> Sent: Thursday, February 03, 2011 8:07 AM
> To: Templin, Fred L
> Cc: Brian E Carpenter; IPv6 Operations
> Subject: Re: [v6ops] [Fwd: 
> seriously ISATAP is another class of tunnel, intra-site and 
> managed (even though that has lots of deployment issues too).
> 
> the issue this draft addresses is how to deal with tunnels 
> going across the Internet, between if not non-consenting then 
> unaware adults, depending on the charity of unknown entities 
> relaying packets for you...
> 
> cheers,
> Ole

---

From: Gert Doering <[email-masked]>
Date: Thu, 3 Feb 2011 17:36:03 +0100

Hi,

> I don't see why enabling 6to4 should be any more of a conscious decision than enabling IPv4.

Because it does even more not work than IPv4.

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: John Gammons <[email-masked]>
Date: Thu, 3 Feb 2011 12:27:47 -0500

> I don't see why enabling 6to4 should be any more of a conscious decision than enabling IPv4.

Agreed.  While I see both sides of this argument, from a CPE/Residential Gateway perspective, I think IPv6 should be enabled by default.  Attempting native IPv6, and falling back to 6to4, before giving up (surprisingly similar to the way Microsoft has handled this one).  At this stage of the game, some level of IPv6 connectivity is arguably a requirement.  While not perfect, I think the argument can be made that problematic V6 connectivity, is better than none.  

Expecting end-users to turn it on, only further escalates the broken-ness.  Given the complexity of the architecture and being able to accurately weigh the benefits and disadvantages it provides, is extremely difficult for the end-user, which will more often then not, mean they "won't mess with that setting", shutting themselves out of V6 land all together... 

If it is enabled by default in the CPEs, then it will only further the requirements of all operators and content providers to do their part to ensure it's effectiveness, thereby making it less broken, which is the fundamental purpose of this draft.  

Excellent work on this draft btw, very useful to the community....

John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Feb 2011 11:40:07 +1300

> do you only want recommendations to operators or also to vendors?

My thought was to focus this on operators, in the hope that they
might actually read it, if we can push it out through the various
operator forums ASAP.

But of course I agree that there should be clear recommendations
to stack implementers and vendors - that seems to need a bit
of convergence on the 3484bis and happy-eyeballs discussions,
though. How about a separate draft?

   Brian

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 3 Feb 2011 23:48:29 +0100

Hi,

> might actually read it, if we can push it out through the various

I haven't had time to toroughly review it, but crossreading it, it is a
very useful document on many (all?) the gotchas involved.

Thanks from an operator. :-)

> to stack implementers and vendors

Agreed. And we operators need such stuff _quickly_ to have references to
point CPE vendors to how to un-suck their implementations properly,
quickly.

> >  - 6to4/Teredo MUST by default be at the least preferred option in SAS/DAS selection policy. i.e. prefer NATed IPv4 over 6to4/Teredo

Agreed on all of those.

Best regards,
Daniel

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

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 03 Feb 2011 23:43:50 -0500

On 03/02/11 12:27 PM, "John Gammons" <[email-masked]> wrote:

>>>> Wouldn't these be reversed? If you mandate a reachability test to
>>>>make sure the 6to4 is valid, there's no problem with it enabled by
>>>>default.
>>> 
>>>After enabling 6to4 it should still be monitored to avoid problems at a
>>>later time. So I think both suggestions are good.
>> 
>Agreed.  While I see both sides of this argument, from a CPE/Residential
>Gateway perspective, I think IPv6 should be enabled by default.
>Attempting native IPv6, and falling back to 6to4, before giving up
>(surprisingly similar to the way Microsoft has handled this one).  At
>this stage of the game, some level of IPv6 connectivity is arguably a
>requirement.  While not perfect, I think the argument can be made that
>problematic V6 connectivity, is better than none.
>
>Expecting end-users to turn it on, only further escalates the
>broken-ness.  Given the complexity of the architecture and being able to
>accurately weigh the benefits and disadvantages it provides, is extremely
>difficult for the end-user, which will more often then not, mean they
>"won't mess with that setting", shutting themselves out of V6 land all
>together... 
>
>If it is enabled by default in the CPEs, then it will only further the
>requirements of all operators and content providers to do their part to
>ensure it's effectiveness, thereby making it less broken, which is the
>fundamental purpose of this draft.
>

I would agree with John.  Expecting users to turn anything on (at mass) is
like not having it at all.  Most of my customers use default everything.

The suggestion of attempting Native IPv6 followed by 6to4 (perhaps you can
put in 6RD ahead of this if it is possible in a specific network) is a
reasonable approach.  No IPv6 in this new world is not better some IPv6
(some may argue the performance is bad a times).  If the address selection
works correctly, then the customer will at least be able to get to an IPv6
endpoint if required.

As for our network, 6to4 works reasonably well.  In our characterization
and lab work, 6to4 is the least of our concerns.  It's the Native IPv6
code in CPEs that is causing us most of the issues.

>From an operator standpoint I think the following makes perfect sense:
- Try Native IPv6
- if that fails, managed tunnel
- if that fails 6to4 (anycast)
- if that fails IPv4 only

Regards,

Victor K

---

From: Jack Bates <[email-masked]>
Date: Fri, 04 Feb 2011 08:54:42 -0600

> - Try Native IPv6

This is provisioning. If we get it on connection, a standard policy 
should allow this anytime an AAAA is present, even when an A exists.

> - if that fails, managed tunnel

This follows with above. I presume the managed tunnel is something 
special a provider did for their own CPEs.

> - if that fails 6to4 (anycast)

If 6to4 is active, standard policy (at least in windows world, and it 
works well)

1) If we have RFC-1918, 6to4 is deactivated, as it won't work through 
NAT. This will still be a concern with an ISP due to CGN, though there 
are cases where provider side may not be RFC-1918 and this may be an 
issue. I would hope that a provider deploying CGN has other mechanisms 
so that 6to4 isn't used. This is mitigated by below (ie, only 2 will 
break where IPv4 would succeed and most content publishers don't use 
6to4 AAAA addresses)

2) 6to4 -> 6to4 goes direct when AAAA is present, even with an A exists

3) 6to4 -> anycast is used ONLY when an A record doesn't exist.

> - if that fails IPv4 only

6to4 generally won't have an IPv4 backup, though the others will.

Jack

---

From: Rémi Després <[email-masked]>
Date: Fri, 4 Feb 2011 17:12:37 +0100

Le 3 févr. 2011 à 18:27, John Gammons a écrit :

>>> ... I think enabling 6to4 should be a conscious decision.

+1

>>> After enabling 6to4 it should still be monitored to avoid problems at a later time. So I think both suggestions are good.
>> 

(I assume Keith meant enabling "IPv6".)

In my understanding, reasons to limit default IPv6 enablement to native IPv6 addresses (and exclude in it 6to4 addresses) are precisely what this draft-carpenter explains:
- Connections from a 6to4 address to a native IPv6 address may fail, and DO FAIL in a number of configurations where there is no return path.
- Connections from a native IPv6 address to another native IPv6 address don't have the same intrinsic problem. (And this applies including to IPv6 addresses obtained across configured or 6rd tunnels).
 
Thus, as long as there are hosts that don't handle 6to4 addresses differently from native IPv6 addresses, CPEs should better avoid enabling 6to4 by default, and should at least make it easy to disable it.

> Agreed.  While I see both sides of this argument, from a CPE/Residential Gateway perspective, I think IPv6 should be enabled by default.  Attempting native IPv6, and falling back to 6to4, before gi…

Quite different view here:
- Problematic IPv6 leads to bad user experience, and leads to IPv6 being completely turned off.
- No such problem exists with good quality IPv6 (one that provides additional connectivity to users that need it, and that never replaces a working IPv4 connectivity by a failing on in IPv6. 

Happy eyeballs is an approach to mitigate consequences of failing IPv6 connectivity, but its support in all hosts shouldn't be assumed to be available for quite some time.

> Excellent work on this draft btw, very useful to the community....

Agreed.

Regards,
RD

---

From: Jack Bates <[email-masked]>
Date: Fri, 04 Feb 2011 10:51:56 -0600

On 2/4/2011 10:12 AM, Rémi Després wrote:
> In my understanding, reasons to limit default IPv6 enablement to
> native IPv6 addresses (and exclude in it 6to4 addresses) are
> precisely what this draft-carpenter explains: - Connections from a
> 6to4 address to a native IPv6 address may fail, and DO FAIL in a
> number of configurations where there is no return path. - Connections
> from a native IPv6 address to another native IPv6 address don't have
> the same intrinsic problem. (And this applies including to IPv6
> addresses obtained across configured or 6rd tunnels).
>

If there is no native IPv6, 6to4 would need to be enabled (which users 
won't do manually) to get any connectivity to IPv6.

Default windows policy (and should be default for all 6to4) is that the 
ONLY time 6to4 over-rides IPv4 is to reach another 6to4 address 
(advertised in an AAAA). IPv4 has precedence over using 6to4 in all 
other cases (unless the policy is manually changed).

However, having 6to4 enabled does allow the device to reach an IPv6 only 
host.

> Thus, as long as there are hosts that don't handle 6to4 addresses
> differently from native IPv6 addresses, CPEs should better avoid
> enabling 6to4 by default, and should at least make it easy to disable
> it.
>

They should always be handled differently. That is what should be fixed 
if it is broken.

Jack

---

From: Rémi Després <[email-masked]>
Date: Fri, 4 Feb 2011 18:40:55 +0100

Le 4 févr. 2011 à 17:51, Jack Bates a écrit :

> If there is no native IPv6, 6to4 would need to be enabled (which users won't do manually) to get any connectivity to IPv6.
> 
> Default windows policy (and should be default for all 6to4) is that the ONLY time 6to4 over-rides IPv4 is to reach another 6to4 address (advertised in an AAAA). IPv4 has precedence over using 6to4 in all other cases (unless the policy is manually changed).

I agree that this is the right policy because it makes sure 6to4 relays are never used where IPv4 remains available.
(Today, IPv4 generally remains available, be it with NATs and hole-punching technologies for incoming connectivities.)

> However, having 6to4 enabled does allow the device to reach an IPv6 only host.

Some IPv6-only hosts, yes, but not all those that have native IPv6 addresses without having also IPv6 addresses.
That's where the brokenness comes, and IMHO should be avoided.

I don't know how many servers are accessible ONLY in IPv6, and ONLY at native IPv6 addresses (i.e. without having also 6to4 addresses).
But this is a configuration I wouldn't recommend for any server that has to be reachable also from 6to4 addresses.

> They should always be handled differently. That is what should be fixed if it is broken.

Yes.
Until it is fixed, though, it remains safer that CPEs activate IPv6 by default only if their IPv6 prefixes are native (natively routed or with 6rd).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 4 Feb 2011 18:41:26 +0100

Le 4 févr. 2011 à 17:20, Keith Moore a écrit :

> 
> On Feb 4, 2011, at 11:12 AM, Rémi Després wrote:
>> 
>>>> ...I don't see why enabling 6to4 should be any more of a conscious decision than enabling IPv4.
>> 
> No, actually I meant enabling 6to4.

6to4 ... more ... than ... IPv4? (as you wrote)
OR 6 
6to4 ... more ... than ... IPv6? (as I interpreted)

>  IMO, 6to4 should be enabled by default on every host that has IPv4 connectivity and public address space.  
> 
> However I'm all for hosts having heuristics that avoid using 6to4 source addresses to contact non-6to4 addresses if the anycast relay (or other relay router) or return path is nonexistent or broken.

The point is that, as long as these "heuristics" aren't generalized, 6to4 causes diverse IPv6 brokenness that are detrimental to IPv6 in general.

Regards,
RD

---

From: Jack Bates <[email-masked]>
Date: Fri, 04 Feb 2011 11:58:41 -0600

On 2/4/2011 11:40 AM, Rémi Després wrote:
> Some IPv6-only hosts, yes, but not all those that have native IPv6
> addresses without having also IPv6 addresses. That's where the
> brokenness comes, and IMHO should be avoided.
>
> I don't know how many servers are accessible ONLY in IPv6, and ONLY
> at native IPv6 addresses (i.e. without having also 6to4 addresses).
> But this is a configuration I wouldn't recommend for any server that
> has to be reachable also from 6to4 addresses.
>

If it's IPv6 only, it won't have a 6to4 address (otherwise it could be 
reachable via IPv4). It is HIGHLY recommended that no content sites 
should advertise 6to4 addressing. That said, it is highly recommended 
that an IPv4 content site support 6to4 that isn't advertised. The reason 
is that if a host uses 6to4 anycast to reach a native address 
(overriding the proper policy), the server can actually reply directly 
through the 6to4 interface.

> Yes. Until it is fixed, though, it remains safer that CPEs activate
> IPv6 by default only if their IPv6 prefixes are native (natively
> routed or with 6rd).

Except that this will break all IPv6 connectivity. If they can change 
the code to be disabled, they should be able to change it to just 
operate with the appropriate policy. I agree that it is better to 
deactivate the 6to4 *IF* a CPE isn't going to use a policy.

Jack

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Feb 2011 12:33:04 -0500

I suppose I should add that having a host prefer either native v6 or 6to4 over native v4 should probably be dependent on reachability.  If there's no v6 routing to external networks, or no effective 6to4 relay router, and there is routing to public v4 then the host should probably prefer v4 to a nonlocal v6 address.  But that's not the same thing as disabling v6 or 6to4.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Feb 2011 11:20:32 -0500

> (I assume Keith meant enabling "IPv6".)

No, actually I meant enabling 6to4.  IMO, 6to4 should be enabled by default on every host that has IPv4 connectivity and public address space.  

Keith

---

From: Tore Anderson <[email-masked]>
Date: Fri, 04 Feb 2011 19:57:40 +0100

* Keith Moore

> However I'm all for hosts having heuristics that avoid using 6to4
> source addresses to contact non-6to4 addresses if the anycast relay
> (or other relay router) or return path is nonexistent or broken.

6to4 isn't very harmful when terminated on hosts that do proper source
address selection and use it as a last resort towards dual-stacked
destinations. An example of this is how it's done in Microsoft Windows.
(However, it has still caused problems with applications that don't use
the OS-provided resolver interfaces, e.g., the Opera web browser.)

The trouble start once you start *sharing* the 6to4 connectivity to
other nodes on the network, such as implementing it in CPEs, «Internet
Sharing»-type functionality on hosts, or similar. Those 6to4 routers
cannot know whether or not the other nodes on the network are capable of
doing proper source address selection. There are plenty that aren't.
Therefore, 6to4 should *not* be enabled by default in any box that take
on the role of a router - it makes the IPv6 end user experience suck.

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

---

From: John Gammons <[email-masked]>
Date: Fri, 4 Feb 2011 13:59:47 -0500

>> has to be reachable also from 6to4 addresses.

I agree, wherever possible IPv6 ONLY at the server level should be avoided, but with IPv4 exhaustion approaching, this COULD (and arguably will) become necessary for some content providers.  This is why I feel it is necessary to have 6to4 as a fallback connectivity option that is enabled by "default" (with proper policies).

The future will most likely result in more divergence of the two protocols, supporting both legacy IPv4 only hosts/devices and native IPv6 only content and desiring interconnectivity (6to4 when other options aren't available) between the two.... well that's my prediction at least.... and from a CPE perspective (again - provided proper policy is in place), to have 6to4 enabled when all else fails, seems logical and arguably a feature end-users should be entitled to without knowledge of what "6to4" is.  

>> 
> 
> If it's IPv6 only, it won't have a 6to4 address (otherwise it could be reachable via IPv4). It is HIGHLY recommended that no content sites should advertise 6to4 addressing. That said, it is highly recommended that an IPv4 content site support 6to4 that isn't advertised. The reason is that if a host uses 6to4 anycast to reach a native address (overriding the proper policy), the server can actually reply directly through the 6to4 interface.

> Except that this will break all IPv6 connectivity. If they can change the code to be disabled, they should be able to change it to just operate with the appropriate policy. I agree that it is better to deactivate the 6to4 *IF* a CPE isn't going to use a policy.
> 

+1

John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 05 Feb 2011 08:41:19 +1300

This discussion shows exactly why I scoped the draft *not* to include
advice on host behaviour. As long as I'm editing it, I want to focus
on advice to operators. Host behaviour is something done *to*
operators, not *by* operators.

If somebody else wants to write a draft that advises on host behaviour,
go for it, but you'll have to make sense of this discussion, which has been
going for years.

Regards
   Brian

---

From: Jack Bates <[email-masked]>
Date: Fri, 04 Feb 2011 15:23:05 -0600

Yeah, sorry. I did mention in one reply that it was out of scope. :)

I do believe that server operators should support 6to4 on all servers 
that are dual stacked, but should never advertise a 6to4 prefix in DNS. 
This allows them to reply to 6to4 that comes in via native IPv6 directly 
and not rely on another gateway to drop it into 6to4.

This also may be slightly out of scope of your draft.

Jack

---

From: Sander Steffann <[email-masked]>
Date: Fri, 4 Feb 2011 23:50:51 +0100

> I do believe that server operators should support 6to4 on all servers that are dual stacked, but should never advertise a 6to4 prefix in DNS. This allows them to reply to 6to4 that comes in via native IPv6 directly and not rely on another gateway to drop it into 6to4.

Good advise. I would still recommend ISPs to provide a reliable 6to4 relay in case hosts don't do this though.

But you probably already understood that :)
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 05 Feb 2011 11:53:51 +1300

> This also may be slightly out of scope of your draft.

Actually, no, we have that in as advice to content providers.

   Brian

>>> I agree, wherever possible IPv6 ONLY at the server level should be
>>> avoided, but with IPv4 exhaustion approaching, this COULD (and
>>> arguably will) become necessary for some content providers.  This is
>>> why I feel it is necessary to have 6to4 as a fallback connectivity
>>> option that is enabled by "default" (with proper policies).
>>>
>>> The future will most likely result in more divergence of the two
>>> protocols, supporting both legacy IPv4 only hosts/devices and native
>>> IPv6 only content and desiring interconnectivity (6to4 when other
>>> options aren't available) between the two.... well that's my
>>> prediction at least.... and from a CPE perspective (again - provided
>>> proper policy is in place), to have 6to4 enabled when all else fails,
>>> seems logical and arguably a feature end-users should be entitled to
>>> without knowledge of what "6to4" is.
>>>
>>>> If it's IPv6 only, it won't have a 6to4 address (otherwise it could
>>>> be reachable via IPv4). It is HIGHLY recommended that no content
>>>> sites should advertise 6to4 addressing. That said, it is highly
>>>> recommended that an IPv4 content site support 6to4 that isn't
>>>> advertised. The reason is that if a host uses 6to4 anycast to reach
>>>> a native address (overriding the proper policy), the server can
>>>> actually reply directly through the 6to4 interface.
>>>
>>>> Except that this will break all IPv6 connectivity. If they can
>>>> change the code to be disabled, they should be able to change it to
>>>> just operate with the appropriate policy. I agree that it is better
>>>> to deactivate the 6to4 *IF* a CPE isn't going to use a policy.
>>>>
>>>
>>> +1
>>>
>>>> Jack
>>>
>>> John
>>>

---

From: Jack Bates <[email-masked]>
Date: Fri, 04 Feb 2011 20:01:24 -0600

> Good advise. I would still recommend ISPs to provide a reliable 6to4 relay in case hosts don't do this though.

As an ISP, we deployed 6to4 relays years ago, not because we wanted to 
fix IPv6 connectivity per se, but because there was a 6to4 relay being 
announced in BGP and it's IPv6 connectivity sucked. It's wise to have 
the IPv6 anycast (which is actually what many ISPs forget to do and 
breaks replies) and to have the IPv4 anycast (to keep packets from 
finding their way to broken IPv6 networks).

I've been swamped and have to reread the draft, but I think it covered 
both cases.

Jack

---

From: Rémi Després <[email-masked]>
Date: Mon, 7 Feb 2011 09:31:49 +0100

Hello Jack,

This is indeed an interesting discussion.
I hope we can converge.

Le 4 févr. 2011 à 18:58, Jack Bates a écrit :

> If it's IPv6 only, it won't have a 6to4 address (otherwise it could be reachable via IPv4).

This statement isn't completely right because a server having a 6to4 address can be unreachable in IPv4.
Let's take a server that has both:
- a private IPv4 address (the CPE has a NAT44)
- a 6to4 address (the CPE has a public IPv4 address from which it derives a 6to4 prefix)
This server is reachable in IPv6 at its 6to4 address, but isn't reachable in IPv4 because of the NAT. 

Now, in a site that has both a native IPv6 prefix and a 6to4 prefix (in the same CPE or in separate CPEs), each of its servers can have both a native IPv6 address and a 6to4 address.
Then, address-selection rules of RFC 3484 are such that:
- Its native address will be used with native-address clients.
- Its 6to4 address will be used by 6to4-address clients. 
(A client whose only IPv6 address is 6to4 chooses the 6to4 server address because, according to Rule 5 of RFC 3484, it has the same  "label" as the client's in the RFC-3484 policy table.)

Thus, a server that advertises a native IPv6 address AND an 6to4 address becomes reachable by 6to4 clients even if they have no access to 6to4 relays. 
Reachability is thus increased, and I haven't found any adverse effect.
Do you see any?

> It is HIGHLY recommended that no content sites should advertise 6to4 addressing.

Agreed that a server shouldn't advertise a 6to4 address as SOLE IPv6 address.
But, as explained above, advertising a 6to4 address IN ADDITION to a native IPv6 addresses is useful to increase reachability.

> That said, it is highly recommended that an IPv4 content site support 6to4

Agreed...

> that isn't advertised.

Agreed only partially, see above.

>> ... it remains safer that CPEs activate IPv6 by default only if their IPv6 prefixes are native (natively routed or with 6rd).
> 
> Except that this will break all IPv6 connectivity.

I didn't understand what you mean by breaking ALL IPv6 connectivity.
(IPv6 connectivity between NATIVE addresses can't be broken by requesting that 6to4 be enabled in CPEs only by a conscious decision.)

> If they can change the code to be disabled, they should be able to change it to just operate with the appropriate policy. I agree that it is better to deactivate the 6to4 *IF* a CPE isn't going to use a policy.

Agreed.

In any case, all of this will become history when native IPv6 availability is generalized (natively routed or with 6rd).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 7 Feb 2011 14:49:01 +0100

> Actually, no, we have that in as advice to content providers.

In my understanding:
- The advice in the draft is that content-provider ISPs, and possibly servers themselves, have 6to4 "relay" functions.
- What Jack suggests is that servers themselves:
  . have 6to4 "router" functions (an therefore their own 6to4 addresses);
  . don't advertise these 6to4 addresses
- A better combination, in a server that has both a public IPv4 address and a native IPv6 address, is that:
  . The server  has the 6to4 "router function" 
  . In IPv6, both the native and the 6to4 addresses are advertised.
An explanation is given in  my last answer to Jack.

If this is wrong, I look forward to explanations why.
If this is right, something could advantageously added to your section 2.3.4 (IMHO).

Regards,
RD

---

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

> This server is reachable in IPv6 at its 6to4 address, but isn't reachable in IPv4 because of the NAT.
In this particular scenario, advertising a 6to4 address increases 
reachability; as it doesn't require the client to have an anycast 6to4 
relay to get to the native IPv6 address; ie, it will keep some 6to4 
clients from breaking.

> But, as explained above, advertising a 6to4 address IN ADDITION to a native IPv6 addresses is useful to increase reachability.
Only if the server isn't advertising an IPv4 address. This is why, 
traditionally, 6to4 advertisements are usually private servers served 
out of homes behind NAT routers.

> Agreed only partially, see above.
Here you should agree fully. It's an IPv4 content site. If it's 
reachable via IPv4, it should NOT have a 6to4 address advertised at this 
point. Advertising 6to4 is likely to cause more breaks than the IPv4 
advertisement.

> (IPv6 connectivity between NATIVE addresses can't be broken by requesting that 6to4 be enabled in CPEs only by a conscious decision.)
Lack of native connectivity or 6rd would leave the CPE with no IPv6 
connectivity if 6to4 is disabled. In the case of IPv6 only sites, there 
is no way to reach them.

> In any case, all of this will become history when native IPv6 availability is generalized (natively routed or with 6rd).

Possibly, unless the ISP is expecting 6to4 instead of 6rd. As an 
engineer that manages 11 telco networks with diverse topologies, I've 
broken things down into general sets.

1) Serving Native IPv6 where all equipment supports it (a majority of 
them, luckily)

2) Serving 6rd where IPv6 is not compatible AND IPv4 is used in policy 
decisions (until the traffic shapers support v6, in other words). 
Alternatively, we may create static tunnels as we consider 6rd somewhat 
wasteful.

3) PPPoE areas are strictly native period.

4) Depend on 6to4 in all areas that haven't transitioned.

5) No IPv6 support on dialups. They'll now get to use the proxy servers 
for IPv6 connectivity in addition to the compress support (so called 
dialup acceleration). This is subject to change, as we may create a 
single upgraded pool and pseudowire the T1s from each telco over mpls to 
combine the entire set of dialup customers.

Jack

---

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

> An explanation is given in  my last answer to Jack.

I'd argue that,

- All servers with IPv6 connectivity have the 6to4 "router function"
- If server advertises a IPv4 addresses, do NOT advertise 6to4 addresses
- if server does not advertise IPv4, DO advertise 6to4 address

Summary of my explanation:
- If IPv4 connectivity is available, clients need to use it and not 6to4 
addresses
- If IPv4 is not available, clients should use 6to4 direct over anycasting.

I'm still unsure on this last one, but I'm reasonably sure that anything 
which would break direct 6to4 connectivity will break using anycasting 
as well (unless some NAT66 took place).

Jack

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 08:19:20 -0600

On 2/7/2011 8:07 AM, Keith Moore wrote:
> It seems to me that servers which support all of (native v6, 6to4, v4) will be more reachable than servers which support only (native v6, v4), because there will be v6-only hosts that sit behind 6to4 routers (each with only an external v4 connection) and those hosts will therefore be assigned a 6to4 address but not a native v6 address.

The problem with your client side layout is that it is very specific.

- If we are referring to a CPE, there is no reason they should not be 
doing IPv4 NAT AND 6to4
- If we are referring to an ISP network layout, the ISP will need to fix 
the network.

The argument/benefit of 6to4 over IPv4 is support for end to end 
connectivity when you have a 6to4 CPE. The problem is that 6to4 often 
breaks (and will break more often with CGN) more than using IPv4. 
Advertising a 6to4 address on a server which supports IPv4 will cause 
more connectivity issues, especially as CGN takes effect.

Jack

---

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

On Feb 7, 2011, at 8:59 AM, Jack Bates wrote:

> - If IPv4 connectivity is available, clients need to use it and not 6to4 addresses
> I'm still unsure on this last one, but I'm reasonably sure that anything which would break direct 6to4 connectivity will break using anycasting as well (unless some NAT66 took place).

Keith

---

From: Rémi Després <[email-masked]>
Date: Mon, 7 Feb 2011 15:33:26 +0100

>> - All servers with IPv6 connectivity have the 6to4 "router function"
Not all of them:
- If they have private IPv4 addresses, they can't have the 6to4 router function.

>> - If server advertises a IPv4 addresses, do NOT advertise 6to4 addresses

See Keith's point below.

>> - if server does not advertise IPv4, DO advertise 6to4 address

Only if a native address is also advertised (otherwise, reachability from hosts whose only IPv6 address is native may have broken connectivity).

> It seems to me that servers which support all of (native v6, 6to4, v4) will be more reachable than servers which support only (native v6, v4), because there will be v6-only hosts that sit behind 6t…

Same understanding.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 7 Feb 2011 15:37:23 +0100

Le 7 févr. 2011 à 15:19, Jack Bates a écrit :

> - If we are referring to a CPE, there is no reason they should not be doing IPv4 NAT AND 6to4
> - If we are referring to an ISP network layout, the ISP will need to fix the network.
> 
> The argument/benefit of 6to4 over IPv4 is support for end to end connectivity when you have a 6to4 CPE.

Agreed.

> The problem is that 6to4 often breaks (and will break more often with CGN) more than using IPv4.

6to4 breaks in case of native IPv6 clients connecting to 6to4 servers, but not between two 6to4 addresses.

> Advertising a 6to4 address on a server which supports IPv4 will cause more connectivity issues, especially as CGN takes effect.

Could you detail more?
AFAIK, traffic from a 6to4 source doesn't go across a CGN.

RD

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 08:37:32 -0600

I'm retracting my argument of 6to4 direct over anycast. See below

> relay to get to the native IPv6 address; ie, it will keep some 6to4

This would work in the short term. In the long run, advertising a 6to4 
in DNS will cause more breakage.

An ISP which supports a 6to4 anycast relay (which should be all of them) 
should have a policy as follows.

- If not performing CGN on IPv4, allow the packet through untouched. The 
server (which should support 6to4 or have guaranteed relay that does) 
can send the packet back direct.

- If performing CGN on IPv4, the 6to4 relay should be prior to CGN and 
NPTv6 should be performed on the relay. This will force the server to 
send the packet back to the native address where it will be translated 
back to the local 6to4 address.

CGN is coming. The providers will be the ones who must make the 6to4 
necessary changes. Servers advertising a 6to4 address in a CGN 
environment will break fixes that providers can deploy (if we want to 
call NPTv6 a fix).

Jack

---

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

> - If we are referring to a CPE, there is no reason they should not be doing IPv4 NAT AND 6to4

Yes, but IPv4 NAT will break applications that 6to4 will not.  Given the choice between a v6 address and a NATted v4 address, the former will often (though not always) work better.  Furthermore if the CPE is provided by an ISP, the ISP can make sure that its relay routers work.

> The argument/benefit of 6to4 over IPv4 is support for end to end connectivity when you have a 6to4 CPE. The problem is that 6to4 often breaks (and will break more often with CGN) more than using IPv4.

That depends on what application you're running.  It's not true in general.

> Advertising a 6to4 address on a server which supports IPv4 will cause more connectivity issues, especially as CGN takes effect.

you appear to be assuming that everything acts like HTTP.

Keith

---

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

> AFAIK, traffic from a 6to4 source doesn't go across a CGN.

6to4 direct to 6to4 will tunnel over IPv4 and not use an ISP relay. CGN 
will break it.

By NOT advertising 6to4 on the server, the 6to4 client is forced to use 
the anycast relay. The provider can then policy it with NPTv6 if the v4 
address is behind CGN. Responses will be returned to the relay natively 
then.

Jack

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 09:48:16 -0500

On Feb 7, 2011, at 9:42 AM, Jack Bates wrote:

> 6to4 direct to 6to4 will tunnel over IPv4 and not use an ISP relay. CGN will break it.
> 
> By NOT advertising 6to4 on the server, the 6to4 client is forced to use the anycast relay. The provider can then policy it with NPTv6 if the v4 address is behind CGN. Responses will be returned to the relay natively then.

I keep seeing this pattern where desperate and technically dubious measures that are employed to keep v4 working, also hamper transition to v6.   This is fundamentally broken.  

The principle requirement that should be imposed of all v4-extension measures is that they provide (or at least, do not inhibit) a clear transition path to v6.

Keith

---

From: Martin Millnert <[email-masked]>
Date: Mon, 07 Feb 2011 09:49:12 -0500

On Fri, 2011-02-04 at 19:57 +0100, Tore Anderson wrote:
> Therefore, 6to4 should *not* be enabled by default in any box that
> take on the role of a router - it makes the IPv6 end user experience
> suck. 

"take on the role of a router != 6to4 relay", I assume. :)

Excellent.  More advice for the other draft, about suggested default
values for automatic v6 tunnels on hosts?

Or should it be merged into this?  The above quite falls between the two
atm.

Regards,
Martin

---

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

On 2/7/2011 8:35 AM, Keith Moore wrote:
> Yes, but IPv4 NAT will break applications that 6to4 will not.  Given
> the choice between a v6 address and a NATted v4 address, the former
> will often (though not always) work better.  Furthermore if the CPE
> is provided by an ISP, the ISP can make sure that its relay routers
> work.
>

I agree, if CGN wasn't going to exist. However, it will be, and I see 
direct 6to4 breaking. The way around this is for 6to4 to be properly 
supported by the ISP (see my other responses)

> That depends on what application you're running.  It's not true in

It's not true in general, yet 6to4 is breaking and one of the reasons 
for this draft. With CGN, I expect 6to4 to break even more as it is not 
NAT friendly. However, NPTv6 at a multicast relay will work perfectly 
fine (though probably isn't much better than CGN on the v4).

Unfortunately, relays aren't used if 6to4 is advertised.

>> Advertising a 6to4 address on a server which supports IPv4 will
>> cause more connectivity issues, especially as CGN takes effect.
>

I'm presuming that CGN will exist and NAT break 6to4. The workarounds 
for basic connectivity for an ISP is to use the ISP relays, but those 
relays only take effect if 6to4 isn't advertised by the server.

There will be a degree of application breakage in an ISP provided NAT 
scenario. 6to4 only connectivity will take the worst of it. 6rd is 
definitely recommended over 6to4 as it doesn't require the NPTv6 on the 
relay when NAT44 is in effect and is guaranteed to use the ISP relays.

Jack

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 08:57:06 -0600

On 2/7/2011 8:48 AM, Keith Moore wrote:
> I keep seeing this pattern where desperate and technically dubious
> measures that are employed to keep v4 working, also hamper transition
> to v6.   This is fundamentally broken.
>

If we are not keeping v4 working, then 6to4 should never be used, as 
there shouldn't be IPv4 connectivity to use it. It is a transition 
technology (and the worst of them, though the most common activated). A 
dual stack server should use IPv4 for it's connectivity over 6to4 
direct. An IPv6 only server should not encourage a client to try and 
reach it direct via 6to4 (let the client anycast so ISP workarounds will 
allow the communication).

> The principle requirement that should be imposed of all v4-extension
> measures is that they provide (or at least, do not inhibit) a clear
> transition path to v6.
>

That is what we are discussing. A fundamental flaw of 6to4 is that if 
the address is advertised in DNS and the client tries to connect 
directly, any NAT in the middle will break it. By not advertising a 6to4 
address, the client will either use anycast 6to4 relays where ISPs can 
NPTv6 to deal with the NAT or use IPv4 direct which is at least acceptable.

Jack

---

From: Martin Millnert <[email-masked]>
Date: Mon, 07 Feb 2011 10:06:55 -0500

On Mon, 2011-02-07 at 09:07 -0500, Keith Moore wrote:
> It seems to me that servers which support all of (native v6, 6to4, v4)
> will be more reachable than servers which support only (native v6,
> v4), because there will be v6-only hosts that sit behind 6to4 routers
> (each with only an external v4 connection) and those hosts will
> therefore be assigned a 6to4 address but not a native v6 address.  

A very favorable configuration here could be the following:
  A ("content") server that has native v6 and v4 will benefit from
sending IPv6-in-IPv4 packets back for connections arriving from
2002::/16.
  Adding some additional application layer glue/clue here, a host with
native IPv6 and IPv4 can consider arriving 6to4-packets to be plain IPv4
when the connection is handed off to the application layer (for those
that roll their own...), with clearly added benefits to the already
IPv4-aware application layer. 
(I've heard "But I don't want to run a 6to4 interface on my servers"
more than once, so, this way you don't have to).

As far as I can see this should be the way forward for "content
servers", which could go a long way of dealing with poor 6to4-relays in
the reverse path by simply ignoring them, and the 6to4 problem becomes
mostly a one-way problem: operator -> content provider, which this draft
addresses.

It furthermore enables operators to, for any content provider using this
method, to be in control of the 6to4 relay they use themselves.

Content providers are clearly interested in minimizing the pain 6to4
causes.   A draft covering the above, in addition to this
pain-minimizing draft for operators, could work together to make the
problem smaller over time, which must be good.

Regards,
Martin

---

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

On Feb 7, 2011, at 9:51 AM, Jack Bates wrote:

> I agree, if CGN wasn't going to exist. However, it will be, and I see direct 6to4 breaking. The way around this is for 6to4 to be properly supported by the ISP (see my other responses)

maybe the way around it is for all ISPs that implement CGN to also implement native v6 via some means.  the people that cause breakage need to assume some responsibility for fixing the breakage.  

> It's not true in general, yet 6to4 is breaking and one of the reasons for this draft. With CGN, I expect 6to4 to break even more as it is not NAT friendly. However, NPTv6 at a multicast relay will work perfectly fine (though probably isn't much better than CGN on the v4).
> 

if CGN breaks 6to4 then that should be mentioned in the advisory document... I don't have time to look right now to be sure, but I don't recall that it was mentioned.

Keith

---

From: Tore Anderson <[email-masked]>
Date: Mon, 07 Feb 2011 16:11:44 +0100

* Rémi Després

> Thus, a server that advertises a native IPv6 address AND an 6to4
> address becomes reachable by 6to4 clients even if they have no access
> to 6to4 relays.

I actually attempted this a while back. It was a disaster and the
brokenness percentage skyrocketed. I don't think any content providers
in their right mind will publish AAAA-records for a 2002::/16 address.

Aben and Huston have both measured a 6to4 fail rate of around 15% - and
that is with relays working fine in both directions! As long as nobody's
using 6to4 except as a last resort, it's not a problem, but the instant
you publish 6to4 AAAAs, you will attract traffic from millions of hosts
in networks that filter proto-41.

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

---

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

> sending IPv6-in-IPv4 packets back for connections arriving from

I can't imagine an interpretation of this that makes any sense at all.   what in the world do you mean?

Keith

---

From: Tore Anderson <[email-masked]>
Date: Mon, 07 Feb 2011 16:17:11 +0100

* Martin Millnert

> "take on the role of a router != 6to4 relay", I assume. :)

No, that's what I meant. Anything that operates as a router, like a CPE,
home gateway, wireless access point, end-user OS with «turn your box
into a router»-type of functionality (e.g. Windows ICS), and so on,
should *not* have 6to4 relay functionality enabled by default.

The only place where 6to4 causes little damage is when terminated on an
end host that doesn't share the 6to4 connectivity in any way, provided
that the host in question also have RFC 3484-compliant system resolvers
or de-prefers 6to4 another way.

Best regards,

---

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

On Feb 7, 2011, at 9:57 AM, Jack Bates wrote:

> If we are not keeping v4 working, then 6to4 should never be used, as there shouldn't be IPv4 connectivity to use it. It is a transition technology (and the worst of them, though the most common activated). A dual stack server should use IPv4 for it's connectivity over 6to4 direct. An IPv6 only server should not encourage a client to try and reach it direct via 6to4 (let the client anycast so ISP workarounds will allow the communication).
> 
> That is what we are discussing. A fundamental flaw of 6to4 is that if the address is advertised in DNS and the client tries to connect directly, any NAT in the middle will break it.

That is not a flaw with 6to4, it's a flaw with the idea that you can put NATs in the middle of the network.  

Keith

---

From: Martin Millnert <[email-masked]>
Date: Mon, 07 Feb 2011 10:29:32 -0500

> should *not* have 6to4 relay functionality enabled by default.

Right, I need to further quality my '6to4 relay'. I meant 6to4 relay as
ISP operated relays.  They quite necessarily need to have "6to4
enabled". :)

Regards,
-- 
Martin Millnert <[email-masked]>

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 09:32:44 -0600

> That is not a flaw with 6to4, it's a flaw with the idea that you can put NATs in the middle of the network.

Then give the ISPs more IPv4 space, please. NAT in the middle will 
happen with IPv4. Guaranteed. The more native IPv6 traffic there is, the 
more IPv4 will be broken.

Connectivity will be broken worse than it is. Anyone who depends on 6to4 
as a transition technology is asking for problems. It CAN work somewhat 
if the ISP relays are used, though in a CGN environment, the relay will 
have to use NPTv6, which will also break IPv6 as much as IPv4 CGN. 
However, some connectivity is better than none.

All ISPs are recommended to deploy native (direct or tunneled), 6rd, or 
any transition mechanism other than 6to4. Advertising 6to4 via AAAA is 
likely to break connectivity to your server.

Jack

---

From: Tore Anderson <[email-masked]>
Date: Mon, 07 Feb 2011 16:34:37 +0100

* Martin Millnert

> ISP operated relays.  They quite necessarily need to have "6to4

My main gripe is the «by default» bit. I'd be equally upset if C or J or
any other ISP-grade router vendor started announcing 2002::/16 or
192.88.99.1/24 into the DFZ without the network admin first needing to
explicitly configure it...  :-)

Best regards,

---

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

On 2/7/2011 9:07 AM, Keith Moore wrote:
>
> maybe the way around it is for all ISPs that implement CGN to also
> implement native v6 via some means.  the people that cause breakage
> need to assume some responsibility for fixing the breakage.
>

6to4 is the transition protocol of least resort. If it's being used, 
things are already in bad shape. Advertising 6to4 is asking for breakage.

> if CGN breaks 6to4 then that should be mentioned in the advisory
> document... I don't have time to look right now to be sure, but I
> don't recall that it was mentioned.

There is no IF. CGN breaks 6to4. It is NAT. 6to4 doesn't work through 
NAT. I'm not even sure an ALG could fix this as there's no reserved bits 
for the ALG to determine which IPv4 customer to send to, thus there 
would have to be some type of v6 NAT state involved.

Jack

---

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

> Then give the ISPs more IPv4 space, please. NAT in the middle will happen with IPv4. Guaranteed. The more native IPv6 traffic there is, the more IPv4 will be broken.
> 
> Connectivity will be broken worse than it is. Anyone who depends on 6to4 as a transition technology is asking for problems. It CAN work somewhat if the ISP relays are used, though in a CGN environment, the relay will have to use NPTv6, which will also break IPv6 as much as IPv4 CGN. However, some connectivity is better than none.
> 
> All ISPs are recommended to deploy native (direct or tunneled), 6rd, or any transition mechanism other than 6to4. Advertising 6to4 via AAAA is likely to break connectivity to your server.

I get what you are saying.  What I'm saying is that IETF cannot afford to keep looking at these mechanisms in isolation from one another.  Nor can it afford to endorse mechanisms that extend the life of v4 at the expense of mechanisms that enable transition to v6.

Keith

---

From: Martin Millnert <[email-masked]>
Date: Mon, 07 Feb 2011 10:39:36 -0500

> I can't imagine an interpretation of this that makes any sense at all.   what in the world do you mean?

Sorry Keith, I'll try again.

First, I was just agreeing that a content server should not send packets
towards 6to4 anycast space.

Then, I tried to explain a possible implementation method for a
dual-stacked content server:

 1) A content server has native IPv6 and IPv4, eg is dual-stacked.
 2) A TCP SYN arrives on its IPv6 interface from 2002::/16 space.
 3) Return packets are sent as IPv6-over-IPv4 to the unicast address
(Brian did note some brokenness here; perhaps it can be helped by using
source address 192.88.99.1?)
 4) When the connection is delivered to the application layer, it is
converted into a IPv4 connection, by decoding the IPv4 address that is
encoded in 2002::/16 as the source address.
 5) From now on, it's just IPv4 for the applications which they should
be fairly familiar with.

Did this make more sense?

Regards,
Martin

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 09:40:51 -0600

On 2/7/2011 9:34 AM, Tore Anderson wrote:
> explicitly configure it...:-)
>

I believe the presumption is that if there is no connectivity other than 
6to4, might as well activate the 6to4 to reach anything not IPv4.

A quick look on my windows box shows no 2002::/16 addressing; only 
native (presumably to keep 2002::/16 advertised networks from taking 
precedence over native IPv6 advertised networks via address selection 
algorithm.

6to4 should never be active when another IPv6 address is available. It 
also should never be used unless IPv6 is the only available mechanism. 
This is why I'm strongly against anyone ever advertising 2002::/16 in DNS.

Jack

---

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

On Feb 7, 2011, at 10:34 AM, Jack Bates wrote:

> 6to4 is the transition protocol of least resort. If it's being used, things are already in bad shape. Advertising 6to4 is asking for breakage.

the breakage is being caused elsewhere; 6to4 is just one of many things that suffer from it.

it's fine to point out that CGN breaks 6to4.   that's another reason that CGN should be discouraged, or at least, not deployed except along with a mechanism for carriage of native v6.

Keith

---

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

> Did this make more sense?

no.  it makes no sense at all to convert a 6to4 connection into an ipv4 connection.

Keith

---

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

On Feb 7, 2011, at 10:40 AM, Jack Bates wrote:

> I believe the presumption is that if there is no connectivity other than 6to4, might as well activate the 6to4 to reach anything not IPv4.
> 
> A quick look on my windows box shows no 2002::/16 addressing; only native (presumably to keep 2002::/16 advertised networks from taking precedence over native IPv6 advertised networks via address selection algorithm.
> 
> 6to4 should never be active when another IPv6 address is available. It also should never be used unless IPv6 is the only available mechanism. This is why I'm strongly against anyone ever advertising 2002::/16 in DNS.

I do this all the time, and it generally works well.  Of course one of the reasons that I do this is because I don't have enough IPv4 addresses to assign to all of my hosts.

That's not to say that I've never seen the problems mentioned in Brian's draft - I'm pretty sure I've seen most of those crop up also.   But in general they have not been a problem for me.

So I think your recommendation against ever advertising a 2002 address in DNS is overbroad.  

And I find it completely unacceptable to use CGN as an excuse to discourage use of 6to4.

Keith

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 10:09:47 -0600

> So I think your recommendation against ever advertising a 2002 address in DNS is overbroad.

If the IETF is going to set a draft with recommendations, the draft 
should take into account the entire picture. ie, servers shouldn't 
advertise 6to4 via AAAA but they should support it or make sure they 
have a 6to4 relay router to handle responses that do come via 6to4. All 
ISPs should support anycast 6to4 addressing to support any clients which 
do not have other IPv6 options available. In addition, cases where the 
provider does provide CGN, NPTv6 can be used on the anycast relay to 
allow it to work with the hidden addressing. Providers are recommended 
to use native or at least a transition mechanism other than 6to4 as 
quickly as possible.

> And I find it completely unacceptable to use CGN as an excuse to discourage use of 6to4.

I'm not discouraging use of 6to4. I'm providing an appropriate scope 
where it is more functional.

Encouraging:

- use of anycast relays by ISPs to support hosts who have no other IPv6 
capability
- support on servers to reply to 6to4 addressing or at least have a 
known relay to handle the conversion.

Discouraging:

- advertising 2002::/16 addresses via DNS, as it promotes direct 
connectivity from 6to4 clients which may break communication
- using 6to4 as the only means of a server to talk IPv6 (if you can 
setup a server, you can setup a static tunnel)

The idea is that you provide a complete package in the recommendation. 
People who don't follow the recommendation cause their own grief, as 
6to4 itself is a poor transition technology.

Jack

---

From: Martin Millnert <[email-masked]>
Date: Mon, 07 Feb 2011 11:12:41 -0500

> explicitly configure it...  :-)

Haha, yes, of course. :) Wouldn't that be funny though.

Regards,
Martin

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 10:16:28 -0600

On 2/7/2011 9:52 AM, Keith Moore wrote:
> I do this all the time, and it generally works well.  Of course one
> of the reasons that I do this is because I don't have enough IPv4
> addresses to assign to all of my hosts.

If you're running a server with AAAA addresses, get a tunnel or native 
IPv6 or even 6rd. Using 6to4 as the primary means of a server's 
connectivity is ill advised. Responding to 6to4 is fine and should 
definitely be supported. The key on responding to 6to4 is that the 
operator of the server MUST know that there is a 6to4 relay to covert 
back to 6to4, or their server must be able to do it.

6to4 works best as a client mechanism, as clients often don't have the 
ability to manually setup a tunnel for native IPv6 addressing. It is 
substandard to 6rd and teredo.

Jack

---

From: Rémi Després <[email-masked]>
Date: Mon, 7 Feb 2011 17:33:55 +0100

> maybe the way around it is for all ISPs that implement CGN to also implement native v6 via some means.  the people that cause breakage need to assume some responsibility for fixing the breakage.  

Absolutely.
In particular, most if not all ISPs that supports the 6to4 relay function should extend it to support 6rd because:
- the cost should be extremely limited
- the effect is (without breaking 6to4) to offer native addresses to sites whose CPEs supports 6rd (see for example http://www.gossamer-threads.com/lists/nsp/ipv6/27039)

Regards,
RD

---

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

On Feb 7, 2011, at 11:09 AM, Jack Bates wrote:

> If the IETF is going to set a draft with recommendations, the draft should take into account the entire picture. ie, servers shouldn't advertise 6to4 via AAAA but they should support it or make sure they have a 6to4 relay router to handle responses that do come via 6to4.

No.  that's way overbroad.  You're making assumptions about servers (and clients) which aren't true in general.   

> All ISPs should support anycast 6to4 addressing to support any clients which do not have other IPv6 options available. In addition, cases where the provider does provide CGN, NPTv6 can be used on the anycast relay to allow it to work with the hidden addressing. Providers are recommended to use native or at least a transition mechanism other than 6to4 as quickly as possible.
> 
> I'm not discouraging use of 6to4. I'm providing an appropriate scope where it is more functional.
> 
> Encouraging:
> 
> - use of anycast relays by ISPs to support hosts who have no other IPv6 capability
> - support on servers to reply to 6to4 addressing or at least have a known relay to handle the conversion.
> 
> Discouraging:
> 
> - advertising 2002::/16 addresses via DNS, as it promotes direct connectivity from 6to4 clients which may break communication
> - using 6to4 as the only means of a server to talk IPv6 (if you can setup a server, you can setup a static tunnel)
> 

Again, overbroad.  Just as one example, if 6to4 is the only way to contact a server from outside of its local network, then it's entirely appropriate to advertise that server's 6to4 address in DNS.  

Also, it's not the case that every application that uses DNS to obtain destination addresses, works better over NATted v4 than over 6to4.

DNS does not exist merely to advertise web servers and email MXes.  Whether it makes sense to advertise a 2002:: address via an AAAA record is highly dependent on how that host is used, what its clients are, etc.  Your recommendation might make sense for a domain that is only used for a web server, but it doesn't make sense in general.

Keith

---

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

On Feb 7, 2011, at 11:16 AM, Jack Bates wrote:
> If you're running a server with AAAA addresses, get a tunnel or native IPv6 or even 6rd.

In my experience configured tunnels are much worse than 6to4.   Also, 6to4 is available to me without my having to make any special arrangements with anybody else.  That's very powerful, and you're way out of line for trying to impair that functionality.

> Using 6to4 as the primary means of a server's connectivity is ill advised.

It's the best that's available to me right now.  I'll stop using it as a primary means of connectivity as soon as I find a reasonable ISP that provides native v6 at a reasonable price.

> 6to4 works best as a client mechanism, as clients often don't have the ability to manually setup a tunnel for native IPv6 addressing. It is substandard to 6rd and teredo.

My experience indicates otherwise.

Keith

---

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

> - the effect is (without breaking 6to4) to offer native addresses to sites whose CPEs supports 6rd (see for example http://www.gossamer-threads.com/lists/nsp/ipv6/27039)

I'm all for ISPs supporting 6rd.  Though if they want to implement pure v6 instead, that's also fine w/me.  I just don't think that ISPs should break a standard IPv6 transmission mechanism without providing some form of real IPv6.

Keith

---

From: Jack Bates <[email-masked]>
Date: Mon, 07 Feb 2011 12:12:36 -0600

On 2/7/2011 11:39 AM, Keith Moore wrote:
> Again, overbroad.  Just as one example, if 6to4 is the only way to
> contact a server from outside of its local network, then it's
> entirely appropriate to advertise that server's 6to4 address in DNS.
>

This makes the assumption that 6to4 is the ONLY mechanism for IPv6
transition for a server. I would argue that any server which requires
6to4 to be operational is substandard at best. There is an expectation
that a server should have better capabilities than a client, and as such
should be able to create static tunnels or similar to obtain native IPv6.

> Also, it's not the case that every application that uses DNS to
> obtain destination addresses, works better over NATted v4 than over
> 6to4.

Except if the NAT is at the service provider, the 6to4 being chosen will
cause an immediate break.

> DNS does not exist merely to advertise web servers and email MXes.
> Whether it makes sense to advertise a 2002:: address via an AAAA
> record is highly dependent on how that host is used, what its
> clients are, etc.  Your recommendation might make sense for a domain
> that is only used for a web server, but it doesn't make sense in
> general.
>

It makes perfect sense in general, especially given that 6to4 should be
made historic anyways. Your position of advertising it via DNS requires
a lot of conditionals which should not be expected out of 6to4, when the
networks are migrating into more hostile 6to4 environments.

You are stating:

- A server may require 6to4 for connectivity

I say 6to4 servers are broken. Get a nailed  up tunnel. There are plenty
of free ones out there. If we are talking p2p, it's a crap shoot.

 From your other response you stated:
> In my experience configured tunnels are much worse than 6to4.   Also,
> 6to4 is available to me without my having to make any special
> arrangements with anybody else.  That's very powerful, and you're way
> out of line for trying to impair that functionality.

I find that people who say tunnels are much worse are referring to the 
latency problem which 6to4 CAN overcome by using the same route as IPv4, 
or the problem with IPv6 isolated networks. However, as native IPv6 
paths are corrected through the core networks and CGN becomes more 
common for IPv4, using 6to4 in this way will make your connectivity MUCH 
worse.

In other words, it is a timing issue. Pre-IPv6 deployment of core 
networks, 6to4 had some benefits. As IPv6 becomes more dominate in core 
networks, 6to4 will more often than not break when depended on by servers.

- 6to4 connectivity is sometimes better than NAT44

I agree, except IPv4 connectivity will be worse over time and NAT444 is
better than 6to4 not working at all. A client could change address
selection policies to prefer 6to4 via anycast over any IPv4, but that is
a per client decision and should not be made standard.

It is a question of what works best in most situations. 6to4 should be
marked historic, and the server applications of 6to4 should definitely
not be used (outside of supporting a 6to4 response). Honestly, quit 
support IPv4 by running 6to4 servers. Move on to native. If the latency 
sucks, work to fix it.

Jack

---

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

On 2/7/2011 11:45 AM, Keith Moore wrote:
> I just don't think that ISPs should break a standard IPv6
> transmission mechanism without providing some form of real IPv6.

It's not your decision to make, and it will happen out of necessity. 
Servers choosing to advertise 6to4 do so at their own risk. If an ISP is 
forced to rely on 6to4 as a fallback, they will support NPTv6 on the 
6to4 relays. It's the only viable option for 6to4 in CGN.

Get a tunnel. Quit supporting a dying protocol that should have been 6rd 
to begin with (so we'd have lots of 6rd implementations instead of 
broken 6to4).

Jack

---

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

> should be able to create static tunnels or similar to obtain native IPv6.

I think what you are mowing over here is the notion of near-peer-to-peer servers.   When Keith says "server," he means "any node that accepts incoming connections, and needs to be contacted from elsewhere on the Internet."   What you mean when you say "server" is "a dedicated central node configured to provide specific services to a broad range of end-users."   E.g., a web server or a streaming video server run by some corporation, typically with some kind of income stream supporting it.

So it's not surprising that you and Keith disagree on usage here.   But the use case Keith is describing is perfectly valid, and indeed, back in the days before "server" meant "giant anycast cloud referred to with a single name, from which we download content," most "servers" were of the type Keith is referring to.

Keith's use case is valid.   Whether 6to4 in DNS is the right way to address it is certainly up for debate, but let's not pretend that the need Keith is describing doesn't exist, or doesn't matter.   I agree with Keith that the fact that CGN breaks his use case is a bug, not a feature--that is, it is not a valid reason to deprecate 6to4.

---

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

> should be able to create static tunnels or similar to obtain native IPv6.

WTF?  

Look, the Internet is not about a client-server paradigm.  The Internet is fundamentally, and architecturally, peer to peer.    There is no such expectation about servers in the Internet - there is actually no such thing as a "server" (as distinct from a "client") in the Internet architecture.  There are only hosts that send and receive packets.  Being able to accept a SYN TCP packet and return a SYN ACK TCP packet in response, is a perfectly normal thing for any Internet host to do.  

> cause an immediate break.

If my ISP imposes a NAT on my connection, I will get another ISP THAT VERY DAY.     

> made historic anyways.

your premise is false, so your conclusion is unwarranted.

> Your position of advertising it via DNS requires

I've tried nailed up tunnels.  They worked much worse for me than 6to4, and were also more trouble to set up.

> I find that people who say tunnels are much worse are referring to the latency problem which 6to4 CAN overcome by using the same route as IPv4, or the problem with IPv6 isolated networks. However, as native IPv6 paths are corrected through the core networks and CGN becomes more common for IPv4, using 6to4 in this way will make your connectivity MUCH worse.

As soon as people can get native v6 *everywhere* (that includes dialup/ cell modem/hotels/starbucks/etc.), they'll have no need for 6to4.   Until that's the case, it's irresponsible to try to kill it. 

> In other words, it is a timing issue. Pre-IPv6 deployment of core networks, 6to4 had some benefits. As IPv6 becomes more dominate in core networks, 6to4 will more often than not break when depended on by servers.

I don't see how deployment of v6 in core networks adversely affects 6to4.    And it only reduces the need for 6to4 when native v6 is available.

> better than 6to4 not working at all.

Incorrect.  There are cases where nat44 works better; there are also cases where 6to4 works better.    Force either one to the exclusion of the other and you break more things than if you allow both.

> A client could change address

Default address selection rules have always been naive.  Applications have to do their own address selection, in accordance with their own needs, if they expect to work well in this hodgepodge of addressing and routing scenarios.    That will continue to be the case until every host in the world has one and only one globally unique IPv6 address and no v4 addresses.  (in other words, it will continue for the foreseeable future)

> It is a question of what works best in most situations.

NO, that is the wrong question to ask.  Stop trying to make the whole Internet act as if it were only using HTTP.

Keith

---

From: Rémi Després <[email-masked]>
Date: Mon, 7 Feb 2011 19:35:46 +0100

Le 7 févr. 2011 à 18:45, Keith Moore a écrit :

> I'm all for ISPs supporting 6rd.  Though if they want to implement pure v6 instead, that's also fine w/me.

That's clearly better where it can be done, no doubt about it.

>  I just don't think that ISPs should break a standard IPv6 transmission mechanism without providing some form of real IPv6.

Not sure to understand what you mean.
In any case:
- 6rd provides "real" native IPv6 addresses.
- It's virtue is that, where some intermediate devices aren't ready for IPv6, native addresses can be deployed without waiting for these devices to be upgraded. 

Regards, 
RD

---

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

> - It's virtue is that, where some intermediate devices aren't ready for IPv6, native addresses can be deployed without waiting for these devices to be upgraded. 

sorry, by "real" IPv6 I meant something that uses the native v6 packet format to end hosts, uses native globally scoped v6 addresses, and provides non-NATted connectivity with the public v6 network.  6rd certainly qualifies.

Keith

---

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

> - 6rd provides "real" native IPv6 addresses.

Not quite *real*, because the 6rd address still
includes an embedded IPv4 address - I presume
that is why you put the quotes around "real"?

Thanks - Fred

---

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

> that is why you put the quotes around "real"?

for my purposes it doesn't matter how the bits of the address are determined.    what matters is that the v6 packets using those addresses can be sent over the public v6 network, and the hosts using those addresses are reliably reachable (modulo explicit security policy, of course) from the public v6 network.

Keith

---

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

On 2011-02-08 02:59, Jack Bates wrote:
>> - The advice in the draft is that content-provider ISPs, and possibly
>> servers themselves, have 6to4 "relay" functions.
>> - A better combination, in a server that has both a public IPv4
>> address and a native IPv6 address, is that:

The 6to4 standard explicitly forbids advertising any prefix in 2002::/16
that is longer than /16, for reasons explained in the standard and very
strongly supported by the Operations AD at that time.

This proposal appears to imply
a) saying it's OK to import entropy from the IPv4 routing table into the
   IPv6 routing table, something that we've been specifically avoiding
   for the last 15 years.
b) implying that servers will insert multiple AAAA records in the DNS,
   so that they will be "multihomed" on both native and 6to4 addresses.
   This was never the design goal of 6to4, which was designed specifically
   to hop over IPv4-only ISPs.

This thread is about a draft containing advice to operators on how to mitigate
the problems caused by Anycast 6to4 (and Teredo). If you want to talk about
expanding the scope of 6to4 beyond what is envisaged by the current
standards, could you all kindly start a new thread? Please?

I won't be adding any proposals to expand the scope of 6to4 to my draft.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Feb 2011 09:42:25 +1300

> no.  it makes no sense at all to convert a 6to4 connection into an ipv4 connection.

Actually, I see his point. The probability in this scenario is that the v4
path back to the client is actually better than the v6 path, but the problem is
that the client believes it's using IPv6, so it will be quite alarmed
if the SYN/ACK arrives back as an IPv4 packet.

So it doesn't work, afaics, unless both ends contain this trick.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Feb 2011 12:47:02 -0800

> The 6to4 standard explicitly forbids advertising any prefix in
> 2002::/16 that is longer than /16, for reasons explained in the
> standard and very strongly supported by the Operations AD at that
> time.

really?

>    IPv6 routing table, something that we've been specifically avoiding

and other ipv6 fantasies.  deaggregation is driven by st00pidity and
multi-homing, neither of which seems to be decreasing.

>    to hop over IPv4-only ISPs.

we can hope 6to4 will die soon.

> This thread is about a draft containing advice to operators on how to
> mitigate the problems caused by Anycast 6to4 (and Teredo). If you want
> to talk about expanding the scope of 6to4 beyond what is envisaged by
> the current standards, could you all kindly start a new thread?

i want 6to4, teredo, 6rd, ... all dead dead dead.  they are damaging
kludges to support pretend-v6 around lack of deployment.  let the lack
of deployment show.  the truth shall set you free.

randy

---

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

>> standard and very strongly supported by the Operations AD at that

That's my recollection from ngtrans WG sessions, yes.

> multi-homing, neither of which seems to be decreasing.

Correct. We'll get deaggregation in v6 for that reason, but that
doesn't mean we should deaggregate 2002::/16 too.

> of deployment show.  the truth shall set you free.

I think that's unfair on 6rd, which presents a genuine PA prefix to the
IPv6 routing system. But yes, nobody wants 6to4 and Teredo to survive;
that doesn't mean they will die before their time though. This draft is
about reducing the pain until they die.

    Brian

---

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

> I won't be adding any proposals to expand the scope of 6to4 to my draft.

Brian, Do you consider it out of scope to add the following?

1) If 6to4 Addressing is advertised via AAAA records, publishers should 
be aware that CGN/LSN/Provider NAT will break customers behind them from 
utilizing direct 6to4 communications

2) Implementers of CGN/LSN/Provider NAT (that doesn't have some really 
nifty 6to4 ALG) should block protocol 41 and return ICMP unreachables.

(I presume this would be enough to close connections quickly and stop 
the 6to4 break delays)

3) Implementers of CGN/LSN/Provider NAT that support 6to4 anycast should 
implement NPTv6 to convert the 2002:: addresses inbound from IPv4 
anycast to local IPv6 addresses.

4) All 6to4 anycast relays for 2002::/16 should make sure their IPv4 
address is not behind NAT.

I understand some of this is perhaps out of scope as you've defined, 
while some of it is still within scope (dealing directly with anycast). 
All of it I think addresses concerns of breakage.

Jack

---

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

> in their right mind will publish AAAA-records for a 2002::/16 address.

I will definitely add advice against that in the draft.

   Brian

---

From: Drake Wilson <[email-masked]>
Date: Mon, 7 Feb 2011 14:28:49 -0700

> So it doesn't work, afaics, unless both ends contain this trick.

Surely it can't work in the general case regardless?  A 6to4 block
could correspond to any number of otherwise-NAT44 hosts behind a
single public IPv4 address, for instance.

Essentially if this worked then we'd be in "v6 traffic can just be v4
traffic with some extra information" land.  That wouldn't be terrible
on all fronts, but I don't think we're anywhere close to it.

So no, it doesn't make any sense to convert a 6to4 connection into an
IPv4 connection.  However, the other point is sound: with 6to4 clients
it makes sense to be able to respond from a 6to4 address if your
server also has native IPv4, because those packets will take the short
path across IPv4 space rather than relying on relays between 6to4
space and other forms of IPv6 space, which appear to be the main
reliability hitch with 6to4.

>     Brian

   ---> Drake Wilson

---

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

(I'm breaking Jack's message down into separate topics with
appropriate subject headers)

On 2011-02-08 10:09, Jack Bates wrote:
...
> utilizing direct 6to4 communications

Yes, this is a good point. Should we simply recommend against advertising
*any* 6to4 address in DNS, or at least provide a very strong health warning?

    Brian

---

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

> nifty 6to4 ALG) should block protocol 41 and return ICMP unreachables.

I think I already have that in, but I'll check.
> (I presume this would be enough to close connections quickly and stop

Not necessarily, depending on the client stack, but it certainly does
no harm.

    Brian

---

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

> *any* 6to4 address in DNS, or at least provide a very strong health warning?

Based on Keith's argument, I would say a very strong health warning. 
It's not really our place to tell a publishing site that they can't 
break their own connectivity.

Jack

---

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

> anycast to local IPv6 addresses.

I think it's too soon to include that in operational advice; who knows
whether NPT6 will even be published as an RFC?

Also, this approach seems to me to be too complex to become accepted
practice.

    Brian

---

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

> address is not behind NAT.

That was far too obvious for me to mention ;-)

Thanks

   Brian

---

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

> So it doesn't work, afaics, unless both ends contain this trick.

Correct.  And more generally, the client _application_ chose to open a connection to a v6 address and has every right to expect that it is using v6 and not v4.  There are a great many subtle differences between the two, and sometimes applications need to know about them.

Keith

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Feb 2011 14:57:42 -0800

>> kludges to support pretend-v6 around lack of deployment.  let the
>> lack of deployment show.  the truth shall set you free.
> I think that's unfair on 6rd, which presents a genuine PA prefix to
> the IPv6 routing system.

6rd is just one more in a long line of hacks to allow somone running
windows at home to pretend that their provider is giving them ipv6
transport when, in fact, they do not.

randy

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Feb 2011 15:20:01 -0800

> On Behalf Of Randy Bush
> Sent: Monday, February 07, 2011 2:58 PM
> To: Brian E Carpenter
> Cc: IPv6 Operations
> Subject: Re: [v6ops] Out of scope discussion [Fwd:I-D 
> Action:draft-carpenter-v6ops-6to4-teredo-advisory-00.txt]
> 

Then, long live IRON!

Fred

---

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

> Also, this approach seems to me to be too complex to become accepted

I don't really like it, but it's the only way I've seen to support 6to4 
anycast behind CGN. The fallback is to disallow 6to4. I think it is good 
to point out an option, even if we believe it is better to not use 6to4 
in such environments. There are many who won't even think of it.

Jack

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2011 18:46:38 -0500

On Feb 7, 2011, at 6:32 PM, Jack Bates wrote:

> I don't really like it, but it's the only way I've seen to support 6to4 anycast behind CGN. The fallback is to disallow 6to4. I think it is good to point out an option, even if we believe it is better to not use 6to4 in such environments. There are many who won't even think of it.

To me this seems like it's of such limited applicability that it will never see actual use.

The correct fallback, of course, is for ISPs using CGN to:

- provide an option for their customers who need it to get a native v4 address via some other means (say by tunneling), and permit 6to4 over that, and/or
- provide native v6 for all of their customers using CGN, and encourage their customers to migrate to v6 if CGN doesn't work for them

otherwise we should declare CGN Historic from day one.

Keith

---

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

> *any* 6to4 address in DNS, or at least provide a very strong health warning?

Mumble.  AAAA records aren't the problem, the unreliability of exchanging packets with 6to4 destinations in the face of NATs in the network is the problem.  That problem exists regardless of whether those 6to4 addresses are advertised in DNS.   

(I think it's important to clearly distinguish between the problem statement from any recommendations that might result from that identified problem.)

I would support publishing a carefully tailored warning about using 6to4.  e.g.

It is NOT RECOMMENDED to rely on 6to4 addresses for connectivity to servers intended for general public use, unless 

a) a 6to4 address is the only kind of public IPv6 address that is available to that server, OR
b) there is a mechanism associated with the protocol(s) used on that server that makes 6to4 the least preferred option.

Examples (and yes, I know this needs work...but hopefully you get the idea):

1. An IPv4 NAT/IPv6 router that provides Internet connectivity for several hosts, is assigned a public IPv4 address by its upstream provider, but has no IPv6 addresses.  The router implements NAPT to provide v4 addresses for the hosts that it supports, and 6to4 to provide IPv6 addresses for the hosts that it supports.   

If there is a need for some of those hosts to act as "servers", i.e., to accept connections which were initiated from outside the router, it is reasonable for those services to be accessed using the server hosts' 6to4 addresses.  If there is a need for those servers to be advertised in DNS, it is reasonable to publish AAAA records containing those 6to4 addresses.

2.  An IPv4 NAT/IPv6 router that provides Internet connectivity for several hosts, is assigned a public IPv4 address by its upstream provider, and also has an IPv6 /48 block routed to it.  The router implements NAPT to provide v4 addresses for the hosts that it supports, and provides native connectivity for v6.  The router also is configured to advertise 6to4 addresses to its hosts. 

It may be advisable in such a case for this network to discourage use of its 6to4 addresses in favor of native v6 addresses, for its publicly accessible servers.  One way to do this might be to advertise the native v6 addresses using AAAA records in DNS, but not to expose the 6to4 addresses in this way.    

If the servers are only used with specific protocols that use MX or SRV records, it may be possible to expose the 6to4 addresses of those servers in a way that minimizes the potential for disruption.  For example, the 6to4 address of a server that is only used for incoming mail might be exposed as follows:

example.com.   MX   10 native6.example.com.
               MX   20 6to4.example.com.

native6.example.com.  AAAA 2001:1234:5678:abcd::1
6to4.example.com.     AAAA 2002:2345:6789:abcd::1

Similar techniques can be used with protocols that use SRV records.

3. A host is assigned a public IPv4 address, and derives a 6to4 address from that public IPv4 address.  The host does not have native IPv6 connectivity.

It may be reasonable for such a host to advertise its 6to4 address using DNS AAAA records (along with its IPv4 address using DNS A records), since there is no other public IPv6 address available.    Advertising the 6to4 address will enable connectivity for (a) applications running on hosts which only have IPv6 connectivity, and (b) applications running on hosts with both NATted IPv4 and IPv6 connectivity but which cannot function properly through NAT.  

However, many application clients can operate over either v4 or v6, and/or are capable of operating through NAT.  Many of these clients also unilaterally prefer IPv6 addresses (including 6to4 addresses) to IPv4 addresses, advertising this host's 6to4 address in DNS may cause those applications to take longer to connect -- or in rare cases, to fail entirely when they would have worked by connecting via IPv4.

One way to work around the problem might be to advertise different DNS records for different applications.  For example:

; all of these domains point to the same host.
; HTTP works fine through NAT, works fine with either v4 or v6
; most clients can be expected to have some means of fetching web pages using v4

www.example.com.      A     35.69.103.137

; an app that requires IPv6

v6app.example.com.    AAAA  2002:2345:6789:abcd::1

; for logging into the host

ssh.example.com.      AAAA  2002:2345:6789:abcd::1
                      A     35.69.103.137

4. A host is assigned a public IPv4 address, and derives a 6to4 address from that public IPv4 address.  The host also has native IPv6 connectivity.

In this case, the only situation in which 6to4 addresses will be the best destination addresses for some client is when that client is also using 6to4.    If the applications supported by the servers on this host can also use IPv4 (NATted or not such as is available to that client), it makes sense to advertise only the public v4 address and the public v6 address in DNS, as there is a very marginal benefit at best to such clients connecting via a 6to4 address.

Again, if there are a variety of services supported by such a host, with different degrees of NAT / v4 / v6 tolerance, it may make sense to advertise different DNS records for different services.

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Feb 2011 15:58:50 -0800

>> transport when, in fact, they do not.

one more in a long line of bad whitewash

---

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

On 2/7/2011 5:46 PM, Keith Moore wrote:
> - provide an option for their customers who need it to get a native v4 
> address via some other means (say by tunneling), and permit 6to4 over 
> that, and/or

All customers need IPv6 access. Not all customers can have a native IPv4 
address. In some cases, it is possible that 6to4 will be the only option 
available.

> - provide native v6 for all of their customers using CGN, and 
> encourage their customers to migrate to v6 if CGN doesn't work for them
>

It isn't a matter of migrating customers by their choice. It is a matter 
of providing them IPv6 connectivity any way possible and maintaining 
some IPv4 connectivity. Both stacks need to be reachable, even if in a 
limited state. 6to4 is an unideal transition mechanism and shouldn't be 
used if possible, but there are cases (as it is currently the most 
deployed) where 6to4 will be the only mechanism.

> otherwise we should declare CGN Historic from day one.
You can't declare CGN Historic if there is no other way to allow IPv4 
connectivity with the absence of unique IPv4 addresses. As an ISP, I 
don't like the options any more than you do. However, my job is to 
provide all customers access to both IPv4 and IPv6 content that they 
might wish to reach to the best of my ability. Like most ISPs, there is 
a separation between the technical architecture of the network and the 
people who decide on what equipment to buy and when. As such, there will 
be different levels of connectivity depending on the location, but ALL 
locations will have basic (customers want http connectivity most) 
connectivity to both protocols with focus first on IPv6 connectivity.

Jack

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 Feb 2011 16:15:21 -0800

> From: Randy Bush [mailto:[email-masked]] 
> Sent: Monday, February 07, 2011 3:59 PM
> To: Templin, Fred L

No sir - this is a for-real service that owns up to the
difficulties faced by others you've named and fixes them.

Fred

---

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

> difficulties faced by others you've named and fixes them.

Which $50 CPEs are currently supporting IRON?

Jack

---

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

On Feb 7, 2011, at 7:07 PM, Jack Bates wrote:

> All customers need IPv6 access. Not all customers can have a native IPv4 address. In some cases, it is possible that 6to4 will be the only option available.

I can't disagree with that.

> It isn't a matter of migrating customers by their choice. It is a matter of providing them IPv6 connectivity any way possible and maintaining some IPv4 connectivity. Both stacks need to be reachable, even if in a limited state. 6to4 is an unideal transition mechanism and shouldn't be used if possible, but there are cases (as it is currently the most deployed) where 6to4 will be the only mechanism.

All of the transition mechanisms, including dual stack, are "unideal" in some ways.   There are cases where 6to4 works fairly well and cases where it works less well.  It makes sense to document those cases.  

Also, in the cases where the network gratuitously breaks 6to4 because of misconfiguration, it's worthwhile to try to identify and fix these problems.   Operators are still gaining experience with 6to4 and there is some possibility that the situation will improve over time.  I don't see how this is inherently different than, say, identifying sources of bogus BGP advertisements in v4.

> You can't declare CGN Historic if there is no other way to allow IPv4 connectivity with the absence of unique IPv4 addresses.

It's not like CGN is the only way to offer IPv4 connectivity.  It's not like all 2**32 IPv4 addresses are actually assigned to hosts or routers.  There are lots of ways to better utilize IPv4 addresses.  Sure they're ugly.  There are tradeoffs between the amount of burden to put on networks and the amount of burden to put on applications.  (Not surprisingly network operators tend to gloss over the needs of applications and focus on their own needs.)

But honestly I don't have much of a problem with ISPs giving CGN to customers, especially those who aren't significantly harmed by it .  IPv4 is nearing EOL, and many customers are NATing all of their hosts anyway.  But I do think it's incumbent on those ISPs to offer either some way of getting native v4, or some IPv6 solution, to those customers.   To me this is an architectural principle of "don't paint yourself into a corner", or maybe (to use a flying analogy) "don't fly so far up into a narrow canyon that you can't turn around within the canyon's width".  CGN makes some sense as a stopgap measure, but only if it also provides a way out of the mess - or alternatively, if a way out is provided along with CGN.

Keith

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 8 Feb 2011 07:35:38 +0100

Please don't start another IRON discussion, I'm just curious so I ask:

> one more in a long line of bad whitewash

Randy,
Why is IRON such a bad thing?

Fred,
What good will IRON bring?

10 line (of 80chars) for each of you;)

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

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

> So it doesn't work, afaics, unless both ends contain this trick.

That's not what I meant =)
The IPv4 connection would only falsely live in the stack itself, as
presented to the application layer of the "server".
  The packets sent back to the client by the server's stack will still
be IPv4-packets carrying IPv6 packets in its payload, possibly sourced
from 192.88.99.1: 6to4 packets.  Since the client is using 6to4, this is
the form of packets it expects to get back.  But let's scratch and kill
my idea here, it has 0 bearing on this discussion, and I regret putting
it forth in this time and place.

(Any eventual merits of the idea (which is not my own, either) will
remain for those who see/understand the utility on doing it, which may
or may not make sense in their environment. )

Cheers,
Martin

---

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

> *any* 6to4 address in DNS, or at least provide a very strong health warning?

After this discussion, there remains one scenario worth documenting if a warning against 6to4 AAAAs is envisaged.
In this scenario 6to4 AAAAs add connectivity without destroying any:
- There are servers in a site that has a public IPv4 address and no native-IPv6 prefix (like most residential sites today), and whose CPE supports 6to4.
-  These servers have neither As nor a native-IPv6 AAAAs to publish. They have 6to4 AAAAs as only reachable addresses
- If they publish these 6to4 AAAAs, they becomes accessible by clients that have real 6to4 connectivity (i.e. not prevented by any firewall), and by native-IPv6-address clients that have upstream access to a 6to4 relay. 
- Other clients having no chance to reach these servers anyway, nothing is broken.

Regards,
RD

---

From: Erik Kline <[email-masked]>
Date: Tue, 8 Feb 2011 09:49:20 +0000

> *any* 6to4 address in DNS, or at least provide a very strong health warning?

I already added code to our authoritative DNS server to never, ever*
serve an AAAA to a resolver asking for same via 6to4 or Teredo.  I
should double-check that the restriction still applies to requests
with such client IP information inside the draft EDNS Client Subnet
option, but IIRC it does.

-Erik

* there's separate code for "always serving AAAAs" for experimental
measurement purposes and things like ipv6.google.com

---

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

> After this discussion, there remains one scenario worth documenting if a warning against 6to4 AAAAs is envisaged.
I don't think it's necessary. I believe the warning will be CGN 
specific. It's a good reminder that when your 6to4 breaks, you have 
something to look for.

There's no problem with using AAAA for 6to4. You just won't have a lot 
of connectivity from a lot of different networks. If not interested in 
those networks or their users, there is no problem.

Jack

---

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

> Which $50 CPEs are currently supporting IRON?

Maybe you didn't see from a few messages back, but
although the CPE would be a natural platform for the
IRON client software, IRON will work just fine with
unmodified CPEs.

All that is needed is for some device in the customer
home network to download a piece of software provided
by the IRON service provider. That happens all the time
today, and requires no CPE equipment vendor cooperation.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Feb 2011 08:29:34 -0800

Hi Roger,

> What good will IRON bring?

I provided a list of requirements several messages back:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07316.html

The good that IRON brings is that it addresses each of these
requirements (and more).

Thanks - Fred

---

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

Hi Randy,

Le 7 févr. 2011 à 22:05, Brian E Carpenter a écrit :
>> ... i want 6to4, teredo, 6rd, ... all dead dead dead.  they are damaging
>> kludges to support pretend-v6 around lack of deployment... 
> 
> IPv6 routing system.

Indeed.

I suppose you ignore that about half of the native IPv6 traffic Google sees still comes from a single ISP, and that this ISP is that which  has been using 6rd as its way to offer IPv6 since 2007.
Thus, suggesting that 6rd has limitations comparable to those of Teredo and 6to4, while claiming to be in favor of IPv6 deployment, is a pure contradiction.
If I may, your reputation deserves better than that.

Regards,
RD

---

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

> I will definitely add advice against that in the draft.

The point of Tore is well made, so that, for large content providers, I now agree.

OTOH, the advice should be softened for small servers that are in sites in where CPEs have 6to4 prefixes and no native IPv6 prefix. 
I believe Keith also made this point.

Regards,
RD