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

From: Ray Hunter <[email-masked]>
Date: Tue, 21 Feb 2012 18:56:17 +0100

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:[email-masked]
> To:[email-masked]
> Cc:[email-masked]
> Subject: I-D Action: draft-ietf-6man-addr-select-opt-02.txt
> Message-ID:<[email-masked]>
> 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
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 24 Feb 2012 17:17:55 +0900

Ray,

thank you for your comments.

On 2012/02/22, at 2:56, Ray Hunter wrote:

> 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.

If we think about the routing table, the entries related to a certain network interface will also be added and deleted, when the interface goes up and down.

So, it seems to me that this issue is not too new, or strange for implementors.

> 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.

Do you suggest splitting them into different documents, or just defining the transport information format and leaving others to implementation dependent ?
I do not see much value in just dividing this into two documents. It just makes it troublesome to understand this mechanism.

Regarding the latter case,
IMO, this mechanism is so new, and no operational experiences are gained by administrators, implementors, and so on. So, we first have to propose the expected /recommended way to use this mechanism. If you find the current specification goes beyond recommendation in some points, please tell it to me.

> 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.

agree.

> 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.

agree.

> 
> 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).

I think it is a matter of implementation, and common for several other DHCPv6 options.

It may be helpful for implementors, but this document should not be the right place for this generic issue.

Thanks !

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: [email-masked]
  TEL +81-422-59-3334 FAX +81-422-59-6364

---

From: Ray Hunter <[email-masked]>
Date: Fri, 24 Feb 2012 11:26:53 +0100

Answers in line

> So, it seems to me that this issue is not too new, or strange for implementors.
My concern is that the guidance in this draft is not correctly 
formulated IMHO.

I agree that incorrect use of the addr-select-opt may lead to a security 
issue, in that node-global behavior is affected by the proposed option. 
Thus traffic intended for interface 1/ network 1 may be misdirected to 
interface 2 / network 2 by receiving an address-selection policy option 
from network 2.

However, this security risk is not directly correlated to the number of 
active interfaces at the time the policy is received IMHO.

In some situations I can think of, you may well want to trust a 
particular DHCPv6 server to configure a link address on an interface, 
plus maybe some hints about which name servers or time servers to use to 
set up an initial connection, but not to set a policy for which address 
ranges and hence interfaces to select for which traffic. Even receiving 
policy information over one active interface may not be considered a 
reasonable risk by some e.g. if a second interface is brought up later 
(e.g. a tunnel), and (some of) the old policy information from the first 
interface is not flushed because that first interface is still up and 
the second interface does not provide a policy update.

In a corporate environment, it may well be desirable to receive policy 
updates on multiple interfaces without having to explicitly configure 
this, because all updates ultimately have been derived from a trusted AS 
source.

Therefore I think the risk is more closely related to the consistency 
and provenance of the DHCPv6 derived address selection policy 
information i.e. whether the device is receiving the option from more 
than one Autonomous System simultaneously, or from an AS source that is 
not trusted.

I'd be happy if the draft contained a warning of the risk, without 
getting into details of how to mitigate the risk in implementation.
> IMO, this mechanism is so new, and no operational experiences are gained by administrators, implementors, and so on. So, we first have to propose the expected /recommended way to use this mechanism…
I humbly suggest considering which WG is appropriate for defining which 
portion of the overall mechanism. There seems to be a very large overlap 
with MIF, and one possible way to handle this would be to have the pure 
transport of the option defined in your 6man draft (which I guess could 
be pretty non-contentious), and defining the use of the information in 
the MIF workflow. Another option might be simply to co-post the draft to 
the MIF WG.

<snip>

> It may be helpful for implementors, but this document should not be the right place for this generic issue.
Agree. This is off topic for your draft, but maybe someone will take up 
the generic challenge in another draft.

<snip>

regards,
RayH