Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status

Pekka Savola <pekkas@netcore.fi> Thu, 07 April 2011 07:42 UTC

Return-Path: <pekkas@netcore.fi>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0CAE3A69FD for <v6ops@core3.amsl.com>; Thu, 7 Apr 2011 00:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.594
X-Spam-Level:
X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu6mAXThROBe for <v6ops@core3.amsl.com>; Thu, 7 Apr 2011 00:42:44 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 637913A69FC for <v6ops@ietf.org>; Thu, 7 Apr 2011 00:42:44 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p377iIoQ014564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 10:44:18 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p377iHIE014561; Thu, 7 Apr 2011 10:44:17 +0300
Date: Thu, 07 Apr 2011 10:44:17 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: Christopher Palmer <Christopher.Palmer@microsoft.com>
In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <alpine.LRH.2.02.1104071034280.14313@netcore.fi>
References: <0AB09EDBCD1C484EBE45978D62F3513C3CD8A349@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <BANLkTimjZ4SjCPE1xS1erf4_9ZEEharNhA@mail.gmail.com> <BANLkTims5GD5r6NLHayn3JqzDpd8K+u7+g@mail.gmail.com> <BANLkTinGNRmYK6-0Xc-2r5VUgz7smYD+hg@mail.gmail.com> <41E97647-E5FF-4077-ACF5-00C157E40C59@bogus.com> <0AB09EDBCD1C484EBE45978D62F3513C3CD8ABB4@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi
X-Virus-Status: Clean
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, Carlos Martinez-Cagnazzo <carlos@lacnic.net>
Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 07 Apr 2011 07:42:45 -0000

On Thu, 7 Apr 2011, Christopher Palmer wrote:
> "A host with a public but natted v4 address will alwas get hosed by this."
>
> A host in that condition will have a broken 6to4 address, but won't experience a degradation in their web experience if they have RFC 3484 implemented.
>
> So really this would be the third proposed 6to4 mitigation:
>
> 1. Ensuring that IPv4->IPv4 is ranked higher than 6to4->IPv6 in the RFC 3484.
> 2. Changing default host behavior. (still being debated)
> 3. Deprecation of the prefix.
>
> Given (1) and (2), the operational value of 3 is still lost on me. Is the expectation that ISPs stop routing 6to4 packets? Is this a signal that we don't just hate 6to4, but we super hate it?

This will require an update in the RFC 3484 implementation.  Maybe 
this is what you meant, or maybe not.

Joel is probably referring to this:

http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02#section-2.4

(This issue has a lot of history -- known for some 7-8yrs, see 
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03#section-2.1)

If I understand this correctly:

The NAT44ting/6to4 gateway has public IP 1.1.1.1 (WAN)
It is advertising 2002:0101:0101:0::/64 out on LAN.
It is doing NAT on LAN.

Hence, hosts behind such gateway have IPv6 address 
2002:0101:0101:0::EUI64 and 192.168.1.1.

When connecting to a dual-stack server with IP addresses 2.2.2.2 and 
2001:db8::1.

It will use 6to4 instead of IPv4 through NAT. FAIL.

If the client would have had IP address 1.1.1.2 and 
2002:0101:0101:0::EUI64, with (current) RFC3484 implementation, it 
would have preferred IPv4 instead of 6to4.

So, there are are really two layers of RFC3484 brokenness:

  1) not implemented at all
  2) 6to4 is used if v4 has mismatching scope (private->public)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings