Skip to main content

Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-stateless-dhcpv6-renumbering-02

Revision differences

Document history

Date Rev. By Action
2012-08-22
02 (System) post-migration administrative database adjustment to the Yes position for Thomas Narten
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2004-11-05
02 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-11-04
02 Amy Vezza IESG state changed to Approved-announcement sent
2004-11-04
02 Amy Vezza IESG has approved the document
2004-11-04
02 Amy Vezza Closed "Approve" ballot
2004-10-29
02 Margaret Cullen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman
2004-10-29
02 Thomas Narten [Ballot Position Update] Position for Thomas Narten has been changed to Yes from Discuss by Thomas Narten
2004-10-29
02 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2004-10-28
02 Margaret Cullen
Sent the following message to follow-up on discuss comments:

To: Steve Bellovin , Thomas Narten
From: Margaret Wasserman
Subject: draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt
Cc: Ralph Droms <rdroms@cisco.com …
Sent the following message to follow-up on discuss comments:

To: Steve Bellovin , Thomas Narten
From: Margaret Wasserman
Subject: draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt
Cc: Ralph Droms <rdroms@cisco.com...snip...cisco.com, tjc@ecs.soton.ac.uk

Hi Steve and Thomas,

The DHCPv6 renumbering draft has been updated to address your discuss comments.  You can find the latest version at:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt

If this version addressing your comments, please clear your discuss.  Otherwise, please let us know what issues remain.

Thanks,
Margaret
2004-10-28
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-10-28
02 (System) New version available: draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt
2004-10-15
02 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-10-15
02 (System) Removed from agenda for telechat - 2004-10-14
2004-10-14
02 Steven Bellovin
[Ballot discuss]
The Security Considerations section should be updated to say something like this:

    As with all renumberings, sites should update any address …
[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.
2004-10-14
02 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to Discuss from No Objection by Steve Bellovin
2004-10-14
02 Thomas Narten
[Ballot comment]
>    This combination of Stateless Address Autoconfiguration and stateless
>    DHCPv6 could be used quite commonly in IPv6 networks.  In the …
[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/
2004-10-14
02 Thomas Narten
[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 …
[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.
2004-10-14
02 Thomas Narten [Ballot Position Update] New position, Discuss, has been recorded for Thomas Narten by Thomas Narten
2004-10-14
02 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2004-10-14
02 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-10-14
02 Harald Alvestrand
[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 …
[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
2004-10-14
02 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-10-14
02 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-10-13
02 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-10-13
02 Michelle Cotton IANA Review - We understand this document to have NO IANA Actions
2004-10-13
02 Russ Housley [Ballot comment]
In section 5: s/denialof service/denial of service/
2004-10-13
02 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2004-10-12
02 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin
2004-10-12
02 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2004-10-05
02 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-10-03
02 Margaret Cullen State Changes to IESG Evaluation from Publication Requested by Margaret Wasserman
2004-10-03
02 Margaret Cullen Placed on agenda for telechat - 2004-10-14 by Margaret Wasserman
2004-10-03
02 Margaret Cullen [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman
2004-10-03
02 Margaret Cullen Ballot has been issued by Margaret Wasserman
2004-10-03
02 Margaret Cullen Created "Approve" ballot
2004-10-03
02 (System) Ballot writeup text was added
2004-10-03
02 (System) Last call text was added
2004-10-03
02 (System) Ballot approval text was added
2004-10-03
02 Margaret Cullen
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 …
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.
2004-10-03
02 Margaret Cullen Draft Added by Margaret Wasserman in state Publication Requested
2004-07-20
01 (System) New version available: draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt
2004-03-09
00 (System) New version available: draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt