On May 30, 2011, at 10:38 PM 5/30/11, Fred Baker wrote: > > 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.
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 > > 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. > >> Brian E Carpenter wrote: >>> Ray, >>> >>> On 2011-05-31 08: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? >>>> >>>> >>> >>> Whichever RFC3484bis or the local policy table determines; >>> 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). >> >> >>>> Think >>>> dynamic DNS too: which (destination) address(es) would be auto >>>> registered at the server end? >>>> >>>> >>> >>> 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. >>> >>> >>> >> <snip> >>> >>> 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 >>> >>> >>> >> 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 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
