IETF Logo Mail Archive

Re: [pcp] [BEHAVE] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option

"Dan Wing" <dwing@cisco.com> Fri, 07 September 2012 23:35 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55A221E8084; Fri, 7 Sep 2012 16:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7wJTyzV7mkL; Fri, 7 Sep 2012 16:35:04 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39C3F21F8581; Fri, 7 Sep 2012 16:35:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=966; q=dns/txt; s=iport; t=1347060904; x=1348270504; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=YLmnc2BtpIsP1eem+xPQRNum+HxcSxFl50wiMNQvu2c=; b=ECrWqHlSSZJjH5hZxbWMa2TZ2nVYATP8WIRAtgA7S+dlYZdER59ZDbxI 7eV+RYPRblYawgDtVIJHZRwJIiH179OyXmpaKecXQKiYd0DkrpH+QRomv RoYpI80s8dz3lQt8ihx3CIxn6Q4mPSQ/r6aiCZM99m42Yh1SSymdihRNl Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAGyDSlCrRDoG/2dsb2JhbABFq1SPfYEHgiEBAQQICgEXED8NAwIJDzcZIxsBAQQBHReHbZsaoBiLF4YvA4hThQ6WMYFngwQ
X-IronPort-AV: E=Sophos;i="4.80,388,1344211200"; d="scan'208";a="54476878"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 07 Sep 2012 23:35:03 +0000
Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q87NZ3S0023869; Fri, 7 Sep 2012 23:35:03 GMT
From: Dan Wing <dwing@cisco.com>
To: teemu.savolainen@nokia.com, mohamed.boucadair@orange.com, simon.perreault@viagenie.ca
References: <94C682931C08B048B7A8645303FDC9F36E57B08381@PUEXCB1B.nanterre.francetelecom.fr> <504898BD.7000702@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08524@PUEXCB1B.nanterre.francetelecom.fr> <5048AC63.50700@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B085C5@PUEXCB1B.nanterre.francetelecom.fr> <5048C127.50704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E57B08650@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444ABB8@008-AM1MPN1-053.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36E57B08727@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696204453374@008-AM1MPN1-052.mgdnok.nokia.com>
Date: Fri, 07 Sep 2012 16:35:04 -0700
Message-ID: <04f301cd8d51$68b6cbd0$3a246370$@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: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAB0jEWA=
Content-Language: en-us
Cc: pcp@ietf.org, behave@ietf.org
Subject: Re: [pcp] [BEHAVE] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 07 Sep 2012 23:35:04 -0000

...
> > * PCP is needed for NAT64 to accept incoming connections/hosting
> > servers/reduce keepalive messages/etc.
> 
> Only if an operator chooses to provide these goodies to hosts; I have
> no evidence that says all operators who deploy NAT64 are ok to allow
> incoming connections/hosting services/helping hosts to reduce keepalive
> signaling. I do hope PCP finds its place in networks and helps save
> battery etc, but it is not something that can be assumed to happen
> (always).

The MAP Opcode allows those incoming connections, which is separate
from the PEER Opcode to optimize keepalives.  It would be annoying
to implementers, but I could imagine some network operators deploying
a PCP server with PEER enabled but with MAP disabled.  I would
imagine the network operators that, today, find excuses to rotate
their subscriber's IP addresses every day would be among those 
operators that will not allow MAP but might allow PEER.

-d

v2.23.0 | Report a Bug | By Email