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

Tim Chown <> Mon, 12 July 2010 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 575103A67EA for <>; Mon, 12 Jul 2010 15:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VcOfRHVdh-ap for <>; Mon, 12 Jul 2010 15:33:52 -0700 (PDT)
Received: from ( [IPv6:2001:630:d0:f102::25e]) by (Postfix) with ESMTP id 5E4D83A687F for <>; Mon, 12 Jul 2010 15:33:51 -0700 (PDT)
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id o6CMXvf7031550 for <>; Mon, 12 Jul 2010 23:33:57 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 o6CMXvf7031550
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; 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 ( [2001:630:d0:f102::25d]) by ( [2001:630:d0:f102::25e]) envelope-from <> with ESMTP id m6BNXv0540029710bw ret-id none; Mon, 12 Jul 2010 23:33:57 +0100
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o6CMXTkW027238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; 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 <>
In-Reply-To: <>
Date: Mon, 12 Jul 2010 23:33:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|3ca8075d4eb1863cb8018f0e02542e3cm6BNXv03tjc||>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <> <EMEW3|845deefc014cffb25c028873df838d81m6AIDs03tjc||> <> <>
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
Subject: Re: [addr-select-dt] Update: draft-ietf-6man-addr-select-considerations-01
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: <>, <>
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.