Re: [addr-select-dt] Update: draft-ietf-6man-addr-select-considerations-01

Tim Chown <tjc@ecs.soton.ac.uk> Mon, 12 July 2010 22:33 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 575103A67EA for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 15:33:55 -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 VcOfRHVdh-ap for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 15:33:52 -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 5E4D83A687F for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 15:33:51 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6CMXvf7031550 for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 23:33:57 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6CMXvf7031550
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278974037; bh=mBvq3dKpTXFQvnAj02OlcNP5oHk=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=S0mFv9deyY3ULlNyN/HTqZzeKrp6R2KANvzQthP3rsmYW7r7w+84LHwDKSrao8HtZ uAkRdEvHUZj4bCU5QNcA9x0hVHhZz30t+jB7tFBxxb57LN4yYqi0PeqoDeDKEuyNeU WTnKL6j+7BCfgBLcZaghkQ3UnM+9zZvCR8Xy8woU=
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 m6BNXv0540029710bw ret-id none; Mon, 12 Jul 2010 23:33:57 +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 o6CMXTkW027238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 23:33:30 +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: <0E00E48C-1B68-4811-9FEA-C790C7E61DBD@nttv6.net>
Date: Mon, 12 Jul 2010 23:33:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|3ca8075d4eb1863cb8018f0e02542e3cm6BNXv03tjc|ecs.soton.ac.uk|4C9704A4-14A7-4ED1-98C3-FDF75769B412@ecs.soton.ac.uk>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <30111D11-0DAE-4A21-8AA9-2B75BABB82B8@ecs.soton.ac.uk> <EMEW3|845deefc014cffb25c028873df838d81m6AIDs03tjc|ecs.soton.ac.uk|30111D11-0DAE-4A21-8AA9-2B75BABB82B8@ecs.soton.ac.uk> <0E00E48C-1B68-4811-9FEA-C790C7E61DBD@nttv6.net> <4C9704A4-14A7-4ED1-98C3-FDF75769B412@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=m6BNXv054002971000; tid=m6BNXv0540029710bw; 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: o6CMXvf7031550
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [addr-select-dt] Update: draft-ietf-6man-addr-select-considerations-01
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:33:55 -0000

On 12 Jul 2010, at 20:47, Arifumi Matsumoto wrote:

> Tim,
> 
> thank you for your generous efforts on this draft.
> Now this document is quite thorough. I really appreciate it.
> 
> When we finish this document, why not bring this and go out to 6man ML for discussion ?

Yes,we should do that.

> 4.5. Multiple Interface Nodes
>     ...
>   not.  In this case it is interesting to note the choice to use the
>   VPN tunnel for all, or just VPN home site traffic, is typically left
>   as a choice for the user via a tickbox selection.
> 
> From my experience, even the tick-box does not appear. If I install and launch VPN software, it changes several related settings as it wants. I think this is quite reasonable behavior of VPN software. The software interprets that it is given highest priority from the user by installing and launching the software.

Comment added.

> 6.3.  Manual Configuration?
> 
> I think this whole point is rather related to the solution section. 
> And especially in merging subsection. It is about policy merging or
> non-merging of default policy table or manually configured policy
> with the received policy.
> 
> 6.4.  Policy Conflicts
> 
> Again, this whole point also should be placed in solution space ?
> At least, it is not about when to obtain poicy.

Agree.   Both moved.

> 7.2.  Pull model
> ...
>   an administrator, is a more practical use of DHCPv6.  If future
>   methods offer additional 'hints' based on routing information, this
>   becomes part of the 'policy conflict' problem to be solved.
> 
> I do not know why hints based methods solve the policy conflict.
> As far as the destination address selection based on precedence is used,
> policy conflict can not be helped. In policy table based one, an entry
> in the table can conflict with others, and in hinsts based one, a hint
> can conflict with other hints. In my understanding, that's the only
> difference.

Sentence removed as it is ambiguous and unnecessary in the text there.

> 7.3.  Push model
> ...
>   However, we may
>   find that RAs may be a good place to indicate whether a default
>   policy is in place or not, to avoid hosts requesting non-existent
>   updates via DHCPv6.
> 
> I think I fail to see the reason why the O flag of RA is not enough.

OK.   Text removed.

> 7.4.  Routing Hints
> ...
>   The same thought seems relevant to address selection.  There's no
>   point selecting a source address whose prefix is not being advertised
>   in RAs.
> 
>   While routing and prefix hints may help a host make selection
>   decisions, we should consider to what extent we wish to 'burden' a
>   host with holding such information.  If a host is to determine and
>   cache routing hints, this may require an update of RFC 3484 policy
>   table syntax to support preference for address pairs.
> 
> In this section, what you suggest is to keep looking at RAs in order
> to know upstream network changes ? I think it is more helpful is
> it is described that way.
> 
> About the last sentence, I fail to guess what the routing hints are
> like, and therefore why we many need to update policy table.

Imagine an ICMPv6 query that could get an ordered list of address pairs as a response.    We do plan to write a draft based on the implementation we have done of that, just time has been an issue.

Tim