Re: [addr-select-dt] 2nd teleconference

Tim Chown <tjc@ecs.soton.ac.uk> Mon, 12 July 2010 22:17 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 B00AA3A67EE for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 15:17:11 -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 GxGguwn2oztr for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 15:17:10 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 6E6363A6C1D for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 15:17:07 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6CMHDCf028779 for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 23:17:13 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6CMHDCf028779
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278973033; bh=zIP62QJ+a3L74+zfZ6Ize0Kgbso=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=FvAve+dwEKFAyIv6axTPAKjrVm6saqMCO0ZRZmUK25ztXK2QVf/P6OHWMtbluRGf8 mWvQVDOMAyh8QymdfTzk74YJlma0TyLJiH4DH03M7UZSowgq8DUNj3+KTDVnZ+rhPE Eummngo+x1jU7KHFBCwUOK5qOeVStqVErI5LrsbU=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id m6BNHD0540029664Ku ret-id none; Mon, 12 Jul 2010 23:17:13 +0100
Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6CMH5m5024897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 23:17:06 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <53D0CB5A-D04E-4B5F-B97A-B217005FA8B2@nttv6.net>
Date: Mon, 12 Jul 2010 23:17:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|18254a53bfa79da196f96241dc475bb0m6BNHD03tjc|ecs.soton.ac.uk|1B3BD790-3CA2-4486-9A28-87FB8EE0916B@ecs.soton.ac.uk>
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <EMEW3|1a621eda15846417a0a7af75ba7ecc9bm64EB003tjc|ecs.soton.ac.uk|553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net> <0ac701cb1d22$11c1acb0$35450610$@net> <53C7DB02-5151-4F89-ADED-5105BA39A61F@nttv6.net> <B25C4B64-A692-4031-A9E5-0609284BF067@nttv6.net> <B74B73DD-2C4B-425C-87F2-D39EFDD836AA@ecs.soton.ac.uk> <EMEW3|5ff29d0c41dfa2e4c8a73b4f8ffe6d54m6AGWA03tjc|ecs.soton.ac.uk|B74B73DD-2C4B-425C-87F2-D39EFDD836AA@ecs.soton.ac.uk> <53D0CB5A-D04E-4B5F-B97A-B217005FA8B2@nttv6.net> <1B3BD790-3CA2-4486-9A28-87FB8EE0916B@ecs.soton.ac.uk>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6BNHD054002966400; tid=m6BNHD0540029664Ku; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6CMHDCf028779
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [addr-select-dt] 2nd teleconference
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 22:17:11 -0000

On 12 Jul 2010, at 11:55, Arifumi Matsumoto wrote:
> 
> And after the cut-off, I want to continue making progress and present better output to the 6man people in Maastricht.

Agreed.

>>> This mechanism SHOULD be used only when the administrator of a site can make
>>> sure that the address selection information receiver will not receive the same kind
>>> of information from any other *local* entity, or the receiver can accept and process the received
>>> multiple policy sets correctly, e.g. by using pre-configured information.
> 
> I came to think that this applicability seems reasonable.
> 
> - First of all, the mechanism does not provide a standard way of merging, so the network SHOULD NOT distribute policy sets from multiple entities. This restriction seems to be acceptable for the network administrator.

In saying different entities, we're in effect saying different mechanisms.   If the solution for enterprises is DHCPv6-based policy distribution, this should be the case.

> - As in enterprise network, the network administrator can restrict users's network environment so that they do not do multi-home. But, as in access network and wifi spots, he cannot restrict what they do. Does this inhibit him from using this mechanism ? I do not think so. This matter is just the same as other DHCP options like DNS server address option. It is also the host-wide information, but it has not became an obvious problem, mainly due to implementation measures, such as interface prioritization as studied in mif wg.

Well, can an enterprise avoid a user running a VPN to their home network while visiting?   I don't think our visitors would be happy if we did that :)

> We should not say "we do not do this, because this problem is difficult."
> We should day "we do not do this, because there is no perfect or practical solution for doing this."
> 
> I think we can say the latter, because the destination address selection
> based on precedence value does essentially conflict with other precedence value coming from other policy source.

I agree - a much better way to phrase it.

> We understand there are some cases where they need policy merge. So, we should do further work on producing most practical way of policy merging. But, I suppose the output should be experimental or informational RFC, in that we really have to see the output is acceptable and operational in reality.
> 
> One more point about this separation.
> If we do this separation, what do we have to have now ?
> 
> I think it is basically ultimately a receiver's choice whether it does policy merge or not.
> Here, I'm wondering if there should be a way to guide a receiver whether it should merge or not. In this case, there should be a bit to show this preference of policy sender.
> But, we may do not have to discuss this, we just need a bit of reserved field in the option.

Tony I think suggested some per-provider unique reference to identify/verify the source of the policy.   This might make it easier to provide the user with a choice they could understand.

>> It was felt that the dt could work with the authors of the multihome-without-nat66 draft to bolster contributions to the problem space.   While the Troan draft considers many of the issues the DT is concerned with it does not include policy conflict/merger. 
>> http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-00
> 
> As confirmed in their ML, they are happy with non-merge-capable solution.

I suspect they have had similar discussions :)

>> The question arose again if whether RFC3484 should be per node (as now) or per interface.
> 
> As far as it is used for destination address selection, it has to be per host.

Yes, though I understood the points Tony was raising.

>> Arifumi agreed to refresh the 3484-bis draft before the cutoff, and Tony offered to send some comments over the weekend.    Ideally we would like to get 3484-bis to a publication-ready state as soon as possible.   Many vendors/implementors have already implemented many of the changes in the current 3484-bis draft.
> 
> I'll update it from now :)
> 
> If everyone agrees, I want that draft to be this DT's output.

I have just seen it published, thank you.

Tim