Subject: [v6ops] [Technical Errata Reported] RFC6204 (3054)

From: RFC Errata System <[email-masked]>
Date: Fri, 16 Dec 2011 10:45:50 -0800 (PST)

The following errata report has been submitted for RFC6204,
"Basic Requirements for IPv6 Customer Edge Routers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6204&eid=3054

--------------------------------------
Type: Technical
Reported by: Tore Anderson <[email-masked]>

Section: 4.3

Original Text
-------------
   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of the lower of the current Valid Lifetime and 2
          hours (which must be decremented in real time) in a Router
          Advertisement message as described in Section 5.5.3, (e) of
          [RFC4862].

Corrected Text
--------------
   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of either a) zero, or b) the lower of the current
          Valid Lifetime and 2 hours (which must be decremented in real
          time), in a Router Advertisement message as described in
          Section 5.5.3, (e) of [RFC4862].

Notes
-----
The original text in L-13 prohibits implementers from transmitting Valid Lifetime = 0 whenever a prefix needs to be invalidated. It should not, because transmitting VL=0 is easier to implement than sending "the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time)".

Transmitting Valid Lifetime = 0 has the exact same effect on a host as the procedure described in the original text, i.e., it will the host to lower (but never raise) the remaining valid lifetime to 7200 seconds.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6204 (draft-ietf-v6ops-ipv6-cpe-router-09)
--------------------------------------
Title               : Basic Requirements for IPv6 Customer Edge Routers
Publication Date    : April 2011
Author(s)           : H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.
Category            : INFORMATIONAL
Source              : IPv6 Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 19 Dec 2011 08:56:42 -0600

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Monday, December 19, 2011 9:56 AM
To: 'Tore Anderson'; Wuyts Carl
Cc: RFC Errata System; Wes Beebee (wbeebee); [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [v6ops] [Technical Errata Reported] RFC6204 (3054)

This errata seems to be a lazy implementation which does not want to
deal with complexity of the behavior in L-13.  The errata is suggesting
to augment the text with a zero value for Valid Lifetime and that looks
to be an enhancement rather than an errata.  Since rfc6204bis is
supposed to replace rfc6204, rfc6204bis can change the text for L-13 to
include the enhancement.

Hemant

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: Monday, December 19, 2011 5:24 AM
To: Wuyts Carl
Cc: RFC Errata System; Hemant Singh (shemant); Wes Beebee (wbeebee);
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)

* Wuyts Carl

> It'll be backwards compatible, but the =0 was initially not in, so
> has to be added into the RA daemon..

Carl,

If your RA daemon currently implements VL=<the lower of the current
Valid Lifetime and 2 hours (which must be decremented in real time)>,
you don't have to change anything in order to be in compliance with the
new L-13, and you should feel free ignore the errata completely. I don't
understand why you feel otherwise?

What prompted me to submit the errata was discussions with a CPE
manufacturer that felt the current L-13 requirement was needlessly
complex, compared to simply always sending VL=0. The intention is to
make it easier, not harder, for a CPE manufacturer to correctly
implement L-13 by allowing two alternative methods (that both accomplish
the exact same thing).

-- 
Tore Anderson

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 19 Dec 2011 08:52:17 +0100

Well, seems like this one keeps changing.  Behavior first as described in RFC4862, then RFC6204, now RFC6204bis.  We've had complaints in the past that CPE's are not IPv6 ready (or taking too long to become IPv6 ready), but yet again, IETF WGs keep changing behavior on this, so once again, the CPE must be adjusted, so not really helping on this matter.

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of RFC Errata System
Sent: vrijdag 16 december 2011 19:46
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [v6ops] [Technical Errata Reported] RFC6204 (3054)

The following errata report has been submitted for RFC6204, "Basic Requirements for IPv6 Customer Edge Routers".

Section: 4.3

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6204 (draft-ietf-v6ops-ipv6-cpe-router-09)
--------------------------------------
Title               : Basic Requirements for IPv6 Customer Edge Routers
Publication Date    : April 2011
Author(s)           : H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.
Category            : INFORMATIONAL
Source              : IPv6 Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 19 Dec 2011 10:52:25 +0100

It'll be backwards compatible, but the =0 was initially not in, so has to be added into the RA daemon..
I'm not saying this is very difficult, but yet another (small) change. It has of course also impact on our internal testing etc.

Carl Wuyts

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: maandag 19 december 2011 10:37
To: Wuyts Carl
Cc: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)

* Wuyts Carl

> Well, seems like this one keeps changing.  Behavior first as described 
> in RFC4862, then RFC6204, now RFC6204bis.  We've had complaints in the 
> past that CPE's are not IPv6 ready (or taking too long to become IPv6 
> ready), but yet again, IETF WGs keep changing behavior on this, so 
> once again, the CPE must be adjusted, so not really helping on this 
> matter.

Carl,

Could you explain how, exactly, you interpret the proposed errata to require CPE adjustments? It is intended to be backwards compatible with
L-13 in RFC 6204/6204bis.

Thanks,
--
Tore Anderson

---

From: Tore Anderson <[email-masked]>
Date: Mon, 19 Dec 2011 10:36:37 +0100

* Wuyts Carl

> Well, seems like this one keeps changing.  Behavior first as
> described in RFC4862, then RFC6204, now RFC6204bis.  We've had
> complaints in the past that CPE's are not IPv6 ready (or taking too
> long to become IPv6 ready), but yet again, IETF WGs keep changing
> behavior on this, so once again, the CPE must be adjusted, so not
> really helping on this matter.

Carl,

Could you explain how, exactly, you interpret the proposed errata to
require CPE adjustments? It is intended to be backwards compatible with
L-13 in RFC 6204/6204bis.

Thanks,
-- 
Tore Anderson

---

From: Tore Anderson <[email-masked]>
Date: Mon, 19 Dec 2011 11:24:10 +0100

* Wuyts Carl

Carl,

If your RA daemon currently implements VL=«the lower of the current
Valid Lifetime and 2 hours (which must be decremented in real time)»,
you don't have to change anything in order to be in compliance with the
new L-13, and you should feel free ignore the errata completely. I don't
understand why you feel otherwise?

-- 
Tore Anderson

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 19 Dec 2011 11:29:20 +0100

I agree that always sending 0 is easier and less complex.
But we're always trying to stick very close to the standards, so have implemented it the way now without =0, and I'm aware that we can ignore the errata.
On the other hand, this will mean that certain CPEs send =0, others don't, so try to avoid this.

Anyway, my point is that I see too many changes lately for the CPE.  Don't forget we're "just" a residential CPE.  Small things like this, but bigger things like potential changes in dhcpv6 state machine (e.g. the idea to have separate messages for discover etc) are not beneficial to get some CPEs performing well/steady in IPv6.

Carl Wuyts

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: maandag 19 december 2011 11:24
To: Wuyts Carl
Cc: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3054)

* Wuyts Carl

Carl,

If your RA daemon currently implements VL=<the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time)>, you don't have to change anything in order to be in compliance with the new L-13, and you should feel free ignore the errata completely. I don't understand why you feel otherwise?

What prompted me to submit the errata was discussions with a CPE manufacturer that felt the current L-13 requirement was needlessly complex, compared to simply always sending VL=0. The intention is to make it easier, not harder, for a CPE manufacturer to correctly implement L-13 by allowing two alternative methods (that both accomplish the exact same thing).

--
Tore Anderson

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 19 Dec 2011 08:55:47 -0600

Hemant

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: Monday, December 19, 2011 5:24 AM
To: Wuyts Carl
Cc: RFC Errata System; Hemant Singh (shemant); Wes Beebee (wbeebee);

* Wuyts Carl

Carl,

-- 
Tore Anderson

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Dec 2011 10:14:38 +1300

> implement L-13 by allowing two alternative methods (that both accomplish

This seems like a strange use of the errata mechanism when we are so
close to finishing the bis document. It's a technical *change*, not
the correction of an error, so shouldn't it just be in bis?

    Brian

---

From: Tore Anderson <[email-masked]>
Date: Tue, 20 Dec 2011 12:48:58 +0100

* Brian E Carpenter

> the correction of an error, so shouldn't it just be in bis?

Brian,

I don't know, it was Ole's idea to submit an errata against 6204,
actually. I'm not terribly familiar with the formal IETF procedures
myself. I am quite happy if the change is put into 6204bis (only).

That said, disallowing VL=0 appears to me to be either an oversight, or
based on an incorrect reading of RFC 4862 section 5.5.3 (e). If that is
indeed the case I would classify the change as a correction, rather than
a feature enhancement, so calling it an errata makes sense to me.

-- 
Tore Anderson

---

From: Wes Beebee <[email-masked]>
Date: Tue, 20 Dec 2011 14:06:44 -0500

> based on an incorrect reading of RFC 4862 section 5.5.3 (e).

Specifically, RFC 4862 section 5.5.3 (e) governs the processing of RA's on
receipt by a host.  It does not govern the sending of RA's by routers.  In
the case where a router sends VL=0 in an RA, the processing of that RA by
the receiving host will result in exactly the same actions on the part of
the host as when the VL follows the more complicated 2-hour rule.
Therefore, setting VL=0 in the RA will result in no harm done to the network
and may result in a simpler router implementation.

The Errata process bypasses WG consensus.  The advantage of putting this in
rfc6204bis is that the change will be ratified by the WG during the normal
document progression process.

- Wes

---

From: Mark Townsley <[email-masked]>
Date: Wed, 21 Dec 2011 17:28:52 +0100

On Dec 20, 2011, at 8:06 PM, Wes Beebee wrote:

> The Errata process bypasses WG consensus.

The intent of Errata is indeed to catch oversights and errors, not bypass WG consensus (or IETF consensus, which is really what happens when a WG document is approved for publication). ADs have to sign off on all Errata, and part of that job is verifying that the errata is not circumventing consensus.

>  The advantage of putting this in

We can do both.

- Mark