Subject: [v6ops] 6to4-historic summary point: 5. "Clarifications"

From: Fred Baker <[email-masked]>
Date: Wed, 27 Apr 2011 13:17:40 -0700

> 5. "Clarifications"
> -------------------
> 
>> The approach that's most likely to get widespread support is:
>> 
>> 1. make it not be on by default
>> 2. make noise about it being A Bad Thing
>> 3. deprioritise 2002::/16 addresses in resolver libs
>> 4. then make the option hard to find on operating systems / CPEs
>> 5. then remove the option on operating systems
>> 6. then slowly decommission 6to4 relays over many years
>> 
>> draft-ietf-v6ops-6to4-to-historic deals with steps 1-3. 
> 
>    I do think it would be useful to elaborate on the arguments Tore just
>    provided to Dmitry for deprecation of 3056 in the draft, as a form of
>    history writing for the archives.
> 
> Actions: Proposed text?

Tore and Dmitry, this appears to be directed to you. Could you please work with Ole on proposed text?

---

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

> Tore and Dmitry, this appears to be directed to you. Could you please work with Ole on proposed text?

I'd like to reiterate my view that points 4, 5 and 6 are none of the
IETF's business and should not be mentioned in an IETF document.

   Brian

---

From: Tore Anderson <[email-masked]>
Date: Thu, 28 Apr 2011 11:05:51 +0200

* Fred Baker

> please work with Ole on proposed text?

OK:

When 6to4 is used without the mechanism specified in [RFC3068], or as
described in [RFC3056] section 5.2, it will operate in «Peer-to-Peer»
mode where a 6to4-site/host can only communicate with other
6to4-sites/hosts and not with the global Internet. This is problematic
in the situation where such 6to4 connectivity is provided to a site by a
6to4 router (or a 6to4 host with router-like functionality), as the
hosts behind the 6to4 router will not be aware that its 6to4
connectivity is restricted in scope to other 6to4 sites, and could
therefore attempt to use this connectivity for destinations on the
global IPv6 Internet. Doing so will lead to timeouts and a bad user
experience, potentially prompting the user to disable IPv6 entirely.

While this problem could potentially have been mitigated by having the
6to4 router send RAs with a lifetime of 0 that carries a [RFC4191]
More-Specific Route Option for the 6to4 prefix 2002::/16, this method of
implementating a 6to4 router has rarely if ever been done. Also, support
for the [RFC4191] More-Specific Route option is not universally deployed
in common end-user operating systems, and furthermore, one particularly
ubiquitous end-user operating system is known to incorrectly interpret a
RA lifetime of 0 as «infinite». These realities renders the suggested
work-around operationally ineffective on today's Internet.

Perhaps too long? Ole, feel free edit and rewrite as you see fit.

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

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 30 Apr 2011 18:01:46 -0700

I agree with the recommendations 1-2-3 in the section 4 in the draft version dated April 27 and I think those are sufficient, hence I suggest to remove wording regarding deprecation of RFC 3056 and prefix 2002::/16.

Thank you,
Dmitry
________________________________________
From: Fred Baker [[email-masked]]
Sent: Wednesday, April 27, 2011 1:17 PM
To: Tore Anderson; Dmitry Anipko
Cc: [email-masked] WG
Subject: 6to4-historic summary point: 5. "Clarifications"