Skip to main content

IPv6 MANET Local Addresses (MLAs)
draft-templin-6man-mla-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Fred Templin
Last updated 2024-05-24 (Latest revision 2024-05-23)
Replaces draft-templin-6man-ula-uuid
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-templin-6man-mla-04
Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: rfc3879, rfc4007, rfc4291 (if approved)             24 May 2024
Intended status: Standards Track                                        
Expires: 25 November 2024

                   IPv6 MANET Local Addresses (MLAs)
                       draft-templin-6man-mla-04

Abstract

   Mobile Ad-hoc NETworks (MANETs) present an interesting challenge for
   IPv6 addressing due to the indeterminant neighborhood properties of
   MANET interfaces.  MANET routers must assign an IPv6 address to each
   MANET interface that is both unique and routable within the MANET but
   must not be forwarded to other networks.  MANET routers must be able
   to assign self-generated addresses when there is no infrastructure
   present that can delegate topology-relative IPv6 addresses or
   prefixes.  This document therefore specifies a means for MANET
   routers to generate and assign MANET Local Addresses (MLAs).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 25 November 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights

Templin                 Expires 25 November 2024                [Page 1]
Internet-Draft                  IPv6 MLAs                       May 2024

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IPv6 MANET Local Addresses (MLAs) . . . . . . . . . . . . . .   3
   3.  Assigning IPv6 MLAs to an Interface . . . . . . . . . . . . .   5
   4.  Reclaiming fec0::/10  . . . . . . . . . . . . . . . . . . . .   5
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   When two or more IPv6 [RFC8200] nodes come together within a common
   local operating region (e.g., during the formation of a Mobile Ad-hoc
   Network (MANET)), they must be able to assign unique addresses,
   discover multihop routes and exchange IPv6 packets with local network
   peers even if there is no operator infrastructure present.

   MANETs consist of routers that configure interfaces to links with
   undetermined connectivity, in particular where the transitive
   property of connectivity for traditional shared links is not assured.
   MANET routers must nonetheless assign and use IPv6 addresses that are
   unique within the MANET.  This is true even for nodes that configure
   multiple interface connections to the same MANET as a multilink
   routing domain.

   Section 6 of the "IP Addressing Model in Ad Hoc Networks" [RFC5889]
   states that: "an IP address configured on this (MANET) interface
   should be unique, at least within the routing domain" and: "no on-
   link subnet prefix is configured on this (MANET) interface".  The
   section then continues to explain why IPv6 Link-Local Addresses
   (LLAs) are of limited utility on links with undetermined
   connectivity, to the point that they cannot be used exclusively
   within multilink routing domains.

Templin                 Expires 25 November 2024                [Page 2]
Internet-Draft                  IPv6 MLAs                       May 2024

   [RFC5889] suggests that global [RFC4291] (aka "GUA") and unique-local
   [RFC4193] (aka "ULA") addresses are MANET addressing candidates.
   However, assignment of unique GUAs and ULAs must be coordinated
   either through administrative actions or through an automated address
   delegation service that all MANET routers can access.  This document
   asserts that a new form of self-generated and unique MANET-local IPv6
   addresses is needed.

   The key feature of these MANET-local IPv6 addresses is that they must
   be assured unique so that there is no chance of conflicting with an
   address assigned by another node.  There is no requirement that the
   addresses have topologically-oriented prefixes, since the (newly-
   formed) local network may not (yet) connect to any other
   Internetworking topologies.

   The MANET-local IPv6 addresses could then be used for continuous
   MANET-local communications and/or to bootstrap the assignment of
   topologically-oriented addresses under the IPv6 multi-addressing
   architecture [RFC4291].  This would also manifest a new "MANET-local"
   scope for the IPv6 scoped addressing architecture [RFC4007] with
   scope greater than link-local but lesser than global/unique-local
   unicast.

   This document proposes a new unique local unicast address space known
   as MANET Local Addresses (MLAs).  MLAs use the formerly-deprecated
   IPv6 site-local prefix fec0::10 according to the address generation
   procedures specified in this document.

2.  IPv6 MANET Local Addresses (MLAs)

   The IPv6 addressing architecture specified in [RFC4291], [RFC4193]
   and [RFC4007] defines the supported IPv6 unicast/multicast/anycast
   address forms with various scopes including link-local, site-local
   and others.  Unique-local and global unicast addresses are typically
   assigned through Stateless Address AutoConfiguration (SLAAC)
   [RFC4862] and/or the Dynamic Host Configuration Protocol for IPv6
   (DHCPv6) [RFC8415], but these services require the presence of IPv6
   network infrastructure which may not be immediately available in
   spontaneously-formed MANETs or other isolated local networks.

   A new IPv6 address type known as the DRIP Entity Tag (DET) (or,
   Hierarchical Host Identity Tag (HHIT)) [RFC9374] provides a well-
   structured address format with exceptional uniqueness properties.  A
   portion of the address includes the node's self-generated Overlay
   Routable Cryptographic Hash IDentifier (ORCHID) while the remainder
   of the address includes a well-formed IPv6 prefix plus bits
   corresponding to an attestation service that supports address proof-
   of-ownership.  Verification of the attestation aspect of the address

Templin                 Expires 25 November 2024                [Page 3]
Internet-Draft                  IPv6 MLAs                       May 2024

   requires access to network infrastructure, but this may not always be
   available.  Furthermore, [RFC9374] provides no guidance for
   assignment of a DET/HHIT to an interface nor any evidence that they
   could be used as the source/destination addresses of IPv6 packets.

   MANET interfaces have the interesting property that a MANET router R
   will often need to forward packets between MANET nodes A and B even
   though R uses the same interface in the inbound and outbound
   directions.  Since nodes A and B may not be able to communicate
   directly even though both can communicate directly with R, the link
   connectivity property is intransitive and the IPv6 Neighbor Discovery
   (ND) Redirect service cannot be used.  Conversely, R may need to
   forward packets between nodes A and B via different MANET interfaces
   within a single MANET that includes multiple distinct links/regions.
   Due to these indeterminant (multi-)link properties, exclusive use of
   IPv6 Link Local Addresses (LLAs) is also out of scope.

   This document therefore introduces a new fully-self-generated IPv6
   unicast address format known as the MANET Local Address (MLA) that
   can be used either instead of or in addition to other IPv6 unicast
   address types (noting again that a single interface may have multiple
   IPv6 addresses [RFC4291]).  The address uses the formerly-deprecated
   Site-Local IPv6 Address prefix fec0::10 according to the modified
   format shown in Figure 1:

     | 10 bits  |1|       53 bits         |         64 bits            |
     +----------+-+-----------------------+----------------------------+
     |1111111011|L|      subnet ID        |       interface ID         |
     +----------+-+-----------------------+----------------------------+

             Figure 1: IPv6 MANET Local Address (MLA) Format

   In this format, the node sets the first 10 bits of the address to the
   constant string '1111111011' then sets the 11th bit (i.e., the
   "(L)ocal" bit) to 1.  The node next sets subnet ID to a 53 bit random
   value calculated the same as specified in Section 3.2.1 of [RFC4193]
   for the Unique Local Address Global ID.

   The node finally generates and assigns a semantically opaque
   interface ID based on this self-generated prefix as specified in
   [RFC7217]; the resulting 128-bit MLA then has the proper format of an
   IPv6 address with a 64-bit "prefix" followed by a 64-bit interface
   identifier as required by the IPv6 addressing architecture.  For
   example:

      fee7:6c29:de12:4b74:884e:9d2a:73fc:2d94

Templin                 Expires 25 November 2024                [Page 4]
Internet-Draft                  IPv6 MLAs                       May 2024

   After a node creates an MLA, it can use the address within the
   context of spontaneously-organized local networks in which two or
   more nodes come together in the absence of supporting infrastructure
   and can still exchange IPv6 packets with little or no chance of
   address collisions.  The use could be limited to bootstrapping the
   assignment of topologically correct IPv6 addresses through other
   means mentioned earlier, or it could extend to longer term usage
   patterns such as sustained communications with single-hop neighbors
   on a local link or even between multi-hop peers within a MANET.

   Note: the above MLA generation procedures apply when the L bit is set
   to 1; MLA generation procedures for L=0 may be specified by future
   documents.

3.  Assigning IPv6 MLAs to an Interface

   IPv6 MLAs have no topological orientation and can therefore be
   assigned to any of a node's IPv6 interfaces.  The node can then begin
   to use MLAs as the source/destination addresses of IPv6 packets that
   are forwarded over the interface within a local routing region.

   MLAs may then serve as a basis for multihop forwarding over a MANET
   interface and/or for local neighborhood discovery over other IPv6
   interface types.  Due to their uniqueness properties, the node can
   assign an IPv6 MLA to an interface without invoking (pre-service)
   Duplicate Address Detection (DAD), however it should deprecate the
   MLA and assign a new IPv6 MLA if it detects a duplicate through (in-
   service) DAD.

4.  Reclaiming fec0::/10

   Returning to a debate from more than 20 years ago, this document now
   proposes to reclaim the deprecated prefix "fec0::/10" for use as the
   MLA top-level prefix.  [RFC3879] documents the reasons for
   deprecation including the assertion that "Site is an Ill-Defined
   Concept".  However, the concept of a MANET is a logical one and not
   necessarily one constrained by physical boundaries.

Templin                 Expires 25 November 2024                [Page 5]
Internet-Draft                  IPv6 MLAs                       May 2024

   For example, a MANET router may connect to multiple distinct MANETs
   with a first set of interfaces connected to MANET "A", a second set
   of interfaces connected to MANET "B", etc.  According to the scoped
   IPv6 addressing architecture, the router would assign a separate MLA
   for each interface set A, B, etc. and maintain separate MANET routing
   protocol instances for each set.  MLAs A, B, etc.  then become the
   router IDs for the separate routing protocol instances, but the MANET
   router may elect to redistribute discovered MLA routes between the
   instances.  The uniqueness property of MLAs therefore transcends
   logical MANET boundaries but without "leaking" into external
   networks.

   The prefix (formerly known as "Site-Local") has the distinct
   advantage that it is reserved and available for reclamation by a
   future standards track publication, for which this document
   qualifies.  Upon publication as a standards track RFC, the RFC Editor
   is instructed to update [RFC3879], [RFC4007] and [RFC4291] to reflect
   this new use for "fec0::/10".

5.  Requirements

   IPv6 nodes MAY assign self-generated IPv6 MLAs to their interface
   connections to local networks (or MANETs).  If the node becomes aware
   that the address is already in use by another node, it instead
   generates and assigns a new MLA.

   IPv6 routers MAY forward IPv6 packets with MLA source or destination
   addresses over multiple hops within the same local network (or
   MANET).

   IPv6 routers MUST NOT forward packets with MLA source or destination
   addresses to a link outside the packet's local network (or MANET) of
   origin.

   IPv6 routers MUST NOT advertise the prefix fec0::/10 in routing
   protocol exchanges with correspondents outside the local network (or
   MANET).

   The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the fee0::/11 block.

   At the present time, AAAA and PTR records for MLAs in the fee0::/11
   block are not recommended to be installed in the global DNS.

Templin                 Expires 25 November 2024                [Page 6]
Internet-Draft                  IPv6 MLAs                       May 2024

6.  Implementation Status

   In progress.

7.  IANA Considerations

   [RFC3879] instructed IANA to mark the FEC0::/10 prefix as
   "deprecated", and as such it does not appear in the IANA IPv6
   Special-Purpose Address Registry.

   Upon publication, IANA is instructed to add the prefix FEC0::/10 to
   the 'iana-ipv6-special-registry' registry with the name "MANET-Local
   Unicast" and with RFC set to "[RFCXXXX]" (i.e., this document).

8.  Security Considerations

   IPv6 MLAs include very large uniquely-assigned bit strings in both
   the prefix and interface identifier components.  With the random
   prefix generation procedures specified in [RFC4193] and the
   semantically opaque interface identifier generation procedures
   specified in [RFC7217] the only apparent opportunity for address
   duplication would be through either intentional or unintentional
   misconfiguration.  A node that generates an MLA and assigns it to an
   interface should therefore be prepared to deprecate the MLA and
   generate/assign a new one if it detects a legitimate duplicate.

9.  Acknowledgements

   This work was inspired by continued investigations into 5G MANET
   operations in cooperation with the Virginia Tech National Security
   Institute (VTNSI).

   Emerging discussions on the IPv6 maintenance (6man) mailing list
   continue to shape updated versions of this document.  The author
   acknowledges all those whose useful comments have helped further the
   understanding of this proposal.

   Honoring life, liberty and the pursuit of happiness.

10.  References

10.1.  Normative References

   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
              DOI 10.17487/RFC4007, March 2005,
              <https://www.rfc-editor.org/info/rfc4007>.

Templin                 Expires 25 November 2024                [Page 7]
Internet-Draft                  IPv6 MLAs                       May 2024

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

10.2.  Informative References

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, DOI 10.17487/RFC3879, September
              2004, <https://www.rfc-editor.org/info/rfc3879>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC5889]  Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
              Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
              September 2010, <https://www.rfc-editor.org/info/rfc5889>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

   [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
              "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
              ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
              <https://www.rfc-editor.org/info/rfc9374>.

Templin                 Expires 25 November 2024                [Page 8]
Internet-Draft                  IPv6 MLAs                       May 2024

Appendix A.  Change Log

   << RFC Editor - remove prior to publication >>

   Differences from earlier versions:

   *  First draft publication.

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA 98124
   United States of America
   Email: fltemplin@acm.org

Templin                 Expires 25 November 2024                [Page 9]