Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01)

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Wed, 13 April 2011 21:23 UTC

Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: softwires@ietfc.amsl.com
Delivered-To: softwires@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2FADBE083D for <softwires@ietfc.amsl.com>; Wed, 13 Apr 2011 14:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vPUGp66L95Q for <softwires@ietfc.amsl.com>; Wed, 13 Apr 2011 14:23:37 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id DCCB1E0742 for <softwires@ietf.org>; Wed, 13 Apr 2011 14:23:36 -0700 (PDT)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 13 Apr 2011 14:23:35 -0700
Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 13 Apr 2011 14:23:35 -0700
Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Wed, 13 Apr 2011 14:23:33 -0700
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Mark Townsley <mark@townsley.net>
Date: Wed, 13 Apr 2011 14:23:30 -0700
Thread-Topic: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01)
Thread-Index: Acv5TMaCdWSJdP6dQiSBHNMXJ0QTDgA0Bkcw
Message-ID: <DD1A73D9E9C89144A927C5080F70285A015E3F1E02AE@NA-EXMSG-S702.segroup.winse.corp.microsoft.com>
References: <DD1A73D9E9C89144A927C5080F70285A015E3F1E01DE@NA-EXMSG-S702.segroup.winse.corp.microsoft.com> <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net>
In-Reply-To: <5C4F8A4C-A7AE-4E6E-960B-650DED19982F@townsley.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 21:23:38 -0000

Hello Mark,

I agree that if the 4rd IPv4 address is only used in such a way, that applications cannot start use the address directly (such as e.g. perform binding to the address assigned to an interface), then this issue doesn't apply.

However I'm not sure that the current draft makes clear that this is the only intended use. For example, it defines CE as "a node.. it may be a host..", instead of saying that CE is a function implemented in a host. Also, the introduction in section 1 also does not include NAPT as a required element of the solution (it says "The 4rd mechanism tunnels IPv4 over IPv6 using an algorithmic mapping.."). 

Some existing implementations may be assigning the address used for NAPT to an interface (and as long as the address is for the host exclusive use, an implementation is able ensure such usage doesn't cause problems) - that's what Windows ICS you mentioned actually does.

With the current language, I don't think it is unlikely that implementers will be tempted to assign a 4rd IPv4 address to an interface (e.g. with intent to enable wider set of apps to work without a NAPT in the middle), and if the spirit of the draft is that the IPv4 address assigned to the node by 4rd should be only be used for CE function, performing NAPT, (or more specifically, should not be made available for applications to bind) then I think it may be useful to state it as such to guide implementers.

Thank you,
Dmitry

-----Original Message-----
From: Mark Townsley [mailto:mark@townsley.net] 
Sent: Tuesday, April 12, 2011 1:04 PM
To: Dmitry Anipko
Cc: softwires@ietf.org
Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01)


Hello Dmitry,

My view is that 4rd is most easily understood if and only if it connects to a CE function that is performing NAPT. The CE function may be in what is traditionally considered a host, or in what is clearly a router.

More specifically, a device that is forwarding packets from one interface (virtual or otherwise) to another through a NAPT that has one interface with IPv6 configured (via DHCPv6 or otherwise) as performing 4rd (which enables dual-stack via a port-restricted IPv4 address for the NAPT using IPv6 as the transport) then you a have a 4rd CE. That could be a "host" in that it is a Windows PC with internet connection sharing for IPv4 turned on and hence forwards packets between interfaces with a NAPT due to the IPv4-enabled interface created when 4rd is configured. 

I would avoid anything that requires the host forwarding table to be altered to accommodate 4rd. Instead, the NAPT function that is already present in a small router or host configured to look like a router is modified to use a set of ports that it is allowed to use when 4rd is enabled. 

- Mark