The list was certainly not intended to be ordered, we will update to bullet points and, just for further clarity, add We can certainly add in some text to the effect of:
- The prefix defined in [RFC9602] - ULA addresses - GUA addresses Further, I do agree that RFC9602 is the best possible option, albeit not the only one. How does this sound? "RFC9602 allocates and makes a dedicated prefix available for SRv6 SIDs for use inside of a trusted SRv6 domain. Use of other prefixes for this purpose will result in further security considerations such as, but not limited to potential SID pool route leakage or more complicated filtering requirements. As stated in the security considerations section of RFC 9602, the usage of the prefix allocated by this document [RFC9602] improves security by making it simpler to filter traffic at the edge of the SR Domains. Or something to that effect. Thoughts? On Wed, Sep 3, 2025 at 3:48 AM Alvaro Retana <[email protected]> wrote: > > Tom: > > I’m not arguing in favor of recommending the use of ULA/GUA. > > I’m suggesting that if the intent is to say “you can do whatever you want, at your own risk”, then the document should say something about those risks, along the lines of “use rfc9602…if you use anything else, this may happen: you will have a harder time filtering, etc.” Not an exhaustive description of how to use other alternatives, but rather the considerations (risks) if an operator decides to do so. > > [BTW, by asking “is that it?” I intended to clarify that I understood your suggestion correctly, and not imply that it was insufficient. Sorry if I was not clear.] > > Alvaro. > > On September 3, 2025 at 3:04:09 AM, Tom Hill ([email protected]) wrote: > > 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] > > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
