Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events
draft-ietf-v6ops-cpe-slaac-renum-08

[Ballot comment]
[[ comments ]]

[ section 3.4 ]

* At the end of the 2nd paragraph and the 2nd NOTES paragraph, I think it
  could be made clearer that this recommendation especially applies to ND
  Options that contain address or prefix information from within a prefix
  learned on the WAN side.

  These timers seem fine in general as well, but I think as written it's
  a blanket recommendation without explicitly saying why these options
  need updating, i.e. if someone asks what does "if and where applicable"
  actually mean -- it means ND options with address/prefix information
  taken from a delegated prefix whose lifetime has been reduced
  (possibly to zero, possibly progressively shorter values trending to zero).

[Ballot comment]
Section 3

  o  WPD-10: CE Routers MUST by default use a stable IAID value that
      does not change between CE Router restarts, DHCPv6 client
      restarts, or interface state changes. e.g., Transient PPP
      interfaces.  See Section 3.2 for further details.

The text in Section 3.2 goes into a bit more detail to clarify that this
is basically a pre-existing requirement from RFC 8415, but the short
text here is easy to misread as imposing a requirement to use a stable
persistent identifier, which would have lousy privacy properties.  RFC
8415 does acknowledge this issue to some extent, but the most applicable
text about it seems to be in Section 4.5 of RFC 7844, that clarifies
that the IAID needs to be consistent for the association *as long as the
link-layer address remains constant*, which is a very natural scope and
consistent with best practices for simultaneously changing identifiers
at different layers when needed for privacy improvement.  It would be
great if we could spend a few words here to clarify that this is not a
permanent identifier that could be abused for tracking, perhaps "(Per
[RFC8415] it is still expected to change when the link-layer address
changes.)", though I was hoping to have something shorter.

Additionally, while RFC 8415 is clear that the IAID is assigned by the
client, this text might benefit from noting (e.g.) which interface it is
used on, since the CE router will often be on both ends of different
DHCPv6 exchanges.

[Ballot comment]
Thank you for the work put into this easy-to-read document.

I support Erik Kline's DISCUSS points.

I have cleared my previous blocking DISCUSS and thank you for addressing all my previous COMMENTS.

But please also check:
-  Suresh Krishnan's IoT directorate review:
https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-iotdir-telechat-krishnan-2020-10-21/
- Sheng Jiang's Internet directorate review:
https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-intdir-telechat-jiang-2020-10-19/

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS (addressed in -06, no more blocking, kept here for archive) ==

As observed by Sheng in his review and by Rob Wilton, the use of normative-looking "MUST" is unusual in an informational document even with the section 2 about requirement languages as the use of uppercase could confuse the reader; or at least limit their use in the L-* text in section 3. Also, note that RFC 2119 has been updated by RFC 8174.  The precedent set by RFC 7084 seems a bad one.

I will trust the responsible AD decision on this topic.

== COMMENTS (addressed, kept for archives) ==

The shepherd write-up includes twice "a particular corner case where DHCPv6 is being used to distribute effectively static addresses". Perhaps is it due for not being a native English speaker, but, the use of "corner case" in a shepherd write-up appears to me as weird and unexpected: is it the shepherd's opinion or the WG consensus of being a 'corner case'. I read this as 'very rare case' whereas I sincerely think, and Jordi's review indicates so, that this is not a rare case.

-- Abstract --
I wonder why the word "IPv6" is never mentioned in the abstract while the whole document is about IPv6. OTOH, perhaps the default IP version in 2020 is indeed IPv6 ;-)

-- Section 3 --
Should the L-13 of RFC 7084 be also updated ? Briefly discussed in section 3.3

I wonder what is the actual structure of this section? There are 4 L-XX requirements followed by 3 subsections and mapping between L-15 with section 3.1 and the same for L-16, L-17 but not for L-18 ?

As noted in section 3.1, L-13 is actually Section 6.3 of [RFC8415] that is standard track

-- Section 3.2 --
There is a reference to section 2.1 of this document but the authors probably meant section 3.1 of this document or Section 6.3 of [RFC8415].

Should the list of ND options include by default all options ? or at least indicate that this is not an exhaustive list to allow for future ND options ?

-- Section 3.3 --
I agree with "IPv6 network renumbering is expected to take place in a planned manner," but this sentence seems to contradict the premisses of draft-ietf-v6ops-slaac-renum. Unsure how to reconciliate the two I-D (sharing some authors ;-) ).

" since we acknowledge " suggest to slightly rewrite this sentence to make it less personal.

Suggestion to mention whether RA are sent only on received RS, multicasted immediately (the document mention periodically), or unicasted when possible (some CPE keeps the mapping of all its unicast client notably on the Wi-Fi side).

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-v6ops-cpe-slaac-renum-06, which is currently in a second Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

The following Last Call announcement was sent out (ends 2021-01-13):

From: The IESG
To: IETF-Announce
CC: Owen DeLong , draft-ietf-v6ops-cpe-slaac-renum@ietf.org, owen@delong.com, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Improving the Reaction of Customer Edge Routers to Renumbering Events) to Best Current Practice


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Improving the Reaction of Customer Edge
Routers to Renumbering Events'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-01-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

This is the second IETF LC for this document -- it was originally LCed as Informational. IESG Eval suggested that it was more BCP-like, and so the document was returned to the V6OPS WG, and re-WGLCed as BCP. It is now being IETF LCed as BCP, and will then go through IESG Eval again.... and the process-elves rejoice...



Abstract


  In scenarios where network configuration information becomes invalid
  without any explicit signaling of that condition (such as when a
  Customer Edge Router crashes and reboots without knowledge of the
  previously-employed configuration information), hosts on the local
  network will continue using stale network configuration information
  for an unacceptably long period of time, thus resulting in
  connectivity problems.  This document specifies improvements to
  Customer Edge Routers that help mitigate the aforementioned problem
  for typical residential and small office scenarios.  This document
  updates RFC7084.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4191: Default Router Preferences and More-Specific Routes (Proposed Standard - IETF stream)
    rfc4861: Neighbor Discovery for IP version 6 (IPv6) (Draft Standard - IETF stream)
    rfc4862: IPv6 Stateless Address Autoconfiguration (Draft Standard - IETF stream)
    rfc8106: IPv6 Router Advertisement Options for DNS Configuration (Proposed Standard - IETF stream)
    rfc8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed Standard - IETF stream)

This is the second IETF LC for this document -- it was originally LCed as Informational. IESG Eval suggested that it was more BCP-like, and so the document was returned to the V6OPS WG, and re-WGLCed as BCP. It is now being IETF LCed as BCP, and will then go through IESG Eval again.


I'm always cautious when trying to make the datatracker do the right thing when deviating from the normal process.... I'm assuming that the secretariat will helpfully point out the 27 intermediate steps that I shold have taken :-P

Document originally LCed and Evaluated as Informational. IESG Eval exposed that BCP was more appropriate - document returned to WG, re-WGLCed as BCP, and now returned to AD.
See:
https://mailarchive.ietf.org/arch/msg/v6ops/23R_SlJP9l5pdkgFTglDZh1sh7Y/
https://mailarchive.ietf.org/arch/msg/v6ops/_seai5Rf5bU6AnPwc3bHqbAI_7M/
https://mailarchive.ietf.org/arch/msg/v6ops/xb4aVGUkkv8ZBxtbeewXjyNq7TQ/

See thread: https://mailarchive.ietf.org/arch/msg/v6ops/23R_SlJP9l5pdkgFTglDZh1sh7Y/

Document is being returned to the WG so that the status can be changed to BCP. IESG Evals, and discussions showed that it was much more BCP-like than Info
I hope to see the document again soon (ie: this isn't "Bad document, go away'", it is "Good document, come back with higher status....")

[Ballot discuss]
Let's resolve the document status issue -- it was last-called as Proposed Standard, it's listed as Informational, but it seems like it should be a BCP.

I support Rob's DISCUSS and I believe the RFC 8174 boilerplate should be used.

[Ballot discuss]
Thank you for the work put into this easy-to-read document.

I support Erik Kline's DISCUSS points.

Please find below a couple of non-blocking COMMENT points and one nit but please also check:
-  Suresh Krishnan's IoT directorate review:
https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-iotdir-telechat-krishnan-2020-10-21/
- Sheng Jiang's Internet directorate review:
https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-intdir-telechat-jiang-2020-10-19/

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==
As observed by Sheng in his review and by Rob Wilton, the use of normative-looking "MUST" is unusual in an informational document even with the section 2 about requirement languages as the use of uppercase could confuse the reader; or at least limit their use in the L-* text in section 3. Also, note that RFC 2119 has been updated by RFC 8174.  The precedent set by RFC 7084 seems a bad one.

I will trust the responsible AD decision on this topic.

[Ballot comment]
The shepherd write-up includes twice "a particular corner case where DHCPv6 is being used to distribute effectively static addresses". Perhaps is it due for not being a native English speaker, but, the use of "corner case" in a shepherd write-up appears to me as weird and unexpected: is it the shepherd's opinion or the WG consensus of being a 'corner case'. I read this as 'very rare case' whereas I sincerely think, and Jordi's review indicates so, that this is not a rare case.

-- Abstract --
I wonder why the word "IPv6" is never mentioned in the abstract while the whole document is about IPv6. OTOH, perhaps the default IP version in 2020 is indeed IPv6 ;-)

-- Section 3 --
Should the L-13 of RFC 7084 be also updated ? Briefly discussed in section 3.3

I wonder what is the actual structure of this section? There are 4 L-XX requirements followed by 3 subsections and mapping between L-15 with section 3.1 and the same for L-16, L-17 but not for L-18 ?

As noted in section 3.1, L-13 is actually Section 6.3 of [RFC8415] that is standard track

-- Section 3.2 --
There is a reference to section 2.1 of this document but the authors probably meant section 3.1 of this document or Section 6.3 of [RFC8415].

Should the list of ND options include by default all options ? or at least indicate that this is not an exhaustive list to allow for future ND options ?

-- Section 3.3 --
I agree with "IPv6 network renumbering is expected to take place in a planned manner," but this sentence seems to contradict the premisses of draft-ietf-v6ops-slaac-renum. Unsure how to reconciliate the two I-D (sharing some authors ;-) ).

" since we acknowledge " suggest to slightly rewrite this sentence to make it less personal.

Suggestion to mention whether RA are sent only on received RS, multicasted immediately (the document mention periodically), or unicasted when possible (some CPE keeps the mapping of all its unicast client notably on the Wi-Fi side).

[Ballot comment]
I support Rob's DISCUSS, for the reasons Barry gave.  In addition, I believe IETF consensus is to use BCP 14 in its entirety, not just the first half of it.

Also, this sentence gave me pause:

"This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality."

Maybe this should be an applicability statement, and thus Standards Track?

[Ballot comment]
I support Rob's DISCUSS, for the reasons Barry gave.  In addition, I believe IETF consensus is to use BCP 14 in its entirety, not just the first half of it.

[Ballot discuss]
[ section 3.2 ]

* I absolutely agree in principle at these other lifetimes should be updated
  to the shorter of the two applicable lifetimes, but I'm worried that this
  text is not sufficiently precise.  Specifically, this recommendation only
  applies to options that depend in any way on the change in the delegated
  prefix, yes?  Perhaps just this qualifier is sufficient?

  For example, none of these comparative lifetime recommendations apply to
  a stable ULA for a router that meets requirements ULA-[1..5] and chooses
  to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think.

  That being said, should this document also be saying that the ULA-derived
  options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot
  causes a new ULA to be generated (i.e. the one supposedly in stable storage
  is lost or otherwise unrecoverable)?

[Ballot comment]
[[ comments ]]

[ section 3.1 ]

* With respect to the second bullet: the lifetimes need to be dynamically
  *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT
  values are always lower than the remaining PD lifetimes.  In this situation,
  the requirement is still that the lifetimes can be updated, but to the
  casual observer of the steady state the RA contents might appear static
  (e.g., while the PD'd prefix is continuously renewed).

  Maybe there's no text required here, but I didn't want a reader to be left
  with the impression that no two RAs could be identical


[[ nits ]]

[ section 3.3 ]

* In the 2nd bullet's 2nd bullet (this might be easier if these lists were
  numbered), it might be good to clarify that "the *deprecated* prefix can
  simply be advertised..."

[Ballot comment]
I support Rob's DISCUSS and agree that it would be better just to use the terms in lower case, rather than making them appear as special key words but disclaim the definition.  I'll note that RFC 7084 predates RFC 8174, and that the latter clarifies that using the terms in lower case has exactly the meaning that the disclaimer in Section 2 is trying (unsuccessfully) to make.

I also agree with Ben's comment that keeping the grammatical error "preferable" is unnecessary.  But if we end up getting rid of the whole thing, that becomes moot anyway.

[Ballot comment]
I am not sure that we should avoid having the conversation about
intended status; consider, for example, "CE Routers SHOULD override the
default [...] values from [RFC4861]" (RFC 4861 is a Draft Standard).  (The
question was raised in the genart review thread by virtue of skew between
the datatracker state and the document header, but it looks like the WG chair
changed the status in the datatracker and there was no further discussion of
the topic on the list.)

The diff between Abstract and Introduction is interesting: there is a
parenthetical "(such as when a Customer Edge Router crashes and reboots
without knowledge of the previously-employed configuration information)"
only in the abstract that might also be useful in the introduction, and
the abstract uses 'hosts' where the introduction uses 'nodes'.  (There
are a couple other incidental wording differences that the authors might
wish to consider normalizing on one wording for, as well as the expected
additional text in the introduction that is not appropriate for an
abstract.)

Section 2

  purpose of establishing industry-common baseline functionality.  As
  such, the document points to several other specifications (preferable
  in RFC or stable form) to provide additional guidance to implementers

I'm not sure that there's value in saying "preferable" [sic] in the
final RFC; it's not like there would be a further chance to change the
reference to have such a property anymore.

Section 3.1

                                                      This means that
  the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be
  dynamically adjusted such that they never span past the remaining
  preferred and valid lifetimes of the corresponding prefixes delegated
  via DHCPv6-PD on the WAN-side.

(nitty/editorial) Perhaps it is obvious to most readers, but perhaps it
is not universally clear that the "advertised" part refers to
"advertised by the CPE in SLAAC PIOs"; if I wanted to reword to remove
ambiguity, I might go with something like 'This means that the
"Preferred Lifetime" and "Valid Lifetime" advertised in PIOs by the CE
router MUST be dynamically adjusted [...]'.
The next paragraph (for the DHCPv6 case) uses a similar wording, but the
first paragraph of that sentence is a bit more clear about "employed
with DHCPv6 on the LAN-side" that also serves to reduce the potential
ambiguity.  I'm happy to see or propose a similar rewording for the
DHCPv6 case if that would be useful, but don't mind if we leave both
paragraphs unchnaged, either.

  CE Routers providing stateful address configuration via DHCPv6 SHOULD
  set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
  the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the
  valid-lifetime of the same option to the lesser of the remaining
  valid lifetime and ND_VALID_LIMIT.

Is it worth mentioning that ND_PREFERRED_LIMIT and ND_VALID_LIMIT are
defined in Section 4?

Section 3.2

      *  CE Routers need not employ the (possibly long) DHCPv6-PD
        lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs

(nit) do we want "received" in there anywhere (e.g., "received DHCPv6-PD
lifetimes")?

      *  Similarly, CE Routers need not employ the (possibly long)
        DHCPv6-PD lifetimes for the valid-lifetime and preferred-

(Likewise, we could use "received" or "WAN-side" here.)

Section 3.3

  In order to phase-out stale SLAAC configuration information:
  [...]
  If a CE Router provides LAN-side DHCPv6 (address assignment or prefix
  delegation), then:
  [...]

(editorial) Can/should these sentences use a parallel structure (e.g.,
"If a CE Router provides SLAAC configuration information, then [...]")?

      *  In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
        lifetimes for any address assignments or prefix delegations for
        the deprecated prefixes for at least the valid-lifetime
        previously employed for them, or for a period of ND_VALID_LIMIT
        if the recommended lifetimes from Section 3.2 are employed.

Is it deliberate to say nothing at all about Advertise messages (which
are sent in response to Solicit messages, not any of the listed ones)?

      *  The requirement in this section is conveyed as a "SHOULD" (as
        opposed to a "MUST"), since we acknowledge that the requirement
        to store information on stable storage may represent a
        challenge for some implementations.

(editorial/style) It's not entirely clear that we gain much from the use
of the first person, here.  E.g., we could say 'conveyed as a "SHOULD"
(as opposed to a "MUST"), since the requirement to store information on
stable storage may represent a challenge for some implementations'.

Section 6

I suggest noting that the security considerations from RFC 7084 continue
to apply.  (Also, basically the same comment I had for
draft-ietf-v6ops-slaac-renum applies, which still does not imply any
changes to the text.)

Section 8.1

Since we say that we are *not* using the BCP 14 keywords in the sense of
RFC 2119, it does not seem that RFC 2119 needs to be a normative
reference.

Section 8.2

It would feel more natural, at least to me, if RFC 7084 was listed as a
normative reference.  (In the sense that we are Updating it to make
incremental additions, but you need the whole combined assembly of both
documents in order to have a functional setup.)

[Ballot discuss]
Hi,

Hopefully this isn't hard to resolve, but I don't understand the meaning of the text in section 2:

    2.  Requirements Language

      Take careful note: Unlike other IETF documents, the key words "MUST",
      "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
      "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
      described in [RFC2119].  This document uses these keywords not
      strictly for the purpose of interoperability, but rather for the
      purpose of establishing industry-common baseline functionality.  As
      such, the document points to several other specifications (preferable
      in RFC or stable form) to provide additional guidance to implementers
      regarding any protocol implementation required to produce a
      successful CE router that interoperates successfully with a
      particular subset of currently deploying and planned common IPv6
      access networks.

      Note: the aforementioned terms are used in exactly the same way as in
      [RFC7084], with the above explanation copied verbatim from
      Section 1.1 of [RFC7084].

This paragraph tells me how these words are not used. But it doesn't seem to explain how they are meant to be interpreted.

My only assumption is that these words have no special meaning in this document at all, but they than raises the question as to why not to write them all in lower case.  Alternatively, following the standard RFC 2119 rules and boilerplate would also seem to make sense ...

[Ballot comment]

    3.2.  LAN-side Option Lifetimes

      CE Routers SHOULD override the default PIO "Preferred Lifetime" and
      "Valid Lifetime" values from [RFC4861], and employ shorter lifetime
      values to improve the robustness to renumbering events, while
      complying with the requirements from Section 2.1 of this document and
      the recommendations in [RFC7772].

The reference to Section 2.1 should probably be to section 3?


    7.  Acknowledgments

      The authors would like to thank Owen DeLong, Philip Homburg, and Ted
      Lemon, for their valuable help in improving this document via
      successive detailed reviews.

      The authors would like to thank Mikael Abrahamsson, Brian Carpenter,
      Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo
      Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade,
      Pete Resnick, Mark Smith, Job Snijders, Sander Steffann, Ole Troan,
      Loganaden Velvindron, Timothy Winters, Christopher Wood, and
      Chongfeng Xie, for providing valuable comments on earlier versions of
      this document.

      The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim
      Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick
      Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon,
      Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael
      Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for
      providing valuable comments on [I-D.gont-6man-slaac-renum], on which
      this document is based.

Is the third paragraph definitely needed in this document?  Perhaps ietf-6man-slaac-renum which is based on gont-6man-slaac-renum could contain this acknowledgement?  Or perhaps you could merge the two paragraphs into one, if this is an earlier version of this document.  This would also allow you to remove one of the references to similarly named documents in the references.


    8.2.  Informative References

      [I-D.gont-6man-slaac-renum]
                  Gont, F., Zorz, J., and R. Patterson, "Improving the
                  Robustness of Stateless Address Autoconfiguration (SLAAC)
                  to Flash Renumbering Events", draft-gont-6man-slaac-
                  renum-08 (work in progress), May 2020.

      [I-D.ietf-6man-slaac-renum]
                  Gont, F., Zorz, J., and R. Patterson, "Improving the
                  Robustness of Stateless Address Autoconfiguration (SLAAC)
                  to Flash Renumbering Events", draft-ietf-6man-slaac-
                  renum-01 (work in progress), August 2020.

      [I-D.ietf-v6ops-slaac-renum]
                  Gont, F., Zorz, J., and R. Patterson, "Reaction of
                  Stateless Address Autoconfiguration (SLAAC) to Flash-
                  Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work
                  in progress), August 2020.

I was surprised that this document has informative references to three other very similarly named documents!  I would think that at least the first reference is not required since it is superseded by ietf-6man-slaac-renum and thus could be elided?

Regards,
Rob

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-v6ops-cpe-slaac-renum-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-09-09):

From: The IESG
To: IETF-Announce
CC: owen@delong.com, warren@kumari.net, Owen DeLong , draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Improving the Reaction of Customer Edge Routers to Renumbering Events) to Proposed Standard


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Improving the Reaction of Customer Edge
Routers to Renumbering Events'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In scenarios where network configuration information becomes invalid
  without any explicit signaling of that condition (such as when a
  Customer Edge Router crashes and reboots without knowledge of the
  previously-employed configuration information), hosts on the local
  network will continue using stale network configuration information
  for an unacceptably long period of time, thus resulting in
  connectivity problems.  This document specifies improvements to
  Customer Edge Routers that help mitigate the aforementioned problem
  for typical residential and small office scenarios.  This document
  updates RFC7084.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/

NOTE: draft-ietf-v6ops-cpe-slaac-renum and draft-ietf-v6ops-slaac-renum are closely related and should be reviewed together.

No IPR declarations have been submitted directly on this I-D.

(1) This draft is aimed at being an Informational RFC is the appropriate type because
        it provides clarifying information and suggested behaviors to address issues
        experienced in existing implementations.

(2) IESG Approval Announcement

Technical Summary:

This document sets forth recommendations intended to improve CPE default behavior on IPv6 networks.
Specifically, it aims to clarify certain timer interactions on dynamic prefixes and improve behavior
in scenarios where network configuration information becomes invalid without explicit signaling
of that condition.

Document Quality:

The document so far has been approved by the V6OPS working group (successful working group
last call). The document does not specify new protocol, but rather changes to the default parameters
in existing protocols.

Personnel

Owen DeLong is the Document Shepherd
Fred Baker and Ron Bonica are the WG chairs
Warren Kumari is the responsible AD.


(3) Shepherd’s review

Prior to becoming shepherd, I was significantly involved in reviewing each revision of the document
and provided feedback and contributed improvements at each step. I have been active in the
debate of this I-D on the working group mailing list. This version of the document is ready for
publication. While there remains one dissenter in the working group, the working group has
reached consensus. His concerns are a particular corner case where DHCPv6 is being used to
distribute effectively static addresses.

(4) Shepherd’s concerns

I have no concerns about the depth or breadth of the reviews that have been performed.

Through the three revisions, the document has received substantial comments from the working
group and significantly improved with each revision as a result. Author has been very responsive
and incorporated feedback very well.

(5) Special Reviews Needed

I do not believe any special reviews are necessary for this document. The HOMENET
working group may wish to review this document as the proposed change in default behavior
could affect their work, but we believe the proposals here would be beneficial in such an
environment.

(6) Shepherd’s Concerns or issues

I have no concerns or issues with the document in its current form.

(7) IPR disclosures

There are no relevant IPR disclosures in this document. The document does not touch on
any technologies other than those in existing RFCs developed within the IETF.

(8) IPRs referencing this document

No IPR disclosures have been filed referencing this document and for the reasons stated in the
previous section, it is very unlikely one would be filed.

(9) WG consensus strength

This document had good participation and discussion in the working group and received fairly
broad support both prior to and during WG last call.

(10) Dissent

There remains one dissenter, but I would not characterize his discontent as extreme, nor has
he threatened appeal. His concern relates to a corner case where DHCP is being used by an
ISP to distribute (through DHCPv6-PD) a static prefix address which does not change. He is
concerned that the proposed default behavior here could either increase his configuration
complexity or result in an unnecessary local outage in the event that he loses connectivity
to his service provider. Multiple alternative solutions were suggested to him on the mailing
list. Since this document specifies only default behavior and does not preclude vendors
from providing knobs to alter that behavior, I believe his objection was more than adequately
addressed.

(11) ID nits

No nits found (once I got past the fact that the NITS interface via URL doesn’t cope well
with this draft for reasons beyond me). Feeding it the raw text worked fine.

(1) This draft is aimed at being an Informational RFC is the appropriate type because
        it provides clarifying information and suggested behaviors to address issues
        experienced in existing implementations.

(2) IESG Approval Announcement

Technical Summary:

This document sets forth recommendations intended to improve CPE default behavior on IPv6 networks.
Specifically, it aims to clarify certain timer interactions on dynamic prefixes and improve behavior
in scenarios where network configuration information becomes invalid without explicit signaling
of that condition.

Document Quality:

The document so far has been approved by the V6OPS working group (successful working group
last call). The document does not specify new protocol, but rather changes to the default parameters
in existing protocols.

Personnel

Owen DeLong is the Document Shepherd
Fred Baker and Ron Bonica are the WG chairs
Warren Kumari is the responsible AD.


(3) Shepherd’s review

Prior to becoming shepherd, I was significantly involved in reviewing each revision of the document
and provided feedback and contributed improvements at each step. I have been active in the
debate of this I-D on the working group mailing list. This version of the document is ready for
publication. While there remains one dissenter in the working group, the working group has
reached consensus. His concerns are a particular corner case where DHCPv6 is being used to
distribute effectively static addresses.

(4) Shepherd’s concerns

I have no concerns about the depth or breadth of the reviews that have been performed.

Through the three revisions, the document has received substantial comments from the working
group and significantly improved with each revision as a result. Author has been very responsive
and incorporated feedback very well.

(5) Special Reviews Needed

I do not believe any special reviews are necessary for this document. The HOMENET
working group may wish to review this document as the proposed change in default behavior
could affect their work, but we believe the proposals here would be beneficial in such an
environment.

(6) Shepherd’s Concerns or issues

I have no concerns or issues with the document in its current form.

(7) IPR disclosures

There are no relevant IPR disclosures in this document. The document does not touch on
any technologies other than those in existing RFCs developed within the IETF.

(8) IPRs referencing this document

No IPR disclosures have been filed referencing this document and for the reasons stated in the
previous section, it is very unlikely one would be filed.

(9) WG consensus strength

This document had good participation and discussion in the working group and received fairly
broad support both prior to and during WG last call.

(10) Dissent

There remains one dissenter, but I would not characterize his discontent as extreme, nor has
he threatened appeal. His concern relates to a corner case where DHCP is being used by an
ISP to distribute (through DHCPv6-PD) a static prefix address which does not change. He is
concerned that the proposed default behavior here could either increase his configuration
complexity or result in an unnecessary local outage in the event that he loses connectivity
to his service provider. Multiple alternative solutions were suggested to him on the mailing
list. Since this document specifies only default behavior and does not preclude vendors
from providing knobs to alter that behavior, I believe his objection was more than adequately
addressed.

(11) ID nits

No nits found (once I got past the fact that the NITS interface via URL doesn’t cope well
with this draft for reasons beyond me). Feeding it the raw text worked fine.