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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
