Hi Joel & Robert,
Thank you for your valuable comments.
We will add some explicit text in the new version to state that this draft
aligns with the underlying SRv6 RFCs when the DHCP is used.
B.R.
Weiqiang Cheng
From: Joel Halpern
Date: 2023-07-15 02:25
To: Robert Raszuk
CC: Weiqiang Cheng; wangaijun; spring;
draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org
Subject: Re: [spring] spring WG Adoption Call for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp
My assumption in suggesting the solution I did was that the DHCP server would
be configured properly and would comply with what we say the requirements are.
I am not asking the protocol to enforce the domain. I am asking that the
document be clear about when this DHCP usage is consistent with the underlying
RFCs. And to tell folks not to violate those RFCs.
If the authors or the WG want to take it even further, that is their right /
privilege.
Yours,
Joel
On 7/14/2023 2:19 PM, Robert Raszuk wrote:
Ok last email on this ... let's talk IETF and standardization as you prefer.
You asked:
Speaking as an individual participant, it seems to me that the description of
using CPE as SRv6 endpoints needs to state explicitly and clearly that this
assumes that the CPE are managed by the access operator, and that all of the
relevant endpoints are part of a single operator / domain.
But subject draft is defining two new DHCPv6 options OPTION_IA_SRV6_LOCATOR &
OPTION_IALOCATOR. No more no less. There is no OPTION_LIMITED_DOMAIN_MEMBER
which when received the former two can be processed.
So any client will be able to get those options.
If you (or others) would be really trying to make this work standards wise you
would define an extension to protocol(s) to indicate that the querying node is
part of what you called a "limited domain" or not. Today to the best of my
understanding such boundary is protocol wise undefined.
Otherwise irrespective if authors add proposed text or not the behaviour will
be identical in practice.
Kind regards,
Robert
On Fri, Jul 14, 2023 at 6:27 PM Joel Halpern <j...@joelhalpern.com> wrote:
You may not subscribe to the notion of limited domains. But the RFCs do.
Hence, the WG is required to do so. An operator can of course do anything they
want, and they choose their risks. But IETF standardization work is subject to
the restrictions we as a community agree to.
Yours,
Joel
On 7/14/2023 12:25 PM, Robert Raszuk wrote:
> then anyone, almost anywhere in the Internet, can inject such packets.
Sure can. And just like without SRv6 I am protecting my hosts from such
injections.
See SRv6 has a very broad range of use cases. But it does not promise a secure
and encrypted pipe (at least last time I checked). There are better protocols
focusing just to do that.
So imagine I want to enhance my packets between v6 speaking hosts with demux
value so when the packet arrives it goes to its own dedicated namespace. And as
before I am protecting such namespaces from attacks the same way I protect my
default namespace (as example I do have on secure machines a whitelisted set of
rules who can talk to me directly).
That is why I never subscribed to this notion of limited domain in respect to
building SRv6 walls :)
Cheers,
Robert
On Fri, Jul 14, 2023 at 6:15 PM Joel Halpern <jmh.dir...@joelhalpern.com> wrote:
If a deployment of SRv6 uses unsecured tunnels as a means to deliver SRv6
packets between pieces of the domain, then anyone, almost anywhere in the
Internet, can inject such packets. That is not a limited domain. It is a wide
open domain.
Yours,
Joel
On 7/14/2023 12:01 PM, Robert Raszuk wrote:
Why would you expect this to always unconditionally use "secure tunnels" ? For
lot's of applications basic encapsulation is sufficient. Note that I mentioned
the case where my sites are connected over ISP not the Internet.
Besides if there is concern about data protection or data integrity lot's of
applications use app level encryption so asking for transport tunnel security
would be redundant at best.
Thx,
R.
On Fri, Jul 14, 2023 at 5:42 PM Joel Halpern <j...@joelhalpern.com> wrote:
If they want to specify in the draft that the CPE are operator managed by a
single operator, and that they use secure tunnels (not just arbitrary overlay)
between the BRAS then we can as a WG see if that suffices. But the draft
doesn't currently say that.
Yours,
Joel
On 7/14/2023 11:40 AM, Robert Raszuk wrote:
Joel,
Limited domain (if you will) can be also build in the overlay - unless you
point me to any standards track RFC which says otherwise. If I connect over ISP
with v6 I can run my own limited domain over such ISP between hosts in my
sites.
Of course ISP may recognize that I am actually sending v6 packets with
extension headers and drop those ... but this is not a concern for this thread
nor for IETF. In such a case I will would switch an ISP :)
Cheers,
R.
On Fri, Jul 14, 2023 at 5:33 PM Joel Halpern <j...@joelhalpern.com> wrote:
Nope.
The host case for SRv6 is for hosts run by the operator within their domain.
8986 explicitly requires that SRv6 be used only within a limited domain.
It is clear from other comments that you do not like this restriction. That is
your priviledge as an individual. But IETF work has to respect the restriction.
Yours,
Joel
On 7/14/2023 11:28 AM, Robert Raszuk wrote:
Joel,
Point 1:
Reading RFC8986 I see in section 4.16.2 clear definition of SRv6 running on
user hosts.
One of the applications of the USP flavor is when a packet with an SRH is
destined to an
application on hosts with smartNICs ("Smart Network Interface Cards")
implementing
SRv6. The USP flavor is used to remove the consumed SRH from the extension
header
chain before sending the packet to the host.
Point 2:
If two hosts want for whatever reason to use SRv6 over the provider's IPv6
underlay (and they may possibly benefit from DHCP allocation of locators) they
can happily do so and I see nowhere in any SRv6 spec any mandate which would
state a word against such deployment model.
Thx,
Robert
PS, This entire notion of "limited domain" is as you very well know the history
is not a very technical thing ...
On Fri, Jul 14, 2023 at 5:08 PM Joel Halpern <j...@joelhalpern.com> wrote:
Speaking as an individual participant, it seems to me that the description of
using CPE as SRv6 endpoints needs to state explicitly and clearly that this
assumes that the CPE are managed by the access operator, and that all of the
relevant endpoints are part of a single operator / domain. Otherwise, this
usage violates the base rules for SRv6.
Personally, I would like to see this fixed before adoption completes.
Yours,
Joel
On 7/14/2023 9:44 AM, Joel Halpern wrote:
I probably need to re-read the draft. Does the draft assume the CPE is part of
the operator domain? Remember that SRv6 MUST be used ONLY within a limited
domain?
Yours,
Joel
On 7/14/2023 2:22 AM, Weiqiang Cheng wrote:
Hi Aijun,
Thank you very much for your comments.
We will add some text to describe that the CPE utilizes locators obtained
through DHCP to provide differentiated services.
Best Regards
Weiqiang Cheng
发件人： Aijun Wang
发送时间： 2023-07-14 11:19
收件人： 'Alvaro Retana'; spring@ietf.org
抄送： draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org;
spring-cha...@ietf.org
主题： 答复: [spring] spring WG Adoption Call for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp
Support its adoption.
It will be more convincible to add some descriptions in the document that the
CPE itself needs to obtain different IPv6 address that can differentiate the
services that it can provide.
Best Regards
Aijun Wang
China Telecom
-----邮件原件-----
发件人: spring-boun...@ietf.org [mailto:spring-boun...@ietf.org] 代表 Alvaro Retana
发送时间: 2023年7月5日 20:00
收件人: spring@ietf.org
抄送: draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org;
spring-cha...@ietf.org
主题: [spring] spring WG Adoption Call for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp
Dear WG:
This message starts a two-week adoption call for
draft-cheng-dhc-distribute-srv6-locator-by-dhcp, ending on July/19.
It "describes the method of assigning locators to SRv6 Endpoints through
DHCPv6".
https://datatracker.ietf.org/doc/draft-cheng-spring-distribute-srv6-locator-by-dhcp/
Please review the draft and consider whether you support its adoption by the
WG. Please share any thoughts with the list to indicate support or opposition
-- this is not a vote.
If you are willing to provide a more in-depth review, please state it
explicitly to give the chairs an indication of the energy level in the working
group willing to work on the document.
WG adoption is the start of the process. The fundamental question is whether
you agree the proposal is worth the WG's time to work on and whether this draft
represents a good starting point. The chairs are particularly interested in
hearing the opinion of people who are not authors of the document.
Thanks!
Alvaro (for the Chairs)
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
