Subject: [rfc2462bis] summary and proposal about the M/O flags

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 24 May 2004 20:23:35 +0900

All,

Thanks for the feedback on this subject so far.

I think we are now approaching a consensus, so here is a summary of
resolution.

- keep the M/O flags
- clearly specify the protocols for the flags: RFC3315 for M and
  RFC3736 for O
- clarify (change) the meaning of the M/O flags; they are just hints
  of availability of the corresponding services, not triggers for
  invoking the protocols under a certain level of requirement
- remove or reword "requirements" regarding these flags according to
  the above change
- remove ManagedFlag and OtherConfigFlag, which were
  implementation-internal variables in RFC2462 tightly depending on
  the "requirement" nature of the M/O flags
- clarify the possible confusion coming from the fact that RFC3736
  calls itself "stateless" while rfc2462bis uses "stateful"
- leave the actual usage of the M/O flags will be used to a separate
  document.  rfc2462bis mentions the other document

The followings are the specific changes I'd propose.  These are just a
draft of draft, but would be very close to the final text (unless I
get serious comments).  I'm referring to rfc2462bis-00 as the "old"
text, but it should not be so different from RFC2462 on this matter.

1. revise abstract as follows:

   [...] The autoconfiguration
   process includes creating a link-local address and verifying its
   uniqueness on a link, determining what information should be
   autoconfigured (addresses, other information, or both), and in the
   case of addresses, whether they should be obtained through the
   stateless mechanism, the stateful mechanism, or both.  [...]
   [...] The
   details of autoconfiguration using the stateful protocol are
   specified elsewhere.

To:

   [...] The autoconfiguration
   process includes creating a link-local address and verifying its
   uniqueness on a link, determining what information can be
   autoconfigured (addresses, other information, or both), and in the
   case of addresses, whether they can be obtained through the
   stateless mechanism, the stateful mechanism, or both.  [...]
   [...] The
   details of autoconfiguration using the stateful protocol is
   specified in RFC3315 and RFC3736.

2. same change as the previous one to the first paragraph of Section
   1.

3. Revise the third paragraph of Section 1 to:

   In the stateful autoconfiguration model, hosts obtain interface
   addresses and/or configuration information and parameters from a
   DHCPv6 server.  Servers maintain a database that keeps track of which
   addresses have been assigned to which hosts. The stateful
   autoconfiguration protocol allows hosts to obtain addresses, other
   configuration information or both from a server.  Stateless and
   stateful autoconfiguration complement each other. For example, a host
   can use stateless autoconfiguration to configure its own addresses,
   but use stateful autoconfiguration to obtain other information.

4. add the following paragraph between the third and fourths
   paragraphs of Section 1:

   To obtain other configuration information without configuring
   addresses in the stateful autoconfiguration model, a subset of
   DHCPv6 will be used [RFC3736].  While the model is called
   "stateful" in order to highlight the contrast to the stateless
   protocol defined in this document, the intended protocol is also
   defined to work in a stateless fashion.  This is based on a result,
   through operational experiments, that all known "other"
   configuration information can be managed by a stateless server,
   that is, a server that does not maintain state of each client that
   the server provides with the configuration information.

5. revise the last sentence of the (current) fourth paragraph of
   Section 1:

   [...] The site administrator specifies which type of
   autoconfiguration to use through the setting of appropriate fields in
   Router Advertisement messages [5].

To:

   [...] The site administrator specifies which type of
   autoconfiguration is available through the setting of appropriate
   fields in Router Advertisement messages [5].

6. revise the last bullet of the list in Section 3:

   o  System administrators need the ability to specify whether
      stateless autoconfiguration, stateful autoconfiguration, or both
      should be used.  Router Advertisements include flags specifying
      which mechanisms a host should use.

To:

   o  System administrators need the ability to specify whether
      stateless autoconfiguration, stateful autoconfiguration, or both
      is available.  Router Advertisements include flags specifying
      which mechanisms a host can use.

7. revise the fifth paragraph of Section 4 (page 9) as follows:

   The next phase of autoconfiguration involves obtaining a Router
   Advertisement or determining that no routers are present. If routers
   are present, they will send Router Advertisements that specify what
   sort of autoconfiguration a host should do.  If no routers are
   present, stateful autoconfiguration should be invoked.

To:

   The next phase of autoconfiguration involves obtaining a Router
   Advertisement or determining that no routers are present. If routers
   are present, they will send Router Advertisements that specify what
   sort of autoconfiguration a host can do.  When no routers are
   present, stateful autoconfiguration may be available.

8. revise the sixth paragraph of Section 4 as follows:

   [...]  Router Advertisements contain
   two flags indicating what type of stateful autoconfiguration (if any)
   should be performed. A "managed address configuration" flag indicates
   whether hosts should use stateful autoconfiguration to obtain
   addresses. An "other stateful configuration" flag indicates whether
   hosts should use stateful autoconfiguration to obtain additional
   information (excluding addresses).

To:

   [...]  Router Advertisements contain
   two flags indicating what type of stateful autoconfiguration (if any)
   is available. A "managed address configuration (M)" flag indicates
   whether hosts can use stateful autoconfiguration [RFC3315] to obtain
   addresses. An "other stateful configuration (O)" flag indicates whether
   hosts can use stateful autoconfiguration [RFC3736] to obtain additional
   information (excluding addresses).

9. add the following to the end of the previous part:

     The details of how a host may use the M flags, including any use
     of the "on" and "off" transitions for this flag, to control the
     use of the stateful protocol for address assignment will be
     described in a separate document.  Similarly, the details of how
     a host may use the O flags, including any use of the "on" and
     "off" transitions for this flag, to control the use of the
     stateful protocol for getting other configuration information
     will be described in a separate document.

10. remove the definitions of ManagedFlag and OtherConfigFlag from
    Section 5.2 (page 12).  We'll also need to adjust the wording
    around the definition.

11. revise Section 5.5.2 as follows:

   Even if a link has no routers, stateful autoconfiguration to obtain
   addresses and other configuration information may still be
   available, and hosts may want to use the mechanism.  From the
   perspective of autoconfiguration, a link has no routers if no
   Router Advertisements are received after having sent a small number
   of Router Solicitations as described in RFC 2461 [5].

12. remove the first and second paragraphs of Section 5.5.3
   ("requirements" parts of the M/O flags).

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

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Mon, 24 May 2004 14:15:19 +0200

Jinmei,

> Thanks for the feedback on this subject so far.
thank you for the comprehensive summary, it looks very good!

>    of Router Solicitations as described in RFC 2461 [5].
Since there was a question regarding DHCPv6 and default router
information options on the DHC-WG's mailing list, one short question to
clarify the meaning of this paragraph: would you say that "routers have
to send RAs if they forward packages" is a valid interpretation of this
paragraph? Thanks in advance for clarifying this.

Christian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 25 May 2004 12:33:36 +0900

>>>>> On Mon, 24 May 2004 14:15:19 +0200, 
>>>>> "Christian Strauf (JOIN)" <[email-masked]> said:

> paragraph? Thanks in advance for clarifying this.

I'm not sure if we need to take a particular action for this in
rfc2462bis, but you may want to add a note like this in Section 5.5.2:

  Note that it is possible that there is no router on the link in this
  sense but is a node that has the ability to forward packets.  In
  this case, hosts must be manually configured about the forwarding
  node's address to be able to send packets off-link, since sending
  router advertisements is the only mechanism to configure the default
  router's address automatically.

We might add a further notice on the suggested configuration:

  Thus, a node that has the ability of forwarding should be configured
  to send router advertisements unless there is a strong reason to not
  do so.

Though I personally think the last sentence is too much in the scope
of rfc2462bis.  But I can live with either

1. do nothing on this in rfc2462bis,
2. add the above note without the "further" notice, or
3. add the above note with the "further" notice

Are you happy with the clarification (with or without the "further"
notice")?  What do others think?

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

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Tue, 25 May 2004 08:26:57 +0200

> 3. add the above note with the "further" notice
I understand your reservations regarding the scope of the sentence, but
w.r.t. to the "default router issue" I think that especially the
"further notice" section will relieve us of some pain because it
clarifies that we really do want forwarding nodes to send RAs in the
majority of cases. So I would vote for 3.. However, we could try to
clarify this issue in another document (something like a BCP?), if we
feel that it's out of scope for 2462bis.

> notice")?  What do others think?
Yes, the clarification looks very good and I really think that it is
necessary. I'm curious to hear the others' opinions where it should be
placed (in 2462bis or someplace else).

Christian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 29 May 2004 12:22:13 +0900

>>>>> On Tue, 25 May 2004 08:26:57 +0200, 

> placed (in 2462bis or someplace else).

There seems to be no strong opinion except yours ("another" Christian
wanted to leave this to ND-proxy, but I think this is not necessarily
related to ND-proxy as I pointed out in the response to him).

So I'll add the proposed clarification with the "further notice" in
the next revision of rfc2462bis.  We can still change the wording or
even remove the text if someone finds a significant problem in it or a
better place to describe that in reviewing the revision.

I'll probably reword the "further notice" though, since the original
text seems a bit too strong.  I'll probably say:

  Thus, a node that has the ability of forwarding should be configured
  to send router advertisements on a link that has a host depending on
  the advertisements unless there is a strong reason to not do so.

For example, a forwarding node does not have to send RAs on a p2p link
if the administrator is sure that the other end of the link is also a
router.  We might be able say "A strong reason" in the original text
incudes this example, but I think it should be better to clarify the
point explicitly.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 31 May 2004 15:17:03 +0900

>>>>> On Sat, 29 May 2004 12:22:13 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> better place to describe that in reviewing the revision.

On second thoughts, I now think the "further notice" should rather go
to rfc2461bis (ND updates).  In fact, this particular point is only
related to router discovery.  So the next revision of rfc2462bis will
only contain the shorter version of the note in Section 5.5.2:

We could even move this part to rfc2461bis, but I personally think
this minimal note makes sense to be here because this is a direct note
on the case of "no router in the link".

In any event, we'll able to reconsider the details on this upon the
new revision or last call cycles.

					JINMEI, Tatuya

---

From: "Gerrit van Niekerk" <[email-masked]>
Date: Mon, 31 May 2004 10:05:38 +0200

I find the language somewhat confusing. This is what I undestand the paragraph 
to say:

  Note that it is possible that there is no router on the link in this
  sense, but there is a node that has the ability to forward packets.  In
  this case, the forwarding node's address must be manually configured in 
  nodes to be able to send packets off-link, since the only mechanism to       
configure the default router's address automatically is to send
  router advertisements.

>   router's address automatically.

===============================================
Gerrit van Niekerk
GP van Niekerk Ondernemings BK
Roosstraat 211, Meyerspark, 0184, South Africa
Tel: +27(12)8036501 Fax: +27(12)8034131
Email: [email-masked], [email-masked]
Web: http://www.gpvno.co.za
===============================================

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 31 May 2004 17:41:17 +0900

>>>>> On Mon, 31 May 2004 10:05:38 +0200, 
>>>>> "Gerrit van Niekerk" <[email-masked]> said:

> configure the default router's address automatically is to send

Yes, this is what I meant.  I'm not sure if the original text was
confusing and if the above one is better...this is probably a matter
of taste, so I'll listen to others for a while, and simply take the
majority.  If no one else makes preference, I'll simply keep the
original text.

Thanks for the comment, anyway.

					JINMEI, Tatuya