Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails)

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Nov 2003 08:52:57 -0500

Comments (mostly editorial) in line...

- Ralph

At 11:12 AM 11/20/2003 +0200, [email-masked] wrote:
>Hi all,
>
>Please ignore previous mails on this topic,  here is the proposed text:
>
>thanks,
>John
>
> > >  In addition, in the absence of a router,
> > >    IPv6 Nodes that implement DHCP MUST attempt to use DHCP.
> > >
> > > ==> what does "in the absence of a router" mean?  maybe this needs to be
> > > made slightly more explicit to be unambiguous..
> >
> > Suggested text?
>
>reword:
>
>    For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP
>    upon the receipt of a Router Advertisement with the 'M' flag set (see
>    section 5.5.3 of RFC2462).  In addition, in the absence of a router,
>    IPv6 Nodes that implement DHCP MUST attempt to use DHCP.
>
>to:
>
>    Nodes that implement DHCP MUST use DHCP upon the receipt of a
>    Router Advertisement with the 'M' flag set (see section 5.5.3 of
>    RFC2462).  In addition, in the absence of a router,

How about replacing "in the absence of a router" with "if the node does not
receive any Router Advertisements"?  Please ignore my suggestion if I'm
leading us down a previously explored rathole.

>    IPv6 Nodes that implement DHCP MUST attempt to use DHCP.  In this

Is the capitalization of "Nodes" consistent with the rest of the doc
(seems to be, based on the text snippets included here?)?

>    context, 'use DHCP' means trying to obtain both address(es) and
>    other configuration information through DHCP.

As was suggested elsewhere, substituting DHCPv6 for DHCP throughout
wouldn't hurt (but certainly isn't critical).

> > >    For those IPv6 Nodes (acting as hosts) that implement DHCP, those
> > >    nodes MUST use DHCP upon the receipt of a Router Advertisement with
> > >    the 'O' flag set (see section 5.5.3 of RFC2462).  In addition, in the
> > >    absence of a router, hosts that implement DHCP MUST attempt to use
> > >    DHCP.
> > >
> > > ==> attempt to use DHCP _for what_ ?  Getting stateful information, of
> > > course, not the addresses?
> >
> > Suggested text?
>
>reword:
>
>    For those IPv6 Nodes (acting as hosts) that implement DHCP, those
>    nodes MUST use DHCP upon the receipt of a Router Advertisement with
>    the 'O' flag set (see section 5.5.3 of RFC2462).  In addition, in the
>    absence of a router, hosts that implement DHCP MUST attempt to use
>    DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a
>    Router Advertisement can be ignored.  Furthermore, in the absence of
>    a router, these types of node are not required to initiate DHCP.

s/types of node/such Nodes/ (for clarity and consistency)?

>to:
>
>    IPv6 Nodes (acting as hosts) that implement DHCP, MUST use DHCP upon

Is there a reason to differentiate between nodes acting as hosts here, but
not in the paragraph describing the behavior in response to the 'M' bit?
I'd suggest, in fact, that only hosts want to use DHCPv6 for address
assignment, while both hosts and routers want to use DHCPv6 for other
configuration information.  Again, please ignore my suggestion if the issue
has already been explored.

>    the receipt of a Router Advertisement with the 'O' flag set (see
>    section 5.5.3 of RFC2462).  In addition, in the
>    absence of a router, hosts that implement DHCP MUST attempt to use

My comment above about "in the absence of a router" applies here, too.

>    DHCP. In this context, 'use DHCP' means trying to obtain only other
>    configuration information through DHCP, not address(es).
>
>    IPv6 Nodes that do not implement DHCP can ignore the 'O' flag
>    of a Router Advertisement.

Is there a specific reason that a similar sentence does not appear in the
text about the 'M' bit?

>   Furthermore, in the absence of
>    a router, these types of node are not required to initiate DHCP.

s/types of node/such Nodes/ (for clarity and consistency)?

>(these are not only editorial issues IMHO, especially the latter one,
>if someone is envisioning that in absence of a router, DHCP should try
>to get an address as well, from the context of other config
>information)

I'm afraid I don't understand the parenthetical comment...

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

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

---

From: Soliman Hesham <[email-masked]>
Date: Thu, 20 Nov 2003 09:06:35 -0500

> not in the paragraph describing the behavior in response to 

=> In general, unless previously discussed and rejected for some 
reason, I'd globally: s/Nodes (acting as hosts)/host

It's a bit clumsy to read as it is.

Hesham

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Nov 2003 09:37:10 -0500

Hesham,

At 09:27 AM 11/20/2003 -0500, Soliman Hesham wrote:

>  > I strongly suggest the use of "Nodes" (unqualified) in the text
>  > about the 'O' bit:
>
>=> To be clear, I was suggesting substitusting "Nodes (acting as hosts)".
>I'm not sure if you're replying to my comment or in general.

Thanks for the clarification; I don't think I precisely understood your
substitution.

And, now that I think about the problem a little more carefully, esp. after
reading the text you cite below from RFC 2461 (thanks for looking up the
reference), I've convinced myself the problem is a little more complicated
than I thought at first glance.

In the case of routers, I think the 'M' and 'O' bits should be
used conditionally based on configuration in the router.  That is,
I can imagine situations in which an operator would want to
control the behavior of several routers on a link through
the 'M' and 'O' bits, while in other situations an operator
would want to configure each router manually, ignoring the
'M' and 'O' bits...

>  > However, there is some question about any discussion of "nodes" and
>  > RAs, as there may be text in RFC 2461 (I'm working from
>  > memory, here, which
>  > in my case is a remarkably unreliable service; I hope
>  > someone more familiar
>  > with RFC 2461 can confirm or deny) that allows or requires
>  > routers to ignore RAs.
>
>=> In 6.2.7 :
>
>    Routers SHOULD inspect valid Router Advertisements sent by other
>    routers and verify that the routers are advertising consistent
>    information on a link.  Detected inconsistencies indicate that one or
>    more routers might be misconfigured and SHOULD be logged to system or
>    network management.  The minimum set of information to check
>    includes:
>
>     - Cur Hop Limit values (except for the unspecified value of zero).
>
>     - Values of the M or O flags.
>
>     - Reachable Time values (except for the unspecified value of zero).
>
>Whether that means routers can also act upon the information
>they receive is of course a separate issue. But at least
>it is clear that routers are not required to automatically drop RAs.
>
>Hesham
>
>
>
>
>
>  >
>  > - Ralph
>  >
>  > At 09:06 AM 11/20/2003 -0500, Soliman Hesham wrote:
>  > >  >

---

From: [email-masked]
Date: Fri, 21 Nov 2003 10:37:06 +0200

Bob,
> Please remind me why the "in the absence of a router" text is there.  I am 
> having a hard time thinking about a scenario where there would be a DHCP 
> server, but no router.  The presences of a DHCP relay agent would also need 
> a router to be useful.

Agreed.  The text is bad.  Thinking further, it should be something like
if an RA is not received, then DHCP is used.  However, thinking about this
further, if no RA is received, maybe someone might like to be prompted to
use manual configuration, not DHCP.  Would that be possible?

John

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 21 Nov 2003 13:50:30 -0800

> Also, I think we should revisit this text in the RFC2462bis
> effort.  Changing the MUST to MAY in the 5.5.2 paragraph looks like
the
> right change to me, but that's a different email thread.

I would agree with that. In any case, I object to tying a MUST condition
to the availability of the code in the implementation. Implementation is
a necessary condition, but so is for example user or admin consent,
maybe battery state, whatever. The text should not speak about
implementation.

-- Christian Huitema