Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD

From: Ray Hunter <[email-masked]>
Date: Mon, 30 May 2011 22:05:14 +0200

>
> Message: 2 Date: Mon, 30 May 2011 12:47:19 +0200 From: Markus Hanauska 
> <[email-masked]> To: Mark Smith 
> <[email-masked]> Cc: Thomas Narten 
> <[email-masked]>, "[email-masked]" <[email-masked]>, Ralph Droms 
> <[email-masked]> Subject: Re: Node Requirements: Elevating 
> DHCPv6 from MAY to SHOULD Message-ID: 
> <[email-masked]> Content-Type: 
> text/plain; charset=us-ascii On 2011-05-23, at 23:56 , Mark Smith wrote:
>>> >>  Christopher Morrow<[email-masked]>  writes:
>>> >>  
>>> >>  Just say that at startup time, invoke SLAAC&  DHCPv6 both. Then use
>>> >>  whatever is available. That would have been simple and
>>> >>  predictable. (And avoided 10GB of mailing list discussion!)
>>>        
>
> I'm totally with Christopher here. A flag is actually not necessary at al IMHO. Considering the huge address space and the fact that an IPv6 node usually has multiple addresses per interface anyway, one or two additional addresses make no difference for the node or the network at a whole.
Which source address (SLAAC/DHCPv6) would be used by the client for an 
outbound session if a SLAAC address and a DHCPv6 were both configured on 
the same link and with the same prefix, in the absence of a flag? Think 
dynamic DNS too: which (destination) address(es) would be auto 
registered at the server end?

The main argument I'd make for network managers being able to 
predictably choose for centrally administered static addresses via 
DHCPv6 if they want to, is to be able to preserve existing 
semi-backward-compatible behavior similar to IPv4 + DHCPv4 + DHCP relay 
(which I realize is far from perfect). There are a lot of operational 
people who currently rely on having predictable IP addresses for 
accounting, audit, scripting, firewall rules, neighbor filtering, fault 
tracing, reverse DNS, policy based routing, setting DSCP in QoS, any 
other number of ACL's  .... (completely putting to one side any argument 
whether that is good or bad practice, or whether there are now better 
solutions to achieve these effects)

In summary, I'll be happy if any new proposal can still mimic 
semi-backward-compatible behavior of IPv4 + DHCPv4.

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 May 2011 09:12:01 +1200

Ray,

On 2011-05-31 08:05, Ray Hunter wrote:
...
> the same link and with the same prefix, in the absence of a flag? 

Whichever RFC3484bis or the local policy table determines;
this is orthogonal to the question of where the addresses come from.

> Think

Both, if it's a server and you've chosen to use dynamic address
allocation for servers. Again, this is orthogonal to where
the addresses come from. It's going to be SOP for servers with
multiple addresses.

> solutions to achieve these effects)

Yes, there are lots of bad habits that have grown up over the years
that IPv6 challenges. For example, setting the DSCP *as a function of
the source address* makes me cringe. We're going to have to get used to
the fact that IP addresses are not constants.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 May 2011 14:25:33 -0700

On May 30, 2011, at 2:12 PM, Brian E Carpenter wrote:

> For example, setting the DSCP *as a function of

good grief. The only reasonable use of a DSCP is to identify the set of requirements the application has. It has nothing to do with the address.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 31 May 2011 00:57:38 +0200

This is danger of going off topic I know (maybe it should go in v6ops), 
but it's important to me to be able to understand the consequences of 
the discussion, so please bear with me. 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 the 
first to ask.

> this is orthogonal to the question of where the addresses come from.
Hmm. That's the conclusion I also came to myself already if there were 
no flags.

So how would you prefer DHCPv6 (centrally) assigned addresses as opposed 
to SLAAC EUI64 addresses derived from MAC BIA ?

Is this still an open issue, and I should just be patient?

Would you have to set a prefix for every single DHCP range in RFC3484, 
and make sure the DHCPv6 assigned range did not overlap with likely 
EUI64 derived addresses to be able to guarantee that the DHCPv6 assigned 
address will be preferred?

Or would you have to double the amount of entries in the ACL for both 
the DHCPv6 address and the SLAAC address (coded to MAC address)

Or will RFC3484 bis be updated to include this behavior by automatically 
guessing which addresses are SLAAC addresses and which are DHCPv6 
addresses and allow users to prefer DHCPv6 addresses?

Bearing in mind destination address selection is also affected, so it 
might have to be able to remotely 'guess' what is a SLAAC address versus 
a DHCPv6 assigned address. [I checked the RFC 3484 bis list and there is 
no text today in version 02 
http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 nor 
anything proposed to cover this case in emails]

see http://www.ietf.org/mail-archive/web/ipv6/current/msg13878.html for 
the last note.

 > I'll send a query to the ipv6-ops list just to see if this is a 
common expectation.

The answer to the operational question: Yes IMHO there is a very clear 
operational expectation of being able to easily achieve DHCPv4 like 
behavior using DHCPv6, and this is hot operational topic.

Some people have 50000 rules in their firewalls today. They won't thank 
anyone for 100K rules (to support both SLAAC+DHCPv6), or 50K rules that 
may change every time a NIC card fails (SLAAC only).

> the addresses come from. It's going to be SOP for servers with
<snip>
> the fact that IP addresses are not constants.
In the meantime, we have to continue to operate networks whilst 
transitioning.

As I asked, regardless of whether we think it's good or bad practice, I 
can assure you that it's certainly _common_ practice. Pretty much 
everyone I know who implements MPLS DSCP based QoS networks does it via 
IP based ACL's to overwrite DSCP on network ingress.

offtopic: on the longer term, please give us some alternatives to manage 
and signal identities and QoS policies that are widely implemented by 
all manufacturers and all network providers. No 2 MPLS networks I know 
of use the same DSCP settings. Applications generally only set DSCP= EF 
on voice traffic. Everything else you have no standard signaling 
mechanism. It's rare for two OS'es to behave exactly the same way today. 
Same with 2 applications. In the absence of anything better, people get 
stuck on the lowest common denominator (IP address) and network ingress 
re-writing.

Anyway for some operations it really isn't so bad: think of a few 
traveling VIP users who need a bit better service without spending a 
fortune on 802.1X or additional fancy multi-SSID wireless VLANs. Think 
well managed server farm and private network where there's a bulk back 
up server (all traffic placed in D3 class) next to an interactive 
software licence in server (all traffic placed in D1 class) and the rest 
of the traffic in D2. These guys are sometimes more worried about pure 
performance and cost and ease of management, rather than theft of 
service, re-writing apps etc. etc.

Not necessarily nice. But operational reality.

regards,
RayH

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 May 2011 19:38:40 -0700

On May 30, 2011, at 3:57 PM, Ray Hunter wrote:

> This is danger of going off topic I know (maybe it should go in v6ops), but it's important to me to be able to understand the consequences of the discussion, so please bear with me. 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 the first to ask.

link-local will use SLAAC no matter what. It just does.

I'll let Ralph or one of the other RFC 3315 authors comment on DHCPv6, as they knows a lot more about it than I. 

I would expect, however, that the use of DHCP is something configured on the system in question, just like it is in IPv4. Not that there is an auto-configure option in IPv4 - the other alternative is manual configuration, and most systems come with DHCP configured as the default. IPv6 systems come, at least today, with SLAAC as the default. So there is a requirement to configure DHCPv6, at least from that perspective. That said, SLAAC ain't gonna happen in the absence of RAs, and you can disable RAs on the router. So if an interface comes up and no RA is forthcoming, I could imagine the thing probing with a DHCPv6 request.

> Hmm. That's the conclusion I also came to myself already if there were no flags.
> 
> So how would you prefer DHCPv6 (centrally) assigned addresses as opposed to SLAAC EUI64 addresses derived from MAC BIA ?
> 
> Would you have to set a prefix for every single DHCP range in RFC3484, and make sure the DHCPv6 assigned range did not overlap with likely EUI64 derived addresses to be able to guarantee that the DHCPv6 assigned address will be preferred?
> 
> Or would you have to double the amount of entries in the ACL for both the DHCPv6 address and the SLAAC address (coded to MAC address)
> 
> Or will RFC3484 bis be updated to include this behavior by automatically guessing which addresses are SLAAC addresses and which are DHCPv6 addresses and allow users to prefer DHCPv6 addresses? 
> 
> Bearing in mind destination address selection is also affected, so it might have to be able to remotely 'guess' what is a SLAAC address versus a DHCPv6 assigned address. [I checked the RFC 3484 bis list and there is no text today in version 02 http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 nor anything proposed to cover this case in emails]
> 
> see http://www.ietf.org/mail-archive/web/ipv6/current/msg13878.html for the last note.
> 
> > I'll send a query to the ipv6-ops list just to see if this is a common expectation.
> 
> The answer to the operational question: Yes IMHO there is a very clear operational expectation of being able to easily achieve DHCPv4 like behavior using DHCPv6, and this is hot operational topic.
> 
> Some people have 50000 rules in their firewalls today. They won't thank anyone for 100K rules (to support both SLAAC+DHCPv6), or 50K rules that may change every time a NIC card fails (SLAAC only).
> 
> 
>>> Think
> In the meantime, we have to continue to operate networks whilst transitioning.
> 
> As I asked, regardless of whether we think it's good or bad practice, I can assure you that it's certainly _common_ practice. Pretty much everyone I know who implements MPLS DSCP based QoS networks does it via IP based ACL's to overwrite DSCP on network ingress.
> 
> offtopic: on the longer term, please give us some alternatives to manage and signal identities and QoS policies that are widely implemented by all manufacturers and all network providers. No 2 MPLS networks I know of use the same DSCP settings. Applications generally only set DSCP= EF on voice traffic. Everything else you have no standard signaling mechanism. It's rare for two OS'es to behave exactly the same way today. Same with 2 applications. In the absence of anything better, people get stuck on the lowest common denominator (IP address) and network ingress re-writing.
> 
> Anyway for some operations it really isn't so bad: think of a few traveling VIP users who need a bit better service without spending a fortune on 802.1X or additional fancy multi-SSID wireless VLANs. Think well managed server farm and private network where there's a bulk back up server (all traffic placed in D3 class) next to an interactive software licence in server (all traffic placed in D1 class) and the rest of the traffic in D2. These guys are sometimes more worried about pure performance and cost and ease of management, rather than theft of service, re-writing apps etc. etc.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Markus Hanauska <[email-masked]>
Date: Tue, 31 May 2011 11:29:49 +0200

On 2011-05-30, at 22:05 , Ray Hunter wrote:

> Which source address (SLAAC/DHCPv6) would be used by the client for an outbound session if a SLAAC address and a DHCPv6 were both configured on the same link and with the same prefix, in the absence of a flag?

As I already said in my previous mail: The DHCP address should win by default; that is, of course, unless the admin/user of the node has configured anything else. If a network runs a DHCP server that hands out addresses, network admins probably do so for a reason. The SLAAC one is valid and inbound traffic might arrive for it, but for outgoing traffic, some RFC should simply have given an order of preference:

1. Manual configured IP
2. DHCP
3. SLAAC with Privacy Extension
4. SLAAC with Interface ID

>  Think dynamic DNS too: which (destination) address(es) would be auto registered at the server end?

All of them, since a single DNS entry can resolve to plenty of different IP addresses (DNS has always been designed to allow this scenario). The order should be the same as the order of preference above, though you can argue if it is meaningful to register Privacy Extension addresses at all, since they will dynamically change pretty often.

> There are a lot of operational people who currently rely on having predictable IP addresses for accounting, audit, scripting, firewall rules, neighbor filtering, fault tracing, reverse DNS, policy based routing, setting DSCP in QoS, any other number of ACL's  ....

I can also totally agree with your statement above - but there is one thing you are missing: It is not only important, to have predictable IP addresses in some scenarios, it is also important to have "constant" IP addresses, since even if the address is predictable, it will be a problem if it is going to change every couple of months. SLAAC addresses based on interface IP are in fact predictable; but they not constant! On the other hand, when using DHCP, it takes me 2 minutes to change the stored interface ID of a DHCP client in the server config to assure, that even after an interface ID change, the client still gets the same IP address as before. How will you do this with SLAAC? Manually configuring the same MAC address as the old interface? You shouldn't manually assign MAC addresses, if not really necessary, especially not those which claim to be globally unique, even though they are in fact not. MAC address collisions are worst case scenarios for most networks. Further certain clients, e.g. take an iPhone or iPad, don't allow you to change interface IDs at all AFAIK.

Regards,
Markus

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 31 May 2011 11:57:19 +0200 (CEST)

On Tue, 31 May 2011, Markus Hanauska wrote:

>> outbound session if a SLAAC address and a DHCPv6 were both configured 
>> on the same link and with the same prefix, in the absence of a flag?
>
> As I already said in my previous mail: The DHCP address should win by 
> default; that is, of course, unless the admin/user of the node has 
> configured anything else. If a network runs a DHCP server that hands out 
> addresses, network admins probably do so for a reason. The SLAAC one is 
> valid and inbound traffic might arrive for it, but for outgoing traffic, 
> some RFC should simply have given an order of preference:
>
> 1. Manual configured IP
> 2. DHCP

I don't see the exact argument behind this ordering.

What about the ordering, if you get more than one DHCP addresses?

>From operating system point of view all the addresses are the same. How do 
you select which one to use? The RFC 4941 states, that usage of Privacy 
enhanced addresses can be selected based on the destination addresses.

If you want consistent behaviour, the application should bind() to a 
specific address.

>
>> There are a lot of operational people who currently rely on having 
>> predictable IP addresses for accounting, audit, scripting, firewall 
>> rules, neighbor filtering, fault tracing, reverse DNS, policy based 
>> routing, setting DSCP in QoS, any other number of ACL's ....
>
> I can also totally agree with your statement above - but there is one 
> thing you are missing: It is not only important, to have predictable IP 
> addresses in some scenarios, it is also important to have "constant" IP 
> addresses, since even if the address is predictable, it will be a 
> problem if it is going to change every couple of months. SLAAC addresses 
> based on interface IP are in fact predictable; but they not constant! On 
> the other hand, when using DHCP, it takes me 2 minutes to change the 
> stored interface ID of a DHCP client in the server config to assure, 
> that even after an interface ID change, the client still gets the same 
> IP address as before. How will you do this with SLAAC?

Not with SLAAC, but static addresses. Anyway usually the requirement is 
not the "constant" IP, but accountability of the user/server.

Best Regards,
 		Janos Mohacsi

---

From: Markus Hanauska <[email-masked]>
Date: Tue, 31 May 2011 13:39:14 +0200

> What about the ordering, if you get more than one DHCP addresses?

How would this be any different to the situation as we have it today? It's rather strange arguing to say something introduces a problem, if this is not a new problem, but one that is in existence already by the current standards. In whatever way this situation is handled today, it would be handled the same way, I'd say.

> From operating system point of view all the addresses are the same.

This is not quite true. If I have a SLAAC address with interface ID and one with Priv Ext, all systems I know prefer the one with Priv Ext for outgoing traffic, unless a client/server software explicitly picks another one. The same thing could be the case for DHCP addresses.

>  The RFC 4941 states, that usage of Privacy enhanced addresses can be selected based on the destination addresses.

Yes, but there is nothing special about this. Every address can be picked according to the destination address simply by adding a routing table entry for a certain destination or destination range; this also works with IPv4.

> Not with SLAAC, but static addresses.

My impression was the consent on this list is that static addresses are evil(TM), since it is the most error prone way of assigning addresses on a network. And I cannot really disagree, there is some truth in that statement. Also it is more painful to remotely log into hosts and manually assign them IPs, instead of managing all this in a central place: The DHCP server config.

Regards,
Markus

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 31 May 2011 13:52:44 +0200 (CEST)

Hi,

You quoting is misleading - you getting out of context my answers.

On Tue, 31 May 2011, Markus Hanauska wrote:

> How would this be any different to the situation as we have it today? 
> It's rather strange arguing to say something introduces a problem, if 
> this is not a new problem, but one that is in existence already by the 
> current standards. In whatever way this situation is handled today, it 
> would be handled the same way, I'd say.

Yes. Your address list has 4 element, mine list can have 5 or even more. 
You ordering is incomplete. I agree, It has to be handled in the same way:
bind() to proper address.

> This is not quite true. If I have a SLAAC address with interface ID and 
> one with Priv Ext, all systems I know prefer the one with Priv Ext for 
> outgoing traffic, unless a client/server software explicitly picks 
> another one. The same thing could be the case for DHCP addresses.

This is not quite true either. You can select in some OS, to prefer 
privacy address or not. For DHCP, I don't see difference between static 
and DHCP assigned.

>
>>  The RFC 4941 states, that usage of Privacy enhanced addresses can be 
>> selected based on the destination addresses.
>
> Yes, but there is nothing special about this. Every address can be 
> picked according to the destination address simply by adding a routing 
> table entry for a certain destination or destination range; this also 
> works with IPv4.

Will it work this way on all the operating systems?

> My impression was the consent on this list is that static addresses are 
> evil(TM), since it is the most error prone way of assigning addresses on 
> a network. And I cannot really disagree, there is some truth in that 
> statement. Also it is more painful to remotely log into hosts and 
> manually assign them IPs, instead of managing all this in a central 
> place: The DHCP server config.

I am referring here the assigning static addresses to stable servers (to 
avoid problems of MAC address changes). For address assignment 
point of view static and DHCP is the almost the same. DHCP slightly worse, 
since you are relying operation of your DHCP server. Or slightly better, 
you have the assigned addresses in one database.

Regards,
 	Janos Mohacsi

---

From: Tim Chown <[email-masked]>
Date: Tue, 31 May 2011 13:43:58 +0100

> I would expect, however, that the use of DHCP is something configured on the system in question, just like it is in IPv4. Not that there is an auto-configure option in IPv4 - the other alternative…

But then it can't get a default router configuration by DHCPv6?

It's interesting that my 18(?) month old HP Laserjet n model has IPv6 support, and even being that old can be configured to 

a) just autoconfigure
b) use DHCPv6 when the M bit is set in the RA
c) use DHCPv6 when stateless autoconfig fails
d) always use DHCPv6
or
e) use a manually-configured IPv6 address. 

If you're interested in how that appears via the HP web config screen, see a screenshot at http://users.ecs.soton.ac.uk/tjc/ietf/hplaserjet-example.png

I think, but am not sure, that the screenshot shows the default configuration.  While there is no privacy addressing in this example, that could be an additional option, though it makes little sense for such a device.

To me, if you want to run DHCPv6, you set the RA M bit, and it's then down to hosts to choose to honour that.  But if you don't have management control of any device, unless you put additional measures in place, the host can always be configured with a different/additional address to that offered by DHCPv6. 

Tim

---

From: Mark Smith <[email-masked]>
Date: Tue, 31 May 2011 22:58:24 +0930

On Tue, 31 May 2011 11:29:49 +0200

> 4. SLAAC with Interface ID

Some people might prefer SLAAC over DHCP. For example, if I were
attached to a public hot spot with my laptop, then I'd want to use 
SLAAC with Privacy Extensions in preference to DHCP, even if there is a
DHCP server available.

> I can also totally agree with your statement above - but there is one thing you are missing: It is not only important, to have predictable IP addresses in some scenarios, it is also important to have "constant" IP addresses, since even if the address is predictable, it will be a problem if it is going to change every couple of months. SLAAC addresses based on interface IP are in fact predictable; but they not constant! On the other hand, when using DHCP, it takes me 2 minutes to change the stored interface ID of a DHCP client in the server config to assure, that even after an interface ID change, the client still gets the same IP address as before. How will you do this with SLAAC? Manually configuring the same MAC address as the old interface? You shouldn't manually assign MAC addresses, if not really necessary, especially not those which claim to be globally unique, even though they are in fact not. MAC address collisions are worst case scenarios for most networks. Further
  c
>  ertain clients, e.g. take an iPhone or iPad, don't allow you to change interface IDs at all AFAIK.
> 
> Regards,
> Markus

---

From: Markus Hanauska <[email-masked]>
Date: Tue, 31 May 2011 15:50:16 +0200

On 2011-05-31, at 15:28 , Mark Smith wrote:

> Some people might prefer SLAAC over DHCP.

That's why things like these are usually configurable. Just because there exists a well defined default order doesn't mean you are not allowed to manually override it, does it?

> For example, if I were

I doubt this would buy you anything. See, if the network admin was okay with people using SLAAC, he wouldn't hand out IP addresses through DHCPv6. Either he would not operate a DHCPv6 server at all or he would only operate a stateless DHCPv6 server to hand out DNS, NTP and other useful server addresses. Do you know of any device that supports DHCPv6 but not SLAAC? I don't. Would such a device be even standard conform? So if the admin operates a DHCPv6 server at that hotspot handing out IP address, he probably wants you to use those addresses and all other addresses may, for example, not be routable, that means if you override the order above, your outgoing traffic works within the hotspot only, but you cannot reach the rest of the Internet any longer and since hotspots usually put the user into virtual LANs and don't allow direct traffic between two hotspot users, there is nothing you could do while being connected to the hotspot.

Regards,
Markus

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 May 2011 09:24:19 -0700

On May 30, 2011, at 7:38 PM, Fred Baker wrote:
> 
> [...] IPv6 systems come, at least today, with SLAAC as the default. So there is a requirement to configure DHCPv6, at least from that perspective. That said, SLAAC ain't gonna happen in the absence of RAs, and you can disable RAs on the router. So if an interface comes up and no RA is forthcoming, I could imagine the thing probing with a DHCPv6 request. [...]

For what it's worth, the behavior of Apple's iOS 4.3 and later is straightforward.  If there is no RA, then there is no IPv6.  iOS 4.3 doesn't support manual IPv6 configuration, so automatic configuration is the only way to plumb it.  The DHCPv6 client only starts if the router indicates availability with O=1.  Remember when I was complaining that we needed RFC 6106 for the O=0 case?  Given that we have that, I don't see any benefit to starting the DHCPv6 client unless a router explicitly tells us to expect service.  No router?  No need for dynamic host configuration.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Ray Hunter <[email-masked]>
Date: Tue, 31 May 2011 22:45:33 +0200

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 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 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 
line / 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 RFC4682
 > 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 RFC4681
 > When set, it indicates that addresses are available via Dynamic Host 
Configuration Protocol [DHCPv6].

O (Other) flag = X -> irrelevant
source RFC4681
 > 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

---

From: Ray Hunter <[email-masked]>
Date: Tue, 31 May 2011 22:52:09 +0200

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

Ray Hunter wrote:
> local configuration. So I may as well be the first to ask.

SHOULD in draft-ietf-6man-node-req-bis-10)

Now the router:

RA has to include all the DHCPv6 valid prefixes as RA options for on 
link / off link determination
source RFC 4861

source RFC4862
Information option.

source RFC4861

source RFC4861

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Jun 2011 09:05:25 +1200

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 31 May 2011 17:32:37 -0400

> I'll let Ralph or one of the other RFC 3315 authors comment on DHCPv6, as they knows a lot more about it than I. 

Use of SLAAC is controlled by the A bit in the Prefix Information option.  If the A bit is zero, the host will not configure an address on the receiving interface using SLAAC.  

The M bit in an RA gives a hint that DHCPv6 service is available.  The host behavior is not entirely controlled by the M bit; a host can choose to run DHCPv6 independent of the setting of the M bit.  A reasonable host might not bother with DHCPv6 if the M bit is 0; at the same time, a reasonable host might go ahead with DHCPv6 if it doesn't receive any Prefix Information options with the A bit set to one.

- Ralph

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Jun 2011 08:11:27 +0930

On Tue, 31 May 2011 09:24:19 -0700

> For what it's worth, the behavior of Apple's iOS 4.3 and later is straightforward.  If there is no RA, then there is no IPv6.  iOS 4.3 doesn't support manual IPv6 configuration, so automatic config…

Actually, that raises an interesting question. If SLAAC and DHCPv6 were
enabled by default, ignoring the M and O bits, what type of DHCPv6 is
enabled - stateless or stateful? 

I'm sure people are expecting stateful, so the DHCPv6 client would
initially issue a Solicit and including IA_NA and IA_TA options. My
understanding is that if a DHCPv6 server won't ever provide any
addresses (as it is a "stateless" server), it is to ignore those Solicit
messages. Since the end-node may have also acquired addresses via
SLAAC, it eventually wouldn't care. However, it would have to timeout
the Solicits as per RFC3315, just in case there was a stateful DHCPv6
server available. I understand this retransimission/timeout period
is 120 seconds (SOL_MAX_RT). At that point, it should then resort to
stateless operation, using an Information-Request message, to acquire
Other DHCPv6 supplied options. So 2 minutes would need to elapse before
the client would receive options it is interested in via stateless
DHCPv6. That's an awfully long time to wait to find out other DHCPv6
option values that can't be supplied in an RA as per RFC6106.

Perhaps a stateful and stateless DHCPv6 transaction could be performed
in parallel to avoid this 2 minute delay. I think that would create
another possible conflict. What if the non-address option values that
are received via the stateless DHCPv6 transaction are different to the
non-address option values supplied by a stateful DHCPv6 server? The
current selection of either stateful or stateless DHCPv6 operation for
a segment via M&O bits, and then a DHCPv6's client's selection of a
single DHCPv6 server to continue or have a transaction with avoids
this option value mismatch ambiguity.

Regards,
Mark.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 31 May 2011 20:39:06 -0400

On May 31, 2011, at 6:41 PM, Mark Smith <[email-masked]> wrote:

> Mark

Working from memory, there's an error code through which a DHCPv6 server can explicitly NAK an address assigment request.

- Ralph