IETF Logo Mail Archive

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

<teemu.savolainen@nokia.com> Fri, 07 September 2012 13:17 UTC

Return-Path: <teemu.savolainen@nokia.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 B7E0821F841B; Fri, 7 Sep 2012 06:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level:
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 yi3Z3qf3bShM; Fri, 7 Sep 2012 06:17:21 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A13ED21F85EF; Fri, 7 Sep 2012 06:17:20 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q87DHEvU031013; Fri, 7 Sep 2012 16:17:15 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 16:17:14 +0300
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.232]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 15:17:14 +0200
From: teemu.savolainen@nokia.com
To: mohamed.boucadair@orange.com, simon.perreault@viagenie.ca
Thread-Topic: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option
Thread-Index: Ac2MREsThTb5jn5dQvm14yeG1MbvVgAdLJUwAAPMTNAAAgZYgAADCg4QAAPxyvAAAq5H8A==
Date: Fri, 07 Sep 2012 13:17:12 +0000
Message-ID: <916CE6CF87173740BC8A2CE4430969620445C977@008-AM1MPN1-053.mgdnok.nokia.com>
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> <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E57B08811@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IkG58TW0g8v3pRTIa5m0oRvOwWvPPL+sw1OI592gw0w+/D3rEkeVQ4iwch1++FHcoO6ydKVeY+yCx3JcwHtjroRij1AGuFnPfkj1BKE+9amJQMLBqkOWtEyXwQcgA66Rr5fF+0nTmIq9fhFmwOM2gfVNHhve4r0QbqTjQVKTmTfd6LlB35tVQWpxV69dUtObFgw3JVNtcAwDrBbnM2Wr5OowXtvCCIa3PhLR4cmMj1tWHfI6o6eIvLmFmocxa5M0VK9vjgxt2LbmQJFRMeIhWR2HkLrNofwa3pe2qo3hym0M
x-originating-ip: [10.163.19.180]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Sep 2012 13:17:14.0774 (UTC) FILETIME=[19004360:01CD8CFB]
X-Nokia-AV: Clean
Cc: pcp@ietf.org, behave@ietf.org
Subject: Re: [pcp] 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 13:17:21 -0000

Hi,

Inline:

> >From a host standpoint there are no guarantees to have PCP always
> >available when a NAT64 is present.
> 
> Med: Yes, this is deployment-specific. Note the LSN requirements draft
> mandates to have a way to open mappings.

I hope the cellular (and other) operators actually follow the guidance once that draft becomes RFC. 
 
> Med: This is what I wanted to hear. The intent was not to say PCP is better. My
> initial discussion point was focusing on PCP-enabled networks and only that
> case. Concretely, would it be possible to add a sentence in the sense of your
> statement above?

I think the heuristic draft is best to be kept as a standalone tool and I think that it definitely should not speculate on what other tools there might be available in the future (there have been other proposals as well at the individual I-D level).

If the PREFIX64 option is adopted by the PCP WG, I think it could describe how it will coexist with heuristic-option, e.g. saying that if a client supports PCP, it SHOULD/MUST try with PREFIX64 option before performing heuristic procedures.

Btw how do you get the IPv4 subnet->Pref64::/n mapping list with this option? I quickly looked the draft and it also seemed to deliver just one Pref64::/n?

> >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).
> 
> Med: That's fair. Again, I'm exclusively positioning this discussion in context
> where PCP is deployed.

Good, and I definitely support deployment of PCP.

> >This tool perhaps could be PCP - if this WG thinks it is ok to extent
> >PCP for this kind of provisioning purposes - for me this sounds a bit
> >like loading PCP with something that might fit better to DHCPv6.
> 
> Med: I disagree: PCP is there to help NAT traversal, returning the PREFIX64 is
> part of that problem.

Well, ok, I agree and changed my mind on this:) The PCP Server definitely has an interface to NAT64 (unlike DHCPv6 Server), and hence it could ask the Pref64::/n from it (or provision it to NAT64, whatever you guys plan to do).

> Med: I didn't asked for that. Sorry I was not clear: the scope of this discussion
> is: PCP-enabled networks.

Thanks, in PCP-enabled networks it is definitely ok to skip heuristics in favor for explicit configuration. 

If you do go forward with explicit option, you could look if you can resolve the "mapping of IPv4 address ranges to IPv6 prefixes" problem. Something better perhaps than asking from PCP Server what is the Pref64::/n for a given IPv4 address..

Best regards

	Teemu

v2.23.0 | Report a Bug | By Email