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

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 15 Jan 2021 15:47:35 +0000

Ah, yes – our good friend Dave Thaler. If I am being totally honest, the idea of assigning
an address to a loopback is not something I came up with on my own – it was suggested
to me by Dave himself back when he was on the IAB.

Fred

From: Robert Moskowitz [mailto:[email-masked]]
Sent: Thursday, January 14, 2021 5:56 PM
To: Templin (US), Fred L <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]; Dickson (US), Sean M <[email-masked]>
Subject: Re: [Drip] [EXTERNAL] Re: HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

Then there is rfc 6250 that shows how some of these assumptions about addresses and interfaces is not so simple.

:)
On 1/14/21 12:03 PM, Templin (US), Fred L wrote:

Michael, RFC4291 says the following:

   "IPv6 addresses of all types are assigned to interfaces, not nodes.

   An IPv6 unicast address refers to a single interface.  Since each

   interface belongs to a single node, any of that node's interfaces'

   unicast addresses may be used as an identifier for the node."

Note that it clearly states that: "An IPv6 *unicast* address refers to a

singe interface." - so, this is about IPv6 unicast addresses (which could

be GUA, ULA or LLA) and not multicast or others.

Fred

-----Original Message-----

From: Michael Richardson [mailto:[email-masked]]

Sent: Tuesday, January 12, 2021 5:13 PM

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]>

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

Templin (US), Fred L <[email-masked]><mailto:[email-masked]> wrote:

    > 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.

Well, that seems like arbitrarily dumb bureaucracy.

Of course, we can write that down, but since nobody can check, we should just

nod and smile.

Anyway, it says that it's "for an interface", but, that doesn't mean it has

to be *on* an interface :-)

Oh, and multicast and anycast addresses might never be on an interface.

--

Michael Richardson <[email-masked]><mailto:[email-masked]>   . o O ( IPv6 IøT consulting )

           Sandelman Software Works Inc, Ottawa and Worldwide

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

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Jan 2021 16:27:10 -0500

> to me by Dave himself back when he was on the IAB.

We really struggled in draft-ietf-anima-autonomic-control-plane with how to
attribute the business of putting a {GUA}/128 on a loopback interface.

Operationally, everyone does this in Enterprise and ISP networks, but it was
remarkably difficult to find good references for this operational practice.

https://www.ietf.org/archive/id/draft-ietf-anima-autonomic-control-plane-30.html#name-acp-loopback-interfaces

We even had to say:
   [RFC-Editor: please remove this paragraph: Note to reviewers: Please do
   not complain again about an obsolete RFC number in the following
   paragraph. The text should make it clear that the reference was chosen to
   indicate a particular point in time, but not to recommend/use a
   particularly obsolete protocol spec.]

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