Hi Gunter,
Thanks for your quick reply. Agree with your concern—when operators consider
deploying DHCP for SRv6, especially involving CPEs at the edge, your security
concern definitely needs careful consideration. Much appreciated!
Best Regards,
Weiqiang Cheng
---原始邮件---
发件人: "Gunter van de Velde (Nokia)" <[email protected]>
发送时间: 2026-03-03 22:16:42
收件人: Weiqiang Cheng <[email protected]>
The IESG <[email protected]>
抄送: "aretana.ietf " <[email protected]>
buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]>
spring-chairs <[email protected]>
spring <[email protected]>
主题: RE: [spring] Re: Gunter Van de Velde's Discuss
ondraft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)
Hi Weiqiang Cheng,
Thank you for the update.
Your text does cover the key security concern for a SRv6 DHCP client running on
customer premises, thank you for the update, eventhough it rather brief.
That said, I have serious architectural security concerns about positioning an
SRv6 border router on a CPE home device or appliance. That concern sits outside
the scope of DHCP and is likely a discussion better suited for the SPRING WG if
that is something the WG believes is a great idea or not.
I’ll clear my blocking DISCUSS on this document. Thanks again for the update.
G/
From: Weiqiang Cheng <[email protected]> Sent: Tuesday, March 3,
2026 2:46 AM To: chengweiqiang <[email protected]> Gunter van de
Velde (Nokia) <[email protected]> The IESG <[email protected]> Cc:
aretana.ietf <[email protected]> buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]> spring-chairs
<[email protected]> spring <[email protected]> Subject: Re: [spring] Re:
Gunter Van de Velde's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Hi Gunter，
We have submitted the new version-15,
In the security section, security considerations have been added.
B.R.
Weiqiang Cheng
From: Weiqiang Cheng
Date: 2026-02-12 10:05
To: Gunter van de Velde \(Nokia\) The IESG
CC: aretana.ietf buraglio draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
spring-chairs spring
Subject: [spring] Re: Gunter Van de Velde's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)
Dear Gunter,
Thank you for your valuable feedback. I fully understand and agree with your
suggestion regarding the importance of clarifying the risks associated with
extending segment routing to CPE devices.
In response to your comment, we will add a brief discussion in the Security
Considerations section of the next revision.
Please let me know if you have any further suggestions or require additional
adjustments.
Best regards,
Weiqiang
From: Gunter van de Velde \(Nokia\)
Date: 2026-02-11 21:50
To: Weiqiang Cheng The IESG
CC: aretana.ietf buraglio draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
spring-chairs spring
Subject: [spring] Re: Gunter Van de Velde's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)
I saw that version -14 was posted.
Thank you for clearing and resolving most of the open discuss’s.
The last one standing is:
“
[DISCUSS#3] in the security section i find no discussion on the risk of having
locators or sub-sets of locators leak to hosts? This could pose a serious
infrastructure security concern when the CPE is located at customer premise.
[Co-authors] We fully acknowledge the value of explicitly highlighting such
risks. We will add text in the draft as you suggested. This clarification will
be included in the Security Considerations section of the next revision.
GV2> Thank you
“
I found in the security section the following new testblob:
“
As a border node device,
the CPE MUST implement appropriate traffic filtering capabilities on
both its internal and external interfaces, as required by Section 5.1
of [RFC8754].
“
While the document notes that filtering is required, it doesn’t explain why
extending segment routing to the CPE is risky. Traditionally, SR-MPLS networks
terminate MPLS at the BRAS, not at the customer’s CPE. Connecting the core
segment-routing backbone directly to a CPE can introduce security concerns.
Adding a brief discussion of these risks and their implications in the security
section will help clarify the need for the recommended filters and safeguards.
Brgds,
G/
From: Gunter van de Velde (Nokia) Sent: Monday, January 26, 2026 10:47 AM To:
'Weiqiang Cheng' <[email protected]> The IESG <[email protected]> Cc:
aretana.ietf <[email protected]> buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]> spring-chairs
<[email protected]> spring <[email protected]> Subject: RE: Gunter Van de
Velde's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with
DISCUSS)
Hi Weigiang,
Thanks for the feedbacks.
Inline GV2>
From: Weiqiang Cheng <[email protected]> Sent: Thursday, January
22, 2026 6:53 AM To: Gunter van de Velde (Nokia)
<[email protected]> The IESG <[email protected]> Cc: aretana.ietf
<[email protected]> buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]> spring-chairs
<[email protected]> spring <[email protected]> Subject: Re: Gunter Van de
Velde's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with
DISCUSS)
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Dear Gunter,
Thank you for your review and valuable discussion points. Please find our
responses inline below.
Best regards,
Weiqiang
From: Gunter Van de Velde via Datatracker
Date: 2026-01-21 19:16
To: The IESG
CC: aretana.ietf buraglio draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
spring-chairs spring
Subject: Gunter Van de Velde's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS)
Gunter Van de Velde has entered the following ballot position for
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
# Gunter Van de Velde, RTG AD, comments for
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13
# # The line numbers used are rendered from IETF idnits tool:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13.txt
# This document describes a method for assigning SRv6 locators to SRv6 Segment
Endpoint Nodes using DHCPv6.
[DISCUSS#1] One thing I found myself wondering about is how these locators
relate to the IGP algorithms they’re associated with. It may very well be that
the current proposal is intentionally algorithm-agnostic, and that’s perfectly
fine. With this DISCUSS, I’m mainly trying to better understand how this
approach aligns with IGP flexible algorithms and to understand if this may be
potentially described within the document.
[Co-authors] The current version does not consider adopting Flex-algo, mainly
for two reasons: First, in many application scenarios, customer-side terminals
do not support IGP second, there is currently no clear demand for using
Flex-algo. As per your suggestion, the authors will further analyze the value
of IGP flexible algorithms in this scenario in subsequent work.
GV2> I’m not fully convinced this is just about whether or not to adopt
flex-algo. The document is clearly about SRv6 locators, which is fine. What I’m
trying to better understand is what happens if a locator ends up being
associated by the network with a non-default algorithm (say 128–255) instead of
algorithm 0.
>From your response, it sounds like the assumption is that locators used with
>this dhcpv6 technology are flex-algo agnostic. If that’s the case, does that
>mean the locators discussed here are implicitly tied to algorithm 0 only, or
>are locators for algorithms 128–255 also in scope? Maybe in future there is an
>additional dhcp extension to signal additional Locator attributes?
If there is a working assumption regarding implicit algorithm 0, it might be
worth spelling it out more explicitly in the document. That would help readers
avoid having to infer the intent or go on a bit of a treasure hunt to
understand the gap and its implications.
[DISCUSS#2] In addition, I’d like to get a sense of whether it would be
considered good or bad practice for the SRv6 locator of algorithm 0 (assuming,
as I suspect, that non-zero algorithms are not applicable here) to have a
portion of its address space carved out and used for direct DHCP-based
assignment to attached hosts. Operational guidance on this may be useful.
[Co-authors] As mentioned above regarding the scenario of IGP flexible
algorithms, we will analyze the requirements further. In this document, we will
add some text on operational guidance in next version.
GV2> Thanks. Let me know when there is a new document version posted.
[DISCUSS#3] in the security section i find no discussion on the risk of having
locators or sub-sets of locators leak to hosts? This could pose a serious
infrastructure security concern when the CPE is located at customer premise.
[Co-authors] We fully acknowledge the value of explicitly highlighting such
risks. We will add text in the draft as you suggested. This clarification will
be included in the Security Considerations section of the next revision.
GV2> Thank you
[DISCUSS#4] The document does not talk about SRv6 csid locators and csid
structures (RFC9800). Is that intentional?
[Co-authors] This draft can support the csid defined in RFC9800. In Figure 3,
the IA Locator Option Format can distinguish between Locator Block and Locator
Node, and can handle compressed SID lists. In the new version of the draft, we
will add some text, reference RFC9800, and clearly state support for CSID.
GV2> Thank you. Looking forward for a next version.
Be well,
G/
I’m looking forward to your thoughts and clarification on this.
Gunter Van de Velde,
Routing AD
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
