| TOC |
|
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.
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 (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.
1.
Introduction
1.1.
Specification of Requirements
2.
Protocol Operation
2.1.
The Forwarding Layer
2.2.
The Configuration Layer
2.3.
Configuration data
2.4.
Extensibility
3.
Protocol encoding
3.1.
Message format
3.2.
Message format
3.3.
Option format
4.
Security Considerations
5.
IANA Considerations
6.
References
6.1.
Normative References
6.2.
Informative References
§
Author's Address
| TOC |
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] (Mockapetris, P., “Domain names - implementation and specification.,” November 1987.).
In classical networks, such configuration is usually performed with no operator intervention using one or more among DHCP [DHCP] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.), DHCPv6 [DHCPv6] (Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) or IPv6 Router Advertisements [NDP] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery in IPv6,” September 2007.). 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.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
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] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.).
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.
| TOC |
The forwarding layer is in charge of sending, forwarding and receiving messages.
| TOC |
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:
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 node's interfaces configured for AHCP operation to the well-known link-local AHCP multicast address.
| TOC |
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:
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] (Floyd, S. and V. Jacobson, “The synchronization of periodic routing messages,” April 1994.), 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.
| TOC |
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 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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
In the Requesting state, a client has tentative configuration information obtained from an Offer message. It periodically (every 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.
| TOC |
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 (Lease expiration time) below.
A few minutes before reaching the lease expiration time, the client switches to the Renewing state.
| TOC |
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.
| TOC |
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
| TOC |
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.
| TOC |
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 (Operation without a stable clock)). Note that 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.
| TOC |
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.
| TOC |
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.
| TOC |
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 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.
| TOC |
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.
| TOC |
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-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.
| TOC |
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.)
| TOC |
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.
| TOC |
The AHCP protocol is extensible: new message types and new options may be added in the future.
| TOC |
The forwarding layer is agnostic to message types: nothing in the specification in Section 2.1 (The Forwarding Layer) 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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
- 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.
| TOC |
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.
- 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.
| TOC |
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.
| TOC |
| TOC |
0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+ | Option no. | +-+-+-+-+-+-+-+
The Pad option is ignored on reception.
Fields :
- Option no
- Set to 0 to indicate a Pad option.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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 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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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 :
- 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.
| TOC |
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.
| TOC |
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.
- Prefix 1...
- Specifies an IPv4 prefix that is delegated to the requesting node.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
The sample implementation of AHCP uses the multicast group ff02::cca6:c0f9:e182:5359 and the UDP port 5359.
| TOC |
| TOC |
| [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. |
| TOC |
| [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. |
| TOC |
| Juliusz Chroboczek | |
| University of Paris 7 | |
| 175 Rue du Chevaleret | |
| 75013 Paris, | |
| France | |
| Email: | jch@pps.jussieu.fr |