Hi Mark, Thanks for your comments. Please find responses inline. > On Sep 29, 2022, at 8:58 PM, Mark Smith <markzzzsm...@gmail.com> wrote: > > > > On Thu, 29 Sept 2022 at 19:51, Brian Carpenter <brian.e.carpen...@gmail.com > <mailto:brian.e.carpen...@gmail.com>> wrote: > No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve for > the dreamt-of centrally registered ULA prefixes, and fd00::/8 is fully > committed. > > If SRV6 is important, it could justify its own prefix. > > I think SRv6 must have its own prefix. > > SIDS that are copied into IPv6 addresses in RFC 8986 have a different format, > field names, field semantics and forwarding methods verses previous IPv6 > addressing and forwarding in RFC4291, RFC4193 etc. > > I think the only way to be able to create a new IPv6 address format that has > new and different attributes is to have a new well known prefix for it. > Multicast (FF00::/8), ULA (FC00::/8), Link-Locals (FE80::/10) and > Discard-Only (100::/64) are all examples.
Yes. I fully agree with you on all the above points. > > I'd also suggest a centralised registry for these SRv6 prefixes, or at least > a pseudo random embedded id similar to ULAs, to avoid SRv6 prefix collisions > if SR domains/networks merge. NAT/NPT on SRv6, including on SIDs/IPv6 > addresses in the SRH itself, is not pleasant to think about, nor is > renumbering a well established SID address space/SR domain. I am personally not in favor of a centralized registry or randomized bits after to provide probabilistic uniqueness (as I do not think these are expected to be globally routable). That said, with my editor hat on, I hope that other WG participants will chime in and the chairs can determine whether this is the path to go when we document the operational guidelines for this prefix. Regards Suresh
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
