Hi Alice, Here is the updated xml file, I responded to all the questions in the xml. Let me know if there are unresolved issues.
~Tim On Mon, Jul 21, 2025 at 4:15 PM Timothy Winters <t...@qacafe.com> wrote: > Hi Alice, > > Thanks I have started reviewing the changes and will have an update this > week. > > ~Tim > > On Mon, Jul 21, 2025 at 3:16 PM Alice Russo <aru...@staff.rfc-editor.org> > wrote: > >> Tim, >> >> This is a reminder that we await word from you regarding the questions >> below and this document's readiness for publication as an RFC. The files >> are here: >> >> https://www.rfc-editor.org/authors/rfc9818.html >> https://www.rfc-editor.org/authors/rfc9818.pdf >> https://www.rfc-editor.org/authors/rfc9818.txt >> https://www.rfc-editor.org/authors/rfc9818.xml (source) >> >> Diff files of all changes from the approved Internet-Draft: >> https://www.rfc-editor.org/authors/rfc9818-diff.html >> https://www.rfc-editor.org/authors/rfc9818-rfcdiff.html (side by side) >> >> This page shows the AUTH48 status of your document: >> https://www.rfc-editor.org/auth48/rfc9818 >> >> Thank you. >> RFC Editor/ar >> >> > On Jul 3, 2025, at 5:51 PM, rfc-edi...@rfc-editor.org wrote: >> > >> > Greetings, >> > >> > While reviewing this document during AUTH48 ( >> https://www.rfc-editor.org/authors/rfc9818.html and other formats), >> please resolve the following questions, which are also in the XML file. >> > >> > 1) <!-- [rfced] How may this title be rephrased for clarity? >> > Also, is "LAN" needed in this title? (Neither "LAN" nor "local" is >> mentioned >> > in the abstract.) Do either of these options convey the intended >> meaning? >> > Please feel free to suggest otherwise. >> > >> > Original: >> > IPv6 CE Routers LAN DHCPv6 Prefix Delegation >> > >> > Current: >> > IPv6 Customer Edge (CE) Routers LAN DHCPv6 Prefix Delegation >> > >> > Option A: >> > DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs >> > >> > Option B: >> > DHCPv6 Prefix Delegation in LANs for IPv6 Customer Edge (CE) Routers >> > --> >> > >> > >> > 2) <!--[rfced] For clarity, how may this be rephrased? In particular, >> > the phrase "CE Router supporting prefix delegation" is unclear. >> > >> > Original: >> > The default configuration of CE Router supporting >> > prefix delegation is designed to be a flat model to support zero >> > configuration networking. >> > >> > Perhaps: >> > For prefix delegation that supports CE routers, the default >> > configuration is designed to be a flat model to support >> > zero-configuration networking. >> > >> > Or simply: >> > For prefix delegation that supports CE routers, the default >> > configuration is a flat model to support zero-configuration >> > networking. >> > --> >> > >> > >> > 3) <!--[rfced] Please clarify "multi-provisioned networks". Is there >> > another term that is more common? The term "multi-provisioned" >> > does not appear in past RFCs or current Internet-Drafts. >> > >> > Original: >> > This document does not cover dealing with multi-provisioned networks >> > with more than one provider. >> > --> >> > >> > >> > 4) <!--[rfced] Which update do you prefer, as this definition is >> missing 'the', >> > but perhaps you prefer to match the cited document? >> > >> > Original: IPv6 node: A device that implements IPv6 protocol. >> > >> > Option A: IPv6 node: A device that implements IPv6. >> > (to match RFC 8200, which is cited in the lead-in text) >> > >> > Option B: IPv6 node: A device that implements the IPv6 protocol. >> > --> >> > >> > >> > 5) <!-- [rfced] FYI, for expanding GUA, "Unique" has been changed to >> > "Unicast" in order to match RFC 4291. Please review. >> > >> > Original: >> > * GUA:Global Unique Addresses, as defined in [RFC4291]. >> > >> > Current: >> > GUA: Global Unicast Address, as defined in [RFC4291]. >> > --> >> > >> > >> > 6) <!--[rfced] Please clarify; how should this fragment be updated to >> > be a sentence? >> > >> > Original: >> > The end-user network for IPv6 that is a stub network. >> > --> >> > >> > >> > 7) <!--[rfced] Please review this update for accuracy; due to "its", >> > the subject ("IPv6 CE routers") has been changed to singular. It >> > currently reads that a single router could have more than one LAN >> interface. >> > >> > Original: >> > LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment >> > according to Section 13.3 of [RFC8415] (Identity Association >> > for Prefix Delegation (IA_PD) option) on its LAN >> > interface(s). >> > >> > Current: >> > LPD-1: Each IPv6 CE router MUST support IPv6 prefix assignment >> > according to Section 13.3 of [RFC8415] (Identity Association >> > for Prefix Delegation (IA_PD) option) on its LAN >> > interface(s). >> > >> > Alternatively (both plural): >> > LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment >> > according to Section 13.3 of [RFC8415] (Identity Association >> > for Prefix Delegation (IA_PD) option) on their LAN >> > interfaces. >> > --> >> > >> > >> > 8) <!--[rfced] Because the second sentence is singular, should the >> first >> > sentence be parallel? >> > >> > Original: >> > LPD-2: IPv6 CE routers MUST assign a prefix from the delegated >> > prefix as specified by L-2 in Section 4.3 of [RFC7084]. If >> > insufficient prefixes are available the IPv6 CE Router MUST >> > log a system management error. >> > >> > Perhaps: >> > LPD-2: Each IPv6 CE router MUST assign a prefix from the delegated >> > prefix as specified by L-2 in Section 4.3 of [RFC7084]. If >> > insufficient prefixes are available, the IPv6 CE router MUST >> > log a system management error. >> > --> >> > >> > >> > 9) <!--[rfced] Should "both ULA and GUA" be both "ULAs and GUAs"? If >> so, >> > please review whether "the GUA" is accurate in the second phrase. >> > >> > Original: >> > LPD-9: If an IPv6 CE router is provisioning both ULA and GUA via >> > prefix delegation, the GUA SHOULD appear first in the DHCPv6 >> > packets. >> > >> > Perhaps: >> > LPD-9: If an IPv6 CE router is provisioning both ULAs and GUAs via >> > prefix delegation, the GUA SHOULD appear first in the DHCPv6 >> > packets. >> > >> > Or (singular): >> > LPD-9: If an IPv6 CE router is provisioning both the ULA and the GUA >> via >> > prefix delegation, the GUA SHOULD appear first in the DHCPv6 >> > packets. >> > --> >> > >> > >> > 10) <!--[rfced] Terminology >> > >> > a) This term appeared inconsistently and has been updated to the latter. >> > Please let us know if you prefer otherwise. >> > >> > CE Router vs. CE router [based on usage in RFC 7084] >> > >> > b) Capitalization of these terms is not consistent. Please let us >> > know your preference. >> > >> > Prefix Delegation vs. prefix delegation >> > >> > Delegated Prefix (in LPD-6) vs. delegated prefix (in LPD-2, LPD-5) >> > >> > c) Please review usage of this term and let us know if any updates are >> needed. >> > We note RFC 8415 uses the hyphen for the "prefix-length" field. >> > >> > prefix-length (3 instances) vs. prefix length (2 instances) >> > --> >> > >> > >> > 11) <!-- [rfced] FYI, the original URL provided for [eRouter] is to the >> most >> > recent version of this CableLabs specification, Version I22, which was >> > published in May 2024, so we updated the reference as follows. >> > >> > Original: >> > [eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification Version >> > I21", February 2022, >> > <https://www.cablelabs.com/specifications/CM-SP-eRouter>. >> > >> > Current: >> > [eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification", Data- >> > Over-Cable Service Interface Specifications, Version I22, >> > May 2024, >> > <https://www.cablelabs.com/specifications/CM-SP-eRouter>. >> > >> > Re: "in Section 8.5 of CableLabs IPv6 eRouter specification [eRouter]", >> > we note that Section 8.5 has the same title in I21 and I122. >> > However, if you prefer to reference Version I21, please let us know >> > (and in that case, we recommend this URL: >> > https://www.cablelabs.com/specifications/CM-SP-eRouter?v=I21). >> > --> >> > >> > >> > Thank you. >> > >> > RFC Editor/ar >> > >> >> >> > On Jul 3, 2025, at 6:01 PM, rfc-edi...@rfc-editor.org wrote: >> > >> > Tim, >> > >> > One additional question: >> > >> > 12) Re: LPD-6, what does "that is not assigned" refer to? As far as >> verb agreement, it does not match "packets". >> > >> > Original: >> > IPv6 CE routers MUST continue to drop packets >> > including destination address that is not assigned to the >> > LAN or delegated. >> > >> > Perhaps: >> > IPv6 CE routers MUST continue to drop packets, >> > including destination address, that are not assigned to the >> > LAN or delegated. >> > >> > Thank you. >> > RFC Editor/ar >> >> >> >>
<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="info" ipr="trust200902" updates="7084" obsoletes="" docName="draft-ietf-v6ops-cpe-lan-pd-09" number="9818" consensus="true" xml:lang="en" submissionType="IETF" tocInclude="true" sortRefs="false" symRefs="true" version="3"> <front> <title abbrev="DHCPv6 PD on IPv6 CE Routers in LANs">DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs</title> <seriesInfo name="RFC" value="9818"/> <author fullname="Timothy Winters" initials="T." surname="Winters"> <organization abbrev="QA Cafe">QA Cafe</organization> <address> <postal> <street>100 Main Street, Suite #212</street> <city>Dover</city> <region>NH</region> <code>03820</code> <country>United States of America</country> </postal> <email>t...@qacafe.com</email> </address> </author> <date month="July" year="2025"/> <area>OPS</area> <workgroup>v6ops</workgroup> <keyword>IPv6</keyword> <keyword>Internet Protocol Version 6</keyword> <keyword>DHCPv6</keyword> <!-- [rfced] How may this title be rephrased for clarity? Also, is "LAN" needed in this title? (Neither "LAN" nor "local" is mentioned in the abstract.) Do either of these options convey the intended meaning? Please feel free to suggest otherwise. Original: IPv6 CE Routers LAN DHCPv6 Prefix Delegation Current: IPv6 Customer Edge (CE) Routers LAN DHCPv6 Prefix Delegation Option A: DHCPv6 Prefix Delegation on IPv6 Customer Edge (CE) Routers in LANs Option B: DHCPv6 Prefix Delegation in LANs for IPv6 Customer Edge (CE) Routers [twinters] - Added a short mention of LAN in the abstract and went with Option A for the Title. --> <abstract> <t>This document defines requirements for IPv6 Customer Edge (CE) routers to support DHCPv6 Prefix Delegation for distributing available prefixes to LAN devices that were delegated to a IPv6 CE router. This document updates RFC 7084.</t> </abstract> </front> <middle> <section> <name>Introduction</name> <t>This document describes guidelines for DHCPv6 Prefix Delegation in IPv6 Customer Edge (CE) routers <xref target="RFC7084"/> in order to properly utilize the IPv6 prefixes delegated by service providers. Many service providers assign larger address blocks than /64 to CE routers, as recommended in <xref target="RFC6177"/>. If an IPv6 CE router does not support the Identity Association for Prefix Delegation (IA_PD) Prefix Option (<xref target="RFC8415" section="21.21"/>) on the LAN, it will not be able to assign any prefixes beyond its local interfaces, limiting the usefulness of assigning prefixes larger than /64 by the operator. Supporting IA_PD on the LAN interfaces of a CE router will allow those unused prefixes to be distributed into a network. Note that efforts such as those of the Stub Networking Auto Configuration (SNAC) Working Group depend on IPv6 prefixes being properly distributed in the LAN.</t> <t>Two models, hierarchical prefix and flat, were proposed in the past for prefix sub-delegation beyond an IPv6 CE router. Hierarchical prefix delegation requires an IPv6 CE router to sub-delegate IPv6 prefixes based on a set of rules. If more than one router uses hierarchical prefix delegation, an IPv6 prefix tree is created. When no routing protocol is enabled to discover the network topology, it is possible to have an unbalanced prefix delegation tree, which leads to running out of prefixes. More information on hierarchical prefix delegation can be found, e.g., in Section 8.5 of CableLabs IPv6 eRouter specification <xref target="eRouter"/>. A flat prefix delegation requires the router to be provisioned with the initial prefix and to assign /64 prefixes to all other prefix requests from routers in the LAN-facing interface. <!--[rfced] For clarity, how may this be rephrased? In particular, the phrase "CE Router supporting prefix delegation" is unclear. Original: The default configuration of CE Router supporting prefix delegation is designed to be a flat model to support zero configuration networking. Perhaps: For prefix delegation that supports CE routers, the default configuration is designed to be a flat model to support zero-configuration networking. Or simply: For prefix delegation that supports CE routers, the default configuration is a flat model to support zero-configuration networking. [twinters] - I just left out the mention of prefix delegation, as it confused the sentence. --> <!--[rfced] Please clarify "multi-provisioned networks". Is there another term that is more common? The term "multi-provisioned" does not appear in past RFCs or current Internet-Drafts. Original: This document does not cover dealing with multi-provisioned networks with more than one provider. [twinters] - I changed this to multi-prefix, thanks for the catch. --> The default configuration of CE router is designed to be a flat model to support zero-configuration networking.</t> <t>This document does not cover dealing with multi-prefix networks with more than one provider. Due to the complexity of a solution that would require routing, provisioning, and policy, this is out of scope of this document.</t> </section> <section anchor="Requirements_Language"> <name>Requirements Language</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> <t>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 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 deployed and planned common IPv6 access networks.</t> </section> <section anchor="Terminology"> <name>Terminology</name> <t>The document makes use of the following terms, some of which are from <xref target="RFC8200" section="2"/> </t> <!--[rfced] Which update do you prefer, as this definition is missing 'the', but perhaps you prefer to match the cited document? Original: IPv6 node: A device that implements IPv6 protocol. Option A: IPv6 node: A device that implements IPv6. (to match RFC 8200, which is cited in the lead-in text) Option B: IPv6 node: A device that implements the IPv6 protocol. [twinters] - Fixed with Option A. --> <!-- [rfced] FYI, for expanding GUA, "Unique" has been changed to "Unicast" in order to match RFC 4291. Please review. Original: * GUA:Global Unique Addresses, as defined in [RFC4291]. Current: GUA: Global Unicast Address, as defined in [RFC4291]. [twinters] - Agree. --> <dl spacing="normal" newline="false"> <dt>IPv6 node:</dt><dd>A device that implements IPv6.</dd> <dt>IPv6 router:</dt><dd>An IPv6 node that forwards IPv6 packets not explicitly addressed to itself.</dd> <dt>IPv6 host:</dt><dd>An IPv6 node that is not a router.</dd> <dt>ULA:</dt><dd>Unique Local Address, as defined in <xref target="RFC4193"/>.</dd> <dt>GUA:</dt><dd>Global Unicast Address, as defined in <xref target="RFC4291"/>.</dd> </dl> </section> <section> <name>IPv6 End-User Network Architecture</name> <!--[rfced] Please clarify; how should this fragment be updated to be a sentence? Original: The end-user network for IPv6 that is a stub network. --> <t>The end-user network for IPv6 contains stub networks. <xref target="fig-1"/> illustrates the model topology.</t> <figure anchor="fig-1"> <name>Example IPv6 End-User Topology</name> <artwork align="center"><![CDATA[ +-----------+ | Service | | Provider | | Router | +-----+-----+ | | | Customer | Internet Connection | +-----v-----+ | IPv6 | | CE | | Router | +-----+-----+ | +------+-------+ | | | | +---+----+ +-----+-----+ | IPv6 | | | | Host | | Router | | | | | +--------+ +-----+-----+ | | +---+----+ | IPv6 | | Host | | | +--------+]]></artwork> </figure> </section> <section anchor="Requirements"> <name>Requirements</name> <t> IPv6 CE routers distribute configuration information obtained during WAN interface provisioning to LAN-facing IPv6 hosts and routers. A CE router that is compliant with <xref target="RFC7084"/> would only provide IPv6 hosts with configuration information. This document allows for addressing and routing of IPv6 prefixes to both hosts and routers. These requirements are in addition to the ones in <xref target="RFC7084" section="4.3"/>.</t> <section> <name>LAN Prefix Delegation Requirements (LPD)</name> <ol spacing="normal" type="LPD-%d:" indent="9"><li> <!--[rfced] Please review this update for accuracy; due to "its", the subject ("IPv6 CE routers") has been changed to singular. It currently reads that a single router could have more than one LAN interface. Original: LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment according to Section 13.3 of [RFC8415] (Identity Association for Prefix Delegation (IA_PD) option) on its LAN interface(s). Current: LPD-1: Each IPv6 CE router MUST support IPv6 prefix assignment according to Section 13.3 of [RFC8415] (Identity Association for Prefix Delegation (IA_PD) option) on its LAN interface(s). Alternatively (both plural): LPD-1: IPv6 CE routers MUST support IPv6 prefix assignment according to Section 13.3 of [RFC8415] (Identity Association for Prefix Delegation (IA_PD) option) on their LAN interfaces. [twinters] - The current proposal works for me. --> <t>Each IPv6 CE router <bcp14>MUST</bcp14> support IPv6 prefix assignment according to <xref target="RFC8415" section="13.3"/> (Identity Association for Prefix Delegation (IA_PD) option) on its LAN interface(s).</t> </li> <!--[rfced] Because the second sentence is singular, should the first sentence be parallel? Original: LPD-2: IPv6 CE routers MUST assign a prefix from the delegated prefix as specified by L-2 in Section 4.3 of [RFC7084]. If insufficient prefixes are available the IPv6 CE Router MUST log a system management error. Perhaps: LPD-2: Each IPv6 CE router MUST assign a prefix from the delegated prefix as specified by L-2 in Section 4.3 of [RFC7084]. If insufficient prefixes are available, the IPv6 CE router MUST log a system management error. [twinters] - Added the each. --> <li> <t>Each IPv6 CE routers <bcp14>MUST</bcp14> assign a prefix from the delegated prefix as specified by L-2 in <xref target="RFC7084" section="4.3"/>. If insufficient prefixes are available, the IPv6 CE router <bcp14>MUST</bcp14> log a system management error.</t> </li> <li> <t>The prefix assigned to a link <bcp14>MUST NOT</bcp14> change in the absence of a local policy or a topology change.</t> </li> <li> <t>After LAN link prefix assignments, the IPv6 CE router <bcp14>MUST</bcp14> keep the remaining IPv6 prefixes available to other routers via Prefix Delegation.</t> </li> <li> <t>IPv6 CE routers <bcp14>MUST</bcp14> maintain a local routing table that is dynamically updated with leases and the associated next hops as they are delegated to clients. Packets with destination addresses in a delegated prefix MUST be routed to that prefix regardless of which interface they are received on. When a delegated prefix is released or expires, the associated route <bcp14>MUST</bcp14> be removed from the IPv6 CE router's routing table. A delegated prefix expires when the valid lifetime assigned in the IA_PD expires without being renewed. When a prefix is released or expires, it <bcp14>MUST</bcp14> be returned the pool of available prefixes.</t> </li> <!--[rfced] Re: LPD-6, what does "that is not assigned" refer to? As far as verb agreement, it does not match "packets". Original: IPv6 CE routers MUST continue to drop packets including destination address that is not assigned to the LAN or delegated. Perhaps: IPv6 CE routers MUST continue to drop packets, including destination address, that are not assigned to the LAN or delegated. [twinters] - Updated as suggested. --> <li> <t>By default, the IPv6 CE router filtering rules <bcp14>MUST</bcp14> allow forwarding of packets with an outer IPv6 header containing a source address belonging to delegated prefixes, along with reciprocal packets from the same flow, following the recommendations of <xref target="RFC6092"/>. This updates WPD-5 of <xref target="RFC7084"/> to not drop packets from prefixes that have been delegated. IPv6 CE routers <bcp14>MUST</bcp14> continue to drop packets, including destination address, that are not assigned to the LAN or delegated.</t> </li> <li> <t>The IPv6 CE routers <bcp14>MUST</bcp14> provision IA_PD prefixes with a prefix-length of 64 on the LAN-facing interface unless configured to use a different prefix-length by the CE router administrator. The prefix-length of 64 is used as that is the current prefix-length supported by SLAAC <xref target="RFC4862"/>. For hierarchical prefix delegation, a prefix-length shorter than 64 may be configured.</t> </li> <li> <t>IPv6 CE routers configured to generate a ULA prefix as defined in ULA-1 of <xref target="RFC7084" section="4.3"/> <bcp14>MUST</bcp14> continue to provision available GUA IPv6 prefixes.</t> </li> <li> <!--[rfced] Should "both ULA and GUA" be both "ULAs and GUAs"? If so, please review whether "the GUA" is accurate in the second phrase. Original: LPD-9: If an IPv6 CE router is provisioning both ULA and GUA via prefix delegation, the GUA SHOULD appear first in the DHCPv6 packets. Perhaps: LPD-9: If an IPv6 CE router is provisioning both ULAs and GUAs via prefix delegation, the GUA SHOULD appear first in the DHCPv6 packets. Or (singular): LPD-9: If an IPv6 CE router is provisioning both the ULA and the GUA via prefix delegation, the GUA SHOULD appear first in the DHCPv6 packets. [twinters] - Updated to singular. --> <t>If an IPv6 CE router is provisioning both a ULA and GUA via prefix delegation, the GUA <bcp14>SHOULD</bcp14> appear first in the DHCPv6 packets.</t> </li> <li> <t>IPv6 CE routers <bcp14>MUST NOT</bcp14> delegate prefixes via DHCPv6 on the LAN using lifetimes that exceed the remaining lifetimes of the corresponding prefixes learned on the WAN.</t> </li> </ol> </section> </section> <section anchor="Security"> <name>Security Considerations</name> <t>This document does not add any new security considerations beyond those mentioned in <xref target="RFC8213" section="4"/>, <xref target="RFC8415" section="22"/>, and <xref target="RFC6092" section="6"/>.</t> </section> <section anchor="IANA"> <name>IANA Considerations</name> <t> This document has no IANA actions.</t> </section> </middle> <!--[rfced] Terminology a) This term appeared inconsistently and has been updated to the latter. Please let us know if you prefer otherwise. CE Router vs. CE router [based on usage in RFC 7084] [twinters] - Agree. b) Capitalization of these terms is not consistent. Please let us know your preference. Prefix Delegation vs. prefix delegation Delegated Prefix (in LPD-6) vs. delegated prefix (in LPD-2, LPD-5) [twinters] - delegated prefix (no capitalization) is correct, fixed it one other place. c) Please review usage of this term and let us know if any updates are needed. We note RFC 8415 uses the hyphen for the "prefix-length" field. prefix-length (3 instances) vs. prefix length (2 instances) --> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7084.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8213.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6092.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6177.xml"/> <!-- [rfced] FYI, the original URL provided for [eRouter] is to the most recent version of this CableLabs specification, Version I22, which was published in May 2024, so we updated the reference as follows. Original: [eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification Version I21", February 2022, <https://www.cablelabs.com/specifications/CM-SP-eRouter>. Current: [eRouter] CableLabs, "IPv4 and IPv6 eRouter Specification", Data- Over-Cable Service Interface Specifications, Version I22, May 2024, <https://www.cablelabs.com/specifications/CM-SP-eRouter>. Re: "in Section 8.5 of CableLabs IPv6 eRouter specification [eRouter]", we note that Section 8.5 has the same title in I21 and I122. However, if you prefer to reference Version I21, please let us know (and in that case, we recommend this URL: https://www.cablelabs.com/specifications/CM-SP-eRouter?v=I21). --> <reference anchor="eRouter" target="https://www.cablelabs.com/specifications/CM-SP-eRouter";> <front> <title>IPv4 and IPv6 eRouter Specification</title> <author fullname="CableLabs" surname="CableLabs"> <organization/> </author> <date month="May" year="2024"/> </front> <refcontent>Data-Over-Cable Service Interface Specifications, Version I22</refcontent> </reference> </references> </references> <section anchor="Acknowledgements" numbered="false"> <name>Acknowledgements</name> <t> Thanks to the following people for their guidance and feedback: <contact fullname="Marion Dillon"/>, <contact fullname="Erik Auerswald"/>, <contact fullname="Esko Dijk"/>, <contact fullname="Tim Carlin"/>, <contact fullname="Richard Patterson"/>, <contact fullname="Ted Lemon"/>, <contact fullname="Michael Richardson"/>, <contact fullname="Martin Huneki"/>, <contact fullname="Gabor Lencse"/>, <contact fullname="Ole Troan"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="David Farmer"/>, <contact fullname="Kyle Rose"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Tim Chown"/>, <contact fullname="Ron Bonica"/>, and <contact fullname="Erica Johnson"/>.</t> </section> </back> </rfc>
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
