Subject: Re: Short 6MAN WG Last Call: <draft-ietf-6man-node-req-bis-09.txt>

From: Ole Troan <[email-masked]>
Date: Thu, 5 May 2011 15:49:03 +0200

I'm on the fence with regards to this document. if this document is meant to be the RFC1122/1812 document for IPv6,
I think we are too early in the deployment of IPv6 to have gathered enough experience with what works and what doesn't.
as a profile of an IPv6 node though, it isn't too far off.

a couple of comments:

* section 5.3.  Default Router Preferences and More-Specific Routes - RFC 4191
  this is a "MAY wish" and in conflict with RFC6204, L-3.
  please make this a SHOULD or even a MUST (as hosts not supporting it will not be able to interoperate on networks behind
  RFC6204 routers.

* RFC2675: I would just remove that.

* 5.9.4 Default Address Selection
  As RFC3484 generates IPv6 brokenness. I think we should change this reference to RFC3484bis.

* 5.9.5.  Stateful Address Autoconfiguration
  I still disagree with the MAY for DHCP. I don't think we should state the 'at the present time SLAAC'.
  hosts that cannot do DHCP for address assignment may not be able to connect to many cable networks (see DOCSIS 3)
  and access networks specified by the BBF.

* 6 DHCP vs. Router Advertisement Options for Host Configuration
  I don't understand the purpose of this section.
  it should include text explaining how to handle conflicts between multiple mechanisms if anything.
  and make it clear that every node has to implement all mechanisms. that's the natural consequence
  of designing multiple ways of doing the same thing.

* 8.1.  Transition Mechanisms
  Just remove the section. it doesn't add value.

* 12.1.1 Router Alert
  not just acknowledge that the HBH option was a bad idea and nuke it?

cheers,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 May 2011 10:30:55 -0700

Ole,

> as a profile of an IPv6 node though, it isn't too far off.

This is, of course, and update the the current Node Requirements as define in RFC4294.  Weither it is the last update, is anyones guess, but I think it clearly better to update it now as we know there are many things that are wrong with RFC4294.

I would also note that RFC1122 was written in 1989 and RFC1812 in 1995.  Neither of those reflect current practice with IPv4.  We might be at the same point of deployment with IPv6 as IPv4 was in 1989 :-)

Bob

---

From: <[email-masked]>
Date: Thu, 5 May 2011 17:35:04 +0000

I agree with Bob.  Also, the world is a bit different than in 1989 and 1995.  There are a lot of organizations creating different IPv6 'profiles', 'certifications' and guidelines.  I think it has always been our intention to use the Node Requirements to provide some guidelines from the IETF point of view. We can review some  of your specific comments, though.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bob Hinden
Sent: Thursday, May 05, 2011 10:31 AM
To: Ole Troan
Cc: 6man Mailing List; Brian Haberman; Bob Hinden
Subject: Re: Short 6MAN WG Last Call: <draft-ietf-6man-node-req-bis-09.txt>

Ole,

On May 5, 2011, at 6:49 AM, Ole Troan wrote:

> I'm on the fence with regards to this document. if this document is 
> meant to be the RFC1122/1812 document for IPv6, I think we are too early in the deployment of IPv6 to have gathered enough experience with what works and what doesn't.

Bob

> 
> a couple of comments:
> 
> * section 5.3.  Default Router Preferences and More-Specific Routes - 
> RFC 4191  this is a "MAY wish" and in conflict with RFC6204, L-3.
>  please make this a SHOULD or even a MUST (as hosts not supporting it 
> will not be able to interoperate on networks behind
>  RFC6204 routers.
> 
> * 5.9.5.  Stateful Address Autoconfiguration  I still disagree with 
> the MAY for DHCP. I don't think we should state the 'at the present time SLAAC'.
>  hosts that cannot do DHCP for address assignment may not be able to 
> connect to many cable networks (see DOCSIS 3)  and access networks specified by the BBF.
> 
> * 6 DHCP vs. Router Advertisement Options for Host Configuration  I 
> don't understand the purpose of this section.
>  and make it clear that every node has to implement all mechanisms. 
> that's the natural consequence  of designing multiple ways of doing the same thing.
> 

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

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 May 2011 13:48:19 -0400

Hi Ole.

Thanks for the review!

> meant to be the RFC1122/1812 document for IPv6, I think we are too
> early in the deployment of IPv6 to have gathered enough experience
> with what works and what doesn't.  as a profile of an IPv6 node
> though, it isn't too far off.

As Bob says, this  is a revision of an existing document. Its a much
more current set of recommendations than RFC 4294.

>   please make this a SHOULD or even a MUST (as hosts not supporting it will not be able to interoperate on networks behind

I'm not entirely sure what to do here. RFC 4191 is not widely
implemented, AFAIK. It's in Windows Vista (and onwards) and also
Linux. Not sure where else (I'm guessing not on Macs?)

So, I'm not at all sure we should recommend it as a SHOULD. IMO, its
not a crucial document, and its not widely implemented.

Can someone explain to me the rationale for mandating 4191 in 6204?
What was the scenario that was envisioned that necessitates 4191? 

> * RFC2675: I would just remove that.

The docuent currently says:

      IPv6 Jumbograms [RFC2675] MAY be supported.

How about I replace that with:

      IPv6 Jumbograms [RFC2675] are an optional extension that allow
      the sending of IP datagrams larger than 65.535 bytes.  IPv6
      Jumbograms make use of IPv6 hop-by-hop options and are only
      suitable on paths in which every hop and link are capable of
      supporting Jumbograms (e.g., within a campus or datacenter). To
      date, few implementations exist and there is essentially no
      reported experience from usage. Consequently, IPv6 Jumbograms
      [RFC2675] remain optional at this time.

(key change is "MAY" to just lower case "optional").      

>   this reference to RFC3484bis.

Can't do that. That would delay publication of the RFC.

BTW, you could make the same arguement w.r.t. the Flow Label. And
possibly other things that are still in revision...

>   state the 'at the present time SLAAC'.

Note: full quote is:

      At the present time, the configuration of stateless address
      autoconfiguration is more widely implemented in hosts than
      address configuration through DHCP.

This would appear to be statement of fact. (And on rereading it, I
would suggestion changing the sentence to: 

      At the present time, the configuration of addresses via
      stateless autoconfiguration is more widely implemented in hosts
      than address configuration via DHCP.

>   hosts that cannot do DHCP for address assignment may not be able
>   to connect to many cable networks (see DOCSIS 3)

Is this true for *end user* hosts at behind a DOCSYS modem?  I believe
not. 

> and access networks specified by the BBF.

IMO, the day of having CPE devices support bridging are gone. It is
perfectly fine to require the use of a router rather than allowing end
clients to connect directly. Such routers could be required to
implement DHC. But you can't reasonably expect all client end devices
to support it. We missed the boat on that years ago.

>   I don't understand the purpose of this section.

It is a bit of history/background.

>   it should include text explaining how to handle conflicts between
    multiple mechanisms if anything.

The existing specifications already  address this. This document has
nothing to add.

>   and make it clear that every node has to implement all
>   mechanisms. that's the natural consequence of designing multiple
>   ways of doing the same thing.

The WG has not been willing to do that. Unless something has changed
recently, I do not see support for elevating DHC support beyond MAY
(for addresses anyway).

>   Just remove the section. it doesn't add value.

I agree there  isn't much there, but for completeness, I think it
should stay.

>   not just acknowledge that the HBH option was a bad idea and nuke it?

Not sure what your point is here. HBH options are mandatory to
implement at this time. Way to late to deprecate them. Neighbor
Discovery depends on it (i.e., MLD mandates it, and you need MLD for
ND).

Thomas

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 May 2011 20:54:26 +0200

Thomas,

> more current set of recommendations than RFC 4294.

please let me withdraw that comment. off the cuff remark.

> What was the scenario that was envisioned that necessitates 4191? 

it was the only way we found to keep support for ULA prefixes.
the scenario is if you have a home CPE with ULA enabled, but no upstream IPv6 connectivity.
if that router advertises itself as a router for default, as opposed to router for ULA, host implementations
that don't do 3484bis, and don't handle ICMPs, will contribute to IPv6 breakage. e.g. 75 second time outs per TCP connection.

> (key change is "MAY" to just lower case "optional").      

I'm fine with that.
the reason I brought it up is because we have people (aka customers) asking us for support for this. and it has so far in every case been either because of mixing it up with jumbo frames, or not understanding what it is.

> possibly other things that are still in revision...

while it isn't correct to say that rfc3484 contributes to IPv6 breakage, I would very much like a reference to something that actually helps.
is it urgent to get the node requirements document out? I thought 3484-revise was quiet far along in the process.
chairs?

>      than address configuration via DHCP.

that statement will be true as long as there exists a single host on the planet that doesn't do DHCPv6.
assuming they all do SLAAC. ;-)

> Is this true for *end user* hosts at behind a DOCSYS modem?  I believe

yes, it is. a DOCSIS modem is a bridge. with a router it is OK obviously.

> to support it. We missed the boat on that years ago.

I disagree.
the consequence is that hosts that not support DHCP, will just not get service.
that's pretty bad, and I think the prudent approach would be to have SLAAC as a MUST and stateful as a SHOULD.
after all you have the following text that states:

   "However, some environments may require the use of DHCP and may not support the
   configuration of addresses via RAs."

that is a pretty severe interoperability problem.
I'm happy that 6106 is a SHOULD, but if you are looking for implementations for that option you have to look very hard "at the present time".
basically I want the document to say that IETF has standardised two mechanisms to configure hosts. one using ND and one using DHCP. as they apply to different management models, nodes SHOULD implement both. (and add suitable apologies to the world for having messed this up badly. ;-))

> It is a bit of history/background.

I would be happier if it included text stating the above.

> The existing specifications already  address this. This document has

does it in the general case?
i.e. that if you get one address from SLAAC and one from DHCPv6 the result is two addresses.
same with DNS options and so on. do you have a reference?

> recently, I do not see support for elevating DHC support beyond MAY

we are making solutions depending on DHCP support:
draft-ietf-mif-dhcpv6-route-option
draft-ietf-6man-addr-select-opt
...

> I agree there  isn't much there, but for completeness, I think it

OK.

> Discovery depends on it (i.e., MLD mandates it, and you need MLD for

if ipv6->next_header == 0
 plonk ?

OK, I will not argue the point further. packets with HBH headers will be severely rated limited anyway...

cheers,
Ole

---

From: <[email-masked]>
Date: Fri, 6 May 2011 17:54:39 +0000

Thomas,

One small comment and one small nit, inline:

> BTW, you could make the same arguement w.r.t. the Flow Label. And possibly other things that are still in revision...

COMMENT: I think we have general agreement in the WG that IPv6 will still be evolving for some time, and we fully expect that more updates to the Node Requirements will be needed, so waiting for all changes would be pointless.

> This would appear to be statement of fact. (And on rereading it, I would suggestion changing the sentence to: 
> 

NIT: Would it make sense to change "At the present time, ..." with "At the time of publication of this document, ..."

Otherwise, I agree with your comments.

John

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 May 2011 12:58:01 -0700

At Fri, 06 May 2011 13:48:19 -0400,

> Linux. Not sure where else (I'm guessing not on Macs?)

(I'm not sure if the following information is really relevant to the
discussion context, but am providing some fact in case it does.)

Many major BSD variants (including FreeBSD) have been supporting the
host part of default router preferences (but not more specific routes)
for quite a long time (according to the source code repository, this
feature was incorporated to FreeBSD in October 2005).  I don't know
the details of MacOS X on this point (or I'm so lazy that I've not
checked its behavior using my laptop), but it at least seems to
recognize the preference value:

% ndp -r
fe80::230:48ff:feb9:9a5c%en0 if=en0, flags=, pref=medium, expire=23m7s
(note the "pref" field)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 9 May 2011 16:58:52 -0700

Thomas,

My personal observation, if it's implemented in Windows Vista & WIn7, Linux, BSD, (and probably Macs), then this sounds like widely implemented.  This plus Ole's use scenario, leads me to think it should be a SHOULD.  

Bob

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 May 2011 20:15:58 -0400

> My personal observation, if it's implemented in Windows Vista &
>  WIn7, Linux, BSD, (and probably Macs), then this sounds like widely
>  implemented.  This plus Ole's use scenario, leads me to think it
>  should be a SHOULD.

I could probably go with a SHOULD.

But, I wonder if we are living in the past using the above as
representative of implementations.

When are we going to start counting cell phones, tablets and other
electronic devices?

I've seen various stats that say traditional PCs will be a minority of
devices accessing the Internet sometime this year.

(Of course, the overall percentage of such devices with IPv6 makes the
argument sort of moot, but that's a detail...)

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Mon, 9 May 2011 17:24:05 -0700

Thomas,

> argument sort of moot, but that's a detail...)

To put it another way, if we think there is a good use case for this as Ole describes, we will be doing a service to the devices that don't have their IPv6 code yet, to make it a SHOULD so they are more likely to implement it.

Agree?

Bob

---

From: Fred Baker <[email-masked]>
Date: Mon, 9 May 2011 17:37:03 -0700

On May 9, 2011, at 5:15 PM, Thomas Narten wrote:

> When are we going to start counting cell phones, tablets and other electronic devices?

When they start implementing IPv6 at all...

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 May 2011 20:49:26 -0400

> it was the only way we found to keep support for ULA prefixes.  the
> scenario is if you have a home CPE with ULA enabled, but no upstream
> IPv6 connectivity.  if that router advertises itself as a router for
> default, as opposed to router for ULA, host implementations that
> don't do 3484bis, and don't handle ICMPs, will contribute to IPv6
> breakage. e.g. 75 second time outs per TCP connection.

Seems to me, the real issue is the following (from RFC 6204):

   G-4:  By default, an IPv6 CE router that has no default router(s) on
         its WAN interface MUST NOT advertise itself as an IPv6 default
         router on its LAN interfaces.  That is, the "Router Lifetime"
         field is set to zero in all Router Advertisement messages it
         originates [RFC4861].

   G-5:  By default, if the IPv6 CE router is an advertising router and
         loses its IPv6 default router(s) on the WAN interface, it MUST
         explicitly invalidate itself as an IPv6 default router on each
         of its advertising interfaces by immediately transmitting one
         or more Router Advertisement messages with the "Router
         Lifetime" field set to zero [RFC4861].

That is, a CPE router with multiple LAN interfaces is not allowed to
advertise itself as a default router (when it loses internet
connectivity), when that is arguably a fine thing for it to do.

I have to wonder whether RFC 6204 has gotten this wrong. It is very
CPE centric, assuming it is the only router on the home network. It
has conflated the notion of a router being fine as a default router
for the hosts attached to the same link (i.e., via RAs) and the the
more traditional router notion of default route.

I.e., if the CPE router has multiple LAN interfaces, each with a ULA
(or other prefix) assigned to it, advertising itself as a default
router seems like a perfectly reasonable thing to do.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Mon, 9 May 2011 18:02:35 -0700

> When they start implementing IPv6 at all...

iOS and Symbian appear to do IPv6 pretty well.  I think iOS is ahead of MacOS as it get's updated more often.  Not sure about Android, Win7 phone, and the others.

Bob

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 10 May 2011 12:12:19 +1000

>iOS and Symbian appear to do IPv6 pretty well.  I think iOS is ahead of
>MacOS as it get's updated more often.

=> They do but I'm not sure that they support it over 3G. I.e., the IPv6
stack is there and functional over WLAN but for some reason (I'm guessing
licensing issues related to the 3G chipset) they don't support PDP context
IPv6 when I last checked. I'm not talking about Symbian, just iOS

>  Not sure about Android, Win7 phone, and the others.

=> They do over wlan, same problem with 3G. I don't know about blackberry,
sonyericsson ...etc.

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 May 2011 07:48:06 +0200 (CEST)

On Mon, 9 May 2011, Bob Hinden wrote:

> MacOS as it get's updated more often.  Not sure about Android, Win7 
> phone, and the others.

Android 2.3.4 actually has GUI options to configure IPv6 APN, but we have 
yet to find a phone we can get it working with. Right now we presume it's 
a baseband issue on the phones we have available.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 May 2011 09:59:49 +0200

Thomas,

> router seems like a perfectly reasonable thing to do.

indeed, but unfortunately that causes IPv6 breakage. this is not at all CPE centric, from the CPE perspective advertising itself as a default router is obviously not an issue. the problem is host implementations that have a ULA address and a default route (but no connectivity to the IPv6 Internet). these hosts will choose IPv6 first when connecting to dual-stack destinations, this leads to multi-minute time outs.

we had some very extensive discussions on this exact point during the last call of RFC6104.
I hope we do not have to rehash those here.

cheers,
Ole

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 May 2011 17:12:55 -0400

> indeed, but unfortunately that causes IPv6 breakage. this is not at
>  all CPE centric, from the CPE perspective advertising itself as a
>  default router is obviously not an issue. the problem is host
>  implementations that have a ULA address and a default route (but no
>  connectivity to the IPv6 Internet). these hosts will choose IPv6
>  first when connecting to dual-stack destinations, this leads to
>  multi-minute time outs.

Let me be sure I understand. Which 3484 rule comes into play that has
an impact here? Is it:

   Rule 1:  Avoid unusable destinations.
   If DB is known to be unreachable or if Source(DB) is undefined, then
   prefer DA.  Similarly, if DA is known to be unreachable or if
   Source(DA) is undefined, then prefer DB.

I.e., if trying to reach a site, and the IPv6 address is "unreachable"
per above, choose the v4 address? (Sounds great in theory!). So the
CPE rule that says you MUST NOT advertise yourself as a default router
if you don't have real IPv6 connectivity is intended to result in all
destinations (other than local ones) showing up as  "unreachable" when
the above rule happens?

Is this the intention, or am I looking at the wrong scenario here?

> we had some very extensive discussions on this exact point during
> the last call of RFC6104.  I hope we do not have to rehash those
> here.

I'll try not to. :-)

Thomas

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 May 2011 23:19:06 +0200

Thomas,

> Is this the intention, or am I looking at the wrong scenario here?

that is indeed the intention.
this also appears to work well regardless of a node implementing 3484 or not.

>> the last call of RFC6104.  I hope we do not have to rehash those

thanks. ;-)

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 May 2011 07:46:28 +0930

Hi Thomas,

On Wed, 11 May 2011 17:12:55 -0400

> Is this the intention, or am I looking at the wrong scenario here?

I think what caught people a bit was a particular CPE which doesn't
generate an ICMPv6 destination unreachable when the default IPv6 route
disappeared or wasn't present (or didn't at the time - this caused my
employer's customers a lot of grief when we started shipping IPv6
enabled by default in them). I tested this scenario with another CPE
that did generate ICMPv6 destination reachables when the default route
disappeared, and found that my end-node immediately reverted to using
IPv4 when both AAAAs and As were available and the AAAA was offsite.

However, as generating ICMPv6 dest unreachables is a SHOULD, not a
MUST, and they can be rate limited, it seems to me that using RA RIOs to
convey local IPv6 topology to end nodes is a more robust way of
trying to ensure local IPv6 reachability across local subnets when the
offsite default route disappears. So I agree with making supporting
them a node requirement.

Regards,
Mark.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 12 May 2011 09:09:36 -0400

> To put it another way, if we think there is a good use case for this
>  as Ole describes, we will be doing a service to the devices that
>  don't have their IPv6 code yet, to make it a SHOULD so they are
>  more likely to implement it.

Here is some proposed text:

   5.3.  Default Router Preferences and More-Specific Routes - RFC 4191

   "Default Router Preferences and More-Specific Routes" [RFC4191]
   provides support for nodes attached to multiple (different) networks
   each providing routers that advertise themselves as default routers
   via Router Advertisements.  In some scenarios, one router may provide
   connectivity to destinations the other router does not, and choosing
   the "wrong" default router can result in reachability failures.  In
   such cases, RFC4191 can help.

   Small Office/Home Office (SOHO) deployments supported by routers
   adhering to [RFC6204], use [RFC4191] to advertise routes to certain
   local destinations.  Consequently, nodes that will be deployed in
   SOHO environments SHOULD implement [RFC4191].

Thoughts?

Thomas

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 May 2011 15:20:30 +0200

>   SOHO environments SHOULD implement [RFC4191].

I think that looks very good.

cheers,
Ole

---

From: Thomas Narten <[email-masked]>
Date: Thu, 12 May 2011 09:23:20 -0400

Ole,

Getting back to some of your other points...

> the reason I brought it up is because we have people (aka customers)
>  asking us for support for this. and it has so far in every case
>  been either because of mixing it up with jumbo frames, or not
>  understanding what it is.

Understood. One of the goals of this version of the document is to
make sure that there is real guidance, and not just "you SHOULD do
this". If there is guidance, hopefully people will think a little bit
more before asking vendors to implement something that does not appear
to be needed in practice...

> I disagree.  the consequence is that hosts that not support DHCP,
> will just not get service.  that's pretty bad, and I think the
> prudent approach would be to have SLAAC as a MUST and stateful as a
> SHOULD.  after all you have the following text that states:

>    "However, some environments may require the use of DHCP and may
>    not support the configuration of addresses via RAs."

> that is a pretty severe interoperability problem.  I'm happy that
> 6106 is a SHOULD, but if you are looking for implementations for
> that option you have to look very hard "at the present time".
> basically I want the document to say that IETF has standardised two
> mechanisms to configure hosts. one using ND and one using DHCP. as
> they apply to different management models, nodes SHOULD implement
> both. (and add suitable apologies to the world for having messed
> this up badly. ;-))

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.

But that is not a new argument, and isn't any different today than it
was ten years ago. And over the years, the WG has not always been
particularly friendly towards DHCv6. It's only in the last few years
that there has been an acceptance that DHCPv6 will actually get used
on some deployments (by operator choice).

However, I do not see evidence that the WG has changed its thinking
and would now be willing to make implementation of DHCP a SHOULD.

Unless this changes, I will leave the text as is.

Thomas

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 May 2011 19:55:52 +0200

> MAY.

thank you

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 May 2011 08:52:21 +1200

On 2011-05-13 01:23, Thomas Narten wrote:
...
> addrconf OR DHCP, they only have that choice of devices widely

+1

> was ten years ago. 

I think it is, and it certainly is if you make that "fifteen years ago"
when DHCP(v4) was operationally young and the IPv6 design did not
assume the existence of DHCPv6.

There will, I'm sure, be many scenarios in the future where SLAAC is
just fine; but it's time for DHCPv6 to be a first-class citizen.

  Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 May 2011 07:24:55 +0930

On Thu, 12 May 2011 15:20:30 +0200

+1

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 May 2011 07:37:29 +0930

Hi Thomas,

On Thu, 12 May 2011 09:23:20 -0400

> and would now be willing to make implementation of DHCP a SHOULD.

I think it would be reasonable to make DHCP a SHOULD, however
I've thought that one of the reasons SLAAC exists is to provide
simpler and lighter weight address configuration method for resource
constrained end-nodes such as embedded ones. So perhaps it could be
worth mentioning that an example of an exception to the SHOULD would be
those types of end-nodes.

Regards,
Mark.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 12 May 2011 17:22:05 -0500

> those types of end-nodes.

More generally, I'd say SLAAC exists because with IPv6 it's possible to assign globally unique IP addresses to hosts, without risk of collisions, without having to have the network specify all of the 128 bits.

But in situations where the address provided to a host must be completely predictable, SLAAC won't work.

I don't think that resource-constrained need to be a significant criterion?

Bert

---

From: Doug Barton <[email-masked]>
Date: Thu, 12 May 2011 15:40:13 -0700

> I don't think that resource-constrained need to be a significant criterion?

Rather than trying to enumerate all the reasons that it might be one or 
the other, how about language to the effect of:

If building a special-purpose device for use on a network where only 
RA/SLAAC is allowed then implementors MAY omit DHCPv6 support. Otherwise 
DHCPv6 SHOULD be provided.

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: Sat, 14 May 2011 09:24:33 +0930

Hi Bert,

On Thu, 12 May 2011 17:22:05 -0500

> I don't think that resource-constrained need to be a significant criterion?

I'd thought that SLAAC was created instead of just making an IPv6
equivalent of DHCPv4 and leaving that as a single address
configuration mechanism was because it required less maintained state
and processing. Less maintained state and processing would best suit low
CPU powered and memory devices, which is why I suggested "loosening"
the SHOULD for DHCPv6 a bit for those devices. SLAAC is of course
convenient in other situations too.

Regards,
Mark.