On Mon., 2 Sep. 2019, 07:39 Robert Raszuk, <[email protected]> wrote:
> Nick, > > How about using ULAs as defined in RFC4193 ? > I've analysed uSID in the context of all current IPv6 unicast address formats in this email. https://mailarchive.ietf.org/arch/msg/spring/Gsr-nJqzhyYIrj8mG6p3KZ_HZ5E Short answer is you can only put uSIDs in the IID portion of any of those address formats, and must also ensure that the resulting IID value formed from the set of uSID values don't also match the reserved IID values. The uSID proposal is taking the position that all the bits after the high order prefix are available for any purpose. This is not correct, and would violate a number of standards track RFCs, including the IPv6 Addressing Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193). In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal ID, must be pseudo random. This is the most critical property of ULA addresses and prefixes, as it is the solution to the problem ULAs are designed to solve. 3.2 <https://tools.ietf.org/html/rfc4193#section-3.2>. Global ID The allocation of Global IDs is pseudo-random [RANDOM <https://tools.ietf.org/html/rfc4193#ref-RANDOM>]. They MUST NOT be assigned sequentially or with well-known numbers. This is to ensure that there is not any relationship between allocations and to help clarify that these prefixes are not intended to be routed globally. Specifically, these prefixes are not designed to aggregate. > After all isn't local IPv6 FC00::/7 address block defined precisely for > such private use cases like the one which uSID requires? > > Clearly RIRs will not allocate /22 blocks left and right and that v6 > prefix would be required if I have 1000 node network and my uSID is /32. > > Thx, > R. > > > On Sun, Sep 1, 2019 at 11:33 PM Nick Hilliard <[email protected]> wrote: > >> Ron Bonica wrote on 01/09/2019 22:10: >> > - >> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02 >> >> Ron, >> >> if this draft proposes using up to /32 per router in a SRv6 domain, or >> even /40 to /48, it may be appropriate to solicit input from RIR address >> policy groups about the impact this may have on ipv6 assignment / >> allocation policies. >> >> Nick >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
