IETF Securing Neighbor Discovery WG Tuomas Aura
INTERNET DRAFT Microsoft Research
Expires August 2003 February 2003
Cryptographically Generated Addresses (CGA)
draft-aura-cga-00.txt
Status of This Memo
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
Cryptographically generated addresses (CGA) are IPv6 addresses
where the interface identifier is generated by hashing the address
owner's public key. The address owner can then use the
corresponding private key to assert address ownership and to sign
messages sent from the address without any additional security
infrastructure. This document describes a generic CGA format that
can be used in multiple applications.
Aura Expires August 24, 2003 [Page 1]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
Table of Contents
Status of This Memo...............................................1
Abstract..........................................................1
Table of Contents.................................................2
1. Introduction...................................................3
2. The CGA Address Format.........................................4
3. The CGA Certificate and the Hash Values........................5
4. CGA Generation.................................................6
5. CGA Verification...............................................8
6. Security Considerations.......................................10
Acknowledgments..................................................12
Intellectual Property Statement..................................12
References.......................................................13
Authors' Addresses...............................................14
Aura Expires August 24, 2003 [Page 2]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
1. Introduction
This document specifies how to create IPv6 addresses from the
cryptographic hash of a public key (and auxiliary parameters).
Public-key signatures can then be used for authenticating messages
from the address owner. The main advantage of the CGA-based
authentication is that additional security infrastructure, such as
a PKI or TTP, is not needed. Potential applications include Mobile
IPv6 binding update authentication (e.g. as a part of the CAM
protocol [OR01]), proof of address ownership in secure neighbor
discovery and duplicate address detection [AAK+02], and key
exchange for opportunistic IPSec encryption and authentication.
The address format defined in this document differs from previous
proposals [OR01][Nik01][MC02] at least in the following respects:
(1) Two hash values are computed instead of one. The first hash
value (Hash1) is used to produce the Interface Identifier
(i.e. rightmost 64 bits) of the address. The purpose of the
second hash (Hash2) is to artificially increase that
computational complexity of generating new addresses and,
consequently, the cost of brute-force attacks. This allows
the address owner to select levels of security above the 62-
bit limit of CAM.
(2) The Routing Prefix (i.e. leftmost 64 bits) of the address is
included in the first hash input, which makes some brute-
force attacks against global-scope addresses more expensive
because the attacker must do a separate brute-force search
for each address prefix. However, we take care not to make
mobility more expensive for the address owner. When the
Routing Prefix changes, the second hash value can be reused,
thus avoiding the expensive brute-force part of address
generation.
(3) The input to both hash functions is formatted as (parts of)
a self-signed X.509 v3 certificate. This has several
advantages. First, a self-signed certificate is a standard
format for storing and transferring public keys in Internet
protocols. Second, the signature on the certificate proves
that the public-key owner wants to use the IPv6 address.
Third, future protocols may bind arbitrary security-critical
information (other than the address owner's public key) to
the IPv6 address by defining a new type of certificate
extension for that purpose. Fourth, the use of X.509 v3
certificates makes it easy to use CGA-based and PKI-based
address authentication side by side in the same protocols.
Some protocols, however, may need to save octets and
transfer only the public key and other absolutely necessary
Aura Expires August 24, 2003 [Page 3]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
parameters, rather than a full self-signed certificate. An
optimized parameter format is defined for this purpose.
In order to verify the address owner's signatures, one needs to
have the address itself and the associated self-signed certificate,
which contains the public key. The address format and certificate
format are defined in Sections 2 and 3. The detailed algorithms for
generating addresses and for verifying them are given in Sections 4
and 5. Finally, Section 6 discusses security of the technique.
2. The CGA Address Format
The leftmost 64 bits of the 128-bit IPv6 Address form the Routing
Prefix. The rightmost 64 bits of the address are called the
Interface Identifier.
Cryptographically generated addresses also have a security
parameter (Sec), which determines the level of security. The
security parameter is a 3-bit unsigned integer encoded in the three
rightmost bits of the 128-bit IPv6 address.
Sec = Address & 7
The address is associated with a self-signed X.509 v3 certificate,
which contains the address owner's public key. Two hash values
Hash1 and Hash2 are computed from parts of the certificate. The
format of the certificate and the inputs to the hash functions are
defined in Section 3.
A cryptographically generated address (CGA) is defined as an IPv6
address where the 12*Sec leftmost bits of the second hash value
Hash2 are zero, and the rightmost 64 bits of the first hash value
Hash1 equal the Interface Identifier of the address. The three
rightmost bits of the address, which encode the security parameter
Sec, and the universal and group bits are ignored in the
comparison. The latter two bits must both be one. [Alternatively,
we can stick with U=1, G=0. That would make it difficult to use
CGA-based authentication side by side with weaker protocols.]
The above definition can be stated in terms of the following three
bit masks (Mask1, Mask2, Mask3):
Mask1 = 0x00000000000000000000000000000000 if Sec=0,
0xfff00000000000000000000000000000 if Sec=1,
0xffffff00000000000000000000000000 if Sec=2,
0xfffffffff00000000000000000000000 if Sec=3
0xffffffffffff00000000000000000000 if Sec=4,
0xfffffffffffffff00000000000000000 if Sec=5,
Aura Expires August 24, 2003 [Page 4]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
0xffffffffffffffffff00000000000000 if Sec=6, and
0xfffffffffffffffffffff00000000000 if Sec=7
Mask2 = 0x00000000000000000300000000000000
Mask3 = 0x0000000000000000fffffffffffffff8
A cryptographically generated address is an IPv6 address for which
the following are true:
(Hash1 & Mask3) | Mask2 == Address & Mask3
Hash2 & Mask1 == 0
3. The CGA Certificate and the Hash Values
Each CGA address is associated with a self-signed X.509 v3
certificate [HFPS02][ITU97]. The subjectPublicKeyInfo data value in
the certificate is the address owner's public key. A certificate
extension contains the following parameters: a 12-octet Modifier,
the 8-octet Routing Prefix of the address, and Collision Count,
which can get values 0, 1 and 2. The extnID field in the extension
has the following value:
cgaExtnID = { 1 3 6 1 4 1 311 TBD }
The critical field in the extension MAY be set to false or true,
depending on whether the certificate has other uses than CGA-based
authentication. The extnValue field in the extension contains a
DER-encoded data value of the following type:
CGAParameters ::= SEQUENCE {
modifier OCTET STRING (SIZE 12),
routingPrefix OCTET STRING (SIZE 8),
collisionCount INTEGER (0..2) }
Two 128-bit hash values Hash1 and Hash2 are computed with the MD5
algorithm from parts of the certificate. The input to Hash1 is the
concatenation of the DER-encoded subjectPublicKeyInfo and
CGAParameters data values. The input to Hash2 is the concatenation
of the DER-encoded subjectPublicKeyInfo and modifier data values.
As an alternative to the certificate, an optimized parameter format
MAY be used. The optimized format is simply the concatenation of
the subjectPublicKeyInfo and CGAParameters data values. Security
protocols that use CGA addresses MUST specify whether they use the
certificate format or the optimized parameter format. The same
address MAY be used in both types of protocols.
Aura Expires August 24, 2003 [Page 5]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
Note 1: The DER encoding of the CGAParameters data value is 29
octets long and has the following (hexadecimal) format: 30 1d 04 0c
xx xx xx xx xx xx xx xx xx xx xx xx 04 08 yy yy yy yy yy yy yy yy
02 01 zz, where xx..xx is the Modifier, yy..yy is the Routing
Prefix, and zz is the Collision Count. All the 29 octets are
included in the input to Hash1. Only the 12 octets xx..xx are
included in the input to Hash2.
4. CGA Generation
The process of generating a new CGA takes three input values: a 64-
bit Routing Prefix, the Public Key of the address owner, and the
security parameter Sec, which is an unsigned 3-bit integer. The
result is a new CGA and the associated self-signed certificate (as
defined in Sections 2-3). The cost of generating a new CGA depends
on the security parameter Sec, which gets values from 0 to 7.
If Sec=0, a CGA can be generated from the hash input with the
following steps:
(1) DER-encode the address owner's public key as an ASN.1
structure of the type SubjectPublicKeyInfo.
(2) Create an ASN.1 structure of type CGAParameters. Set the
modifier data value to 12 zero octets. Set the routingPrefix
data value to be the Routing Prefix. Set the collisionCount
data value to zero. DER-encode the CGAParameters data value.
(3) Concatenate the DER-encoded SubjectPublicKeyInfo and
CGAParameters data values. Execute the MD5 algorithm on the
concatenation. The result is Hash1.
(4) Concatenate the 64-bit Routing Prefix and the rightmost 64
bits of Hash1 to form a 128-bit IPv6 address.
(5) Set the group and universal bits in the address both to 1
and the three rightmost bits of the address all to 0.
(6) If an address collision is detected, increment the
collisionCount data value in the DER-encoded CGAParameters
data value and go back to step (3). However, after three
collisions, stop and report the error.
(7) Create and sign a self-signed X.509 v3 certificate using the
SubjectPublicKeyInfo data item created in step (1). Include
in the certificate an extension where the extnID has the
value cgaExtnID, critical has the value false or true, and
the extnValue contains the encoded CGAParameters data value
Aura Expires August 24, 2003 [Page 6]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
from step (2). The certificate MAY contain other fields and
extensions.
If the generated CGA will be used only in protocols that that use
the optimized parameter format, step (9) MAY be skipped.
Nodes MAY set the security parameter Sec to zero and implement only
the above procedure, which is deterministic and relatively fast.
However, it is RECOMMENDED that implementations support the
generation of addresses with higher Sec values. For any Sec value
from 0 to 7, a CGA can be created as follows:
(1) DER-encode the address owner's public key as an ASN.1
structure of the type SubjectPublicKeyInfo.
(2) Create an ASN.1 structure of type CGAParameters. Set the
modifier data value to 12 random octets. Set the
routingPrefix data value to be the Routing Prefix. Set the
collisionCount data value to zero. DER-encode the
CGAParameters data value.
(3) Concatenate the DER-encoded SubjectPublicKeyInfo and
modifier data values. Execute the MD5 algorithm on the
concatenation. The result is Hash2.
(4) Compare the 12*Sec leftmost bits of Hash2 with zero. If they
are all zero (or if Sec=0), continue with the step (5).
Otherwise, increment the modifier data value (as if the
content octets of the modifier were a 96-bit integer) and go
back to step (3).
(5) Concatenate the DER-encoded SubjectPublicKeyInfo and
CGAParameters data values. Execute the MD5 algorithm on the
concatenation. The result is Hash1.
(6) Concatenate the 64-bit Routing Prefix and the rightmost 64
bits of Hash1 to form a 128-bit IPv6 address.
(7) Set the group and universal bits in the address both to 1
and the three rightmost bits of the address to the value
Sec.
(8) If an address collision is detected, increment the
collisionCount data value in the encoded CGAParameters data
value and go back to step (5). However, after three
collisions, stop and report the error.
(9) Create and sign a self-signed X.509 v3 certificate using the
SubjectPublicKeyInfo data item created in step (1). Include
Aura Expires August 24, 2003 [Page 7]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
in the certificate an extension where the extnID has the
value cgaExtnID, critical has the value true or false, and
the extnValue contains the encoded CGAParameters data value
from step (2). The certificate MAY contain other fields and
extensions.
If the generated CGA will be used only in protocols that that use
the optimized parameter format, step (9) MAY be skipped.
Note 1: The initial value of Modifier in step (1) and the method of
modifying it in step (4) MAY be chosen arbitrarily. In order to
avoid trying the same Modifier values repeatedly, it is RECOMMENDED
that the initial value is chosen randomly. The quality of the
random number generator is not important as long as the same values
are not repeated frequently. The RECOMMENDED way to modify Modifier
is to increment the content octets of the modifier data value as if
they were an unsigned 96-bit integer. (Octet order can be chosen
arbitrarily and overflows can be ignored.)
Note 2: For security parameter values greater than 0, this second
algorithm is not guaranteed to terminate after a certain number of
iterations. The brute-force search in steps (3)-(4) takes on the
average approximately 2^(12*Sec) iterations to complete.
Note 3: If the Routing Prefix of the address changes but the
address owner's public key does not, the old value of Modifier can
be used and it is unnecessary to repeat the brute-force search.
5. CGA Verification
CGA verification takes two inputs: an IPv6 address and a self-
signed X.509 v3 certificate. In protocols where saving octets is
essential, the certificate MAY be replaced by the optimized
parameter format (i.e. a concatenation of the DER-encoded
SubjectPublicKeyInfo and CGAParameters data items). The
verification either succeeds or fails. If the verification
succeeds, the verifier knows that the certificate contains the
public key of the address owner. The verifier can then use the
public key to authenticate signed messages from the address owner
or to exchange a session key with the address owner.
The CGA is verified with the following steps:
(1) Compare the group and universal bits in the address to one.
If either bit is zero, the address is a non-CGA address and
no verification can be done.
(2) Read the security parameter Sec from the three rightmost
bits of the address. (Sec is an unsigned 3-bit integer.)
Aura Expires August 24, 2003 [Page 8]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
(3) Find the encoded subjectPublicKeyInfo data value in the
certificate.
(4) Find and decode a certificate extension with extnID value
equal to cgaExtnID. Decode the content octets of the
corresponding extnValue data value, which have the type
CGAParameters. Check that the collisionCount value is 0, 1
or 2. The CGA verification fails if the extension does not
exist, if decoding of the extension fails, or if the
collisionCount value is out of range.
(5) Check that the routingPrefix data value is equal to the
Routing Prefix (i.e. leftmost 64 bits) of the address.
(6) Concatenate the encoded SubjectPublicKeyInfo and
CGAParameters data values. Execute the MD5 algorithm on the
concatenation. The result is Hash1.
(7) Take the rightmost 64 bits of Hash1 output and compare them
with the Interface Identifier (i.e. the rightmost 64 bits)
of the address. Differences in the group and universal bits
and in the three rightmost bits are ignored. If the 64-bit
values differ (other than in the five ignored bits), the CGA
verification fails.
(8) Concatenate the encoded SubjectPublicKeyInfo and modifier
data values. Execute the MD5 algorithm on the concatenation.
The result is Hash2.
(9) Compare the 12*Sec leftmost bits of Hash2 with zero. If any
one of these is non-zero, CGA verification fails. If Sec=0,
verification never fails at this step.
(10)
Verify the signature on the self-signed certificate. If the
signature is invalid, the GCA verification fails. Otherwise,
the CGA verification succeeds.
All nodes that verify CGAs MUST be able to process all security
parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7. The verification
procedure is relatively fast and always requires a constant amount
of computation.
In protocols where the optimized parameter format is used instead
of the certificate format, the signature verification in step (10)
is skipped.
Note 1: The values of Modifier and Collision Count are ignored in
the CGA verification procedure, except for checking that Collision
Aura Expires August 24, 2003 [Page 9]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
Count is in the allowed range in step (3) and for including them
into the appropriate hash inputs.
6. Security Considerations
The purpose of CGA addresses is to prevent stealing and spoofing of
IPv6 addresses. The public key of the address owner is bound
cryptographically to the address. The address owner can use the
corresponding private key to assert its ownership of the address
and to sign messages sent from the address.
It is important to understand that that attacker can create a new
address from an arbitrary routing prefix and its own public key.
What the attacker cannot do is to impersonate somebody else's
address. This is because the attacker would have to find a
collision of the cryptographic hash value Hash1. (The property of
the hash function needed here is called second pre-image
resistance.)
The signature on the self-signed certificate proves that the owner
of the public key wants to be associated with the address. The
signature also binds other certificate fields to the address.
Protocols that use CGAs but need to bind additional information
(other than the public key) to the address may define new
certificate extensions for this purpose.
Some CGA applications may need to sign individual IPv6 packets. A
CGA-signed packet will have the CGA address as its source address,
and it will have to contain the associated certificate, a payload,
and a signature. There is the problem that the packet size may
exceed the Ethernet MTU. In that case, the optimized parameter
format, rather than the full certificate, can be sent to the
verifier. (In fact, the full certificate need not be created if it
is not needed for other protocols.) Protocols that use this
optimization obviously cannot require verification of the signature
on the certificate. These protocols should include the source
address of the packet in the signed message in order to prove that
the public-key owner wants to use the address. For simplicity, the
signature on the self-signed certificate MUST always be verified if
a certificate is available to the verifier.
As computers become faster, the 64 bits of the Interface Identifier
will not be sufficient to prevent attackers from searching for hash
collisions. It helps somewhat that we include the routing prefix of
the address in the hash input. This prevents the attacker from
using a single pre-computed database to attack addresses with
different routing prefixes. The attacker needs to create a separate
database for each routing prefix. Link-local addresses are,
Aura Expires August 24, 2003 [Page 10]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
however, left vulnerable because the same routing prefix is used by
all IPv6 nodes.
In the long term, some kind of hash extension technique must be
used to counter the effect of faster computers. Otherwise, the CGA
technology could become outdated after 5-20 years. The idea in this
document is to increase the cost of both address generation and
brute-force attacks by the same parameterized factor while keeping
the cost of address use and verification constant. This provides
protection also for link-local addresses.
For this purpose, the input to a second hash function Hash2 is
modified by varying the value of Modifier until the leftmost 12*Sec
bits of Hash2 are zero. This increases the cost of address
generation approximately by a factor of 2^(12*Sec). It also
increases the cost of brute-force attacks by the same factor. That
is, the cost of creating a certificate that binds the attacker's
public key with somebody else's address is increased approximately
by a factor of 2^(12*Sec). The address owner may choose the
security parameter Sec depending of its own computational capacity
and the expected lifetime of the address. Currently, Sec values
between 0 and 2 are sufficient for most IPv6 nodes. As computers
become faster, higher Sec values will slowly become useful.
Theoretically, if a typical attacker is able to tap into N local
networks at the same time, an attack against link-local addresses
is N times as efficient as an attack against addresses of a
specific network. This effect can be countered by using log2(N)
bits longer hash extensions for link-local addresses than for
global-scope addresses. (Incrementing Sec by one causes a 12-bit
increase in the length of the hash extension.)
In order to make it possible for mobile nodes whose routing prefix
changes frequently to use Sec values greater than 0, we have
decided not to include the routing prefix in the input of Hash2.
The result is weaker than if the routing prefix were included in
the input of both hashes. On the other hand, our scheme is at least
as strong as using the hash extension technique without including
the routing prefix in either hash. It is also at least as strong as
not using the hash extension but including the routing prefix. This
trade-off was made because mobile nodes frequently move to insecure
networks where they are at the risk of denial-of-service attacks,
for example, during the duplicate address detection procedure.
In most applications of CGA, the goal is prevent denial-of-service
attacks. Therefore, it is usually sensible to start by using a low
Sec value and to replace addresses with stronger ones only when
denial-of-service attacks based on brute-force search become a
significant problem. On the other hand, if CGA is used as a part of
Aura Expires August 24, 2003 [Page 11]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
a strong authentication or secrecy mechanisms (e.g. CGA
authentication plus Secure DNS), then it may be necessary to start
with higher Sec values. (Fortunately, link-local addresses are not
used in the latter kind of applications.)
Collision Count is used to modify the input to Hash1 if there is an
address collision. It is important not to allow Collision Count
values higher than 2. First, it is extremely unlikely that three
collisions would occur and the reason is certain to be either a
configuration or implementation error or a denial-of-service
attack. (These DoS attacks can be prevented if the IPv6 neighbor
discovery messages are authenticated with CGA addresses.) Second,
an attacker who is doing a brute-force search to match a given CGA
address can try all different values of Collision Count without
repeating the brute-force search for Modifier. Thus, the more
different values are allowed for Collision Count, the less
effective the hash-extension technique is in preventing brute-force
attacks.
It is important to understand that when a CGA address is used to
authenticate messages from an IPv6 node, the receiver of the
message must know the exact IPv6 address. In network layer
signaling, such as duplicate address detection and Mobile IPv6
binding updates, the IPv6 address is the natural identifier for a
network node. In other applications, such as opportunistic IPSec,
it is possible to get around the protection by tricking the
receiver into accept the wrong IPv6 address, e.g. by DNS spoofing,
unless the address resolution is protected by at least equally
strong mechanisms.
Finally, CGA-based authentication has some implications on privacy.
The CGA addresses can be randomized by choosing a random initial
value for Modifier and by generating a new address at desired
intervals. If the node reveals the associated certificate or public
key to its correspondents, it should also replace the public key at
the same time as the address. This gives the same level of
protection as the IPv6 address privacy extensions [ND01]. However,
the cost of public-key and address generation may imply less
frequent address changes.
Acknowledgments
Many of the ideas in this draft were influenced by Michael Roe,
Christian Huitema and Pekka Nikander.
Intellectual Property Statement
The author believes that there are several patents or patent
applications that cover parts of this specification.
Aura Expires August 24, 2003 [Page 12]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
References
[AAK+02] Jari Arkko, Tuomas Aura, James Kempf, Vesa-Matti
M„ntyl„, Pekka Nikander, and Michael Roe. Securing IPv6 neighbor
discovery and router discovery. In Proc. 2002 ACM Workshop on
Wireless Security (WiSe), pages 77-86, Atlanta, GA USA, September
2002. ACM Press.
[Eas99] Donald Eastlake. Domain name system security extensions. RFC
2535, IETF Network Working Group, March 1999.
[HD98] Robert M. Hinden and Stephen E. Deering. IP version 6
addressing architecture. RFC 2373, IETF Network Working Group, July
1998.
[HFPS02] Russell Housley, Warwick Ford, Tim Polk, and David
Solo. Internet X.509 public key infrastructure certificate and
certificate revocation list (CRL) profile. RFC 3280, IETF Network
Working Group, April 2002.
[ITU97] International Telecommunication Union. ITU-T recommendation
X.509 (1997 E): Information technology - open systems
interconnection - the directory: Authentication framework, June
1997.
[ITU02] International Telecommunication Union. ITU-T recommendation
X.690, information technology -- ASN.1 encoding rules:
Specification of basic encoding rules (BER), canonical encoding
rules (CER) and distinguished encoding rules (DER), July 2002. Also
appeared as ISO/IEC International Standard 8825-1.
[JB99] Stephen Kent and Randall Atkinson. Security architecture for
the Internet Protocol. RFC 2401, IETF Network Working Group,
November 1998.
[MC02] Gabriel Montenegro and Claude Castelluccia. Statistically
unique and cryptographically verifiable identifiers and addresses.
In Proc. ISOC Symposium on Network and Distributed System Security
(NDSS 2002), San Diego, February 2003.
[Mos01] Robert Moskowitz. Host identity payload and protocol.
Internet-Draft draft-ietf-moskowitz-hip-05.txt, October 2001. Work
in progress.
[ND01] Thomas Narten and Richard Draves. Privacy extensions for
stateless address autoconfiguration in IPv6. RFC 3041, IETF Network
Working Group, January 2001.
Aura Expires August 24, 2003 [Page 13]
INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2003
[NN98] Thomas Narten, Erik Nordmark, and William Allen Simpson.
Neighbor discovery for IP version 6 (IPv6). RFC 2461, IETF Network
Working Group, December 1998.
[Nik01] Pekka Nikander. A scaleable architecture for IPv6 address
ownership. Internet-draft, March 2001. Work in Progress.
[OR01] Greg O'Shea and Michael Roe. Child-proof authentication for
MIPv6 (CAM). ACM Computer Communications Review, 31(2), April 2001.
[TN98] Susan Thomson and Thomas Narten. IPv6 stateless address
autoconfiguration. RFC 2462, IETF Network Working Group, December
1998.
Authors' Addresses
Tuomas Aura
Microsoft Research
7 J J Thomson Avenue
Cambridge, CB3 0FB
United Kingdom
Phone: +44 1223 479708
Email: tuomaura@microsoft.com
Aura Expires August 24, 2003 [Page 14]