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
<mailto:wangai...@tsinghua.org.cn>
*发送时间：* 2023-07-14 11:19
*收件人：* 'Alvaro Retana'
<mailto:aretana.i...@gmail.com>;
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
<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
