Message: 2 Date: Mon, 30 May 2011 12:47:19 +0200 From: Markus Hanauska
<hanau...@equinux.de> To: Mark Smith
<i...@69706e6720323030352d30312d31340a.nosense.org> Cc: Thomas Narten
<nar...@us.ibm.com>, "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms
<rdroms.i...@gmail.com> Subject: Re: Node Requirements: Elevating
DHCPv6 from MAY to SHOULD Message-ID:
<3044c560-f46c-477a-bd87-df252f689...@equinux.de> Content-Type:
text/plain; charset=us-ascii On 2011-05-23, at 23:56 , Mark Smith wrote:
>> Christopher Morrow<christopher.mor...@gmail.com> 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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
