Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 4076

[Ballot discuss]
The Security Considerations section should be updated to say something like this:

    As with all renumberings, sites should update any address filters, access
    control lists, etc., to reflect the new prefix.

[Ballot comment]
>    This combination of Stateless Address Autoconfiguration and stateless
>    DHCPv6 could be used quite commonly in IPv6 networks.  In the absence
>    of an alternative method for DNS, NTP and other options to be
>    automatically configured, it may become the most common combination
>    for statelessly configuring hosts.

I don't think this last sentence is needed. It hints at the
possibility that other mechanisms might be invented that would be used
instead of stateless DHC. Not sure why this document wants to say
that.

>    While a DHCPv6 server unicasts Reconfigure message to individual
>    clients to trigger the clients to intiate Information-request/reply
>    configuration exchanges to update their configuration settings, the
>    stateless variant of DHCPv6 cannot use the Reconfigure mechanism
>    because it does not maintain a list of IP addresses (leases) to send
>    the unicast messages to.

Perhaps add a sentence something like:

  Note that in DHCPv6, Reconfigure messages must be unicast; multicast
  is not allowed.

>    Thus events including the following cannot be handled:
>
>    o  Full site renumbering

Don't understand this bullet. Just what is it about renumbering that
can't be done (and isn't covered more explicitely by later points?)


>    o  Security is important; e.g., avoiding denialof service attacks
>      mounted through Reconfigure messages sent from an attacker.

s/denialof/denial of/

[Ballot discuss]
The problem should be more clearly stated. Note that it is not just a
problem for "stateless" DHCP. The fundamental problem is that only IP
address options have a lifetime, so there is no mechanism to "expire"
old information or otherwise force a client to recheck that
new/updated information is available. Even in "stateful" dhcp, this is
the case. It's less of a problem there though because when renewing
address leases, one learns (as a side-effect) about changes to other
parameters. But similar problems can occur there, e.g., if address
leases are 2 weeks long, yet changes/updates to other parameters are
made before then. So, I think it is misleading to imply that the
problem is just related to stateless DHCP.

>    resolver addresses.  It does not maintain state about the information
>    assigned to clients;  the additional parameters do not have an
>    explicit life-time associated with them in the same way that IP
>    addresses do, and hence the DHCPv6 server does not need to maintain
>    the state of the clients.

better: (the lifetime is not a factor in the need to maintain state)

  It does not maintain state about the information assigned to
  clients, hence there is no need to maintain per-client state on the
  server. In other words, all clients can be given the same
  information, in the same way that the information in Router
  Advertisements is not client-specific.

[Ballot comment]
Reviewed by John Loughney, Gen-ART

His review:

This document is ready to go. 

One small nit:

Page 4:

3.1  Site renumbering

  One of the fundamental principles of IPv6 is that sites receive their
  IPv6 address allocations from an ISP using provider assigned (PA)
  address space.  There is currently no provider independent (PI)
  address space in IPv6.  A site wishing to change ISP must thus
  renumber its network.

"A site wishing to change" struck me as odd, as in many cases, some sites
need to change ISP because of mergers or bankruptcies.  I would change the
sentence to:

A site changing its ISP must thus renumber its network.

One question, the Security Considerations section says:

8.  Security Considerations

  There are no security considerations in this problem statemement per
  se.  However, whatever mechanism is designed or chosen to address
  this problem should avoid the introduction of new security concerns
  for (stateless) DHCPv6.

Now, I was actually hoping that there would be some text or pointers
discussing the effect of renumber on security. What are the impacts
to security of using DHCPv6 on security?  I am wrong in thinking that
this is what should be captured in Security Considerations text?

John

AD questions for draft-ietf-dhc-stateless-dhcpv6-renumbering

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes and no.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

The WG as a whole understands and agrees with the conclusions of this
document.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary
  - Working Group Summary
  - Protocol Quality

This document is to be published as an Informational RFC.