Re: [pcp] PCP Server Selection - Address Family Selection
Simon Perreault <simon.perreault@viagenie.ca> Mon, 28 April 2014 12:40 UTC
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E001A09E8 for <pcp@ietfa.amsl.com>; Mon, 28 Apr 2014 05:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b80HvqRl8NcH for <pcp@ietfa.amsl.com>; Mon, 28 Apr 2014 05:40:47 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 96F601A07CD for <pcp@ietf.org>; Mon, 28 Apr 2014 05:40:47 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AF06F403DD; Mon, 28 Apr 2014 08:40:46 -0400 (EDT)
Message-ID: <535E4C4E.5050507@viagenie.ca>
Date: Mon, 28 Apr 2014 08:40:46 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>, Sebastian Kiesel <ietf-pcp@skiesel.de>
References: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> <535A77E8.7010201@viagenie.ca> <79E3AFAF-D801-4152-94AC-57FA4B5D1BED@cisco.com> <20140426213757.GD4891@gw01.ehlo.wurstkaes.de> <09A44D3D-B395-459D-86DD-66874E914521@cisco.com>
In-Reply-To: <09A44D3D-B395-459D-86DD-66874E914521@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/AE-_xYT5hWw0v-_TIuIdUom6RQ4
Cc: PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] PCP Server Selection - Address Family Selection
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 28 Apr 2014 12:40:49 -0000
Le 2014-04-27 20:52, Dan Wing a écrit : > > On Apr 26, 2014, at 2:37 PM, Sebastian Kiesel <ietf-pcp@skiesel.de> wrote: > >> On Fri, Apr 25, 2014 at 06:42:53PM -0700, Dan Wing wrote: >>> >>> On Apr 25, 2014, at 7:57 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote: >>> >>>> Le 2014-04-25 10:51, Sebastian Kiesel a écrit : >>>>> draft-ietf-pcp-server-selection-02 says in Section 3: >>>>> >>>>> 1. If the PCP client can use both address families when >>>>> communicating to a particular PCP server, the PCP client SHOULD >>>>> select the source address of the PCP request to be of the same IP >>>>> address family as its requested PCP mapping (i.e., the address >>>>> family of the Requested External IP Address). >>>>> >>>>> >>>>> What is the reason for saying it SHOULD use the same familiy as the >>>>> requested EXTERNAL IP address? I think it would make more sense to use >>>>> the same familiy as the INTERNAL address (if there is a difference at >>>>> all). >>>> >>>> +1 >>>> >>>> I stated this in my review. >>> >>> The intent of the wording is to avoid NAT64 (or NAT46) where NAT44 or >>> no NAT was necessary at all. >> >> reasonable goal, but does text about that belong here? >> >> this text is about PCP messages, and I think they should use the >> same address family as the actual user data flow on their side of >> the NAT. > > If that avoids IP address family translation, sounds good to me. Or is there some other value or purpose? I understand what you want, but the text doesn't get you what you want. I want something different, but we can both get what we want with appropriate text. First, "sending over IPvX" doesn't imply that the internal address is IPvX, because of THIRD_PARTY. What you want is: "the client SHOULD pick an internal address of the same family as that of the mapping's external address." Second, what I want is to avoid THIRD_PARTY. So that's why you need to send the request using the chosen internal address as source for the PCP request. (This is actually stricter than just using the same address family, in case you have multiple addresses of that address family.) Summarizing: "If a PCP client has access to internal addresses of multiple families, then it SHOULD choose the mapping's internal address such that it is of the same family as that of the mapping's external address. This is done to avoid address family translation when possible. The PCP client SHOULD use the mapping's internal address as source for the PCP request. This is done to avoid using the THIRD_PARTY option when possible." 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
- [pcp] PCP Server Selection - Address Family Selec… Sebastian Kiesel
- Re: [pcp] PCP Server Selection - Address Family S… Simon Perreault
- Re: [pcp] PCP Server Selection - Address Family S… Dan Wing
- Re: [pcp] PCP Server Selection - Address Family S… Sebastian Kiesel
- Re: [pcp] PCP Server Selection - Address Family S… Dan Wing
- Re: [pcp] PCP Server Selection - Address Family S… Simon Perreault
- Re: [pcp] PCP Server Selection - Address Family S… Prashanth Patil (praspati)
- Re: [pcp] PCP Server Selection - Address Family S… Simon Perreault