[6MAN] I-D Action: draft-ietf-6man-addr-select-opt-02.txt

[Ray Hunter <[e-mail]>]

I have read draft-ietf-6man-addr-select-opt-03. I support this work. Thanks.

Some comments.

1) I find Section 4.3 unsatisfactory. In highly-mobile devices, the 
status "single-homed" and "only one upstream line" is time dependent. A 
highly-mobile device may have a semi-permanent 4G uplink, and a 
temporary wifi uplink dependent on the user's current location. Whether 
a new Address Selection Policy table is installed or not should not 
depend primarily on the order that the interfaces are brought up.

2) Suggest splitting transport of policy/configuration information from 
actual use of the policy/configuration information by the end node. I'm 
thinking of how routers may have multiple sources of routing information 
(derived from various sources: static, RIPng, OSPFv3) but they may only 
install subsets of the total known information into the single active 
forwarding table using local policy configuration concepts such as 
Administrative Distance and locally defined route filters.

3) MIF RFC 6419 identifies that address selection and interface 
selection mechanisms are not consistently applied across various 
implementations.

Humbly suggest adding an Informative Reference, whilst leaving solving 
such selection and consistency problems to the MIF WG.

4) MIF RFC 6418 defines the concepts of "Provisioning Domain" & 
"Administrative Domain"

Humbly suggest adding an Informative Reference and adopting this 
terminology in your draft.

5) DHCPv6 RFC 3315 Section 16 states "a client .. SHOULD send the 
message through the interface for which configuration information is 
being requested."

Since a highly-mobile node may communicate with multiple (inconsistent) 
sources of DHCPv6 information via different interfaces, depending on the 
selected DHCPv6 server(s)/ relays, and which interfaces are active at 
any particular time, is it worth discussing a mechanism to track the 
provenance of the received "node-global information"?

I think it may be useful to be able to tag DHCPv6 derived 
policy/configuration information (such as the Address Selection Policy 
table) with a provenance, so that an end node may associate the 
configuration/ policy information learned from an interface/DHCPv6 
server combination with a "Provisioning Domain" and/or "Administrative 
Domain."

Otherwise how do you know which Address Selection Policy table is 
appropriate to install/ de-install as the active table as each interface 
goes up/down?

And if the MIF WG defines a way of selecting a Provisioning Domain, the 
Address Selection Policy info learned via DHCPv6 will already be 
appropriately tagged (before being processed/installed into any active 
node-global table).

regards,
RayH

> Message: 5
> Date: Wed, 15 Feb 2012 03:40:10 -0800
> From:[e-mail]
> To:[e-mail]
> Cc:[e-mail]
> Subject: I-D Action: draft-ietf-6man-addr-select-opt-02.txt
> Message-ID:<[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>
> 	Title           : Distributing Address Selection Policy using DHCPv6
> 	Author(s)       : Arifumi Matsumoto
>                            Tomohiro Fujisaki
>                            Jun-ya Kato
>                            Tim Chown
> 	Filename        : draft-ietf-6man-addr-select-opt-02.txt
> 	Pages           : 10
> 	Date            : 2012-02-15
>
>     RFC 3484 defines default address selection mechanisms for IPv6 that
>     allow nodes to select appropriate address when faced with multiple
>     source and/or destination addresses to choose between.  The RFC 3484
>     allowed for the future definition of methods to administratively
>     configure the address selection policy information.  This document
>     defines a new DHCPv6 option for such configuration, allowing a site
>     administrator to distribute address selection policy overriding the
>     default address selection policy table, and thus control the address
>     selection behavior of nodes in their site.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-02.txt
>