Subject: RFC2461bis issue: clarity of using DHCP? [RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) (fwd)]

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Nov 2003 16:06:05 +0200 (EET)

Hi,

Just bringing this issue up explicitly..

RFC2461bis may have to take a better stance on what using managed 
address autoconfiguration or getting other configuration means (as 
discussed in the DHCPv6 thread here).

No suggestions at this point, perhaps we'll have to see when we agree 
about the text for Node Requirements..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
---------- Forwarded message ----------
Date: Thu, 20 Nov 2003 14:50:19 -0500
From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails)

> 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,
>    IPv6 Nodes that implement DHCP MUST attempt to use DHCP.  In this 
>    context, 'use DHCP' means trying to obtain both address(es) and 
>    other configuration information through DHCP.

This wording seems clumsy to me.  How about:

If no Router Advertisements are recieved within (NN seconds?) of
joining a link and sending a Router Solicitation, IPv6 hosts that
implement DHCPv6 should attempt to use DHCPv6 to obtain both
IPv6 address(es) and other configuration information.  [Do we
need to say what happens if a router advertisement is received
later?]

Upon receipt of a router advertisement with the 'M' flag set (see
section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST attempt 
to use DHCPv6 to obtain both IPv6 addess(es) and other configuration
information.

> to:
> 
>    IPv6 Nodes (acting as hosts) that implement DHCP, 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. 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.  Furthermore, in the absence of
>    a router, these types of node are not required to initiate DHCP.

Similarly, how about:

"Upon reciept of a Router Advertisement with the 'O' flag set (see
section 5.5.3 of RFC 2462), IPv6 hosts that implement DHCPv6 MUST
attempt to use DHCPv6 to obtain non-address configuration information,
but not IPv6 address(es). 

IPv6 nodes that do not implement DHCPv6 client functionality should
ignore the 'M' and 'O' bits of the router advertisement."

The no router case shouldn't be repeated here, as it is covered
above.  And, yes, I do think that hosts should attempt to use
DHCPv6 to get IPv6 addresses in the absence of a router.  Also, I 
think it is silly to say that hosts that don't implement DHCPv6 
don't need to use it...

--------------------------------------------------------------------
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: Ralph Droms <[email-masked]>
Date: Tue, 25 Nov 2003 08:00:26 -0500

Pekka's request for assignment of a new option code number for a Neighbor
Discovery option prompted me to take a quick look at RFC2461, which doesn't
have an IANA Considerations section.  I suggest that IANA Considerations be
added to RFC2461bis, with rules about assigning new option codes.  The rules
for new option codes in DHCPv6, from the IANA Considerations section of RFC
3315, seem appropriate for ND options as well:

    New DHCP option codes are tentatively assigned after the
    specification for the associated option, published as an Internet
    Draft, has received expert review by a designated expert [11].  The
    final assignment of DHCP option codes is through Standards Action, as
    defined in RFC 2434 [11].

    [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Nov 2003 16:12:25 +0200 (EET)

>     defined in RFC 2434 [11].

What does "tentatively assigned" mean?  What if the document doesn't 
get produced in the end, because even though a designated expert is OK 
with it, it is not useful in general?

I don't assume it would be possible to "reclaim" such tentatively 
assigned numbers, at least easily.  But not sure if someone has 
thought this through?

IMHO, the proposal would place too high trust in just one expert 
saying whether this seems OK or not.  The bar needs to be higher, e.g. 
IESG's decision, or maybe adopting the document as WG item, or 
something like that.

(FWIW, draft-narten-ipv6-iana-considerations-00.txt proposes "IESG 
Approval" or "Standards Action".)

---

From: Ralph Droms <[email-masked]>
Date: Tue, 25 Nov 2003 13:43:17 -0500

Comments in line...

>with it, it is not useful in general?

"Tentatively assigned" means it can be returned to the list of
available option codes if no RFC is published.

>assigned numbers, at least easily.  But not sure if someone has

Reclaiming the numbers was difficult in DHCPv4, because the assignment
at the time of a request to IANA, based solely on the existence of
an Internet Draft, was considered permanent.  The rules in DHCPv6
make clear that the assignment is tentative until the RFC is
published, and the assignment may be revoked in the future.

>IESG's decision, or maybe adopting the document as WG item, or

We tried to balance the delay in going through the entire IESG against
the possibility that there is no WG to consider the assignment.  Thus,
we used the "designated expert" rule.

We also used our experience with DHCPv4, where the rule is (now) to
assign option codes at the time of Standards action.

>Approval" or "Standards Action".)

Oops, I missed draft-narten-ipv6-iana-considerations-00.txt.  I assume
IESG approval covers preliminary assignment prior to Standards action?
That text sounds fine to me...

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Nov 2003 16:32:59 +0200 (EET)

> That text sounds fine to me...

Yes, IESG approval should be possible at any stage of the draft 
lifetime.

But note that the particular draft in question is still just a 
personal submission, and has not moved anywhere in the publication 
process yet.