Re: [pcp] UNSUPP_FAMILY error code

Simon Perreault <simon.perreault@viagenie.ca> Thu, 30 May 2013 09:58 UTC

Return-Path: <simon.perreault@viagenie.ca>
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 3985221F9473 for <pcp@ietfa.amsl.com>; Thu, 30 May 2013 02:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.359
X-Spam-Level:
X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfTm1sGdKtBH for <pcp@ietfa.amsl.com>; Thu, 30 May 2013 02:58:44 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EC70F21F8956 for <pcp@ietf.org>; Thu, 30 May 2013 02:58:37 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 46DDB4689C; Thu, 30 May 2013 05:58:37 -0400 (EDT)
Message-ID: <51A722CC.5030506@viagenie.ca>
Date: Thu, 30 May 2013 11:58:36 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Stuart Cheshire <cheshire@apple.com>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com> <D8DD871C-9946-4BDB-B99E-061792B1C9B4@apple.com> <51A5BF11.5030100@viagenie.ca> <EFDFCA6A-8369-4333-94E4-1F5393D7F9C2@apple.com>
In-Reply-To: <EFDFCA6A-8369-4333-94E4-1F5393D7F9C2@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: pcp@ietf.org
Subject: Re: [pcp] UNSUPP_FAMILY error code
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: Thu, 30 May 2013 09:58:45 -0000

Le 2013-05-30 05:52, Stuart Cheshire a écrit :
>> It could be useful to point out that the set of supported external address families depends on the internal address family. That is, sending the same request over IPv4 and IPv6 could yield different results.
>
> Good point. How about this updated text?
>
>     Note that while the specific address placed in the Suggested External
>     Address field is merely a suggestion that the PCP server is free to
>     ignore, the address family is not.  If the suggested address *family*
>     cannot be provided by this PCP server, then it MUST return a PCP
>     error reply containing the UNSUPP_FAMILY error code.

This is important. And I think it is right. I cannot imagine a use case 
where a client doesn't know or care about the external address family.

>     The ability to provide the requested external address family may
>     depend on the client's internal address.

internal address *family*.

>     For example, a gateway that
>     supports traditional NAT44, and native IPv6, but not NAT64, is able
>     to provide mappings from an internal IPv4 address to an external IPv4
>     address, and mappings from an internal IPv6 address to an external
>     IPv6 address, but not mappings from an internal IPv6 address to an
>     external IPv4 address.  When such a gateway receives a request to map
>     an internal IPv4 address to an external IPv4 address it MUST return

s/MUST/MAY/

Quotas, local policy, the weather, etc. may all impact the server's 
willingness to serve that request.

>     an external IPv4 address, if available, but when it receives a
>     request to map an internal IPv6 address to an external IPv4 address
>     it MUST return an UNSUPP_FAMILY error.

Good.

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