Ray, Without going into details: how about turning this into draft-hunter-v6ops-something and having the debate over in v6ops?
I think that would be useful, personally. Regards Brian On 2011-06-01 08:52, Ray Hunter wrote: > 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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
