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

[Ray Hunter <[e-mail]>]

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