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. > 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 --------------------------------------------------------------------
