Internet DRAFT - draft-chroboczek-ahcp
draft-chroboczek-ahcp
Network Working Group J. Chroboczek
Internet-Draft University of Paris 7
Intended status: Experimental August 9, 2010
Expires: February 10, 2011
The Ad Hoc Configuration Protocol
draft-chroboczek-ahcp-00
Abstract
The Ad Hoc Configuration Protocol is a protocol for automatically
configuring nodes in a multihop mesh network. It is designed to
replace DHCPv4, DHCPv6 and IPv6 Router Advertisements in networks
where these protocols are difficult or impossible to deploy.
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 http://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 February 10, 2011.
Copyright Notice
Copyright (c) 2010 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
(http://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 and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Chroboczek Expires February 10, 2011 [Page 1]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Forwarding Layer . . . . . . . . . . . . . . . . . . . 4
2.2. The Configuration Layer . . . . . . . . . . . . . . . . . 5
2.3. Configuration data . . . . . . . . . . . . . . . . . . . . 10
2.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11
3. Protocol encoding . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Message format . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Message format . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Option format . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Normative References . . . . . . . . . . . . . . . . . . . 26
6.2. Informative References . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chroboczek Expires February 10, 2011 [Page 2]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
1. Introduction
In order to participate in global routing, an IPv4 or IPv6 node needs
to be configured with a globally unique IP address. Additionally, in
order to be useful, a node usually needs a small set of higher-layer
configuration data, such as the address of a DNS forwarder [DNS].
In classical networks, such configuration is usually performed with
no operator intervention using one or more among DHCP [DHCP], DHCPv6
[DHCPv6] or IPv6 Router Advertisements [NDP]. All of these protocols
are based on link-local broadcast or multicast communication, and
hence require that a server be present on every link on which there
is a node requiring configuration.
Mesh networks use a different network model from classical networks,
where the notion of link is not quite clear. In such networks, it is
impractical to deploy servers within every link-local broadcast
domain.
AHCP is a centralised configuration protocol that allows
configuration of nodes across multiple hops. In order to configure a
network using AHCP, a small number of AHCP servers are deployed, and
placed at arbitrary locations. All AHCP nodes implement a very
primitive multicast routing protocol, which is used to carry AHCP
configuration information beyond the direct neighbours of the AHCP
servers.
1.1. Specification of Requirements
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].
Chroboczek Expires February 10, 2011 [Page 3]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
2. Protocol Operation
Every AHCP node is assigned a globally unique 8-octet identifier
known as its Node Id. We suggest that Node Ids should be assigned in
modified EUI-64 format [ADDRARCH].
Every AHCP message is sent with a header carrying a source Node Id, a
destination Node Id, as well as a hop count that limits the message's
distribution. Additionally, the header contains an original hop
count, which is the hop count the message was originated with.
Two Node Ids are special, and MUST NOT be assigned to a node. The
Broadcast Node Id consists of 64 bits of ones, and is used as the
destination field of mesages destined to all nodes within a given hop
count; it MUST NOT appear as the source Id of an AHCP message. The
Undefined Node Id consists of 64 bits of zeroes; it is used
internally by the sample implementation of AHCP, and MUST NOT appear
as either the source or destination Id of an AHCP message.
AHCP is a layered protocol: routing and forwarding of messages is
handled by a lower, Forwarding Layer, while origination and reception
of messages is handled by an upper, Configuration Layer.
2.1. The Forwarding Layer
The forwarding layer is in charge of sending, forwarding and
receiving messages.
2.1.1. Sending messages
When the configuration layer desires to originate a message, it
passes the message a destination Node Id, a hop count and an optional
IPv4 or IPv6 unicast destination address to the Forwarding layer.
The Forwarding layer prepends a message header to the message with
the following data:
o the Source Id field is set to the sender's Node Id;
o the Destination Id field provided by the Configuration layer;
o the Nonce is set to an arbitrary random value
o both the Original Hopcount and Hopcount fields are set to the
value provided by the Configuration layer.
If a unicast destination address was provided, the resulting datagram
is sent to that address, using normal unicast routing. If no such
address was provided, the datagram is flooded over all of the sending
Chroboczek Expires February 10, 2011 [Page 4]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
node's interfaces configured for AHCP operation to the well-known
link-local AHCP multicast address.
2.1.2. Receiving and forwarding messages
Every node maintains a table of recently received messages, indexed
by triples of the form
(Source Id, Destination Id, Nonce)
Upon receiving a message, an AHCP node first validates the message.
It makes the following checks:
o if the message's Hop Count is 0, then the message is silently
discarded;
o if the message's Source Id is the receiving node's Id, then the
message is silently discarded;
o if the message's Destination Id is the undefined Id, then the
message is discarded;
o if the message's Source Id is either the undefined Id or the
Broadcast Id, then the message is discarded;
o if the message is present in the table of recently received
messages, then it is silently discarded.
When a message has passed the above checks, it is inserted in the
table of recently received messages.
The forwarding layer then considers the message for forwarding. If
the message's Hop Count is 2 or more, then, after a small random
delay [JITTER], the hop count is decremented and the message is
forwarded to the well-known AHCP multicast address over all of the
node's interfaces on which forwarding has been configured.
Finally, if the message's Destination Id is either the wildcard Id or
the Id of the receiving node, then the message is passed to the
Configuration Layer for further processing.
2.2. The Configuration Layer
The upper layer of AHCP, known as the configuration layer, is
implemented in terms of the primitives provided by the forwarding
layer, namely originating and receiving messages.
Unlike the forwarding layer, which is a pure peer-to-peer layer, the
Chroboczek Expires February 10, 2011 [Page 5]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
configuration layer follows a client/server architecture. At the
forwarding layer, AHCP messages are divided into requests and
replies. Nodes are divided into three categories:
forwarder nodes, that never originate any messages;
client nodes, that originate requests and receive replies; and
server nodes, that receive requests and originate replies.
2.2.1. Forwarder operation
A forwarder is an AHCP node whose configuration layer that does
nothing. In other words, while a forwarder forwards messages
normally, it never originates messages and ignores any messages
destined to it.
AHCP forwarders are useful to maintain a connected network in
situations where some nodes are configured manually or by other means
than AHCP.
2.2.2. Client Operation
A client is an AHCP node which is configured by AHCP. A client's
configuration layer originates AHCP requests, and receives AHCP
replies.
AHCP clients are structured as finite state automata with four states
(described in detail below). In the Initial state, an ACHP client
has no valid configuration data; in all other states, it has valid
configuration data which it can use for configuring the other
components of the networking stack.
2.2.2.1. The Initial state
In the Initial state, the client has no configuration information.
It periodically (every few seconds) sends a Discover message with
destination Id equal to the broadcast Id. The hop count of this
message is initially 1, and is incremented every three messages.
Upon receiving an Offer message, the client examines the
configuration data that it contains to determine whether it is
acceptable. If it is, it switches to the Requesting state.
2.2.2.2. The Requesting state
In the Requesting state, a client has tentative configuration
information obtained from an Offer message. It periodically (every
Chroboczek Expires February 10, 2011 [Page 6]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
few seconds) sends a Request message with destination Id equal to the
source Id of the recently received Offer message, and hop count equal
to the hop count it used in the Request message that it last sent.
(It might be tempting to use the difference between the initial and
the remaining hop count of the Offer message; however, this might
cause the protocol to fail in the presence of asymmetric links.)
When the client receives an acceptable Ack message from the server,
it configures itself with the data contained in the message and
switches to the Bound state.
If the client receives a Nack message from its selected server, or
times out without receiving an Ack message, it switches back to the
Initial state.
2.2.2.3. The Bound state
In the Bound state, the client has configured itself with data
obtained from an Ack message. This data is valid until the lease
expiration time, defined in Section 2.2.2.5 below.
A few minutes before reaching the lease expiration time, the client
switches to the Renewing state.
2.2.2.4. The Renewing state
The Renewing state is similar to the Configured state, in that the
node is currently configured; however, without a new message from the
server, this data will expire soon.
In this state, the client behaves just like it does in the Requesting
state: it periodically sends a Request message with destination Id
equal to the source Id of the Offer message, and hop count equal to
the hop count it used in the Request message that it last sent.
When the client receives an acceptable Ack message from the server,
it compares it with its stored configuration. If the stored
configuration and the received data only differ in the lease
expiration time, it extends its lease validity time with no further
action. Otherwise, it deconfigures itself and then configures itself
with the new data. It then switches to the Bound state.
If the client receives a Nack message from its selected server, or
the lease validity time is reached, it unconfigures itself and
switches to the Initial state.
Chroboczek Expires February 10, 2011 [Page 7]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
2.2.2.5. Lease expiration time
Every Ack message carries a relative time, written "expires", after
which the configuration is no longer valid; this value is determined
by the server, and already contains sufficient slack to cover any
propagation time, processing time and clock skew. If the server has
a real-time clock, the message also carries the absolute UTC time,
written "originating_time", at which the Ack message was originated.
The lease expiration time is the time, w.r.t. the client's local
clock, at which the client node MUST discard any configuration data
it has. Assuming that the Ack message was received by the client
node at time "reception_time" (according to its local clock), then
the lease expiration time is defined as follows. If the node has a
real-time clock, and the server included an originating time, then
the lease expiration time is defined as:
MIN(reception_time + expires, originating_time + expires)
Otherwise, it is simply defined as
reception_time + expires
2.2.2.6. Optimisations
When the client is in the Renewing state, and therefore is configured
with one or more unicast addresses, unicast routing has a good chance
of being operational; hence, a useful optimisation is to send Request
messages to a unicast address. If the Ack message that was used for
configuring contained a My-IPv6-address or My-IPv4-address option,
and hence an IP address of the server is known, the client SHOULD
send the Request message in a unicast packet addressed to one of the
server's IP addresses a small number of times before switching to
normal multicast operation.
Another useful optimisation is to increase the hop count of requests
at the very end of the Renewing state. The algorithm described above
assumes that the distance between the client and its selected server
has not increased during the lease's lifetime; if it has, the client
will loose its lease, deconfigure, switch back to the Initial state
and reconfigure. Increasing the hop count of Request messages just
before the lease expires can avoid this extra configuration cycle.
2.2.3. Server Operation
An AHCP server has persistent storage where it keeps a databsse of
leases given out to clients. Additionally, it has a local clock that
remains stable across reboots (but see Section 2.2.3.3). Note that
Chroboczek Expires February 10, 2011 [Page 8]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
the clock is not assumed to be synchronised with UTC, although more
reliable operation is possible when it is.
Upon receiving a request, the server sends a reply. The exact
behaviour depends on the kind of the request message.
2.2.3.1. Replying to a Discover message
Upon receiving a Discover message, the server checks whether it is
likely that it could reply positively to an identical Request
message; this may involve checking the lease database, but MUST NOT
involve committing the lease to permanent storage.
If this is the case, the server replies with an Offer message
containing, to the extent possible, the same data that it would send
in an ACK reply to an identical Request message. Otherwise, the
server simply drops the received message, letting the client fall
back to a different server.
2.2.3.2. Replying to a Request message
Upon receiving a Request message, the server takes any actions
necessary to reserve any resources offeredto the client; this will
probably involve committing a lease into stable storage. If
reserving the resources is possible, it replies with an ACK message
listing any resources granted to the client.
If it is not possible to satisfy the client's request, the server
SHOULD reply with a NACK message. This message MAY be empty, but
SHOULD contain any data that allows the client to identify the
request that is being denied; for example, any IP address formerly
assigned to this client SHOULD be included.
2.2.3.3. Operation without a stable clock
An AHCP server SHOULD monitor its real-time clock, and refuse to give
out leases unless it believes that its clock is reasonably stable;
this might involve checking for NTP synchronisation, or simply making
a number of consistency checks.
In isolated mesh networks, however, it may be difficult or impossible
to guarantee that servers' clocks are stable. For this reason, AHCP
supports a mode of operation with no stable clocks.
In this mode of operation, the lease database maintains not only the
leases' expiration time, but also the leases' initial duration. If
the server's clock remains stable, leases are allowed to expire
normally; whenever a clock instability is detected (e.g. because the
Chroboczek Expires February 10, 2011 [Page 9]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
system is rebooted, has gone into a sleep mode, or the real-time
clock has been stepped), all lease expiration times are reset to
their initial duration.
2.3. Configuration data
AHCP messages carry a body, which is structured as a list of options.
Every option is a TLV specifying a piece of configuration data.
Additionally, an option can be marked as "mandatory" by preceding it
by a specific option called "Mandatory".
With the exception of the Origin Time, My IPv6 Address and My IPv4
Address options, the precise semantics of options depends on the kind
of message they are sent in. These options SHOULD be included in all
messages if possible.
2.3.1. Options in Discover and Request messages
Mandatory options contained in a Discover or Request message mandate
constraints that a server SHOULD obey when constructing a reply. If
a server is unable to satisfy a mandatory option in its reply, it
SHOULD silently ignore the request if it is a Discover message, and
SHOULD reply with a Nack if the request is a Request message.
Non-mandatory options contained in a Discover or Request message
specify suggestions to the server; the server SHOULD, if possible,
obey the suggestions; however, if this is impossible, the server MUST
NOT refrain from replying positively to a request just because a
suggestion could not be satisfied.
Options in Discover and Request messages can have one of three forms:
an option in a request may be empty (i.e. its Length field may be
0), in which case it requests or suggests that the same option be
included in the server's reply;
as a special case, an option in a request may have a value (i.e.
its Length field may have the expected value for this kind of
option), in which case it requests or suggests that the same
option be included in the server's reply and have this exact
value;
in the particular case of requests containing a prefix, the Length
field may have a value of 1, in which case the option contains the
suggested or requested prefix length.
Note that it is permissible for an option to appear twice in a single
Discover or Request message, once as a mandatory and once as a non-
Chroboczek Expires February 10, 2011 [Page 10]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
mandatory option. For example, it is usual for a client to send a
Request containing both a mandatory empty IPv4-address option, and a
non-mandatory non-empty IPv4-address option. In this case, the
client is requesting an IPv4 address, and suggesting what its value
should preferably be.
2.3.2. Options in positive replies
An option in an Offer or Ack message specifies a given value or set
of values for a given configuration parameter. Positive replies MUST
NOT contain duplicate options, and MUST NOT contain empty options.
A mandatory option in such a message specifies that the client MUST
use this option for configuration if it uses any of the options
included in the message. In other words, a client MUST NOT use a
message for configuration unless it is going to use all the data
contained in all of the mandatory options in the message.
For example, a network that does not allow access to DNS servers
outside it will send mandatory DNS Server options to force all
clients to use its DNS servers. (Note that this is not a security
mechanism, just a way to indicate to clients how to configure so as
to not run afoul of a network's policies.)
2.3.3. Options in Nack replies
Bodies of Nack replies contain options that could not be satisfied by
the server. Empty options are allowed, in which case they indicate
an option that could not be included by the server.
2.4. Extensibility
The AHCP protocol is extensible: new message types and new options
may be added in the future.
2.4.1. New message types
The forwarding layer is agnostic to message types: nothing in the
specification in Section 2.1 requires checking the message type.
Hence, the forwarding layer treats unknown message types in the same
way as it treats the message types defined in this document.
The configuration layer MUST silently ignore any message with an
unknown message type.
Chroboczek Expires February 10, 2011 [Page 11]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
2.4.2. New option types
Upon receiving a message containing a mandatory option with an
unknown option type, the receiving node MUST ignore the whole
message, except if it is a Request message, in which case the
receiving node SHOULD send a Nack message in reply.
Non-mandatory options with an unknown option type MUST be silently
ignored; their presence MUST NOT prevent the rest of the message from
being processed normally.
Chroboczek Expires February 10, 2011 [Page 12]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
3. Protocol encoding
An AHCP message is sent as the body of a UDP datagram, either sent to
the well-known link-local AHCP multicast address, in which case the
network-layer hop count MUST be set to 1, or to an arbitrary unicast
address. In either case, the datagram is sent to the well-known AHCP
port.
3.1. Message format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic = 43 | Version = 1 | Hopcount |Orig. Hopcount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Id +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Id +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Body...
+-+-+-+-+-+-+-+-+-+-+
Fields:
Magic The arbitrary but carefully chosen value 43; messages with
a first octet different from 43 MUST be silently ignored.
Version This document specifies version 1 of the AHCP protocol.
Messages with a second octet different from 1 MUST be
silently ignored.
Hopcount The remaining hop count of this message. Messages with a
hop count of 0 MUST be silently ignored. Messages with a
hop count of 1 MUST NOT be forwarded.
Original Hopcount The original hop count of this message. This
field MUST NOT be modified by forwarders.
Nonce An arbitrary 32-bit value chosen so that the triple (Source
id, Destination id, Nonce) is globally unique.
Chroboczek Expires February 10, 2011 [Page 13]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
Source Id The id of the node sending this message.
Destination Id The id of the destination node, or the broadcast id
if this message is destined to all nodes.
Body The body of the message.
3.2. Message format
The body of an AHCP message consists of a single AHCP message. Any
data following the message MUST be forwarded without modification,
and silently ignored on reception.
All messages have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MBZ | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-
Fields :
Type This field specifies the kind of message.
MBZ This field is sent as 0, and MUST be ignored on reception.
Length The length of the body, exclusive of the Type, Reserved and
Length fields. If the body is longer than the expected
length of a given type of message, any extra data MUST be
silently ignored.
Options A list of options either requested or offered by this
message.
The following messages have been defined:
0 Discover: this message is used by a client to locate servers
willing to provide it with configuration data.
1 Offer: this message is used by a server to reply to a Discover
message.
Chroboczek Expires February 10, 2011 [Page 14]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
2 Request: this message is used by a client to request configuration
data from a particular server.
3 Ack: this message is used by a server to reply positively to a
Request message.
4 Nack: this message is used by a server to reply negatively to a
Request message.
5 Release: this message is optionally used by a client to release
any configuration data that has been granted to it.
3.3. Option format
Messages carry a body that consists of a sequence of options. Except
for Pad and Mandatory, all options have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields :
Option no This field specifies the kind of option.
Length The length of the value, exclusive of the Option no, and
Length fields.
Value This is the value of this option.
3.3.1. Format of specific options
3.3.1.1. Pad
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+
| Option no. |
+-+-+-+-+-+-+-+
The Pad option is ignored on reception.
Fields :
Chroboczek Expires February 10, 2011 [Page 15]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
Option no Set to 0 to indicate a Pad option.
3.3.1.2. Mandatory
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+
| Option no. |
+-+-+-+-+-+-+-+
The mandatory option specifies that the option immediately following
it is mandatory.
Fields :
Option no Set to 1 to indicate a Mandatory option.
3.3.1.3. Origin Time
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | Absolute time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Origin Time option specifies the time, encoded as a number of
seconds since 00:00:00, 1 January 1970 UTC, at which this message was
originated. This option SHOULD be included in all messages if the
originating node has a real-time clock that is trusted to be
synchronised with UTC within a few seconds, and MUST NOT be sent if
the sending node does not have such a clock. Note that this option
is unusual in that it has the same meaning whatever kind of message
it is sent in.
Fields :
Option no Set to 2 to indicate an Origin Time option.
Chroboczek Expires February 10, 2011 [Page 16]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
3.3.1.4. Expires
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Expires option specifies the time interval, encoded as a number
of seconds, after which the configuration data contained in this
message will stop being valid. Any extra margin intended to cover
propagation time and clock skew MUST be included in this time
interval. An Expires option MUST be included in every Ack message.
Fields :
Option no Set to 3 to indicate an Expires option.
3.3.1.5. My-IPv6-address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Address 1 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Address 2 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
The My-IPv6-Address option specifies one or more global unicast IPv6
addresses of the originating node. This option SHOULD be sent if the
sending node has a global IPv6 unicast address over which it can be
reached, and MUST NOT be sent if the sending node has no IPv6
Chroboczek Expires February 10, 2011 [Page 17]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
address, or if it is unable to receive AHCP packets sent over IPv6
unicast. Note that this option is unusual in that it has the same
meaning whatever kind of message it is sent in.
Fields :
Option no Set to 4 to indicate a My-IPv6-Address option.
Address 1... Specifies a unicast IPv6 address that can be used for
reaching the originating node.
3.3.1.6. My-IPv4-address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The My-IPv4-Address option specifies one or more unicast IPv4
addresses of the originating node. This option SHOULD be sent if the
sending node has an IPv4 unicast address over which it can be
reached, and MUST NOT be sent if the sending node has no IPv4
address, or if it is unable to receive AHCP packets sent over IPv4
unicast. Note that this option is unusual in that it has the same
meaning whatever kind of message it is sent in.
Fields :
Option no Set to 5 to indicate a My-IPv4-Address option.
Address 1... Specifies a unicast IPv4 address that can be used for
reaching the originating node.
Chroboczek Expires February 10, 2011 [Page 18]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
3.3.1.7. IPv6 Prefix
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Prefix 1 |
+ +
| |
+ +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ... |
+
The IPv6 Prefix option specifies one or more IPv6 prefixes suitable
for stateless autoconfiguration.
Fields :
Option no Set to 6 to indicate an IPv6 prefix option.
Prefix 1... Specifies a prefix, encoded as a 16-octet prefix
followed by a 1-octet prefix length, that the receiving
node may use for stateless autoconfiguration. The prefix
length SHOULD be shorter than 64.
3.3.1.8. IPv4 Prefix
The Option number 7 is reserved for the IPv4 Prefix option. This
option MUST NOT be sent, and MUST be silently ignored on reception,
unless it is marked with the Mandatory option, in which case the
whole message MUST be silently ignored.
Chroboczek Expires February 10, 2011 [Page 19]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
3.3.1.9. IPv6 Address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Address 1 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Address 2 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Address option specifies one or more IPv6 addresses that are
assigned to the requesting node.
Fields :
Option no Set to 8 to indicate an IPv6 Address option.
Address 1... Specifies a unicast IPv6 address that is assigned to
the requesting node.
3.3.1.10. IPv4 Address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 Address option specifies one or more IPv4 addresses that are
assigned to the requesting node.
Fields :
Chroboczek Expires February 10, 2011 [Page 20]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
Option no Set to 9 to indicate an IPv4 Address option.
Address 1... Specifies a unicast IPv4 address that is assigned to
the requesting node.
3.3.1.11. IPv6 Prefix Delegation
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Prefix 1 |
+ +
| |
+ +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ... |
+
Fields :
Option no Set to 10 to indicate an IPv6 Prefix Delegation option.
Prefix 1... Specifies an IPv6 prefix that is delegated to the
requesting node.
3.3.1.12. IPv4 Prefix Delegation
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Prefix 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ...
+
Fields :
Option no Set to 11 to indicate an IPv4 Prefix Delegation option.
Chroboczek Expires February 10, 2011 [Page 21]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
Prefix 1... Specifies an IPv4 prefix that is delegated to the
requesting node.
3.3.1.13. Name Server
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Address 1 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Address 2 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nameserver option specifies one or more addresses of DNS servers
to be used by the requesting node.
Fields :
Option no Set to 12 to indicate a Nameserver option.
Address 1... A list of addresses of suitable name servers. IPv6-
mapped IPv4 addresses are allowed.
Chroboczek Expires February 10, 2011 [Page 22]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
3.3.1.14. NTP Server
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option no. | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Address 1 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Address 2 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NTP Server option specifies one or more addresses of SNTP servers
to be used by the requesting node.
Fields :
Option no Set to 13 to indicate an NTP Server option.
Address 1... A list of addresses of suitable SNTP servers. IPv6-
mapped IPv4 addresses are allowed.
Chroboczek Expires February 10, 2011 [Page 23]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
4. Security Considerations
As defined in this document, AHCP is a completely insecure protocol.
Any node can pose as an AHCP server, and any node can perform a
denial-of-service attack on a server by requesting large numbers of
leases. While a number of mitigations are possible, a proper
solution to this issue requires cryptographically authenticating each
AHCP message; the provision of ignoring any data that follows the
message is designed to allow appending a cryptographic key.
Unlike DHCP, which is purely a link-local protocol, AHCP allows for
packets to be sent to global unicast addresses. An AHCP network's
border routers should be configured to drop AHCP packets coming from
the global Internet, and AHCP node should be configured to ignore
AHCP packets with a global source address that does not belong to the
network configured by AHCP.
The information that an AHCP node announces to its neighbours is
often sufficient to determine a mobile node's physical location with
reasonable precision. The privacy issues that this causes can be
mitigated somewhat by using randomly chosen Node Ids and changing
them periodically.
Chroboczek Expires February 10, 2011 [Page 24]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
5. IANA Considerations
The sample implementation of AHCP uses the multicast group ff02::
cca6:c0f9:e182:5359 and the UDP port 5359.
Chroboczek Expires February 10, 2011 [Page 25]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
6. References
6.1. Normative References
[ADDRARCH]
Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
6.2. Informative References
[DHCP] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003.
[DNS] Mockapetris, P., "Domain names - implementation and
specification.", RFC 1035, November 1987.
[JITTER] Floyd, S. and V. Jacobson, "The synchronization of
periodic routing messages", IEEE/ACM Trans. Netw. 2, 2,
122-136, April 1994.
[NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery in IPv6", RFC 4861, September 2007.
Chroboczek Expires February 10, 2011 [Page 26]
Internet-Draft The Ad Hoc Configuration Protocol August 2010
Author's Address
Juliusz Chroboczek
University of Paris 7
175 Rue du Chevaleret
75013 Paris,
France
Email: jch@pps.jussieu.fr
Chroboczek Expires February 10, 2011 [Page 27]
