From addr-select-dt-bounces@ietf.org Thu Oct 2 06:46:28 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120543A67E4; Thu, 2 Oct 2008 06:46:28 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148F43A677D for ; Thu, 2 Oct 2008 06:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] 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 HbdZ+2ZPbs-B for ; Thu, 2 Oct 2008 06:46:21 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 7FC7F3A67E4 for ; Thu, 2 Oct 2008 06:46:21 -0700 (PDT) Received: from ([128.244.96.179]) by pilot.jhuapl.edu with ESMTP with TLS id 5502123.117420980; Thu, 02 Oct 2008 09:25:58 -0400 Message-ID: <48E4CBE6.9090700@innovationslab.net> Date: Thu, 02 Oct 2008 09:25:58 -0400 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: addr-select-dt@ietf.org Subject: [addr-select-dt] Address Selection DT Wiki X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org All, I have created a wiki page for your use. It is located at http://trac.tools.ietf.org/area/int/trac/wiki/v6AddrSelect Regards, Brian _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Thu Oct 2 06:54:59 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721B228C22B; Thu, 2 Oct 2008 06:54:59 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E13828C1F4 for ; Thu, 2 Oct 2008 06:54: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Z9wGjIB32D for ; Thu, 2 Oct 2008 06:54:57 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id BA8153A67E4 for ; Thu, 2 Oct 2008 06:54:56 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m92DtJ2A072845; Thu, 2 Oct 2008 22:55:20 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: <8C1182C2-A948-447C-9BB0-C458847045B4@nttv6.net> From: Arifumi Matsumoto To: Brian Haberman In-Reply-To: <48E4CBE6.9090700@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 2 Oct 2008 22:56:14 +0900 References: <48E4CBE6.9090700@innovationslab.net> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [127.0.0.1]); Thu, 02 Oct 2008 22:55:20 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] Address Selection DT Wiki X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Brian, thank you so much. On 2008/10/02, at 22:25, Brian Haberman wrote: > All, > I have created a wiki page for your use. It is located at http://trac.tools.ietf.org/area/int/trac/wiki/v6AddrSelect > > Regards, > Brian > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Wed Oct 8 01:13:26 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1162A3A6892; Wed, 8 Oct 2008 01:13:26 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F148F3A6948 for ; Wed, 8 Oct 2008 01:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 np4IfBHwB5hS for ; Wed, 8 Oct 2008 01:13:24 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id CB7D93A6892 for ; Wed, 8 Oct 2008 01:13:23 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m988Dt9S091764 for ; Wed, 8 Oct 2008 17:13:55 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: <22CB7CD7-80DB-4CA4-8780-0CCCBF882120@nttv6.net> From: Arifumi Matsumoto To: addr-select-dt@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 17:13:51 +0900 X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Wed, 08 Oct 2008 17:13:55 +0900 (JST) Subject: [addr-select-dt] discussion at Montreal X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi all, last week at Montreal, where v4v6interim meeting was held, I had some time to talk with Marc Blanchet and Suresh Krishnan, and confirmed the following starting points. # Some parts of these crossover hiromi-san's e-mail on 11 Sep. ----- The goal of this design team -> to work out an mechanism that solves address selection problems by dynamically updating the policy table. What we would like to solve ? -> We would like to solve all or some of the problematic cases described in RFC 5220 (Problem Statements). How do we solve ? -> option a) revising RFC 3484 -> option b) some dynamic way to update the policy table (e.g. DHCPv6 option) -> option c) both a) and b) ------ If you have any comments or questions regarding these points, let us know. BTW. I wrote a few things on our wiki page. I'll update this page according to the discussion at ML. http://trac.tools.ietf.org/area/int/trac/wiki/v6AddrSelect?version=3 Kindest regards, Arifumi Matsumoto _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Wed Oct 8 07:19:52 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD68E3A6892; Wed, 8 Oct 2008 07:19:52 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D6D3A6907 for ; Mon, 6 Oct 2008 22:43:08 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 JEQ6DQwZh6JV for ; Mon, 6 Oct 2008 22:43:00 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 7450B3A6924 for ; Mon, 6 Oct 2008 22:42:59 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m975gDab071974; Tue, 7 Oct 2008 14:42:13 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: <5FA391AF-D7E9-48E4-B153-94CD07EF11E3@nttv6.net> From: Arifumi Matsumoto To: Marc Blanchet , ahain@cisco.com, Tim Chown , marcelo braun bagnulo , Suresh Krishnan , teemu.savolainen@nokia.com, Francis Dupont , evans@commandinformation.com, "John.zhao" , Tim Enos , Sebastien Roy , Mohacsi Janos In-Reply-To: <8360E29B-47DB-45BC-B3A2-9CA502535A12@inetcore.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 14:42:09 +0900 References: <8360E29B-47DB-45BC-B3A2-9CA502535A12@inetcore.com> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Tue, 07 Oct 2008 14:42:24 +0900 (JST) X-Mailman-Approved-At: Wed, 08 Oct 2008 07:19:51 -0700 Cc: 6man-chairs@tools.ietf.org, addr-select-dt@ietf.org Subject: Re: [addr-select-dt] Mailing List was set! X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org To the design team members, I'm sorry if you receive two copies of this e-mail. If you have completed ML subscription, you will receive two copies of this e-mail. At the ML web page, I found that not everyone completed ML subscription. Please make sure you subscribe to the mailing list by web-site or e-mail. List-Subscribe: , Kindest regards. On 2008/08/15, at 14:20, Ruri Hiromi wrote: > To design team members ; > (I bcc'ed to all members) > > Brian Haberman set up a mailing list for the design work of 3484 > policy table dynamic update. > > I had direct mails from 12 persons to work with as I listed in the > following. > > current 3484 policy dynamic update design team > - Marc Blanchet > - Tim Chown > - Marcelo Bagnulo Braun > - Suresh Krishnan > - Tony Hain > - Francis Dupont > - Evans TJ > - John.zhao > - Sebastien Roy > - Janos Mohacsi > - Tim Enos > - Teemu Savolainen > - Fujisaki Tomohiro > - Arifumi Matsumoto > - Ruri Hiromi > > Please subscribe this mail list with your convenient e-mail address. > > List-Id: IPv6 Address Selection Design Team > List-Unsubscribe: >, > > List-Archive: > List-Post: > List-Help: > List-Subscribe: dt>, > > > > ------------------------------- > Ruri Hiromi > Intec NetCore, Inc. / Keio university > hiromi@inetcore.com > > > > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Thu Oct 9 19:36:39 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A503A6877; Thu, 9 Oct 2008 19:36:39 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988563A6811 for ; Thu, 9 Oct 2008 19:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001] 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 SRNzPo1OoXcd for ; Thu, 9 Oct 2008 19:36:36 -0700 (PDT) Received: from mail.syce.net (mail.syce.net [IPv6:2001:fa8:fffe:1000::25]) by core3.amsl.com (Postfix) with ESMTP id 32C6C3A682F for ; Thu, 9 Oct 2008 19:36:35 -0700 (PDT) Received: from localhost (localhost.syce.net [IPv6:::1]) by mail.syce.net (8.14.2/8.14.2) with ESMTP/inet6 id m9A2bF1G012557; Fri, 10 Oct 2008 11:37:15 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Fri, 10 Oct 2008 11:37:14 +0900 (JST) Message-Id: <20081010.113714.162018359.fujisaki@syce.net> To: arifumi@nttv6.net From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: <22CB7CD7-80DB-4CA4-8780-0CCCBF882120@nttv6.net> References: <22CB7CD7-80DB-4CA4-8780-0CCCBF882120@nttv6.net> X-Mailer: Mew version 6.1 on Emacs 22.2 / Mule xmeacs 21.4.21 Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.syce.net [IPv6:::1]); Fri, 10 Oct 2008 11:37:15 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] discussion at Montreal X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Arifumi-san, One question, | ----- | The goal of this design team | -> to work out an mechanism that solves address selection problems by dynamically updating the policy table. | | What we would like to solve ? | -> We would like to solve all or some of the problematic cases described in RFC 5220 (Problem Statements). | | How do we solve ? | -> option a) revising RFC 3484 Does option a) mean we should consider solutions other than policy distribution? -- Tomohiro Fujisaki _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Mon Oct 13 20:19:38 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF48E3A6BA0; Mon, 13 Oct 2008 20:19:38 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF463A6BA0 for ; Mon, 13 Oct 2008 20:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_20=-0.74] 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 4JT5PVnnrGSg for ; Mon, 13 Oct 2008 20:19:36 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 65AC73A6B67 for ; Mon, 13 Oct 2008 20:19:36 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9E3KRBl055061; Tue, 14 Oct 2008 12:20:27 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: =?ISO-2022-JP?B?KFRvbW9oaXJvIC1JTlNUQUxMRVItIEZ1amlzYQ==?= =?ISO-2022-JP?B?a2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhCKQ==?= In-Reply-To: <20081010.113714.162018359.fujisaki@syce.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 12:20:23 +0900 References: <22CB7CD7-80DB-4CA4-8780-0CCCBF882120@nttv6.net> <20081010.113714.162018359.fujisaki@syce.net> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Tue, 14 Oct 2008 12:20:27 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] discussion at Montreal X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-2022-jp"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi, On 2008/10/10, at 11:37, (Tomohiro -INSTALLER- Fujisaki/藤 崎 智宏) wrote: > > Arifumi-san, > > One question, > > | ----- > | The goal of this design team > | -> to work out an mechanism that solves address selection problems > by dynamically updating the policy table. > | > | What we would like to solve ? > | -> We would like to solve all or some of the problematic cases > described in RFC 5220 (Problem Statements). > | > | How do we solve ? > | -> option a) revising RFC 3484 > > Does option a) mean we should consider solutions other than policy > distribution? My understanding is that we intend to work on a mechanism for updating host's policy table, so we assume the existence of RFC 3484. However, at the same time, we don't exclude minor-update of RFC 3484, such as adding one line to the default policy table. So, solutions other than policy distribution and minor-update of RFC 3484 are outside of our scope. Regards. _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Tue Oct 14 02:38:39 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4043A6B14; Tue, 14 Oct 2008 02:38:39 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892A63A67EE for ; Tue, 14 Oct 2008 02:38:37 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZtolo0LxGf6 for ; Tue, 14 Oct 2008 02:38:36 -0700 (PDT) Received: from owl.ecs.soton.ac.uk (owl.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe77:96e]) by core3.amsl.com (Postfix) with ESMTP id 0C2433A6B14 for ; Tue, 14 Oct 2008 02:38:35 -0700 (PDT) X-ECS-MailScanner-Watermark: 1224581962.87986@1BHRyUOD74sDfqcAlRiY6w Received: from gander.ecs.soton.ac.uk ([IPv6:2001:630:d0:f102:21d:9ff:fe22:9fc]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m9E9dLdG009692 for ; Tue, 14 Oct 2008 10:39:21 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id m9E9dIXe022681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Oct 2008 10:39:18 +0100 Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id m9E9dIdU025175 for ; Tue, 14 Oct 2008 10:39:18 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id m9E9dI4c025174 for addr-select-dt@ietf.org; Tue, 14 Oct 2008 10:39:18 +0100 Date: Tue, 14 Oct 2008 10:39:18 +0100 From: Tim Chown To: addr-select-dt@ietf.org Message-ID: <20081014093918.GG20073@login.ecs.soton.ac.uk> References: <22CB7CD7-80DB-4CA4-8780-0CCCBF882120@nttv6.net> <20081010.113714.162018359.fujisaki@syce.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner-ID: m9E9dIXe022681 X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m9E9dLdG009692 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [addr-select-dt] Focusing on triggers/causes of policy change X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi, I think we need to get a little focus based on Brian's steer for us, so we can plan to produce an initial draft text. Note the -00 cutoff is 27th October, so we have two weeks to produce initial text, if we want to make that cutoff. My suggestion would be that the text should initially include thoughts along the lines of Ruri's input, i.e. triggers for policy changes. From this we should get a better understanding how often and why the policies change. This should help us in then appreciating which solution fits best. I don't think we should talk about solution spaces in -00. This my initial question is what people on the team think of Ruri's input on triggers? I agree we should look a 5220 as one source of input. On the subject of changes to default policy (3484), I suspect that while we could make defaults 'better' in the general case, in this team we - initially at least - just view one 'trigger' as being an initial deployment of policy for the site that may overwrite certain defaults. Tim _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Thu Oct 16 04:29:47 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A30E3A6AC0; Thu, 16 Oct 2008 04:29:47 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD3F3A68C0 for ; Thu, 16 Oct 2008 04:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] 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 rCz2ZyF4h35q for ; Thu, 16 Oct 2008 04:29:44 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 444C13A6B56 for ; Thu, 16 Oct 2008 04:29:43 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9GBU9fM095526; Thu, 16 Oct 2008 20:30:09 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: Tim Chown In-Reply-To: <20081014093918.GG20073@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 16 Oct 2008 20:30:05 +0900 References: <22CB7CD7-80DB-4CA4-8780-0CCCBF882120@nttv6.net> <20081010.113714.162018359.fujisaki@syce.net> <20081014093918.GG20073@login.ecs.soton.ac.uk> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 16 Oct 2008 20:30:10 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] Focusing on triggers/causes of policy change X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi, I agree that we should start with trigger discussion. Regarding RFC 5220, the following cases are listed. Let me try an analysis of these from the aspect of updating trigger. 2.1.1. Multiple Routers on a Single Interface ..............4 2.1.2. Ingress Filtering Problem ...........................5 2.1.3. Half-Closed Network Problem .........................6 2.1.4. Combined Use of Global and ULA ......................7 2.1.5. Site Renumbering ....................................8 2.1.6. Multicast Source Address Selection ..................9 2.1.7. Temporary Address Selection .........................9 2.2.1. IPv4 or IPv6 Prioritization ........................ 10 2.2.2. ULA and IPv4 Dual-Stack Environment ................ 11 2.2.3. ULA or Global Prioritization ....................... 12 Only 2.1.1 and 2.1.2 may need dynamic policy table update triggered by routing changes, as long as the site uses a dynamic routing protocol intra-site and the routing protocol is configured to reflect changes of extra-site routing topology. In such a case, the policy table of hosts may needs to be updated according to the routing policy. It should be noted that we have other mechanims for dynamical routing topology change, for example deprecating one of the advertised prefixes. This mechanism may help when one of the upstream links has a trouble. Regarding any other cases in RFC 5220, IMO an update of the policy table is triggered by an intra-site topology/policy change. So, only the site administrator triggers policy table updates. Can we agree on this analysis ? On 2008/10/14, at 18:39, Tim Chown wrote: > Hi, > > I think we need to get a little focus based on Brian's steer for us, > so we can plan to produce an initial draft text. > > Note the -00 cutoff is 27th October, so we have two weeks to produce > initial text, if we want to make that cutoff. > > My suggestion would be that the text should initially include thoughts > along the lines of Ruri's input, i.e. triggers for policy changes. > From > this we should get a better understanding how often and why the > policies > change. This should help us in then appreciating which solution fits > best. I don't think we should talk about solution spaces in -00. > > This my initial question is what people on the team think of Ruri's > input on triggers? > > I agree we should look a 5220 as one source of input. > > On the subject of changes to default policy (3484), I suspect that > while > we could make defaults 'better' in the general case, in this team we > - initially at least - just view one 'trigger' as being an initial > deployment of policy for the site that may overwrite certain defaults. > > Tim > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Mon Oct 20 20:34:29 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950753A6B3B; Mon, 20 Oct 2008 20:34:29 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C9A3A6B3B for ; Mon, 20 Oct 2008 20:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001] 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 1GXM-9NB1lzH for ; Mon, 20 Oct 2008 20:34:27 -0700 (PDT) Received: from mail.syce.net (mail.syce.net [IPv6:2001:fa8:fffe:1000::25]) by core3.amsl.com (Postfix) with ESMTP id 1A7713A6927 for ; Mon, 20 Oct 2008 20:34:26 -0700 (PDT) Received: from localhost (localhost.syce.net [IPv6:::1]) by mail.syce.net (8.14.2/8.14.2) with ESMTP/inet6 id m9L3Z3Gn015424; Tue, 21 Oct 2008 12:35:03 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Tue, 21 Oct 2008 12:35:12 +0900 (JST) Message-Id: <20081021.123512.51863029.fujisaki@syce.net> To: arifumi@nttv6.net From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: References: <20081014093918.GG20073@login.ecs.soton.ac.uk> X-Mailer: Mew version 6.1 on Emacs 22.2 / Mule xmeacs 21.4.21 Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.syce.net [IPv6:::1]); Tue, 21 Oct 2008 12:35:04 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] Focusing on triggers/causes of policy change X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi Arifumi-san, Do you think we should discuss timing of the policy table distribution (e.g. host initlalization phase and host running phase)? We can use a same protocol all in all phase or not. | Regarding RFC 5220, the following cases are listed. | Let me try an analysis of these from the aspect of updating trigger. | | 2.1.1. Multiple Routers on a Single Interface ..............4 | 2.1.2. Ingress Filtering Problem ...........................5 | 2.1.3. Half-Closed Network Problem .........................6 | 2.1.4. Combined Use of Global and ULA ......................7 | 2.1.5. Site Renumbering ....................................8 | 2.1.6. Multicast Source Address Selection ..................9 | 2.1.7. Temporary Address Selection .........................9 | 2.2.1. IPv4 or IPv6 Prioritization ........................10 | 2.2.2. ULA and IPv4 Dual-Stack Environment ................11 | 2.2.3. ULA or Global Prioritization .......................12 | | Only 2.1.1 and 2.1.2 may need dynamic policy table update triggered | by routing changes, as long as the site uses a dynamic routing protocol | intra-site and the routing protocol is configured to reflect changes | of extra-site routing topology. | | In such a case, the policy table of hosts may needs to be updated | according to the routing policy. | It should be noted that we have other mechanims for dynamical routing | topology change, for example deprecating one of the advertised prefixes. | This mechanism may help when one of the upstream links has a trouble. I think in a case hosts need to chage their address (e.g. deprecating the address), the hosts should re-obtaion the selection policy (in the case of deprecation, it may be unnecessary to change its policy) and the trigger can be the address configuration mechanism (RA or DHCPv6). It may be more difficult in a case that hosts do not need to change their address, how to inform hosts to re-obtaion the policy, or deliver the pollicy to hosts. When we use DHCPv6 for policy distribution, it is difficult to inform hosts to re-obtain the policy (can we use reconfigura message?). | Regarding any other cases in RFC 5220, IMO an update of the policy table | is triggered by an intra-site topology/policy change. So, only the | site administrator triggers policy table updates. | | Can we agree on this analysis ? Basically, yes. | On 2008/10/14, at 18:39, Tim Chown wrote: | | > Hi, | > | > I think we need to get a little focus based on Brian's steer for us, | > so we can plan to produce an initial draft text. | > | > Note the -00 cutoff is 27th October, so we have two weeks to produce | > initial text, if we want to make that cutoff. | > | > My suggestion would be that the text should initially include thoughts | > along the lines of Ruri's input, i.e. triggers for policy changes. From | > this we should get a better understanding how often and why the policies | > change. This should help us in then appreciating which solution fits | > best. I don't think we should talk about solution spaces in -00. | > | > This my initial question is what people on the team think of Ruri's | > input on triggers? | > | > I agree we should look a 5220 as one source of input. | > | > On the subject of changes to default policy (3484), I suspect that while | > we could make defaults 'better' in the general case, in this team we | > - initially at least - just view one 'trigger' as being an initial | > deployment of policy for the site that may overwrite certain defaults. | > | > Tim | > _______________________________________________ | > addr-select-dt mailing list | > addr-select-dt@ietf.org | > https://www.ietf.org/mailman/listinfo/addr-select-dt | | _______________________________________________ | addr-select-dt mailing list | addr-select-dt@ietf.org | https://www.ietf.org/mailman/listinfo/addr-select-dt | _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Tue Oct 21 06:21:22 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC383A6B5C; Tue, 21 Oct 2008 06:21:22 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12483A6B67 for ; Tue, 21 Oct 2008 06:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ocEYM+26xGZg for ; Tue, 21 Oct 2008 06:21:05 -0700 (PDT) Received: from owl.ecs.soton.ac.uk (owl.ecs.soton.ac.uk [152.78.68.129]) by core3.amsl.com (Postfix) with ESMTP id DC4CD3A6B5C for ; Tue, 21 Oct 2008 06:21:04 -0700 (PDT) X-ECS-MailScanner-Watermark: 1225198004.60295@HyDZtnpySeqojetooibZyg Received: from gander.ecs.soton.ac.uk ([IPv6:2001:630:d0:f102:21d:9ff:fe22:9fc]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m9LCkdsd009394 for ; Tue, 21 Oct 2008 13:46:43 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id m9LCke1U027279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2008 13:46:40 +0100 Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id m9LCkeKd031766 for ; Tue, 21 Oct 2008 13:46:40 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id m9LCkeEW031765 for addr-select-dt@ietf.org; Tue, 21 Oct 2008 13:46:40 +0100 Date: Tue, 21 Oct 2008 13:46:40 +0100 From: Tim Chown To: addr-select-dt@ietf.org Message-ID: <20081021124640.GC26548@login.ecs.soton.ac.uk> References: <20081014093918.GG20073@login.ecs.soton.ac.uk> <20081021.123512.51863029.fujisaki@syce.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081021.123512.51863029.fujisaki@syce.net> User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner-ID: m9LCke1U027279 X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m9LCkdsd009394 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [addr-select-dt] Focusing on triggers/causes of policy change X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org T24gVHVlLCBPY3QgMjEsIDIwMDggYXQgMTI6MzU6MTJQTSArMDkwMCwgVG9tb2hpcm8gLUlOU1RB TExFUi0gRnVqaXNha2kv6Jek5bSOIOaZuuWujyB3cm90ZToKPiAKPiBIaSBBcmlmdW1pLXNhbiwK PiAKPiBEbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIGRpc2N1c3MgdGltaW5nIG9mIHRoZSBwb2xpY3kg dGFibGUgZGlzdHJpYnV0aW9uCj4gKGUuZy4gaG9zdCBpbml0bGFsaXphdGlvbiBwaGFzZSBhbmQg aG9zdCBydW5uaW5nIHBoYXNlKT8gV2UgY2FuIHVzZQo+IGEgc2FtZSBwcm90b2NvbCBhbGwgaW4g YWxsIHBoYXNlIG9yIG5vdC4KCkl0IHdvdWxkIGNlcnRhaW5seSBzaW1wbGlmeSB0aGUgZGlzY3Vz c2lvbiBpZiB3ZSBjb3VsZCBhc3N1bWUgdGhhdCB0aGUKc2FtZSBwcm90b2NvbC9tZXRob2QgY2Fu IGJlIHVzZWQgZm9yIHN0YXJ0dXAgYW5kIGZvciBob3N0cyBhbHJlYWR5IHJ1bm5pbmcKd2l0aCBh IHBvbGljeS4gICBJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB0aGlzIHNob3VsZCBub3QgYmUgc28/ Cgo+ICB8IFJlZ2FyZGluZyBSRkMgNTIyMCwgdGhlIGZvbGxvd2luZyBjYXNlcyBhcmUgbGlzdGVk Lgo+ICB8IExldCBtZSB0cnkgYW4gYW5hbHlzaXMgb2YgdGhlc2UgZnJvbSB0aGUgYXNwZWN0IG9m IHVwZGF0aW5nIHRyaWdnZXIuCj4gIHwgCj4gIHwgICAgICAgICAgICAgMi4xLjEuIE11bHRpcGxl IFJvdXRlcnMgb24gYSBTaW5nbGUgSW50ZXJmYWNlIC4uLi4uLi4uLi4uLi4uNAo+ICB8ICAgICAg ICAgICAgIDIuMS4yLiBJbmdyZXNzIEZpbHRlcmluZyBQcm9ibGVtIC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjUKPiAgfCAgICAgICAgICAgICAyLjEuMy4gSGFsZi1DbG9zZWQgTmV0d29yayBQ cm9ibGVtIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42Cj4gIHwgICAgICAgICAgICAgMi4xLjQu IENvbWJpbmVkIFVzZSBvZiBHbG9iYWwgYW5kIFVMQSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uNwo+ ICB8ICAgICAgICAgICAgIDIuMS41LiBTaXRlIFJlbnVtYmVyaW5nIC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjgKPiAgfCAgICAgICAgICAgICAyLjEuNi4gTXVsdGljYXN0IFNv dXJjZSBBZGRyZXNzIFNlbGVjdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi45Cj4gIHwgICAgICAgICAg ICAgMi4xLjcuIFRlbXBvcmFyeSBBZGRyZXNzIFNlbGVjdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uOQo+ICB8ICAgICAgICAgICAgIDIuMi4xLiBJUHY0IG9yIElQdjYgUHJpb3JpdGl6YXRp b24gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTAKPiAgfCAgICAgICAgICAgICAyLjIuMi4gVUxB IGFuZCBJUHY0IER1YWwtU3RhY2sgRW52aXJvbm1lbnQgLi4uLi4uLi4uLi4uLi4uLjExCj4gIHwg ICAgICAgICAgICAgMi4yLjMuIFVMQSBvciBHbG9iYWwgUHJpb3JpdGl6YXRpb24gLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xMgo+ICB8IAo+ICB8IE9ubHkgMi4xLjEgYW5kIDIuMS4yIG1heSBuZWVk IGR5bmFtaWMgcG9saWN5IHRhYmxlIHVwZGF0ZSB0cmlnZ2VyZWQKPiAgfCBieSByb3V0aW5nIGNo YW5nZXMsIGFzIGxvbmcgYXMgdGhlIHNpdGUgdXNlcyBhIGR5bmFtaWMgcm91dGluZyBwcm90b2Nv bAo+ICB8IGludHJhLXNpdGUgYW5kIHRoZSByb3V0aW5nIHByb3RvY29sIGlzIGNvbmZpZ3VyZWQg dG8gcmVmbGVjdCBjaGFuZ2VzCj4gIHwgb2YgZXh0cmEtc2l0ZSByb3V0aW5nIHRvcG9sb2d5LgoK SSB0aGluayBpdCdzIHBvc3NpYmxlIHRoYXQgc29tZSBvZiB0aGUgYWJvdmUgaXNzdWVzIG1heSBi ZSBhZGRyZXNzZWQgYnkKYW4gdXBkYXRlIHRvIFJGQzM0ODQuICAgV2hldGhlciB0aGV5IGFyZSBv ciBub3QsIHdlIHNob3VsZCBjb25zaWRlciBhKQpob3cgY29tbW9ubHkgdGhlIGFib3ZlIGlzc3Vl cyBhcmlzZSBhbmQgYikgd2hhdCB0aGUgaW1wYWN0IG9mIGVhY2ggbWlnaHQgYmUuCgo+ICB8IElu IHN1Y2ggYSBjYXNlLCB0aGUgcG9saWN5IHRhYmxlIG9mIGhvc3RzIG1heSBuZWVkcyB0byBiZSB1 cGRhdGVkCj4gIHwgYWNjb3JkaW5nIHRvIHRoZSByb3V0aW5nIHBvbGljeS4KPiAgfCBJdCBzaG91 bGQgYmUgbm90ZWQgdGhhdCB3ZSBoYXZlIG90aGVyIG1lY2hhbmltcyBmb3IgZHluYW1pY2FsIHJv dXRpbmcKPiAgfCB0b3BvbG9neSBjaGFuZ2UsIGZvciBleGFtcGxlIGRlcHJlY2F0aW5nIG9uZSBv ZiB0aGUgYWR2ZXJ0aXNlZCBwcmVmaXhlcy4KPiAgfCBUaGlzIG1lY2hhbmlzbSBtYXkgaGVscCB3 aGVuIG9uZSBvZiB0aGUgdXBzdHJlYW0gbGlua3MgaGFzIGEgdHJvdWJsZS4KPiAKPiBJIHRoaW5r IGluIGEgY2FzZSBob3N0cyBuZWVkIHRvIGNoYWdlIHRoZWlyIGFkZHJlc3MgKGUuZy4gZGVwcmVj YXRpbmcKPiB0aGUgYWRkcmVzcyksIHRoZSBob3N0cyBzaG91bGQgcmUtb2J0YWlvbiB0aGUgc2Vs ZWN0aW9uIHBvbGljeSAoaW4gdGhlCj4gY2FzZSBvZiBkZXByZWNhdGlvbiwgaXQgbWF5IGJlIHVu bmVjZXNzYXJ5IHRvIGNoYW5nZSBpdHMgcG9saWN5KSBhbmQKPiB0aGUgdHJpZ2dlciBjYW4gYmUg dGhlIGFkZHJlc3MgY29uZmlndXJhdGlvbiBtZWNoYW5pc20gKFJBIG9yIERIQ1B2NikuCgpXaGVu IHdlIHJhbiByZW51bWJlcmluZyBleHBlcmltZW50cyBoZXJlLCB3ZSBvbmx5IGhhZCBSQSBhdmFp bGFibGUsIGFuZAp0aHVzIGEgJ3NpbXBsZScgQmFrZXItc3R5bGUgcmVudW1iZXJpbmcgZXZlbnQg d291bGRuJ3QgbGVhZCB0byBhIG5ldwpwb2xpY3kgdXBkYXRlIGJlaW5nIHRyaWdnZXJlZC4gICBB bmQgY2VydGFpbmx5IG5vdCBhIERIQ1AgYmFzZWQgb25lLgogCj4gSXQgbWF5IGJlIG1vcmUgZGlm ZmljdWx0IGluIGEgY2FzZSB0aGF0IGhvc3RzIGRvIG5vdCBuZWVkIHRvIGNoYW5nZQo+IHRoZWly IGFkZHJlc3MsIGhvdyB0byBpbmZvcm0gaG9zdHMgdG8gcmUtb2J0YWlvbiB0aGUgcG9saWN5LCBv ciAKPiBkZWxpdmVyIHRoZSBwb2xsaWN5IHRvIGhvc3RzLiAKClRoaXMgbWF5IGJlIHBhcnRseSBy ZWxhdGVkIHRvIHRoZSBkaXNjdXNzaW9ucyBhYm91dCBob3N0cyB0cmFuc2l0aW9uaW5nCmJldHdl ZW4gUkEgYW5kIERIQ1AgZW52aXJvbm1lbnRzLiAgICBUaGVyZSdzIHNvbWUgY3VlIHJlcXVpcmVk IHRoYXQKaW5kaWNhdGVzIHNvbWUgJ2NoYW5nZScgaW4gdGhlIG5ldHdvcmsgdGhhdCBtYXkgcmVx dWlyZSBhY3Rpb24gYnkgdGhlCmhvc3RzLgogCj4gV2hlbiB3ZSB1c2UgREhDUHY2IGZvciBwb2xp Y3kgZGlzdHJpYnV0aW9uLCBpdCBpcyBkaWZmaWN1bHQgdG8gaW5mb3JtCj4gaG9zdHMgdG8gcmUt b2J0YWluIHRoZSBwb2xpY3kgKGNhbiB3ZSB1c2UgcmVjb25maWd1cmEgbWVzc2FnZT8pLgoKSW5k ZWVkLiAgICBXZSBzaG91bGQgY2FwdHVyZSB0aGlzIGFzIGEgcmVxdWlyZW1lbnQsIG9yIGF0IGxl YXN0IGEgcHJvYmxlbS4KCj4gIHwgUmVnYXJkaW5nIGFueSBvdGhlciBjYXNlcyBpbiBSRkMgNTIy MCwgSU1PIGFuIHVwZGF0ZSBvZiB0aGUgcG9saWN5IHRhYmxlCj4gIHwgaXMgdHJpZ2dlcmVkIGJ5 IGFuIGludHJhLXNpdGUgdG9wb2xvZ3kvcG9saWN5IGNoYW5nZS4gU28sIG9ubHkgdGhlCj4gIHwg c2l0ZSBhZG1pbmlzdHJhdG9yIHRyaWdnZXJzIHBvbGljeSB0YWJsZSB1cGRhdGVzLgo+ICB8Cj4g IHwgQ2FuIHdlIGFncmVlIG9uIHRoaXMgYW5hbHlzaXMgPwo+IAo+IEJhc2ljYWxseSwgeWVzLgoK SWYgdGhlcmUgYXJlIGFkZGl0aW9uYWwgdHJpZ2dlcnMsIG5vdyB3b3VsZCBiZSBhIGdvb2QgdGlt ZSB0byBhZGQgdGhlbSA6KQogCldlIG5lZWQgc29tZW9uZSB0byB3cml0ZSBhbiBpbml0aWFsIC0w MCBkcmFmdCB0aGF0IGNhcHR1cmVzIGNvbW1lbnRzIApyYWlzZWQgc28gZmFyLiAgSSBhbSBoYXBw eSB0byBkbyB0aGlzLCB1bmxlc3Mgc29tZW9uZSBlbHNlIGhhcyBhIGJ1cm5pbmcKZGVzaXJlIHRv IGRvIHNvLi4uIHNvIGlmIHRoZXJlIGFyZSBtb3JlIGNvbW1lbnRzIHBsZWFzZSByYWlzZSB0aGVt IGluCnRoZSBuZXh0IGRheSBvciB0d28gc28gd2UgY2FuIGJlIHN1cmUgdG8gY2FwdHVyZSB0aGVt IGluIHRoZSBkcmFmdCB0aGF0CndlIHNob3VsZCBzdWJtaXQgYnkgTW9uZGF5LgoKVGltCgoKPiAg fCBPbiAyMDA4LzEwLzE0LCBhdCAxODozOSwgVGltIENob3duIHdyb3RlOgo+ICB8IAo+ICB8ID4g SGksCj4gIHwgPgo+ICB8ID4gSSB0aGluayB3ZSBuZWVkIHRvIGdldCBhIGxpdHRsZSBmb2N1cyBi YXNlZCBvbiBCcmlhbidzIHN0ZWVyIGZvciB1cywKPiAgfCA+IHNvIHdlIGNhbiBwbGFuIHRvIHBy b2R1Y2UgYW4gaW5pdGlhbCBkcmFmdCB0ZXh0Lgo+ICB8ID4KPiAgfCA+IE5vdGUgdGhlIC0wMCBj dXRvZmYgaXMgMjd0aCBPY3RvYmVyLCBzbyB3ZSBoYXZlIHR3byB3ZWVrcyB0byBwcm9kdWNlCj4g IHwgPiBpbml0aWFsIHRleHQsIGlmIHdlIHdhbnQgdG8gbWFrZSB0aGF0IGN1dG9mZi4KPiAgfCA+ Cj4gIHwgPiBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRoYXQgdGhlIHRleHQgc2hvdWxkIGluaXRp YWxseSBpbmNsdWRlIHRob3VnaHRzCj4gIHwgPiBhbG9uZyB0aGUgbGluZXMgb2YgUnVyaSdzIGlu cHV0LCBpLmUuIHRyaWdnZXJzIGZvciBwb2xpY3kgY2hhbmdlcy4gICBGcm9tCj4gIHwgPiB0aGlz IHdlIHNob3VsZCBnZXQgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBob3cgb2Z0ZW4gYW5kIHdoeSB0 aGUgcG9saWNpZXMKPiAgfCA+IGNoYW5nZS4gICBUaGlzIHNob3VsZCBoZWxwIHVzIGluIHRoZW4g YXBwcmVjaWF0aW5nIHdoaWNoIHNvbHV0aW9uIGZpdHMKPiAgfCA+IGJlc3QuICAgSSBkb24ndCB0 aGluayB3ZSBzaG91bGQgdGFsayBhYm91dCBzb2x1dGlvbiBzcGFjZXMgaW4gLTAwLgo+ICB8ID4K PiAgfCA+IFRoaXMgbXkgaW5pdGlhbCBxdWVzdGlvbiBpcyB3aGF0IHBlb3BsZSBvbiB0aGUgdGVh bSB0aGluayBvZiBSdXJpJ3MKPiAgfCA+IGlucHV0IG9uIHRyaWdnZXJzPwo+ICB8ID4KPiAgfCA+ IEkgYWdyZWUgd2Ugc2hvdWxkIGxvb2sgYSA1MjIwIGFzIG9uZSBzb3VyY2Ugb2YgaW5wdXQuCj4g IHwgPgo+ICB8ID4gT24gdGhlIHN1YmplY3Qgb2YgY2hhbmdlcyB0byBkZWZhdWx0IHBvbGljeSAo MzQ4NCksIEkgc3VzcGVjdCB0aGF0IHdoaWxlCj4gIHwgPiB3ZSBjb3VsZCBtYWtlIGRlZmF1bHRz ICdiZXR0ZXInIGluIHRoZSBnZW5lcmFsIGNhc2UsIGluIHRoaXMgdGVhbSB3ZQo+ICB8ID4gLSBp bml0aWFsbHkgYXQgbGVhc3QgLSBqdXN0IHZpZXcgb25lICd0cmlnZ2VyJyBhcyBiZWluZyBhbiBp bml0aWFsCj4gIHwgPiBkZXBsb3ltZW50IG9mIHBvbGljeSBmb3IgdGhlIHNpdGUgdGhhdCBtYXkg b3ZlcndyaXRlIGNlcnRhaW4gZGVmYXVsdHMuCj4gIHwgPgo+ICB8ID4gVGltCj4gIHwgPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ICB8ID4gYWRkci1z ZWxlY3QtZHQgbWFpbGluZyBsaXN0Cj4gIHwgPiBhZGRyLXNlbGVjdC1kdEBpZXRmLm9yZwo+ICB8 ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGRyLXNlbGVjdC1kdAo+ ICB8IAo+ICB8IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gIHwgYWRkci1zZWxlY3QtZHQgbWFpbGluZyBsaXN0Cj4gIHwgYWRkci1zZWxlY3QtZHRAaWV0 Zi5vcmcKPiAgfCBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZHItc2Vs ZWN0LWR0Cj4gIHwgCgotLSAKVGltCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KYWRkci1zZWxlY3QtZHQgbWFpbGluZyBsaXN0CmFkZHItc2VsZWN0LWR0 QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRkci1zZWxl Y3QtZHQK From addr-select-dt-bounces@ietf.org Wed Oct 22 12:10:44 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B263A68B6; Wed, 22 Oct 2008 12:10:44 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC673A68B6 for ; Wed, 22 Oct 2008 12:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599] 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 4aYYdITeEyGB for ; Wed, 22 Oct 2008 12:10:42 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 8A7783A6828 for ; Wed, 22 Oct 2008 12:10:42 -0700 (PDT) Received: from ([128.244.206.121]) by pilot.jhuapl.edu with ESMTP with TLS id 5502123.121436505; Wed, 22 Oct 2008 15:11:07 -0400 Message-ID: <48FF7ACB.60209@innovationslab.net> Date: Wed, 22 Oct 2008 15:11:07 -0400 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: addr-select-dt@ietf.org Subject: [addr-select-dt] Administrative query X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org All, I have a request pending from sanjay.chalikar@cisnet.net.in to join the design team mailing list. Do any of you know who this is? Regards, Brian _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Wed Oct 22 18:38:07 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015723A6A0F; Wed, 22 Oct 2008 18:38:07 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107173A69C3 for ; Wed, 22 Oct 2008 18:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] 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 OSM6063FFfxA for ; Wed, 22 Oct 2008 18:38:05 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id D90173A6846 for ; Wed, 22 Oct 2008 18:38:04 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9N1dKj8025875; Thu, 23 Oct 2008 10:39:20 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: <2FB9BAFD-6997-43A0-A849-3471CBA8367F@nttv6.net> From: Arifumi Matsumoto To: Brian Haberman In-Reply-To: <48FF7ACB.60209@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 23 Oct 2008 10:39:15 +0900 References: <48FF7ACB.60209@innovationslab.net> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 23 Oct 2008 10:39:20 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] Administrative query X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org I suppose we haven't received any e-mail from him. Let me ask him if he knows what this ML is and really he wants to join us. On 2008/10/23, at 4:11, Brian Haberman wrote: > All, > I have a request pending from sanjay.chalikar@cisnet.net.in to > join the design team mailing list. Do any of you know who this is? > > Regards, > Brian > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Wed Oct 22 23:09:19 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF5E3A6A1C; Wed, 22 Oct 2008 23:09:19 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9020D3A69B2 for ; Wed, 22 Oct 2008 23:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] 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 YWoLBqB7QDIr for ; Wed, 22 Oct 2008 23:09:17 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 6A2D43A66B4 for ; Wed, 22 Oct 2008 23:09:16 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9N69rCd027409; Thu, 23 Oct 2008 15:09:53 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: <9238A83A-2370-4AEB-AEBA-2F63399429D6@nttv6.net> From: Arifumi Matsumoto To: Tim Chown In-Reply-To: <20081021124640.GC26548@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 23 Oct 2008 15:09:49 +0900 References: <20081014093918.GG20073@login.ecs.soton.ac.uk> <20081021.123512.51863029.fujisaki@syce.net> <20081021124640.GC26548@login.ecs.soton.ac.uk> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 23 Oct 2008 15:09:58 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] Focusing on triggers/causes of policy change X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-2022-jp"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi, On 2008/10/21, at 21:46, Tim Chown wrote: > On Tue, Oct 21, 2008 at 12:35:12PM +0900, Tomohiro -INSTALLER- > Fujisaki/藤崎 智宏 wrote: >> >> Hi Arifumi-san, >> >> Do you think we should discuss timing of the policy table >> distribution >> (e.g. host initlalization phase and host running phase)? We can use >> a same protocol all in all phase or not. > > It would certainly simplify the discussion if we could assume that the > same protocol/method can be used for startup and for hosts already > running > with a policy. Is there any reason why this should not be so? Of course, we should start with/assume one protocol/method to fulfill all the problems. And if we cannot, we should handle multiple protocols to cover the problems. Tim, do I get what you mean ? > >> | Regarding RFC 5220, the following cases are listed. >> | Let me try an analysis of these from the aspect of updating >> trigger. >> | >> | 2.1.1. Multiple Routers on a Single >> Interface ..............4 >> | 2.1.2. Ingress Filtering >> Problem ...........................5 >> | 2.1.3. Half-Closed Network >> Problem .........................6 >> | 2.1.4. Combined Use of Global and >> ULA ......................7 >> | 2.1.5. Site >> Renumbering ....................................8 >> | 2.1.6. Multicast Source Address >> Selection ..................9 >> | 2.1.7. Temporary Address >> Selection .........................9 >> | 2.2.1. IPv4 or IPv6 >> Prioritization ........................10 >> | 2.2.2. ULA and IPv4 Dual-Stack >> Environment ................11 >> | 2.2.3. ULA or Global >> Prioritization .......................12 >> | >> | Only 2.1.1 and 2.1.2 may need dynamic policy table update triggered >> | by routing changes, as long as the site uses a dynamic routing >> protocol >> | intra-site and the routing protocol is configured to reflect >> changes >> | of extra-site routing topology. > > I think it's possible that some of the above issues may be addressed > by > an update to RFC3484. agree. e.g. section 2.1.4. > Whether they are or not, we should consider a) > how commonly the above issues arise and b) what the impact of each > might be. and, may be after that, we should consider c) what kind of technical/concrete event can be used for triggering the a policy table update mechanism. e.g. Address re-obtainment, address lifetime expiration, or perhaps policy lifetime expiration. > >> | In such a case, the policy table of hosts may needs to be updated >> | according to the routing policy. >> | It should be noted that we have other mechanims for dynamical >> routing >> | topology change, for example deprecating one of the advertised >> prefixes. >> | This mechanism may help when one of the upstream links has a >> trouble. >> >> I think in a case hosts need to chage their address (e.g. deprecating >> the address), the hosts should re-obtaion the selection policy (in >> the >> case of deprecation, it may be unnecessary to change its policy) and >> the trigger can be the address configuration mechanism (RA or >> DHCPv6). I was talking about non-policy-table-based solution for 2.1.1 and 2.1.2. Generally speaking, I agree that an address change should correspond to policy table update. > When we ran renumbering experiments here, we only had RA available, > and > thus a 'simple' Baker-style renumbering event wouldn't lead to a new > policy update being triggered. And certainly not a DHCP based one. > >> It may be more difficult in a case that hosts do not need to change >> their address, how to inform hosts to re-obtaion the policy, or >> deliver the pollicy to hosts. > > This may be partly related to the discussions about hosts > transitioning > between RA and DHCP environments. There's some cue required that > indicates some 'change' in the network that may require action by the > hosts. > >> When we use DHCPv6 for policy distribution, it is difficult to inform >> hosts to re-obtain the policy (can we use reconfigura message?). > > Indeed. We should capture this as a requirement, or at least a > problem. One possible solution is dhcp lifetime option (RFC 4242). Tim must know better than I ;) > >> | Regarding any other cases in RFC 5220, IMO an update of the >> policy table >> | is triggered by an intra-site topology/policy change. So, only the >> | site administrator triggers policy table updates. >> | >> | Can we agree on this analysis ? >> >> Basically, yes. > > If there are additional triggers, now would be a good time to add > them :) > > > We need someone to write an initial -00 draft that captures comments > raised so far. I am happy to do this, unless someone else has a > burning > desire to do so... so if there are more comments please raise them in > the next day or two so we can be sure to capture them in the draft > that > we should submit by Monday. I was just trying to start drafting. But, I'm sure you are better person for that. :) I really appreciate your offering. Kindest regards, > > > Tim > > >> | On 2008/10/14, at 18:39, Tim Chown wrote: >> | >> | > Hi, >> | > >> | > I think we need to get a little focus based on Brian's steer >> for us, >> | > so we can plan to produce an initial draft text. >> | > >> | > Note the -00 cutoff is 27th October, so we have two weeks to >> produce >> | > initial text, if we want to make that cutoff. >> | > >> | > My suggestion would be that the text should initially include >> thoughts >> | > along the lines of Ruri's input, i.e. triggers for policy >> changes. From >> | > this we should get a better understanding how often and why the >> policies >> | > change. This should help us in then appreciating which >> solution fits >> | > best. I don't think we should talk about solution spaces in >> -00. >> | > >> | > This my initial question is what people on the team think of >> Ruri's >> | > input on triggers? >> | > >> | > I agree we should look a 5220 as one source of input. >> | > >> | > On the subject of changes to default policy (3484), I suspect >> that while >> | > we could make defaults 'better' in the general case, in this >> team we >> | > - initially at least - just view one 'trigger' as being an >> initial >> | > deployment of policy for the site that may overwrite certain >> defaults. >> | > >> | > Tim >> | > _______________________________________________ >> | > addr-select-dt mailing list >> | > addr-select-dt@ietf.org >> | > https://www.ietf.org/mailman/listinfo/addr-select-dt >> | >> | _______________________________________________ >> | addr-select-dt mailing list >> | addr-select-dt@ietf.org >> | https://www.ietf.org/mailman/listinfo/addr-select-dt >> | > > -- > Tim > > > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Fri Oct 24 00:11:20 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CCA3A695F; Fri, 24 Oct 2008 00:11:20 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7367F3A68F8 for ; Fri, 24 Oct 2008 00:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 S+PeugryHa2t for ; Fri, 24 Oct 2008 00:11:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1AB0A3A695F for ; Fri, 24 Oct 2008 00:11:13 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9O7C5Wj022402 for ; Fri, 24 Oct 2008 02:12:32 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 10:12:20 +0300 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 10:12:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 10:12:13 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt Thread-Index: Ack1p6dnl8svZHSKRv2nHqqrxI3t3gAAAJ4g From: To: X-OriginalArrivalTime: 24 Oct 2008 07:12:15.0402 (UTC) FILETIME=[D7DAC8A0:01C935A7] X-Nokia-AV: Clean Subject: [addr-select-dt] FW: I-D ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1676442716==" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org This is a multi-part message in MIME format. --===============1676442716== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C935A7.D7AF2D12" This is a multi-part message in MIME format. ------_=_NextPart_001_01C935A7.D7AF2D12 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Would this design team be interested in discussing about this particular aspect related to address selection problematics? Best regards, Teemu > ______________________________________________=20 > From: Savolainen Teemu (Nokia-D-MSW/Tampere) =20 > Sent: 24 October, 2008 10:11 > To: List Mailing > Subject: I-D > ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt >=20 > Hi, >=20 > Somewhat related to recent address selection discussions, I have > written following I-D describing some scenarios, where even before > actual source & destination address selection happens, a right network > interface has to be selected for DNS resolution to succeed (host in > split horizon DNS environment and connected to multiple walled > gardens).. >=20 > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg22323.htm > l >=20 > Feedback is most appreciated. >=20 > Thank you, >=20 > Teemu >=20 > -------- > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Domain name based network interface selection >=20 > Author(s) : T. Savolainen > Filename : > draft-savolainen-6man-fqdn-based-if-selection-00.txt > Pages : 13 > Date : 2008-10-23 > =09 > A multi-homed host with multiple physical and/or virtual network=20 > interfaces has to select which one of the network interfaces to use >=20 > for a new outgoing IPv4 or IPv6 connection. This document describes > a=20 > method to select an interface by using destination's fully > qualified=20 > domain name and DNS suffix information received dynamically for > each=20 > network interface. The method is useful, for example, in split=20 > horizon DNS and walled garden scenarios, where right network=20 > interface has to be selected even before DNS resolution is > conducted. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-savolainen-6man-fqdn-based-i > f-selection-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > f-selection-00.txt> > f-selection-00.txt>=20 >=20 ------_=_NextPart_001_01C935A7.D7AF2D12 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FW: I-D = ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt

Hi,

Would this design = team be interested in discussing about this particular aspect related to = address selection problematics?

Best regards,

        Teemu

    ______________________________________________
    From:   Savolainen Teemu (Nokia-D-MSW/Tampere)  =
    Sent:   24 October, 2008 10:11
    To:     List Mailing
    Subject:       = I-D = ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt

    Hi,

    Somewhat related to recent address = selection discussions, I have written following I-D describing some = scenarios,  where even before actual source & destination = address selection happens, a right network interface has to be selected = for DNS resolution to succeed (host in split horizon DNS environment and = connected to multiple walled gardens)..

    http://www.ietf.org/mail-archive/web/i-d-announce/current/= msg22323.html

    Feedback is most appreciated.

    Thank you,

            Teemu

    --------
    A New Internet-Draft is = available from the on-line Internet-Drafts
    directories.


            Title   =         : Domain name based network = interface selection 
            Author(s)       : T. = Savolainen
            Filename        = : draft-savolainen-6man-fqdn-based-if-selection-00.txt
            Pages   =         : 13
            Date    =         : 2008-10-23
           =20
    A multi-homed host with multiple = physical and/or virtual network
       interfaces has to = select which one of the network interfaces to use
       for a new outgoing = IPv4 or IPv6 connection. This document describes a
       method to select an = interface by using destination's fully qualified
       domain name and DNS = suffix information received dynamically for each
       network interface. = The method is useful, for example, in split
       horizon DNS and = walled garden scenarios, where right network
       interface has to be = selected even before DNS resolution is conducted.

    A URL for this Internet-Draft = is:
    http://www.ietf.org/internet-drafts/draft-savolainen-6man-fqdn-based= -if-selection-00.txt

    Internet-Drafts are also = available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    Below is the data which will = enable a MIME compliant mail reader
    implementation to automatically = retrieve the ASCII version of the
    Internet-Draft.
    <ftp://ftp.ietf.org/internet-drafts/draft-savolainen-6man-fqdn-= based-if-selection-00.txt>

------_=_NextPart_001_01C935A7.D7AF2D12-- --===============1676442716== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt --===============1676442716==-- From addr-select-dt-bounces@ietf.org Fri Oct 24 04:06:09 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720193A697B; Fri, 24 Oct 2008 04:06:09 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24203A68E5 for ; Fri, 24 Oct 2008 04:06:07 -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=[BAYES_00=-2.599] 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 FBO8eoeCfDjZ for ; Fri, 24 Oct 2008 04:06:07 -0700 (PDT) Received: from owl.ecs.soton.ac.uk (owl.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe77:96e]) by core3.amsl.com (Postfix) with ESMTP id CA91F3A689F for ; Fri, 24 Oct 2008 04:06:06 -0700 (PDT) X-ECS-MailScanner-Watermark: 1225451232.48439@a378C7u0Zq3s0a7YxwEPTA Received: from gander.ecs.soton.ac.uk ([IPv6:2001:630:d0:f102:21d:9ff:fe22:9fc]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m9OB7CfI016639 for ; Fri, 24 Oct 2008 12:07:12 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id m9OB7Gxc018216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Oct 2008 12:07:16 +0100 Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id m9OB7GuY024436 for ; Fri, 24 Oct 2008 12:07:16 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id m9OB7GEx024435 for addr-select-dt@ietf.org; Fri, 24 Oct 2008 12:07:16 +0100 Date: Fri, 24 Oct 2008 12:07:16 +0100 From: Tim Chown To: addr-select-dt@ietf.org Message-ID: <20081024110716.GD12828@login.ecs.soton.ac.uk> References: <20081014093918.GG20073@login.ecs.soton.ac.uk> <20081021.123512.51863029.fujisaki@syce.net> <20081021124640.GC26548@login.ecs.soton.ac.uk> <9238A83A-2370-4AEB-AEBA-2F63399429D6@nttv6.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <9238A83A-2370-4AEB-AEBA-2F63399429D6@nttv6.net> User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner-ID: m9OB7Gxc018216 X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m9OB7CfI016639 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [addr-select-dt] Focusing on triggers/causes of policy change X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org On Thu, Oct 23, 2008 at 03:09:49PM +0900, Arifumi Matsumoto wrote: > >We need someone to write an initial -00 draft that captures comments > >raised so far. I am happy to do this, unless someone else has a > >burning > >desire to do so... so if there are more comments please raise them in > >the next day or two so we can be sure to capture them in the draft > >that > >we should submit by Monday. > > I was just trying to start drafting. > But, I'm sure you are better person for that. :) > I really appreciate your offering. OK, I am beginning to draft a text today that I'll circulate soon. This will give some time for comments before submitting on Monday. Tim _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Sun Oct 26 11:08:55 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2279B3A6A5E; Sun, 26 Oct 2008 11:08:55 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E714B3A6A5E for ; Sun, 26 Oct 2008 11:08:53 -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=[BAYES_00=-2.599] 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 5qRjii34iw1f for ; Sun, 26 Oct 2008 11:08:50 -0700 (PDT) Received: from owl.ecs.soton.ac.uk (owl.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe77:96e]) by core3.amsl.com (Postfix) with ESMTP id 8A1733A681A for ; Sun, 26 Oct 2008 11:08:49 -0700 (PDT) X-ECS-MailScanner-Watermark: 1225649400.05143@CjGR9HUxOWyqx1zlQqZ6RA Received: from gander.ecs.soton.ac.uk ([IPv6:2001:630:d0:f102:21d:9ff:fe22:9fc]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m9QI9wYE030554 for ; Sun, 26 Oct 2008 18:09:58 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id m9QIA3fB025665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Oct 2008 18:10:03 GMT Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id m9QIA3Jq032291 for ; Sun, 26 Oct 2008 18:10:03 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id m9QIA3XM032290 for addr-select-dt@ietf.org; Sun, 26 Oct 2008 18:10:03 GMT Date: Sun, 26 Oct 2008 18:10:03 +0000 From: Tim Chown To: addr-select-dt@ietf.org Message-ID: <20081026181003.GA30980@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner-ID: m9QIA3fB025665 X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m9QI9wYE030554 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [addr-select-dt] A strawman draft text - inputs please X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have gathered together comments to the list into an initial draft. You can view it here: http://users.ecs.soton.ac.uk/tjc/ietf/draft-chown-addr-select-considerations-00.txt Or see the attached .xml and .txt files. The -00 submission is Monday night, so please send any comments to me as soon as possible, on the general direction, contents and anything you'd like to see added or removed. Tim PS. Any xml2rfc advice on how to do the (Editor) bit in the text would be useful, so I show as editor not author :) --ZGiS0Q5IWpPtfppv Content-Type: text/xml; charset=us-ascii Content-Disposition: attachment; filename="draft-chown-addr-select-considerations-00.xml" Considerations for IPv6 Address Selection Policy Changes University of Southampton
Southampton SO17 1BJ Hampshire United Kingdom tjc@ecs.soton.ac.uk
Operations IPv6 Operations This text describes the issues surrounding the capability of hosts and networks to be able to have their policies for IPv6 Default Address Selection changed. It discusses considerations for such policy changes, e.g. examples of requirements that may require a change of policy, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC3484 , where IPv6 Deafult Address Selection methods are currently defined.
There have been various operational issues observed (RFC5220) with Default Address Selection for IPv6 (RFC3484) . As as a result, there has been some demand for the capability for systems and networks to be able to have their policy tables, and potentially the rules described in RFC3484, to be modified.
There are a number of aspects to consider in the context of address selection policy updates. First is the frequency for which such updates are likely to be required; this will be determined largely from identifying the scenarios in which a policy change will be required. This may include overriding default system policies on startup, as well as changes while the system is running. Second, by understanding how dynamic the policy update mechanism needs to be we should be better placed to determine what types of update approaches best meet those needs. There may be other considerations of course, e.g. whether the systems are in managed or unmanaged environments, and whether the solution should be proactive or automated, as discussed in . Third, if we assume some policy update mechanism is defined we should consider how hosts and systems may become aware that a policy change has happened, and how policy can be disseminated in a timely fashion. Thus we need to understand what kind of technical/concrete event can be used for triggering the a policy table update mechanism, e.g. address re-obtainment, address lifetime expiration, or perhaps policy lifetime expiration. Finally, we should assess whether these update solutions require/need 3484 to be updated. In some instances, we might envision solutions that simply use RFC3484 as guidelines and provide sufficient controls to address the current limitations in the RFC. However, as noted in RFC5220 , not all the operational issues observed to date can be remedied by updating RFC3484 alone. Thus there may be further work required elsewhere, which may include an RFC3484 update, to address all the issues detailed in RFC5220, as described in ).
We note that there is some existing work in defining Requirements for Address Selection Machanisms , and some initial work has been done in the solution space (for DHCP) , but these are not discussed here. However, RFC5221 does assume that a dynamic policy update mechanism of some form is available.
We wish to determine how frequent address selection policy changes are likely to be, for which we need to understand why the policies might need to be changed, for particular sites or networks (and then see how this might affect the potential solutions). One obvious source of drivers for policy change is RFC5220, in which operational issues with the existing policies described in RFC3484 are listed. There have been some significant changes to IPv6 since RFC3484 was drafted, the introduction of Unique Local Addresses (ULAs) being one such change that has impacted the RFC. In summary, the issues raised in RFC5220 were: Multiple Routers on a Single Interface Ingress Filtering Problem Half-Closed Network Problem (*) Combined Use of Global and ULA (*) Site Renumbering (*) Multicast Source Address Selection (*) Temporary Address Selection IPv4 or IPv6 Prioritization (*) ULA and IPv4 Dual-Stack Environment (*) ULA or Global Prioritization (*) The authors of RFC5220 noted which of these issues can be solved by changes to the RFC3484 policy table, marked (*) above, and which cannot. It is interesting to note that issues largely related to internal networking and policy decisions can be handled this way.
When considering drivers or triggers that may lead to a requirement for the policy to change, we can consider those external to a site or network and those internal. In the case of the first two examples above, a dynamic policy table update may be required by routing changes, assuming the site uses a dynamic routing protocol intra-site and the routing protocol is configured to reflect changes of extra-site routing topology. In such a case, the policy table of hosts may needs to be updated according to the routing policy. It should be noted that we have other mechanims for dynamic routing topology change, for example deprecating one of the advertised prefixes, perhaps when one of the upstream links has a problems. Other examples of external factors include a new transition mechanism being defined (e.g. as with the emergence of Teredo using 2001::/32 as assigned by IANA) and its inclusion being required in the policy table, or a site renumbering event that could be triggered by an upstream provider.
The other examples above are, in the general case, where the site administrator chooses to change a local policy and in doing so triggers the need for policy table updates. Some of these changes one might assume to be set once and to change rarely, e.g.: Setting priority use of IPv6 over IPv4 (or vice versa). Setting priority use of ULAs over globals (or vice versa). Setting priority use of privacy addresses over globals (or vice versa). An internal network renumbering occurs, perhaps due to a site expanding. Disabling longest-prefix match functions to facilitate round-robin load balancing. However it may be the case that different parts of a site have different policies, or policies are changed in a rolling fashion across a site over time as IPv6 or ULAs are introduced (for example). Other administrative changes may occur more frequently, e.g.: Routing tables and forwarding tables change dynamically. A different provider (link) is preferred for a given destination. It's possible that provider links may vary on a daily basis, or by time of day.
When a host starts up it may be configured with the default RFC3484 policies. At this stage a number of addresses may be confiured on a number of interfaces on the host. At this time it may be desirable for the host to be able to receive the site-specific policy updates as a start-up override from the RFC3484 defaults. Other policy changes may be required while the host is running. Ideally the same protocol should be used for the start-up and running state updates.
When a policy table change is made, the change of policy needs to be propogated to the hosts in a network. >From the host perspective, one could assume that when a host changes an address, it should re-obtain the selection policy. If the policy is distributed via the same mechanism that informs a host of a change of address(es), the application of the policy should be synchronised sufficiently with the address change. However, not all hosts may receive the update information at the same time, e.g. dependent on DHCP lease timers. Where hosts use DHCPv6 for address information, in the absence of some form of Reconfigure message, a host may see a delay in policy changes being notified. It should also be noted of course that not all policy changes are tied to a host changing one or more addresses. One possible tool to help here is the DHCPv6 Lifetime Option (RFC4242), which was originally introduced to assist with network renumbering events. Thus there is a general issue of timely and synchronised dissemination of new policy.
The discussion above suggests that many of the potential triggers for policy table changes are 'one-off' in nature, i.e. a site makes a one-time policy change. However, there are also some cases where updates may be required to be more frequent, e.g. the gradual introduction of new policy across a large site, and cases where preferred links for certain destinations change frequently over time (possibly daily). It is not clear how common these cases are.
RFC3484 includes text about mechanisms for changing policy, having 'policy hooks' and having a configurable policy table. The implication is that defaults can be changed, and the text gives examples of this in Section 10. That said, it remains the case that some operational issues with RFC3484 are not just related to the table, but on rules themselves, e.g. longest prefix match (affecting DNS round robin as described in ). We should note though that the word 'default' has to be defined here, i.e. what is the scope of this 'default'. It seems it is 'system wide' but first it just moves the issue to the 'system' definition and second larger or smaller granularities make sense (for instance 'link wide' and 'user wide'). Whether and how this can be considered in an open question. It certainly seems the case that the issues raised in RFC5220, and discussed in mean that an update of RFC3484 is required, if only because some of the issues (as highlighted earlier) cannot be addressed by updating the policy table alone.
In this first draft we avoid any discussion of impact on or implications for solutions. Except that it would be highly preferable if the start-up and running state solutions used the same protocol.
There are no extra Security consideration for this document.
There are no extra IANA consideration for this document.
The design team working on this draft is: Marcelo Bagnulo Braun, Marc Blanchet, Tim Chown, Francis Dupont, Tim Enos, TJ Evans, Brian Haberman, Tony Hain, Ruri Hiromi, Suresh Krishnan, Arifumi Matsumoto, Janos Mohacsi, Sebastien Roy, Teemu Savolainen, Fujisaki Tomohiro, and John Zhao.
&RFC3484; &RFC5220; &RFC5221; &SOLUTIONS; &DHCOPT; &REVISE; --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-chown-addr-select-considerations-00.txt" IPv6 Operations T. Chown Internet-Draft University of Southampton Intended status: Informational October 26, 2008 Expires: April 29, 2009 Considerations for IPv6 Address Selection Policy Changes draft-chown-addr-select-triggers-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This text describes the issues surrounding the capability of hosts and networks to be able to have their policies for IPv6 Default Address Selection changed. It discusses considerations for such policy changes, e.g. examples of requirements that may require a change of policy, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC3484 [1], where IPv6 Deafult Address Selection methods are currently defined. Chown Expires April 29, 2009 [Page 1] Internet-Draft Address Selection Considerations October 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 3 3. Other Related Work . . . . . . . . . . . . . . . . . . . . . . 3 4. Drivers for Policy Changes . . . . . . . . . . . . . . . . . . 4 4.1. Internal vs External Tiggers . . . . . . . . . . . . . . . 5 4.2. Administratively Triggered Changes . . . . . . . . . . . . 5 4.3. Start-up vs Running Changes . . . . . . . . . . . . . . . . 6 5. On Address Changes and Obtaining Policy . . . . . . . . . . . . 6 6. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . . 7 8. Considerations for Solutions . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 12. Informative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Chown Expires April 29, 2009 [Page 2] Internet-Draft Address Selection Considerations October 2008 1. Introduction There have been various operational issues observed (RFC5220) [2] with Default Address Selection for IPv6 (RFC3484) [1]. As as a result, there has been some demand for the capability for systems and networks to be able to have their policy tables, and potentially the rules described in RFC3484, to be modified. 2. Issues to Consider There are a number of aspects to consider in the context of address selection policy updates. First is the frequency for which such updates are likely to be required; this will be determined largely from identifying the scenarios in which a policy change will be required. This may include overriding default system policies on startup, as well as changes while the system is running. Second, by understanding how dynamic the policy update mechanism needs to be we should be better placed to determine what types of update approaches best meet those needs. There may be other considerations of course, e.g. whether the systems are in managed or unmanaged environments, and whether the solution should be proactive or automated, as discussed in [4]. Third, if we assume some policy update mechanism is defined we should consider how hosts and systems may become aware that a policy change has happened, and how policy can be disseminated in a timely fashion. Thus we need to understand what kind of technical/concrete event can be used for triggering the a policy table update mechanism, e.g. address re-obtainment, address lifetime expiration, or perhaps policy lifetime expiration. Finally, we should assess whether these update solutions require/need 3484 to be updated. In some instances, we might envision solutions that simply use RFC3484 as guidelines and provide sufficient controls to address the current limitations in the RFC. However, as noted in RFC5220 [2], not all the operational issues observed to date can be remedied by updating RFC3484 alone. Thus there may be further work required elsewhere, which may include an RFC3484 update, to address all the issues detailed in RFC5220, as described in [6]). 3. Other Related Work We note that there is some existing work in defining Requirements for Chown Expires April 29, 2009 [Page 3] Internet-Draft Address Selection Considerations October 2008 Address Selection Machanisms [3], and some initial work has been done in the solution space (for DHCP) [5], but these are not discussed here. However, RFC5221 does assume that a dynamic policy update mechanism of some form is available. 4. Drivers for Policy Changes We wish to determine how frequent address selection policy changes are likely to be, for which we need to understand why the policies might need to be changed, for particular sites or networks (and then see how this might affect the potential solutions). One obvious source of drivers for policy change is RFC5220, in which operational issues with the existing policies described in RFC3484 are listed. There have been some significant changes to IPv6 since RFC3484 was drafted, the introduction of Unique Local Addresses (ULAs) being one such change that has impacted the RFC. In summary, the issues raised in RFC5220 were: o Multiple Routers on a Single Interface o Ingress Filtering o Problem Half-Closed Network Problem (*) o Combined Use of Global and ULA (*) o Site Renumbering (*) o Multicast Source Address Selection (*) o Temporary Address Selection o IPv4 or IPv6 Prioritization (*) o ULA and IPv4 Dual-Stack Environment (*) o ULA or Global Prioritization (*) The authors of RFC5220 noted which of these issues can be solved by changes to the RFC3484 policy table, marked (*) above, and which cannot. It is interesting to note that issues largely related to internal networking and policy decisions can be handled this way. Chown Expires April 29, 2009 [Page 4] Internet-Draft Address Selection Considerations October 2008 4.1. Internal vs External Tiggers When considering drivers or triggers that may lead to a requirement for the policy to change, we can consider those external to a site or network and those internal. In the case of the first two examples above, a dynamic policy table update may be required by routing changes, assuming the site uses a dynamic routing protocol intra-site and the routing protocol is configured to reflect changes of extra- site routing topology. In such a case, the policy table of hosts may needs to be updated according to the routing policy. It should be noted that we have other mechanims for dynamic routing topology change, for example deprecating one of the advertised prefixes, perhaps when one of the upstream links has a problems. Other examples of external factors include a new transition mechanism being defined (e.g. as with the emergence of Teredo using 2001::/32 as assigned by IANA) and its inclusion being required in the policy table, or a site renumbering event that could be triggered by an upstream provider. 4.2. Administratively Triggered Changes The other examples above are, in the general case, where the site administrator chooses to change a local policy and in doing so triggers the need for policy table updates. Some of these changes one might assume to be set once and to change rarely, e.g.: o Setting priority use of IPv6 over IPv4 (or vice versa). o Setting priority use of ULAs over globals (or vice versa). o Setting priority use of privacy addresses over globals (or vice versa). o An internal network renumbering occurs, perhaps due to a site expanding. o Disabling longest-prefix match functions to facilitate round-robin load balancing. However it may be the case that different parts of a site have different policies, or policies are changed in a rolling fashion across a site over time as IPv6 or ULAs are introduced (for example). Other administrative changes may occur more frequently, e.g.: Chown Expires April 29, 2009 [Page 5] Internet-Draft Address Selection Considerations October 2008 o Routing tables and forwarding tables change dynamically. o A different provider (link) is preferred for a given destination. It's possible that provider links may vary on a daily basis, or by time of day. 4.3. Start-up vs Running Changes When a host starts up it may be configured with the default RFC3484 policies. At this stage a number of addresses may be confiured on a number of interfaces on the host. At this time it may be desirable for the host to be able to receive the site-specific policy updates as a start-up override from the RFC3484 defaults. Other policy changes may be required while the host is running. Ideally the same protocol should be used for the start-up and running state updates. 5. On Address Changes and Obtaining Policy When a policy table change is made, the change of policy needs to be propogated to the hosts in a network. From the host perspective, one could assume that when a host changes an address, it should re-obtain the selection policy. If the policy is distributed via the same mechanism that informs a host of a change of address(es), the application of the policy should be synchronised sufficiently with the address change. However, not all hosts may receive the update information at the same time, e.g. dependent on DHCP lease timers. Where hosts use DHCPv6 for address information, in the absence of some form of Reconfigure message, a host may see a delay in policy changes being notified. It should also be noted of course that not all policy changes are tied to a host changing one or more addresses. One possible tool to help here is the DHCPv6 Lifetime Option (RFC4242), which was originally introduced to assist with network renumbering events. Thus there is a general issue of timely and synchronised dissemination of new policy. 6. How Dynamic? The discussion above suggests that many of the potential triggers for policy table changes are 'one-off' in nature, i.e. a site makes a one-time policy change. Chown Expires April 29, 2009 [Page 6] Internet-Draft Address Selection Considerations October 2008 However, there are also some cases where updates may be required to be more frequent, e.g. the gradual introduction of new policy across a large site, and cases where preferred links for certain destinations change frequently over time (possibly daily). It is not clear how common these cases are. 7. On RFC3484 Default Policies RFC3484 includes text about mechanisms for changing policy, having 'policy hooks' and having a configurable policy table. The implication is that defaults can be changed, and the text gives examples of this in Section 10. That said, it remains the case that some operational issues with RFC3484 are not just related to the table, but on rules themselves, e.g. longest prefix match (affecting DNS round robin as described in [2]). We should note though that the word 'default' has to be defined here, i.e. what is the scope of this 'default'. It seems it is 'system wide' but first it just moves the issue to the 'system' definition and second larger or smaller granularities make sense (for instance 'link wide' and 'user wide'). Whether and how this can be considered in an open question. It certainly seems the case that the issues raised in RFC5220, and discussed in [6] mean that an update of RFC3484 is required, if only because some of the issues (as highlighted earlier) cannot be addressed by updating the policy table alone. 8. Considerations for Solutions In this first draft we avoid any discussion of impact on or implications for solutions. Except that it would be highly preferable if the start-up and running state solutions used the same protocol. 9. Security Considerations There are no extra Security consideration for this document. 10. IANA Considerations There are no extra IANA consideration for this document. Chown Expires April 29, 2009 [Page 7] Internet-Draft Address Selection Considerations October 2008 11. Acknowledgements The design team working on this draft is: Marcelo Bagnulo Braun, Marc Blanchet, Tim Chown, Francis Dupont, Tim Enos, TJ Evans, Brian Haberman, Tony Hain, Ruri Hiromi, Suresh Krishnan, Arifumi Matsumoto, Janos Mohacsi, Sebastien Roy, Teemu Savolainen, Fujisaki Tomohiro, and John Zhao. 12. Informative References [1] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [2] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008. [3] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Requirements for Address Selection Mechanisms", RFC 5221, July 2008. [4] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Solution approaches for address-selection problems", draft-ietf-6man-addr-select-sol-01 (work in progress), June 2008. [5] Fujisaki, T., Matsumoto, A., Niinobe, S., Hiromi, R., and K. Kanayama, "Distributing Address Selection Policy using DHCPv6", draft-fujisaki-dhc-addr-select-opt-06 (work in progress), June 2008. [6] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Things To Be Considered for RFC 3484 Revision", draft-arifumi-6man-rfc3484-revise-00 (work in progress), June 2008. Author's Address Tim Chown (ed) University of Southampton Southampton, Hampshire SO17 1BJ United Kingdom Email: tjc@ecs.soton.ac.uk Chown Expires April 29, 2009 [Page 8] Internet-Draft Address Selection Considerations October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Chown Expires April 29, 2009 [Page 9] --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt --ZGiS0Q5IWpPtfppv-- From addr-select-dt-bounces@ietf.org Sun Oct 26 19:11:52 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830CD3A6987; Sun, 26 Oct 2008 19:11:52 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D853A6912 for ; Sun, 26 Oct 2008 19:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 LzZpVfLDsE8y for ; Sun, 26 Oct 2008 19:11:51 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C1A603A6955 for ; Sun, 26 Oct 2008 19:11:47 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9R2AefU001889; Mon, 27 Oct 2008 11:10:40 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: <5FC9806A-F34F-4C16-BC2D-657FB92C9825@nttv6.net> From: Arifumi Matsumoto To: Tim Chown In-Reply-To: <20081026181003.GA30980@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 27 Oct 2008 11:10:35 +0900 References: <20081026181003.GA30980@login.ecs.soton.ac.uk> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Mon, 27 Oct 2008 11:10:40 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] A strawman draft text - inputs please X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Tim, thank you very much for your generous contribution. Regarding authors list, I think it would be better to follow this draft. http://tools.ietf.org/html/draft-ietf-ipv6-node-requirements-11 I'm sorry, but I cannot advice on xml2rfc. On 2008/10/27, at 3:10, Tim Chown wrote: > Hi, > > I have gathered together comments to the list into an initial draft. > > You can view it here: > http://users.ecs.soton.ac.uk/tjc/ietf/draft-chown-addr-select-considerations-00.txt > > Or see the attached .xml and .txt files. > > The -00 submission is Monday night, so please send any comments to me > as soon as possible, on the general direction, contents and anything > you'd > like to see added or removed. > > Tim > > PS. Any xml2rfc advice on how to do the (Editor) bit in the text would > be useful, so I show as editor not author :) > select- > considerations-00.txt>_______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Sun Oct 26 23:28:09 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EC33A6855; Sun, 26 Oct 2008 23:28:09 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247BA3A6800 for ; Sun, 26 Oct 2008 23:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] 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 BuPbq-whNz1p for ; Sun, 26 Oct 2008 23:28:07 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id DE2F33A677E for ; Sun, 26 Oct 2008 23:28:06 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9R6S3aH003222; Mon, 27 Oct 2008 15:28:03 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: "" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 27 Oct 2008 15:27:57 +0900 References: X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Mon, 27 Oct 2008 15:28:04 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] FW: I-D ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Teemu, I suppose your draft contains problem statements and a solution. Regarding the solution, IMO I'm personally very much interested in your proposal, but this seems to be out of scope of this design team, where we focus on such a address selection mechanism that is based on dynamic policy table updates. Regarding the problem statement, the issue of address selection itself is covered in RFC 5220. Though DNS resolving issue is not clearly written in that RFC, section 2.1.3 covers general problematic case of walled garden network. Kindest regards, On 2008/10/24, at 16:12, wrote: > Hi, > > Would this design team be interested in discussing about this > particular aspect related to address selection problematics? > > Best regards, > > Teemu > > ______________________________________________ > From: Savolainen Teemu (Nokia-D-MSW/Tampere) > Sent: 24 October, 2008 10:11 > To: List Mailing > Subject: I-D ACTION:draft-savolainen-6man-fqdn-based-if- > selection-00.txt > > Hi, > > Somewhat related to recent address selection discussions, I have > written following I-D describing some scenarios, where even before > actual source & destination address selection happens, a right > network interface has to be selected for DNS resolution to succeed > (host in split horizon DNS environment and connected to multiple > walled gardens).. > > http://www.ietf.org/mail-archive/web/i-d-announce/current/ > msg22323.html > > Feedback is most appreciated. > > Thank you, > > Teemu > > -------- > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Domain name based network interface > selection > Author(s) : T. Savolainen > Filename : draft-savolainen-6man-fqdn-based-if- > selection-00.txt > Pages : 13 > Date : 2008-10-23 > > A multi-homed host with multiple physical and/or virtual network > interfaces has to select which one of the network interfaces to use > for a new outgoing IPv4 or IPv6 connection. This document > describes a > method to select an interface by using destination's fully > qualified > domain name and DNS suffix information received dynamically for > each > network interface. The method is useful, for example, in split > horizon DNS and walled garden scenarios, where right network > interface has to be selected even before DNS resolution is > conducted. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-savolainen-6man-fqdn-based-if-selection-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Mon Oct 27 00:25:08 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FB53A6A81; Mon, 27 Oct 2008 00:25:08 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A8D3A6A8F for ; Mon, 27 Oct 2008 00:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LRNAUrx6Rkx3 for ; Mon, 27 Oct 2008 00:25:04 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9210B3A6A46 for ; Mon, 27 Oct 2008 00:25:02 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9R7OqCs001068; Mon, 27 Oct 2008 09:24:59 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 09:24:55 +0200 Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 09:24:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 09:24:50 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [addr-select-dt] FW: I-D ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt Thread-Index: Ack3/TDBN7QtQ94aRLCJrlNRxvcPNAABiSVQ References: From: To: X-OriginalArrivalTime: 27 Oct 2008 07:24:51.0410 (UTC) FILETIME=[19B5B320:01C93805] X-Nokia-AV: Clean Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] FW: I-D ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi, The 2.1.3 indeed covers the general case well, but I fail to see this DNS resolving issue mentioned in any way. So the "address selection mechanism that is based on dynamic policy table updates" will not be covering the DNS server selection problem? Best regards, Teemu >-----Original Message----- >From: ext Arifumi Matsumoto [mailto:arifumi@nttv6.net] >Sent: 27 October, 2008 08:28 >To: Savolainen Teemu (Nokia-D-MSW/Tampere) >Cc: addr-select-dt@ietf.org >Subject: Re: [addr-select-dt] FW: I-D >ACTION:draft-savolainen-6man-fqdn-based-if-selection-00.txt > >Teemu, > >I suppose your draft contains problem statements and a solution. >Regarding the solution, IMO I'm personally very much >interested in your proposal, but this seems to be out of scope >of this design team, where we focus on such a address >selection mechanism that is based on dynamic policy table updates. > >Regarding the problem statement, the issue of address >selection itself is covered in RFC 5220. Though DNS resolving >issue is not clearly written in that RFC, section 2.1.3 covers >general problematic case of walled garden network. > >Kindest regards, > >On 2008/10/24, at 16:12, > wrote: > >> Hi, >> >> Would this design team be interested in discussing about this >> particular aspect related to address selection problematics? >> >> Best regards, >> >> Teemu >> >> ______________________________________________ >> From: Savolainen Teemu (Nokia-D-MSW/Tampere) >> Sent: 24 October, 2008 10:11 >> To: List Mailing >> Subject: I-D ACTION:draft-savolainen-6man-fqdn-based-if- >> selection-00.txt >> >> Hi, >> >> Somewhat related to recent address selection discussions, I have >> written following I-D describing some scenarios, where even before >> actual source & destination address selection happens, a >right network >> interface has to be selected for DNS resolution to succeed (host in >> split horizon DNS environment and connected to multiple walled >> gardens).. >> >> http://www.ietf.org/mail-archive/web/i-d-announce/current/ >> msg22323.html >> >> Feedback is most appreciated. >> >> Thank you, >> >> Teemu >> >> -------- >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Domain name based network interface >> selection >> Author(s) : T. Savolainen >> Filename : draft-savolainen-6man-fqdn-based-if- >> selection-00.txt >> Pages : 13 >> Date : 2008-10-23 >> >> A multi-homed host with multiple physical and/or virtual network >> interfaces has to select which one of the network >interfaces to use >> for a new outgoing IPv4 or IPv6 connection. This document >describes >> a >> method to select an interface by using destination's fully >> qualified >> domain name and DNS suffix information received dynamically for >> each >> network interface. The method is useful, for example, in split >> horizon DNS and walled garden scenarios, where right network >> interface has to be selected even before DNS resolution is >> conducted. >> >> A URL for this Internet-Draft is: >> >http://www.ietf.org/internet-drafts/draft-savolainen-6man-fqdn-based-i >> f-selection-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> f-selection-00.txt >> > >> >> _______________________________________________ >> addr-select-dt mailing list >> addr-select-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/addr-select-dt > > _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Mon Oct 27 01:00:55 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A7228C172; Mon, 27 Oct 2008 01:00:55 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC9128C170 for ; Mon, 27 Oct 2008 01:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 FoaJWEwUY1Xg for ; Mon, 27 Oct 2008 01:00:53 -0700 (PDT) Received: from owl.ecs.soton.ac.uk (owl.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe77:96e]) by core3.amsl.com (Postfix) with ESMTP id 1F23028C171 for ; Mon, 27 Oct 2008 01:00:51 -0700 (PDT) X-ECS-MailScanner-Watermark: 1225699234.79144@80U4fdTd2fWKypRKd+8FPQ Received: from gander.ecs.soton.ac.uk ([IPv6:2001:630:d0:f102:21d:9ff:fe22:9fc]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m9R80YEu008154 for ; Mon, 27 Oct 2008 08:00:34 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id m9R80e31030263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Oct 2008 08:00:40 GMT Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id m9R80drh029744 for ; Mon, 27 Oct 2008 08:00:39 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id m9R80dFk029743 for addr-select-dt@ietf.org; Mon, 27 Oct 2008 08:00:39 GMT Date: Mon, 27 Oct 2008 08:00:39 +0000 From: Tim Chown To: addr-select-dt@ietf.org Message-ID: <20081027080039.GA29082@login.ecs.soton.ac.uk> References: <20081026181003.GA30980@login.ecs.soton.ac.uk> <5FC9806A-F34F-4C16-BC2D-657FB92C9825@nttv6.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <5FC9806A-F34F-4C16-BC2D-657FB92C9825@nttv6.net> User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner-ID: m9R80e31030263 X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m9R80YEu008154 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [addr-select-dt] A strawman draft text - inputs please X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org On Mon, Oct 27, 2008 at 11:10:35AM +0900, Arifumi Matsumoto wrote: > Tim, > thank you very much for your generous contribution. > > Regarding authors list, I think it would be better to follow this draft. > http://tools.ietf.org/html/draft-ietf-ipv6-node-requirements-11 > > I'm sorry, but I cannot advice on xml2rfc. Thanks, Brian has told me the xml2rfc magic to fix the problem. I'll also add email addresses for contacts where I have them (or wait until the second version and be sure to add all contacts then). At the moment, any input on the text itself is most welcome. As it stands it's a gathered summary of what's been raised on the list, but it certainly has a lot of room for improvement. Tim _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Tue Oct 28 03:40:22 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117AA3A6BEE; Tue, 28 Oct 2008 03:40:22 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24A43A6958 for ; Tue, 28 Oct 2008 03:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] 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 QxGhxVAaREK3 for ; Tue, 28 Oct 2008 03:40:19 -0700 (PDT) Received: from owl.ecs.soton.ac.uk (owl.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe77:96e]) by core3.amsl.com (Postfix) with ESMTP id 508D43A6BEE for ; Tue, 28 Oct 2008 03:40:19 -0700 (PDT) X-ECS-MailScanner-Watermark: 1225795201.12006@63XXWWCBBnPfRDSwQcSnZQ Received: from gander.ecs.soton.ac.uk ([IPv6:2001:630:d0:f102:21d:9ff:fe22:9fc]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m9SAdxpd001759 for ; Tue, 28 Oct 2008 10:40:00 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id m9SAe5qH010128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Oct 2008 10:40:05 GMT Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id m9SAe5D1009319 for ; Tue, 28 Oct 2008 10:40:05 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id m9SAe5Nd009318 for addr-select-dt@ietf.org; Tue, 28 Oct 2008 10:40:05 GMT Date: Tue, 28 Oct 2008 10:40:05 +0000 From: Tim Chown To: addr-select-dt@ietf.org Message-ID: <20081028104005.GF6743@login.ecs.soton.ac.uk> References: <20081027211501.8C6DD28C172@core3.amsl.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081027211501.8C6DD28C172@core3.amsl.com> User-Agent: Mutt/1.4.2.2i X-ECS-MailScanner-ID: m9SAe5qH010128 X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: m9SAdxpd001759 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [addr-select-dt] I-D Action:draft-chown-addr-select-considerations-00.txt X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi, The draft has been submitted, see below. Please do keep the discussion running, and comment on what you agree/disagree with or want to see added or removed. It appears that the majority of cases for policy change are 'one off' administrative decisions (like preferring IPv4 over IPv6), though these could be applied in a rolling manner across a site in an incremental change (as pointed out in Dublin). More frequent changes may occur where external routing requirements drive the change, e.g. to favour a certain link. The other isue that has come up that is captured is ensuring hosts can be notified of and receive policy updates in a timely fashion. -- Tim A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations for IPv6 Address Selection Policy Changes Author(s) : T. Chown Filename : draft-chown-addr-select-considerations-00.txt Pages : 10 Date : 2008-10-27 Through operational experience of IPv6 Default Address Selection (RFC3484) [1] implementations, it appears that a requirement has arisen for hosts and networks to be able to have their policies for address selection updated. This text discusses considerations for such policy changes, e.g. examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC3484, where default policies are currently defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-addr-select-considerations-00.txt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt From addr-select-dt-bounces@ietf.org Thu Oct 30 02:42:38 2008 Return-Path: X-Original-To: addr-select-dt-web-archive@ietf.org Delivered-To: ietfarch-addr-select-dt-web-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C033A68CC; Thu, 30 Oct 2008 02:42:38 -0700 (PDT) X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7EED3A68CC for ; Thu, 30 Oct 2008 02:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] 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 VaR2NovdHEFG for ; Thu, 30 Oct 2008 02:42:35 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 189A83A6850 for ; Thu, 30 Oct 2008 02:42:34 -0700 (PDT) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id m9U9fngf099088; Thu, 30 Oct 2008 18:41:56 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: Tim Chown In-Reply-To: <20081028104005.GF6743@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 30 Oct 2008 18:41:45 +0900 References: <20081027211501.8C6DD28C172@core3.amsl.com> <20081028104005.GF6743@login.ecs.soton.ac.uk> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 30 Oct 2008 18:41:57 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] I-D Action:draft-chown-addr-select-considerations-00.txt X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: addr-select-dt-bounces@ietf.org Errors-To: addr-select-dt-bounces@ietf.org Hi. Regarding "How Dynamic?", the biggest concern is whether we work on both external triggers and internal triggers. One of the external trigger is a routing change outside of a site. We can say that this site is multi-homed and have multiple exit routes. When the site is BGP multi-homed and advertises one prefix to both up- streams, then the site doesn't need policy table manipulation. When the site is non-BGP multi-homed and have two prefixes given from both up-streams, each host have multiple addresses and may need policy table manipulation. In IPv4, this case of multi-home is sometimes realized by using NAT-Box at the site exit. However, in such a case in IPv4, do we deploy a dynamic routing mechanism that reflects routing chages outside of the site ? IMO, even the most intelligent NAT-box has a function of static routing and a function of detecting up-stream link failure. This degree of "how dynamic" is all what we MUST provide, isn't it ? ================== | Internet | ================== | | 2001:db8:1000::/36 | | 2001:db8:8000::/36 +----+-+ +-+----+ | ISP1 | | ISP2 | +----+-+ +-+----+ | | 2001:db8:1000:::/48 | | 2001:db8:8000::/48 ++-------++ | Router | <- In IPv4, NAT is sometimes used here. +----+----+ | 2001:db8:1000:1::/64 | 2001:db8:8000:1::/64 ------+---+---------- | +-+----+ 2001:db8:1000:1::100 | Host | 2001:db8:8000:1::100 +------+ Other comments below. * If the aspects in section 2 corresponds to the following sections 4,5,6,7, and their titles, then I guess the structure will be simpler and easier to understand. * 4.1. another example of external factor is emerging of a new address block defined. * 4.2 I think these bullets don't cover all the cases in RFC 5220. e.g. 2.1.3., where a site connects to multiple disjoint network. * 5 I fail to see what this section tries to describe. If the address changes involves network interface's down and up, this falls into start-up. If not, this falls into renumbering. * 6 If you say *gradual* introduction of new policy, the update mechanism does not necessarily be more frequent. If you say *sudden* introduction, then I can get it clearer. Kindest regards, On 2008/10/28, at 19:40, Tim Chown wrote: > Hi, > > The draft has been submitted, see below. Please do keep the > discussion > running, and comment on what you agree/disagree with or want to see > added > or removed. > > It appears that the majority of cases for policy change are 'one off' > administrative decisions (like preferring IPv4 over IPv6), though > these > could be applied in a rolling manner across a site in an incremental > change (as pointed out in Dublin). > > More frequent changes may occur where external routing requirements > drive > the change, e.g. to favour a certain link. > > The other isue that has come up that is captured is ensuring hosts > can be > notified of and receive policy updates in a timely fashion. > > -- > Tim > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Considerations for IPv6 Address Selection Policy > Changes > Author(s) : T. Chown > Filename : draft-chown-addr-select-considerations-00.txt > Pages : 10 > Date : 2008-10-27 > > Through operational experience of IPv6 Default Address Selection > (RFC3484) [1] implementations, it appears that a requirement has > arisen for hosts and networks to be able to have their policies for > address selection updated. This text discusses considerations for > such policy changes, e.g. examples of cases where a change of policy > is required, and the likely frequency of such policy changes. This > text also includes some discussion on the need to also update > RFC3484, where default policies are currently defined. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chown-addr-select-considerations-00.txt > > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt _______________________________________________ addr-select-dt mailing list addr-select-dt@ietf.org https://www.ietf.org/mailman/listinfo/addr-select-dt