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