Subject: [rfc2462bis] what is the stateful configuration protocol

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 13 Apr 2004 22:53:07 +0900

Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one
controversial issue is how clearly we should specify the stateful
address configuration protocol.

The question actually consists of the following two sub-questions:

Question A: how should rfc2462bis specify the stateful protocol?

possible answers:
  1. clearly say that stateful address configuration is DHCPv6
  2. (intentionally) do not say anything about this, and (implicitly
     or explicitly) leave it to the node requirements document

Question B: which references should rfc2462bis have on this matter?   

possible answers:
  X. add an informative reference to RFC3315
  Y. add an informative reference to node-req
  Z. add informative references to both RFC3315 and node-req
  W. do not add any references for this issue (neither RFC3315 nor node-req)

Opinions vary through the discussion on the mailing list.  The
followings are main of them I've seen:

Ralph Droms seems to prefer "1+X".
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01941.html

John Loughney agreed with Ralph (though he did not show strong opinion
of his own).
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01940.html

Bernie Volz also seems to prefer "1+X".
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01912.html

Dave Thaler seems to prefer "2+X" or "2+W".
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01918.html

I personally do not have a strong opinion, but we need to move forward
on this anyway.  If I need to make a choice, I'd also agree with
Ralph.  In fact, I don't see why we cannot be clear on this after the
publication of RFC3315.

Perhaps we might want to leave possibilities of future extensions
(including different "stateful" protocols than DHCPv6) by being
unclear.  But is this really a feasible reason?

On the other hand, if we keep being unclear, future readers will keep
wondering what is actually the stateful protocol or whether it's
just enough to implement DHCPv6, etc.  Even though the node
requirement document would be able answer the question, they'll have
to reach the document by themselves if we take Dave's suggestion.

Is there any other reason for not being clear on this (i.e., not
clearly say the stateful protocol is DHCPv6)?  Or is this just a
matter of preference?

Again, I myself can live with any resolution as long as we can move
forward.  So, any productive comments or suggestions are welcome.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 13 Apr 2004 23:42:46 +0900

>>>>> On Tue, 13 Apr 2004 22:53:07 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> address configuration protocol.

(forgot to mention this) in this message, I intentionally concentrated
on the stateful *address* configuration protocol.  We'll also need a
similar discussion about the stateful protocol for *other*
configurations.  However, things are much clearer for address
configuration and it would help to limit the discussion scope for not
making it unncessarily diverse.

					JINMEI, Tatuya

---

From: Alain Durand <[email-masked]>
Date: Tue, 13 Apr 2004 11:23:29 -0700

>     or explicitly) leave it to the node requirements document

1. We have DHCPv6. Let's just use it and stop confusing people
with the notion that there might be another stateful address 
configuration protocol.

>  W. do not add any references for this issue (neither RFC3315 nor node-req)

X. make it simple.

- Alain.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 13 Apr 2004 20:37:13 +0200

> clearly say the stateful protocol is DHCPv6)?  Or is this just a

I would prefer 2+Y. Simply to minimize dependencies...

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 13 Apr 2004 21:02:51 +0200

On 2004-04-13, at 20.37, Kurt Erik Lindqvist wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

After reading the first mail a bit closer...I am all for referring to 
DHCPv6, I was arguing for not making a direct reference to the RFC but 
rather to the node-req document.

- - kurtis -

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Apr 2004 06:48:57 -0400

Jinmei-san,

I think DHCPv6 ought to be cited as the protocol for other configuration
information, as well.

However, it seems to me the phrase "stateful protocol for *other*
configurations" is a little misleading.  I think the word "stateful" could
be dropped.

- Ralph

At 11:42 PM 4/13/2004 +0900, JINMEI Tatuya /

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Apr 2004 13:20:42 +0200

> configurations" is a little misleading.  I think the word "stateful" 

And terminally confuse everyone who has ever read RFC2462?

It seems to me that having one bit to indicate the protocol to be used 
for configuration isn't all that much. Why not expand both fields to 4 
bits, and then have the IANA maintain a registry? This could look 
something like:

0000        = RA
0001 - 0111 = TBD, fall back on RA (extra bits could be ignored as per 
RFC2641)
1000        = DHCPv6, handling of RA undefined
1001        = DHCPv6, RA is ignored
1010        = DHCPv6 + RA
1011 - 1111 = TBD

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Apr 2004 08:35:53 -0400

I suggest dropping "stateful" from the description because of the potential
for confusion inherent in providing a "stateful protocol for *other*
configurations" with "stateless DHCPv6" [RFC 3736].

This confusion arises from the unfortunate decision to differentiate
RFC 2462 address assignment from DHCP-based address assignment by
designating the former "stateless" and the latter "stateful".  That
difference is more accurately captured in RFC 2461bis by describing RFC 2462
address assignment as autonomous.  But, "stateless address
autoconfiguration" is the accepted phrase with wide dissemination at this
point...

In any event, perhaps the best way to simplify the protocol would be to drop
the "O" bit altogether.  That is, make no attempt to control how a host goes
about finding the additional configuration information.  There was a brief
discussion about this issue at an IPv6 WG interim meeting (Aug 2002?).  If
I remember correctly, and at the risk of over-simplification, the
point of the discussion was that, if I'm a network administrator, under what
circumstances would I ever want to set the 'O' bit so that a device does not
use all available mechanisms to obtain other configuration information?

- Ralph

At 01:20 PM 4/14/2004 +0200, Iljitsch van Beijnum wrote:
>It seems to me that having one bit to indicate the protocol to be used for 
>configuration isn't all that much. Why not expand both fields to 4 bits, 
>and then have the IANA maintain a registry? This could look something like:
>
>0000        = RA

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 Apr 2004 09:09:44 -0700

> I think DHCPv6 ought to be cited as the protocol for other 

This is the logical extension.

> configurations" is a little misleading.  I think the word "stateful" 

Hummm, what about a DHCPv6 server that would return different values of 
some config parameters
for different requesting nodes?

I think the whole notion of stateful vs stateless is a bit 
misleading/confusing anyway, so maybe you're right,
we should drop the word.

	- Alain.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Apr 2004 13:11:17 -0400

Followup on the meaning of "stateless" - one way to interpret "stateless" in
the context of DHCPv6 is: "does not require the maintenance of any dynamic
state for individual clients" (RFC 3736).  The server does, of course,
maintain configuration state and can make decisions about the response sent
to any specific client based on the server's configuration.  (And,
autonomous address assignment isn't "stateless" - the source of the RAs
maintains configuration state, the host maintains state about the addresses
it has selected.)  So, "stateless" really is 
misleading.  "Autonomous/managed" or "serverless/server-based" might be 
more correct...

- Ralph

---

From: Alain Durand <[email-masked]>
Date: Wed, 14 Apr 2004 11:02:56 -0700

On Apr 14, 2004, at 10:11 AM, Ralph Droms wrote:

> to any specific client based on the server's configuration.

Now  the words "dynamic state" introduce even more confusion.
A DHCPv6   server that has a pre-computed table to assign parameters
to client is then stateless, the same server that compute this 
dynamically
(maybe using a simple hash) is still stateless, but if that server 
decides
to cache this information, it becomes stateful...
And a router sending RAs that keeps track of who it send them to is
by this definition also stateful!

Clearly stateless vs stateful is the wrong way to describe the dichotomy
between RA & DHCP based configuration, and this vocabulary
should be removed from RFC2462.

> (And,
> it has selected.)  So, "stateless" really is misleading.  
> "Autonomous/managed" or "serverless/server-based" might be more 
> correct...

serverless/serverbased is incorrect too. A router sending and RA in 
response to an RS
is a server. Autonomous vs managed is IMHO the best terminology.

	- Alain.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Apr 2004 20:21:03 +0200

> designating the former "stateless" and the latter "stateful".

You can't fix this by pretending it didn't happen. This terminology has 
been in use since 1996, so if we want to get rid of it now we need to 
spell the issue out letter for letter.

> That
> address assignment as autonomous.

People may think you're talking about AS numbers...

> the "O" bit altogether.

I don't believe any host implementation that's already out there really 
cares about whether the O and M bits are set. So I guess deprecating 
either or both wouldn't really make any difference to existing 
implementations, and obviously not to non-existing ones either. Thus 
the question becomes: what is it that we want to accomplish? One thing 
we absolutely want is to skip DHCP if we know there is no DHCP server. 
Whether or not we care in advance whether a DHCP server is going to 
give us address information, additional config or both is something I 
can't answer, maybe someone who implements IPv6 in hosts can.

However, I think we might be painting ourselves in a corner by assuming 
RA and DHCP will be the only discovery/configuration options we'll ever 
need. *NOW* is the last time we get to change anything in this regard 
without having to deal with backward compatibility. As soon as OSes are 
released with DHCPv6 support this will no longer be the case.

Another thing that we may want to consider is a few bits that indicate 
to hosts whether any address/configuration information has changed. 
This way, connected hosts know they should initiate a new 
discovery/configuration cycle, and hosts that have been disconnected 
for a few moments, hours (even days?) know the configuration they used 
when they were last connected is still valid so they can immediately 
start communicating while going through a slower d/c cycle to refresh 
the info (to be on the safe side). This should also avoid configuration 
storms after outages.

> That is, make no attempt to control how a host goes
> about finding the additional configuration information.

So always try DHCP even if we know often there will be no DHCP server? 
This means people will have/want to turn off DHCP support manually to 
get rid of the delay and the unnecessary traffic. (IPv6 is already on 
the chatty side on the link anyway.)

---

From: Fred Templin <[email-masked]>
Date: Wed, 14 Apr 2004 11:23:20 -0700

> "Autonomous/managed" or "serverless/server-based" might be more 

If asked to vote on one of these two proposals, I would select
"autonomous/managed"; a node that is "autonomous" in terms
of address configuration might be a "server" for some other
function unrealted to address configuration.

Fred
[email-masked]

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 15 Apr 2004 17:28:23 +0900

> Question A: how should rfc2462bis specify the stateful protocol?

Thank you all who responded.  On this particular topic, the consensus
in this thread seems that we should

  1. clearly say that stateful address configuration is DHCPv6
and
  X. add an informative reference to RFC3315 (but not to the node-req
     document) 

I know there was a different opinion, particularly on the first point,
to reduce dependencies, but the number of people supporting the idea
of 1+X seems sufficiently large to make a decision.  I hope others can
accept this path.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 15 Apr 2004 19:55:07 +0900

>>>>> On Wed, 14 Apr 2004 06:48:57 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> configurations" is a little misleading.  I think the word "stateful" could

You're running too fast despite the prior notice:-) But anyway, this
thread is surely useful for rfc2462bis.  Thanks for raising this
topic.

(I won't try to make a response to each follow-up in this sub-thread,
but I've read all of them.)

It seems to me that we are discussing two (almost) different issues:

1. whether "stateless" is an appropriate word to describe the address
   autoconfiguration mechanism specified in RFC2462 (and bis)
2. whether we need the M/O flags in the first place

Regarding issue 1, I personally think "stateless" is appropriate, at
least in the sense that we don't have to reword it in rfc2462bis.

In fact, RFC2462 clearly says what "stateless" means in that
document.  For example, it says in Introduction:

   Stateless autoconfiguration requires no manual
   configuration of hosts, minimal (if any) configuration of routers,
   and no additional servers.

which means it's a "third-party-serverless" mechanism.  Also, the
following sentence clearly shows that it is an "autonomous"
configuration mechanism:

   The stateless mechanism allows a host to
   generate its own addresses using a combination of locally available
   information and information advertised by routers.

If we are making a brand-new specification, it might make sense to
reconsider the wording from the scratch.  However, "stateless address
autoconfiguration" has been used for quite a long period (almost for
10 years?), and is used in many documents, including in the title of
RFC2462 itself.

So, I don't think the advantage of rewording is worth the expected
confusion.

Issue 2 is a big question...it may even affect the "consensus" we just
made in the first (and original) part of this thread.  I'm going to
make a separate thread for this.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Thu, 15 Apr 2004 07:45:04 -0400

Jinmei-san - I distracted the conversation a little with my posting ... I
think we have come to consensus as you describe in
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg02280.html
and we can consider the question of "how clearly we should specify the
stateful address configuration protocol" closed.  "stateless address
autoconfiguration" is the widely-accepted term and there is no need to
change it.

I had intended only to make the suggestion that "stateful" be dropped from
the phrase "other stateful configuration" (in RFC 2461) , because of the
potential confusion between "other stateful configuration" and "stateless
DHCP" (in RFC 3736).  There is also potential confusion because there is
no "stateless" counterpart to "other stateful configuration".

I also wanted to recall a conversation that taken place at the IPv6 interim
meeting about the usefulness of the 'O' bit ... however, if this
conversation is out-of-scope to the revision of RFC 2461, that's fine and we
can drop it.

- Ralph

At 07:55 PM 4/15/2004 +0900, JINMEI Tatuya /

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 15 Apr 2004 21:46:46 +0900

>>>>> On Thu, 15 Apr 2004 07:45:04 -0400, 

> no "stateless" counterpart to "other stateful configuration".

Okay, thanks for the clarification.  I had actually intended to
propose a similar change, but the discussion have started earlier than
I expected:-)

> conversation is out-of-scope to the revision of RFC 2461, that's fine and we

(You meant the revison of RFC 2462?)  I think it is in the scope of
this work, but do you have a concrete reference to the conversation?
Which interim meeting are you talking about?  The latest ipv6 interim
meeting I remember is the one held in Sep/Oct 1999.  I've roughly gone
through the meeting minutes at 
http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-Sep99.txt
but I could not find a discussion relevant to this topic.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 15 Apr 2004 22:14:33 +0900

>>>>> On Thu, 15 Apr 2004 21:46:46 +0900, 

> but I could not find a discussion relevant to this topic.

Sorry, I was not careful enough: the latest one should be the one in
May/Jun 2001.  I do remember the meeting, but in my poor memory it was
an ngtrans interim meeting (not a joint meeting).  Still, I could not
find a useful reference from the minutes:
http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt

					JINMEI, Tatuya