Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

From: Thomas Narten <[email-masked]>
Date: Fri, 13 May 2011 09:37:39 -0400

Per a previous thread, there are indications that the WG may now be
willing to recommend that DHCPv6 be a SHOULD for all hosts. This is
based on the following rationale:

Thomas Narten <[email-masked]> writes:

> I personally would support having DHCP be a SHOULD rather than a
> MAY. The justification in my mind is that if you want the network
> operator to have the choice of whether they want to use  Stateless
> addrconf OR DHCP, they only have that choice of devices widely
> implement both.

This was supported by some others, particularly now that it is clear
there are more implementations of DHCPv6, e.g.:

Bob Hinden <[email-masked]> writes:

> While my personal view is that DHCPv6 won't be used for host
> configuration in cable/DSL deployments (except for provisioning the
> prefix to the home router), it appears that DHCPv6 is being widely
> implemented in host OS's because it is needed some environments.
> There are enough variations in deployment models that a host
> developer will need to support both.

> Based on this, I think a SHOULD is OK. 

Let me propose the following change be made to the node requirements
document:

OLD/Current:

   DHCP can be used to obtain and configure addresses.  In general, a
   network may provide for the configuration of addresses through Router
   Advertisements, DHCP or both.  At the present time, the configuration
   of addresses via stateless autoconfiguration is more widely
   implemented in hosts than address configuration via DHCP.  However,
   some environments may require the use of DHCP and may not support the
   configuration of addresses via RAs.  Implementations should be aware
   of what operating environment their devices will be deployed.  Hosts
   MAY implement address configuration via DHCP.

New:

      	<t> DHCPv6 <xref target='RFC3315' /> can be used to obtain and
	configure addresses. In general, a network may provide for the
	configuration of addresses through Router Advertisements,
	DHCPv6 or both.  Some operators have indicated that they do
	not intend to support stateless address autoconfiguration on
	their networks and will require all address assignments be
	made through DHCPv6. On such networks, devices that support
	only stateless address autoconfiguration will be unable to
	automatically configure addresses. Consequently all hosts
	SHOULD implement address configuration via DHCP.</t>

Is this acceptable?

Please respond yes or no. Given the WG's previous hesitation to having
DHCPv6 be a SHOULD, it is important that we get a clear indication of
whether or not the WG supports this change.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Fri, 13 May 2011 09:45:37 -0400

Thomas...

> 	SHOULD implement address configuration via DHCP.</t>

Looks fine and appropriate to me, with one nit: s/DHCP/DHCPv6/ in the last line.

- Ralph

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 May 2011 15:29:09 +0100

> Looks fine and appropriate to me, with one nit: s/DHCP/DHCPv6/ in the last line.

Looks good.  

Personally I would probably say 'support' rather than 'implement' in the last sentence, as per the first sentence of 5.9.2 where we say "Hosts MUST support IPv6 Stateless Address Autoconfiguration", but either is OK.

Tim

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 13 May 2011 07:35:42 -0700

> whether or not the WG supports this change.

Yes. I support the new text.

Cb

---

From: Scott Brim <[email-masked]>
Date: Fri, 13 May 2011 11:15:55 -0400

> Looks fine and appropriate to me, with one nit: s/DHCP/DHCPv6/ in the last line.

+1

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 May 2011 08:42:01 -0700

> whether or not the WG supports this change.

Should be a SHOULD.

Fred

---

From: Bob Hinden <[email-masked]>
Date: Fri, 13 May 2011 08:55:48 -0700

Thomas,

> whether or not the WG supports this change.

While I support changing the requirement to a SHOULD, I would prefer the text to be something like:

     	<t> DHCPv6 <xref target='RFC3315' /> can be used to obtain and
	configure addresses. In general, a network may provide for the
	configuration of addresses through Router Advertisements,
	DHCPv6 or both.   There will be a wide range of IPv6 deployment models
        and differences in address assignment requirements.  Consequently all hosts
	SHOULD implement address configuration via DHCP.</t>

It's not just about what some operators may or may not do.  For example enterprises, governments, etc. will also have specific requirements.

Bob

---

From: Thomas Narten <[email-masked]>
Date: Fri, 13 May 2011 12:02:21 -0400

Bob,

> It's not just about what some operators may or may not do.  For
>  example enterprises, governments, etc. will also have specific
>  requirements.

I like this text better than what I proposed as well.

Thanks,
Thomas

---

From: <[email-masked]>
Date: Fri, 13 May 2011 16:19:02 +0000

Hi all,

>	SHOULD implement address configuration via DHCP.</t>

Should we give some guidance on what to do if both mechanisms are available
on a network, the methods give contradictory information? I don't think it is
enough to say that both SHOULD be supported, without giving additional
clarification on what it means when both are supported.

John

---

From: Ralph Droms <[email-masked]>
Date: Fri, 13 May 2011 12:22:30 -0400

> I like this text better than what I proposed as well.

Here's my contribution, trying to make an explicit link between the last two sentences:

        <t> DHCPv6 <xref target='RFC3315' /> can be used to obtain and
	configure addresses. In general, a network may provide for the
	configuration of addresses through Router Advertisements,
	DHCPv6 or both.  There will be a wide range of IPv6 deployment
	models and differences in address assignment requirements,
	some of which may require DHCPv6 for address assignment.
	Consequently all hosts SHOULD implement address configuration
	via DHCPv6.</t>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 13 May 2011 12:25:44 -0400

Hi John.

> clarification on what it means when both are supported.

IMO, it is a bit of a myth that the specs don't say anything to this
point.

Here is Section 5.6 from RFC 4862:

>    5.6.  Configuration Consistency
> 
>    It is possible for hosts to obtain address information using both
>    stateless autoconfiguration and DHCPv6 since both may be enabled at
>    the same time.  It is also possible that the values of other
>    configuration parameters, such as MTU size and hop limit, will be
>    learned from both Router Advertisements and DHCPv6.  If the same
>    configuration information is provided by multiple sources, the value
>    of this information should be consistent.  However, it is not
>    considered a fatal error if information received from multiple
>    sources is inconsistent.  Hosts accept the union of all information
>    received via Neighbor Discovery and DHCPv6.
> 
>    If inconsistent information is learned from different sources, an
>    implementation may want to give information learned securely
>    precedence over information learned without protection.  For
>    instance, Section 8 of [RFC3971] discusses how to deal with
>    information learned through Secure Neighbor Discovery conflicting
>    with information learned through plain Neighbor Discovery.  The same
>    discussion can apply to the preference between information learned
>    through plain Neighbor Discovery and information learned via secured
>    DHCPv6, and so on.
> 
>    In any case, if there is no security difference, the most recently
>    obtained values SHOULD have precedence over information learned
>    earlier.

The last sentence is the main one.

I also think that dealing with this issue in more detail may not be so
easy, and it would be better to do that as updates to those documents
(or a standalone document).

E.g., even DHCP by itself has a longstanding vagueness about how to
handle the merging of information received from running DHCP on
different interfaces. (And one reason its hard is that if the two
interfaces are in different management domains, there is no easy way
to merge the information. We now have a separate WG (MIF) dealing with
that sort of thing.)

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Fri, 13 May 2011 12:26:22 -0400

John...

> clarification on what it means when both are supported.

I think the IETF has been pretty good about keeping the information from the two sources independent.  Regarding address assignment specifically, what contradictory information might be provided?  I can imagine a node might get one address from SLAAC and another from DHCPv6, but that's an acceptable configuration.  DHCPv6 doesn't provide prefix information, so no conflicts there.  I don't think there's an issue if DHCPv6 assigns an address that's not in a prefix advertised in an RA.

- Ralph

---

From: "Timothy E. Enos" <[email-masked]>
Date: Fri, 13 May 2011 12:28:28 -0400

Hi Thomas,

Thanks for posting this.

IMO, a SHOULD is not required in a SOHO environment (which is arguably not a 
corner case for deployment). MAY works.

Just as some environments may require the use of DHCPv6, some environments 
may not.

For those that require use of DHCPv6, they MAY use it.

I think at least in the SOHO context, it's really the local administrative 
policies (not hard and fast technical factors) that determine the (lack of) 
need for DHCPv6.

All the above said, my personal opinion is that DHCPv6 does not need to 
elevated to SHOULD from MAY for the node requirements spec. If the group 
decides to the contrary I can certainly accept that.

My $0.02,

Tim
Ps 127:3-5

---

From: Bob Hinden <[email-masked]>
Date: Fri, 13 May 2011 09:40:03 -0700

Timothy,

On May 13, 2011, at 9:28 AM, Timothy E. Enos wrote:

> Hi Thomas,
> 
> Thanks for posting this.
> 
> IMO, a SHOULD is not required in a SOHO environment (which is arguably not a corner case for deployment). MAY works.
> 
> Just as some environments may require the use of DHCPv6, some environments may not.
> 
> I think at least in the SOHO context, it's really the local administrative policies (not hard and fast technical factors) that determine the (lack of) need for DHCPv6.
> 
> All the above said, my personal opinion is that DHCPv6 does not need to elevated to SHOULD from MAY for the node requirements spec. If the group decides to the contrary I can certainly accept that.

I think all we are trying to say that there are a wide range of deployment models, that we recommend that hosts SHOULD support both.  We are not making any statement about what should be used in a particular deployment.

Or at least, that's my thinking and why I support the SHOULD.  Also, why I suggested changing the text to not talk about "operators".

Bob

> 
> My $0.02,
> 
> Tim
> Ps 127:3-5
> 
> ----- Original Message ----- From: "Thomas Narten" <[email-masked]>
> To: <[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 13 May 2011 18:48:31 +0200 (CEST)

> based on the following rationale:

I support moving it to SHOULD.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Fri, 13 May 2011 16:48:50 +0000

Tim,

I think we are talking about the need of supporting DHCPv6, not the use of DHCPv6. Nodes that are in a SOHO environment may not need to use DHCPv6, but if those nodes also move outside of the SOHO network, they might need DHCPv6 in other networks. IMO, the ability to support both DHCPv6 or stateless address autoconfig is a very good thing for nodes, as it can be quite difficult to know what exact networks a node might attach to.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Timothy E. Enos
Sent: Friday, May 13, 2011 9:28 AM
To: Thomas Narten
Cc: [email-masked]
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

Hi Thomas,

Thanks for posting this.

My $0.02,

Tim
Ps 127:3-5

---

From: <[email-masked]>
Date: Fri, 13 May 2011 16:50:16 +0000

Hi Ralph,

> I think the IETF has been pretty good about keeping the information from the two sources independent.  Regarding address assignment specifically, what 
> contradictory information might be provided?  I can imagine a node might get one address from SLAAC and another from DHCPv6, but that's an acceptable
>  configuration.  DHCPv6 doesn't provide prefix information, so no conflicts there.  I don't think there's an issue if DHCPv6 assigns an address that's not in a prefix 
> advertised in an RA.

You are right, Thomas' text is enough for me.

John

---

From: <[email-masked]>
Date: Fri, 13 May 2011 16:51:19 +0000

> I also think that dealing with this issue in more detail may not be so easy, and it would be better to do that as updates to those documents (or a standalone 
>document).
>
> E.g., even DHCP by itself has a longstanding vagueness about how to handle the merging of information received from running DHCP on different interfaces. (And 
> one reason its hard is that if the two interfaces are in different management domains, there is no easy way to merge the information. We now have a separate WG 
> (MIF) dealing with that sort of thing.)

Agreed, and I don't think the Node Requirements doc is the place to provide this kind of clarification.

---

From: <[email-masked]>
Date: Fri, 13 May 2011 17:12:34 +0000

I support elevating the requirement for DHCPv6 on nodes to a SHOULD. 
Bob's proposed text looks fine.

-Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bob Hinden
Sent: Friday, May 13, 2011 10:56 AM
To: Thomas Narten
Cc: [email-masked]; Bob Hinden
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

Thomas,

On May 13, 2011, at 6:37 AM, Thomas Narten wrote:

>> I personally would support having DHCP be a SHOULD rather than a MAY. 
>> The justification in my mind is that if you want the network operator 
>> to have the choice of whether they want to use  Stateless addrconf OR 
>> DHCP, they only have that choice of devices widely implement both.
> 

Bob

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 13 May 2011 13:29:14 -0400

+1

(and thanks!)

---

From: Wes Beebee <[email-masked]>
Date: Fri, 13 May 2011 13:45:56 -0400

+1 

Note that this is a MUST for equipment in Cable networks, although I do
understand that there will be significant networks that won¹t rely on DHCPv6
in other deployment scenarios.

- Wes

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 May 2011 20:04:52 +0200

> to merge the information. We now have a separate WG (MIF) dealing with

YEs have we a WG item in that group dealing with that sort of thing - 
but it is not yet solved, at least with respect to the default route:

- should the lifetime of the default route sent by DHCP be 32 or 16bit 
long? (ND prefers the latter DHCP the former).

(your dhcp-should text seems to be saying operators dont like RA for 
some cases, hence they dont know how to configure the default route for 
these cases, hence DHCP should, and MIF doesnt lifetime).

Etc.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 May 2011 20:11:13 +0200

Le 13/05/2011 15:37, Thomas Narten a écrit :
> Thomas Narten<[email-masked]>  writes:
>
> Bob Hinden<[email-masked]>  writes:
>
>        	<t>  DHCPv6<xref target='RFC3315' />  can be used to obtain and

YEs I support this text as a SHOULD DHCP.

I have several positive reasons for that, related to efficient
auto-configuration in vehicular environments, moving networks using
prefix delegation - better use just one DHCP, instead of mixed DHCP+RA, etc.

But there are also unknowns: we still dont know how to configure a
default route using DHCPv6. One issue is the lifetime field (Default
Router List structure of ND implementation, and RA, use 16bit lifetimes
for the Default Router, MIF-DHCP draft doesnt say how long a lifetime 
is, and DHCP lifetime fields are typically 32bit). These aspects may be 
under discussion but until solved we dont know. (I know here locally, 
but may be different at yours).  There are other issues.

Alex

---

From: james woodyatt <[email-masked]>
Date: Fri, 13 May 2011 11:28:18 -0700

> Just as some environments may require the use of DHCPv6, some environments may not.

Mobile hosts SHOULD implement DHCPv6 clients.

I wouldn't oppose elevating the requirement further still to say that mobile hosts MUST implement DHCPv6 clients.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 13 May 2011 14:30:47 -0400

Hi Thomas,

> whether or not the WG supports this change.

Yes. I think that elevating DHCPv6 support to SHOULD is a good idea.

Thanks
Suresh

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 13 May 2011 11:34:22 -0700

On May 13, 2011 11:28 AM, "james woodyatt" <[email-masked]> wrote:
> I wouldn't oppose elevating the requirement further still to say that
mobile hosts MUST implement DHCPv6 clients.

Why?  Most mobile v6 nodes do not support it today. ... they use pco ie
during session setup.

Dhcpv6 is nice for LAN but generally not used in cellular networks .

I do not believe there needs to be special wording for mobile

Cb

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 May 2011 20:38:12 +0200

> willing to recommend that DHCPv6 be a SHOULD for all hosts.

<aol>

fwiw, there are large broadband providers that provision using dhcpv4
today.

randy

---

From: Wes Beebee <[email-masked]>
Date: Fri, 13 May 2011 14:43:30 -0400

> I do not believe there needs to be special wording for mobile

Or for any other specific deployment for that matter.  The reason I
mentioned cable is because many popular operating system-based hosts as well
as specific devices have to be able to operate in a cable environment  and
the operational reality is that it is a MUST for all of them.  However,
since there are other, closed, controlled environments where DHCPv6 may not
be necessary, SHOULD is the perfect level to cover all of the deployment
environments.  SHOULD means that you have to follow it unless you have a
good case why not (see RFC 2119 below):

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course

- Wes

---

From: james woodyatt <[email-masked]>
Date: Fri, 13 May 2011 11:56:27 -0700

On May 13, 2011, at 11:34 , Cameron Byrne wrote:
> Why?  Most mobile v6 nodes do not support it today. [...]

I was thinking about RFC 3775, section 11.5.2, which says:

    As described in Section 4, in order to form a new care-of address, a
    mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6
    [29]) Address Autoconfiguration.

---

From: <[email-masked]>
Date: Fri, 13 May 2011 19:00:40 +0000

>    [29]) Address Autoconfiguration.

How a MIP6 (or DSMIP6) MN configures the IPv6 CoA has no bearing on the
present discussion.
I do agree with Cameron that a MUST for mobile devices is a bad idea.

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 13 May 2011 12:59:30 -0700 (PDT)

> I do agree with Cameron that a MUST for mobile devices is a bad idea.

I think it would be much cheaper to implement DHCPv6 client on a mobile than SLAAC code.

--b

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 13 May 2011 16:14:08 -0400

I support the idea of making DHCPv6 a SHOULD, and like the text revision 
proposed by Bob as amended by Ralph.

As to the clarification of what to do in the event of inconsistent 
information when both methods are used, I agree that RFC 4862 covers 
it.   If pushed, citing that RFC would be better than incorporating text.

The comment from Tim that the DHCPv6 man not be of use in SOHO 
deployments, I think SHOULD still leaves enough wiggle room for a 
variety of implementations with different feature sets.

-- 
Edward J Jankiewicz, Senior Technical Advisor
ESG/ISD - Center for Navigation and Survivability Systems
SRI International, Inc.
[email-masked]
Direct:  443-502-5815
Google Voice:  908-718-1335

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 13 May 2011 15:25:36 -0500

> variety of implementations with different feature sets.

I support SHOULD for DHCPv6 as well.

But responding to the above, purely parenthetically, would DOCSIS be out of the question in a SOHO network? If not, and I think not, then we have been hearing that cable networks do use DHCP. So it would become mandatory is SOHO nets that depend on cable broadband.

Bert

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 13 May 2011 13:50:40 -0700

I agree with Ralph's text.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ralph Droms
> Sent: Friday, May 13, 2011 9:23 AM
> To: Thomas Narten
> Cc: [email-masked]; Bob Hinden; Ralph Droms
> models

---

From: [email-masked]
Date: Sat, 14 May 2011 01:21:52 +0200 (CEST)

> I support moving it to SHOULD.

Agreed.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Fri, 13 May 2011 19:32:07 -0400

All,
     The chairs have determined that there is a strong consensus to
elevate DHCPv6 to SHOULD support in the node requirements document.
Since this is the last open issue with this document, the chairs will
begin the advancement process when a new version is published.

Regards,
Brian & Bob

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 15 May 2011 12:11:03 +0000

Thomas,

I am in favor of the new text.  You may want to be specific and refer to
stateful DHCPv6.  Speaking as an operator, for WAN interface provisioning
stateful DHCPv6 is a requirement.  Stateless is not supported at all at
this time.

Thanks,

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 15 May 2011 12:15:37 +0000

Interesting point Bob raises.

Thomas,

Is the intention for the new text to relax the requirement for
auto-configuration?  The new DHCPv6 text should be in addition to support
for stateless auto-configuration to ensure other deployment models are
supported.

John

On 5/13/11 11:55 AM, "Bob Hinden" <[email-masked]> wrote:

>It's not just about what some operators may or may not do.  For example
>enterprises, governments, etc. will also have specific requirements.
>
>Bob
>
>

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 15 May 2011 12:33:54 +0000

Ralph, Thomas, John,

The attributes that come to mind are those that are DNS related via
RFC6106.  In theory I suppose what John mentioned could be an issue,
however, in a broadband DOCSIS environment we only support stateful DHCPv6
for provisioning today as such I do not anticipate seeing these sort of
issues in this scenario.  I could sooner see the issue John raises
occurring in an enterprise or within a home network, especially the
latter.  Regarding the latter, we have seen home router implementations
that issue link local addresses and global unicast addresses
simultaneously via RFC6106 for DNS server addresses.  This has since been
corrected.

John

On 5/13/11 12:26 PM, "Ralph Droms" <[email-masked]> wrote:

>I think the IETF has been pretty good about keeping the information from
>the two sources independent.  Regarding address assignment specifically,
>what contradictory information might be provided?  I can imagine a node
>might get one address from SLAAC and another from DHCPv6, but that's an
>acceptable configuration.  DHCPv6 doesn't provide prefix information, so
>no conflicts there.  I don't think there's an issue if DHCPv6 assigns an
>address that's not in a prefix advertised in an RA.
>
>- Ralph
>
>> 
>> John
>>

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 15 May 2011 13:14:16 +0000

Alex,

In DOCSIS deployments there are no issue with RAs and we do know how to
configure the default route.  DHCPv6 is used mainly for address, prefix,
and configuration information.

John

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 15 May 2011 13:19:43 +0000

Bert,

I sent some mail earlier on this topic.  We do require it for provisioning
via the WAN interface.  On the LAN we aim to ensure there is greater
flexibility.  I just want to make sure it is clear that cable broadband
does not require the use of DHCPv6 in the premise.  This is a local
policy/technical decision.

John

On 5/13/11 4:25 PM, "Manfredi, Albert E" <[email-masked]>
wrote:

>But responding to the above, purely parenthetically, would DOCSIS be out
>of the question in a SOHO network? If not, and I think not, then we have
>been hearing that cable networks do use DHCP. So it would become
>mandatory is SOHO nets that depend on cable broadband.
>
>Bert
>

---

From: "Timothy E. Enos" <[email-masked]>
Date: Sun, 15 May 2011 15:40:34 -0400

Hi Bob,

Thanks for your reply. I would say that partly because there are so many 
different deployment models that MAY is precisely what is informed here. 
That said, an acceptable alternative for me would be that it be SHOULD for 
both DHCPv6 and SLAAC.

DHCP certainly fills a void in IPv4, i.e. the dynamic configuration of hosts 
(i.e. nodes that are not routers). IMO it just isn't as necessary in IPv6 as 
it is in IPv4, as there is no SLAAC-like functionality built into IPv4. 
Further, it seems to me that SLAAC can be extended to do more for 
configuring IPv6 hosts akin to what DHCP does for IPv4 hosts.

So, we currently have two extant standardized ways to dynamically configure 
hosts in IPv6: DHCPv6 and SLAAC. I don't have any qualms about there being 
two different ways to configure IPv6 hosts and understand some do. I 
certainly don't have any qualms about there being more than one standardized 
way to do IPv6 PD either.

Something that was ostensibly first created to address a need to dynamically 
configure IPv4 hosts was further extended to allocate IPv6 prefixes to 
routers. FWIW, here is a paper that examines a few different PD and CD (i.e. 
certificate distribution) mechanisms: http://mobisend.org/SP1b.pdf.

I'm simply sharing my opinion, and appreciate this forum. This is my last 
post on the topic, and respectfully defer to group consensus on this issue.

Thanks,

Tim
Ps 127:3-5

----- Original Message ----- 
From: "Bob Hinden" <[email-masked]>
To: "Timothy E. Enos" <[email-masked]>
Cc: "Bob Hinden" <[email-masked]>; "Thomas Narten" 
<[email-masked]>; <[email-masked]>
Sent: Friday, May 13, 2011 12:40 PM
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

>> IMO, a SHOULD is not required in a SOHO environment (which is arguably 
>> not a corner case for deployment). MAY works.
>>
>> I think at least in the SOHO context, it's really the local 
>> administrative policies (not hard and fast technical factors) that 
>> determine the (lack of) need for DHCPv6.
>>
> I think all we are trying to say that there are a wide range of deployment 
> models, that we recommend that hosts SHOULD support both.  We are not 
> making any statement about what should be used in a particular deployment.
>
> Or at least, that's my thinking and why I support the SHOULD.  Also, why I 
> suggested changing the text to not talk about "operators".
>
> Bob
>
>
>
>>
>> My $0.02,
>>
>> Tim
>> Ps 127:3-5
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 May 2011 08:55:27 +1200

On 2011-05-16 07:40, Timothy E. Enos wrote:
> That said, an acceptable alternative for me would be that it be SHOULD
> for both DHCPv6 and SLAAC.

I am certain that SLAAC remains a MUST. We need stand-alone networks
to configure themselves; that was a very early requirement for IPng.

   Brian

---

From: Seiichi Kawamura <[email-masked]>
Date: Mon, 16 May 2011 09:17:32 +0900

Just read this thread. This is so great.
Thanks to Thomas and all for the new text.

Seiichi

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 May 2011 16:10:31 -0400

> auto-configuration?

No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD.

For one thing, DHCP doesn't have an option configure on-link prefixes,
so we still need SLAAC.

What we should have done oh-so-long-ago is ensure that you could
configure/operate a network with just DHCP (and no SLAAC at all) and
vice versa, and than made both a MUST on hosts.  That way, operators
truly have the choice as to which to use and everything would just
work.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 May 2011 16:21:17 -0400

Thomas - (hoping to fan the discussion) I think operators have expressed the desire to operate networks in DHCP-only mode, and the response has been "No, you don't really want to operate your networks that way".

If operators came forward again with a strong desire to operate networks using only DHCP, and no other technical reason, would they get a different answer today?

- Ralph

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 23 May 2011 16:58:00 -0400

> Thomas - (hoping to fan the discussion) I think operators have expressed the desire to operate networks in DHCP-only mode, and the response has been "No, you don't really want to operate your netwo…

one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6
is on-net, but require full config from a dhcpv6 server".
How does a host know that v6 is available otherwise? (this may be why
someone said "you don't really want to do that..')

-chris

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 May 2011 17:11:28 -0400

> someone said "you don't really want to do that..')

Well, if I could go back in time, I would never have defined the M&O
bits at all.

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!)

(Hmm, maybe I should just write such a spec now, given the M&O bit
definitions are in the twilight zone anyway... Discussion of what to
do with them was effectively removed from the last revisions of the
SLAAC documents, so now there is no clear guidance on how to process
them. The IETF at its finest...)

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2011 09:51:58 +1200

Thomas,

On 2011-05-24 09:11, Thomas Narten wrote:
> (Hmm, maybe I should just write such a spec now, 

Please do. It is one of the gaps identified in RFC 5887, btw.

   Brian

given the M&O bit

---

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

Hi Thomas,

On Mon, 23 May 2011 17:11:28 -0400

> predictable. (And avoided 10GB of mailing list discussion!)

What if both are available, accidentally or intentionally (due to
misunderstanding that it should be one or the other)? Conflict
resolution in these sorts of situations isn't always simple and
predictable. You've now got twice as many things to configure
correctly, and at least twice as many things to troubleshoot if they
don't work.

I'd think either leaving the status quo, or dumping one of them, and
adding the features to the remaining one to make it the functionally
equivalent to the dumped one would be a better thing to do at this time.

I'm not particularly pro-SLAAC, however I sit back and wonder what is
missing from it that makes DHCP essential? It seems to me that the
functional reason people want DHCP is that they think it will track
address use - but it won't if end-nodes are manually assigned static
addresses. SLAAC won't prevent that either - so both SLAAC and DHCP
aren't adequate if your goal is to track address use. In other words,
its a problem that neither of them adequately address and have tried to
address.

> them. The IETF at its finest...)

I'm a bit confused, I find this text in RFC4862 quite clear as to what
to do -

     M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

About the only thing I'd have changed in the above to make it more
clearer is to use the word "stateful" in the M section when referring to
DHCPv6 and "stateless" in the O section.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2011 10:13:17 +1200

Mark,

On 2011-05-24 09:56, Mark Smith wrote:
...
> missing from it that makes DHCP essential? 

To be blunt, that conversation isn't worth having. SLAAC is clearly
essential for isolated or bootstrapping networks to self-configure.
DHCP is clearly viewed as essential by many network managers. EOM.

...

> I'm a bit confused, I find this text in RFC4862 quite clear as to what

It doesn't specify startup defaults and the like. RFC 5887, Section 5.1.1,
bottom of page 12, discusses this.

If you're concerned about SLAAC/DHCPv6 conflict resolution, see
draft-liu-ipv6-renum-conflicts (and join the [email-masked] list).

   Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 24 May 2011 08:01:54 +0930

On Tue, 24 May 2011 10:13:17 +1200

> DHCP is clearly viewed as essential by many network managers. EOM.

"  3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."

It's shame IPv6 fails on that count. I'm genuinely asking what the
improvements are to justify why two mechanisms that are almost
functionally equivalent.

> draft-liu-ipv6-renum-conflicts (and join the [email-masked] list).

Thanks for the reference, I'll have a look.

Regards,
Mark.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 23 May 2011 18:07:15 -0500

> improvements are to justify why two mechanisms that are almost

Mark, as I suggested previously, DHCP is useful in cases where you need the IP addresses of hosts in a network to be predictable. I have no idea why cable systems want DHCP, but I'm saying that IN GENERAL, if hosts needs to know a priori what the address of other hosts is, SLAAC falls flat on its face.

For example, a peer-to-peer network, where you don't want to rely on a DNS.

Bert

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 23 May 2011 19:44:27 -0400

> them. The IETF at its finest...)

ok, so ... as a thought experiment, in v4 you wake up, decide you have
no address and are supposed to dhcp for that..
in v6, you wake up decide you have no address (and don't know if v4/v6
are available)... if you are configured for v6 dhcp, you make that
request and get all the 'right' data.

Essentially, spec dhcpv6 host actions to be the same as v4?

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 23 May 2011 19:48:43 -0400

> For example, a peer-to-peer network, where you don't want to rely on a DNS.

really, the simplest case is enterprise networks:
  joe's machine always gets address 1:2:3::4/128
  janes machine always gets 1.2.3::5/128

this way techsupport always has a predictable mapping for these hosts,
they can identify form log messages over time what jane vs joe did...
not have ot worry about keeping track of the vagaries of privacy
addressing and jane/joe/etc flip flopping around the subnet at
"random".

Brian's point though is fair: Drive through, nothing new to discuss
here (wrt WHY)

-chris

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 May 2011 19:48:52 -0400

> Essentially, spec dhcpv6 host actions to be the same as v4?

yes.

Have DHCPv6 and SLAAC run independently. If you get stuff via one or
the other or both, just use them.

The mistake of the M&O bits was that you needed an RA to tell you to
use DHCP. But if the bits weren't set right, or something, you
wouldn't run DHCP in cases where you should have. Just decouple the
two protocols completely.

The one downside is that you run DHCP even if there are no DHCP
servers. In some environments, that is extra traffic the operator
might not want. I recall many long threads about how the cost of those
extra DHCP pacekts on a wireless network were unacceptable...

Thomas

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 23 May 2011 20:00:17 -0400

> extra DHCP pacekts on a wireless network were unacceptable...

I guess I was thinking that today you have a device, it either is
configured to do dhcp or is manually configured or just is broken. In
the v6 world you could just forget M&O and require someone to
configure (via os config tweaks that already exist for v4 anyway)
dhcpv6 if anything more complex than 'subnet + random address + defgw'
are required (or if they just like DHCP over SLAAC).

(are we saying the same thing? I'm --coffee so...)
-chris

---

From: Thomas Narten <[email-masked]>
Date: Mon, 23 May 2011 20:10:04 -0400

> are required (or if they just like DHCP over SLAAC).

Something like that. The key is that both are implemented. You can
then have defaults for whether or not they are enabled out of the box,
with switches to override the defaults.

But I'm thinking of zeroconfig in the general case. Just plug it into
the net, and it all just works. That means DHCP and SLAAC on by
default.

But zeroconfig isn't all that useful for some types of devices.  For
servers, routers, and other more "infrastructury" devices, it may be
fine to require some config before you plug the machine in.

Of course, manual config is always an option, in which case you turn
off SLAAC & DHCP (except for LL addrs).

Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 May 2011 10:05:19 +0200

On May 24, 2011, at 01:48, Thomas Narten wrote:

> servers. In some environments, that is extra traffic

... and an extra attack (if you happen to have RA-guard but no protection for DHCP).
Maybe not that much of a difference, but still a thing to take note of.

The extra traffic is a little more interesting in constrained node/networks (e.g., 6LoWPAN).
I think we will continue to use the M bit for gating DHCP.
(See section 3.2 of draft-ietf-6lowpan-nd-15.txt for details of how we do this.)
Maybe our needs are not relevant for the ND-classic spec, but this is just one more data point.

Gruesse, Carsten

---

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

On May 23, 2011, at 4:48 PM, Thomas Narten wrote:
> 
> The one downside is that you run DHCP even if there are no DHCP servers. In some environments, that is extra traffic the operator might not want. I recall many long threads about how the cost of those extra DHCP packets on a wireless network were unacceptable.

Yes, and if we'd like to rehash those arguments again, then I stand ready to defend that proposition.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 May 2011 10:51:14 -0700

Hi Thomas, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Narten
> Sent: Monday, May 23, 2011 1:11 PM
> To: Brzozowski, John

Not all links will necessarily require on-link prefixes. For
those, DHCPv6 alone may be sufficient.

Thanks - Fred
[email-masked]

---

From: Christopher Palmer <[email-masked]>
Date: Tue, 24 May 2011 19:14:42 +0000

Very long thread....

I simply wanted to signal our (Windows Networking) support of DHCPv6 being a SHOULD, and I personally think the text below is entirely good.

----------------------------
[email-masked] 
Program Manager 
IPv6 @ Windows

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Friday, May 13, 2011 6:38 AM
To: [email-masked]
Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

Per a previous thread, there are indications that the WG may now be willing to recommend that DHCPv6 be a SHOULD for all hosts. This is based on the following rationale:

> DHCP, they only have that choice of devices widely implement both.

This was supported by some others, particularly now that it is clear there are more implementations of DHCPv6, e.g.:

Bob Hinden <[email-masked]> writes:

> There are enough variations in deployment models that a host developer 
> will need to support both.

OLD/Current:

New:

Is this acceptable?

Please respond yes or no. Given the WG's previous hesitation to having
DHCPv6 be a SHOULD, it is important that we get a clear indication of whether or not the WG supports this change.

Thomas

---

From: <[email-masked]>
Date: Tue, 24 May 2011 19:18:04 +0000

Dumb question, but isn't the text making support for DHCPv6 a SHOULD, but not making it a SHOULD or MUST to run? 

I completely agree that in some networks (or interfaces) where the node 'knows' that DHCP isn't deployed in the network, there is no sense in running DHCP.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 24 May 2011 16:14:07 -0400

> Dumb question, but isn't the text making support for DHCPv6 a
>  SHOULD, but not making it a SHOULD or MUST to run?

Correct. It's a SHOULD to implement. Whether to use it is a separate
discussion, and neither the Node Requirements or IPv6 specs address
this.

Thomas

---

From: Mark Smith <[email-masked]>
Date: Wed, 25 May 2011 06:46:27 +0930

Hi Fred,

On Tue, 24 May 2011 10:51:14 -0700

> those, DHCPv6 alone may be sufficient.

Out of curiosity, wouldn't link locals be classified as SLAAC
addresses (as in, their configuration is stateless and
they're autoconfigured by default)? I understand you're saying that
there are scenarios where RA's wouldn't contain a PIO, or perhaps the
PIO wouldn't have then on-link flag set, however I'm curious if saying
that SLAAC isn't necessary in that scenario is also implying that
link-locals may not be necessary either?

Thanks,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 May 2011 09:17:40 +1200

> discussion, and neither the Node Requirements or IPv6 specs address

Which, to repeat myself again, is exactly the point made by RFC 5887.
As far as the document currently under discussion is concerned, surely
we are done?

   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 25 May 2011 06:51:34 +0930

Hi Bert,

On Mon, 23 May 2011 18:07:15 -0500
"Manfredi, Albert E" <[email-masked]> wrote:

> Mark, as I suggested previously, DHCP is useful in cases where you need the IP addresses of hosts in a network to be predictable.

Isn't the best way to achieve predictable addresses to use static ones?

Or are you talking about an assured and automated permanent binding
between a link layer address and an IPv6 address? If it's the latter
then that is the only functionality gap I can think of between SLAAC
and DHCPv6, although obviously SLAAC addresses are usually derived from
link layer addresses.

> I have no idea why cable systems want DHCP, but I'm saying that IN
> GENERAL, if hosts needs to know a priori what the address of other
> hosts is, SLAAC falls flat on its face.
> 

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 May 2011 15:00:03 -0700

Hi Mark, 

> From: Mark Smith 
> [mailto:[email-masked]] 
> Sent: Tuesday, May 24, 2011 2:16 PM
> To: Templin, Fred L
> Cc: Thomas Narten; Brzozowski, John; Bob Hinden; [email-masked]

Good point; yes, even DHCPv6 requires link-locals. The
link-locals could be manually configured, but it seems
reasonable to assume that they would often be autoconfigured
using SLAAC.

Thanks - Fred

---

From: Doug Barton <[email-masked]>
Date: Tue, 24 May 2011 15:36:31 -0700

> reasonable to assume that they would often be autoconfigured

I'm confused (nothing new about that). In FreeBSD the OS creates the 
LLA, which is then used for rtsol, etc. Are we doing it wrong?

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Mark Smith <[email-masked]>
Date: Wed, 25 May 2011 19:55:28 +0930

Hi Doug,

On Tue, 24 May 2011 15:36:31 -0700

> LLA, which is then used for rtsol, etc. Are we doing it wrong?

No. I was more clarifying/observing that if link-locals are classified
as SLAAC addresses, a pure non-SLAAC environment is impossible because
of the required presence of link-locals for purposes such as those you
mention.

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Wed, 25 May 2011 12:39:08 +0100

> addressing and jane/joe/etc flip flopping around the subnet at

Whether you can enforce that jane only uses 1:2:3::5 and doesn't also use other self-selected addresses is another question; in IPv6 it's easier for devices to use different or additional addresses without causing address conflicts.  Thus having the tools to monitor which addresses are appearing where is pretty useful.

> Brian's point though is fair: Drive through, nothing new to discuss

On the matter of the subject line, yes :)

Tim

---

From: Markus Hanauska <[email-masked]>
Date: Mon, 30 May 2011 12:47:19 +0200

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

> What if both are available,

Then a node has both, a SLAAC address and a DHCPv6 address. Where is the problem? The only problem I can think of is the issue I was trying to discuss here a couple of weeks ago: An address collision between SLAAC addresses and non-SLAAC addresses. Normal SLAAC should never collide with DHCP, since the 'u' bit is always 1 for a SLAAC address (globally unique) but should be '0' for a DHCP address (not globally unique). Only SLAAC with Privacy Extension could collide with DHCP (since it also has a 'u' bit of 0) and I was told on this list "Don't worry, the address space is so huge, this is probably never going to happen". I personally would have preferred if the standards reserved an address range within each /64 network that must not be used by SLAAC (regardless what kind of SLAAC, it is taboo) and thus is safe for DHCP pools or manual assigned addresses;  however most people here seem to reject such an address range (for reasons I cannot really understand, since it would not hurt anyone in any way, but it could be pretty useful in real world scenarios).

> Conflict
> predictable.

Conflict resolution is not really necessary. What kind of conflict do you have to solve? If a network runs a DHCPv6 server that also hands out addresses, the network operators probably want people to use DHCPv6 over SLAAC, so if a host obtains both, an interface address via SLAAC and DHCPv6, then it should prefer the DHCPv6 address for all outgoing traffic, since if it uses the SLAAC address, a router may not forward their traffic or a firewall may drop it. If a network runs a DHCPv6 server, that does not hand out addresses (but possibly other useful information), then the operators probably want you to use SLAAC to obtain an address - in that case the system may use SLAAC or it may use SLAAC with Privacy Extension for outgoing traffic. If no DHCP server is present at all, SLAAC is your only option anyway. If there is a DHCP server but it refuses to talk to you or hand out an address to you, it is the same situation as if no such server was present.

> missing from it that makes DHCP essential?

The possibility to assign a specific address to a specific host, e.g. so that forward and reverse DNS resolution works for this host and so that you can create firewall rules on IP level. The same works with SLAAC, if you can for sure predict the interface identifier, but it will fail if privacy extension enters the game and also it means you have to update lots of configs whenever the interface ID of a node changes (e.g. NIC being replaced), in case of DHCP though, it is enough to store the new MAC address in the DHCP config and still assign the same IP as before to this host and everything will work as it used to.

Sure, you can do the same thing by manually assigning IP addresses and not use DHCP or SLAAC at all but being able to manage all this from a central place (a single server that is DHCP server and DNS server at the same time, for example) is much simpler and a lot less error-prone(!); further if you want/have to change the assigned IP address of a single host or group of hosts, it will be much easier.

> It seems to me that the
> addresses.

However, on most systems you need admin/root access to do any such thing and normal computer users on those networks may not have those access rights to their systems. Also intentionally breaking thinks like forward/reverse DNS resolution has no advantages to the user, it only has disadvantages, so why would he want to do so? The only reason I could think of is bypassing firewall rules and for this, as mentioned before, the user must have admin/root access and even that may not really buy him something, since the firewall may drop any traffic from an IP address that has not been assigned by DHCP. So the only thing the user could do is manually assigning the DHCP address of another node to his node... and this will fail, ND will prevent that from succeeding.

Sure, you can argue "what if a user uses a custom Linux system, with a custom kernel, that does not perform ND at all?"... but honestly, let's not go too deep into the topic security, security is certainly not the main argument for or against DHCP; I also doubt anyone ever said so. High security networks are the 0.01% case of all IPv6 networks and they may even require nodes to establish an IPSec tunnel to allow this host to send any traffic anywhere at all and/or shield network ports through VLANs and so on.

Regards,
Markus

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 May 2011 13:04:29 +0200

In your letter dated Mon, 30 May 2011 12:47:19 +0200 you wrote:
>Conflict resolution is not really necessary. What kind of conflict do you have
> to solve? If a network runs a DHCPv6 server that also hands out addresses, th
>e network operators probably want people to use DHCPv6 over SLAAC, so if a hos
>t obtains both, an interface address via SLAAC and DHCPv6, then it should pref
>er the DHCPv6 address for all outgoing traffic, since if it uses the SLAAC add
>ress, a router may not forward their traffic or a firewall may drop it. 

There is an 'A-bit' in the Prefix Information option. I'd suggest that 
operators use that bit to control the assignment of SLAAC addresses.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 May 2011 22:27:16 +0200

In your letter dated Mon, 30 May 2011 12:47:19 +0200 you wrote:
>Then a node has both, a SLAAC address and a DHCPv6 address. Where is the probl
>em? The only problem I can think of is the issue I was trying to discuss here 
>a couple of weeks ago: An address collision between SLAAC addresses and non-SL
>AAC addresses. Normal SLAAC should never collide with DHCP, since the 'u' bit 
>is always 1 for a SLAAC address (globally unique) but should be '0' for a DHCP
> address (not globally unique). Only SLAAC with Privacy Extension could collid
>e with DHCP (since it also has a 'u' bit of 0) and I was told on this list "Do
>n't worry, the address space is so huge, this is probably never going to happe
>n". 

If you are really worried about this, then I guess you can also just assign
two prefixes to a single link and use one for SLAAC and the other for DHCPv6.

---

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

> two prefixes to a single link and use one for SLAAC and the other for DHCPv6.

Of course this is possible, but this also means, that a node not doing DHCPv6 (because it does not support it or because it is disabled on the node), will only get an address of the SLAAC prefix and thus has to go to through the network router to have its packets routed the other one. So even though both nodes are on the same physical network, all traffic has to pass through a router, instead of being exchanged directly between the two nodes. This means a lot of unnecessary load for the this router to route "local traffic".

Regards,
Markus

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 May 2011 11:19:59 +0200

In your letter dated Tue, 31 May 2011 11:12:13 +0200 you wrote:
>Of course this is possible, but this also means, that a node not doing =
>DHCPv6 (because it does not support it or because it is disabled on the =
>node), will only get an address of the SLAAC prefix and thus has to go =
>to through the network router to have its packets routed the other one. =
>So even though both nodes are on the same physical network, all traffic =
>has to pass through a router, instead of being exchanged directly =
>between the two nodes. This means a lot of unnecessary load for the this =
>router to route "local traffic".

No, ND is more clever than that. All traffic between prefixes that are on-link
goes directly between the hosts. Even when the prefix is off-link it is
possible for the router the send a redirect ICMP to cause further traffic
to be directly between the hosts.

---

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

On Tue, 31 May 2011, Markus Hanauska wrote:

> Of course this is possible, but this also means, that a node not doing 
> DHCPv6 (because it does not support it or because it is disabled on the 
> node), will only get an address of the SLAAC prefix and thus has to go 
> to through the network router to have its packets routed the other one. 
> So even though both nodes are on the same physical network, all traffic 
> has to pass through a router, instead of being exchanged directly 
> between the two nodes. This means a lot of unnecessary load for the this 

Why would you do assign different prefixes via SLAAC and DHCPv6?

This is similar to the problem of IPv4 when you configured secondary 
addresses (from different subnet) to an interface.

Best Regards,
 		Janos Mohacsi

---

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

On Tue, 31 May 2011, Mohacsi Janos wrote:

>> node), will only get an address of the SLAAC prefix and thus has to go to 
>> through the network router to have its packets routed the other one. So 
>> even though both nodes are on the same physical network, all traffic has to 
>> pass through a router, instead of being exchanged directly between the two 
>> nodes. This means a lot of unnecessary load for the this router to route 
>> "local traffic".
>

Yes, Philip is right. I was wrong.

---

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

> to be directly between the hosts.

I don't think this related to ND, is it? ICMP redirects also exist for IPv4 and IPv4 doesn't know ND. I think only difference is that ICPMv6 optionally allows an link layer address in the redirect message. How good IPv6 implementations really support ICMPv6 redirects as of today is another question.

My main problem with that approach is, that not everyone has a $5000++ Cisco router available and the configuration capabilities of some more inexpensive routers are quite limited; especially regarding IPv6, which is still not mainstream (the majority of routers on the market still has no IPv6 support at all). Also what are you going to do, if your ISP only gives you a single /64 prefix? To subdivide it, you have to use some bits for subnetworking, which means your hosts might only have /48 addresses and that disables SLAAC entirely.

I still think it would have been much easier, to define a second bit in the /64 address space. Just like the 'u' bit, which says that an address is globally unique or not, there would be the 'a' bit, which is set if the address has been assigned "automatically" (SLAAC w/ or w/o Privacy Extension) and not set, if this address has been "manually" assigned (either by manual config on the node or by DHCP or anything comparable to DHCP). This will effectively eliminate collisions, except for MAC address collisions or collisions caused by misconfiguration of manual IPs and/or DHCP.

Regards,
Markus

---

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

On Tue, 31 May 2011, Markus Hanauska wrote:

> My main problem with that approach is, that not everyone has a $5000++ 
> Cisco router available and the configuration capabilities of some more 
> inexpensive routers are quite limited; especially regarding IPv6, which 
> is still not mainstream (the majority of routers on the market still has 
> no IPv6 support at all). Also what are you going to do, if your ISP only 
> gives you a single /64 prefix? To subdivide it, you have to use some 
> bits for subnetworking, which means your hosts might only have /48 
> addresses and that disables SLAAC entirely.

If you get /64 and you need more subnets from your provider then probably 
you asked something wrong.
You should get /64 if and only if you have only one subnet! Or your ISP 
does not understand IPv6. In this case avoid it.

>
> I still think it would have been much easier, to define a second bit in 
> the /64 address space. Just like the 'u' bit, which says that an address 
> is globally unique or not, there would be the 'a' bit, which is set if 
> the address has been assigned "automatically" (SLAAC w/ or w/o Privacy 
> Extension) and not set, if this address has been "manually" assigned 
> (either by manual config on the node or by DHCP or anything comparable 
> to DHCP). This will effectively eliminate collisions, except for MAC 
> address collisions or collisions caused by misconfiguration of manual 
> IPs and/or DHCP.
>

What collision? You should use 'u' bit accrdingly:
1 - if automaticaly assigned
0 - if manually assigned.

Best Regards,
 		Janos Mohacsi

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 31 May 2011 12:28:01 +0200 (CEST)

On Tue, 31 May 2011, Philip Homburg wrote:

> No, ND is more clever than that. All traffic between prefixes that are 
> on-link goes directly between the hosts. Even when the prefix is 
> off-link it is possible for the router the send a redirect ICMP to cause 
> further traffic to be directly between the hosts.

I hope there is a recommendation in the standard to have a knob to turn 
this off? With security functions like forced-forwarding and alike, I'd 
definitely not want the hosts to try to communicate directly between each 
other.

I was under the impression that if I don't announce an on-link prefix at 
all, and just do DHCPv6, there hosts would not try to communicate with 
each other directly (ie there is no routing to support this function). 
You're saying my presumption is not true?

Why would a host try to do ND for something that is not on-link according 
to its routing table?

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 May 2011 12:35:01 +0200

In your letter dated Tue, 31 May 2011 11:54:57 +0200 you wrote:
>I don't think this related to ND, is it? ICMP redirects also exist for =
>IPv4 and IPv4 doesn't know ND. I think only difference is that ICPMv6 =
>optionally allows an link layer address in the redirect message. How =
>good IPv6 implementations really support ICMPv6 redirects as of today is =
>another question.

The difference is that IPv4 has a model of one subnet per link. If you
get an ICMP for something that is not on your subnet, then it is best to 
ignore it. There is no problem get the link layer address: just ARP for it.

>My main problem with that approach is, that not everyone has a $5000++ =
>Cisco router available and the configuration capabilities of some more =
>inexpensive routers are quite limited; especially regarding IPv6, which =
>is still not mainstream (the majority of routers on the market still has =
>no IPv6 support at all). 

That's always that case if you want a configuration that is not mainstream:
you either have to buy a more expensive product that has more configuration
options or, in many cases, you can also use open source.

---

From: Markus Hanauska <[email-masked]>
Date: Tue, 31 May 2011 12:37:05 +0200

On 2011-05-31, at 12:10 , Mohacsi Janos wrote:

> If you get /64 and you need more subnets from your provider then probably you asked something wrong.

Or you have the wrong provider... but if this is the only provider available in your area, that can offer you a symmetric 100 MBit/s fibre connection for business purposes, what are you going to do? Move your whole company elsewhere? I don't think so. Sometimes it is also a question of money; you can have a larger prefix, if you are willing to pay ten times the price, which is not acceptable for every company in the world.

> 0 - if manually assigned.

But it is also 0 for SLAAC addresses w/ privacy extension and those are automatically assigned, in example.

Regards,
Markus

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 May 2011 12:40:32 +0200

>definitely not want the hosts to try to communicate directly between each 

A prefix only becomes on-link if there is a prefix option that says so.

Of course, absent secure ND, any host can fake a redirect ICMP. So you either
SEND or L2 devices that filter ICMPs. But you need that anyhow.

>You're saying my presumption is not true?

If the prefix is not announced as on-link then hosts have to send their
packets to a default router until they get a redirect.

>Why would a host try to do ND for something that is not on-link according 

I was not implying that hosts would that without a router announcing the 
prefix as on-link. I just wanted to make clear that IPv6 *supports* direct
communication between hosts that use addresses from different prefixes.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 May 2011 12:46:28 +0200

In your letter dated Tue, 31 May 2011 12:37:05 +0200 you wrote:
>Or you have the wrong provider... but if this is the only provider =
>available in your area, that can offer you a symmetric 100 MBit/s fibre =
>connection for business purposes, what are you going to do? Move your =
>whole company elsewhere? I don't think so. Sometimes it is also a =
>question of money; you can have a larger prefix, if you are willing to =
>pay ten times the price, which is not acceptable for every company in =
>the world.

If the only provider available doesn't do IPv6 at all, then what do you do?
If you want a separate guest net for wifi and you only get one a /64, then
what do you do?

You can't engineer protocols around providers that want to make their
customers misserable.

There are plenty of /48s for everybody. Let's use them!

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 31 May 2011 13:06:20 +0200 (CEST)

> A prefix only becomes on-link if there is a prefix option that says so.

Hm, I might not understand what you mean by "prefix option" here, if an 
ICMP-redirect all of a sudden can make a /128 be on-link even though it's 
not in my routing table.

> prefix as on-link. I just wanted to make clear that IPv6 *supports* 
> direct communication between hosts that use addresses from different 
> prefixes.

Absolutely, but if there is another way than to announce the on-link 
prefix than might make hosts communicate directly to each other on a 
subnet, that's news to me and I find this extremely interesting from a 
security standpoint.

For me, if I have:

R1 X::1/64
H2 X::2/128
H3 X::3/128

R1 doesn't announce any on-link prefix, so H2 and H3 use R1 to communicate 
between each other (they just have their own /128 in their routing table 
and default route pointing to R1 LL address learnt via RA).

Now, what I interpreted you saying is that R1 can tell H2 that H3 is 
on-link by means of an ICMP redirect. This has security (and functional) 
implications in that any L2 network they might have that disallows H2 and 
H3 to communicate between each other even though they're in the same vlan, 
will make this completely stop working if R1 doesn't have a knob to 
disallow it from sending redirects that might indicate that H2 and H3 is 
on the same L2 domain (on-link).

---

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

On Tue, 31 May 2011, Markus Hanauska wrote:

> Or you have the wrong provider...

I agree.

> but if this is the only provider 
> available in your area, that can offer you a symmetric 100 MBit/s fibre 
> connection for business purposes, what are you going to do? Move your 
> whole company elsewhere? I don't think so. Sometimes it is also a 
> question of money; you can have a larger prefix, if you are willing to 
> pay ten times the price, which is not acceptable for every company in 
> the world.

You have to explain your provider to assign more otherwise they are not 
following the registration policy documents of RIRs e.g Section 5.3 
and 5.4.x
http://www.ripe.net/ripe/docs/ripe-512

> But it is also 0 for SLAAC addresses w/ privacy extension and those are automatically assigned, in example.

You can argument for change in the RFC 4941 revision.

Best Regards,
 		Janos Mohacsi

---

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

On 2011-05-31, at 12:35 , Philip Homburg wrote:

> The difference is that IPv4 has a model of one subnet per link.

Why do you think so? The computer I'm using right now has two IP addresses of different IP subnets on the same network interface (and I really mean the same layer 2 network, there are no VLANs in use). I think pretty much any operating system as of today allows for such a configuration.

> options or, in many cases, you can also use open source.

But don't you think it helps a lot to push a new technology to mainstream if it is possible to also use this technology without any expensive hardware or complicated configurations? My main argument was (and still is), that through a couple of tiny changes in the RFCs (only a couple of sentences) and equally small changes to implementations (5-10 lines of additional code), IPv6 could have been so much easier for everyone: Hardware vendors producing IPv6 hardware, software vendors writing IPv6 software, network administrators creating IPv6 networks, end users actually using IPv6. The negative impact would have been close to zero, the positive impact would have been big and maybe IPv6 would have been somewhat more mainstream as of today if people had considered some tiny things. The most important ones are:

1) A need for DHCPv6 right from the start and taking it into consideration everywhere SLAAC was taken into consideration. E.g. is this thread; DHCPv6 should have been "SHOULD" right from day one.

2) A better way to run SLAAC, SLAAC + Privacy Ext, DHCP and manual addressing all on the same link *AND* same prefix in such a way, that it is almost address conflict free without having to rely on ND to discover conflicts (since ND will fail for hosts currently offline, but with reserved addresses): Defining all addressing schemes in such a way, that they don't interfere with each other under "normal" operation conditions - of course MAC address conflicts are still possible, two nodes with SLAAC + Priv Ext may also collide (only ND can avoid that) and misconfiguration will always be possible; but I consider none of these as normal operation conditions). Only two flags in 64 bit node addresses would have been necessary for that.

3) No M/O bits in router advertise messages. Every interface can have a manually configured address, a DHCPv6 address, a SLAAC address, a SLAAC w/ Priv Ext and that for every prefix it is aware of. The order of preference for outgoing traffic is configurable, the default order is defined in any RFC (e.g. I would suggest manual, DHCP, SLAAC w/ Priv Ext, SLAAC).

4) Considering DNS right from the start, since DNS is almost critical for many networks as of today. If one of the IPv6 main design goal was to allow the majority of networks to operate without a DHCP server (and it looks as if it was, otherwise DHCPv6 would have been taken much more into account), something like RFC 6106 (former 5006) was missing way too long IMHO. Though I still fail to see the need for this RFC at all; I had rather said that for simple setups that don't provide DNS servers via DHCP, it would have been enough to have a well defined anycast or even multicast address for DNS servers (I don't know any real life network where DNS server addresses changes so frequently, that this wouldn't work well in practice).

Regards,
Markus

---

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

On Tue, 31 May 2011, Markus Hanauska wrote:

>
>
> But don't you think it helps a lot to push a new technology to 
> mainstream if it is possible to also use this technology without any 
> expensive hardware or complicated configurations? My main argument was 
> (and still is), that through a couple of tiny changes in the RFCs (only 
> a couple of sentences) and equally small changes to implementations 
> (5-10 lines of additional code), IPv6 could have been so much easier for 
> everyone: Hardware vendors producing IPv6 hardware, software vendors 
> writing IPv6 software, network administrators creating IPv6 networks, 
> end users actually using IPv6. The negative impact would have been close 
> to zero, the positive impact would have been big and maybe IPv6 would 
> have been somewhat more mainstream as of today if people had considered 
> some tiny things. The most important ones are:

The impact of changes can be quite substantial.

>
> 1) A need for DHCPv6 right from the start and taking it into 
> consideration everywhere SLAAC was taken into consideration. E.g. is 
> this thread; DHCPv6 should have been "SHOULD" right from day one.

Agree. Adding DHCPv6 support to an existing IPv6 capable implementation 
might be possible.

>
> 2) A better way to run SLAAC, SLAAC + Privacy Ext, DHCP and manual 
> addressing all on the same link *AND* same prefix in such a way, that it 
> is almost address conflict free without having to rely on ND to discover 
> conflicts (since ND will fail for hosts currently offline, but with 
> reserved addresses): Defining all addressing schemes in such a way, that 
> they don't interfere with each other under "normal" operation conditions 
> - of course MAC address conflicts are still possible, two nodes with 
> SLAAC + Priv Ext may also collide (only ND can avoid that) and 
> misconfiguration will always be possible; but I consider none of these 
> as normal operation conditions). Only two flags in 64 bit node addresses 
> would have been necessary for that.

I disagree with introduction of another flags. This requires substantial 
changes in the codes.... Which will take ages....

>
> 3) No M/O bits in router advertise messages. Every interface can have a 
> manually configured address, a DHCPv6 address, a SLAAC address, a SLAAC 
> w/ Priv Ext and that for every prefix it is aware of. The order of 
> preference for outgoing traffic is configurable, the default order is 
> defined in any RFC (e.g. I would suggest manual, DHCP, SLAAC w/ Priv 
> Ext, SLAAC).

We need M/O bits to give some sort of consistency. But nothing prevent a 
host to use DHCPv6 and SLAAC address and static in the same time.

I have to disagree with your suggested ordering.

>
> 4) Considering DNS right from the start, since DNS is almost critical 
> for many networks as of today. If one of the IPv6 main design goal was 
> to allow the majority of networks to operate without a DHCP server (and 
> it looks as if it was, otherwise DHCPv6 would have been taken much more 
> into account), something like RFC 6106 (former 5006) was missing way too 
> long IMHO. Though I still fail to see the need for this RFC at all; I 
> had rather said that for simple setups that don't provide DNS servers 
> via DHCP, it would have been enough to have a well defined anycast or 
> even multicast address for DNS servers (I don't know any real life 
> network where DNS server addresses changes so frequently, that this 
> wouldn't work well in practice).

Nothing prevent you the suggest an draft document for multicast or anycast 
resolving DNS. There is environment where SLAAC more acceptable - e.g. 
less adminisration, and there is environment where DHCPv6 is the only way 
to operate.

Best Regards,
 		Janos Mohacsi

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 May 2011 13:39:55 +0200

>on the same L2 domain (on-link).

RFC-4861 (Neighbor Discovery for IP version 6 (IPv6)):
"8.3.  Host Specification
[...]
"If the Target and Destination Addresses are the same, the host MUST treat the
"Target as on-link.

I have no idea why you want hosts on the same vlan and then use L2 filtering
to prevent them from communicating directly. But yes, if the router would
then start sending redirects, it would create a mess.

---

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

> You can argument for change in the RFC 4941 revision.

When I first mentioned this topic here on the list, I got the impression that there will never be a consent for such a change.

Regards,
Markus

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 31 May 2011 13:45:43 +0200 (CEST)

On Tue, 31 May 2011, Philip Homburg wrote:

> I have no idea why you want hosts on the same vlan and then use L2 
> filtering to prevent them from communicating directly. But yes, if the 
> router would then start sending redirects, it would create a mess.

This has been a common deployment scenario for ETTH for the past 10 years.

On IPv4, this was done by means of local-proxy-arp by the gateway, which 
is suboptimal for other reasons.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 May 2011 14:01:28 +0200

In your letter dated Tue, 31 May 2011 13:19:39 +0200 you wrote:
>Why do you think so? The computer I'm using right now has two IP =
>addresses of different IP subnets on the same network interface (and I =
>really mean the same layer 2 network, there are no VLANs in use). I =
>think pretty much any operating system as of today allows for such a =
>configuration.

I would say that having an interface with two IPv4 addresses is not really in
the model.

But specifically, you may find that for each of those two addresses the host
will treat only the subnet associated with the address as on-link. 

>> That's always that case if you want a configuration that is not =
>mainstream:
>> you either have to buy a more expensive product that has more =
>configuration
>But don't you think it helps a lot to push a new technology to =
>mainstream if it is possible to also use this technology without any =
>expensive hardware or complicated configurations? 

There will always be people/organisation who are different from mainstream.

For example, for the IPv6 setup I'm running at home there are no specs at all.

>1) A need for DHCPv6 right from the start and taking it into =
>consideration everywhere SLAAC was taken into consideration. E.g. is =

I have no idea where that went wrong. 

But SHOULD is a bit tricky in that context. If you assume that statefull
DHCPv6 is expensive (compare to SLAAC) and you want to support extremely
minimal devices, then SHOULD may just be a bit too strong.

>2) A better way to run SLAAC, SLAAC + Privacy Ext, DHCP and manual =
>addressing all on the same link *AND* same prefix in such a way, that it =
>is almost address conflict free without having to rely on ND to discover =
>conflicts (since ND will fail for hosts currently offline, but with =
>reserved addresses): Defining all addressing schemes in such a way, that =
>they don't interfere with each other under "normal" operation conditions =
>- of course MAC address conflicts are still possible, two nodes with =
>SLAAC + Priv Ext may also collide (only ND can avoid that) and =
>misconfiguration will always be possible; but I consider none of these =
>as normal operation conditions). Only two flags in 64 bit node addresses =

I'm not sure that a bit that distinguishes manual configuration from DHCP is
a good thing. SLAAC with EUID already has its bit.

So the only thing that remains is how much faith you have in a random number
generator. I think it is no problem, but we have to wait for large scale
deployment to see if that is justified.

>3) No M/O bits in router advertise messages. Every interface can have a =
>manually configured address, a DHCPv6 address, a SLAAC address, a SLAAC =
>w/ Priv Ext and that for every prefix it is aware of. The order of =
>preference for outgoing traffic is configurable, the default order is =
>defined in any RFC (e.g. I would suggest manual, DHCP, SLAAC w/ Priv =
>Ext, SLAAC).

Some people were worried about useless DHCP traffic. I'm not sure if that
is justified. But just setting those bits in the router config should be no
problem. That only leaves the case where there is no router. If everybody 
always sets those bits, then maybe routers will have them as standard.

>4) Considering DNS right from the start, since DNS is almost critical =
>for many networks as of today. If one of the IPv6 main design goal was =
>to allow the majority of networks to operate without a DHCP server (and =
>it looks as if it was, otherwise DHCPv6 would have been taken much more =
>into account), something like RFC 6106 (former 5006) was missing way too =
>long IMHO. Though I still fail to see the need for this RFC at all; I =
>had rather said that for simple setups that don't provide DNS servers =
>via DHCP, it would have been enough to have a well defined anycast or =
>even multicast address for DNS servers (I don't know any real life =
>network where DNS server addresses changes so frequently, that this =

There is a difference between statefull and stateless DHCPv6. I think NTP
is also pretty important.

This is just one of those things that have to be corrected based on real 
world experience. Unfortunately, the real world ignored IPv6 for 15 years.
So only now do those things get fixed.

---

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

On 2011-05-31, at 13:38 , Mohacsi Janos wrote:

> I disagree with introduction of another flags. This requires substantial changes in the codes.... Which will take ages....

I took a look at the IPv6 implementations of Mac OS X (which comes from the BSD world) and Linux a couple of weeks ago. Introducing such a second flag can be done with only a hand full of code lines and those can be written in about 30 minutes. Basically this flag only needs to be set for all SLAAC addresses, that's all there is to be done. We call this flag A, for automatically assigned, and keep the existing U flag, for globally unique. Then we have the following cases:

Manual (Static) Address: U = 0, A = 0
DHCP Address: U = 0, A = 0
SLAAC: U = 1, A = 1
SLAAC + Priv Ext: U = 0, A = 1

Now only DHCP and Static Addresses can collide and this would happen in case of a misconfiguration; it is impossible to prevent misconfigurations, so you shouldn't even try.

Right now SLAAC + Priv Ext can collide with Static/DHCP addresses (e.g. while the host is offline, ND will not detect such a collision and when the host goes online, it cannot get its address any longer, since it is taken by a SLAAC host). If we would define SLAAC + Priv Ext to set the U bit (which would be wrong, since these addresses are not globally unique), then it could collide with SLAAC addresses of hosts currently offline (again, ND will not work here and those host cannot go online later because their interface ID collides with an address already in use).

> We need M/O bits to give some sort of consistency.

May I ask what kind of consistency are you referring to?

> Nothing prevent you the suggest an draft document for multicast or anycast resolving DNS.

I consider it way too late to start such a project as of today. This should have been standardized already when the other well known multicast/anycast addresses were standardized.

> There is environment where SLAAC more acceptable - e.g. less adminisration

My home DSL router supports IPv6 and the difference between SLAAC and DHCPv6 is one checkbox; check it, and it runs a DHCPv6 server. There is nothing else you have to configure - you can configure address pools, static assignments, which DNS servers to hand out and other options, but you don't have to, if you don't feel like it. So I cannot really comprehend what is so hard about DHCP administration. Most routers/firewalls as of today have a build in DHCPv4 server and in the worst case, you'll have to enter a DNS server, create an address pool and enable it - not really a lot of administration work - in the best case, it will configure all of that automatically for you and you only have to customize settings if you feel like doing so (most home routers have DHCPv4 enabled and pre-configured, so for most users it means, plug your computer into the router or connect to the WLAN and it works out of the box, nothing to configure at all, except for internet access).

Regards,
Markus

---

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

> I would say that having an interface with two IPv4 addresses is not really in

Maybe it is rather uncommon, but it is allowed and also supported by all major operating systems; just wanted to point that out.

> minimal devices, then SHOULD may just be a bit too strong.

Is DHCPv6 more expensive than DHCPv4? Since even the most minimalistic device with IPv4 support I know of has DHCPv4 support; however, you  might be referring to devices even more minimalistic than what I have in mind. I just would like to point out, that I already wrote a DHCPv4 client myself (for a software project) - not fully featured, it only cares for an IP address, a subnet mask, DNS servers, DNS domain and the lease time, all other options are pretty much ignored - and I was surprised how little code I needed for that. It is pretty robust and so far worked well with every DHCP server we ever found. It even supports renewing the lease, though it does not fully implement the state-flow of the RFC (which seems over complicated IMHO). So a device that is not able to run such a simple client must be really, very, very minimalistic and my impression is that DHCPv6 is much simpler than DHCPv4, since it is not an extension to BOOTP (which makes DHCPv4 harder to implement than would otherwise be necessary).

> a good thing. SLAAC with EUID already has its bit.

I'm not advocating to make DHCP and manual configuration distinguishable, but to make SLAAC with Priv Ext distinguishable of DHCP and manual addresses:

> deployment to see if that is justified.

As a programmer, I don't believe in randomness but in predictability. You don't write code that  will only crash in one out of hundred billion cases if you can write code that will never crash for sure - even if the first case is so unlikely, that you may never see the code crash in your whole life.

However, we are losing the point here: With IPv6 I just fail to see the argument SLAAC vs DHCPv6, since there is no real reason IMHO for either/or and I fail to see how this is helpful if there are networks based on SLAAC and networks based on DHCPv6, this only adds unnecessary inconsistency. And people make it even worse by requesting a flag to control whether nodes may use privacy extension or not. Why not make it consistent: Every network is always SLAAC, even if there is a DHCP server, it is SLAAC. Privacy Extension is always possible to protect people's privacy if they feel like it. And only DHCP is optional, but when it is available, it does not replace SLAAC, it "completes" it and either hands out an IP address or not, but even when it hands out an IP address, it does not replace SLAAC. And thus I don't really see any need for an M or O flag in a RA message. Clients supporting DHCP will always try DHCP when a link comes up. Really, this traffic is so little compared to current network speeds, it's absolutely insignificant.

Regards,
Markus

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 31 May 2011 15:12:41 +0200 (CEST)

On Tue, 31 May 2011, Markus Hanauska wrote:

>> I disagree with introduction of another flags. This requires 
>> substantial changes in the codes.... Which will take ages....
>
> I took a look at the IPv6 implementations of Mac OS X (which comes from 
> the BSD world) and Linux a couple of weeks ago. Introducing such a 
> second flag can be done with only a hand full of code lines and those 
> can be written in about 30 minutes. Basically this flag only needs to be 
> set for all SLAAC addresses, that's all there is to be done. We call 
> this flag A, for automatically assigned, and keep the existing U flag, 
> for globally unique. Then we have the following cases:
>

I agree it can be written. Deployment of the code is another story. E.g. 
your cited Mac OS X example: RFC 3484 is written for BSD around 2003. The 
current Mac OS X still does not have it properly implemented.

> May I ask what kind of consistency are you referring to?

Consistency from administrator point of: Administrator have hint what is 
supplied with M/O bits: managed addresses via DHCP, other configuration 
information via DHCP.

> I consider it way too late to start such a project as of today. This 
> should have been standardized already when the other well known 
> multicast/anycast addresses were standardized.

Please write a draft.

> My home DSL router supports IPv6 and the difference between SLAAC and 
> DHCPv6 is one checkbox; check it, and it runs a DHCPv6 server. There is 
> nothing else you have to configure - you can configure address pools, 
> static assignments, which DNS servers to hand out and other options, but 
> you don't have to, if you don't feel like it. So I cannot really 
> comprehend what is so hard about DHCP administration. Most 
> routers/firewalls as of today have a build in DHCPv4 server and in the 
> worst case, you'll have to enter a DNS server, create an address pool 
> and enable it - not really a lot of administration work - in the best 
> case, it will configure all of that automatically for you and you only 
> have to customize settings if you feel like doing so (most home routers 
> have DHCPv4 enabled and pre-configured, so for most users it means, plug 
> your computer into the router or connect to the WLAN and it works out of 
> the box, nothing to configure at all, except for internet access).

Have a look at RFC 6204
http://tools.ietf.org/html/rfc6204
and join to the discussion of

http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-00

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 May 2011 15:26:12 +0200

In your letter dated Tue, 31 May 2011 14:45:24 +0200 you wrote:
>Is DHCPv6 more expensive than DHCPv4? Since even the most minimalistic =
>device with IPv4 support I know of has DHCPv4 support; however, you  =
>might be referring to devices even more minimalistic than what I have in =
>mind. 

I wasn't there. 

Similar arguments were repeated for the DNS option in the RA: a stateless
DHCPv6 query was too much hassle.

>As a programmer, I don't believe in randomness but in predictability. =
>You don't write code that  will only crash in one out of hundred billion =
>cases if you can write code that will never crash for sure - even if the =
>first case is so unlikely, that you may never see the code crash in your =
>whole life.

The question is, what do you gain? Do you expect an actual increase in
reliability? If there are many thing that can go wrong and are likely to
go wrong, then changing one possible fault from very unlikely to designed to
be impossible doesn't really contribute to the overall reliability of the
system.

>However, we are losing the point here: With IPv6 I just fail to see the =
>argument SLAAC vs DHCPv6, since there is no real reason IMHO for =
>either/or and I fail to see how this is helpful if there are networks =
>based on SLAAC and networks based on DHCPv6, this only adds unnecessary =
>inconsistency. And people make it even worse by requesting a flag to =
>control whether nodes may use privacy extension or not. Why not make it =
>consistent: Every network is always SLAAC, even if there is a DHCP =
>server, it is SLAAC. Privacy Extension is always possible to protect =
>people's privacy if they feel like it. And only DHCP is optional, but =
>when it is available, it does not replace SLAAC, it "completes" it and =
>either hands out an IP address or not, but even when it hands out an IP =
>address, it does not replace SLAAC. And thus I don't really see any need =
>for an M or O flag in a RA message. Clients supporting DHCP will always =
>try DHCP when a link comes up. Really, this traffic is so little =
>compared to current network speeds, it's absolutely insignificant.

You get turning SLAAC on and off for free (you need that flag to be able to 
mark a prefix as on-link without allowing hosts to use that prefix as source
address).

As far as I know, the ability to turn DHCPv6 on or off was based on the
amount of network traffic it would generate, so you also get that more of
less for free.

Privacy extension are tricky. The owner of the host and the owner of the
network may have conflicting interests. I'm sure that all network operators
would agree with hosts generally preferring addresses with privacy extensions.