Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt

[David Farmer <[e-mail]>]

On Mon, Jun 14, 2021 at 5:51 PM Ed Horley <[e-mail]> wrote:

> Dale,
> Comments inline below with [ETH] starting my comments
>
> On Mon, Jun 14, 2021 at 12:15 PM Dale W. Carder <[e-mail]> wrote:
>
>> Thus spake Brian E Carpenter ([e-mail]) on Fri, Jun
>> 11, 2021 at 10:22:51AM +1200:
>> > My concern about this draft is that it intentionally creates ambiguous
>> address space, something we have very carefully avoided since the beginning
>> of IPv6.
>>
>> I'm not sure I worry as much about ambiguous as having more prefixes
>> be marked "special", some of the implications of which seem may be at
>> the heart of this proposal.
>>
>> In draft-horley-v6ops-lab-00.txt,
>>
>> "For instance, designing labs utilizing ULA fc00::/7
>>    [RFC4193] is problematic due to the random global ID requirement
>>    preventing hierarchical network prefix design possibilities."
>>
>> Have the authors considered updating 4193?  Is the randomness the issue,
>> or is the resultant /48 the issue?  (of course, one could utilize
>> multiple random /48's as I think has been pointed out)
>>
>
> [ETH] RFC 4193 section 3.2 is pretty clear.
> "  The allocation of Global IDs is pseudo-random [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."
>
> The authors of RFC 4193 felt the pseudo-random property important enough
> aspect of ULA to make it a "MUST NOT" use without it. In addition, because
> of that specific requirement, there are operational implementations of ULA
> that have this REQUIREMENT already built into it. For us to come back and
> change that fundamental characteristic now would likely cause more pain and
> confusion. It is far simplier to assign the use of a currently deprecated
> address space (we are proposing 200::/7, but I am certainly open to hearing
> if others have a better recommendation) and move forward without changing a
> fundamental attribute of ULA.
>

Technically, the pseudo-random assignment strategy only applies to
fd00::/8, where L = 1, and fc00::/8, where L = 0, is reserved and has no
allocation strategy define at this time, see RFC 4193, section 3.1. There
were ideas to define L = 0 for centrally assigned ULA, sometimes known as
ULA-C, for one attempt, see;

https://datatracker.ietf.org/doc/html/draft-hain-ipv6-ulac-02

So, I see no reason why we cannot define an allocation strategy for L =  0,
allowing for the local allocation of large contiguous blocks.

While allowing for L = 1 to remain for pseudo-random allocation of /48
blocks, ensuring no collisions with ULA blocks assigned per RFC 4193.
Probably adding a recommendation that two networks using large contiguous
blocks, from the L = 0 range, SHOULD NOT be merged with each other without
careful coordination of the assignments made from the L = 0 range.

Maybe recommending the Global ID for L=0 be taken from the corresponding 40
bits of the network's GUA Prefix.

Just a thought.

-- 
> Ed Horley
> [e-mail] | [phone]
> Advancing Cloud, IoT, and Security with IPv6
> https://hexabuild.io
> And check out the IPv6 Buzz Podcast at
> https://packetpushers.net/series/ipv6-buzz/
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================