Minimum Requirement of IPv6 for Low Cost Network Appliance
Ver.3.12 2002-1-15
Non-PC Network Appliance Committee, INTAP
Abstract
With the increasing popularity of always-on networking, many non-P C nodes including sensors, home
appliances, and AV equipment are being connected to the Internet. Innumerable new IP addresses are
required to connect these devices and current networking standards are incapable of meeting these
needs. IPv6 is the only solution that provides enough addresses to connect all of the possible equipment.
Resource limitations and cost constraints associated with small-embedded devices make it difficult to
implement the entire IPv6 specification. We call such non-PC embedded devices "Low Cost Network
Appliances", and define the minimum IPv6 requirements for them. In this draft, we will also point out
several items to be discussed in future studies.
1. Target devices
Currently, several IPv6-capable commercial end equipments and protocol stacks, which target non-PC
embedded systems, have already been announced [1][2]. Also, the deployment of IPv6 for various
non-PC platforms is being evaluated [3]. There might be other configurations for IPv6 embedded devices,
which have different design policies, physical shapes, and restriction conditions for the implementation.
Though current PCs usually support more than 64MB of memory area, typical embedded devices have
only limited memory area and CPU performance as shown in Table 1. This causes severe technical
problems for implementing the entire IPv6/IPsec functionality. In case of consumer equipment such as
home appliances, the network functions have to be realized with the lowest cost. Therefore, in order to
provide compact implementations, we must limit the mandatory IPv6 specification.
In this draft, our target is non -PC embedded appliances called Low Cost Network Appliances (LCNA)
which meet the following requirements.
l
l
l
Devices that have no generic functionality, but are targeted at specific tasks.
A device that has network functionality, but has limited resources for networking.
A device that is a host, not a router.
Examples of LCNAs that might be available in the near future are consumer appliances such as
game-machines, AV devices, sensors, digital cameras, LCD projectors, and home appliances including
refrigerators and microwave ovens.
There was a comment that cellular phones are also a kind of LCNA. However, special cellular networks
and richer functionality set the cellular phones apart from our target (consumer) devices. Therefore, we
omit them from our target (see [4] for IPv6 specification of cellular hosts).
Considering the above, we will propose an IPv6/IPsec minimum requirement specification in this draft
based upon the following policy.
l This specification regulates the baseline for guaranteeing that IPv6 compliant LCNAs can
communicate with minimum safety. That is, if it complies with this spec, it is guaranteed that it
can communicate with another device securely if connected by IPv6.
l We do not assume equipment that has any specific usage models. We will summarize a minimum
requirement that is used on various LCNAs in common.
l There are functions that are necessary depending upon specific network topology, communication
content, and usage model such as mobility. For these functions, we will evaluate how generic the
function is, and if it is necessary it will be included into the minimum specification, and if not, we
will indicate that it is an optional function for a specific usage model.
Therefore, in order to adopt this specification to various implementations, it is necessary to classify the
usage style, communication mode, communication contents, network mobility, and actual usage model.
Then, select the optimal combination of items for each implementation.
1.1 Requirement Language
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as
described in [35].
2. Assumption for a minimum host
A minimum host MAY omit the functionality that is described as "out of scope" in this draft.
2.1 Hardware configuration
In this draft, the hardware configuration of a minimum host is as follows:
l A minimum host can provide enough functionality with only one network interface. If the minimum
host has multiple network interfaces, it must support more resources, see 3.3 for detail.
l
l
For Layer 2, we will assume Ethernet as typical shared media and PPP as typical point -to-point
media. Those are considered as minimum interfaces (RFC2467 [5], RFC2470 [6], RFC2497 [7]).
The media that is abstracted as Ethernet/PPP from IP layer is also targeted.
A minimum host can be invoked in stand-alone mode, which means booting via network is not
necessary (See 5.1).
2.2 Transition technology from IPv4
Transition from IPv4 is an important topic when deploying the minimum hosts, but we will omit it in
this draft. Therefore, we will only consider communications over pure IPv6 networks. For the long-term
perspective, the goal is to realize the interconnection with IPv4 networks, but it does not mean that the
operation of a minimum host relies on the existence of translators and/or NATs.
2.3 Multicast
Multicast is not addressed in this draft, and it is a candidate for further study (RFC 237 5[8], RFC
2710[9]). However, multicast related to neighbor discovery is only considered.
2.4 Anycast
A minimum host does not assign anycast addresses to its own interface (RFC 2526[10]). A minimum
host might use the anycast service in some cases, e.g. DNS ser ver discovery, but providing anycast
services MAY be omitted.
2.5 API
Socket API and IPSec API are implementation dependent. For example, the Socket API will b e
expanded in a vendor specific manner, or a Java API layer can hide them. Therefore, these APIs are out
of the scope of this draft.
2.6 Management functions
In this draft, the functions for managing LCNAs via the network are out of scope. This is very
important and has to be listed as a future study items (See 5.2).
2.7 Security
In Section 4 "IPsec minimum requirement", we will regulate a baseline for guaranteeing that a
minimum host can communicate securely. However, Denial of Service (DOS) and intrusion are out of
scope. So, we have to consider defending from DOS and/or intrusion in another place. Also, th e
authentication of users is out of scope, because some minimum hosts can omit a mechanism of user
accounts.
3. IPv6 minimum specification
In the following sections, we will explain minimum requirements according to each related RFC and
Internet Draft.
3.1 Internet Protocol, Version 6 (IPv6) Specification (RFC 2460[18])
As for extension headers, a minimum host only supports the minimum necessary functions. There are
no functions that a host needs to use current IPv6 extension headers, except for Mobile IPv6 functions
(abbreviated as MIP6) and IPsec. Therefore it is OPTIONAL for a minimum host to send packets with
IPv6 extension headers except ESP [19] (See 4.2 for detail of AH/ESP).
It is regulated that a minimum host does not send packets with extension headers. On the other hand,
when a minimum host receives packets with extension headers, it MUST perform minimum processing
specified in RFC2460 [18]. This is based on the principle "Be liberal in what you accept, and
conservative in what you send" as specified in RFC2360 [20]. The detail of the extension header
receiving process is as follows,
When the node receives unsupported extension headers, it MUST returns ICMP Parameter
Problem Message (Type= 4, Code=1) to the sender and discard them.
l When it can recognize the extension header but does not support the options in it, it MUST perform
error processing according to the option number.
Since it is assumed that the minimum host does not need extension header functions, it MAY omit order
check of extension headers. This is also based on RFC2360 [20] principles. Detailed processing for each
extension header is as follows:
l
3.1.1 Hop-by-Hop Options Header
[Sending]
Following 3.1, minimum hosts do not send packets with this extension header.
[Receiving]
A minimum host SHOULD recognize it as a Hop-by-Hop Options Header, and perform the processing
according to the option and option number in it. Because this option is used for signaling and router
alert, in order to control routers on the path, all nod es on transmission path have to interpret this
header but do not need to interpret all options in it.
3.1.2 Routing Header
[Sending]
Following 3.1, minimum hosts do not send packets with this extension header.
[Receiving]
RFC regulates that if the Segment Left field has non -zero value in this header, the node has to forward
the packet to the next intermediate node, even when the node is a host. But in the case of a minimum
host, this forwarding MAY be omitted and be treated as an unsupported extension header, because only
intermediate nodes (such as routers) and the destination node have to interpret this header.
<Optional>
One exception is when the minimum host supports the mobile node function of MIP6. As MIP6 uses a
Routing header, this header MUST be processed correctly. Another exception for sending this header is
when using route optimization for communicating with MIP6 mobility agents. If route optimization is
performed using binding update, the node MUST send packets with these extension headers. When
Binding Update is implemented, it is necessary to understand destination option header also.
3.1.3 Fragment Header
If a minimum host satisfies the following conditions, the host MAY not send this extension header, and
MAY treat one as an unsupported header when receiving it.
l For TCP,
Ø By limiting the max segment size (MSS) advertised by itself less than the value that the total
IP packet length becomes less than IPv6 minimum MTU, the fragmentation of TCP packet
from the correspondent is prevented.
Ø By replacing the MSS advertised by the correspondent to the value that the total IP packet
length becomes less than IPv6 minimum MTU, the minimum host limits the size of
transmitting TCP packets.
l
For UDP,
Ø The application that might receive IP packets with a size bigger than IPv6 minimum MTU
from the correspondent is not supported. A typical example of this application is NFS.
Ø The application that transmits UDP packets from its side has to do the tuning in order to limit
the IP packet length to less than IPv6 minimum MTU.
A minimum host SHOULD implement fragmenting/re-assembling functions if the above conditions are
not satisfied.
[Receiving]
When reassembling the fragmented packets, the host has to store the packets in memory then perform
the reassembly processing. This consumes large amounts of memory.
A designer may want to omit the reassembly processing of fragmented packets if the host system is
memory constrained. However, this might cause serious performance degradation in some cases.
In IPv6, minimum MTU is specified as 1280 bytes, and any packet smaller than that is not fragmented.
When communicating with TCP, if the advertised MSS is set smaller, the receiver side can control the
maximum size which can be used for sender's payload. By using this mechanism, we can reduce the
frequency of the fragmentation. For example, if MSS is advertised as 1000 bytes, no fragmentation
happen as long as the total size of IP header and extension headers does not exceed 280 bytes.
On the other hand, because UDP does not have a packet size control mechanism like TCP, the receiver
side has no way to force the sender to limit the packet size to less than the IPv6 minimum MTU.
Therefore, returning ICMPs and discarding packets might happen. There are several services that
might send UDP packets with a large payload size, such as DNS and NFS. In general, DNS payload is
less than 512 bytes. In case of EDNS0, the certificate information is appended and the packet size
might exceed IPv6 minimum MTU (1280 bytes). However, in this case, TCP can be used as a transport
protocol and the issue is avoided. Typical UDP payload size for NFS is kilobytes order. So if a minimum
host implements NFS service using UDP as transport protocol (not TCP), the reassemble of IP packets
is necessary.
[Sending]
For sending packets, if a minimum host limits the sending packet size to less than IPv6 minimum MTU
(1280 bytes), it will be delivered to final destination without any fragmentation. In this case, the
processing of fragment header is not necessary on sender side. Also the management of path MTU for
each destination can be omitted, which can reduce memory consumption. For TCP, by replacing the
received MSS to IPv6 minimum MTU, the minimum host can control the size of sending packets to less
than 1280 bytes. But in case of UDP, the packet size is determined in the application layer. So it is
necessary to have appropriate application tuning.
3.1.4 Destination Options Header
[Sending]
Following 3.1, minimum hosts do not send packets with this extension header.
[Receiving]
A minimum host SHOULD recognize this header as Destination Options Header and performs
processing according to the options and option numbers in it.
<Optional>
For sending, if the minimum host needs to communicate with mobility agents using the binding update
function of MIP6, it MUST interpret the extension header of received packets. The minimum host
MUST send packets with this extension header. Also, as stated in 3.1.2, the minimum host that can
interpret the binding update function MUST send packets with routing header.
3.1.5 No Next Header
This header is only interpreted but requires no action.
3.2 Path MTU Discovery for IP version 6 (RFC1981) [21]
An implementation that conforms to the conditions specified in "3.1.3 Fragment Header" can omit the
implementation of Path MTU Discovery, because it can guarantee that the TCP/UDP packets are sent
with a length less than the minimum MTU and packet fragmentation must not happen. Therefore, even
if it received ICMP Too Big Message, it can handle that as an error.
3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22]
Because of IPv6 minimum host definition, the following functions for routers can be omitted.
l Sending router advertise messages
l Receiving router solicitation messages
l Sending redirect messages
Receiving Redirect messages is a host function but the implementation MAY omit it. If a host has the
functionality, the host also SHOULD have the implementation of the destination cache.
As specified in RFC2461 [22], it is the same when Layer 2 is PPP.
In this draft, we assume that an LCNA has only one network Interface, but it does not inhibit multiple
interfaces. When an LCNA is assumed to have multiple interfaces, the following considerations are
necessary, which requires more resources.
l Source address selection
l Kinds of routing information (such as destination cache and routing table)
l Number of cache entries will increase
Ø ND cache
Ø Default router list
Ø Prefix list
3.4 IPv6 Stateless Address Autoconfiguration (RFC2462) [23]
Duplicated address detection (DAD) uses the neighbor discovery function. Neighbor discovery is
mandatory in IPv6. Therefore, DAD has almost no impact on resource usage, so all functions of DAD
SHOULD be implemented.
RFC2462 [23] does not mention anything about PPP, but everything SHOULD be implemented.
Because DAD is heavily dependent on neighbor discovery and neighbor discovery is mandatory for the
PPP case.
3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification (RFC2463) [24]
On minimum hosts, ICMP used only by a router MAY be omitted (Table 2). ICMPs for Echo
Request/Reply and minimum error reporting MUST be supported.
3.6 IP Version 6 Addressing Architecture (RFC2373) [25]
By default, minimum hosts MUST have the following three addresses.
Ø Loopback (::1)
Ø Node-local all nodes multicast (ff01::1)
Ø Link-local all nodes multicast (ff02::1)
If address autoconfiguration is performed, the following addresses MUST be supported.
Ø Link-local unicast（fe80/64＋ host ID ）
Ø
Ø
Solicited-node multicast corresponding to the above
Unicast（prefix/64＋ host ID）corresponding to the prefix option of router advertise message
Ø Solicited-node multicast corresponding to the above
If manual configuration is performed, the following addresses MUST be supported.
Ø Arbitrary unicast
Ø Solicited-node multicast corresponding to the above
3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6 Stateless DNS
Discovery (draft-ietf-ipngwg -dns-discovery-02.txt) [27]
The only function that is not supported in the current IPv6 autoconfiguration is automatic discovery of
DNS server. On this topic discussions are ongoing in IETF IPNG WG. If a standard is fixed, it might
become a mandatory item for minimum hosts. AAAA record is defined for transform from IPv6 name to
IPv6 address. So, AAAA is currently mandatory for minimum host name resolution. Also, A6 record is
currently proposed and discussed in IETF for an alternative of AAAA record. We need to check the
progress.
If a minimum host is a passive node, it will not become an initiator of the communication. This means
that automatic discovery of the DNS server and name resolution MAY be omitted (the implementation
of resolver can be omitted on a passive node). On the other hand, if a minimum host is an active node,
DNS name resolving is necessary. In such cases, automatic DNS server discovery SHOULD be
implemented.
4. IPSEC minimum requirement
Considering the restriction of resources on minimum hosts, we have regulated a subset of IPsec
specified in RFC2401 [28] as follows, which is called "minimum security specification".
4.1 Consideration of security for LCNAs
We believe that IPsec is an effective technology in order to guarantee security of communication. That is
the reason why we regulate the minimum IPsec specification in this draft. However, we have to consider
whether this regulation works well in actual implementations of various appliances.
Currently, there are several issues that prevent realizing security even if IPsec minimum specification
is implemented. The first issue is the network environment. In order to deploy minimum hosts on
current network environments, we cannot neglect existing IPv4 networks. Therefore, w e h a v e t o
assume NAT or IPv4/IPv6 translators between the minimum host and the correspondent host. Current
IPsec cannot handle such a situation, which means the effectiveness of the security mechanism relying
upon IPsec is very limited.
Another issue is the cost -performance of minimum hosts. There might be a class of appliances that
cannot perform IPsec processing due to its resource constraints. Enhancing the performance increases
the cost of the appliance, so that decision may be very severe from a business perspective. If IPsec does
not work as a generic security solution, the cost increase caused by implementing IPsec on the
appliance might not be acceptable.
When using 8 bit CISC CPU, for example, the encryption processing is too heavy no matter whether it
is symmetric key encryption or asymmetric key encryption. We have experienced it taking about 30
seconds for SSL handshake when the SSL web server is operated on an 8-bit CPU. This might be a
typical number for the load of asymmetric key processing and might also be a reference of usability. The
load for symmetric key encryption is not negligible either. On the same system, when we turned on UDP
checksum, the throughput of a packet degraded about 1 millisecond. The tick time of the OS on this
system is 2 milliseconds, so UDP checksum calculation consumes about 50 % of the tick time. This
result implies that the symmetric key encryption processing inside the OS is very difficult without any
hardware support.
Considering the above two issues, there are two different approaches for treating IPsec minimum
specification of LCNAs.
l Because IPsec minimum specification is very important for expanding the application of the future
Internet, we have to regulate minimum IPsec as mandatory and should make effort to realize even
if it is hard to deploy. Therefore, it is CORRECT to regulate IPsec minimum specification as
mandatory.
l Even though we regulate minimum IPsec as mandatory, no one uses that because there are no
prospects to deploy it in the real world. Therefore, it is WRONG to regulate the IPsec minimum
specification as mandatory.
When IPv6 is widely used on the Internet, LCNAs will become numerous. Therefore, if we do not
regulate the framework of LCNA's security, there might be much adhoc security implementations for
LCNAs. This would cause an obstacle for the end-to-end communication principle of IPv6. However, we
will not consider this problem in detail in this draft. Therefore, it is very important for the future of the
Internet to make a consensus on this discussion.
4.2 IPsec specification
RFC2401 [28] assumes many communication modes. However, in this draft, we will focus on only the
communication between minimum hosts using IPv6 transport mode. Communication using a security
gateway is out of scope. IPSec for multicast is also out of scope because the discussion of multicast key
exchange has just begun in IETF. Anycast is out of scope because detail is not fixed yet. There are
several proposals for IPSec MIB and IPSec specific ICMP but they are not standardized yet, so they too
are out of scope.
For the security protocol, ESP [19] MUST be implemented. If the encryption of payload is NOT needed
(but the authentication is necessary), the NULL algorithm can be used. Authentication data MUST be
implemented and padding MUST be sequential. Because the usage of IPv6 extension headers is limited
in section 3, authentication header (AH[29]) MAY be omitted from the minimum-security specification.
For the encryption algorithm, AES with 128 bit key length MUST be implemented. CBC [30] MUST be
supported for IV mode. For the authentication algorithm, HMAC-SHA2-256 MUST be implemented.
Other algorithms MAY be implementation-dependent.
RFC2401[28] specifies mandatory SA parameters that must be implemented. However, the items that
are dependent on the specifications which are regulated as unnessesary in this draft MAY be omitted.
For example, because only the transport mode is supported in this draft, the management of IPsec mode
MAY be omitted. If automatic key exchange is not implemented, the parameters for key lifetime MAY
also be omitted. When automatic key exchange is implemented, key lifetime has to be included as an SA
parameter. The specification of key lifetime with transmitted byte count is ambiguous and SHOULD
NOT be implemented.
4.3 How to setup secure communication path
In order to setup a secure communication path by IPsec, the following procedure is necessary:
1.
2.
3.
Two nodes that communicate through IPsec authenticate to each other.
Security association (SA) is setup by exchanging SA parameters in a secure manner negotiated by
the two nodes.
Communication is performed using the setup SA.
We call step 1 and 2 "Key exchange". In current IPsec specification, two types of key exchange are
defined as follows:
(a) Automatic Key Exchange
Key exchange modules exchange SA parameters automatically without any manual operations. The
renewal of the old SA is also done by the same sequence automatically.
(b) Manual Key Exchange
The administrators of hosts exchange SA parameters by some methods, and SAs are setup by some
means (such as commands). The renewal of old SAs is done by the administrator using the same
methods.
4.4 Key exchange specification
The minimum security specification regulates that manual key exchange MUST be implemented.
PKI[31] might be a technique used for automatic mutual authentication, but it will heavily affect the
LCNAs' performance. Also, there are no standards for using PKI[31] from IPsec. Therefore, we will not
regulate automatic key exchange as mandatory (SHOULD be implemented).
IKE[32] is specified as a key exchange algorithm for automatic key exchange. However IKE is designed
for generic purposes and is not suitable for low-power minimum hosts. Also, the description of exception
handling is ambiguous, which makes interoperability of IKE implementations a serious problem. Also,
it has been pointed out that IKE is vulnerable to DOS attacks [33].
Considering these situations, currently more lightweight algorithms are being discussed in IETF. These
algorithms are expected to be suitable for minimum hosts. Also in some cases, a key distribution center
(KDC) model might be applicable for them.
5. Open Issues
In this section, we will summarize items to be considered in future study.
5.1 How to promote IPsec minimum specification
First, as mentioned in 4.1, there is an issue whether the IPsec minimum specification will be used for
all LCNA implementations that have severe resource restrictions. In order to resolve this issue, we have
to perform a promotion such as interoperability events or make a reference implementation open to the
public. Part of these activities are currently implemented by the TAHI group in the WIDE project.
5.2 Network-boot devices
The function for booting from network with tftp or else is out of scope in this draft. This boot code works
in a very limited ROM area, and might need a specially limited specification. Generally such devices are
designed for a special purpose and might need another implementation guideline.
5.3 Management facilities for LCNAs
When LCNAs are commonly used, there are many LCNAs on the home network. In such cases, the
following management facilities will be usable.
l SNMP (RFC2452[11],RFC2454[12],RFC2465[13],RFC2466[14],draft-ietf-ipsec-doi-tc-mib-04.txt[15],
draft-ietf-ipsec-monitor-mib-04.txt[16])
l ICMP name lookup [17]
l Vendor-specific management functions (such as Web-based tools)
In order to define the management functions suitable for LCNAs, we have to define and analyze the
requirements for LCNA management first. For example, traffic measurement, which is useful for router
management, may not be necessary on LCNAs.
5.4 Is SA parameter setup capability mandatory ?
On current IPsec, it is mandated that users can setup SA parameters by some process. However, in the
case of a very low-cost (one-time used) minimum host, SA parameters might be hard-coded and users do
not need to perform setup. We need to consider whether this SA parameter setup capability is
mandatory in LCNAs.
6. Security Consideration
RFC3041 [34] proposes the enhancement of privacy by randomizing the interface-ID part of the IPv6
addresses. If this facility is necessary, the manual key exchange mandated in this draft cannot be used
as is, and we need to consider alternatives (such as automatic key exchange).
As mentioned in 2.7, DOS and intrusion are out of the scope in this draft.
In this draft, only manual key exchange is mandated for LCNAs. However, in some classes of appliances,
the IPsec parameters setup at shipping time might be used until the appliance is disposed. In such
cases, if the lifetime of the appliance is long, we have to evaluate whether the SA algorithm and
key-length setup initially are strong enough considering all the packet counts sent/received. This
evaluation is not done in detail. There is a method where the IPsec parameters are refreshed at a fixed
interval, but this is also dependent on the node API, and it is not covered in this draft.
In this draft, the IPsec API is implementation dependent and must not have any security holes. For
issues with this type of implementation, please refer to RFC2401[28] "2.2 Caveats and Assumptions".
7. Contact information
Please contact to tiny@tahi.org for the questions/comments to this document.
◆Reference
[1] InternetNode Inc. http://www.i-node.co.jp/
[2] ACCESS CO., LTD. http://www.access.co.jp/
[3] IPv6 Promotion Council, Application Working Group, http://www.v6pc.jp/apwg.html
[4] Minimum IPv6 Functionality for a Cellular Host(draft-manyfolks-ipv6-cellular-host-01.txt)
[5] Transmission of IPv6 Packets over FDDI Networks (RFC2467)
[6] Transmission of IPv6 Packets over Token Ring Networks (RFC2470)
[7] Transmission of IPv6 Packets over ARCnet Networks (RFC2497)
[8] IPv6 Multicast Address Assignments (RFC2375)
[9] Multicast Listener Discovery (MLD) for IPv6 (RFC2710)
[10] Reserved IPv6 Subnet Anycast Addresses (RFC2526)
[11] IP Version 6 Management Information Base for the Transmission Control Protocol (RFC2452)
[12] IP Version 6 Management Information Base for the User Datagram Protocol (RFC2454)
[13] Management Information Base for IP Version 6: Textual Conventions and General Group
(RFC2465)
[14] Management Information Base for IP Version 6: ICMPv6 Group (RFC2466)
[15] IPsec DOI Textual Conventions MIB (draft-ietf-ipsec -doi-tc-mib-04.txt)
[16] IPsec Monitoring MIB (draft-ietf-ipsec -monitor -mib-04.txt)
[17] IPv6 Node Information Queries (draft-ietf-ipngwg-icmp-name-lookups-08)
[18] Internet Protocol, Version 6 (IPv6) Specification (RFC 2460)
[19] IP Encapsulating Security Payload (RFC2406)
[20] Guide for Internet Standards Writers (RFC2360)
[21] Path MTU Discovery for IP version 6 (RFC 1981)
[22] Neighbor Discovery for IP Version 6 (IPv6) (RFC 2461)
[23] IPv6 Stateless Address Autoconfiguration (RFC 2462)
[24] Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
(RFC 2463)
[25] IP Version 6 Addressing Architecture (RFC 2373)
[26] DNS Extensions to support IP version 6 (RFC 1886)
[27] IPv6 Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt)
[28] Security Architecture for the Internet Protocol (RFC2401)
[29] IP Authentication Header (RFC2402)
[30] The AES Cipher Algorithm and Its Use With IPsec (draft-ietf-ipsec-ciph -aes-cbc-01.txt)
[31] Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC2459)
[32] The Internet Key Exchange (RFC2409)
[33] Code-preserving Simplifications and Improvements to IKE (draft-ietf-ipsec -improveike-00.txt)
[34] Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (RFC3041)
[35] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.