Re: [Drip] HHIT field order

[Robert Moskowitz <[e-mail]>]

On 10/7/20 5:35 AM, Alexandre Petrescu wrote:
>
>
> Le 05/10/2020 à 14:56, Robert Moskowitz a écrit :
>> This note is going to ask for thoughts on the order of the fields in 
>> a HHIT.  Either
>>
>> Prefix | Suite ID | RAA | HDA | HI Hash
>>
>> or
>>
>> Prefix | RAA | HDA | Suite ID | HI Hash
>>
>> =================
>>
>> In drip-uas-rid, I define the HHIT fields, as I did in 
>> draft-moskowitz-hip-arch-02 in '01, as follows:
>>
>>     A HHIT is built from the following fields:
>>
>>     *  28 bit IANA prefix
>>
>>     *  4 bit HIT Suite ID
>>
>>     *  16 bit Registered Assigning Authority (RAA)
>>
>>     *  16 bit Hierarchical HIT Domain Authority (HDA)
>>
>>     *  64 bit ORCHID hash
>
> I do not understand why we need to fix in stones these limits.
>
> In particular, the 64bit ORCHID hash could be as well 66 or 63.
>
> A more flexible stone-setting would be:
>
> - 3 bits from IANA
> - m bits for prefix
> - n bits for interface ID
> - 3+m+n must equal 128; m and n at the discretion of deployer.

In the next version of the draft, there will be an IANA discuss on the 
prefix size.

First, I believe IANA and RIRs do allocations on nibbles.  So the likely 
IANA prefix will be /28 - /16.

For a prefix there has to be an agreement on the RAA size.  The Suite ID 
is currently set at 4 bits.

For each RAA for a given prefix to do its own HDA size and thus HI Hash 
size could be chaos for developers.

In theory anything adding to 128 should work.  In practice...

>
> Alex
>
> Alex
>
>>
>>
>> But I am proposing a different arrangement in the ICAO/GRAIN IPv6 
>> scheme.  First a bit about GRAIN.
>>
>> The GRAIN network is for Commercial-Civil aviation:
>>
>> "1.2    The network enabling the IATF, the Global Resilient Aviation 
>> Interoperable Network"
>> (GRAIN), is envisioned as an aviation only (dedicated) IPv6 overlay 
>> network on a series of underlying
>> networks and supporting network services."
>>
>> In some doc that I can't find right now this is limited to 
>> commercial/civil aviation.  Further we have:
>>
>> "[Please note that all recreational drone operation within Line Of 
>> Sight (LOS), Class G airspace are not included in this schema. 
>> Recreational drones using point-to-point LOS Command and Control (C2) 
>> are outside the scope]"
>>
>> So there is a potential and almost for sure bifurcating split in UAS 
>> networking.  This does not impact Broadcast Remote ID, but it does 
>> impact Network Remote ID.  The actual Remote ID SHOULD be the same 
>> for each mode.  (Stu does the reqs say this?)
>>
>> The regulators are going to have to figure out the demark.  Are 
>> Police/Fire and Small Business like photographers and realtors in 
>> GRAIN or out of GRAIN.  It will be interesting, as I suspect it will 
>> be a higher cost to be in GRAIN, but there are some advantages to 
>> participants.
>>
>> I should provide an aside here that the GRAIN prefix plus "platform 
>> type" could be /20 so the following reflects this.
>>
>> I added HHITs into the GRAIN addressing scheme, minimally for 
>> commercial/civil UAS usage.  It could be used for more than UAS 
>> within GRAIN.  In doing this I came to thinking two reasons for 
>> altering the field order.
>>
>> I put the Suite ID after the HID:
>>
>> "ICAO DELEGATED NETWORKS /16 FOR PLATFORM TYPE 13 – Hierarchical Host 
>> Identifier Tags (HHITs)
>> /16 IANA Prefix Addressing Scheme
>>
>> Bit #        Field Length        Purpose
>> 1 – 16        16            ICAO IPv6 prefix
>> 17 – 20        4            Platform type = 13
>> 21 – 36       16            GRAIN HHIT RAA
>> 37 – 52       16            GRAIN HHIT HDA
>> 53 – 56        4            HHIT Crypto Suite
>> 57 – 128      72            HHIT HI Hash
>>
>> A HHIT Registered Assigning Authority (RAA) will apply for GRAIN 
>> membership and be allocated a /36 prefix from this type with their 
>> RAA GRAIN number being used in the 16 bits after the platform type. 
>> The RAAs will then accept HHIT Hierarchical HIT Domain Authorities 
>> (HDA) as sub-members and allocate to them /52 prefixes.
>>
>> These HDAs will accept registration from UAS of HHIT Crypto Suite/HI 
>> Hash per the IETF DRIP UAS-RID documents using a 72 bit hash. GRAIN 
>> HHIT addresses may be for the life of the UAS or may be registered 
>> for only some operational period."
>>
>> Note, I do NOT envision different Crypto Suites by HDA.  And:
>>
>> "A .01% hash collision probability occurs after ~1 Billion HHITs 
>> registered (based on the 72 bit hash size) with an HDA. This 
>> increases to 1% with ~10 Billion HHITs registered. If an HDA’s 
>> business model is to provide a per operation HHIT for delivery UA, 
>> and supports a clientele of 1 Million UA making 10 deliveries per 
>> day, then the HDA will reach the .01% level in 100 days of 
>> operation.  Thus an HDA provider in this type of business may request 
>> a block of 128 HDAs from its RAA."
>>
>> ========================
>>
>> The importance here is putting the Crypto Suite and HI Hash together 
>> and the Prefix and aggregation information at the front.  This is 
>> good for filtering policy.  It also makes sense in grouping the HIT 
>> specific parts and the prefix parts.
>>
>> But does it cause any coding or other challenges.  Adam seems to 
>> think so and so far he is the only coder active...
>>
>> I look forward to a lively debate on this!
>>
>> Bob
>>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit