IPng Working Group N. Asokan
INTERNET DRAFT Patrik Flykt
5 January 2000 Charles E. Perkins
Nokia
Thomas Eklund
Xelerated Networks
AAA for IPv6 Network Access
draft-perkins-aaav6-02.txt
Status of This Memo
This document is a submission by the ipng Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted to
the ipng@sunroof.eng.sun.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
IPv6 nodes (clients) need a way to offer credentials to a local AAA
in order to be granted access to the local network. For IPv6, it will
be more efficient and thus reasonable to expect such access controls to
be exerted by IPv6 routers, possibly as part of performing their role
as DHCPv6 relays. DHCPv6 servers and routers are expected to work in
conjunction with AAA servers to determine whether or not the client's
credentials are valid.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page i]
Internet Draft AAA for IPv6 5 January 2000
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 1
3. General Framework 3
3.1. Protocol Description . . . . . . . . . . . . . . . . . . 3
3.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 5
3.3. Replay Protection . . . . . . . . . . . . . . . . . . . . 5
3.4. AAA Credential . . . . . . . . . . . . . . . . . . . . . 6
4. Instantiation with Stateless Address Autoconfiguration 6
4.1. Structure of Protocol Messages . . . . . . . . . . . . . 6
4.1.1. AAA Protocol Message types . . . . . . . . . . . 7
4.1.2. AAA Protocol Message options . . . . . . . . . . 7
4.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Basic operation . . . . . . . . . . . . . . . . . 8
4.2.2. Challenge Request . . . . . . . . . . . . . . . . 10
4.2.3. Termination . . . . . . . . . . . . . . . . . . . 10
4.3. Initiation of the AAA Process . . . . . . . . . . . . . . 11
5. Instantiation with Mobile IPv6 11
6. Instantiation with DHCPv6 11
6.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 11
6.2. Renewal of the AAA credentials . . . . . . . . . . . . . 13
6.3. DHCP Client Considerations . . . . . . . . . . . . . . . 13
6.4. DHCP Relay Considerations . . . . . . . . . . . . . . . . 14
6.5. DHCP Server Considerations . . . . . . . . . . . . . . . 14
7. Message Formats for Stateless Address Autoconfiguration 15
7.1. AAA Challenge Option . . . . . . . . . . . . . . . . . . 15
7.2. AAA Protocol Messages . . . . . . . . . . . . . . . . . . 15
7.3. AAA Protocol Message Options . . . . . . . . . . . . . . 17
7.3.1. Client Identifier option . . . . . . . . . . . . 17
7.3.2. Security Data . . . . . . . . . . . . . . . . . . 18
7.3.3. Challenge . . . . . . . . . . . . . . . . . . . . 19
7.3.4. Generalized Key Reply . . . . . . . . . . . . . . 19
7.3.5. Timestamp . . . . . . . . . . . . . . . . . . . . 21
7.3.6. IPv6 Address . . . . . . . . . . . . . . . . . . 21
7.3.7. Lifetime . . . . . . . . . . . . . . . . . . . . 22
7.3.8. Embedded Data . . . . . . . . . . . . . . . . . . 23
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page ii]
Internet Draft AAA for IPv6 5 January 2000
8. Message Formats for Stateful Address Autoconfiguration with
DHCPv6 24
8.1. NAI Extension . . . . . . . . . . . . . . . . . . . . . . 24
8.2. AAA-Credential Extension . . . . . . . . . . . . . . . . 24
8.3. AAA-Challenge/Response Extension . . . . . . . . . . . . 25
8.4. Generalized AAA Key Reply Extension . . . . . . . . . . . 26
9. Security Considerations 26
10. Open Issues and Discussion 26
10.1. Packet Service Filter . . . . . . . . . . . . . . . . . . 26
10.2. Use of Destination Options . . . . . . . . . . . . . . . 26
References 27
Addresses 28
1. Introduction
This document proposes a way for IPv6 nodes (clients) to offer
credentials to a local AAA server in order to be granted access to
the local network. Whereas for IPv4 it is not clear that routers and
DHCP will be equipped to handle such functions, we believe that it is
more efficient and thus reasonable to expect such access controls to
be exerted by IPv6 routers, possibly as part of performing their role
as DHCPv6 relays. DHCPv6 servers and routers are expected to work in
conjunction with AAA servers to determine whether or not the client's
credentials are valid.
Routers can exert such network access control by the device of
carefully controlling entries in their packet filter and Neighbor Cache.
If a host does not supply verifiable credentials, then the router SHOULD
NOT forward packets to that host. Furthermore, such uncredentialed
devices should have no access (or perhaps only very limited access) to
the other network links adjacent to the router. Only in this way can
a new host be prevented from abusing network connectivity before its
authorization is complete.
2. Terminology
This document makes use of many terms defined in recent AAA
requirements documents (for example, [4]). The general framework
consists of nodes in the following general relationship:
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 1]
Internet Draft AAA for IPv6 5 January 2000
Local Domain Home Domain
+------------------------+ +--------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +--------------------------+ | |
| +---+--+ | | +------+ |
| | \ +------+ | | |
| | \ | other| | +--------------+
+------+ | +---+--+--+---+ | |
| | | | | | | | C = client
| C |- -|- -| A | F |---+ | A = attendant
| | | | | | | F = packet filter
+------+ | +------+------+ | other = other AAA clients
| | AAAL = local authority
+------------------------+ AAAH = home authority
From a system point of view:
+--------------------------+ +----------------+
| Router System | | AAA Server |
+-------------+ | | | Infrastructure |
| Host System | | +--------+ +---------+ | | +------------+ |
| | | | F | | A +-------+ AAAL | |
| | | +--------+ +---------+ | | | | |
| +------+ | | | | | | +-----+------+ |
| | C | | | +------+------+ | | | |
| +------+ | | Controlled | Uncontrolled| ==================
+------|------+ +------------|-------------+ | | |
| | | +-----+------+ |
+-----------------------+ | | AAAH | |
| | | |
| +------------+ |
+----------------+
The entities in the pictures above are defined as follows:
Host System: The host system is the node requesting access to the
network.
Client: The client is the entity whose authorization is checked.
The client resides on the host system.
Router System: The router is the node that provides network access
to the host. In addition to the usual packet forwarding
functionality, the router system typically consists of other
functional blocks like the attendant and the packet filter.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 2]
Internet Draft AAA for IPv6 5 January 2000
Attendant: The attendant is the entity that extracts
identification and authorization data sent by the client and
forwards them to AAAL for verification. It is also responsible
for making the necessary configuration updates (e.g., to the
packet filter, and the router's neighbor cache) so that only
authorized clients can access the network.
Packet filter: A packet filter/firewall/security gateway is the
entity responsible for disallowing unauthorized datagram
traffic. When a client is authorized, the access control list
of the filter is updated with the corresponding host's IP
address(es).
Controlled and uncontrolled access: Each network interface of
the router can be configured to provide AAA services. When
an interface is so configured, all transiting packets are
subject to controlled access. If a packet does not pass access
control, but is an AAA message addressed to the router, it is
given to the Attendant in the uncontrolled access part.
AAAL: The AAA server in the foreign domain that mediates local
access to the AAA infrastructure.
AAAH: The AAA server in the home domain which is able to authorize
each of its clients.
Other nodes: Other hosts that perform some function as a result of
the policy received from AAAH, e.g. accounting, QoS, etc.
AAA credential: Data provided by a client to the AAA in an
authorization request. For example, this can be a message
authentication code constructed using a secret shared between
the host and AAAH.
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 [3].
3. General Framework
Using the terminology just introduced, in this section we describe
the general framework for our proposals.
3.1. Protocol Description
The client solicits access to the network in conjunction with some
protocol. Protocols considered in this document include Stateless
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 3]
Internet Draft AAA for IPv6 5 January 2000
Address Autoconfiguration [7] DHCPv6 [2], as an example of a stateful
autoconfiguration service, and Mobile IPv6.
If the router has AAA service enabled, a packet received on the
interface is made available to the controlled part. The controlled part
will only forward traffic that corresponds to an authorized host. All
other packets will be dropped except for upstream AAA authorization
protocol packets (sent by the host to the router). Such packets are
made available to the attendant in the uncontrolled part. The attendant
may extract the relevant AAA data and forward them to AAAL. The overall
protocol is depicted below.
Router
+.......................+
Host . UCP CP . AAAL AAAH
| LC . | | . | |
|<--------------------| | . | |
|AAA Req: LC,RPI,ID,CR| | . | |
|-------------------->| | . | |
| . | AHR | . | |
| . |- - - - - - - - |- - - - - - - - >| AHR |
| . | | . |- - - >|
| . | | . | AHA |
| . | AHA | . |< - - -|
| . |<- - - - - - - -| -.- - - - - - - | |
| . | Update config | . | |
| . |--------------->| . | |
| . | | . | |
| . | | . | |
| . | | . | |
|AAA Rep: stat,RPI,KR | | . | |
|<--------------------| | . | |
| . | | . | |
+.......................+
LC = Local AAA Challenge
RPI = Replay Protection Indicator used between host and AAAH
CR = AAA Credential
ID = Client Identifier
KR = Key Reply
UCP = Uncontrolled part
CP = Controlled part
AHR = AAA Host Request (using an AAA protocol)
AHA = AAA Host Answer (using an AAA protocol)
The figure describes the authorization protocol exchanges in the
generic case. A run of this protocol is initiated by either the
attendant or the host. First, the attendant (uncontrolled part in the
router) sends a local challenge to the host. The host then constructs
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 4]
Internet Draft AAA for IPv6 5 January 2000
an AAA credential which securely binds the local challenge, the client
identifier, any replay protection indicator used between the host and
AAAH, and other necessary information. The credential is such that it
can be verified by AAAH. The host then sends an ``AAA Request'' message
containing the credential and the information necessary to verify
it. The attendant checks that the local challenge included in the AAA
Request is valid, extracts the AAA related information and sends them to
AAAL using an appropriate AAA protocol. We label this message, AAA Host
Request (AHR). AAAL forwards AHR to AAAH, which verifies the credential
and sends back the result, and any necessary keys. We label this reply
message AAA Host Answer (AHA). The AAAL forwards AHA to the attendant.
AAAL may also forward any necessary keys. The attendant extracts the
relevant data from AHA and forwards them to the host. The attendant
updates configuration of the packet filter (controlled part in the
router) so that traffic to and from the host is allowed to pass through.
3.2. Client Identifier
The client identifier MUST enable AAAL to identify a suitable AAAH
for carrying out all necessary authorization steps. A NAI [1] is often
used to convey identities of users although IPv6 networks may well be
constructed to determine the user's identity based only on the IPv6
address of the user's host. Therefore, the client identifier MAY be a
NAI or an IPv6 address. The NAI MAY also identify the user to AAAL,
although this is not necessary (e.g., the user part of the NAI may be a
pseudonym intelligible only to AAAH).
3.3. Replay Protection
Each participant in the protocol SHOULD verify the freshness of
the protocol messages in order to protect itself from replay attacks.
Replay protection between AAAL and AAAH, and between AAAL and attendant
are handled by the AAA protocol. Therefore, we only need to consider
replay protection between the host and the other entities.
The attendant ensures freshness of an AAA Request message from the
host by verifying that the local challenge included in the Request is a
recent one.
The host and AAAH may use either timestamps or random challenges
(nonces) for replay protection. The former is straightforward. The
latter is as follows. In the AAA Reply, AAAH sends an AAAH challenge.
When the host makes the next AAA Request, it includes this AAAH
challenge. It also includes its own host challenge. When AAAH receives
this request, it verifies that the AAAH challenge is current. In
the reply, AAAH copies the host challenge, and includes a new AAAH
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 5]
Internet Draft AAA for IPv6 5 January 2000
challenge. This way, the host can verify the freshness of the reply
from AAAH.
If the AAAH challenge in an AAA Request is not valid, or if the
client sends an explicit request for an AAAH challenge, AAAH will reply
with a new AAAH challenge.
3.4. AAA Credential
An AAA credential is created by the client and is verified by AAAH.
The creation and verification is based on a security association shared
between the client and AAAH. The credential SHOULD securely bind the
following pieces of information:
- Client identifier,
- Local AAA challenge, if one was provided by the attendant, and
- Depending on the style of replay protection being used between
the host and AAAH, either a timestamp or a pair of challenges.
In specific instantiations, additional data may be included in the
computation of the AAA Credential.
The exact algorithm used to compute the AAA Credential depends on the
security association between the client and AAAH. HMAC_MD5 is a suitable
algorithm, based on a shared secret between the client and AAAH.
4. Instantiation with Stateless Address Autoconfiguration
In this section, we describe how the general protocol sketched in
Section 3 can be used with Stateless address autoconfiguration [7].
4.1. Structure of Protocol Messages
We define a five new ICMPv6 messages to transport AAA data between
the host and the attendant. In addition, we defined several options
that can be embedded in a AAA Protocol Message. Detailed definitions of
these messages are given in Section 7. Here we give a brief description
of each AAA protocol message type, and each AAA option. In addition, we
also defined an AAA Challenge option to Router Advertisement using which
the attendant can send a challenge to the host.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 6]
Internet Draft AAA for IPv6 5 January 2000
4.1.1. AAA Protocol Message types
From host to attendant:
AAA Request: Request for client authorization.
AAA Home Challenge Request: Request for a new challenge from AAAH.
AAA Teardown Request: Request to terminate the currently active
AAA registration.
From attendant to host:
AAA Reply: Reply to AAA Request.
AAA Teardown: Indication of termination of the currently active
AAA registration. This may be in response to a AAA Teardown
Request.
4.1.2. AAA Protocol Message options
Each AAA Protocol Message specifies what AAA options may accompany
it. Currently, the following options are defined.
Security Data: This option is intended to carry security data.
Currently, two subtypes are defined.
AAA Credential: Sent by the client; used by AAAH to verify
the authorization of the client.
AAAH Authenticator: Sent by AAAH; used by the client to
verify the authenticity of AAA Reply.
Client Identifier: This option should enable AAAL to determine the
AAAH to which an AAA Request is to be forwarded. Currently,
two subtypes are defined: NAI, and IPv6 address.
Generalized Key Reply: This option is used to distribute session
keys to be used by the host. Currently several pairs of
subtypes are defined.
Challenge: This option is used to carry nonces used for replay
protection. Currently three subtypes are defined:
Local Challenge: Challenge issued by the attendant to the
host.
Home Challenge: Challenge issued by AAAH to the host.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 7]
Internet Draft AAA for IPv6 5 January 2000
Host Challenge: Challenge issued by the host to AAAH.
Timestamp: This option is used to carry timestamp information used
for replay protection.
IPv6 Address: This option is used to carry IP address information.
Lifetime: This option indicates the lifetime of an AAA
verification.
4.2. Protocol Overview
4.2.1. Basic operation
The basic operation follows the model described in Section 3.1. When
an IPv6 host starts up or enter a new subnet, it receives a Router
Advertisement with a AAA Challenge option. As is usual, this Router
Advertisement is either broadcast periodically, or is sent in response
to a Router Solicitation by the host.
The host will construct a tentative IP address and reply with an AAA
Request ICMPv6 message with the following options:
- Local Challenge option into which the challenge in the Router
Advertisement is copied.
- Either Timestamp option or both AAAH Challenge and Host Challenge
options
- IPv6 Address option consisting of the tentative IPv6 address
chosen
- Client Identifier option consisting of the client's NAI or some
long term IPv6 address
- AAA Credential option constructed by concatenating all of the
preceding options and applying the algorithm specified by the
security association between the host and AAAH.
When challenges are used for reply protection, the host MUST include
the current AAAH challenge (received from AAAH via a previous AAA Reply
message) in the AAAH Challenge option, and a random number in the
Host Challenge option. If the host does not have an AAAH challenge,
it SHOULD send an AAA Home Challenge Request message first (see
Section 4.2.2.
The host MAY perform Duplicate Address Detection (DAD) before sending
the AAA Request. In that case, the source address of AAA Request
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 8]
Internet Draft AAA for IPv6 5 January 2000
MUST be the chosen IPv6 address. Otherwise, if the host has not yet
performed DAD, the source address of AAA Request MUST be the unspecified
address.
On receiving the Request, the attendant MUST check if the chosen
address is already in use. If it is, the attendant MUST send an AAA
Reply with code ADDRESS_IN_USE.
Otherwise, the attendant will extract AAA data and forward them to
AAAL in an AHR message using an AAA protocol, which is then forwarded
to AAAH. The data in each AAA option MUST be conveyed to AAAH by the
AHR message. In return, AAAH will construct an AHA message containing
information in a suitable form that can be be extracted by the attendant
and conveyed to the host in an AAA Reply message with appropriate
options. The following options are relevant:
- Either Timestamp option or both AAAH Challenge and Host Challenge
options
- One or more Key Reply options
- Lifetime option
- AAAH Authenticator option
We describe AAAH behavior in terms of what the host should eventually
receive in the AAA Reply. If the AAA Credential is incorrect, the host
MUST receive an AAA Reply with code INVALID_CREDENTIAL. If challenges
are used for replay protection, and if the AAAH challenge is absent or
invalid, the AAA Reply SHOULD have a code NEW_CHALLENGE, and SHOULD
contain an AAAH Challenge option. If timestamps are used for replay
protection, and the Timestamp option is absent or invalid, the AAA Reply
SHOULD have code INVALID_TIMESTAMP.
AAAH SHOULD choose a validity period for the verification which
should be included in the Lifetime option of AAA Reply. If AAAL
proposes its own lifetime value (in the AHR message), then the Lifetime
option MUST contain the lower of the two values. If AAAH chooses a
key to be used between the attendant and the host, that key SHOULD be
encoded in a Host-Attendant Key Reply option. If timestamps are used
for replay protection, there MUST be a timestamp option. If challenges
are used for replay protection, AAAH MUST copy the Host Challenge,
and include a new random number in the AAAH Challenge. Finally, AAAH
should compute an authenticator, to be included in an AAAH Authenticator
option, by concatenating all the preceding options intended for the
host, and applying the algorithm specified by the security association
between the host and AAAH. In addition, AAAH MAY include information in
the AHA message intended for AAAL.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 9]
Internet Draft AAA for IPv6 5 January 2000
If the verification is successful, AAAH will send back an AHA message
indicating success to AAAL. AAAL will forward this to the attendant. If
there are any keys distributed by AAAH, AAAL MUST re-encode those keys
for the attendant.
The attendant MUST add an entry for a host in its neighbor cache and
at the same time update the packet filter with the client's host IP
address when the AAA verification for the client has been successful.
The lifetime of these entries MUST be set to the value specified in the
AHA message. The attendant will extract all information in the AHA
message intended for the host and send them back in an AAA Reply ICMPv6
message. If the source address of the AAA Request was the unspecified
address, the corresponding AAA Reply MUST be sent to the all-nodes
multicast address. Otherwise the AAA Reply MUST be sent to the source
address of the corresponding AAA Request.
The attendant MUST create security associations for the host
corresponding to any keys distributed to it by AAAL.
When the host receives an AAA Reply indicating success, it MUST
verify the AAAH authenticator and the validity of the replay protection
indicator. If verification succeeds, the host MUST create security
associations for the attendant. The host MUST associate the lifetime
specified in the Lifetime option with the address that was authorized.
When the lifetime expires, the host SHOULD re-initiate the AAA process.
4.2.2. Challenge Request
If the host does not have a valid AAAH challenge, it SHOULD send
an AAA Home Challenge Request message. This SHOULD include the Host
Challenge option and MAY include the Client Identifier option. The
AAA Reply SHOULD have code NEW_CHALLENGE, and SHOULD include an AAAH
Authenticator option.
4.2.3. Termination
It is also possible to terminate valid sessions. To terminate
a session, the attendant clears the packet filter and sends a AAA
Teardown message to the host which invalidates the IP address. A
typical scenario for termination would be in a pre-paid service when the
pre-paid amount is used up. The host may request termination by sending
an AAA Teardown Request message. The attendant MUST reply to this
message with an AAA Teardown message. Both of these messages SHOULD be
protected by an IPSec AH header.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 10]
Internet Draft AAA for IPv6 5 January 2000
4.3. Initiation of the AAA Process
The AAA process can be initiated either from the host or from the
attendant. The attendant can initiate the process by sending a Router
Advertisement with the AAA Challenge option. The host can initiate the
process by sending a Router Solicitation.
5. Instantiation with Mobile IPv6
There are two ways to handle Mobile IPv6. First, the host could do
the AAA processing when it obtains a care-of address, and then it could
send a binding update to the home agent, and possibly to the previous
router and other correspondents.
If the home agent and AAAH belong to the same domain, it may be
more efficient to bundle the binding update to the home agent in the
AAA Request message so that the delay is minimized. We support this
possibility by defining a new option called Embedded Data option. The
host generates an IPv6 packet containing the binding update to the home
agent, but instead of sending it directly, it includes it in the AAA
Request as the payload of an Embedded Data option. AAAH will extract
the binding update IPv6 packet and send it to the home agent. The home
agent SHOULD send the binding acknowledgement back to AAAH so that it
can be similarly transported to the host as part of the AAA Reply.
In addition, we define new subtypes to the AAA Generalized Key Reply
option so that AAAH could distribute authentication keys for use between
the home agent and the mobile node.
6. Instantiation with DHCPv6
WARNING: This section has not yet been converted to conform to the
general model described in Section 3.
6.1. Protocol Overview
When a DHCP client needs to allocate an IPv6 address, it will first
send DHCP Solicit messages soliciting for the DHCP servers serving the
network. In the Solicit message the client MAY identify itself using
the NAI extension. The DHCP servers receiving the solicitation reply by
sending DHCP Advertise messages containing an AAA-Challenge extension
to the client. The value of the AAA-Challenge extension is used as a
challenge by the client.
After receiving the DHCP Advertise the DHCP client computes a
response to the challenge and creates a DHCP Request message that is
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 11]
Internet Draft AAA for IPv6 5 January 2000
to be sent to the DHCP server. The DHCP Request message contains an
AAA-Challenge/Response extension, a NAI extension with the client's NAI
and an AAA-Credential extension.
The DHCP server receiving the DHCP Request extracts the NAI, the
response to the challenge and the AAA credential from the DHCP message
and sends these to AAAL. AAAL uses the AAA network to forward the AAA
message to AAAH. AAAH processes the AAA message and forms a reply to
AAAL. The reply may contain keys, policy information, etc. targeted to
AAAL, the DHCP server and/or the DHCP client. AAAL identifies which
information is given to the DHCP server (e.g. keys) and which are to be
applied locally to the network (e.g. policy). The data that is sent to
the DHCP client (e.g. keys, policy, etc.) is treated as opaque by AAAL
and the DHCP server and forwarded to the DHCP client.
Based on the reply from AAAL, the DHCP server forms a DHCP Reply
message either accepting or denying the registration attempt. The
opaque AAA data received from AAAL is inserted in an extension in the
DHCP Reply message.
A session set up using DHCP follows the guidelines specified by the
DHCP protocol when the session is ended.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 12]
Internet Draft AAA for IPv6 5 January 2000
DHCP DHCP
Host relay server F AAAL AAAH
| | | | | |
| DS + NAI | | | |
|--------|------->| | | |
| DA + C | | | |
|<-------|--------| | | |
|DR + C + CR + NAI| AAA message containing the | |
|--------|------->| values sent in the C, CR and NAI | |
| |--------------------------------->| |
| | | | |- - - >|
| | | | |
| | | AAA message | |< - - -|
| |<---------------------------------| |
| DRep + KR? | | Update F | |
|<----------------| |<----------------| |
| | | | | |
| | | | |
| | | | | |
| | | | |
| | | | | |
DS = DHCP Solicit
DA = DHCP Advertise
DR = DHCP Request
DRep = DHCP Reply
C = AAA Challenge/Response
CR = AAA Credential
KR = AAA Key Reply
6.2. Renewal of the AAA credentials
6.3. DHCP Client Considerations
A DHCP client sending a DHCP Solicit MAY include its NAI in the
message. If a DHCP Advertise with an AAA-Challenge/Reply extension is
received the client has to computes a reply. How the reply is computed
is not yet defined.
The DHCP client sends the needed credentials, challenge reply and
its NAI in the DHCP Request message. A NAI extension identifying the
client MUST be included if the DHCP Request contains an AAA-Credential
extension. If there exists and DHCP security association between the
DHCP client and the DHCP server, the DHCP Request message MUST be
protected by that security association. The security association could
for example have been generated at the time of the previous request of
the address.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 13]
Internet Draft AAA for IPv6 5 January 2000
Upon receiving the DHCP Reply the DHCP client has to be ready for the
following to happen:
- The 'status' field of the DHCP Reply indicates that the address
has been successfully leased to the DHCP client. If the DHCP
Reply is secured by an authentication extension, the correctness
of the authentication extension is checked. If the security
association for the authentication extension does not exist, the
DHCP client will first look for an AAA Key Reply extension for
keys needed to create the security association. If such key
information is present, the client creates the needed security
association and retries to verify the correctness of the message.
- The 'status' field indicates success but no AAA reply extensions
are present. The DHCP client will start using the leased address
as normal.
- The 'status' field indicates that the AAA authorizations has
failed. The DHCP client is unable to gain access in the network.
- The 'status' field indicates any other error condition. The DHCP
client continues according to the DHCP protocol.
6.4. DHCP Relay Considerations
A DHCP relay receiving any AAA extensions MUST forward these
extensions unaltered between the client and the server.
6.5. DHCP Server Considerations
A DHCP server MAY add an AAA-Challenge extension to the DHCP
Advertise message. The challenge sent to the client MAY depend on
the NAI extension in the DHCP Solicitation message but it MAY also be
derived independent of the client's NAI.
Depending on the local policy and/or the capability of the DHCP
server, the DHCP server may choose to ignore the AAA information
contained in the NAI, AAA-Credential and both Challenge/Response
extensions. In this case the DHCP server uses the extensions only when
verifying the possible authentication of the DHCP message. In general
a DHCP server receiving the NAI and AAA extensions SHOULD extract and
forward them to the AAAL.
It is assumed that the AAA processing will require time and
computational power, which would be in vain if some of the information
contained in the message is found to be incorrect. Therefore, prior to
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 14]
Internet Draft AAA for IPv6 5 January 2000
sending the information contained in the AAA extensions to AAAL, the
DHCP server checks the correctness of the DHCP Request message.
If AAAL sends e.g. keys back to the DHCP client, the DHCP server
MUST include these in an AAA Key Reply extension in the DHCP Reply
message. The DHCP server will indicate an AAA failure reported by AAAL
by setting the 'status' field in the DHCP Reply message to 'AAA Failed
Authentication', which is an yet undefined value. The DHCP server will
also add the proper authentication extension to the DHCP Reply and any
further messages, if keys have been distributed by the AAA to be used
between the client and the server.
7. Message Formats for Stateless Address Autoconfiguration
7.1. AAA Challenge Option
The AAA challenge option is applicable to Router Advertisements.
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 = TBD | Length | Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The Type field identifies the option as being an AAA
challenge option and has a value of TBD.
Length The Length field gives the length measured in octets
of this option, including the Type and Length fields.
Challenge This field contains a challenge.
7.2. AAA Protocol Messages
AAA Messages are new ICMPv6 messages. They have the following
general structure.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 15]
Internet Draft AAA for IPv6 5 January 2000
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 = TBD | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message body |
+ +
Type The following new types are defined:
AAA Request: TBD
AAA Home Challenge Request: TBD
AAA Teardown Request: TBD
AAA Reply: TBD
AAA Teardown: TBD
Code The code field depends on the message type. Currently the
following Code fields are defined.
- For AAA Reply
SUCCESS: 0
NEW_CHALLENGE: 1
ADDRESS_IN_USE: 20
INVALID_CREDENTIAL: 50
INVALID_TIMESTAMP: 51
- For AAA Teardown
SUCCESS: 0
- No Code values are defined for the remaining AAA
message types. The Code field MUST be set to zero.
Message body The message body may consist of one or more options.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 16]
Internet Draft AAA for IPv6 5 January 2000
7.3. AAA Protocol Message Options
The general structure of an AAA Protocol Message Option is as
follows.
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option data |
+ +
Type The Type field identifies the option. Currently,
the following types are supported. The most
significant bit of the Type indicates if the option
is unskippable (0) or skippable (1).
Subtype Each option type may be further subdivided. The
Subtype field identifies option at the next level of
granularity.
Length The Length field indicates the size of the Option
data in octets.
Option data The format of option data is depends on the type and
subtype, and is defined below.
7.3.1. Client Identifier option
The Client Identifier option is used by AAAL to decide where to route
the AAA request, and by AAAH in verifying the AAA Credential.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 17]
Internet Draft AAA for IPv6 5 January 2000
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+ +
Type 1 (unskippable)
Subtype Currently two subtypes are defined: NAI (0) and IPv6
address (1)
Length For subtype 1, the Length should be 16.
Identifier For subtype 0, this field contains a NAI formatted
according to RFC2486 [1]. For subtype 1, this field
contains an IPv6 address.
7.3.2. Security Data
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Data |
+ +
Type 2 (unskippable)
Subtype Currently two subtypes are defined: AAA
Credential (0) and AAAH Authenticator (1)
Length Length of the option in octets, not including the
first four octets.
SPI The security parameter index to be used in
interpreting the Security Data.
Security Data The actual payload.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 18]
Internet Draft AAA for IPv6 5 January 2000
7.3.3. Challenge
The Challenge option is used to convey nonces for replay protection
between various pairs of entities.
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge |
+ +
Type 3 (unskippable)
Subtype Currently three subtypes are defined:
- Local Challenge: Challenge issued by the
attendant to the host (0)
- Home Challenge: Challenge issued by AAAH to the
host (1)
- Host Challenge: Challenge issued by the host to
AAAH (2)
Length Length of the challenge in octets.
Challenge The actual challenge data.
7.3.4. Generalized Key Reply
This option is used to convey keys distributed by AAAH for use
between the host and other entities.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 19]
Internet Draft AAA for IPv6 5 January 2000
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAAH SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IPv6 Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded Key Data |
+ +
Type 4 (unskippable)
Subtype Currently three pairs of subtypes are defined:
- Host-Attendant authentication key: Key to
be used between the current attendant and
the host for IPSec authentication (0)
- Host-Attendant encryption key: Key to be
used between the current attendant and the
host for IPsec encryption (1)
- MN-HA authentication key: Key to be used
between the home agent and the host for
IPsec authentication (3)
If the most significant bit of the Subtype
value is 1, the ``Peer IPv6 Address'' field is
present. Otherwise, it is absent.
Length Length of the option in octets except the
first four octets.
AAAH SPI This field indicates the security association
between the host and AAAH which should be used
by the host to interpret the Encoded Key Data
field.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 20]
Internet Draft AAA for IPv6 5 January 2000
Key SPI This field indicates the SPI value for the new
security association into which the key should
be inserted.
Peer IPv6 Address When present, this field indicates the IPv6
address of the peer. This is useful when the
client does not already know the address to be
used. This field is present in subtypes 128
and above.
Encoded Key Data This field contains the key, along with any
other information required by the host to
create the security association. The contents
of the field MUST be encrypted by AAAH as
specified by AAAH SPI.
7.3.5. Timestamp
Timestamp field may be used for replay protection between the host
and AAAH.
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+ +
Type 5 (unskippable)
Subtype Currently no subtypes are defined. Should be zero.
Length Length of the Timestamp in octets.
Timestamp Timestamp value in some format mutually intelligible
to the host and AAAH
7.3.6. IPv6 Address
This option is used by the host to convey the IPv6 address it has
chosen. There may be other uses for this option, too.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 21]
Internet Draft AAA for IPv6 5 January 2000
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 6 (unskippable)
Subtype Currently no subtypes are defined. Should be zero.
Length 32
IPv6 Address A valid IPv6 address.
7.3.7. Lifetime
This option is used to indicate the validity period of a successful
AAA verification.
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 7 (unskippable)
Subtype Currently no subtypes are defined. Should be zero.
Length 4
Lifetime Lifetime in seconds.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 22]
Internet Draft AAA for IPv6 5 January 2000
7.3.8. Embedded Data
This option is used to transport specific kinds of embedded data in
the AAA messages.
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 |WH |Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Embedded Data |
+ +
Type 8 (unskippable)
WH This field indicates who should process the embedded data.
It is interpreted as follows (values in binary)
- 00 - Recipient of the AAA Protocol message (i.e.,
either the host or the attendant)
- 01 - AAAL
- 10 - AAAH
- 11 - reserved
Subtype Currently two subtypes are defined:
- MN-HA binding update (0)
- HA-MN binding acknowledgement (1)
Data The actual embedded data itself. For subtype 0, this
SHOULD be an IPv6 packet addressed to the HA, and
containing a binding update. For subtpe 1, this SHOULD
be an IPv6 packet addressed to the CoA, and containing a
binding acknowledgement from the HA.
For example, to bundle the HA binding update with AAA processing,
the host will first generate a binding update, and insert it into an
embedded data option of the AAA Request message, with WH = 10 (binary)
and Subtype = 0. Based on the value of WH, the attendant will extract
the Embedded Data and forward it to AAAH via AAAL. Based on the Subtype,
AAAH will forward the binding update to the home agent, and will receive
a binding acknowledgement in reply. The attendant will forward the
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 23]
Internet Draft AAA for IPv6 5 January 2000
binding acknowledgement in an Embedded Data option to the AAA Reply
message, with WH - 00 (binary) and Subtype = 1.
8. Message Formats for Stateful Address Autoconfiguration with DHCPv6
WARNING: This section has not yet been converted to conform to the
general model described in Section 3.
8.1. NAI Extension
A DHCP client adds the NAI extension to its DHCP Request whenever it
needs to transmit its NAI to the local AAA service.
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 = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI...
+-+-+-+-+-+-
Type The Type field identifies the extension as being a
NAI extension and has a value of TBD.
Length The Length field gives the length measured in
octets of this extension, not including the Type
and Length fields.
NAI This field contains a NAI formatted according to
RFC2486 [1].
8.2. AAA-Credential Extension
The AAA-Credential extension contains AAA credential that the DHCP
client wants to present to the AAA domain. The AAA-Credential extension
is also used by the DHCP server in order to deliver some AAA credentials
to the DHCP client.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 24]
Internet Draft AAA for IPv6 5 January 2000
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 = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA-Credential...
+-+-+-+-+-+-+-+-+-
Type The Type field identifies the extension as
being an AAA-Credential extension and has a yet
undefined value.
Length The Length field gives the length measured in
octets of this extension not including the Type
and Length fields.
AAA-Credential Host credential to be forwarded to AAAL by the
DHCPv6 server.
8.3. AAA-Challenge/Response Extension
When sent in a DHCP Advertise message the AAA-Challenge/Response
extension contains a challenge sent to the client. When the
AAA-Challenge/Response extension is present in a DHCP Request message it
contains a Response to the previous challenge.
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 = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA-Challenge/Response...
+-+-+-+-+-+-+-+-+-
Type The Type field identifies the extension as being
an AAA-Challenge/Response extension and has value
TBD.
Length The Length field gives the length measured in
octets of this extension not including the Type
and Length fields.
AAA-Challenge/Response A challenge when sent to the client or a
response when sent to the server.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 25]
Internet Draft AAA for IPv6 5 January 2000
8.4. Generalized AAA Key Reply Extension
[to be described]
Should we defined a generalized AAA Key Reply extension in
the style of [6] that can carry encoded keys back to the
host and the host can (somehow) insert them into the IPSec
SA database?
9. Security Considerations
Source address based packet filtering does not guarantee that only
authorized clients will be able to send out traffic through the router.
An attacker can fake the source address of IP packets. In situations
where strong protection is needed, hosts should be required to use an
IPSec AH tunnel to the router.
10. Open Issues and Discussion
10.1. Packet Service Filter
There is also a future work to determine how services can be updated
dynamically based on the authorized services. A typical service filter
will permit/deny a filter rule based on upper layer information for the
authenticated IP address.
The attendant could prepare an ACL with service filters based on the
AAA response for the authenticated services for the different UDP/TCP
ports.
10.2. Use of Destination Options
An alternative to defining new ICMPv6 messages and associated options
will be to define new IPv6 destination options for all AAA related
payload. One disadvantage is that the length of destination options
is limited by the 8-bit length field. An advantage is that embedded
data may be transported more naturally using either a Routing Header or
IP-in-IP encapsulation, thereby avoiding the need for something like the
Embedded Data option.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 26]
Internet Draft AAA for IPv6 5 January 2000
References
[1] B. Aboba and M. Beadles. The Network Access Identifier. Request
for Comments (Proposed Standard) 2486, Internet Engineering Task
Force, January 1999.
[2] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for
IPv6 (DHCPv6). Internet Draft, Internet Engineering Task Force,
February 1999. Work in progress.
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[4] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP
Authentication, Authorization, and Accounting Requirements.
Internet Draft, Internet Engineering Task Force, January 2000.
Work in progress.
[5] E. Nordmark. IPv6 hooks for AAA and "host routing". Internet
Draft, Internet Engineering Task Force, March 2000.
[6] C. Perkins and P. Calhoun. Generalized Key Distribution
Extensions for Mobile IP. Internet Draft, Internet Engineering
Task Force, February 2000.
[7] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard)
2462, Internet Engineering Task Force, December 1998.
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 27]
Internet Draft AAA for IPv6 5 January 2000
Addresses
The working group can be contacted via the current chairs:
Stephen E. Deering Robert M. Hinden
Cisco Systems, Inc. Nokia
170 West Tasman Drive 313 Fairchild Drive
San Jose, CA 95134-1706 Mountain View, CA 94303
USA USA
Phone: +1 408 527 8213 Phone: +1 650 625-2004
Fax: +1 408 527 8254 Fax: +1 650 625-xxxx
EMail: deering@cisco.com EMail: hinden@iprg.nokia.com
Questions about this memo can also be directed to the authors:
N. Asokan Thomas Eklund
Nokia Research Center Xelerated Networks
P.O. Box 407 Regeringsgatan 67
FIN-00045 NOKIA GROUP
Helsinki 103 86 Stockholm
Finland Sweden
Phone: +358 40 743 1961 Phone: +46 8 50625753
E-mail: n.asokan@nokia.com E-mail: thomas.eklund@xelerated.com
Fax: +358 9 4376 6852 Fax: +46 8 54553211
Patrik Flykt Charles E. Perkins
Nokia Networks Communications Systems Lab
P.O. Box 321 Nokia Research Center
FIN-00045 NOKIA GROUP 313 Fairchild Drive
Mountain View, California 94043
Finland USA
Phone: +358 9 511 68072 Phone: +1-650 625-2986
E-mail: patrik.flykt@nokia.com EMail: charliep@iprg.nokia.com
Fax: +358 9 511 68080 Fax: +1 650 625-2502
Asokan, Eklund, Flykt, Perkins Expires 5 July 2001 [Page 28]