Re: [Int-area] AD review of draft-ietf-intarea-shared-addressing-issues

Jari Arkko <jari.arkko@piuha.net> Tue, 18 January 2011 12:25 UTC

Return-Path: <jari.arkko@piuha.net>
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 633713A6E74 for <int-area@core3.amsl.com>; Tue, 18 Jan 2011 04:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level:
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 c0W5evBRqRzE for <int-area@core3.amsl.com>; Tue, 18 Jan 2011 04:25:25 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B69E63A6E7B for <int-area@ietf.org>; Tue, 18 Jan 2011 04:25:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A8F072CC3A; Tue, 18 Jan 2011 14:28:00 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hewAZRQrWyxp; Tue, 18 Jan 2011 14:27:59 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B83B62CC2D; Tue, 18 Jan 2011 14:27:59 +0200 (EET)
Message-ID: <4D35874F.8090903@piuha.net>
Date: Tue, 18 Jan 2011 14:27:59 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Matthew Ford <ford@isoc.org>
References: <4D35459F.6030500@piuha.net> <E6CFE9BB-2A4D-4A11-95A6-C20D1B4C5C86@isoc.org>
In-Reply-To: <E6CFE9BB-2A4D-4A11-95A6-C20D1B4C5C86@isoc.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-intarea-shared-addressing-issues@tools.ietf.org, Internet Area <int-area@ietf.org>
Subject: Re: [Int-area] AD review of draft-ietf-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: Tue, 18 Jan 2011 12:25:26 -0000

Matthew,

>>> In current deployments, one important and widely used feature of many
>>> CPE devices is the ability to open incoming ports (port forwarding)
>>> either manually, or with a protocol such as UPnP IGD.  If a CGN is
>>> present, the port must also be open in the CGN.  The situation may be
>>> alleviated somewhat if the CGN architecture is composed of only one
>>> NAT level (no NAT in the CPE) as for DS-Lite, although a service
>>> provider operating this solution will still be required to offer some
>>> means for configuring incoming ports by their subscribers.  This may
>>> be either via a UPnP or NAT-PMP relay over a tunnelled direct
>>> connection between the CPE and CGN, or a web interface to configure
>>> the incoming port mapping on the CGN. 
>>>       
>> I think this text could be improved. You need to make different points here.  One point is that when the NAT moves from a CPE to a CGN device, the service provider has less incentives and even technical possibilities to proivde the port opening capability. Another point is that if two devices (the home gw and the CGN) need to co-operate in order to do this, then a new protocol is needed.
>>     
>
> Sure, is this clearer?
>
> "In current deployments, one important and widely used feature of many
> CPE devices is the ability to open incoming ports (port forwarding)
> either manually, or with a protocol such as Universal Plug and Play
> Internet Gateway Device (UPnP IGD) [ref].  If a CGN is present, the 
> port must also be opened in the CGN. CGN makes subscribers dependent 
> on their service provider for this functionality.
>
> If the CPE and the CGN are required to co-operate in order for port forwarding 
> functionality to work, protocol development will be required to provide an automated 
> solution. If the CGN architecture is composed of only one NAT level (no NAT in
> the CPE) as for DS-Lite, the service provider will still be required to offer some 
> means for configuring incoming ports by their subscribers.  This may
> be either via a UPnP or NAT-PMP relay over a tunnelled direct
> connection between the CPE and CGN, or a web interface to configure
> the incoming port mapping on the CGN."
>   

Much better. Thanks.

>>> o Applications that do not use any port (e.g., ICMP) - where address
>>>  sharing solutions map subscribers to (private) IP addresses on a
>>>  one-to-one basis this will not be an issue, otherwise such
>>>  applications will require special handling - see Section 9 <http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-02#section-9> for
>>>  more discussion of this;
>>>  
>>>       
>> I'm not sure I understand this. First off, Section 9 clearly states that special handling is required anyway. In addition, the nature of the mapping (one to one or something else) does not seem to impact the handling of ICMP, because no matter what the mapping is, it won't be used by that special handling code as an incoming ICMP uses just public addresses.
>>
>>     
>
> You're right. It is sufficient to say 'Applications that do not use any port (e.g., ICMP) - will require special handling - see Section 9...'
>   

OK

>   
>>> For CGNs, subscribers will be dependent on the
>>> set of ALGs that their service provider makes available.  A
>>> service provider-based NAT may, or may not, support NAT-traversal
>>> for IKE [RFC3947 <http://tools.ietf.org/html/rfc3947>] for example. 
>>>       
>> This seems incorrect. IKE runs on UDP, and RFC 3947 is about endpoints working through NATs. The RFC even specifically mandates a change of the IKE port number in order to avoid some older NATs that might "help" IKE by doing something that ends up being harmful.
>>     
>
> Yes, I agree, bad example.
>   

OK

>> In general, the draft seems to assume that ALGs are required. I think it would be fairer to say that they are required in some cases, and in many other cases end-to-end protocol mechanisms have developed to work around lack of ALGs, to the point of it being preferable to avoid any support in the NAT.
>>
>>     
>
> I'll add some text to the second bullet in Section 6 on p.12 and the first bullet in Section 6 on p.13 to clarify this.
>   

Good.

>>> Viewed from the content provider, a
>>>   subscriber behind a CGN geolocates to wherever the prefix of the CGN
>>>   appears to be; very often that will be in a different city, and
>>>   sometimes in a different country, than the subscriber.
>>>       
>> Do we have evidence of real-life commercial ISP service with the NAT and the subscriber in different countries? I would think that is unlikely... just say "... in a different city than the subscriber".
>>     
>
> I'm not aware of any concrete example, so you're proposed edit is fine for me.
>   

OK

>>> here balancing
>>>   is achieved by deterministically routing traffic from specific source
>>>   IP addresses to specific servers, sudden imbalances in load may be
>>>   experienced as address sharing is enabled for some of those source IP
>>>   addresses. 
>>>       
>> I think that sudden changes due to enabling address sharing is a rather theoretical problem. Its not like a subscriber's address is suddenly used by a CGN. More likely, CGN address pools are taken from address space that is currently unused or at least not recently used, and that growth in the traffic from a CGN happens gradually, as more subscribers get added to it.
>>
>>     
>
> Fair enough - I'll try to wordsmith a little to reflect your comment.
>
> Thanks again for the review,
>   

Thanks for a very quick reply.

Jari