IETF Logo Mail Archive

Re: [Int-area] Revving draft-intarea-shared-addressing-issues

Dave Thaler <dthaler@microsoft.com> Fri, 18 June 2010 02:19 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E643A6874 for <int-area@core3.amsl.com>; Thu, 17 Jun 2010 19:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.338
X-Spam-Level:
X-Spam-Status: No, score=-110.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 p9YtSXe6fTbI for <int-area@core3.amsl.com>; Thu, 17 Jun 2010 19:19:05 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5A0023A67AE for <int-area@ietf.org>; Thu, 17 Jun 2010 19:19:05 -0700 (PDT)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 17 Jun 2010 19:19:04 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.160.7; Thu, 17 Jun 2010 19:19:05 -0700
Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.101]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 17 Jun 2010 19:19:05 -0700
From: Dave Thaler <dthaler@microsoft.com>
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [Int-area] Revving draft-intarea-shared-addressing-issues
Thread-Index: AQHLCJzpPlC2L8n+eEa0/YO9dB51gJJ8PUGAgACdQ4CAAiHRAIACrQsAgACNHQD//6BPQIAAhwCAgAADDwD//4xh8IAFc/uA//+l8OA=
Date: Fri, 18 Jun 2010 02:18:50 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF652C0680C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
References: <1339FDB5-B518-4210-9D7E-6711E4E10DB0@isoc.org> <020401cb08ec$97759280$b94c150a@cisco.com> <4C11EB81.9090407@gmail.com> <01ee01cb0a4c$1d528290$7844150a@cisco.com> <6A8F3173-1CC1-4A0A-A96D-EE5AF1D8B58D@isoc.org> <04b601cb0be9$308d1930$7844150a@cisco.com> <9B57C850BB53634CACEC56EF4853FF652C05FEC1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <BLU137-W306A1BCDBB7C8182DAC35293DC0@phx.gbl> <05a001cb0bfe$5fc2c5f0$7844150a@cisco.com> <9B57C850BB53634CACEC56EF4853FF652C060363@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <AANLkTikOZ58r8RJP-M3k7HUnOV8_RvKbHeHzLTbnkKmu@mail.gmail.com>
In-Reply-To: <AANLkTikOZ58r8RJP-M3k7HUnOV8_RvKbHeHzLTbnkKmu@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF652C0680C1TK5EX14MBXW604w_"
MIME-Version: 1.0
Cc: "int-area@ietf.org" <int-area@ietf.org>, Bernard Aboba <bernard_aboba@hotmail.com>, "brian.e.carpenter@gmail.com" <brian.e.carpenter@gmail.com>, "draft-ford-shared-addressing-issues@tools.ietf.org" <draft-ford-shared-addressing-issues@tools.ietf.org>
Subject: Re: [Int-area] Revving draft-intarea-shared-addressing-issues
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2010 02:19:08 -0000

My point is that anything that sends out RAs with 6to4 prefixes derived from RFC 1918 is in violation
of the RFC and thus isn't doing 6to4, they're doing some proprietary extension to 6to4, not the
standard "6to4".

That's different from Dan's point about if a public IPv4 address is given to multiple devices
(which changes the IP model in ways I warned about in the port restricted IP issues doc)
then the standard "6to4" will break.

-Dave

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Thursday, June 17, 2010 5:38 PM
To: Dave Thaler
Cc: Dan Wing; Bernard Aboba; ford@isoc.org; int-area@ietf.org; brian.e.carpenter@gmail.com; draft-ford-shared-addressing-issues@tools.ietf.org
Subject: Re: [Int-area] Revving draft-intarea-shared-addressing-issues

On Mon, Jun 14, 2010 at 1:23 PM, Dave Thaler <dthaler@microsoft.com<mailto:dthaler@microsoft.com>> wrote:
The in-home NAT cannot turn on 6to4, it's simply not possible.
To turn on 6to4 per the RFC one has to have a globally unique
IPv4 address, which it doesn't in the diagram above.

It shouldn't, but it does. There are home routers in the field that will send out RAs, with 6to4 prefixes derived from RFC1918 addresses, even if they have private IP addresses on the WAN side. The fact that this will never result in working connectivity doesn't prevent the gateways from doing it anyway.

Which by the way is why I think this type problem can only be fixed in the hosts OS and not in the home router (because users never upgrade home routers).

Cheers,
Lorenzo

v2.23.0 | Report a Bug | By Email