Subject: [Autoconf] draft-baccelli-autoconf-problem-statement-01.txt

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 03 Nov 2006 19:00:59 +0100

Hi all,

I'd like to announce the ps-01 document.

Please review it, send comments, and bring discussion to the mailing list.

Thanks.
Emmanuel Baccelli

MANET Autoconfiguration (Autoconf)                     E. Baccelli (Ed.)
Internet-Draft                                                     INRIA
Expires: April 4, 2007                                           K. Mase
                                                      Niigata University
                                                              S. Ruffino
                                                          Telecom Italia
                                                                S. Singh
                                                                 Samsung
                                                            October 2006

 Address Autoconfiguration for MANET: Terminology and Problem Statement
                  draft-baccelli-autoconf-statement-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 4, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Traditional dynamic IP address assignment solutions are not adapted
   to mobile ad hoc networks.  This document elaborates on this problem,
   states the need for a new solution, and provides guidelines and

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 1]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

   requirements for its design.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Overview of the Problem  . . . . . . . . . . . . . . . . .  3
     1.2.  Specification of Requirements  . . . . . . . . . . . . . .  3
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Standalone MANET . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  MANET Connected to an External Network . . . . . . . . . .  5
     2.3.  Deployment Scenarios Selection . . . . . . . . . . . . . .  5
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Specific Broacast Characteristics  . . . . . . . . . . . .  6
     3.2.  Dynamic Topology . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Locally Unique Addresses, Globally Unique Addresses  . . .  7
     3.4.  Multiple Gateways  . . . . . . . . . . . . . . . . . . . .  7
   4.  Solution Guidelines  . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Solution Model . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  General Requirements . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 2]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

1.  Introduction

   Mobile ad hoc networks (i.e.  MANETs, refer to RFC 2501) are networks
   composed of mobile devices, that communicate over wireless media, and
   which dynamically self-organize multi-hop communication between each
   other.  Each device may generate and forward control traffic, and
   forward user traffic (thus potentially behaving like a router).  Each
   device may also use the network by generating user traffic (and thus
   potentially behaving like a host).  We will call such devices MANET
   routers in the rest of the document.

   Some mobile ad hoc network may function regardless of the
   availability of a connection to the infrastructure (i.e. the
   Internet).  More precisely, a MANET may either be disconnected from
   the fixed IP infrastructure (then called a standalone MANET), or
   connected to the fixed IP infrastructure (through one or more
   gateways).

1.1.  Overview of the Problem

   Prior to participation in IP communication, each router's interface
   on a MANET that does not beneficiate from appropriate static
   configuration needs to be automatically assigned at least one IP
   address, that SHOULD be unique (i) locally, for communication inside
   the MANET, or (ii) globally, for communication accross the Internet.
   However, standard automatic IP address assignment solutions do not
   work "as-is" on MANETs due to ad hoc networks' characteristics, and
   new mechanisms are therefore needed.  The goal of this document is to
   detail these problems, and to provide guidelines and requirements for
   solutions to be designed.

1.2.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

1.3.  Terminology

   In addition to the specific wording described in the previous
   section, this document uses the following terminology :

   MANET Router  - A device with one or more wireless interfaces and
      associated IP address(es) which is used by the MANET routing
      protocol in use.

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 3]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

   Local address  - An IP address configured on a MANET router and valid
      for communication among MANET routers that are part of the same ad
      hoc network.  Routers MUST NOT communicate with other routers
      outside the MANET using this address.

   Global address  - An IP address configured on a MANET router and
      valid for communication with routers in the Internet, as well as
      internally within the MANET.

   Internet gateway  - An edge router connected to MANET as well as to
      the Internet and capable of providing bidirectional connectivity
      between the Internet and MANET .  These gateways are expected to
      provide topologically correct IPv6 prefixes.  Internet gateways
      mostly run ad hoc routing protocols, but they can also run
      infrastructure network protocols (e.g.  OSPF).

   Duplicate Address Detection (DAD)  - The process by which a router
      confirms the uniqueness of an address it wishes to configure or
      has already configured.  A router already equipped with an IP
      address participates in DAD in order to protect its IP address
      from being used by another router.

   Pre-service DAD  - The process verifying that a tentative new IP
      address assignment will not create a conflict with other MANET
      devices.

   In-service DAD  - The process of continuously checking that an IP
      address already in use has not become duplicated in the MANET.

   Standalone MANET  - An independent ad hoc network which has no
      connectivity, either direct of via Internet gateways, to any other
      IP networks such as the Internet.

   Network merger  - The process by which two or more ad hoc networks,
      previously disjoint, get connected.  In general, network merger
      happens as a consequence of router mobility and/or wireless link
      environment.

   Network partitioning  - The process by which an ad hoc network splits
      into two or more disconnected ad hoc networks.  In general, this
      proccess happens as a consequence of router mobility and/or
      wireless link environment.

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 4]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

2.  Deployment Scenarios

   Automatic configuration of IP addresses of MANET routers (AUTOCONF)
   may be necessary in a number of deployment scenarios.  In this
   section, we outline the use cases that concern and reveal problems
   related to the Autoconfiguration of MANET routers.

2.1.  Standalone MANET

   In this kind of scenario, the MANET is not connected to any external
   network: all traffic is generated by MANET routers and destined to
   routers in the same MANET.  Routers joining a standalone MANET can
   either (i) have no previous configuration, or (ii) already have one
   or more MANET local and/or global addresses, statically or
   dynamically pre-configured, to be used for IP communication.  Due to
   partitions and mergers, standalone MANETs can often be composed with
   both kinds of routers.

   Typical applications of this scenario include private or temporary
   networks, set-up in areas where neither wireless coverage nor network
   infrastructure exist (e.g. emergency networks for disaster recovery,
   or conference-room networks).

2.2.  MANET Connected to an External Network

   In this scenario, the MANET is connected to an external network,
   (e.g. the Internet), by means of one or more gateways.  MANET routers
   can generate traffic directed to remote hosts accross the Internet.
   As in Section 2.1, routers in a connected MANET could either (i)
   already own a global IP address, which could be used for external
   traffic, or (ii) have no previous configuration.

   Examples include public wireless networks of scattered fixed WLAN
   Access Points participating in the MANET of mobile users, and acting
   as Internet Gateways.  Another example of such a scenario is the
   coverage extension of a fixed wide-area wireless network, where one
   or more mobile routers in the MANET are connected to the Internet
   through technologies such as UMTS or WiMAX.

2.3.  Deployment Scenarios Selection

   Both the standalone MANET scenario and the connected MANET scenario
   are to be addressed by solutions for MANET autoconfiguration.

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 5]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

3.  Problem Statement

   MANET routers that do not beneficiate from appropriate static IP
   address configuration may need to automatically configure at least
   one unique local IPv6 address, in order to enable IP communication
   within the MANET.

   To communicate with hosts across the Internet, configuration
   mechanism may also need to provide one or more global IPv6 addresses.
   Internet Gateways typically manage topologically correct IPv6
   prefixes that can be used to configure global address.  They are
   usually managed by an administrative entity (i.e. a network operator
   or service provider), however they can also be opportunistic and
   unmanaged.  Internet Gateways are typically fixed, but may also be
   mobile.  Their presence in the MANET may be intermittent (the number
   of gateways may vary), and thus the availability of an Internet
   connection in the MANET may also be intermittent.

3.1.  Specific Broacast Characteristics

   Traditional dynamic IP address assignment solutions, such as RFC
   2462, 3315 and 2461, do not work as-is in MANETs due to these
   networks' unique properties, as elaborated in the following sections.
   These solutions assume that a broadcast direclty reaches every device
   on the network, whereas it is generally not the case in MANETs.
   Indeed, some routers in the MANET will typically be indirectly
   connected to the source of the broadcast, through several
   intermediate peer mobile ad hoc routers (see [2]).  In that respect,
   it is worth noting that IPv6 does not currently specify an address
   scope that is applicable for MANET scope.

3.2.  Dynamic Topology

   A significant proportion of the routers in the MANET may be mobile
   with wireless interface(s), leading to ever changing neighbors and
   neighbor sets for most MANET routers.  Therefore network topology may
   change rather dynamically compared to traditional networks.  In
   particular, phenomena such as MANET paritionning (i.e. a MANET
   separating into two or more disconnected MANETs) and MANET merging
   (i.e. two or more disconnected MANETs suddenly being connected) are
   potential events that may greatly disrupt the uniqueness of IP
   addresses in use (see [2]).  For instance, a standalone MANET A may
   feature routers that use IP addresses that are locally unique within
   MANET A, but this uniqueness is not guaranteed anymore if MANET A
   merges at some point with another MANET B.

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 6]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

3.3.  Locally Unique Addresses, Globally Unique Addresses

   Moreover, even if a router uses an IP address that is locally unique
   within its MANET, this address may not be fit for Internet
   communication.  Indeed, in order to be able to communicate with
   outside the MANET (i.e. the Internet), a router must use an IP
   address that must be both globally unique, as well as topologically
   correct, reflecting it's current location.

3.4.  Multiple Gateways

   In the case where multiple gateways are available in the MANET,
   specific problems arise.  One problem is the way in which global
   prefixes are managed within the MANET.  If *one* prefix is used for
   the whole MANET, partitioning of the MANET may invalid routes in the
   Internet towards MANET routers.  On the other hand, use of *multiple*
   network prefixes guarantees traffic is unambiguously routed towards
   the gateway owning one particular prefix, but asymmetry in the
   routers' choice of ingress/egress gateway can lead to non-optimal
   paths followed by inbound/outbound data traffic.  Additional problems
   come from issues with current IPv6 specifications.  For example, the
   strict application of RFC2462 may lead to check every IPv6 unicast
   for uniqueness : in a multiple-gateway / multiple-prefixes MANET,
   this could bring to a large amount of control signalling, due to
   frequent reconfiguration.

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 7]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

4.  Solution Guidelines

4.1.  Solution Model

   This section proposes a high-level conceptual view of generic MANET
   autoconfiguration.  The different phases of the autoconfiguration
   process are abstracted by means of diagrams (Fig. 1 - 4), that
   propose different approaches to the process of autoconfiguration,
   which can be applied in different scenarios.  The purpose of this
   framework is to derive a checklist of autoconfiguration
   functionalities, in order to build solutions taylored for different
   scenarios.

   In the "Full DAD" model, depicted in Fig 1, both in-service and pre-
   service DAD aspects are present.  Basically, with regards to IP
   addressing, a device MAY find itself into any of the three different
   phases depicted in Fig 1. :

   The NO ADDRESS phase -  In this phase a device does not have its own
      IP address.  It does not participate in user data forwarding.  If
      a routing protocol is in use in the MANET, the router does not
      process, generate or forward routing control messages generated by
      other devices.  At some point, the router MAY generate a
      (tentative) address by means of a given address generation method.
      When it generates its address, the device should enter the
      ADVERTISING phase.

   The ADVERTISING phase -  In this phase, a device does not participate
      in user data forwarding.  If a routing protocol is in use in the
      MANET, the router does not forward routing control messages
      generated by other routers.  In this phase, the router MAY perform
      pre-service DAD by means of a given mechanism (for instance by
      using specific control signalling, that could be embeded in the ad
      hoc routing signalling in use).  If pre-service DAD is used, and
      the device detects that its tentative address creates a conflict
      with other MANET devices, it should re-enters the NO ADDRESS
      phase.  Else, if pre-service DAD completes without any address
      conflict being detected, or if pre-service DAD is not required,
      the router should enter the NORMAL phase.  Note that if pre-
      service DAD is used, the ADVERTISING phase MAY have incremental
      substates in order to reduce the risks of routing table pollution
      with duplicate addresses.  In the LOCAL ADVERTISEMENT phase, pre-
      service DAD control signalling reaches only a TTL-limited
      neighborhood, whereas in the GLOBAL ADVERTISEMENT phase, pre-
      service DAD control signalling reaches the whole MANET.

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 8]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

   The NORMAL phase -  In this phase, the device participates in IP
      communication normally.  If a routing protocol is in use in the
      MANET, the device MAY process, generate or forward routing control
      messages as specified by the routing protocol in use, and MAY
      generate or forward user data.  A device in this phase MAY perform
      in-service DAD by means of a given mechanism (for instance by
      using specific control messages that can be embeded in the routing
      control messages).  If in-service DAD is used and if the device
      detects an address conflict that forces it to acquire a new
      address to resolve this conflict, the router should return to the
      NO ADDRESS phase.  Note that the phases in this model are cyclic,
      and that a router can pop up in the MANET in any phase.  For
      instance, a router that beneficiated from appropriate static
      preconfiguration MAY start directly in the NORMAL phase.

                 (Address generation)              (In-service DAD)

                                   Duplicate address
                  +--------------+     detected       +--------------+
                  |  NO ADDRESS  |<-------------------|    NORMAL    |
       +----------|    phase     |                    |    phase     |<--+
       |          +--------------+                    +--------------+   |
       |                      ^                                          |
       |                      | Duplicate address                        |
       |(Tentative) address   |     detected                     Address |
       |   generated          +--------+                         checked |
       |                               |                                 |
       |    +--------------------------------------------------------+   |
       |    |                 ADVERTISING phase                      |   |
       |    |                                                        |   |
       |    |     +--------------+                  +-------------+  |   |
       |    |     |  LOCAL AD.   |                  | GLOBAL AD.  |  |   |
       +--->|     |    phase     |----------------->|   phase     |  |---+
            |     +--------------+                  +-------------+  |
            +--------------------------------------------------------+

                             (Pre-service DAD)

                Fig. 1 Phases model with full DAD.

   This conceptual framework reveals three specific potential aspects of
   the MANET autoconfiguration problem:

      - The (tentative) IP addresses generation and assignment aspect.

Baccelli (Ed.), et al.    Expires April 4, 2007                 [Page 9]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

      - The pre-service DAD aspect, to somehow ensure a reasonalble
      belief in the fact that an address about to be assigned does not
      create a conflict.

      - The in-service DAD aspect, to deal with conflicts that are
      detected between already assigned addresses.

   These distinct aspects MAY be combined in order to build solutions
   taylored for different requirements with regards to DAD, as shown in
   Fig. 1 - 4.

       +--------------+                    +--------------+
       |  NO ADDRESS  |                    |    NORMAL    |
       |    phase     |------------------->|    phase     |
       +--------------+       address      +--------------+
                            generation

                 Fig. 2 Phases model without DAD.

               Pre-service DAD
     +-------------------------------------+
     |                                     |
     |                                     |
     |    +--------------+         +---------------+         +--------------+
     |    |  NO ADDRESS  |         |  ADVERTISING  |         |    NORMAL    |
     +--->|    phase     |-------->|     phase     |-------->|     phase    |
          +--------------+         +---------------+         +--------------+

                 Fig. 3 Phases model without in-service DAD.

Baccelli (Ed.), et al.    Expires April 4, 2007                [Page 10]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

                        In-service DAD
       +----------------------------------------------------------+
       |                                                          |
       |                                                          |
       |    +--------------+                   +--------------+   |
       |    |  NO ADDRESS  |                   |    NORMAL    |   |
       +--->|    phase     |------------------>|     phase    |---+
            +--------------+                   +--------------+

                 Fig. 4 Phases model without pre-service DAD.

4.2.  General Requirements

   A solution for IP address autoconfiguration for MANETs is needed for
   mobile ad hoc router to acquire a correct IP address prior to their
   full participation in the mobile ad hoc routing protocol(s) in use.
   Such a solution must address the distributed, multi-hop nature of
   mobile ad hoc networks.  Autoconfiguration mechanisms must be able to
   follow changes in the MANET and react to gateway connectivity loss,
   or to the event of new gateways becoming available, (re)configuring
   addresses accordingly.  A solution must achieve its task with minimal
   overhead, due to scarse bandwidth, and minimal delay, due to the
   dynamicity of the topology.

Baccelli (Ed.), et al.    Expires April 4, 2007                [Page 11]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

5.  Security Considerations

   Address configuration in MANET could be prone to security attacks, as
   in other type of IPv6 networks.  Security threats to IPv6 neighbor
   discovery are discussed in RFC 3756: in particular, analysis includes
   trust model and threats for a specific ad hoc network scenario, where
   all the routers share a common link (i.e. they are one hop away from
   each other, full-meshed connectivity is available).  Although the
   document does not explicitly address MANETs, where routers can be
   multiple hop away from each other, the trust model it provides could
   be valid also in the context of AUTOCONF.  It is also worth noting
   that, in case of MANET connected to the Internet, other threats
   defined in RFC3756 could apply here, e.g. attacks involving routers
   and DoS attacks on Duplicate Address Detection procedures.

   Analysis has to be further extended to include threats, specific to
   multi-hop networks and, in particular, related to the address
   configuration process: security issues of routing protocol operations
   (e.g. how to secure routing protocol messages) are out of scope of
   AUTOCONF WG.

Baccelli (Ed.), et al.    Expires April 4, 2007                [Page 12]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

6.  IANA Considerations

   This document does currently not specify IANA considerations.

7.  References

   [1]  Macker, J. and S. Corson, "MANET Routing Protocol Performance
        Issues and Evaluation Considerations", RFC 2501, January 1999.

   [2]  Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc Network
        Architecture", ID draft-chakeres-manet-arch, October 2006.

   [3]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
        for IPv6", RFC 2461, December 1998.

   [4]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
        Carney, "Dynamic Host Configuration Protocol for IPv6",
        RFC 3315, July 2003.

   [5]  Narten, T. and S. Thomson, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

Baccelli (Ed.), et al.    Expires April 4, 2007                [Page 13]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

Contributors

   This document is the result of joint efforts, including those of the
   following contributers, listed in alphabetical order: C. Adjih
   (INRIA), T. Clausen (Ecole Polytechnique), C. Perkins (Nokia), P.
   Ruiz (University of Murcia), P. Stupar (Telecom Italia), D. Thaler
   (Microsoft).

Baccelli (Ed.), et al.    Expires April 4, 2007                [Page 14]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

Authors' Addresses

   Emmanuel Baccelli
   INRIA

   Phone: +33 1 69 33 55 11
   Email: [email-masked]

   Kenichi Mase
   Niigata University

   Phone: +81 25 262 7446
   Email: [email-masked]

   Simone Ruffino
   Telecom Italia

   Phone: +39 011 228 7566
   Email: [email-masked]

   Shubhranshu Singh
   Samsung

   Phone: +82 31 280 9569
   Email: [email-masked]

Baccelli (Ed.), et al.    Expires April 4, 2007                [Page 15]

Internet-Draft      MANET Autoconf Problem Statement        October 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Baccelli (Ed.), et al.    Expires April 4, 2007                [Page 16]

_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf