Subject: I-D Action: draft-ietf-6man-addr-select-opt-04.txt

From: [email-masked]
Date: Mon, 16 Jul 2012 11:38:20 -0700

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-04.txt
	Pages           : 11
	Date            : 2012-07-16

Abstract:
   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 parameters and policy table, and thus
   control the address selection behavior of nodes in their site.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-04

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ray Hunter <[email-masked]>
Date: Wed, 18 Jul 2012 19:29:10 +0200

I have read this draft. As previously stated, I like the idea.

comments & questions:

Section 2:
/ a client MAY NOT automatically add rows to the policy table/

MAY NOT seems to contradict Section 4
/This option's concept is to serve as a hint for a node about how to 
behave in the network./

i.e. it's a hint not a command. Is this not then a "SHOULD NOT"? 
Otherwise won't we get questions about who is leading for determining 
end-node global behaviour, the device owner or the network operator? Or 
is this MAY NOT flag only valid IF the node chooses to trust and install 
the policy table communicated via DHCPv6?

/label:  An 8-bit unsigned integer;/

Is there any specification in an RFC that says ALL implementations can 
only handle a label of 8 bits?

/precedence:  An 8-bit unsigned integer;/

Is there any specification in an RFC that says that ALL implementations 
can only handle a precedence of 8 bits?

draft-ietf-6man-rfc3484bis-06 refers to numeric comparisons, but does 
not appear to specify a type.

I see later in Section 5:

/Currently, the label and precedence values are defined as 8-bit 
unsigned integers.  In almost all cases, this value will be enough./

How many times have I heard that about fixed length fields.
What happens if it is not enough?
Is it worth considering variable length labels and precedence fields? Or 
making them 16 bits to start with?

/An IPv4-mapped address [RFC4291] must  be used to represent an IPv4 
address as a prefix value./

Whilst I agree with this statement, some examples in the Microsoft 
documentation I have read show dual entries in the policy table: one for 
mapped IPv4 address prefixes and one for IPv4-Compatible IPv6 address 
prefixes.

e.g. the default policy table is shown with entries like:
::/96 20 3
::ffff:0:0/96 10 4

Since IPv4-Compatible IPv6 addresses are deprecated, can we assume that 
these can be safely ignored, or not?

I have always played it safe and configured both in Windows 7, so I'm 
not sure of underlying behaviour of the implementation and if this might 
change over time or versions.

/The zone-index is defined in RFC 3493 [RFC3493] as 'scope ID'/

I can't find a direct reference to 'scope ID' in RFC3493.
Is it 'sin6_scope_id'? That would make sense as it is defined as 32 bit 
integer.

Section 4.3:
/In other cases the node MUST NOT use Policy Table options unless the 
node is specifically configured to do so./

When I first read this I asked myself "is that not too draconian?" I 
think a document link to the definition of a "secure channel" in the 
Security Considerations section would answer that question effectively 
i.e. a signed DHCP message is considered a secure channel, regardless of 
the underlying transport.

What about version control of the policy table itself? Is there a need 
for a policy-table version option like a DNS SOA serial number? I could 
imagine some potential corner-case problems with replay attack or race 
conditions, especially if the local router is acting as some sort of 
smart caching DHCPv6 server introducing local options. Or is that just 
too obscure to worry about?

Thanks!
RayH