Subject: Re: [Drip] HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 12 Jan 2021 17:28:51 +0000

Stu, I admittedly don’t know much about HIP (even though my officemate
was one of the authors), but it occurs to me that the HIT/HHIT could also be
used with AERO/OMNI instead of HIP.

With AERO/OMNI, there is always a virtual interface (the OMNI interface)
that the HIT/HHIT would be assigned to, i.e., even if there are multiple
underlying interfaces associated with the OMNI interface. The HIT/HHIT
could then be called a valid IPv6 address.

Another point is that the document at some points references HIP. If it
intends to continue to do so, please make sure that it is just an example
and not the exclusive potential user of HITs/HHITS, as others such as
AERO/OMNI are also candidate users.

Thanks - Fred

From: Card, Stu [mailto:[email-masked]]
Sent: Tuesday, January 12, 2021 9:14 AM
To: Templin (US), Fred L <[email-masked]>
Cc: [email-masked]; Dickson (US), Sean M <[email-masked]>
Subject: Re: [Drip] HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

Interesting point Fred.

One (sophist?) definition would be that a [H]HIT is associated with the set of virtual interfaces used by the host for HIP (e.g. hip0, hip1), with the caveat that these are not always up.

This is not really different from a DHCP reservation associated with a wireless interface on a mobile host, inc. one that connects to different routers so only gets that address when it connects to the router configured with that DHCP reservation.

Do you consider that sufficient?
On Tue, Jan 12, 2021, 11:57 AM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi, in the draft it says in a couple of places that HITs and HHITs are "valid IPv6 addresses".
But, in RFC8200, "address" is defined as follows:

   address      an IPv6-layer identifier for an interface or a set of interfaces.

So, the HIT/HHIT cannot be called a "valid IPv6 address" unless it is also associated
with an interface or a set of interfaces.

The simple and effective fix for this is to, in the document, state that the HIT/HHIT
will always be assigned to a virtual interface of the device (e.g., loopback, etc.).
With that simple fix, I believe the statement that the HIT/HHIT is a valid IPv6
address is supported; without it, I do not believe the claim can be made.

Thanks - Fred

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

---

From: "Card, Stu" <[email-masked]>
Date: Tue, 12 Jan 2021 12:47:24 -0500

On 1st quick consideration of your idea, I _think_ you are right!

[H]HITs are artifacts emerging from HIP work, but neither require nor
exclusively support running HIP.

Thanks for this novel idea!

On Tue, Jan 12, 2021, 12:29 PM Templin (US), Fred L <
[email-masked]> wrote:

> *From:* Card, Stu [mailto:[email-masked]]
> *Sent:* Tuesday, January 12, 2021 9:14 AM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* [email-masked]; Dickson (US), Sean M <[email-masked]>
> *Subject:* Re: [Drip] HITs and HHITs as valid IPv6 addresses in
> 'draft-ietf-drip-rid'
>
>
>
> Interesting point Fred.
>
>
>
> One (sophist?) definition would be that a [H]HIT is associated with the
> set of virtual interfaces used by the host for HIP (e.g. hip0, hip1), with
> the caveat that these are not always up.
>
>
>
> This is not really different from a DHCP reservation associated with a
> wireless interface on a mobile host, inc. one that connects to different
> routers so only gets that address when it connects to the router configured
> with that DHCP reservation.
>
>
>
> On Tue, Jan 12, 2021, 11:57 AM Templin (US), Fred L <
> [email-masked]> wrote:
>
> [email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2021 13:27:51 -0500

Backwards. :)

HIP is an artifact of Host Identity based Internet Protocol addresses...

A bit of history behind it all.  For some reason I am very familiar with it!

On 1/12/21 12:47 PM, Card, Stu wrote:
> On Tue, Jan 12, 2021, 12:29 PM Templin (US), Fred L 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     *From:*Card, Stu [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Templin (US), Fred L <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Dickson (US), Sean
>     M <[email-masked] <mailto:[email-masked]>>
>     One (sophist?) definition would be that a [H]HIT is associated
>     with the set of virtual interfaces used by the host for HIP (e.g.
>     hip0, hip1), with the caveat that these are not always up.
>
>     This is not really different from a DHCP reservation associated
>     with a wireless interface on a mobile host, inc. one that connects
>     to different routers so only gets that address when it connects to
>     the router configured with that DHCP reservation.
>
>     On Tue, Jan 12, 2021, 11:57 AM Templin (US), Fred L
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/tm-rid>
>
>

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

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

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2021 16:43:42 -0500

Fred,

Lots of history here and challenges within the IETF.  But let's keep 
this simple:

The Host Identity Tag (HIT), based on Host Identities provides a unique 
namespace that fits within the IPv6 namespace.  The intent in HIT was to 
provide a cryptographically provable IPv6 address.  This resulted in the 
address to be non-routable and requiring a routing underlayment.

But why/how would one party trust another's Identity claim?  Public Key 
crypto in every single datagram did not work then or now.   So a Host 
Identity Protocol (HIP) was needed to establish trust and potentially 
set up that routing underlayment.  Thus HI and HIT are defined within 
HIP, historically, but are not be design limited to use in HIP (or by 
ESP BEET mode).

Stu came knocking at my door, so to speak 2 years ago, about using this 
unique provable identity for Unmanned Aircraft.  I JUST happened to have 
various prior work on proposing how hierarchy for address management can 
work within HITs.

So here we are with HHITs for a virtual interface, being used within 
higher layer applications (like other IPv6 addresses).

I would be very interested in working with you on HHITs on the AERO/OMNI 
virtual interface.  The challenge we will need to address is why should 
anyone trust an interface's claim to a specific HHIT.

Take this 'offline' from DRIP and let's exchange ideas.

Or, I am on the ATN list if that is a reasonable home for this discussion.

Bob

On 1/12/21 12:28 PM, Templin (US), Fred L wrote:
> *From:*Card, Stu [mailto:[email-masked]]
> One (sophist?) definition would be that a [H]HIT is associated with 
> the set of virtual interfaces used by the host for HIP (e.g. hip0, 
> hip1), with the caveat that these are not always up.
>
> wireless interface on a mobile host, inc. one that connects to 
> different routers so only gets that address when it connects to the 
> router configured with that DHCP reservation.
>