Hi Alvaro,
On 8/28/25 23:08, Alvaro Retana wrote:
If I understand your proposal correctly, you're suggesting the following:
s/
Some examples of an infrastructure address range for SIDs are: 1. ULA
addresses 2. The prefix defined in [RFC9602] 3. GUA addresses
/
Implementations of SRv6 should number SIDs within their trusted domain
from the reserved prefix as defined within RFC9602.
Is that it?
The brevity of my suggested text was really that, less is more --
implying that you can do whatever you want, at your own risk.
I wrote something very succinct because as soon as I tried writing
language that catered to any and all "bad ideas", it suddenly became a
monster.
I agree with the premise that all prefix ranges are not equal. However,
I disagree with not mentioning ULA/GUA (which is the result of replacing
the text above).
As you suggest, if "we have a duty to represent such prefix ranges as
something other than equals", the document should explicitly point at
the risks of using them. Note that even rfc9602 contains some text (in
the Security Considerations) about the case of not using the range
defined there.
The Security Considerations section of RFC9602 is useful, and gives even
greater reason to limit our SID numbering recommendations to the prefix
defined therein. It is the only prefix with any explicit designation for
SRv6 SIDs.
When one considers how to identify SRv6 SIDs, it should be as simple as
possible to filter them from IPv6. Mixing SRv6 with *portions* of the
ULA and GUA space available to an ISP does not, in my tired, network
operator opinion, meet the requirement of being simple.
I realise that there are vendors actively advocating for the use of ULA,
and I think such deployment advice should be updated in favour of
RFC9602, and I think this is the intended document to help do that. I
want to see deployments that are as robust and as secure as they
possibly can be.
--
Tom
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
