Subject: [v6ops] I-D Action:draft-ietf-v6ops-6to4-to-historic-00.txt

From: [email-masked]
Date: Tue, 05 Apr 2011 05:30:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status
	Author(s)       : O. Troan
	Filename        : draft-ietf-v6ops-6to4-to-historic-00.txt
	Pages           : 6
	Date            : 2011-04-05

Experience with the "Connection of IPv6 Domains via IPv4 Clouds
(6to4)" IPv6 transitioning mechanism has shown that the mechanism is
unsuitable for widespread deployment and use in the Internet.  This
document requests that RFC3056 and the companion document "An Anycast
Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 05 Apr 2011 16:57:49 +0200

* I-D.ietf-v6ops-6to4-to-historic-00.txt

> 4.  Deprecation
> 
>    This document formally deprecates the 6to4 transition mechanism and
>    the IPv6 6to4 prefix defined in [RFC3056], i.e., 2002::/16.  The
>    prefix MUST NOT be reassigned for other use except by a future IETF
>    standards action.
[...]
> 5.  IANA Considerations
> 
>    IANA is requested to mark the 2002::/16 prefix as "deprecated",
>    pointing to this document.  Reassignment of the prefix for any usage
>    requires justification via an IETF Standards Action [RFC5226].
> 
>    IANA is requested to mark the 2.0.0.2.ip6.arpa domain [RFC5158] as
>    "deprecated", pointing to this document.  Redelegation of the domain
>    for any usage requires justification via an IETF Standards Action
>    [RFC5226].RFC5158

Ole,

There's no similar language deprecating the IPv4 WKP 192.88.99.0/24. Is
that an omission?

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

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 5 Apr 2011 12:32:45 -0700

Hi,

I have a question regarding http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-00 and IPv6 day. 

In section 4.1. among other items the draft recommends to vendors to disable Anycast 6to4 functionality by default. If an OS vendor has an ability to do that for existing implementations, is there a WG consensus whether such changes should be done before the IPv6 day? 

I've checked the Prague WG meeting jabber logs, and I see there was a discussion regarding the intent of IPv6 day, but I'm not sure there was a consensus. There were arguments both for letting more things break on IPv6 day, in order to find what breaks and fix it (e.g. programs not using RFC 3484 sorting), as well as arguments fixing pro-actively things which can be fixed in order for users not to encounter already known issues.

Thanks.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Apr 2011 21:39:58 +0200 (CEST)

On Tue, 5 Apr 2011, Dmitry Anipko wrote:

> In section 4.1. among other items the draft recommends to vendors to 
> disable Anycast 6to4 functionality by default. If an OS vendor has an 
> ability to do that for existing implementations, is there a WG consensus 
> whether such changes should be done before the IPv6 day?

I don't think there was consensus, but there are quite a few people who 
would like to see it disabled.

What should *really* be done is to disable sending RAs out the WAN 
interface when ICS is turned on and 6to4 is the only IPv6 available. 
Please never ever send RAs out the WAN interface at all. This is causing 
serious breakage.

> I've checked the Prague WG meeting jabber logs, and I see there was a 
> discussion regarding the intent of IPv6 day, but I'm not sure there was 
> a consensus. There were arguments both for letting more things break on 
> IPv6 day, in order to find what breaks and fix it (e.g. programs not 
> using RFC 3484 sorting), as well as arguments fixing pro-actively things 
> which can be fixed in order for users not to encounter already known 
> issues.

I'm of the opinion that IPv6 tunneling should be default off in devices. 
If nothing else, please change so that 6to4 reachability is treated the 
same way as teredo, ie lower than native ipv4.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 5 Apr 2011 20:08:03 -0700

Thanks Mikael. I agree there are many sources which can contribute to IPv6 brokenness. Some of them are easier to fix than others. 

My question, however, specifically is whether for IPv6 day it is preferred that the known issues are fixed, or rather not fixed in case it helps to uncover other issues contributing to the brokenness.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Apr 2011 13:41:20 +1000

In message <[email-masked].
winse.corp.microsoft.com>, Dmitry Anipko writes:
> Thanks Mikael. I agree there are many sources which can contribute to IPv6 br
> okenness. Some of them are easier to fix than others. 
> 
> My question, however, specifically is whether for IPv6 day it is preferred th
> at the known issues are fixed, or rather not fixed in case it helps to uncove
> r other issues contributing to the brokenness.

I would say leave 6to4 along.

If 6to4 is broken and it results in a application breaking then
that application is not RFC 1123 compliant and needs to be fixed.

If a application is excessively slow due to 6to4 not working it
also needs to be fixed.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2011 06:17:11 +0200 (CEST)

On Wed, 6 Apr 2011, Mark Andrews wrote:

> If a application is excessively slow due to 6to4 not working it also 
> needs to be fixed.

The behaviour is already known, there is nothing to be learnt from leaving 
this broken for 3 more months.

I'd say get rid of 6to4 (or downprio it) asap and get that process going, 
little or nothing is gained by waiting.

I want as little breakage as possible on IPv6 day so that content 
providers feel confident to turn on dual stack on their content.

If the result is bad and we THEN say "ok, we confirmed that 6to4 is 
causing problems, please turn it off", we will have lost time.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Apr 2011 15:59:18 +1000

In message <[email-masked]>, Mikael Abrah
> this broken for 3 more months.

If you have a fix for a application, install it.  However part of
the point is to find the list of applications which don't work
correctly in a non optimal environment or are you claiming links
won't go down and the broken applications don't need to be discovered.

Similarly we need to check the applications in a IPv6-only environment.
iChat and iCal don't work in such a environment, Apple have been
informed.  They require A IPv4 address to be configured even if it
is a link-local address.  While vendors should be testing in all
sorts of environments there is nothing like the real world to find
something new.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2011 08:17:31 +0200 (CEST)

On Wed, 6 Apr 2011, Mark Andrews wrote:

> If you have a fix for a application, install it.  However part of the 
> point is to find the list of applications which don't work correctly in 
> a non optimal environment or are you claiming links won't go down and 
> the broken applications don't need to be discovered.

IPv6 day will discover applications that don't work well in a dual stack 
as content providers turn on A/AAAA. The main impact that I've heard they 
are afraid of, is people not being able to reach their websites. 23 second 
delay for each object counts as "not being able to reach". It is my 
opinion that this behaviour is well known.

There is little to be learnt here, we just need to fix it. Fixing it might 
be "happy eyeballs", but that is really far away. Turning off 6to4 would 
be a quick fix for a lot of the brokenness seen by eyeballs. If we feel 
likely that we want 6to4 to be turned off after ipv6 world day, why not do 
it immediately and have less brokenness that day, so content providers 
will feel more secure in turning on dual stack for their content, so that 
the "real" ipv6 connectivity that we know works better (managed tunnels 
and real dual stack) can be measured.

For me, changing the 6to4 recommendation so that it would work exactly 
like teredo and not do AAAA questions when only 6to4 or teredo is 
available, would work as well. I just don't want users to use 6to4 and 
teredo to reach websites that are dual stack.

> informed.  They require A IPv4 address to be configured even if it is a 
> link-local address.  While vendors should be testing in all sorts of 
> environments there is nothing like the real world to find something new.

Afaik World IPv6 day is not about testing ipv6 single stack. I agree it 
needs to be done (I'm pushing microsoft to fix MSN messenger for NAT64 use 
for instance), but that's something that for me has less priority than 
trying to get dual stack content working.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2011 18:53:52 +1200

My personal opinion is that the recommendations in 6to4-advisory
should be applied as soon as possible by as many operators as
possible, regardless of IPv6 Day.

The reason I would like to get it finalised before IPv6 Day is
so that, when operators suffer from 6to4-related issues on that day,
they can be pointed to the document as the way to mitigate them.

Regards
   Brian

On 2011-04-06 18:17, Mikael Abrahamsson wrote:
>> point is to find the list of applications which don't work correctly
>> in a non optimal environment or are you claiming links won't go down
>> and the broken applications don't need to be discovered.
> 
> as content providers turn on A/AAAA. The main impact that I've heard
> they are afraid of, is people not being able to reach their websites. 23
> second delay for each object counts as "not being able to reach". It is
> my opinion that this behaviour is well known.
> 
> There is little to be learnt here, we just need to fix it. Fixing it
> might be "happy eyeballs", but that is really far away. Turning off 6to4
> would be a quick fix for a lot of the brokenness seen by eyeballs. If we
> feel likely that we want 6to4 to be turned off after ipv6 world day, why
> not do it immediately and have less brokenness that day, so content
> providers will feel more secure in turning on dual stack for their
> content, so that the "real" ipv6 connectivity that we know works better
> (managed tunnels and real dual stack) can be measured.
> 
>> Similarly we need to check the applications in a IPv6-only
>> environment. iChat and iCal don't work in such a environment, Apple
>> have been informed.  They require A IPv4 address to be configured even
>> if it is a link-local address.  While vendors should be testing in all
> needs to be done (I'm pushing microsoft to fix MSN messenger for NAT64
> use for instance), but that's something that for me has less priority
> than trying to get dual stack content working.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2011 09:06:26 +0200 (CEST)

On Wed, 6 Apr 2011, Brian E Carpenter wrote:

> The reason I would like to get it finalised before IPv6 Day is so that, 
> when operators suffer from 6to4-related issues on that day, they can be 
> pointed to the document as the way to mitigate them.

Operators? I thought this was an end-user problem primarily?

We don't want operators to turn off 6to4 relays, we want end-systems to 
turn off using them, right?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2011 19:20:16 +1200

On 2011-04-06 19:06, Mikael Abrahamsson wrote:
>> The reason I would like to get it finalised before IPv6 Day is so
>> that, when operators suffer from 6to4-related issues on that day, they
>> can be pointed to the document as the way to mitigate them.
> 

End users are the victims, but the mitigations are in the hands
of operators.

> turn off using them, right?

Indeed. But I don't think many end users will be reading my draft.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2011 09:38:27 +0200 (CEST)

On Wed, 6 Apr 2011, Brian E Carpenter wrote:

> End users are the victims, but the mitigations are in the hands of 
> operators.

How? The only thing an ISP can try to do is handle the access they provide 
and run a local 6to4 relay, that doesn't mitigate someone else running a 
bad relay or blocking at their end.

> Indeed. But I don't think many end users will be reading my draft.

No, but Microsoft can turn off (or change the behaviour of) 6to4 via a 
patch release on all Vista and Win7 systems. But this would have to be 
decided quickly to make it for May patch-tuesday.

I'm afraid we're too late anyway...

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Apr 2011 09:51:39 +0200

Tore,

> There's no similar language deprecating the IPv4 WKP 192.88.99.0/24. Is

yes, that is an omission. I will add that.
just have to make sure to find text that doesn't encourage operators to immediately black hole 192.88.99.0/24. that would just make the situation worse.

cheers,
Ole

---

From: [email-masked]
Date: Wed, 6 Apr 2011 11:37:08 +0300

> I'm afraid we're too late anyway...

there is already such a patch http://support.microsoft.com/kb/929852, so 
it might be a matter of decision making. 
For that I suppose IETF should agree on making 6to4 historic in the first 
place to give enough reason to vendors to turn it off during software 
updates. As an operator you can link to that from your website.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2011 20:47:20 +1200

> updates. As an operator you can link to that from your website.

Turning it off as the default is quite common practice already in
managed enterprise networks, but that isn't the main target "market"
here - it's unmanaged SOHO hosts, and an optional patch isn't going
to help there.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2011 20:54:23 +1200

On 2011-04-06 19:38, Mikael Abrahamsson wrote:
> How? The only thing an ISP can try to do is handle the access they
> provide and run a local 6to4 relay, that doesn't mitigate someone else
> running a bad relay or blocking at their end.

Well, there's a reason that the draft is structured the way it is: show
each category of ISP why it's in their selfish interest to mitigate
6to4 problems. However, indeed the word is 'mitigate' not 'fix'.

> decided quickly to make it for May patch-tuesday.

It's a bit tricky to turn it off under the nose of existing users,
who may be using it quite happily. Remember that many 6to4 sessions
are completely successful. 6to4-to-historic is trying to change the
default for *future* products. For current users, it's quite unclear
how to deal with it in a way that doesn't generate millions of
help-desk calls.

> I'm afraid we're too late anyway...

Oh, the "day" is rather symbolic - the issue exists before, during,
and after the day.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2011 20:55:46 +1200

> just have to make sure to find text that doesn't encourage operators to immediately black hole 192.88.99.0/24. that would just make the situation worse.

For that you can refer (non-normatively) to my draft, I think.

    Brian

---

From: [email-masked]
Date: Wed, 6 Apr 2011 11:56:06 +0300

Brian E Carpenter <[email-masked]> wrote on 06-04-2011 
11:47:20:

> From: Brian E Carpenter <[email-masked]>
> To: [email-masked]
> Cc: Mikael Abrahamsson <[email-masked]>, Dmitry Anipko 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> [email-masked]
> Date: 06-04-11 11:47

> here - it's unmanaged SOHO hosts, and an optional patch isn't going

If by hosts you mean PCs, then it might make a lot of difference by simply 
adding the modification in the automatic software updates. A lot of users 
rely on automatic update procedures and it will make a difference.
For CPEs with automatic 6to4 tunneling, this is indeed a different story.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2011 10:58:55 +0200 (CEST)

On Wed, 6 Apr 2011, Brian E Carpenter wrote:

> It's a bit tricky to turn it off under the nose of existing users, who 
> may be using it quite happily. Remember that many 6to4 sessions are 
> completely successful. 6to4-to-historic is trying to change the default 
> for *future* products. For current users, it's quite unclear how to deal 
> with it in a way that doesn't generate millions of help-desk calls.

Well, I could imagine a "recommended" patch could do this.

---

From: [email-masked]
Date: Wed, 6 Apr 2011 12:00:49 +0300

[email-masked] wrote on 06-04-2011 11:58:55:

> From: Mikael Abrahamsson <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Dmitry Anipko 
> <[email-masked]>
> Date: 06-04-11 11:59
> Sent by: [email-masked]
> 

> Well, I could imagine a "recommended" patch could do this.

+1
And as long as this fix is nothing more than a registry change, a tech 
savvy user who knows what he is doing and wants to have the 6to4 back can 
reverse the process in no time.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2011 21:12:41 +1200

On 2011-04-06 20:58, Mikael Abrahamsson wrote:
>> completely successful. 6to4-to-historic is trying to change the

How? In my mind the patch would have to bring up a dialogue box
saying something like:

 Hi, this is your friendly Microsoft Connectivity wizard!!

 I've noticed that you are running a connectivity mechanism called 6to4.
 To find out more about this, please look here <URL>.

 Do you really want to run this mechanism? To find out if
 it's causing you trouble, please click here <URL>.

 OK, if you want to keep running it, you can just click <OK>.
 But if you want to disable it, please click <DISABLE 6to4 and EXIT>.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2011 11:57:39 +0200 (CEST)

> How? In my mind the patch would have to bring up a dialogue box

No, it would just disable 6to4 (or lower the prefix preference so that 
IPv4 is preferred) outright. My guess is that 99% of people running 6to4 
have no idea they're doing that.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 6 Apr 2011 07:35:42 -0700

On Apr 6, 2011, at 2:57 AM, Mikael Abrahamsson wrote:

> No, it would just disable 6to4 (or lower the prefix preference so that IPv4 is preferred) outright. My guess is that 99% of people running 6to4 have no idea they're doing that.

+1

Let's not forget there is precedence here. Did Apple receive a million support calls when they lowered the preference of 6to4 in 10.6.5? I doubt it. Did they throw a dialog box up at the user? No.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 6 Apr 2011 07:42:10 -0700

Dmitry,

I heard pretty strong consensus at the meeting last week for a comment I made at the mic which was roughly "Do on IPv6 day what you would do if it wasn't just one day". I also heard consensus to make 6to4 historic. Put these together, and I would say that if your intention is to disable or lower the preference of 6to4 by default long-term (which I sincerely hope it is), please do so before World IPv6 Day. If we can help it, we don't want to be testing something that isn't going to be around long-term.

- Mark

---

From: Sander Steffann <[email-masked]>
Date: Wed, 6 Apr 2011 16:43:56 +0200

+1

Thanks,
Sander

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Apr 2011 08:33:31 -0700

On Apr 6, 2011 7:44 AM, "Sander Steffann" <[email-masked]> wrote:
>
> > I heard pretty strong consensus at the meeting last week for a comment I
made at the mic which was roughly "Do on IPv6 day what you would do if it
wasn't just one day". I also heard consensus to make 6to4 historic. Put
these together, and I would say that if your intention is to disable or
lower the preference of 6to4 by default long-term (which I sincerely hope it
is), please do so before World IPv6 Day. If we can help it, we don't want to
be testing something that isn't going to be around long-term.

+1. 6to4 is a know challenge that should not be on or preferred by default.
There is no value in extending the pain to new heights.

Cb

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 15:51:24 +0000

> > I heard pretty strong consensus at the meeting last week for a
> comment I made at the mic which was roughly "Do on IPv6 day what you
> would do if it wasn't just one day". I also heard consensus to make
> 6to4 historic. Put these together, and I would say that if your
> intention is to disable or lower the preference of 6to4 by default
> long-term (which I sincerely hope it is), please do so before World
> IPv6 Day. If we can help it, we don't want to be testing something that
> isn't going to be around long-term.
> 
> +1

+1 as well

I believe that nobody does need 6to4 right now, nor in the next few months (although it could be argued due to APNIC exhaustion, but it would be speculation, and we know that native v6, not 6to4, is the solution there).
Furthermore there's consensus regarding the fact that it's breaking connectivity and makes things worse, so why wait?

By the way, probably a stupid idea : would Operating Systems understand and disable 6to4 if ISPs were sending back "host unreachable" for the 6to4 IPv4 address ?

Guillaume

---

From: james woodyatt <[email-masked]>
Date: Wed, 06 Apr 2011 10:11:56 -0700

On Apr 6, 2011, at 07:35 , Mark Townsley wrote:
> 
> Did Apple receive a million support calls when they lowered the preference of 6to4 in 10.6.5?

No, but Apple *was* criticized in the press for it, and I remember wasting valuable time explaining to alarmed managers how Apple did not actually "fix broken IPv6 by breaking it some more" despite popular reports to the contrary.

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

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 6 Apr 2011 11:19:46 -0700

Thank you all for your responses, they answered my question.

Best regards,
Dmitry

From: Cameron Byrne [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 8:34 AM
To: Sander Steffann
Cc: Dmitry Anipko; Mark Townsley; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

> > I heard pretty strong consensus at the meeting last week for a comment I made at the mic which was roughly "Do on IPv6 day what you would do if it wasn't just one day". I also heard consensus to…

+1. 6to4 is a know challenge that should not be on or preferred by default. There is no value in extending the pain to new heights.

Cb

> [email-masked]<mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2011 06:28:16 +1200

> have no idea they're doing that.

Well, we just don't know and disabling running code silently is not
something I could support.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2011 06:30:46 +1200

> There is no value in extending the pain to new heights.

That isn't the point. The point is the millions (literally) of systems
out there that *will* be running 6to4 by default for, very likely,
years to come.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Apr 2011 20:33:57 +0200 (CEST)

On Thu, 7 Apr 2011, Brian E Carpenter wrote:

> out there that *will* be running 6to4 by default for, very likely, years 
> to come.

Absolutely, but many tens of millions of systems can be fixed by vendor 
patch.

So again, there is little ISPs can do to mitigate the problem (at least if 
it's not at their end), so let's at least try to make end system behaviour 
change where we can and try to inform the rest.

The solution should be to turn off tunneling we know is bad, otherwise the 
"solution" will be to turn off IPv6 totally, and then those systems will 
be stuck in IPv4only-land for a long-time.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2011 06:38:55 +1200

On 2011-04-07 06:33, Mikael Abrahamsson wrote:
> So again, there is little ISPs can do to mitigate the problem (at least
> if it's not at their end), so let's at least try to make end system
> behaviour change where we can and try to inform the rest.
> 
> The solution should be to turn off tunneling we know is bad, otherwise
> the "solution" will be to turn off IPv6 totally, and then those systems
> will be stuck in IPv4only-land for a long-time.

I would still like it to be a choice, not a patch that arbitrarily changes
system behaviour, but in any case is not in the IETF's hands.

The 6to4-to-historic draft is pretty clear on the recommended behaviour.

   Brian

---

From: Christopher Palmer <[email-masked]>
Date: Wed, 6 Apr 2011 19:06:15 +0000

>From the perspective of Windows...

Isn't it fair to say:
                6to4 is enabled by default on Windows Vista and Windows 7
                Windows Vista and Windows 7 implement RFC 3484

Thus, the only sources of "brokenness" - scoped to Windows:
                Applications that sort addresses correctly (by not following Windows guidance)
                Hosts that are behind Windows when it has been configured with Internet Connection Sharing, and do not have RFC 3484.
                                (we know about the ICS and 6to4 bugs that exacerbate this issue)

Are there other categories of brokenness from an experience perspective? Major applications that are broken?

----------------------------
[email-masked]
Program Manager
IPv6 @ Windows

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne
Sent: Wednesday, April 06, 2011 8:34 AM
To: Sander Steffann
Cc: [email-masked]; Dmitry Anipko
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Cb

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Apr 2011 21:34:18 +0200

Christopher,

> From the perspective of Windows…
>  
> Isn’t it fair to say:
> Thus, the only sources of “brokenness” – scoped to Windows:

the ICS 'rouge RA' issue:
 - host A is on a dual stack link with native IPv6 support (IPv6 default router with native IPv6 connectivity)
 - host B on the same link, turns on ICS and advertises itself as a default router
 - host A picks host B as default router instead of the correct one

cheers,
Ole

---

From: Christopher Palmer <[email-masked]>
Date: Wed, 6 Apr 2011 19:37:51 +0000

Yeah, we know about the rouge RAs (that's what I meant by ICS bugs that exacerbate the issue). 

Anything else?

Best!
Chris

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, April 06, 2011 12:34 PM
To: Christopher Palmer
Cc: Cameron Byrne; Sander Steffann; [email-masked]; Dmitry Anipko
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Christopher,

cheers,
Ole

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Apr 2011 12:46:51 -0700

On Wed, Apr 6, 2011 at 12:06 PM, Christopher Palmer
<[email-masked]> wrote:
>                 Hosts that are behind Windows when it has been configured
> with Internet Connection Sharing, and do not have RFC 3484.
>

I would be careful that all that appears to be public IP assigned to
the PC are not in fact public IPs ... they are BOGONs used by SPs for
various reasons like NAT44 in mobile or NAT444 in broadband.

I am not saying BOGONs are good or anybody should use them, but they
are in use now and will be used in the future and consequently they
will be a source for pain when a Windows computers thinks 6to4 will
work because it has a public address, but it fact, it is going via NAT
and 6to4 will blackhole.

Cameron

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Apr 2011 21:51:33 +0200

Christopher,

> Yeah, we know about the rouge RAs (that's what I meant by ICS bugs that exacerbate the issue). 

ack. becoming a 6to4 router should be very hard for the uninitiated to turn on, and there should be some sort of check that automatically disables it if the interface is connected to a different network.

> Anything else?

from the top of my mind:

- no reachability test towards the 6to4 relay router.
- doesn't react to ICMPs(?)
- how does it work with "bogons"? non-routable non-RFC1918 IPv4 addresses? (result of some CGN deployments).

cheers,
Ole

---

From: Martin Millnert <[email-masked]>
Date: Wed, 06 Apr 2011 16:41:52 -0400

> out there that *will* be running 6to4 by default for, very likely,

Brian,

If I am reading Dmitry and Christopher correctly, and if I'm correct in
expecting a high level of competent engineering at MS, we have:

anticimex@shakira:~$ host 6to4.ipv6.microsoft.com
6to4.ipv6.microsoft.com has address 192.88.99.1
6to4.ipv6.microsoft.com has IPv6 address 2002:836b:213c:1:e0:8f08:f020:8

And (from
http://technet.microsoft.com/en-us/library/cc779985(WS.10).aspx ):
"Automatically performs a Domain Name System (DNS) query for the name
6to4.ipv6.microsoft.com to obtain the IPv4 address of the Microsoft 6to4
relay router on the Internet. You can use the netsh interface ipv6 6to4
set relay command to specify which DNS name to query."

Thus the "fix" for a very substantial amount of today's Internet hosts
(and more to come with current ongoing enterprise win7 migration
rollouts) could be in fact, very, very simple.

Obviously shipping new code to machines requires patches to go out --
but the above could possibly be done swiftly.  But how much has already
been hidden in the Windows stack for this day, we'll have to see. :)

I could imagine that updating hosts to query instead "6to4".$DOMAIN may
be something one could consider, and MS aren't strangers to configure
the netstack via DNS queries on $DOMAIN, but we'll see what they do.

All in all, MS has a unique position to make a big impact here, one that
I welcome warmly.  If they are willing to do this (by biting the PR
bullet) to fix the current circular
non-IPv6-deploying-dependency-situation we have, I'd be extremely
happy. :)

Cheers,
Martin

---

From: Christopher Palmer <[email-masked]>
Date: Wed, 6 Apr 2011 22:46:07 +0000

The flattery makes one feel warm in the heart.

Yes - Windows clients currently "learn" the 6to4 anycast prefix by resolving 6to4.ipv6.microsoft.com. 

Modification of this A record could be used to modify Windows Vista/7 behavior without requiring a Windows Update, and fix the perceived issue semi-magically.

Best!
Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Millnert
Sent: Wednesday, April 06, 2011 1:42 PM
To: Brian E Carpenter
Cc: [email-masked]; Dmitry Anipko
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Brian,

If I am reading Dmitry and Christopher correctly, and if I'm correct in expecting a high level of competent engineering at MS, we have:

anticimex@shakira:~$ host 6to4.ipv6.microsoft.com 6to4.ipv6.microsoft.com has address 192.88.99.1 6to4.ipv6.microsoft.com has IPv6 address 2002:836b:213c:1:e0:8f08:f020:8

And (from
http://technet.microsoft.com/en-us/library/cc779985(WS.10).aspx ):
"Automatically performs a Domain Name System (DNS) query for the name 6to4.ipv6.microsoft.com to obtain the IPv4 address of the Microsoft 6to4 relay router on the Internet. You can use the netsh interface ipv6 6to4 set relay command to specify which DNS name to query."

Thus the "fix" for a very substantial amount of today's Internet hosts (and more to come with current ongoing enterprise win7 migration
rollouts) could be in fact, very, very simple.

Obviously shipping new code to machines requires patches to go out -- but the above could possibly be done swiftly.  But how much has already been hidden in the Windows stack for this day, we'll have to see. :)

I could imagine that updating hosts to query instead "6to4".$DOMAIN may be something one could consider, and MS aren't strangers to configure the netstack via DNS queries on $DOMAIN, but we'll see what they do.

All in all, MS has a unique position to make a big impact here, one that I welcome warmly.  If they are willing to do this (by biting the PR
bullet) to fix the current circular
non-IPv6-deploying-dependency-situation we have, I'd be extremely happy. :)

Cheers,
Martin

---

From: Christopher Palmer <[email-masked]>
Date: Wed, 6 Apr 2011 22:59:21 +0000

These won't translate into user problems - a correctly configured application or a 3484-compliant host will be fine in these situations. 

They might eventually try a broken connection which is unfortunate, but correct sorting will make 6to4 a last resort. So really, the brokenness will never establish itself except in the following 2 scenarios, AFAIK.

               Applications that sort addresses correctly (by not following Windows guidance)
               Hosts that are behind Windows when it has been configured with Internet Connection Sharing, and do not have RFC 3484.
                                (exacerbated by the rouge RA issue with ICS)

Best!
Chris

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, April 06, 2011 12:52 PM
To: Christopher Palmer
Cc: Cameron Byrne; Sander Steffann; [email-masked]; Dmitry Anipko
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Christopher,

from the top of my mind:

cheers,
Ole

---

From: Martin Millnert <[email-masked]>
Date: Wed, 06 Apr 2011 18:59:23 -0400

Chris,

> Modification of this A record could be used to modify Windows Vista/7 behavior without requiring a Windows Update, and fix the perceived issue semi-magically.

That sounds absolutely terrific.  If pushing this draft through helps in
this effort (i.e. the IETF making clear recommendations to OS vendors),
it's a strong motivation to do so, to say the least.

Cheers,
Martin

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Apr 2011 09:04:58 +0200

Chris,

> These won't translate into user problems - a correctly configured application or a 3484-compliant host will be fine in these situations. 

did you mean 3484-revise compliant?
what happens if there is a broken 6to4 connectivity but working Teredo connectivity? then because of the lack of reachability tests, processing of ICMPs, will lead to much longer time outs than required.

>                                (exacerbated by the rouge RA issue with ICS)

happy eyeballs.

btw: I was looking at this from a more general point of view than just the Windows implementation (that appears to have gotten the SAS/DAS selection sorted out).

cheers,
Ole

---

From: Tore Anderson <[email-masked]>
Date: Thu, 07 Apr 2011 09:05:26 +0200

Hi Chris,

* Christopher Palmer

> Modification of this A record could be used to modify Windows Vista/7
> behavior without requiring a Windows Update, and fix the perceived
> issue semi-magically.

Unfortunately, last I checked, it does not help to override the A record
to resolve to nothing. The Default Gateway field in the ipconfig output
shows an empty value (where it usually says 2002:c058:6301::). The 6to4
adapter is enabled, and ICS continues to annouce it with RAs.

Doing this is equivalent to disabling anycast 6to4 (RFC 3068) but
leaving router 6to4 (RFC 3056) functionality intact. It does *not* help
*at* *all* against dual-stack brokenness, since the hosts that receive
the RA will get an IPv6 address and an IPv6 default router, and will try
to use that to get to the IPv6 internet. Which is guaranteed to not
work, and you're guaranteed end-user brokenness.

This problem is the biggest reason why I strongly feel that 3056 should
be marked historic along with 3068.

However, if it is possible to muck around with the
6to4.ipv6.microsoft.com record in a way that prevents the 6to4 interface
from being enabled (and, by extension, RAs from ICS) - please do share!
I know of several network operators who would be absolutely ecstatic
about having a way to disable rogue RAs from 6to4/ICS for their entire
user base in one fell swoop.

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

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 7 Apr 2011 00:36:31 -0700

Hi Ole,

>>what happens if there is a broken 6to4 connectivity but working Teredo connectivity? then >>because of the lack of reachability tests, processing of ICMPs, will lead to much longer time outs than required.

As I understand, people are mostly concerned regarding how broken 6to4 is compared to native IPv6 and IPv4, and not how much Teredo works better than 6to4.

In that regard, for native IPv6 destinations (since relay router was mentioned below) and IPv4, connections 6to4->native would not be preferred over native->native or IPv4->IPv4 even by the original (not revised) RFC 3484 due to 6to4->Native label mismatch. Hence, an application using OS sorting or following RFC 3484 would not be affected by bad relay, and should have first tried native IPv6 or IPv4.

Regarding Teredo - if the destination has native IPv6 address only, then the interface choice is determined by route and interface metric, and not RFC 3484, so revised RFC would not help. And if destination has both Teredo and native, then again because of label match for Teredo<->Teredo will win over 6to4->Native. 

Thanks,
Dmitry
________________________________________
From: Ole Troan [[email-masked]] On Behalf Of Ole Troan [[email-masked]]
Sent: Thursday, April 07, 2011 12:04 AM
To: Christopher Palmer
Cc: Cameron Byrne; Sander Steffann; [email-masked]; Dmitry Anipko
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Chris,

happy eyeballs.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2011 19:44:16 +1200

Firstly, many thanks to Chris for engaging in this discussion.

> it's a strong motivation to do so, to say the least.

But how will that affect people who are happily using 6to4? Please don't forget
that many 6to4 sessions are entirely successful. I really don't see how
we could legitimately mess those people up to eliminate the cases that don't
work.

    Brian

---

From: [email-masked]
Date: Thu, 7 Apr 2011 10:50:53 +0300

> >> Modification of this A record could be used to modify Windows 
> Vista/7 behavior without requiring a Windows Update, and fix the 
> perceived issue semi-magically.
> >

> we could legitimately mess those people up to eliminate the cases that 
don't

+1
Killing it entirely seems a bit too much. It is still a way to get 
reasonably working IPv6 for some purposes.
I believe it will be good enough to disable the 6to4 and teredo by default 
with a patch, but still leave it configurable from cli for whoever 
understands why he is doing that.
deprecating 2002::/16 prefix is also unreasonable at this point.

Roman

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 10:28:44 +0200

Christopher,

there is a bug still existing since 2009 which relates to state changes of IPv6 addresses.
For history please see: http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002718.html
Actual discussion: http://lists.cluenet.de/pipermail/ipv6-ops/2011-April/005188.html

How to reproduce?

Case A:
1) advertise IPv6 prefix to SLAAC enabled Vista/Win7 hosts
2) withdraw this prefix by sending RA with PIO and PrefLT=0
3) re-advertise the same prefix with common timers

Results in deprecated, unusable IPv6 addresses on the systems despite the fact that timers are updated according to the recent PIO information.

Case B (quoting myself from ipv6-ops list):
<quote>
You can reproduce this behavior without sending PIO with PrefLT=0 if you send the Vista/Win7 system in standby and wake it up after time X.
Where X is defined as ValidLifetime > X > PreferredLifetime.
</quote>

Same result as in case A.

best regards,
Christian

<><><><><><><><><><><><><><>
Christian Hahn

T-Systems International GmbH
Systems Integration 
IP Products, Services and Networks
Goslarer Ufer 35, 10589 Berlin
Tel	+49 30 -3497 3164
Fax 	+49 30 -3497 3165
Mobil	+49 170 7641791
E-Mail: [email-masked]
Internet: <<http://www.t-systems.com>> 

>>                 Hosts that are behind Windows when it has 
>been configured with Internet Connection Sharing, and do not 
>have RFC 3484.
>> Are there other categories of brokenness from an experience 
>perspective? Major applications that are broken?
>
> - host A is on a dual stack link with native IPv6 support 
>(IPv6 default router with native IPv6 connectivity)

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 7 Apr 2011 10:34:47 +0200

On Wed, Apr 6, 2011 at 6:17 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> If a application is excessively slow due to 6to4 not working it also needs
>> to be fixed.
>
> I want as little breakage as possible on IPv6 day so that content providers
> feel confident to turn on dual stack on their content.
>
> If the result is bad and we THEN say "ok, we confirmed that 6to4 is causing
> problems, please turn it off", we will have lost time.

... and that is time we are running quite low on already.

I can't argue that it's safe to have IPv6 on if we know it will cause
problem in our network.
However, if I can show that that issue (in this case 6to4) are already
handled and all we
have todo is ito apply a patch to the OS (from the vendor) it will be
just another point to
remove form the todo list instead of being a possible problem left open.

-- 

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

---

From: Martin Millnert <[email-masked]>
Date: Thu, 07 Apr 2011 10:36:17 -0400

Brian, Roman,

> > we could legitimately mess those people up to eliminate the cases that 

It's either on by default or off by default.
draft-ietf-v6ops-6to4-advisory-00 suggests that it is off by default,
and user-enable:able.

> reasonably working IPv6 for some purposes.

We're *not* discussing "killing it entirely".

> understands why he is doing that.

That is exactly what modifying the A-record of 6to4.ipv6.microsoft.com.
will supposedly accomplish.
  Quoting my previous e-mail:
"You can use the netsh interface ipv6 6to4 set relay command to specify
which DNS name to query."

Thus, anyone who wants to use 6to4 would only have to do the above, and
my guess is that you can enter IPv4 literals ("192.88.99.1" ) as well as
domain names there.

Regards,
Martin

---

From: Martin Millnert <[email-masked]>
Date: Thu, 07 Apr 2011 10:51:21 -0400

Tore,

On Thu, 2011-04-07 at 09:05 +0200, Tore Anderson wrote:
> 6to4.ipv6.microsoft.com record in a way that prevents the 6to4
> interface from being enabled (and, by extension, RAs from ICS) -
> please do share! 

That's where I saw the possibility of prudent forward-looking
engineering, by for example using an A-record pointing to an address in
127/8, as a means of signaling "disable yourself" to the 6to4 adapter.
We still haven't seen whether this is how it actually works or not, but
it is certainly what Chris is alluding.

Failing this, as you describe so well, new code is obviously required to
ship to hosts.

Regards,
Martin

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 9 Apr 2011 19:26:13 -0700

Hi Tore,

To clarify on this: when A record is absent, Windows 6to4 hosts do not configure default route to 6to4 relay for themselves. It is correct that ICS, if configured on 6to4 host, will advertize default route irrespectively of whether 6to4 relay is configured or not. But for those hosts, which don't have ICS configured, modification of the A record for the relay name does have effect. To verify that, I tested that today on a fresh Windows 7 install.

>>It does *not* help

Are there data indicating that overwhelming majority of clients, which experience IPv6 brokenness and have 6to4 addresses, are broken because they received ICS rogue 6to4 RAs, and that they are not 6to4 hosts, which try sending traffic through black-holed 6to4 relay due to the default route they have to that relay?

Thank you,
Dmitry

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: Thursday, April 07, 2011 12:05 AM
To: Christopher Palmer
Cc: Martin Millnert; Brian E Carpenter; [email-masked]; Dmitry Anipko
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Hi Chris,

* Christopher Palmer

Best regards,

---

From: Tore Anderson <[email-masked]>
Date: Sun, 10 Apr 2011 07:40:30 +0200 (CEST)

Hi Dimitry,

* Dmitry Anipko

> Are there data indicating that overwhelming majority of clients,
> which experience IPv6 brokenness and have 6to4 addresses, are broken
> because they received ICS rogue 6to4 RAs,

There's plenty of empirical evidence. After spending a few minutes
with Google:

https://ow.feide.no/_media/geantcampus:2011-gn3na3t4-ipv6-gregr.pdf
http://malc.org.uk/6doom
http://ripe61.ripe.net/presentations/162-ripe61.pdf
http://www.rfc-editor.org/rfc/rfc6104.txt
http://www.gossamer-threads.com/lists/nanog/users/139564#139564
http://www.getipv6.info/index.php/Customer_problems_that_could_occur#Internet_Connection_Sharing
http://www.uknof.org.uk/uknof10/Chown-IPv6-campus.pdf
http://www.gossamer-threads.com/lists/nsp/ipv6/28106#28106
http://www.ietf.org/mail-archive/web/72attendees/current/msg00478.html
http://www.ipv6.leeds.ac.uk/Docs/IPv6issues.pdf
http://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf
https://ow.feide.no/_media/geantcampus:2011-gn3-na3t4-ipv6-skjesol.pdf
http://www.personal.psu.edu/dvm105/blogs/ipv6/2011/01/rogue-ra-while-shopping-for-sh.html
http://www.apan.net/meetings/Sydney2010/Session/Slides/IPv6/10%20John_Mann_20100210.pdf

I'll stop here, but you'll be able to find many more accounts of
6to4 rogue RAs from ICS causing major operational problems by
using your favourite search engine.

Best regards,

---

From: "Dale W. Carder" <[email-masked]>
Date: Sun, 10 Apr 2011 15:56:23 -0500

Hi Dmitry,

On Apr 9, 2011, at 9:26 PM, Dmitry Anipko wrote:
> 
> Are there data indicating that overwhelming majority of clients, which experience IPv6 brokenness and have 6to4 addresses, are broken because they received ICS rogue 6to4 RAs

This is the #1 cause of v6 brokenness on our campus network.

Dale

---

From: "John Mann (ITS)" <[email-masked]>
Date: Mon, 11 Apr 2011 14:37:22 +1000

Hi,

The problem that Windows 7  IPv6 addresses can't be un-deprecated is biting
Fritz!Box users in Australia

There is a discussion of this problem, along with a youtube demonstration at
   http://forums.whirlpool.net.au/forum-replies.cfm?t=1648260&p=5#r97
The discussion is scattered through several later pages at least as far as
   http://forums.whirlpool.net.au/forum-replies.cfm?t=1648260&p=15#r288

Also:

http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/e1873459-5b9f-4c3e-b9e7-fdf778bae491/

Thanks,
    John

On 7 April 2011 18:28, <[email-masked]> wrote:

> For history please see:
> http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002718.html
> Actual discussion:
> http://lists.cluenet.de/pipermail/ipv6-ops/2011-April/005188.html
>
> How to reproduce?
>
> Case A:
> Results in deprecated, unusable IPv6 addresses on the systems despite the
> fact that timers are updated according to the recent PIO information.
>
> You can reproduce this behavior without sending PIO with PrefLT=0 if you
> send the Vista/Win7 system in standby and wake it up after time X.

---

From: "John Mann (ITS)" <[email-masked]>
Date: Mon, 11 Apr 2011 15:02:37 +1000

Hi,

On 11 April 2011 06:56, Dale W. Carder <[email-masked]> wrote:

> > Are there data indicating that overwhelming majority of clients, which
> experience IPv6 brokenness and have 6to4 addresses, are broken because they
> received ICS rogue 6to4 RAs
>

This _was_ the #1 cause of brokenness on our campus networks in 2009.
Mostly Windows Vista personal laptops causing problems for OS X 10.4/5 Macs.

Finding/fixing PCs one at a time couldn't keep up with the problem,
especially for student PCs in residences
who were only active in the evenings.

We suppressed the rogue RAs (but didn't fix the problem by stopping the PCs
from being 6to4 gateways) by applying this filter across 53,000+ user switch
ports
---
ipv6 access-list RA-FILTER
 deny icmp any any router-advertisement
 deny icmp any any router-renumbering
 permit ipv6 any any
---

The graph of concurrently visible rogue 6to4 routers on our network can be
seen decreasing from 11 to 0
   http://ns0b.its.monash.edu/test/ipv6-rogue-routers-month.png

Thanks,
    John

---

From: Masanobu Kawashima <[email-masked]>
Date: Mon, 11 Apr 2011 21:29:25 +0900

Hi John,

I reported same problem to Japanese Microsoft engineers on March 11th.
They've already finished to confirm this problem. They are considering
 how fix it. I might inform their decision one of these days.

Sincerely,
Masanobu

>> Same result as in case A.

========================================
 NEC AccessTechnica, Ltd.               
 Access Networks Engineering Department 
 Masanobu Kawashima                     
 [email-masked]               
 http://www.necat.co.jp/                
========================================

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 12 Apr 2011 00:30:41 -0700

Hi Tore,

definitely 6to4 RAs sent by ICS is one of the brokenness sources. However it is not the only source, and my question was how many users are there, sitting with 6to4 default route and experiencing IPv6 brokenness, who would be fixed by changing relay A record. 

None of the sources you quoted seems to do such comparison - they are mostly focused on ICS RA issue, which is highly visible to network administrators, but it doesn't automatically mean that issues in other configurations don't exist or less important, even if they are less visible to administrators. 

One could estimate the number of users affected by 6to4 RAs (for example, on IPv4 only networks) and by 6to4 on hosts, based on market shares of OSes and browsers:

If X is a number of hosts worldwide with assigned public IPv4 addresses, an estimate for the number of affected users for Windows 6to4 hosts could be - X * 0.35 (Windows 7 + Vista share) * 0.005 (upper estimate of share of older browsers not following RFC 3484).  

An estimate for the number of affected users on IPv4 networks affected by 6to4 ICS RAs - X * 0.35 (W7 + Vista market share) * MobileICSShare * AvgMachinesPerLAN * (0.06 (upper estimate of share of older versions of some OSes, not following RFC 3484) + 0.35 (Windows 7 + Vista share) * 0.005 ) where MobileICSShare stands for relative share of Windows7+Vista with ICS enabled which are not always at one location, and AvgMachinesPerLAN is how many machines are in an average LAN.

In comparison the common factor X*0.35 can be excluded, and one needs to compare ~0.005 with MobileICSShare * AvgMachinesPerLAN * 0.06. To estimate MobileICSShare * AvgMachinesPerLAN, my guess for AvgMachinesPerLAN is 100-1000. With such numbers, for number of affected users in the two scenarios to be of the same order, MobileICSShare needs to be 10^-4 - 10^-3. 

I don't have good data sources to estimate actual MobileICSShare value, but worldwide 10^-4 - 10^-3 doesn't seem to be completely unreasonable, and number of the affected users in the two scenarios may be of the same order. So if there is any truth in such rough estimate, disabling 6to4 relay record may reduce IPv6 brokenness. How much exactly - I guess only a measurement could show.

Thank you,
Dmitry

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: Saturday, April 09, 2011 10:41 PM
To: Dmitry Anipko
Cc: Christopher Palmer; Martin Millnert; Brian E Carpenter; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

Hi Dimitry,

* Dmitry Anipko

Best regards,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Apr 2011 09:55:15 +0200 (CEST)

On Tue, 12 Apr 2011, Dmitry Anipko wrote:

> So if there is any truth in such rough estimate, disabling 6to4 relay 
> record may reduce IPv6 brokenness. How much exactly - I guess only a 
> measurement could show.

I am 100% sure that disabling 6to4 by default would seriously reduce IPv6 
brokenness. It will also seriously reduce the number of people using IPv6 
(over 6to4), but I think the consensus is that right now it's better to 
reduce use of IPv6 compared to having a significant share of added IPv6 
brokenness.

So in my opinion from reading this WG, a lot of people (majority) wants 
users to get IPv6 when it's done right and has a very high possibility of 
working, as opposed to having IPv6 that we know is breaking in a lot of 
cases but that reaches a higher number.

6to4 was great for testing, it's not great for production.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 12 Apr 2011 10:15:52 +0200

Hi Dmitry,

* Dmitry Anipko

> definitely 6to4 RAs sent by ICS is one of the brokenness sources.
> However it is not the only source, and my question was how many users
> are there, sitting with 6to4 default route and experiencing IPv6
> brokenness, who would be fixed by changing relay A record.

My guess? Almost none.

Removing the relay A record will only help people that are:

1) Windows users (millions), and
2) Have a local 6to4 interface (millons), and
3) Prefer to use the 6to4 interface above IPv4 (almost none - pretty
much only Opera users that haven't upgraded in more than a year).

As you've confirmed yourself, removing the relay A record does nothing
for users behind/besides a ICS host, as they will still have an default
route and a 6to4 address.

> None of the sources you quoted seems to do such comparison - they are
> mostly focused on ICS RA issue, which is highly visible to network
> administrators, but it doesn't automatically mean that issues in
> other configurations don't exist or less important, even if they are
> less visible to administrators.

The ICS rogue RA issue is the way I see it *THE* problem with IPv6 in
Windows. I'm happy to hear that you acknowledge it to be a problem.

I'm looking at this from the content provider's perspective, not as
network operator that has a RA problem on my own network: I see users
being unable to access my dual-stacked sites, and when talking to the
operators of the networks those end users are in, they tell me that
they're tearing their hair out about rogue RAs and don't know what to do
about them.

The problem is not limited to 6to4 though, any rogue RA causes grief,
including the site-local and prefix-less ones that ICS can generate.
Especially on dual-stacked LANs, as the hosts get confused about which
next-hop to use.

(BTW: The University of Oslo ended up developing an intricate system
that detects rogue RA, shoots them down with ramond and immediately
moves the end-user's switch port into an quarantine VLAN where the only
thing he can access is a captive portal that instructs him to first
disable ICS, and then afterwards contact the help desk in order to have
his network access restored.)

> One could estimate the number of users affected by 6to4 RAs

I fail to see why this is interesting, as it is beyond any doubt that
rogue RAs from ICS are a huge problem. Can you please fix it ASAP? Just
make ICS never send out any RAs unless it has native IPv6 connectivity
to share, and push this patch out to your users in Windows Update. It
would help *A LOT*.

If we notice any further IPv6 problems caused by any Microsoft products
we'll make sure to let you know so that you can have a look at those
too. But until then - the ICS rogue RA problem has been known for a long
time now and is very well understood; please don't delay fixing it just
because you want to look for other issues too.

Best regards,

---

From: Doug Barton <[email-masked]>
Date: Tue, 12 Apr 2011 12:20:26 -0700

> we could legitimately mess those people up to eliminate the cases that don't

The questions we need to be looking at are:
1. What benefits are gained from successful 6to4 connections?
2. What costs are associated with unsuccessful ones?

For those who really legitimately care about IPv6 access and have a 
"need" to do it, there are other tunneling methods available that are at 
least as good, if not better. So disabling 6to4 would not seriously 
hamper people in the first category, although it would create some 
inconvenience for them in terms of having to switch.

On the other hand, the unsuccessful 6to4 connections have a very high 
cost in that they are a major contributing factor causing content 
providers to be hesitant to deploy real IPv6. One could also argue that 
the presence of 6to4 has created a reduced incentive for ISPs as well, 
but I don't place a lot of weight on that argument.

So, benefits, nearly zero; costs, huge. To me that's a pretty clear cut 
decision point. Stick a fork in it, it's done.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: james woodyatt <[email-masked]>
Date: Tue, 12 Apr 2011 14:24:58 -0700

On Apr 12, 2011, at 12:20 , Doug Barton wrote:
> 
> On the other hand, the unsuccessful 6to4 connections have a very high cost in that they are a major contributing factor causing content providers to be hesitant to deploy real IPv6. One could also argue that the presence of 6to4 has created a reduced incentive for ISPs as well, but I don't place a lot of weight on that argument.

I don't believe this claim of high costs associated with failed 6to4 is supported by evidence.  Furthermore, I fail to see how deprecating 6to4 will do anything to increase the incentives for either content providers or Internet service providers to deploy native IPv6 applications and service.

The content providers can identify plenty of other sources of IPv6 brokenness with which to excuse dragging their heels to effect the transition.  Those source mainly revolve around buggy CPE router implementations that have nothing to do with 6to4 or its anycast relay service.  Moreover, the incumbent service providers have little incentive to deploy native IPv6 while content providers are still available over IPv4 and they are protected from competition because NAT444 offers better customer lock-in mechanisms than DS and DS-lite.

I therefore contend that deprecating 6to4 now is a waste of IETF time.  The utility of 6to4 will wither away naturally over time.  Attempting to hurry it along by publishing an RFC will help no one.

---

From: Jan-Hinrich Fessel <[email-masked]>
Date: Tue, 12 Apr 2011 23:40:29 +0200

Am 12.04.2011 um 09:55 schrieb Mikael Abrahamsson:

>> So if there is any truth in such rough estimate, disabling 6to4 relay record may reduce IPv6 brokenness. How much exactly - I guess only a measurement could show.
> 
> I am 100% sure that disabling 6to4 by default would seriously reduce IPv6 brokenness. It will also seriously reduce the number of people using IPv6 (over 6to4), but I think the consensus is that right now it's better to reduce use of IPv6 compared to having a significant share of added IPv6 brokenness.
> 
> So in my opinion from reading this WG, a lot of people (majority) wants users to get IPv6 when it's done right and has a very high possibility of working, as opposed to having IPv6 that we know is breaking in a lot of cases but that reaches a higher number.
> 

+1

-- 
Jan-Hinrich Fessel

---

From: "Frank Bulk - iName.com" <[email-masked]>
Date: Tue, 12 Apr 2011 17:38:59 -0500

There are several known items of brokenness.  If all we can do is take small
steps to address them, that's better than taking no steps at all.  As
someone else said earlier in this thread, we'd rather have a little less
IPv6 traffic (collateral damage) because 6to4 is disabled in the OS or
router than have the measured levels brokenness.  My current top concern for
my end users on World IPv6 day?  Routers that support 6to4 and end-users who
plug their PC directly into our cable modem or ONT and use 6to4 that way.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
james woodyatt
Sent: Tuesday, April 12, 2011 4:25 PM
To: Doug Barton
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-advisory-00 and IPv6 day question

On Apr 12, 2011, at 12:20 , Doug Barton wrote:
>
> On the other hand, the unsuccessful 6to4 connections have a very high cost
in that they are a major contributing factor causing content providers to be
hesitant to deploy real IPv6. One could also argue that the presence of 6to4
has created a reduced incentive for ISPs as well, but I don't place a lot of
weight on that argument.

I don't believe this claim of high costs associated with failed 6to4 is
supported by evidence.  Furthermore, I fail to see how deprecating 6to4 will
do anything to increase the incentives for either content providers or
Internet service providers to deploy native IPv6 applications and service.

The content providers can identify plenty of other sources of IPv6
brokenness with which to excuse dragging their heels to effect the
transition.  Those source mainly revolve around buggy CPE router
implementations that have nothing to do with 6to4 or its anycast relay
service.  Moreover, the incumbent service providers have little incentive to
deploy native IPv6 while content providers are still available over IPv4 and
they are protected from competition because NAT444 offers better customer
lock-in mechanisms than DS and DS-lite.

I therefore contend that deprecating 6to4 now is a waste of IETF time.  The
utility of 6to4 will wither away naturally over time.  Attempting to hurry
it along by publishing an RFC will help no one.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Apr 2011 18:50:24 +1200

> I therefore contend that deprecating 6to4 now is a waste of IETF time.  The utility of 6to4 will wither away naturally over time.  Attempting to hurry it along by publishing an RFC will help no one.

I fully agree with James, and unlike Doug I believe that it would
be totally wrong for us to intentionally break working connectivity
(via 6to4 or any other mechanism). Specifically, some people use 6to4
because it works; it's considerably more bother to find a tunnel
broker.

I'm not fighting against draft-ietf-v6ops-6to4-to-historic, because
it's harmless to existing users and may reduce future problems. But if
ISPs do what is suggested in draft-ietf-v6ops-6to4-advisory, things
will be better *for their customers and for their OPEX* before, during
and after IPv6 day.

   Brian

---

From: "John Mann (ITS)" <[email-masked]>
Date: Wed, 13 Apr 2011 19:22:57 +1000

Hi,

On 13 April 2011 07:24, james woodyatt <[email-masked]> wrote:

> cost in that they are a major contributing factor causing content providers
> to be hesitant to deploy real IPv6. One could also argue that the presence
> of 6to4 has created a reduced incentive for ISPs as well, but I don't place
> a lot of weight on that argument.
>
> supported by evidence. ...

I can't provide overall numbers, but I can provide anecdotal evidence.

As I remember it ... in November 2008, I enabled IPv6 on
http://www.monash.edu.au (that's Monash acting as content provider).
IPv6 was only enabled on a few user subnets.
Everything went well over the Christmas break.

Then, with the start of the academic year in 2009, users started reporting
problems (that's Monash acting as an access provider).
Users starting reporting slowness or complete inability to get to
www.monash.edu.au
Often Macs ... and it was often tracked down to nearby Windows Vista
laptops.
By tracking down and disabling IPv6 on that laptop and/or disabling IPv6 on
all the Macs we were kept busy, but were keeping the problem manageable.
Student machines are harder to track down ...

In parallel, we were trying other solutions, such as enabling real IPv6
dual-stack on the affected subnets.
This helped, but sometimes Macs would align themselves with the rogue 6to4
RAs rather than to our Cisco router RAs.

And then some Professors had troubles.  Not only was accessing Monash web
sites slow, but late every afternoon, they became unusable.
Professors don't call ITS Helpdesk -- they complain to the Dean that their
ability to do important research and apply for grants is compromised !!
Deans don't call ITS Helpdesk -- they complain at University IT Steering
committee meetings !!

Eventually, the problem filters down the chain of command to us.
We were quickly able to identify the problem and solve it, and spent the
next 2 days in their building smoothing things over.
It was a laptop tunneling all IPv6 traffic out to a 6to4 relay and then back
into Monash - slow access.
And at 4:30pm each day the user took the laptop home, but the Macs still had
a default IPv6 route and continued sending IPv6 traffic to the PC's Ethernet
address until the route expired -- blackholing all IPv6 traffic.

We did *not* tell the users that the problem was triggered by turning on
IPv6 on the main web site.
But we did turn off IPv6 on the main web site for a couple of days.

But I promised that after we got over _this_ problem, all would be well with
IPv6.
And we turned IPv6 back on for the main web site.
Next I did a large amount of work to enable RA filtering on every
user-facing Catalyst 3750 switch port.

So, yes, unsuccessful 6to4 connections did almost stop/reverse Monash's IPv6
content-provider rollout.
And it cost a lot of effort to make Monash's access-provider network safe
against 6to4 rogue routers.

    John

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Apr 2011 11:45:15 +0200 (CEST)

On Wed, 13 Apr 2011, John Mann (ITS) wrote:

> And it cost a lot of effort to make Monash's access-provider network 
> safe against 6to4 rogue routers.

Were you able to motivate and get buy-in from higher management that 
implementing proper filtering (SAVI) in the network is important after all 
these problems?

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Apr 2011 11:51:36 +0200

>address until the route expired -- blackholing all IPv6 traffic.

I wonder wonder what went wrong there. According to the neighbor discovery
RFC, reachable time is 30 seconds. After that, a couple of probes once a second
and the rogue router is declared unreachable. And at that point the host
should switch over to a router that is actually reachable.

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Apr 2011 11:56:58 +0200

Hi,

> should switch over to a router that is actually reachable.

Possibly it switched to the "proper router" but continued to use the
no-longer-working source address (6to4-based)...

That's at least what I've observed on my Linux systems at home - if a 
"rogue RA" is seen, the Linux will eventually stop using that router, but
the rogue IPv6 address will stick, and will continue sabotaging IPv6 for
a long time.  (Same scope as the "working" address, so source address
selection doesn't help)

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: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Apr 2011 22:12:52 +1200

Could you look at the advice re Rogue RA in
draft-ietf-v6ops-6to4-advisory-00 and suggest how it can
be made more complete?

Section 4.1 bullet 5, the end of Section 4.2, and Section
4.3 mention this issue.

Thanks
   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Apr 2011 12:45:44 +0200 (CEST)

> Section 4.1 bullet 5, the end of Section 4.2, and Section

Doing a text search for "SAVI" yields 0 hits in the document. I believe it 
would be very valuable to have that included.

<https://datatracker.ietf.org/wg/savi/charter/>

They have a lot of functionality that makes "Rogue RA" a non-problem. If a 
port isn't supposted to have a router, RAs are suppressed.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Apr 2011 13:22:25 +0200

In your letter dated Wed, 13 Apr 2011 11:56:58 +0200 you wrote:
>(Same scope as the "working" address, so source address
>selection doesn't help)

Isn't that where you get into longest match. In this case I would guess that
an address from a Monash prefix would be a better match for
the Monash website than a 6to4 address.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Apr 2011 13:32:29 +0200

>Section 4.1 bullet 5, the end of Section 4.2, and Section

What about advising people running official routers to have at least one
router on each lan with the priority set to high?

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 13 Apr 2011 08:16:25 -0700

www.monash.edu.au
laptops.
> By tracking down and disabling IPv6 on that laptop and/or disabling IPv6
on all the Macs we were kept busy, but were keeping the problem manageable.
committee meetings !!
> It was a laptop tunneling all IPv6 traffic out to a 6to4 relay and then
back into Monash - slow access.
> And at 4:30pm each day the user took the laptop home, but the Macs still
had a default IPv6 route and continued sending IPv6 traffic to the PC's
Ethernet address until the route expired -- blackholing all IPv6 traffic.
> But I promised that after we got over _this_ problem, all would be well
with IPv6.
>
> So, yes, unsuccessful 6to4 connections did almost stop/reverse Monash's
IPv6 content-provider rollout.

Thanks.  Real lessons from a real network.

Cb

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Apr 2011 03:30:43 +1200

On 2011-04-13 22:45, Mikael Abrahamsson wrote:
> Doing a text search for "SAVI" yields 0 hits in the document. I believe
> it would be very valuable to have that included.
> 
> They have a lot of functionality that makes "Rogue RA" a non-problem. If
> a port isn't supposted to have a router, RAs are suppressed.

Right, but is there anything an ISP can install before IPv6 Day?

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Apr 2011 17:43:39 +0200 (CEST)

> Right, but is there anything an ISP can install before IPv6 Day?

Well, one strong recommendation is to filter everything that is not ARP or 
IP ethertypes in the access equipment. This is very important if you don't 
have any IPv6 SAVI functionality. It completely removes the rogue RA 
problem.

It's of course a problem if you're delivering native IPv6 (without SAVI 
type security features), but if you do, then I guess the better way is to 
make sure your RAs are sent with higher priority than I guess Windows 
would use by default?

---

From: james woodyatt <[email-masked]>
Date: Wed, 13 Apr 2011 10:05:45 -0700

On Apr 13, 2011, at 02:22 , John Mann (ITS) wrote:
> 
> As I remember it ... in November 2008, I enabled IPv6 on http://www.monash.edu.au...

I think current data would be more useful in this discussion than outdated anecdotes.

When I review the data at <http://stats.ottix.net/ipv6/>, what I see is that a lot of academic networks are numbering their local area networks with public IPv4 addresses and that a fair number of hosts on those networks are successfully getting workable IPv6 service over 6to4 through the Ottowa IX anycast relay.  One imagines that many of those hosts might get better Internet service overall if were stop using 6to4, but the data at OttIX is inconclusive on that question.

It seems to me that I-D.ietf-v6ops-6to4-advisory needs to be nailed to the doors of the IT departments at every single one of those universities and colleges that you see listed in that page.  If you're going to number your networks with public realm IPv4 addresses, then you really need to think about how you're going to handle 6to4 traffic.  Some of the hosts on your network will be expecting to use it, and you should figure out how you're going to make it work as well as possible, so long as you continue to number out IPv4 public realm space.

Having IETF move RFC 3056 and RFC 3068 to Historic status won't solve any of your problems.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 13 Apr 2011 19:22:13 +0200

> It seems to me that I-D.ietf-v6ops-6to4-advisory needs to be nailed to the doors of the IT departments at every single one of those universities and colleges that you see listed in that page.  If y…

Ironic. The picture you paint is that an IPv6 transition technology could be providing an incentive for operators to move networks numbered with global IPv4 addresses to private IPv4 addresses.

- Mark

---

From: james woodyatt <[email-masked]>
Date: Wed, 13 Apr 2011 11:35:32 -0700

> Ironic. The picture you paint is that an IPv6 transition technology could be providing an incentive for operators to move networks numbered with global IPv4 addresses to private IPv4 addresses.

...and/or roll out native IPv6 service.  Standing athwart the path to progress with a stop sign in hand isn't going to work for anyone.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Apr 2011 20:36:00 +0100

On 13/04/2011 19:35, james woodyatt wrote:
> ...and/or roll out native IPv6 service.  Standing athwart the path to
> progress with a stop sign in hand isn't going to work for anyone.

No, but as a medium-term objective, removing automatic 6to4 tunnel creation 
(e.g. the Linksys WRT610N) and then later, the ability to manually create 
6to4 tunnels in operating systems and other software would probably be 
considered useful by the operator community at least.  I can't say how 
end-users or prod-dev people would feel about this.

As a long term objective, removing 6to4 support is probably good for everyone.

How do we get to these positions from where we are right now?

Nick

---

From: Martin Millnert <[email-masked]>
Date: Wed, 13 Apr 2011 16:48:13 -0400

> As a long term objective, removing 6to4 support is probably good for everyone.

Yes, so the question is when the appropriate time to describe the
phase-out plan is.  
  A real phase-out plan would probably include one date where anycast
relays began sending ICMP-please-uninstall-yourself back to hosts' 6to4
adapters (and stop routing them).

> How do we get to these positions from where we are right now?

1. ISPs rolling out native v6 is a decent 6to4-mitigation technique
which will go a long way to mitigate the problem.  (How many residential
users get public IPv4 behind their home gateway?)

2. Vendors cleaning up broken 6to4 code (various internet sharing
schemes that are broken comes to mind) and shipping updates will be a
massive win, at worst it will start reversing a bad trend.
  And the role I see for the IETF here is to point out what's broken and
give appropriate recommendations on fixes (in a wording that convinces
product managers that they should actually do something about it...)

3. Disabling automatic 6to4-enabling on hosts would be good, too, like
you say (virtually everyone seems to agree about this?).

#2 begs me to question: 
  Brian, 4.1 in draft-ietf-v6ops-6to4-advisory-00: "This is bad practice
- it should always be a conscious decision by a user to enable 6to4."
Would you have a comment on increasing the usage of 2119-wording in the
draft?  Is a change of the above "should" to "MUST" inappropriate, the
draft being a advisory text, and all?

Regards,
Martin

---

From: "John Mann (ITS)" <[email-masked]>
Date: Thu, 14 Apr 2011 07:52:21 +1000

Mikael

> implementing proper filtering (SAVI) in the network is important after all

We were/are doing as much ingress filtering as we can.
We use mostly Cisco Catalyst 3750G switches in the edge network, and do
"dhcp snooping" "bpdu guard" "switchport port-security ..." "storm-control
broadcast" etc. to sanitise L2 and IPv4.
At the time, there were limited options for sanitising IPv6 traffic. Not
sure about now.

Doesn't SLAAC and "privacy addresses" would make it hard to tie down which
IPv6 client addresses should be on which user port, compared to "dhcp
snooping" being able to create a 1:1 mapping between Ethernet address and
IPv4 address.

I hadn't heard of "SAVI" in Cisco switches.  Do they call it something else?

Thanks,
    John

---

From: "John Mann (ITS)" <[email-masked]>
Date: Thu, 14 Apr 2011 08:11:03 +1000

Mikael

On 14 April 2011 01:43, Mikael Abrahamsson <[email-masked]> wrote:

> ,,,
> make sure your RAs are sent with higher priority than I guess Windows would
> use by default?

More "outdated anecdotes" ...

My testing did *not* show that setting
   ipv6 nd router-preference High
on Cisco routers was enough to _reliably_ get (Mac OS X 10.4 / 10.5) hosts
to ignore rogue Windows 6to4 routers.

It seemed like those Macs would use the first RA they saw ...

And, not implementing RFC 3484 led to other faulty behavior like trying to
connect to a Global IPv6 address, when the Mac only had link-local IPv6
addresses.

    John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Apr 2011 19:30:01 +1200

On 2011-04-14 08:48, Martin Millnert wrote:

<snip>

> draft being a advisory text, and all?

Well, it will get published a lot quicker if it is kept as an
Informational draft without formal language.

I think you should raise this comment against
draft-ietf-v6ops-6to4-to-historic-00.txt, which says:

"2. Implementations capable of acting as 6to4 routers SHOULD NOT
    enable 6to4 without explicit user configuration.
...
3.  If implemented in future products 6to4 SHOULD be disabled by
    default"

     Brian

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 14 Apr 2011 09:54:33 +0200

Having IETF move RFC 3056 and RFC 3068 to Historic status won't solve
any of your problems.

GV> it doesn't solve the problem at this current moment, however as 6to4
should popup less in the future, it will avoid the problem becoming an
incremental problem. The advisory document from Brian is good help users
get a better 6to4 experience then when these advisory rules would not of
existed.

G/

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 18 Apr 2011 01:16:56 +0200

On Tue, Apr 05, 2011 at 12:32:45PM -0700, Dmitry Anipko wrote:
> disable Anycast 6to4 functionality by default. If an OS vendor has
> an ability to do that for existing implementations, is there a WG
> consensus whether such changes should be done before the IPv6 day? 

Speaking only for myself (obviously), I'd like to see 6to4 disabled by
default, or at least priority lowered below IPv4. There's no point in
having folks run into known problems - I think that would be detrimental
to the overall goal.

And while you're at it, fixing the ICS RA-on-WAN and RA undeprecation
problems as well would be appreciated. :-)

Best regards,
Daniel (an operator voice)

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