Re: [BEHAVE] draft-ietf-behave-nat64-discovery-heuristic in PCP-enabled networks?

Simon Perreault <simon.perreault@viagenie.ca> Fri, 07 September 2012 12:45 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB4921F8734 for <behave@ietfa.amsl.com>; Fri, 7 Sep 2012 05:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599]
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 Hl09ovGxWZAk for <behave@ietfa.amsl.com>; Fri, 7 Sep 2012 05:45:58 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0194321F8715 for <behave@ietf.org>; Fri, 7 Sep 2012 05:45:58 -0700 (PDT)
Received: from balaise.nomis80.org (modemcable212.59-179-173.mc.videotron.ca [173.179.59.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3AE54415C0 for <behave@ietf.org>; Fri, 7 Sep 2012 08:45:57 -0400 (EDT)
Message-ID: <5049EC84.2090102@viagenie.ca>
Date: Fri, 07 Sep 2012 08:45:56 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: behave@ietf.org
References: <94C682931C08B048B7A8645303FDC9F36E57B08679@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE4430969620444AB9D@008-AM1MPN1-053.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE4430969620444AB9D@008-AM1MPN1-053.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [BEHAVE] draft-ietf-behave-nat64-discovery-heuristic in PCP-enabled networks?
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Sep 2012 12:45:59 -0000

On 09/07/2012 03:11 AM, teemu.savolainen@nokia.com wrote:
> IMHO PCP proposal for Pref64::/n falls to similar category as DHCPv6 in
> the draft-ietf-behave-nat64-learn-analysis-03.txt. I.e. it may not be
> deployed alongside NAT64, it requires PCP client implementation on a
> node, and so forth.

Yes they are similar, but there are differences:

>    The PROs of the proposal are listed below:
>
>    +  Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #4 via
>       DHCPv6 information lifetime.

Same for PCP.

>    +  Does not involve DNS system.  Therefore, applications that would
>       not normally initiate any DNS queries can still learn the NAT64
>       prefix.

Same for PCP.

>    +  DHCPv6 is designed to provide various kinds of configuration
>       information in a centrally managed fashion.

Not really the same, but this is fuzzy...

>    The CONs of the proposal are listed below:
>
>    -  Change of NSP requires change to DHCPv6 configuration.

Here PCP is different: since the PCP server presumably has direct access 
to CGN configuration, there is no need to change the PCP server 
configuration.

>    -  Requires at least Stateless DHCPv6 client on hosts.

PCP requires a PCP client on hosts.

>    -  Requires support on DHCPv6 clients, which is not trivial in all
>       operating systems.

PCP requires support on PCP clients.

>    -  The DHCPv6-based solution involves changes and management on
>       network side nodes that are not really part of the NAT64/DNS64
>       deployment (or issues caused by their existence).

This does not apply to PCP.

>    -  A new DHCPv6 option is required and the corresponding changes to
>       both DHCPv6 clients and servers.

And a new PCP option/opcode is required.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca