[pcp] PCP proxying / relaying

"Dan Wing" <dwing@cisco.com> Fri, 11 March 2011 20:17 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: pcp@core3.amsl.com
Delivered-To: pcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7B13A6944 for <pcp@core3.amsl.com>; Fri, 11 Mar 2011 12:17:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.499
X-Spam-Level:
X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 2IV8zBasdHnv for <pcp@core3.amsl.com>; Fri, 11 Mar 2011 12:17:18 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 276AB3A691A for <pcp@ietf.org>; Fri, 11 Mar 2011 12:17:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4061; q=dns/txt; s=iport; t=1299874718; x=1301084318; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=H/FoCNFxVTjuVUoNFqF3kUc5NjXX9zJQ6Wmf8mMUGrw=; b=fakX05Cj3te11dO/wh5+WROpsPhXeC45zAQlZHpuXHbvmdafMjI/++4R ErVo8apkHStEeuBBQag7GcA9Tur7Gq6NyVUyPDNPkxTo8+z7gG8rcWWOE C2LTwJee+As8QWDjXefg7RXjrtsz+hqXaZUcQY2khy9hZQyY+fGGyGm+P 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPsSek2tJV2c/2dsb2JhbACaSItpd6ZAnCSDG4JHBIUp
X-IronPort-AV: E=Sophos;i="4.62,304,1297036800"; d="scan'208";a="319640144"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-2.cisco.com with ESMTP; 11 Mar 2011 20:18:26 +0000
Received: from dwingWS ([10.21.79.146]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2BKIQxh005666; Fri, 11 Mar 2011 20:18:26 GMT
From: Dan Wing <dwing@cisco.com>
To: pcp@ietf.org, Francis.Dupont@fdupont.fr
Date: Fri, 11 Mar 2011 12:18:25 -0800
Message-ID: <2d0501cbe029$7a96b850$6fc428f0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvgKXov4fOkvFqFQL6y8Ko/8cU0oA==
Content-Language: en-us
Subject: [pcp] PCP proxying / relaying
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2011 20:17:19 -0000

A subscriber might have multiple IP addresses, from the same ISP.  There are

several ways this could occur:

  * IPv6 subscriber with a /64 (e.g., native IPv6, with a CPE implementing 
    Simple CPE Security [RFC6092]).  This is unrelated to IPv4, and might
    be an IPv6-only subscriber, a Dual-Stack Lite subscriber, 6rd
subscriber,
    dual-stack subscriber, and so on.

  * Dual-Stack Lite subscriber, with an IPv6 /64 and multiple IPv4 addresses

  * IPv4-only subscriber with multiple IPv4 addresses (e.g., "business
service"),
    behind a CGN.

(There are probably others, which don't yet exist on anyone's radar, such as
an ISP offering filtering (firewalling) for an IPv4 subscriber, in order to
block incoming IPv4 address sweeps, pings, etc., prior to consuming access
link bandwidth.)


For all of these cases, consensus seems to be that we do not want any
arbitrary host to create, modify, or delete mappings for any other arbitrary
host.  Rather, we want only the subscriber's CPE to do that.  The subscriber
would need to log into the CPE to do that, using the CPE's administrative
interface (e.g., HTTP with the administrative username/password).


If PCP is implemented in end hosts (e.g., PCs), this is complicated by PCP
clients which send PCP requests to their default gateway.  Several network
topologies could exist.  For example, with DS-Lite or other dual-stack
technologies with an ISP-operated PCP-aware CGN, two scenarios would be in
operation at the same time, one scenario for each address family.

Whenever there are multiple IPv4 addresses at the subscriber's premise,
either because of DS-Lite or because of a "business class" service, the
scneario looks like this:
   [IPv4 host]--[PCP-aware CPE router]--------[PCP server and CGN at
ISP]--<Internet>

For IPv6, the PCP-aware router in the CPE implements Simple CPE Security
[RFC6092] and the scenario looks like this:
   [IPv6 host]--[PCP-aware CPE router]--<Internet>


There are two ways that PCP can be handled in the CPE router:

  1.  CPE router passes packet using internal node's IPv4 address.  This
      is simple routing.
  2.  CPE router passes packet using the CPE router's own IPv4 
      external address (e.g., for DS-Lite would be 192.0.0.2).  This
      requires doing "PCP proxying" or "PCP Relaying" (see below).
  3.  CPE router passes packet using the CPE router's external 
      IPv6 address.  This requires doing "PCP proxying" or "PCP 
      Relaying".

PCP proxying:  described in draft-bpw-pcp-proxy-00.txt.  Implements
a PCP server in the CPE router which understands most of the protocol.

PCP relaying:  this is more akin to how DHCP Relay works today.  In
DHCP relay, a DHCP-aware router on the local LAN picks up the 
broadcasted message, populates the GIADDR field (so that the router
does not need to maintain state) and forwards the DHCP message to
the DHCP server's IP address.  The packet's source address is
re-written to the router's IP address, so the DHCP server's response
goes back to the router, which uses the GIADDR to send the message
back to its original interface.  

Critical distinction between PCP Proxy and PCP relay is this:  the
relay understands very, very little of the protocol.


A concern I have, which others have raised usually in conjunction
with the term "ALG", is that PCP proxying might prevent the PCP
protocol from being extended.  For example, introducing a new 
OpCode requires updating the PCP Client and PCP server (which is 
normal, necessary, and expected) but if it requires also updating
the PCP Proxy, we will have harmed ourselves.  As we all know,
software in CPE routers is seldom, if ever, upgraded by users.
Most don't know their CPE routers even run software that can be
upgraded, don't know how to do it, or are afraid of bricking it.


My question to the group, and to Francis:  how close to a "relay"
can we get, so that the PCP-aware software in the CPE router 
does the least amount of work?

-d