errata logo graphic

Found 6 records.

Status: Verified (3)

RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", December 2003

Source of RFC: dhc (int)

Errata ID: 2468

Status: Verified
Type: Technical

Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 12.1 / 12.2 says:

 Section 12.1:
   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached, with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

It should say:

 Section 12.1:
   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached.

New last paragraph of 12.2:
  When the DR delegates prefixes to a Requesting Router, the
  Requesting Router has sole authority for assignment of those
  prefixes, and the Delegating Router MUST NOT assign any prefixes
  from that delegated prefix to any of its own links.

Notes:

This change clarifies that the authority over the address space is delegated to the RR (Requesting Router). Moving the use restriction for the address space from the DR (Delegating Router) to the RR (Requesting Router).

2011-08-02: Notes updated per request from Ole Troan and Leaf Yeh.


Errata ID: 2469

Status: Verified
Type: Technical

Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 11.1 says:

The requesting router MUST ignore any Advertise message that includes
a Status Code option containing the value NoPrefixAvail, with the
exception that the requesting router MAY display the associated
status message to the user.

It should say:

The requesting router MUST ignore any IA_PDs in an Advertise message that includes
a Status Code option containing the value NoPrefixAvail, with the
exception that the requesting router MAY display the associated
status message to the user.

Errata ID: 2470

Status: Verified
Type: Technical

Reported By: Ole Troan
Date Reported: 2010-08-17
Verifier Name: Ralph Droms
Date Verified: 2013-03-09

Section 11.2 says:

If the delegating router will not assign any prefixes to any IA_PDs
in a subsequent Request from the requesting router, the delegating
router MUST send an Advertise message to the requesting router that
includes the IA_PD with no prefixes in the IA_PD and a Status Code
option in the IA_PD containing status code NoPrefixAvail and a status
message for the user, a Server Identifier option with the delegating
router's DUID and a Client Identifier option with the requesting
router's DUID.

It should say:

If the delegating router will not assign any prefixes to an IA_PD
in a subsequent Request from the requesting router, the delegating
router MUST send an Advertise message to the requesting router that
includes the IA_PD with no prefixes in the IA_PD and a Status Code
option in the IA_PD containing status code NoPrefixAvail and a status
message for the user, a Server Identifier option with the delegating
router's DUID and a Client Identifier option with the requesting
router's DUID. The server SHOULD include other stateful IA options
(like IA_NA) and other configuration options in the Advertise message.

Notes:

Edited by Ralph Droms on 2010-08-20 to correct reference to IA_NA (was IA_PD) in last line.


Status: Held for Document Update (3)

RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", December 2003

Source of RFC: dhc (int)

Errata ID: 248

Status: Held for Document Update
Type: Editorial

Reported By: Hideshi Enokihara
Date Reported: 2006-06-15
Held for Document Update by: Brian Haberman

Section 9 says:

   If a requesting router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the client discards the IA_PD
   option and processes the remainder of the message as though the
   delegating router had not included the IA_PD option.

It should say:

   If a requesting router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the requesting router discards the IA_PD
   option and processes the remainder of the message as though the
   delegating router had not included the IA_PD option.

Notes:


Errata ID: 1880

Status: Held for Document Update
Type: Editorial

Reported By: Yukiyo Akisada
Date Reported: 2009-09-15
Held for Document Update by: Brian Haberman

Section 9 says:

   If a delegating router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the delegating router ignores the
   invalid values of T1 and T2 and processes the IA_PD as though the
   delegating router had set T1 and T2 to 0.

It should say:

   If a delegating router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the delegating router ignores the
   invalid values of T1 and T2 and processes the IA_PD as though the
   requesting router had set T1 and T2 to 0.

Errata ID: 3736

Status: Held for Document Update
Type: Editorial

Reported By: Alexandru Petrescu (w/ text from R. Droms)
Date Reported: 2013-09-25
Held for Document Update by: Ted Lemon
Date Held: 2013-09-25

Section 14 says:

If a delegating router communicates with a requesting router through
a relay agent, the delegating router may need a protocol or other
out-of-band communication to add routing information for delegated
prefixes into the provider edge router.

It should say:

If a delegating router communicates with a requesting router through
a relay agent, the delegating router may need a protocol or other
out-of-band communication to configure routing information for delegated
prefixes on any router through which the requesting router may forward
traffic.

Notes:

This is a terminology correction. See discussion on the email list DHCWG of the DHC WG of IETF, 24 September 2013, http://www.ietf.org/mail-archive/web/dhcwg/current/msg14709.html


Report New Errata