Subject: Re: [Drip] drip-rid - Suite IDs and HIT size

From: "Card, Stu" <[email-masked]>
Date: Sun, 2 Jan 2022 10:52:38 -0500

Bob & anyone else with CIDR deployment knowledge/experience --

Please point me to some reading where I can learn about the challenges
encountered in rolling out CIDR in IPv4 and/or IPv6 conventional (locator,
not identifier) addressing.
That may bring me around to Bob's perspective or enable me to address the
points he has asked me to address.
Thanks.

-- Stu

On Thu, Dec 23, 2021 at 9:16 AM Robert Moskowitz <[email-masked]>
wrote:

> Stu,
>
> I have been giving this careful thought.
>
> Yes, we (the Internet) now have a lot of experience with CIDR.  Will one
> such organization step up now to include the necessary processes so this
> will get through and be deployed?
>
> Adding CIDR support now without a commitment for deployment, for a lot of
> the world will significantly delay adoption.
>
> And it gets more complicated as you move away for well established parts
> of the world with working policies.
>
> But I have been looking hard at this from the other direction.  You
> receive a DET, how do you learn more about the UAS?  With the fixed RAA|HDA
> structure, with just the HDA attestation of the DET and {RAA,HDA} cache,
> the receiver knows the beginnings about the UAS and how to learn more with
> forward lookups.
>
> With a CIDR approach, the HID becomes an opaque block at first.  The cache
> is of HIDs and some flexible structure for working out what the hierarchy
> is for this DET.  Lot more attestations will be needed.  The full chain?
> More air time?
>
> Will you please work out what this cache structure is for basic
> interoperability development?  Please provide text for the draft?
>
> Regional caches (vs worldwide) may be harder to support.  Don't know for
> sure, maybe not an issue.
>
> With Internet access, a 'classic' ip6.arpa reverse lookup, returning a PTR
> would return some arbitrary FQDN to find the HDA,USS and what hierarchy
> that HDA,USS is working under.  Minimum of two round trips to DNS, versus
> only one for fixed RAA|HDA.  When you only have milliseconds, help is
> seconds away.
>
> Now there is an attraction to more hierarchy:
>
> Whoever runs the US civil RAA may very much NOT want to deal with each US
> university wanting their own HDA and would welcome turning this over to
> Internet2.  Of course Internet2 may well want their own RAA as they are
> international and would, perhaps, offer services to any university.  Or
> Internet2 may get a few RAAs to regionalize the registered UAS into
> regional HDAs.
>
> True, we just DON'T know how best to make deployment simpler.
>
> I am still basically not convinced on the complete value of flexible
> Hierarchy here (CIDR approach).
>
>
>    - It adds significantly to deployment complexity.
>    - It adds significantly to receiver resolution of DET,UAS.
>    - It brings more challenges to less developed Internet regions that
>    lack IPv6 support.
>    - Probably more.
>
> IF someone takes on both adding needed text to the draft AND commits to
> this getting deployed on all aspects of the UAS ecosystem, I am willing to
> bring such someone on board.
>
> I do not see this as easy, nor that a simple change to the drip-rid doc to
> say use flexible, CIDR-like, hierarchy is in our best interest for smooth
> and long-term adoption/use.
>
> Bob
>
>
>
> On 12/22/21 18:47, Card, Stu wrote:
>
> Thanks Bob.
>
> My argument is simply that CIDR now has been working for many years to
> manage the precious pool of addresses in a manner that avoids sparsity
> while still enabling growth.
> The registries themselves (RAA and HDA in the simple 2 level model, but
> this would be generalized) should be the CIDR sub-allocators.
> Assuming that the acceptance we are currently getting in aviation leads to
> broad adoption there, other sectors will want to adopt this.
> That means a single /28 and simple 2 level hierarchy won't cut it.
>
> I propose that we state explicitly in the DET draft that arbitrary
> prefixes can be used, provided they accommodate a hash of at least 64 bits
> and a HHIT Suite ID of 8 bits.
> The HID is however many bits remain after the prefix and before the HHIT
> Suite ID and hash.
> We would ask for an initial IANA allocation of a /28 for experimental and
> general non-intensive use, which leaves 28 bits for the HID.
> Meanwhile ICAO is already getting a /16 from IANA for aviation intensive
> use, to which they append a 4 bit "platform type", of which a DET/HHIT is
> one, so effectively that's a /20 prefix, but they want a 72 bit hash, so
> again we have 28 bits for the HID (in a second, separate prefix, with more
> likely to follow for other sectors).
> Don't forget that HHITs (unlike their predecessor HITs) _are
> aggregatable_! Not in IP locator based underlay routing, but in IP
> identifier based overlay routing.
>
>
> On Wed, Dec 22, 2021 at 3:54 PM Robert Moskowitz <[email-masked]>
> wrote:
>
>> fellow drippers.
>>
>> Stu and I have been privately debating about potential number of Suite
>> IDs and how to balance this all.  Plus Stu thinks a CIDR model would
>> work for HIDs...
>>
>> First, I do NOT want to even consider the ORCHID hash shorter than 64
>> bits.  Just don't want to deal with potential baggage of 2nd pre-image
>> attack issues.
>>
>> So 64 bits to work with for Prefix, HID, and OGA (Suite IDs).
>>
>> Right now that is a 28,32,4 bit division.  We are almost out of
>> available Suite IDs in that 4-bit space.  Yes, RFC 7401 defines how to
>> add 15 more by taking 4 bits from the hash, but see above for concerns.
>>
>> So Stu's view to increase the OGA to 8 bits is reasonable on some level
>> of reasonablity.
>>
>> This can only be done with either a /24 prefix or a 28-bit HID.  So I
>> looked hard at how to work with 28 bits for the HID.
>>
>> I discard a CIDR approach.  I participated in the original CIDR wg and
>> remember Tony Li and others presenting.  I also remember what it took to
>> implement this for IPv4.  And the YEARS to put in place the processes to
>> support it with IPv6.  IMHO, this is only a viable approach if one of
>> the current IPv6 address managers stepped forward and said, "No problem,
>> we can easily and cost affordably provide the process here."  Not
>> likely.  So what can we do with fixed sizes for RAA and HDA?
>>
>> Here are my thoughts:
>>
>> 14 bits for each RAA and HDA.  That is 16K for each.
>>
>> Now there are 193 state members in ICAO.  Say 2 RAAs for starters for
>> each state (civil and military) and toss in a few non-state RAAs and we
>> are still within 512 RAAs.  OK, double that for good measure and up to
>> 1024 or only 10 bits needed.  So whoever takes on the RAA number
>> assignment process could spread out the numbering such that IF some
>> entity comes back asking for another number assignment, it will tend to
>> be the next over, making a CIDR-like assignment.
>>
>> Same thing for an RAA to do with its HDA space.  Spread out the number
>> assignment such that if an HDA entity needs more it can get neighboring
>> space.  This is actually a real concern for an HDA entity that is
>> supporting delivery service UAS that may use a DET per day or per
>> operation.
>>
>> Now IMO, this is all out of scope of drip-rid, but important to talk
>> about to slice down the HID to 28 bits.  I COULD capture this in an
>> appendix, but after we agree here, I don't really see the need other for
>> people not on this list to see the decision process behind a 14|14 HID.
>>
>> Going to an 8-bit HHIT Suite ID, would be a new IANA registry, perhaps
>> still in the HIP registry space.  It would cleanly map the 4-bit and 4x4
>> bit HIPv2 Suite ID and go from there.
>>
>>
>> Discussion PLEASE.
>>
>> Oh, as of current with the ICAO routable address space work, DETs have
>> an effective /20 prefix.  Either 32-bit HIDs or just larger ORCHID
>> hash.  I lean for same HID allocation model, so larger hash.
>>
>>
>> I want to either make or drop this change for a version I will put
>> together early January.
>>
>> Bob
>>
>> --
>> Tm-rid mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tm-rid
>>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Jan 2022 20:48:16 -0500

> not identifier) addressing.

Not really sure I understand the question.

In going from class A/B/C without subnetting, there often issues where people had
hard coded the /8, /16 and /24 stuff.  But that tended to be in obscure
places, and was in the early 1990s.  Almost anyone with a /8 or /16 had some
kind of subnetting policy (you didn't just throw the /8 on the campus LAN).
There was some equipment that didn't understand one might have different
subnet lengths for different parts.  And then RFC2317 is still not well
deployed.

IPv6 had no such issues.

    >> the world will significantly delay adoption.

I don't know what the issue is.

    >> interoperability development?  Please provide text for the draft?

I don't think that this is a CIDR issue.
This is about having different boundaries in different parts of the structure?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide