Message: 2 Date: Thu, 26 May 2011 16:21:59 -0400 From: Thomas Narten<nar...@us.ibm.com> To:ipv6@ietf.org Subject: Re: review of draft-ietf-node-req-bis Message-ID:<201105262021.p4qklx2b020...@cichlid.raleigh.ibm.com>Going back to this... Jari Arkko<jari.ar...@piuha.net> writes: <snip> New text: 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 Because a single DHCP server can support devices on multiple links, it is not necessary that every router support DHCPv6 directly. However, in order to support DHCPv6 servers on other links, routers SHOULD support relay agent functionality of DHCPv6 [RFC3315]. Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6 server functionality as well. I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't think every router needs to support DHCP, hence the MAY. But SHOULD is also not a MUST, so I'd be OK with SHOULD. Indeed, where one arguably should have a MUST is in relay agent functionality. SHould I elevate it? Thoughts? Thomas
All from my own very very humble opinion based on experiences mainly in enterprise networks.
Many people have centralized DHCPv4 at least at the site level, if not the enterprise level, for very good and varied operational reasons (not just because they had to have them for allocating and registering names and addresses) and much of that functionality cannot currently be replaced by SLAAC alone (or any other widely deployed alternatives AFAIK).
I was reminded just the other day of the (humble) origins in bootp when someone walked into the office and wanted to set the Code 67 boot_file_name and Code 66 boot_server in the DHCP scope for use by a server located on another remote site, which contacted the central DHCP server via DHCP relay.
DHCPv6 server on a router is definitely not a must. Probably not even a should. MAY is absolutely fine for me.
DHCPv6 relay on a router is definitely at least a SHOULD. Otherwise those centralized IPAM systems that exist today will not be able to function with IPv6: you will break existing functionality that enterprise network managers currently use to great extent.
On the other hand, a MUST for DHCP relay on routers seems to go way too far for me. DHCPv6 support is after all only a SHOULD for end nodes. And it may not even be turned on by default.
So what parameters are network operators expecting to set on an end node that is so important?
I'd like it to be otherwise, but the truth seems to be that the current consensus is that there is no consensus on a single mechanism of how to signal options and settings between a network manager/ service provider and an end node.
Personally, I won't buy a router without a DHCPv6 relay function. But then again in an SP environment with PD, where do you point DHCPv6 relay to by default to fetch content if it is a MUST? Does it serve local config parameters (set by the local admin to control e.g. printservers) or does it serve config parameters sent to the household end node systems by the Service Provider (which might be ignored by end nodes not running DHCPv6)? Who has the admin rights? Potential can of worms and source of conflict until the question is sorted out for each DHCPv6 option of who can set the value and which source is authoritative.
So in summary, I'd settle for MAY for server, and SHOULD for relay. IMVVVVHO regards, RayH
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
