Re: draft-ietf-v6ops-6to4-to-historic (yet again)

Tim Chown <tjc@ecs.soton.ac.uk> Tue, 26 July 2011 14:15 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAFF21F8CB5 for <ietf@ietfa.amsl.com>; Tue, 26 Jul 2011 07:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4HafjcSkV80 for <ietf@ietfa.amsl.com>; Tue, 26 Jul 2011 07:15:07 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 4B10421F8AA8 for <ietf@ietf.org>; Tue, 26 Jul 2011 07:15:06 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p6QEF2t0029807 for <ietf@ietf.org>; Tue, 26 Jul 2011 15:15:02 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p6QEF2t0029807
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1311689702; bh=uFkxO5fSOwUZ38TAF9gyL526dKI=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=HbqReXUw9cnFuyTAspwpeqEATyzEkREQNVMYMV8+eFZiOW4SSsXI7xmw/557SwoCN fRXqluZjrsMr0IZBkD+WZ+K9etT6h17caJq+3k+WTbZ3Od27oYDLIzQONBl7Q/BPpw DcXhxMMKcTkUhMBUrK4HN0DbWY/SSvCt6OIltI0M=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id n6PFF20366136564Gl ret-id none; Tue, 26 Jul 2011 15:15:02 +0100
Received: from [IPv6:2001:df8::112:7d1d:53b8:a466:28b4] ([IPv6:2001:df8:0:112:7d1d:53b8:a466:28b4]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p6QEEvVS028391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ietf@ietf.org>; Tue, 26 Jul 2011 15:14:57 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1244.3)
Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net>
Date: Tue, 26 Jul 2011 15:14:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|038a96b178501de6df9159a9611a0231n6PFF203tjc|ecs.soton.ac.uk|80E059EE-12CD-49D1-8426-2BC74C573108@ecs.soton.ac.uk>
References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <80E059EE-12CD-49D1-8426-2BC74C573108@ecs.soton.ac.uk>
To: IETF Discussion <ietf@ietf.org>
X-Mailer: Apple Mail (2.1244.3)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n6PFF2036613656400; tid=n6PFF20366136564Gl; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p6QEF2t0029807
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 14:15:07 -0000

On 25 Jul 2011, at 15:30, Ronald Bonica wrote:
> 
> Please post your views on this course of action by August 8, 2011.

Some observations.

Our own users made use of 6to4 maybe 8+ years ago, and at the time it was handy to have.  Today though we're not aware of any of our users running 6to4 intentionally. We have IPv6 native on site, and anyone who wants home IPv6 connectivity either goes to an ISP that provides it, e.g. A&A in the UK, or they use a tunnel broker.  Brokers have the additional benefit of working through NATs and with dynamic IPv4 endpoints.

Our site sees about 1-2% of all inbound traffic being IPv6, and of that less than 1% is 6to4, and this is only likely to fall further with rfc3484-bis. What 6to4 we do see is probably reasonably robust in that our return path uses the JANET-provided 6to4 relay.  

Most operating systems either already, or before long will, support rfc3484-bis, which means hosts should use IPv4 in preference to 6to4 where both are available.  To choose to use 6to4, the user would need to consciously change their 3484 policy table, assuming their OS supports that (Linux and Windows do, MacOS X Lion appears not to).

Geoff Huston has presented data at IETF80 showing 6to4 brokenness and performance. We now have 'Happy Eyeballs Lite' implemented in Chrome and (I believe, not tested it yet) Firefox, which means the browser can adapt to broken IPv6, whether caused by 6to4 or other factors.

The 6to4-advisory draft suggests off-by-default, which I agree with, and use of relays to improve user experience. The problem is we can't expect every site/ISP to run a relay (or multi-address with 6to4) so there will inevitably always be problems with the 3068 mode of 6to4.

We measured rogue RAs over a two year period on our wireless network.  About 60% of the time at least one host was emitting a rogue 6to4-based RA. While these were mitigated by ramond, it would be good to see vendors fix this; it's not just MS ICS.  Happy Eyeballs is a mitigation for such rogue RAs also.

So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will further reduce what little use there is of 6to4 now, and happy eyeballs will mitigate any remaining instances of its use that are bad. So whether 6to4 is tagged Historic or not, it should be causing significantly less harm.  

Tim