2.3.3 Ad-Hoc Network Autoconfiguration (autoconf)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-25

Chair(s):

Thomas Clausen <thomas.clausen@polytechnique.fr>
Shubhranshu Singh <shubhranshu@samsung.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: manetautoconf@ml.free.fr
To Subscribe: manetautoconf-request@ml.free.fr
Archive:

Description of Working Group:

In order to communicate among themselves, ad hoc nodes (refer to RFC
2501) need to configure their network interface(s) with local
addresses that are valid within an ad hoc network. Ad hoc nodes may
also need to configure globally routable addresses, in order to
communicate with devices on the Internet.

From the IP layer perspective, a MANET presents itself as a L3
multi-hop network formed over a collection of links. Thus, each ad hoc
node in the MANET is, potentially, acting as a L3 router in order to
provide connectivity to other nodes within the MANET. Each ad hoc node
maintains host routes to other ad hoc nodes
within the MANET - in addition to network routes to destinations
outside the MANET. If connected to the Internet, MANETs are edge
networks, i.e. their boundary is defined by their edge routers. Due to
the nature of the links over which a MANET is formed, ad hoc nodes
within a MANET do not share access to a single multicast-capable link
for signaling. This implies that the usual delivery semantics of
link-local multicast and broadcast are not preserved within a MANET.

The address autoconfiguration related protocol specifications such as
RFCs 2462, 2461, as used in traditional IP networks, assume that
subnet-local signals (e.g. link-local multicast signals) are received
by each of the hosts on the particular subnet without being forwarded
by the routers defining the subnet boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.

The main purpose of the AUTOCONF WG is to standardize mechanisms to be
used by ad hoc nodes for configuring unique local and/or globally
routable IPv6 addresses. The ad hoc nodes under consideration are,
once configured, expected to be able to support multi-hop
communication by running MANET routing protocols as developed by the
IETF MANET WG. An AUTOCONF mechanism should not be dependent on any
specific MANET routing protocol, however the routing protocol may
provide for optimizations. With this in mind, the goals of AUTOCONF WG
are to:

- Produce a "MANET architecture" document defining the MANET
architecture as is related to IP networks and the Internet.

- Produce a "terminology and problem statement" document, defining the
problem statement and goals for AUTOCONF.

- Develop an IPv6 address autoconfiguration mechanism to be used by ad
hoc nodes for configuring unique local addresses as well as, in cases
where Internet connectivity exists, globally routable unique
addresses.

- Develop a mechanism to promote configured address uniqueness in the
situation where different ad hoc networks merge.

Issues and requirements related to prefix and/or address providing
entities, such as an Internet gateway, will be addressed within the
group to the extent that they are directly related to the AUTOCONF
mechanisms. Security concerns related to AUTOCONF mechanisms will also
be discussed within the group.

The working group will reuse existing specifications whenever
reasonable and possible.

Goals and Milestones:

Oct 2005  Submit 'MANET architecture' document for WG review
Nov 2005  Submit 'terminology and problem statement' document for WG review
Apr 2006  Submit 'MANET architecture' document to IESG for publication as an informational RFC
May 2006  Submit 'terminology and problem statement' document to IESG for publication as an informational RFC
May 2006  Submit initial I-D of 'IPv6 address autoconfiguration mechanism' for WG review
May 2006  Submit initial -ID of 'configured address uniqueness maintenance' for WG review
Sep 2006  Revise WG documents and review
Dec 2006  Revise documents based upon implementation experience
Apr 2007  Submit 'IPv6 address autoconfiguration mechanism' specification and supporting documentation to IESG for publications as Proposed Standard
Apr 2007  Submit 'configured address uniqueness maintenance' specification and supporting documentation to IESG for publications as Proposed Standard
Oct 2007  Close or recharter the WG

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Ad hoc Network Autoconfiguration WG (autoconf)

Tuesday, November 8, 2005 at 1740-1840 
=============================

CHAIRS: Shubhranshu Singh 
        Thomas Clausen   

Minute taker: Masafumi Watari
 
Agenda
- Agenda bashing :05 min
- AUTOCONF charter presentation: 10 min
- MANET architecture discussion - Chairs: 20 min
- Terminology & Problem statement discussion - Perkins: 
  (draft-singh-autoconf-adp-02.txt) : 15 min
- Framework for MANET autoconfiguration - Mase: 10 min
(http://www.net.ie.niigata-u.ac.jp/AUTOCONF/draft-mase-autoconf-framework-01.txt)
- (multi-gateway considerations, if time permits - Simon Ruffino )

=============================
AUTOCONF charter presentation - Chairs

Changes since autoconf BOF

Deliverables

WG Milestones

Tom: Whether also IPv4 autoconfiguration be part of this or is it 
exclusively repeated.

Thomas: IPv6 only and is chartered.

Tom: Know a few people interested in it.  Would the WG consider
that then?

Margarret:  No.  If we finish IPv6, then we can consider that.

=============================
- MANET Architecture discussion - Chairs: 20 min

Why...?
- Chartering process of AUtoCONF revealed divergent understanding: "we 
know, but havnen't communicated well"
- MANET originated in routing area
- Now spreading to INT area
- Deployment scenarios, which may, in time, involve other WGs and areas

Where...?
- MANET?
- AUTOCONF?
- Elsewhere?
- Since ATOCONF brought the need of such discussion & document to light:
 -> first deliverable of AUTOCONF

What...?
- What is a MANET?
- Why is it different/
- What does MANET imply for IP / the IETF?
- Overriding question:
 - Do we need to rework all IETF protocols inorder to function MANET?
  -> NO

Traditional Observations
- MANETs support:
 - highly dynamic topology
 - fragile, low-capacity links
 - no dedicated infrastructure components

Example Differences

 Other Networks              |MANETs
 ----------------------------+------------------------------
 Links for the network       |Network forms the links
 Broadcast Interfaces        |Half-Broadast Interfaces
 Routing: diff. interfaces   |Routing: same interface
 Hierarichal ctrl. structure |Entirely "flat", decentralized
 Seperate infra./host        |Both infra./host
 No, or macro-mobility       |Yes - micro mobility
 ...                         |...

Q: When you talk about Hierarichal, are you refering to the control
strucutre?

Thomas C: Yes

Dave T: Routing in diff/same, I don't see a real difference.
Thomas: The difference is with Broadcast and multicast.
Dave T: Then your talking about the second line, so there is no difference
with the third line.  On the 4th one, there are work on it so

Dave T: Is it true that it is not legal for a node not to have to forward 
in the base requirement?

Charlie: Entirely "flat"... issue.

Q: with the routing, there might be cases re-directs.

Marshley: Does a MANET node has to forward?

Shubhranshu: Yes.

Marshley: Then it is not entirely flat.

Thomas C: MANET protocol is flat, there could be hierarichal topology 
with other protocols.

Q: About routing in the same interface issue,  I want to generaize that 
when MANET nodes could have multiple interfaces. Whether there is a need 
to relay or not, MANET node must do so. How would we call MANET nodes 
that does not involved in relaying.  We need to clarify that.

Thomas C: We will discuss this on the ML.

Roadmap
- This IETF
 - Solicit disussions on arch I-D
- Post IETF
 - publish MANET arch I-D
  - draft-autoconf-manet-arch-xx.txt

Reminder
- Charter
 - Oct 05: submit "MANET arch" document for WG review
 - Apr 06: submit "MANET architecture" document to IESG for publication
Dave T: I think that it is a right place to do this here in the INT area.

=============================
Terminology & Problem statement discussion - C. Perkins: 
(draft-singh-autoconf-adp-02.txt)

Updates since ver 00
- A better term explanation
- Problem Statement section
 - MANET node's multi-hop feature explanation
 - MANET node's host and router capability explanation
- Inclusion of goals section
- Better scenario section explanation
- Editorial changes

Terminologies
- Local address
 - valid only within the MANET
- Standalone ad hoc netwokr
 - MANET not connected to any other/infra network
- Hybrid ad hoc network
 - MANET connected to infra network
- Internet Gateway
 - a node which has connectivity to the internet and enables a MANET
   to be reachable from the Internet
 - Sometimes called GATEWAY for short

RM: Local address, to me don't have clear picture in a Hierarichal MANET. 
So, MANET is considered as a stub network, if we have large MANETs, and 
dive MANET into MANET, then what is the scope for the local address?
Charlie: It seems to me that would be outside of the initial scope of 
the charter.  It could be possible by extending the first effort.

RM: How would you define the scope of the local address?

Charlie: For example by changing the prefix length?

Dave T: MANET node may have nodes that are not forwarders, so does local 
address include nodes that doesn't do forwarding. Unique local address 
would be more preferrable.

Charlie: Are you suggesting not to include the term?

Dave T: We should not try and invent new terms.

Thomas C: Agree on that.

Terminology (cont)
- Duplicate address detection
- Network Merger
- Network partition

Problem Statement
- Typical features of ad hoc networks
 - Multi-hop packet forwarding
 - Hosts also relay packets
 - Infrastucture-less
 - Arbitrary mobility/dyanmic topology
 - Different concept of link
- These features require reexaminaiton of existing mechanisms
 - RFC 2462, 2461, 3315, etc
- No standard specification today describes how ad hoc nodes should 
  autoconfigure an IP address and perform DAD

Problem Statement (scenarios)
- A MANET may appear in two different situations
 - There is complete absence of any infra
  - standalone ad hoc network
 - there is address and/or prefix allocation agency
  - hybrid ad hoc network

- switching between the above wo
  - requires the allocation modes to be compabitle
- A MANET autoconfiguration solution should be able to accomomodate  all 
  these situations

Problem Statement (partition/merger)
- Network merger & partition
 - inherent property of ad hoc network
 - may occur at any point of time
 - merger may result i naddress conflict
 - relevant to standalone as well as hybrid network
 - partition may not cause any problem, but resources could be used 
   multiple times after the partition ocurs (i.e., once in each partitioned 
   subset)

RM: If you have a MANET with two gateways and advertise same prefixes, 
do you have to host route and share to the gateways? Parition case could 
be a problem with multiple gateway.


Charlie: Agree for further studies.

Thomas N: Its not specific to MANET and can also be said to any network

Charlie: Not different but enphasize the need for a solution to the problem

Goals
- A MANET node which needs to configure an address
- MUST configure local address(es) when standalone.  It MAY also configure global
address(es) when connected to the Internet.
- MUST perform duplicate address detection
- SHOULD use a mechanism to detect network merger and to ensure the uniqueness of its current address-in-use
- MAY need a mechanism to detect network partition
- Note regarding security: 

Q: DAD before interface thing, you may need to join a routing protocol, 
that seems hard to meet.

Charlie: There are several ways to do it and there is a solution, but is 
not the only solution.

RM: Should we require to mention to the goals in the solution.

Charlie: lets take it to the ML.

To Do
- Terminology
 - MANET-DAD ro DAD?
 - MANET-local address or local addres
 - Any others
- Routing-addressing dependincies
- security considerations

Brain: Back in the goals, do you have a number of nodes...
to support?

Thomas N: DAD, you need to work it across the entire MANET, but the
thing you need is DAD that local in each MANET.  For example, if we can
have only a single node for each link, then what we need is a mechanism
to provide unique prefix to each link

Thomas: Will continue discussion on that on the ML.

=============================
- Framework for MANET autoconfiguration - Mase: 10 min
(http://www.net.ie.niigata-u.ac.jp/AUTOCONF/draft-mase-autoconf-framework-01.txt)
A Common Framework for Autoconfiguration of Stand-Slone Ad Hoc Networks

Aims
- Autoconfiguration of unique local address for a stand-alone MANET
- Not a solution, but a common framework

Terms
- Tentative address
- Address generation
- MANET-wide DAD
 - The action of detecting address conflict in the MANET
  - Pre-Service MANET-DAD: verify that a tentative address is out of address
    conflict with other MANET nodes.
  - In-Service MANET-DAD
    ...
- Familiar addres - an address is familiar to a node

Out of time....skipping slides

Fig: Autoconfiguration state transition diagram.

Additional Benefits of Autoconfiguration States
...

Thomas C: While we have two charter items on the architectural and 
problem statements, that does not preclude that on the ML in producing 
the solution space. Also please get involved in the architectural 
document.

Slides

Agenda bash & Charter
MANET Architecture
Problem Statement Update
Solution Framework