Re: [v6ops] 6to4v2 (as in ripv2)?

"Frank Bulk" <frnkblk@iname.com> Mon, 08 August 2011 04:22 UTC

Return-Path: <frnkblk@iname.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC121F877F; Sun, 7 Aug 2011 21:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.354
X-Spam-Level:
X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D20pK9NAmZJ3; Sun, 7 Aug 2011 21:22:32 -0700 (PDT)
Received: from premieronline.net (smtp1-3.premieronline.net [96.31.0.23]) by ietfa.amsl.com (Postfix) with ESMTP id 40BD621F8548; Sun, 7 Aug 2011 21:22:29 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26;
Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 29531710-1729245 for multiple; Sun, 07 Aug 2011 23:22:53 -0500
From: Frank Bulk <frnkblk@iname.com>
To: 'Keith Moore' <moore@network-heretics.com>
References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <m1QlzXt-0001gSC@stereo.hq.phicoh.net> <52599079-C6E9-48F9-AFAE-78E7989FB105@network-heretics.com>
In-Reply-To: <52599079-C6E9-48F9-AFAE-78E7989FB105@network-heretics.com>
Date: Sun, 07 Aug 2011 23:22:29 -0500
Message-ID: <009e01cc5582$d51bcc60$7f536520$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcxMiriIWmxxIR09QDaIGoHS//aBGAIfH75Q
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net
X-SpamDetect: : 0.000000
X-Info: aspam skipped due to (g_smite_skip_auth)
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=3 Friend=408 Surbl=0 Catch=0 r=0 ip=199.120.69.26
X-IP-stats: Incoming Outgoing Last 0, First 883, in=13688188, out=64386, spam=0 Known=true ip=199.120.69.26
Cc: IPv6 Operations <v6ops@ietf.org>, ietf@ietf.org, Philip Homburg <pch-v6ops@u-1.phicoh.com>
Subject: Re: [v6ops] 6to4v2 (as in ripv2)?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: frnkblk@iname.com
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 04:22:33 -0000

Hmmm...it's been well documented that 6to4 causes bad experiences, not
decreases the chance of having them.  Since much of the IPv6-accssible
content is dual-stacked, unless you're using an application that implements
HE, the odds are in your favor to use IPv4 rather than IPv4+6to4.

Frank

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Keith Moore
Sent: Wednesday, July 27, 2011 1:25 PM
To: Philip Homburg
Cc: IPv6 Operations; Keith Moore; ietf@ietf.org
Subject: Re: [v6ops] 6to4v2 (as in ripv2)?

On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote:

> In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote:
>> In message <4E2F4491.30102@gmail.com>, Brian E Carpenter writes:
>>> Of course, if implementors choose to drop the code you might not be
>>> able to upgrade software versions - but hopefully by that time you
>>> will have native IPv6 service anyway.
>> 
>> Which is exactly why HISTORIC is NOT appropriate. 
> 
> With rfc3484-revise and the documented brokenness of 6to4, it doesn't make
> any sense for implementors to offer 6to4 anyhow.

False.  It makes even more sense to offer 6to4 because it significantly
decreases the chance that it will cause a bad experience for users of
services that provide both v4 and v6 addresses, while increasing the chance
letting local hosts/users talk to v6-only services/hosts.

<snip>

Keith

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops