[manet] Re: IPv6 Address for Ad Hoc Networks

["Templin (US), Fred L" <[e-mail]>]

Hi Michael, see below for responses to your message:

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Sunday, August 04, 2024 11:33 AM
> To: Templin (US), Fred L <[e-mail]>; IPv6 List <[e-mail]>; [e-mail]
> Subject: Re: [IPv6]Re: IPv6 Address for Ad Hoc Networks
> 
> 
> Hi,
> I have read mla-21.
> I think the word "amorphously" in paragraph three is not the word you want.
> (dictionary.com says "amorphous" means without form, denies existence of
> adverb, but such a word ought to exist)
> 
> I think the word you want is autonomously, or autonomically.

No, "amorphously" is precisely the word that I want. The word is defined in
Merriam-Webster and accurately describes what I am trying to capture.
The thesaurus does not provide any suitable alternatives. 

> I don't really understand section 4.
> Does a node have an MLA for each network it joins?

A different MLA for each Ad-Hoc network - the same as the RFC4007 scoped
addressing architecture had for "site".

> Or for each interface on each network it joins?

Each interface connection to the same Ad-Hoc network configures the same MLA.

> I think MLAs should be added as loopback addresses on a single interface (lo,
> or dummy or null).  Then the ad-hoc routing protocol should spread /128
> routes for that MLA using the v6-LL of the device as the nexthop.

RFC5889 explains why LLAs are not useful; the Ad-Hoc network interface can
be a connection to a multilink and not just a singleton link where an LLA could
be useful. Also, when a node has multiple interface connections to the same
Ad-Hoc network it needs to use an MLA - not an LLA.

> This is how RFC8994 works, and how most IGPs are configured.

This document is intended to update RFC5889 which is specifically about Ad-Hoc networks.
For MANET routing protocols, the expectation is that the MLAs assigned to Ad-Hoc interfaces
would also serve as router IDs for the routing protocols. 

> About RFC8994: at first it seems a little less ad-hoc, but given the OMNI
> context, I actually reconsider.  RFC8994 does allocation of /120 or /116
> (from within the ACP's /48 ULA) prefixes via PKIX certificates.  (See below)
> 
> Yes, this is very very much centrally managed, but it's tied to the
> onboarding of the device, and the provisioning of the security credential.
> Surely in 2024 ADHOC networks need security, and that means some kind of
> credential.

I want to be flexible to support all manners of Ad-Hoc networks ranging from
those where an anonymous group of nodes happen to find themselves within
communications range of each other (when a purely randomly-generated
address can be used) to those where the address has some form of
attestation properties.

> I'm generally skeptical that you need 116-bits of randomness.
> I think 64-bits might enough.  I don't think you can/should squat on ORCHIDs
> or HHITs; or rather, I think we have more than enough v6 space to set aside
> some for OMNI.

If you look, the document no longer says anything about the length of the
prefix TBD::/N nor anything about HITs/HHITs. I happen to think those
would be good candidates, with HITs as a more self-generated address
type and HHITS more associated with an attestation service. But, the
document is silent on candidate MLA types.

> "If the node becomes aware that the address is
>    already in use by another node, it instead generates and assigns a
>    new MLA."
> 
> without a mechanism for DAD, I don't see how this statement can ever be
> enacted.

When a node joins an Ad-Hoc network, it can listen for its tentative address
already being in use in control messages asserted by other nodes. That was
at one time called "in-service DAD" in contrast to "pre-service DAD" used on
classical links like Ethernet.

> I think you should consider if you truly and really need/want such random
> addresses.  I think you will ultimately need a secured identity.

The document is open to accepting multiple MLA types - earlier versions of the
draft called for HIT/HHIT but the current draft is now silent. Different MLA types
ranging from those that are fully self-generated to those that are coordinated
with some form of attestation service should be useful for their respective
domains of application.

> i.e:
>         X509v3 extensions:
>             X509v3 Subject Alternative Name:
>                 otherName:[e-mail]
> 
> as per section 6.11.5 of RFC8994, I allocate "Vlong" style addresses so that
> the nodes have not just a /128 for themselves, but also some additional
> addresses for local VMs, containers or different (virtual) services.
> (No, these prefixes are not for extending the network, but for network
> management.  If a device needed a /64 for SLAAC, then it would get one via
> DHCPv6 over the production network, not the ACP)

I don't see anything here that relates to the MLA draft - MLAs will always be /128's
with no subnetting. Again, the goal is to update RFC5889 where /128 is established.

Fred

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