Re: [spring] Beyond SRv6.

On Mon., 2 Sep. 2019, 07:39 Robert Raszuk, <robert@raszuk.net> 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 <nick@foobar.org> 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
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>