Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]

[Ray Hunter <[e-mail]>]

Sorry a couple of important typos on RFC numbers: email escaped too early.
Disregard previous message, and use this one.

Ray Hunter wrote:
> It's definitely going to become an operational FAQ, unless it is very 
> clear whether/how a network operator can force equivalent use of 
> DHCPv4 static address assignment for both source and destination 
> addresses via DHCPv6 (possibly by turning off SLAAC for assignment of 
> GUA on an interface via a flag, or via RFC3484 bis), and how to 
> achieve this effect for all nodes on a link, without resorting to 
> local configuration. So I may as well be the first to ask.

In the absence of other answers, here's my analysis and "how to achieve 
current semi backward-compatible DHCPv4 like behavior in DHCPv6".

Conclusion: it does not see to be very straightforward IMVVHO.
[note: not in any way a flame, just an attempt at documenting a 
real-live use-case v. current implementations of current standards
The use case is based on current implementations of IETF standards in 
Windows 7 and Windows 2008. This is not a criticism of those OS'es. It's 
just a common combination already in production that people like me can 
easily relate to.]


Problem statement: a network manager wants to be able to create firewall 
rules to control access at a granularity level of an individual Windows 
7 PC communicating via IPv6 with an individual Windows Server 2008. The 
motivation is SoX / ISO27001 compliance. The manager does not want the 
firewall rules to have to change every day, and the rules should also be 
independent of the NIC related MAC/EUI-64 address so that they do not 
change upon NIC hardware replacement.


Suggested analysis & solution according to TODAY's documents:

Assumptions of today's default behavior (implementation dependent):
Both Windows 2008 & Windows 7 have IPv6 enabled by default and IPv6 is 
preferred over IPv4 (source: Understanding IPv6 2)
Windows Server 2008 auto registers SLAAC IPv6 GUA in DNS, but not 
temporary addresses. (source: Understanding IPv6 2)
DHCPv6 IPAM system will also register DHCPv6 assigned IPv6 GUA in DNS 
(source: an commercial implementation)
Windows 7 uses temporary addresses for outbound sessions by default. 
(source: Understanding IPv6 2)
Firewall only supports static filtering rules configured by the CLI. 
(source: all common implementations)
DHCPv6 will be available in every implementation (via recent upgrade to 
SHOULD in draft-ietf-6man-node-req-bis-10)


If a DNS server received auto-registration for both SLAAC GUA and DHCPv6 
GUA derived addresses in DNS, the manager does not want the Windows 7 
machine to connect to the SLAAC generated GUA e.g. 
2001:4f0:df8c:2:021c:c0ff:fee2:84e4 instead of the DHCPv6 obtained GUA 
e.g. 2001:47f0:df8c:2::2 because only the DHCPv6 GUA 2001:47f0:df8c:2::2 
will have a firewall rule entry.

Equally it is more than likely that there will be no firewall rule to 
allow RFC 3041 temporary addresses from the Windows 7 PC source address, 
so any session attempts to connect from a source using a temporary 
address will also fail.


After doing my own research, I think the answer today to achieve desired 
semi-backwards compatible DHCPv4 like behavior is:

RFC3484 prefix policy table is required to determine source and 
destination address preference if there are both DHCPv6 GUA & SLAAC GUA 
configured on the same node at the same precedence in the prefix policy 
table.

RFC3484 & RFC3484 bis currently have no mechanism to achieve preference 
of DHCPv6 GUA over a SLAAC GUA on the same prefix, so the manager 
currently needs to stop both nodes obtaining a SLAAC derived GUA in the 
first place, otherwise behavior is unpredictable [no tie break in 
RFC3484 or RFC3484 bis].

Any RFC 3041 temporary addresses that are used by a client or server on 
outbound sessions (Windows default) would also probably get blocked by a 
host to server firewall rule. So the manager needs to turn off the 
feature of using temporary addresses by default on every server and 
every host system [no IETF mechanism to do this, so this is local 
configuration via Active Directory or via a netsh command: netsh 
interface ipv6 set global randomizeidentifiers=disabled].


Now the router:
DHCPv6 relay =ENABLED, and manually configured pointed at a central 
DHCPv6 server

RA = ENABLED because it is needed for the default route on both Windows 
machines
source http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-10
 > Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 
are expected to determine their default router information and on-link 
prefix information from received Router Advertisements.

RA has to include all the DHCPv6 valid prefixes as RA options for on 
link / off link determination
source RFC 4861
 > A router SHOULD include all its on-link prefixes (except the 
link-local prefix) so that multihomed hosts have complete prefix  
information about on-link destinations for the links to which they attach.

RA has to be configured to set the A flag = OFF for ALL prefixes on this 
router interface (autonomous address-configuration flag)
source RFC4862
 > If the Autonomous flag is not set, silently ignore the Prefix 
Information option.

M (managed) flag = ON -> indicate presence of DHCPv6 and desire to use it
source RFC4861
 > When set, it indicates that addresses are available via Dynamic Host 
Configuration Protocol [DHCPv6].

O (Other) flag = X -> irrelevant
source RFC4861
 > If the M flag is set, the O flag is redundant and can be ignored 
because DHCPv6 will return all available configuration information.


You may ask "how is this different from IPv4 today at an operational/ 
implementation level?"

IMVHO [this is not a flame! just an attempt at a neutral analysis from 
an existing enterprise network based implementation]
We have no temporary IPv4 addresses to override by default
We have no SLAAC equivalent in IPv4 to turn off
By default nodes generally use DHCPv4 + broadcast on link connection 
(hard coded default in almost every OS but which can be overridden)
Default router is generally learned via DHCPv4 in an existing tool
We generally only have one IPv4 address that is auto-registered in DNS 
per adapter
We have no address selection issues (there's only 1 source and 1 
destination address)
DHCPv4 server or DHCPv4 relay is built into almost every implementation 
even though it was hardly formally standardized

regards,
RayH