Re: Your comment on the minutes for 6man@IETF71
Arifumi Matsumoto <arifumi@nttv6.net> Thu, 05 June 2008 08:29 UTC
Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipngwg-archive@lists.ietf.org
Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDD628C14A; Thu, 5 Jun 2008 01:29:31 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EE33A6D21 for <ipv6@core3.amsl.com>; Thu, 5 Jun 2008 01:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU1YVqvE5kZd for <ipv6@core3.amsl.com>; Thu, 5 Jun 2008 01:29:29 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id A342528C20B for <ipv6@ietf.org>; Thu, 5 Jun 2008 01:28:26 -0700 (PDT)
Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.1) with ESMTP id m558SKPh034189; Thu, 5 Jun 2008 17:28:21 +0900 (JST) (envelope-from arifumi@nttv6.net)
Message-Id: <81B5F12D-9EF6-4FF8-8D60-1AC2516E5AB8@nttv6.net>
From: Arifumi Matsumoto <arifumi@nttv6.net>
To: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
In-Reply-To: <200806031420.58986.remi.denis-courmont@nokia.com>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Your comment on the minutes for 6man@IETF71
Date: Thu, 05 Jun 2008 17:28:14 +0900
References: <6D8BBDC9-5D83-4BBF-8167-DDCDC6450C3F@inetcore.com> <200806031420.58986.remi.denis-courmont@nokia.com>
X-Mailer: Apple Mail (2.924)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 05 Jun 2008 17:28:25 +0900 (JST)
Cc: ipv6@ietf.org, dthaler@microsoft.com, "\"(Tomohiro -INSTALLER- Fujis"@core3.amsl.com, "金山 健一 / KANAYAMA Ken"@core3.amsl.com, "aki/藤崎 智宏)\"" <fujisaki@syce.net>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Rémi, thank you for clarification. Regarding IPv4 private address scope issue, in ietf@ietf.org ML, it was discussed a lot recently and some people suggested to make IPv4 private address scope global. As you mentioned, I agree that application specific address selection behavior should be implemented by using RFC 5014 or its extension. Anyway, these issues should be fixed by revising RFC 3484 itself I believe. Kindest regards, Arifumi Matsumoto On 2008/06/03, at 20:20, Rémi Denis-Courmont wrote: > > Hello, > > On Tuesday 03 June 2008 13:44:26 ext Ruri Hiromi wrote : >> Hello, we are just reviewing the minutes for modification of our >> draft(http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-sol-0 >> 0.txt ), we hope you taking your time for clarification of your >> comment. >> >> In the minutes, you said, "need?" in reply to Dave Thaler's comment >> as >> "2 mechanisms, using scope or table - row in table is simpler how do >> you get cfg out of the host without changing specs". >> Could you give us more details about "need?"? Did you mean "Is >> there a >> necessity for 2 mechanism?" ? > > Hmm, Philadelphia is far... If I recall correctly... I hinted that > we may need > to make the scopes also a configurable policy table. In RFC3484, > precedences > and labels are configurable, but not scopes. > > Because scoping rules are applied before any label or precedence > rules, there > are scenarios where it is impossible to configure the source address > selection policy. > > For instance, assume the sourcing host has: > - SLL: one link-local IPv6 address, > - S6: one public IPv6 address within the 6to4 label (2002:...), and > - S4: one private IPv4 address from RFC1918 space. > > and the remote destination has: > - D6: one public IPv6 address within the native label, and > - D4: one public IPv4 address. > > Then the scopes are: > SLL: link-local scope > S4: private scope > S6, S4 & D6: global scope > > No matter how you configure the label and precedence policy tables, > RFC3484 > will _always_ pick S6->D6, because it is the only couple with matching > scopes. However, it seems realistic that S4->D4 would work better, > because S6 > is a 6to4 address, and 6to4 is not reliable. Of course, this a policy > decision. > > One solution is to allow configuring the scope tables as well, but > it might be > over-engineering, as this is quite static information. Another > solution is to > add per-application "profiles" to the source address selection. As > such, > applications that require network transparency would use the current > RFC3484 > scope tables and use S6->D6. > > But applications that do not need transparency and can work through > IPv4 NATs > (such as HTTP) would use a different scope table where there all IPv4 > addresses are global scopes. In that case, you get, the scope > matching allows > two different couples: > S6->D6 > S4->D4 > Because S6 (6to4 label) and D6 (native label) have different labels, > and > S4->D4 have the same label (IPv4 label), S4->D4 would be preferred. > > In practice, this could be implemented using a new source address > selection > flag to the getaddrinfo() socket API, e.g. extending RFC5014. > > -- > Rémi Denis-Courmont -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- Re: Your comment on the minutes for 6man@IETF71 Arifumi Matsumoto