SERVICES & APPLICATIONS

ISSUE: 25TH
MARCH 2011

Standards for IPv6 Conformance and Interoperability

No. SD/IPv6-001/01/MAR.2011

TEC TELECOMMUNICATION ENGINEERING CENTRE KHURSHID LAL BHAWAN, JANPATH NEW Delhi 110 001 INDIA
All Rights Reserved and no part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise without written permission from the Telecommunication Engineering Center, New Delhi
1

Standards for IPv6 Conformance and Interoperability

History Sheet

Sl No. 1.

Title Standards Conformance Interoperability for

GR No. IPv6 No. SD/IPv6-001/01/MAR.2011 and

Remarks Issue 01

Standards For IPv6 Conformance and Interoperability No. SD/IPv6-001/01/MAR.2011

CONTENTS

Chapter 1. 2. 3. 4. 5. 6. 7.

Contents Introduction and Scope Functional Requirements

Additional specifications for specific protocols for Conformance and Interoperability

Page No. 5 9 16 62 72 74 76

IETF RFC summary for IPv6 Abbreviations Glossary References

Chapter-1

Introduction and Scope

CHAPTER-1 Introduction and Scope

1. Introduction
Internet Protocol version 6 (IPv6) is the new version of the Internet Protocol, designed as the successor to IP version 4 (IPv4). The changes from IPv4 to IPv6 primarily fall into the following categories. Expanded Addressing Abilities IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes and simpler autoauto configuration of the addresses. Header Format Simplification Some IPv4 header fields have been dropped or made optional to reduce the common have commoncase processing cost of packet handling and to limit the bandwidth cost of the IPv6 header. Improved support for Extensions and options Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. Flow labeling capability A new capability is added to enable the labeling of packets belonging to particular traffic flows for which the sender requests special handling, such as non-default flows non quality of service or real-time service. real Authentication and privacy capabilities Extensions to support authentication, data integrity and data confidentiality are specified for IPv6.

a)

b)

c)

d)

e)

2. IPv4 and IPv6 Addresses

3. IPv6 Packets An IPv6 packet is the smallest message entity exchanged via the Internet Protocol across an Internet Protocol version 6 (IPv6) network. Packets consist of control information for addressing and routing, and a payload consisting of user data. The control information in IPv6 packets is subdivided into a mandatory fixed header and optional extension headers. The payload of an IPv6 packet is typically a datagram or segment of the higher-level Transport Layer protocol, but may be data for an Internet Layer (e.g., ICMPv6) or Link Layer (e.g., OSPF) instead. IPv6 packets are typically transmitted over a Link Layer protocol, such as Ethernet which encapsulates each packet in a frame, but this may also be a higher layer tunneling protocol, such as IPv4 when using 6to4 or Teredo transition technologies. Routers do not fragment IPv6 packets, as they do for IPv4. Hosts are required to implement path MTU discovery to take advantage of MTUs greater than the smallest MTU of 1280 octets. Hosts may use fragmentation to send packets larger than the observed path MTU. 4. IPv4 & IPv6 Headers
4.1 Header Comparison - The comparison of headers in IPv4 and IPv6 is given below.

4.2

Fixed Header

IPv4 has a variable header but in IPv6 the main header is fixed size of 40 bytes (320 bits). All other information is carried through extension headers. IPv6 packet headers contain many of the fields found in IPv4 packet headers; some of these fields differ from IPv4. The 40-byte IPv6 header consists of the following eight fields:
(i)

Version (4) - Indicates the version of the Internet Protocol.

Traffic class (8) - Previously the type-of-service (ToS) field in IPv4, the traffic class field defines the class-of-service (CoS) priority of the packet. However, the semantics for this field (for example, diffserv code points) are identical to IPv4. (iii) Flow label (20) - The flow label identifies all packets belonging to a specific flow (that is, packet flows requiring a specific class of service [CoS]); routers can identify these packets and handle them in a similar fashion. (iv) Payload length (16) - Previously the total length field in IPv4, the payload length field specifies the length of the IPv6 payload. (v) Next header (8) - Previously the protocol field in IPv4, the Next Header field indicates the next extension header to examine. (vi) Hop limit (8) - Previously the time-to-live (TTL) field in IPv4, the hop limit indicates the maximum number of hops allowed. (vii) Source address (128) - Identifies the address of the source node sending the packet. (viii) Destination address (128) - Identifies the final destination node address for the packet.
(ii)

4.3

Extension Headers In IPv6, extension headers are used to encode optional Internet-layer information. Extension headers are placed between the IPv6 header and the upper-layer header in a packet. IPv6 allows you to chain extension headers together by using the next header field. The next header field, located in the IPv6 header, indicates to the router which extension header to expect next. If there are no more extension headers, the next header field indicates the upper-layer header (TCP header, UDP header, ICMPv6 header, an encapsulated IP packet, or other items).

5. Scope of the Document

a. The document specifies the standards requirements of networking equipments for their IPv6 conformance and interoperability with other similar networking equipments running the IPv6 protocol in a network. b. Due to the universality of IPv6 and the fact that some parts of the specifications are still in a grey area as these have not been adequately addressed by the Internet Engineering Task Force (IETF), a large number of implementations are possible due to variations in interpretation. Therefore, interoperability will be a critical feature of IPv6 based networking equipments. c. This document is primarily based on the requirements specified by the IPv6 Forum, and in particular the IPv6 Ready Logo Programme for Phase-I and Phase-II for IPv6 conformance and Interoperability of networking equipments. Additional requirements based on Indian conditions have also been incorporated to some extent. d. Government agencies, network providers and organizations are expected to procure and deploy IPv6 ready equipments based on these minimum specifications and amendments released from time to time. e. This document does not give details on transition strategies for moving from IPv4 based networks to IPv6 based networks. These are covered in specific IETF RFCs not within the scope of this document. These IETF specifications are given below which address issues in specific deployment and transition scenarios for Enterprise and ISPs. 7

i. Enterprise Networks: [RFC4057] IPv6 Enterprise Network Scenarios [RFC4852] IPv6 Enterprise Network Analysis - IP Layer 3 Focus [RFC3750] Unmanaged Networks IPv6 Transition Scenarios [RFC3904] Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks

ii. ISPs and Transit Network Infrastructure: [RFC4029] Scenarios and Analysis for Introducing IPv6 into ISP Networks [RFC2185] Routing Aspects of IPv6 Transition iii. Interoperation with IPv4 Infrastructure: [RFC4038] Application Aspects of IPv6 Transition [RFC4213] Basic Transition Mechanisms for IPv6 Hosts and Routers iv. Security Issues: [RFC4942] IPv6 Transition/Co-existence Security Considerations [RFC4864] Local Network Protection for IPv6

Chapter-2

Functional Requirements

Chapter No.

Title

2.A 2.B

Core Protocols for IPv6 Conformance Core Protocols for IPv6 Interoperability

CHAPTER-2.A Core Protocols for IPv6 Conformance

1.0

Common Topology for Core Conformance Testing

2.0

Relevant References
[ADDRCONF] [DS-FIELD] [ECN] [ICMPv6] [IPv6-ARCH] [IPv6-SPEC] [ND] [PMTU] [RFC-5095] IPv6 Stateless Address Autoconfiguration, RFC 4862, September 2007. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998. The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168, September 2001. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 4443, March 2006. Internet Protocol, Version 6 Addressing Architecture, RFC 4291, February 2006. Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998. Neighbor Discovery for IP Version 6 (IPv6), RFC 4861, September 2007. Path MTU Discovery for IPv6, RFC 1981, August 1996. Deprecation of Type 0 Routing Headers in IPv6, RFC 5095, December 2007

10

3.0

Core Protocols for IPv6 Conformance (RFC2460)

The base specification specifies the basic IPv6 header and the initially defined IPv6 extension headers and options. It also discusses packet size issues, the semantics of flow labels and traffic classes, and the effects of IPv6 on upper-layer protocols. These are the essential requirements specified under IPv6 Ready Logo Programme Phase-I of the IPv6 Forum.
(i)

IPv6 Header Verify that a node properly processes and generates the Version, Traffic Class, Flow Label, Payload Length, Next Header, and Hop Limit fields in the IPv6 header. Verify that a node transmits the appropriate ICMPv6 Parameter Problem messages in response to invalid or unknown fields. Extension Headers and Options
The descriptions cover the processing of options and extension headers, particularly the Hop-by-Hop Options, Destination Options, and Routing headers. A node should properly process and generate the Header Extension Length field in extension headers, and the Option Type and Option Data Length fields in IPv6 options. The node should also correctly process header options in order, packets with a routing header destined for the node, and many extension headers or options in a single packet. In addition, a node should generate the proper ICMPv6 message in response to invalid or unknown fields.

(ii)

(iii)

Fragmentation

IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octetpacket in one piece, linkspecific fragmentation and reassembly must be provided at a layer below IPv6. The node should properly time out fragment reassembly, abandon reassembly on packets that exceed a maximum size, process stub fragments, and reassemble overlapping fragments. The node should also generate the proper ICMPv6 messages.

4.0

Core Protocols for IPv6 Conformance (RFC4861)

RFC4861 cover the Neighbor Discovery Specification for Internet Protocol version 6. The Neighbor Discovery protocol is used by nodes to determine the link-layer address for neighbors known to reside on attached links as well as to quickly purge cached values that become invalid. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf. Finally, nodes use the protocol to actively keep track of neighbors that are reachable and those that are not. When a router or the path to a router fails, a host actively searches for functioning alternates. These descriptions will verify the readiness of an IPv6 implementation vis--vis the Neighbor Discovery specification. The following are described in RFC 4861

11

(i) (ii) (iii)

Router and Prefix Discovery Address Resolution and Neighbor Unreachability Detection Redirect Function

5.0

Core Protocols for IPv6 Conformance (RFC4862)

The following descriptions cover the IPv6 Stateless Address Autoconfiguration specification. These descriptions gives details on the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The following also verify that a host correctly processes a Router Advertisement and correctly assigns lifetimes. The following are described in RFC 4862. (i) (ii) Address Autoconfiguration and Duplicate Address Detection Router Advertisement Processing and Address Lifetime

6.0

Core Protocols for IPv6 Conformance (RFC1981)

The descriptions cover the Path MTU Discovery for IP version 6. The Path MTU Discovery protocol is a technique to dynamically discover the PMTU of a path. The basic idea is that a source node initially assumes that the PMTU of a path is the (known) MTU is the first hop in the path. If any of the packets sent on the path are too large to be forwarded by some node along the path, that node will discard them and return ICMPv6 Packet Too Big messages. Upon receipt of such a message, the source node reduces its assumed PMTU for the path based on the MTU of the constricting hop as reported in the Packet Too Big message. The Path MTU Discovery process ends when the nodess estimate of the PMTU is less than or equal to the actual PMTU.

7.0

Core Protocols for IPv6 Conformance (RFC4443)

It describes the format of a set of control messages used in ICMPv6. It does not describe the procedures for using these messages to achieve functions like Path MTU discovery; these procedures are described in other documents.

12

CHAPTER-2.B (Core Protocols for IPv6 Interoperability)

1.0

IPv6 Interoperability Specification

Contrary to IPv4, which started with a small closed group of implementers, the universality of IPv6 leads to a huge number of implementations. Interoperability has always been considered as a critical feature in the Internet community. Due to the large number of IPv6 implementations, it is important to provide the market a strong signal proving the level of interoperability across various products. The following specifications give the essential requirements for interoperability of diverse IPv6 products with each other.

2.0

General Node Requirements

Host

o Ability to configure a global address and default router by receipt of Router Advertisement. o If the device is a Special Device and it does not support configuring the automatically, the device must have the ability to assign an address on the attached interface manually. o If the device is a Special Device and it does not support setting the default router automatically, the device must have the ability to set the Reference Routers address as default router manually. Router
o Ability to transmit Router Advertisements with a positive AdvValidLifetime. o Ability to transmit Router Advertisements with a positive AdvDefaultLifetime.

Host and Router

o Ability to use a ping6 application and print out results indicating the receipt of an ICMPv6 Echo Reply. o Ability to show multicast ping result indicating the receipt of each ICMPv6 Echo Reply.

3.0 Relevant References

[ADDRCONF] [ICMPv6] IPv6 Stateless Address Autoconfiguration, RFC 4862 September 2007. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 4443, March 2006. Internet Protocol, Version 6 Addressing Architecture, RFC 4291, February 2006.

[IPv6-ARCH]

13

[IPv6-SPEC]

Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998.

[ND] [PMTU]

Neighbor Discovery for IP Version 6 (IPv6), RFC 4861, September 2007. Path MTU Discovery for IPv6, RFC 1981, August 1996.

[RFC-5095]

Deprecation of Type 0 Routing Headers in IPv6, RFC 5095, December 2007 Multicast Listener Discovery (MLD) for IPv6, RFC 2710, October 1999. TCP Extensions for Transactions Functional Specification, RFC 1644, July 1994. File Transfer Protocol (FTP), RFC 959, October 1985. TELNET Protocol Specification, RFC 854, May 1983. TFTP Protocol (Revision 2), RFC 1350, July 1992 Hypertext Transfer Protocol HTTP/1.1, June 1999.

[MLD] [T/TCP] [FTP] [TELNET] [TFTP] [HTTP]

4.0

IPv6 Core Protocol and ICMPv6 Interoperability

(i) ICMPv6 Echo Interoperability - To verify that a successful ICMPv6 Echo Request, Every node must Echo Reply exchange can be achieved in two directions. implement an ICMPv6 Echo responder function that receives Echo Requests and sends corresponding Echo Replies. A node should also implement an applicationlayer interface for sending Echo Requests and receiving Echo Replies, for diagnostic purposes. The source address of an Echo Reply sent in response to a unicast Echo Request message must be the same as the destination address of that Echo Request message. An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast address. The source address of the reply MUST be a unicast address belonging to the interface on which the multicast Echo Request message was received. Address Autoconfiguration and Duplicate Address Detection - To verify that a device can properly initialize on a network and communicate with other on- link partners. When a host initializes on a given link, it performs stateless address autoconfiguration and Duplicate Address Detection. To ensure that all configured addresses are likely to be unique on a given link, hosts run the Duplicate Address Detection algorithm on addresses before assigning them to an interface. The Duplicate Address Detection algorithm is performed on all addresses, independent of whether they are obtained via stateless or stateful autoconfiguration. In addition, routers perform Duplicate Address Detection on all addresses prior to assigning them to an interface. A tentative address that is determined to be a 14

(ii)

duplicate as described above, MUST NOT be assigned to an interface and the node SHOULD log a system management error. If the address is a link- local address formed from an interface identifier, the interface SHOULD be disabled. (iii) Processing Router Advertisments- Prefix Discovery: To verify that a device can properly perform prefix discovery. Processing Router Advertisements- Router Lifetime: To verify that a device can properly perform Router Discovery. Redirect Function (Host vs Router) - Verify the correct interoperability between a devices redirect handling with that of various IPv6 implementations. Routers send redirect packets to inform a host of a better first-hop node on the path to a destination. Hosts can be redirected to a better first-hop router, but can also be informed by a redirect that the destination is in fact a neighbor. The latter is accomplished by having the ICMPv6 Target Address be equal to the ICMPv6 Destination Address in the redirect message. Path MTU Discovery and Fragmentation - Verify that devices can participate in path MTU discovery and handle fragmentation in an IPv6 network. IPv6 nodes should implement Path MTU Discovery in order to discover and take advantage of paths with PMTU greater than the IPv6 minimum link MTU. A source node initially assumes that the PMTU of a path is the (known) MTU of the first hop in the path. If any of the packets sent on that path are too large to be forwarded by some node along the path, that node will discard them and return ICMPv6 Packet Too Big messages. Upon receipt of such a message, the source node reduces its assumed PMTU for the path based on the MTU of the constricting hop as reported in the Packet Too Big message.

(iv)

(v)

(vi)

15

Chapter-3 Additional Specifications for Specific Protocols for Conformance and Interoperability
Chapter Title

3.A 3.B 3.C 3.D 3.E 3.F 3.G 3.H 3.I 3.J 3.K 3.L 3.M 3.N 3.O 3.P 3.Q 3.R 3.S 3.T 3.U 3.V 3.W

DHCPv6 Conformance Specifications DHCPv6 Interoperability Specifications IPsec (Internet Protocol Security) IPsec Interoperability Specifications IKEv2 Conformance IKEv2 Interoperability MIPv6 Self Test Specifications for CN MIPv6 Self Test Specifications for HA MIPv6 Interoperability Test Specifications MIPv6 Conformance MN Specifications MLDv2 Conformance Specifications MLDv2 Interoperability Specifications SNMP / MIB Conformance Specifications SNMP / MIB Conformance Specifications Session Initiation Protocol (SIP) Proxy Server Conformance Specifications Session Initiation Protocol (SIP) Registrar Server Conformance Specifications Session Initiation protocol (SIP) User Agent (UA), Endpoint (EP), Back to Back User Agent (B2BUA) Conformance Specifications Session Initiation Protocol (SIP) Interoperability Specifications IP Multimedia Subsystem User Equipment (IMS-UE) Conformance Specifications IP Multimedia Subsystem InteroperabilitySpecifications User Equipment (IMS-UE)

Network Mobility (NEMO) Home Agent (HA) Self Test Conformance Specifications Network Mobility (NEMO) Mobile Router (MR) Conformance Specifications Network Mobility (NEMO) Interoperability Specifications

16

CHAPTER-3.A DHCPv6 Conformance Specifications

1. Introduction
(i) The Dynamic Host Configuration Protocol (DHCP) is an auto configuration protocol used on IP networks. Computers that are connected to IP networks must be configured before they can communicate with other computers on the network. DHCP allows a computer to be configured automatically, eliminating the need for intervention by a network administrator. It also provides a central database for keeping track of computers that have been connected to the network. This prevents two computers from accidentally being configured with the same IP address. In the absence of DHCP, hosts may be manually configured with an IP address. Alternatively IPv6 hosts may use stateless address autoconfiguration to generate an IP address. IPv4 hosts may use linklocal addressing to achieve limited local connectivity. In addition to IP addresses, DHCP also provides other configuration information, particularly the IP addresses of local caching DNS resolvers. Hosts that do not use DHCP for address configuration may still use it to obtain other configuration information. There are two versions of DHCP, one for IPv4 and one for IPv6. While both versions bear the same name and perform much the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they can be considered separate protocols.
There are three possibilities for equipment types using DHCPv6: a) DHCP client (or client): A node that initiates requests on a link to obtain configuration parameters from one or more DHCP servers. b) DHCP server (or server): A node that responds to requests from clients, and may or may not be on the same link as the client(s).

(ii)

c) DHCP relay agent (or relay agent): A node that acts as an intermediary to deliver DHCP messages between clients and servers, and is on the same link as the client.

This conformance specification consists mainly of four ADVANCED functions. The following tests will tell if the NUT supports the ADVANCED functions.
17

a) Adv1- Address assignment for Client device, Server device, Relay agent device b) Adv2- DNS configuration in parallel with Address Assignment for Client device, for Server device, for Relay agent device c) Adv3- Stateless DHCPv6 for DNS configuration for Client device, for Server device, for Relay agent device d) Adv4- Prefix Delegation for Requesting router (Client) device, for Delegating router (Server) device e) Adv5- DNS configuration in parallel with Prefix Delegation for Requesting router (Client) device, for Delegating router (Server) device.
Advanced Functionality Tests Adv-1 Adv-2 Adv-3 Adv-4 Adv-5 References RFC3315 RFC3315+RFC3646 RFC3736 RFC3633 RFC3633+RFC3646

2. RFC 3315 - Client Specification

It covers the specifications for the client implementation of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The scope of the tests includes major functionality groups such as client behavior in client-initiated configuration exchange, client behavior in server-initiated configuration exchange, client behavior in server solicitation, and message validation by client.
2.1. Client Basic Behaviors, Constants and Format The tests focus on the DHCP Basic behaviors, constants and format. The messages that are sent by the client will locate servers that will assign the IPv6 addresses and/or additional configuration information pertaining to client IAs. 2.2. Client Message Transmission The tests focus on the Client message creation, transmission and termination of DHCP IPv6 exchanges. The messages that are sent by the client will locate servers that will assign the IPv6 addresses and/or additional configuration information pertaining to client IAs. 2.3. Client Message Reception The tests focus on the clients implementation of DHCPv6 and the reception of valid and invalid DHCPv6 messages by a server device.

3. RFC 3315 - Server Specification

It covers specifications for the server implementation of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The scope of the tests includes major functionality groups such as server behavior in client-initiated configuration exchange, server behavior in s e r v e r initiated configuration exchange and m e s s a g e validation by server. 3.1. Server Basic Behaviors, Constants and Format Focus on the DHCP Basic Behaviors, constants and format. The messages that are sent by the client will locate servers that will assign the IPv6 addresses and/or additional configuration information pertaining to client IAs. 3.2. Server Message Transmission
18

Focus on the Server message creation, transmission and termination of DHCP IPv6 exchanges. 3.3. Server Message Reception Focus on the servers implementation of DHCPv6 and the reception of valid and invalid DHCPv6 messages by a client device.

4. RFC 3315 - Relay Agent Specification

It covers specifications for the relay agent implementation of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These tests verify the process for relaying specific messages regarding Address Assignment. These tests verify the readiness of a DHCPv6 Relay agent implementation vis--vis base specifications of the Dynamic Host Configuration Protocol for IPv6.

5. RFC 3646 - Client Specification

It covers specifications for the client implementation of the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These tests verify the process for receiving a list of available DNS recursive name servers and a domain search list from a server in parallel with Address Assignment. They verify the readiness of a DHCPv6 client implementation vis--vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification.

6. RFC 3646 - Server Specification

It covers specifications for the sever implementation of the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The tests verify the process for passing a list of available DNS recursive name servers and a domain search list to a client in verify the readiness of a DHCPv6 server parallel with Address Assignment. They implementation vis--vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification (Other configuration information function concurrently processing Address Assignment).

7. RFC 3646 - Relay Agent Specification

It covers specifications for the relay agent implementation of the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The tests verify the process for relaying specific messages regarding a list of available DNS recursive name servers and a domain search list from a server in parallel with Address Assignment. They verify the readiness of a DHCPv6 relay agent implementation vis--vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification (Other configuration information function concurrently processing Address Assignment).

8. RFC 3736 - Client Specification

It covers specifications for the client implementation of the Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The tests verify the process for receiving a list of available DNS recursive name servers and a domain search list from a server in Stateless Dynamic Host Configuration Protocol for IPv6. They verify the readiness of a DHCPv6 client implementation vis--vis the Stateless Dynamic Host Configuration Protocol for IPv6 specification (Focus on DNS recursive name servers and Domain search list option).
19

9. RFC 3736 - Server Specification

It covers specifications for the server implementation of the Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). They verify the process for receiving a list of available DNS recursive name servers and a domain search list from a server in Stateless Dynamic Host Configuration Protocol for IPv6. The tests are designed to verify the readiness of a DHCPv6 server implementation vis--vis the Stateless Dynamic Host Configuration Protocol for IPv6 specification (Focus on DNS recursive name servers and Domain search list option).

10. RFC 3736 - Relay Agent Specification

It covers specifications for the Relay agent implementation of the Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The tests verify the process for receiving a list of available DNS recursive name servers and a domain search list from a server in Stateless Dynamic Host Configuration Protocol for IPv6. They verify the readiness of a DHCPv6 relay agent implementation vis--vis the Stateless Dynamic Host Configuration Protocol for IPv6 specification (Focus on DNS recursive name servers and Domain search list option).

11. RFC 3633 Requesting Router (Client) Specification

It covers specifications for the requesting router (Client) implementation of IPv6 Prefix options for Dynamic Host Configuration Protocol (DHCP) version 6. The tests verify the process for receiving a list of available IPv6 Prefix options from a server in Dynamic Host Configuration Protocol for IPv6. They verify the readiness of a DHCPv6 requesting router (Client) implementation vis--vis the IPv6 Prefix options for Dynamic Host Configuration Protocol for IPv6 specification. 11.1.
Client Basic Behaviors, Constants and Format The tests focus on the DHCP Basic behaviors, constants and format. The messages that are sent by the client will locate servers that will assign the IPv6 prefixes and/or additional configuration information pertaining to client IAs. Client Message Transmission The tests focus on the Requesting router (Client) message creation, transmission and termination of DHCP IPv6 exchanges. The messages that are sent by the client will locate servers that will assign the IPv6 prefixes and/or additional configuration information pertaining to client IAs. Message Reception The tests focus on the requesting routes (Client) implementation of DHCPv6 and the reception of valid and invalid DHCPv6 messages by a server device.

11.2.

11.3.

12. RFC 3633 Delegating Router (Server) Specification

It covers specifications for the delegating router (Server) implementation of IPv6 Prefix options for Dynamic Host Configuration Protocol (DHCP) version 6. The tests verify the process for transmitting a list of available IPv6 Prefix options from a server in Dynamic Host Configuration Protocol for IPv6. They verify the readiness of a DHCPv6 delegating router (Server) implementation vis--vis the IPv6 Prefix options for Dynamic Host Configuration Protocol for IPv6 specification.
20

12.1.

12.2.

12.3.

Delegating Router (Server) Basic Behaviors, Constants and Format The tests focus on the DHCP Basic Behaviors, constants and format. The messages that are sent by the requesting router will locate delegating router that will assign the IPv6 prefix and/or additional configuration information pertaining to client IAs. Server Message Transmission The tests focus on the delegating router message creation, transmission and termination of DHCP IPv6 exchanges. Message Reception The tests focus on the requesting routers implementation of DHCPv6 and the reception of valid and invalid DHCPv6 messages by a delegating router device.

13. RFC 3646 Requesting Router (Client) Specification

It covers specifications for the Requesting Router (client) implementation of the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The tests verify the process for receiving a list of available DNS recursive name servers and a domain search list from a server in parallel with Address Assignment. They verify the readiness of a DHCPv6 Requesting Router (client) implementation vis--vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification.

14. RFC 3646 Delegating Router (Server) Specification

It covers specifications for the Delegating Router (Server) implementation of the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The tests verify the process for passing a list of available DNS recursive name servers and a domain search list to a Requesting Router (client) in parallel with Prefix Assignment. They verify the readiness of a Delegating Router (Server) implementation vis--vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification.

21

CHAPTER-3.B DHCPv6 Interoperability Specifications

1. Introduction - There are five possibilities for equipment types:

a) DHCP client (or client): A node that initiates requests on a link to obtain configuration parameters from one or more DHCP servers. b) DHCP relay agent (or relay agent): A node that acts as an intermediary to deliver DHCP messages between clients and servers, and is on the same link as the client. c) DHCP server (or server): A node that responds to requests from clients, and may or may not be on the same link as the client(s). d) DHCP-PD Requesting Router: A node that requests configuration for an IPv6 Prefix according to RFC 3633 e) DHCP-PD Delegating Router: A node that responds to requests for configuration of an IPv6 Prefix according to RFC 3633.

2. Advanced Functionality - The following ADVANCED functions will be tested

(i) (ii) (iii) (iv) (v) Adv-1: Address Assignment Adv-2: DNS Configuration in parallel with Address Assignment Adv-3: Stateless DHCPv6 for DNS Configuration Adv-4: Prefix Delegation Adv-4: Prefix Delegation in parallel with DNS Configuration
References RFC3315 RFC3315+RFC3646 RFC3736 RFC3633 RFC3633+RFC3646

Advanced Functionality Tests Adv-1 Adv-2 Adv-3 Adv-4 Adv-5

3. Interoperable device requirement:

Each applicant must be tested against other devices according to the following (All Vendors MUST be different): 1. Client Application a. Must be tested against 2 Servers and 2 Relay-Agents 2. Server Application a. Must be tested against 2 Clients and 2 Relay-Agents 3. Relay-Agent Application a. Must be tested against: 2 Clients, 2 Servers, and 2 Relay-Agents b. 4 Different vendors are required, the vendor in each device
22

type must be different. 4. Requesting Router Application a. Must be tested against 2 Delegating Routers 5. Delegating Router Application a. Must be tested against 2 Requesting Routers

4. RFC 3315
To verify the readiness of DHCPv6 client, server and relay agent interoperability vis-vis the base specifications of the Dynamic Host Configuration Protocol for IPv6.

5. RFC 3646
To verify the readiness of DHCPv6 client and server interoperability vis--vis the specifications of the Dynamic Host Configuration Protocol for IPv6 options for passing a list of available DNS recursive name servers and a domain search list to a client.

6. RFC 3736
To verify the readiness of DHCPv6 client and server interoperability vis--vis the specifications of the Stateless Dynamic Host Configuration Protocol for IPv6.

7. RFC 3633
To verify the readiness of DHCPv6 Requesting Router (Client) and Delegating Router (Server) interoperability vis--vis the specifications of the DHCPv6-PD protocol.

8. RFC 3633 + RFC 3646

To cover basic interoperability of the IPv6 Prefix Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6-PD). It relates to DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3646. The tests are designed to verify the readiness of DHCPv6 Requesting Router (Client) and Delegating Router (Server) interoperability vis--vis the specifications of the DHCPv6-PD protocol.

23

CHAPTER-3.C IPsec (Internet Protocol Security)

1.0

Introduction
(i) Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite. It can be used in protecting data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-tonetwork), or between a security gateway and a host (network-to-host).
A Node Under Test (NUT) is required to satisfy following requirements. (i) Equipment Type A NUT can be of following 2 types a. End Node - A node which can use IPsec only for itself. Host and Router can be an End-Node. b. SGW (Security Gateway) - A node which can provide IPsec tunnel mode for nodes behind it. Router can be a SGW. (ii) Security Protocol - A NUT is required to pass all of the ESP tests regardless of the equipment type. Mode - The mode requirement depends on the type of NUT. (iii) a. End-Node - If the NUT is an End-Node, it must pass all the Transport mode tests. If the NUT supports the Tunnel mode, it also must pass all the Tunnel mode tests. (i.e., Tunnel mode is ADVANCED functionality for End-Node) b. SGW - If the NUT is a SGW, it must pass all the Tunnel mode tests.

(ii)

2.0

Related References
The following RFCs are required to be complied w.r.t. IPSec

"The Use of HMAC-SHA-1-96 within ESP andAH", RFC 2404, RFC2404 November 1998.
RFC2410 RFC2451 RFC3566 RFC3602

"The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003. "The AES-CBC Cipher Algorithm and Its Use with IPsec",
24

RFC 3602, September 2003.

RFC3686

"Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. "Security Architecture for the Internet Protocol", RFC 4301, December 2005. "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005. "The Camellia Cipher Algorithm andIts Use With IPsec", RFC 4312, December 2005. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. Using HMAC-SHA-256, HMAC-SHA-384, and HMACSHA-512 with IPsec, RFC4868, May 2007.

RFC4301 RFC4303

RFC4305

RFC4312

RFC4443

RFC4868

3.0

Encryption Algorithms
Two encryption algorithms are specified by the IPv6 Forum in the categories: (i) (ii) BASE ALGORITHM a. 3DES-CBC ADVANCED ALGORITHM a. AES-CBC b. AES-CTR c. NULL d. CAMELLIA-CBC

ll NUTs must pass the BASE ALGORITHM tests to confirm to specifications given by the IPv6 Forum. A NUT which supports algorithms listed as ADVANCED ALGORITHM, must pass all corresponding tests. The algorithm requirement is independent from NUT type.

4.0

Authentication Algorithms
IPv6 Forum has defined BASE ALGORITHM and ADVANCED ALGORITHM. All NUTs have to pass all the tests of BASE ALGORITHM to confirm to the specifications. The NUTs, which support the algorithms that are listed as ADVANCED ALGORITHM, have to pass all the corresponding tests. The algorithm requirement is independent from NUT type. (i) (ii) BASE ALGORITHM: a. HMAC-SHA1 ADVANCED ALGORITHMS: a. AES-XCBC-MAC-96 b. NULL c. HMAC-SHA-256
25

CHAPTER-3.D IPsec Interoperability Specifications

1.0

Interoperable device requirement - The following interoperability conditions

required to be fulfilled.

are

a) For End-Node:

(i) (ii)

Transport Mode (BASIC): 2 End-Node devices from different vendors Tunnel Mode (ADVANCED): 2 SGW devices or 2 End-Node devices from different vendors. These 2 vendors must not be same as the vendors for transport mode test

Transport Mode Tunnel Mode

End-Node 1 End-Node 2 SGW 1 SGW 2

or End-Node 1

Vendor A Vendor B Vendor C Vendor D Vendor A Vendor B Vendor C Vendor D

BASIC

ADVANCED

Transport Mode Tunnel Mode

BASIC ADVANCED

End-Node 2 End-Node 3 End-Node 4

b) For SGW: Tunnel Mode (BASIC): 2 SGW devices or 2 End-Node devices from different vendors

Tunnel Mode

SGW 1 SGW 2
or End-Node 1

Vendor A Vendor B Vendor A Vendor B

BASIC

Tunnel Mode

BASIC

End-Node 2

2.0

Required Tests
The following table describes which tests are required for interoperability

Focused Interface Test

Device Type

26

End-Node End-Node vs. End-Node (Transport) Transport Mode: ESP=3DES-CBC HMACSHA1 BASIC

SGW N/A

Transport Mode: ESP=3DES-CBC AES-XCBC ADVANCED N/A Transport Mode: ESP=3DES-CBC NULL Transport Mode: ESP=AES-CBC(128-bit) HMAC-SHA1 Transport Mode: ESP=AES-CTR HMACSHA1 Transport Mode: ESP=NULL HMAC-SHA1 ADVANCED N/A ADVANCED N/A ADVANCED N/A ADVANCED N/A

Transport Mode: ESP=CAMELLIA-CBC(128- ADVANCED N/A bit) HMAC-SHA1 Transport Mode: ESP=3DES-CBC ADVANCED N/A HMAC-SHA-256 Transport Mode: Select SPD (ICMP Type) Transport Mode: dummy packet handling Transport Mode: TFC padding SGW vs. SGW (Tunnel) *1 ADVANCED N/A *3 ADVANCED N/A ADVANCED N/A *4 BASIC ADVANCED ADVANCED ADVANCED ADVANCED ADVANCED ADVANCED ADVANCED

Tunnel Mode: ESP=3DES-CBC HMAC-SHA1 N/A Tunnel Mode: ESP=3DES-CBC AES-XCBC Tunnel Mode: ESP=3DES-CBC NULL Tunnel Mode: ESP=AES-CBC(128-bit) HMAC-SHA1 Tunnel Mode: ESP=AES-CTR HMAC-SHA1 Tunnel Mode: ESP=NULL HMAC-SHA1 N/A N/A N/A N/A N/A

Tunnel Mode: ESP=CAMELLIA-CBC(128N/A bit) HMAC-SHA1 Tunnel Mode: ESP=3DES-CBC HMAC-SHA- N/A 256

27

Tunnel Mode: ESP=Select SPD (ICMP Type) Tunnel Mode: ESP=dummy packet Tunnel Mode: ESP=TFC padding

N/A N/A N/A

ADVANCED *3 ADVANCED ADVANCED

Focused Interface Test

Device Type

End-Node

SGW

End-Node vs. SGW (Tunnel ) *1, *2

Tunnel Mode: ESP=3DES-CBC HMAC-SHA1 BASIC

BASIC

Tunnel Mode: ESP=3DES-CBC AES-XCBC

ADVANCED ADVANCED

Tunnel Mode: ESP=3DES-CBC NULL Tunnel Mode: ESP=AES-CBC(128-bit) HMAC-SHA1 Tunnel Mode: ESP=AES-CTR HMAC-SHA1

ADVANCED ADVANCED ADVANCED ADVANCED

ADVANCED ADVANCED

Tunnel Mode: ESP=NULL HMAC-SHA1

ADVANCED ADVANCED

Tunnel Mode: ESP=CAMELLIA-CBC(128ADVANCED ADVANCED bit) HMAC-SHA1 Tunnel Mode: ESP=3DES-CBC HMAC-SHA- ADVANCED ADVANCED 256 Tunnel Mode: ESP=Select SPD (ICMP Type) ADVANCED ADVANCED *3 *3 ADVANCED ADVANCED

Tunnel Mode: ESP=dummy packet handling

Tunnel Mode: ESP=TFC padding End-Node vs. End-Node (Tunnel) *1, *2

ADVANCED ADVANCED N/A

Tunnel Mode: ESP=3DES-CBC HMAC-SHA1 BASIC

Tunnel Mode: ESP=3DES-CBC AES-XCBC

ADVANCED N/A

28

Tunnel Mode: ESP=3DES-CBC NULL

ADVANCED N/A

Tunnel Mode: ESP=AES-CBC(128-bit) HMAC-SHA1 Tunnel Mode: ESP=AES-CTR HMAC-SHA1 Tunnel Mode: ESP=NULL HMAC-SHA1

ADVANCED N/A

ADVANCED N/A ADVANCED N/A

Tunnel Mode: ESP=CAMELLIA-CBC(128ADVANCED N/A bit) HMAC-SHA1 Tunnel Mode: ESP=3DES-CBC HMAC-SHA- ADVANCED N/A 256 Tunnel Mode: ESP=Select SPD (ICMP Type) Tunnel Mode: ESP=dummy packet handling ADVANCED N/A *3 ADVANCED N/A

Tunnel Mode: ESP=TFC padding

ADVANCED N/A

*1

If device is a SGW, either of them ("SGW vs. SGW" or "End-Node vs. SGW") must be run. Need to run test with more than 2 implementations as a counter part regardless of equipment type. The case when you choose SGW as a counter part, you need to run the test of "SGW vs. SGW". The case when you choose End-Node as a counter part, you need to run the test of "End-Node vs. SGW". If device is an End-Node and it supports Tunnel Mode, either of them must be run. Run test with more than 2 implementations as a counter part regardless of equipment type. The case when you choose SGW as a counter part, you need to run the test of "End-Node vs. SGW". The case when you choose EndNode as a counter part, you need to run the test of "End-Node vs. End-Node". This test should be done by using ICMP This test should be done using UDP

*2

*3 *4

29

3.0

The following components have to be verified

(i) (ii) (iii) (iv) (v) (vi) Transport Mode (End-Node vs End-node) Tunnel Mode (SGW vs. SGW) Tunnel Mode (End-Node vs. SGW) Tunnel Mode (End-Node vs. End-Node) Tunnel Mode (End-Node vs. SGW) Tunnel Mode (End-Node vs. End-Node)

30

CHAPTER-3.E IKEv2 Conformance

1.0

Introduction
Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security association (SA) in the IPSec protocol suite. IKE builds upon the Oakley protocol and ISAKMP. IKE uses certificates for authentication which are either preshared or distributed using DNS(preferably with DNSSEC), and a key exchange process to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained. To confirm to IKEv2 requirements, the Node Under Test (NUT) must satisfy all of the following requirements.
(i)
Equipment Type - There are two possibilities for equipment types: a. End-Node: - A node who can use IKEv2 (IPsec) only for itself. Host and Router can be an End- Node. b. SGW (Security Gateway): - A node who can provide IKEv2 (IPsec tunnel mode) for nodes behind it. Router can be a SGW. Function List (Basic/Advanced Functionality table) This conformance test specification consists of following BASIC/ADVANCED functions. The tests for ADVANCED functions may be omitted if the NUT does not support the ADVANCED function. All NUTs are required to support BASIC. ADVANCED is required for all NUTs which support ADVANCED function. BASIC ADVANCED

(ii)

Parameter

Exchange Type

Initial Exchanges (IKE_INIT, IKE_AUTH) CREATE_CHILD_SA INFORMATIONAL

ENCR_AES_CBC ENCR_AES_CTR PRF_AES128_XCBC AUTH_AES_XCBC_96

IKE_SA

Encryption Algorithm Pseudo-random Function Integrity Algorithm

ENCR_3DES PRF_HMAC_SHA1 AUTH_HMAC_SHA1_96

31

Diffie-Hellman Group

2 (1024 MODP Group)

CHILD_SA

Encryption Algorithm Integrity Algorithm Extended Sequence Numbers

ENCR_3DES AUTH_HMAC_SHA1_96 No Extended Sequence Numbers PSK ESP

14 (2048-bit MODP Group) 24 (2048-bit MODP Group with 256-bit Prime Order Subgroup) ENCR_AES_CBC ENCR_AES_CT R ENCR_NULL AUTH_AES_XCBC_96 NONE Extended Sequence Numbers Tunnel Sending Sending -

Authentication Method Security Protocol Encapsulation mode End-Node SGW Multiple Proposals Multiple Transforms Liveness Check

Transport Tunnel Receiving Receiving Support

Cookies Rekeying Traffic Selector Negotiation Requesting an Internal Address on a Remote Network Perfect Forward Secrecy Closing SAs ID Type Creating additional CHILD_SA Support Support Support

Support -

Support Support Support

ID_IPV6_ADDR -

32

2.0

The Following RFCs have to be complied

RFC 4306 - Internet Key Exchange (IKEv2) Protocol, December, 2005. RFC 4307 - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2), December, 2005 RFC 4718 - IKEv2 Clarifications and Implementation Guidelines, October, 2006

33

CHAPTER-3.F IKEv2 Interoperability 1.0 Introduction

To pass the tests for IKEv2 interoperability, the target device must satisfy all of the following requirements.

(i)

(ii)

Equipment Type - There are two possibilities for equipment types: a. End-Node: - A node who can use IKEv2 (IPsec transport mode and tunnel mode) only for itself. Host and Router can be an End-Node b. SGW (Security Gateway): A node who can provide IKEv2 (IPsec tunnel mode) for nodes behind it. Router can be a SGW Function List (Basic/Advanced Functionality table) - This interoperability test scenario consists following BASIC/ADVANCED functions. The tests for ADVANCED functions may be omitted if the target device does not support the ADVANCED function. All target devices are required to support BASIC. ADVANCED is required for all target devices which support ADVANCED function.

Parameter

BASIC Initial Exchanges (IKE_INIT, IKE_AUTH) CREATE_CHILD_SA INFORMATIONAL

ADVANCED

ENCR_AES_CBC PRF_AES128_XCBC PRF_HMAC_SHA2_256 AUTH_AES_XCBC_96 AUTH_HAMC_SHA2_256_128 14 (2048 MODP Group) 24 (2048 MODP Group with 256-bit Prime Order Subgroup) ENCR_AES_CBC ENCR_AES_CTR ENCR_NULL AUTH_AES_XCBC_96 NONE AUTH_HMAC_SHA2_256_128

Exchange Type

Encryption Algorithm IKE_SA Pseudo-random Function Integrity Algorithm

ENCR_3DES

PRF_HMAC_SHA1 AUTH_HMAC_SHA1_96

Diffie-Hellman Group Encryption Algorithm Integrity Algorithm

2 (1024 MODP Group)

ENCR_3DES

CHILD_SA

AUTH_HMAC_SHA1_96

34

ESN Authentication Method Security Protocol End-Node SGW Multiple Proposals Multiple Transforms Liveness Check Cookies Rekeying Traffic Selector Negotiation

Disable PSK ESP Transport Tunnel Receiving Receiving Support Support Support

Enable RSA Digital Signature Tunnel Sending Sending Support -

Encapsulation mode

Requesting an Internal Address on a Remote Network PFS Closing SAs ID Type Creating Additional CHILD_SA

Support ID_IPV6_ADDR -

Support Support Support

2.0

Related References
The following documents are referenced:

[IKEV2]

"Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[RFC4307] "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. [Clarif]

"IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.

35

CHAPTER-3.G MIPv6 Self Test Specification for CN

1.0

Introduction
Mobile IPv6 (MIPv6) is a protocol developed as a subset of Internet Protocol version 6 (IPv6) to support mobile connections. MIPv6 is an update of the IETF (Internet Engineering Task Force) Mobile IP standard (RFC 2002) designed to authenticate mobile devices (known as mobile nodes) using IPv6 addresses. In traditional IP routing, IP addresses represent a topology. Routing mechanisms rely on the assumption that each network node will always have the same point of attachment to the Internet, and that each node's IP address identifies the network link where it is connected. In this routing scheme, if you disconnect a mobile device from the Internet and want to reconnect through a different network, you have to configure the device with a new IP address, and the appropriate netmask and default router. Otherwise, routing protocols have no means of delivering datagram (packets), because the device's network address doesn't contain the necessary information about the node's network point of attachment to the Internet. MIPv6 allows a mobile node to transparently maintain connections while moving from one subnet to another. Each device (MN = Mobile Node) is identified by its home address although it may be connecting to a node (CN = Correspondent Node) in another network. When connecting through a foreign network, a mobile device sends its location information to a home agent(HA), which intercepts packets intended for the device and tunnels them to the current location. The following describes the specifications for Mobile IPv6 self test for a correspondent node (CN)

2.0

Reference standards
This documentation covers the functions specified in the IETF RFC and Mobile IPv6 Test Profile given by the IPv6 Forum (IPv6 Ready Logo Programme). They are listed below. (i) RFC3775: Mobility Support in IPv6 (http://www.ietf.org/rfc/rfc3775.txt) (ii) RFC3776: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (http://www.ietf.org/rfc/rfc3776.txt) (iii)IPv6 Ready Logo Phase-2 Mobile IPv6 Policy (http://www.ipv6ready.org/about_phase2_test.html) (iv) IPv6 Ready Logo Phase-2 Mobile IPv6 Test Specification Profile (http://www.ipv6ready.org/about_phase2_test.html)

36

Chapter-3.H MIPv6 Self Test Specification for HA

1.0

Introduction
The following describes the specifications for the Home Agent (HA).

2.0

Reference standards
This documentation covers the functions specified in the IETF RFC and Mobile IPv6 Test Profile given by the IPv6 Forum (IPv6 Ready Logo Programme). These are listed below. (i) RFC3775: Mobility Support in IPv6 (http://www.ietf.org/rfc/rfc3775.txt) (ii) RFC3776: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (http://www.ietf.org/rfc/rfc3776.txt) (iii)RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (http://www.ietf.org/rfc/rfc4877.txt) (iv) IPv6 Ready Logo Phase-2 Mobile IPv6 Policy (http://www.ipv6ready.org/about_phase2_test.html) (v) IPv6 Ready Logo Phase-2 Mobile IPv6 Test Specification Profile (http://www.ipv6ready.org/about_phase2_test.html)

37

CHAPTER-3.I MIPv6 Interoperability Test Specification

1.0

Introduction
This document describes test scenarios to verify the interoperability between Mobile IPv6 equipment, in the form of Correspondent Nodes (CNs), Home Agents (HAs), and Mobile Nodes (MNs).

2.0

Reference standards
This documentation covers the functions specified in the IETF RFC and Mobile IPv6 Test Profile listed below. (i) RFC3775: Mobility Support in IPv6 (http://www.ietf.org/rfc/rfc3775.txt) RFC3776: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes (ii) and Home Agents (http://www.ietf.org/rfc/rfc3776.txt) RFC4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (iii) (http://www.ietf.org/rfc/rfc4877.txt) (iv) Guidelines for Implementation (v) IPv6 Ready Logo Phase 2 Policy

38

CHAPTER-3.J MIPv6 Conformance MN Specification

1.0

For MIPv6 conformance of the mobile node, the following have to be complied for the Mobile Node (MN) Operation. These are specified in RFC3775 (Mobility Support in IPv6).

(i) (ii) (iii) (iv) (v) (vi) (vii) (viii) (ix) (x) (xi) (xii) (xiii) (xiv)

Generate Home Address (HoA) using RFC2462 Generate Care of Address (CoA) using RFC2462 Movement Detection Home Registration Home Re-Registration Returning Home Correspondent Registration Dynamic Home Agent Address Discovery Mobile Prefix Discovery Binding Error ICMP Error Payload Packet IPsec Security Association (SA) Mobile to Mobile

39

CHAPTER-3.K MLDv2 Conformance Specification

1.0

Introduction
The Multicast Listener Discovery Protocol (MLD) is used by IPv6routers to discover the presence of multicast listeners (i.e., nodes that wish to receive multicast packets) on their directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. Note that a multicast router may itself be a listener of one or more multicast addresses; in this case it performs both the "multicast router part" and the "multicast address listener part" of the protocol, to collect the multicast listener information needed by its multicast routing protocol on the one hand, and to inform itself and other neighboring multicast routers of its listening state on the other hand. The following describes the router Conformance specifications for MLDv2 (Multicast Listener Discovery Version 2.

2.0

References
The following documents are referenced in this text: [MLD] - Multicast Listener Discovery Version 2 (MLDv2) for IPv6, RFC 3810, June (i) 2004. (ii) [SSM] - Using Internet Group Management Protocol Version 3 (IGMPV3) and Multicast Listener Discovery Protocol 2 (MLDv2) for Source-Specific Multicast, RFC 4606, August 2006.

3.0

Basic Functionality
To verify that the basic MLDv2 router functionalities are performed correctly on the RUT (Router Under Test). These functionalities include value configuration, Querier Election, Report reception, Query transmission, MLDv2 security, and Router-Side Processing Suppression.

4.0

Message Format
To verify that the MLDv2 packet types are properly formatted: General Queries, GroupSpecific Queries, and Group-and-Source Specific Queries. In particular check the formats of the Checksum, Group Address, Reserved, Max Response Code, and Queriers Query Interval Code fields. Also verify that the MLDv2 Router validates the IP Destination, validates the checksum, and that the Router properly handles unrecognized codes. Finally, verify Additional Data, and Auxiliary Data report reception.

5.0

Value Adoption and Timers

To verify that an MLDv2 Router will adopt the appropriate values for certain timers when nonquerier. These values include the Robustness Variable, the Other Querier Present Interval, the Group Membership Interval, Queriers Query Interval Code Adoption, and Older Host Present Interval. Also verify that timer expiration is handled correctly.
40

6.0

Report Reception
To verify that when an MLDv2 Router receives a MLDv2 Report the router switches to the appropriate state, updates times, and transmits queries as required. These specifically test the charts found in RFC 3376 Sections 6.4.1 and 6.4.2 reproduced below for convenience.

Router State Report Rec'd New Router State

INCLUDE (A) INCLUDE (A) IS_IN (B) IS_EX (B) INCLUDE (A+B) EXCLUDE (A*B,B-A)

Action(s)
(B)=GMI (B-A)=0 Delete (A-B) Group Timer=GMI (A)=GMI (A-X-Y)=GMI Delete (X-A) Delete (Y-A) Group Timer=GMI

EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X,Y) IS_EX (A)

EXCLUDE (X+A,Y-A) EXCLUDE (A-Y,Y*A)

Router State Report Rec'd New Router State

INCLUDE (A) INCLUDE (A) INCLUDE (A) ALLOW (B) BLOCK (B) TO_EX (B) INCLUDE (A+B) INCLUDE (A) EXCLUDE (A*B,B-A)

Action(s)

INCLUDE (A)

TO_IN

(B)

EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X,Y) TO_EX (A)

EXCLUDE (X,Y) TO_IN (A)

(B)=GMI Send Q(G,A*B) (B-A)=0 Delete (A-B) Send Q(G,A*B) Group Timer=GMI (B)=GMI INCLUDE (A+B) Send Q(G,A-B) EXCLUDE (X+A,Y-A) (A)=GMI EXCLUDE (X+(A-Y),Y) (A-X-Y)=Group Timer Send Q(G,A-Y) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer Delete (X-A) Delete (Y-A) Send Q(G,A-Y) Group Timer=GMI EXCLUDE (X+A,Y-A) (A)=GMI Send Q(G,X-A) Send Q(G)

7.0

Version Interoperability
To verify that an MLDv2 Router ignores the appropriate Reports when in MLDv1 Group Member Compatibility Modes. Also verify the Router translates MLDv1 Reports into their corresponding MLDv2 Reports, that the Router has the appropriate Group Compatibility Mode scope, and that the Other Host Present Interval expires and transitions modes as expected.

8.0

Source Specific Multicast

To verify that an MLDv2 Router accommodates source-specific multicast (SSM). Sourcespecific multicast is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission.

41

CHAPTER-3.L MLDv2 Interoperability Specification

1.0 Introduction

The chapter describes the router Interoperability specifications for MLDv2 (Multicast Listener Discovery Version 2.

2.0

References
The following documents are referenced in this text: (i) [MLD] - Multicast Listener Discovery Version 2 (MLDv2) for IPv6, RFC 3810, June 2004. (ii) [SSM] - Using Internet Group Management Protocol Version 3 (IGMPV3) and Multicast Listener Discovery Protocol 2 (MLDv2) for Source-Specific Multicast, RFC 4604, August 2006.

3.0

- MLDv2 defines several timers and default values. These defaults are taken or calculated from RFC3376:

Timers and Default Values

4.0

Listener and Router Interoperability - To verify that an MLDv2 router and listener behave correctly when interacting with multicast address records, source records, version compatibility, and source specific multicast. Router Interoperability
- To verify that MLDv2 routers behave correctly when interacting with other routers on the network.

5.0

42

CHAPTER-3.M SNMP / MIB Conformance Specifications

1.0

Introduction (SNMP)
The Simple Network Management Protocol (SNMP) is most commonly used protocol to communicate management information between the network management stations and the agents in the network elements. According to the SNMP architectural model, network management stations execute management applications which monitor and control gateways, terminal servers and the like, and which have management agents for performing the network management functions requested by the network management stations. Verification of the IPv6 network management functionality of the IPv6-capable equipment by SNMP protocol based on related RFCs is the main goal of this chapter.

2.0

References
The following RFCs are related
[ADDR]

Internet Protocol Version 6 (IPv6) Addressing Architecture, RFC 3315, April 2003.

[ICMPv6]

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 4443, March 2006.

[INA-TC]

Textual Conventions for Internet Network Addresses, RFC 4001, February 2005. Internet Protocol, version 6 (IPv6) Specification, RFC 2460, December 1998. IPv6 Forum IPv6 (http://www.ipv6ready.org/) Ready Technical Documentation.

[IPv6SPEC]

[IPv6 Ready Phase II Test Specification Core Protocols] [MIB-DEF]

Concise MIB definitions, RFC 1212, March 1991.

43

[MIB-II] [MIB for IP]

Management Information Base for Network Management of TCP/IPbased internets MIB-II, RFC 1213, March 1991. Management Information Base for the Internet Protocol (IP), RFC 4293, April 2006. Structure and Identification of Management Information for TCP/IPbased Internets, RFC 1155, May 1990. Structure of Management Information version 2 (SMIv2), RFC 2578, April 1999. Conformance Statements for SMIv2. RFC 2580, April 1999. Textual Conventions for SMIv2, RFC 2579, April 1999. A Simple Network Management Protocol (SNMPv1), RFC 1157, May 1990. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3rd ed., 1999. Protocol Operations for version 2 of the Simple Network Management Protocol, RFC 3416, December 2002. Introduction to Community- based SNMPv2, RFC 1901, January 1996. Management Information Base (MIB) for the Simple Network Management Protocol (SNMP), RFC 3418, December 2002. Structure of Management Information version 2 (SMIv2), RFC 2578, April 1999.

[SIMI]

[SMIv2]

[SMIv2-CS]

[SMIv2-TC]

[SNMPv1]

[SNMP]

[SNMPv2]

[SNMPv2C]

[SNMPv2MIB]

[SMIv2]

3.0

Requirements
This specification is intended to verify the SNMPv2C protocol behaviors, as defined in RFC 3416, over IPv6. SNMPv2C, as defined in RFC 3416, is the most prevalent management protocol on top to IPv4 network layer. To provide a more efficient network management perspective, IETFs recent RFC 4293 document integrates RFC2465 for the IPv6 Management Information Base (MIB) and RFC 2466 for IPv6 ICMP MIB into

44

Management Information Base for the Internet Protocol which will be used to manage network nodes in the IP Internet community using SNMP protocol.

4.0

Target SNMPv2C agent and manager The SNMPv2C tests shall be categorized as SNMPv2C agent or manager according to SNMPv2C agent or manager role the NUT undertakes.

5.0

NUT as SNMPv2C Agent - RFC 3416 SNMPv2(SNMPv2C) Protocol Operations T o v e r i f y SNMPv2C functionalities based in RFC 3416, IETF specification by which management information for a network element may be inspected or altered by logically remote users.

45

Chapter-3.N SNMP / MIB Conformance Specification

1.0 Introduction MIB (Management Information Base)
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). 2.0

Reference Standards
(i) RFC 3418 SNMPv2 MIB - To verify the readiness of a SNMPv2 MIB implementation. (ii) RFC 4293 IP-MIB - To verify the readiness of a new RFC 4293 MIB implementation.

46

CHAPTER-3.O Session Initiation protocol (SIP) Proxy Server Conformance Specifications

1.0 Introduction
The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol(IP). The protocol can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions consisting of one or several media streams. The modification can involve changing addresses or ports, inviting more participants, and adding or deleting media streams. Other feasible application examples include video conferencing, streaming multimedia distribution, instant messaging, presence information, file transfer and online games. This chapter describes the SIP Conformance specification.

2.0

Reference standards
(i) (ii) (iii) (iv) (v) (vi) (vii)

RFC3261: SIP: Session Initiation Protocol (http://www.ietf.org/rfc/rfc3261.txt) RFC3264: An Offer/Answer Model with Session Description Protocol (http://www.ietf.org/rfc/rfc3264.txt) RFC4566: SDP: Session Description Protocol (http://www.ietf.org/rfc/rfc4566.txt) RFC2617: HTTP Authentication: Basic and Digest Access Authentication (http://www.ietf.org/rfc/rfc2617.txt) RFC3665: SIP Basic Call Flow Examples (http://www.ietf.org/rfc/rfc3665.txt) IPv6 Ready Logo Phase 2 Policy SIP IPv6 Test Scope

47

CHAPTER-3.P Session Initiation protocol (SIP) Registrar Server Conformance Specifications

1.0

Introduction
This chapter describes the SIP Conformance specifications for a Registrar Server. A SIP registrar is a server in a Session Initiation Protocol (SIP) network that accepts and processes SIP REGISTER requests. The SIP registrar provides a location service which registers one or more IP addresses to a certain SIP URI (Uniform Resource Identifier), indicated by the sip scheme, although other protocol schemes are possible.

2.0

Reference standards
(i) (ii) (iii) (iv) (v) (vi) RFC3261: SIP: Session Initiation Protocol (http://www.ietf.org/rfc/rfc3261.txt) RFC3264: An Offer/Answer Model with Session Description Protocol (http://www.ietf.org/rfc/rfc3264.txt) RFC4566: SDP: Session Description Protocol (http://www.ietf.org/rfc/rfc4566.txt) RFC2617: HTTP Authentication: Basic and Digest Access Authentication (http://www.ietf.org/rfc/rfc2617.txt) RFC3665: SIP Basic Call Flow Examples (http://www.ietf.org/rfc/rfc3665.txt) IPv6 Ready Logo Phase 2 Policy on SIP IPv6 Test Scope

48

CHAPTER-3.Q Session Initiation protocol (SIP) User Agent (UA), Endpoint (EP), Back to Back User Agent (B2BUA) Conformance Specifications

1.0

Introduction
This chapter describes the SIP Conformance specification for User Agent, Endpoint and Back-toBack User Agent

2.0

Reference standards
(i) (ii) (iii) (iv) (v) (vi) RFC3261: SIP: Session Initiation Protocol (http://www.ietf.org/rfc/rfc3261.txt) RFC3264: An Offer/Answer Model with Session Description Protocol (http://www.ietf.org/rfc/rfc3264.txt) RFC4566: SDP: Session Description Protocol (http://www.ietf.org/rfc/rfc4566.txt) RFC2617: HTTP Authentication: Basic and Digest Access Authentication (http://www.ietf.org/rfc/rfc2617.txt) RFC3665: SIP Basic Call Flow Examples (http://www.ietf.org/rfc/rfc3665.txt) IPv6 Ready Logo Phase 2 Policy SIP IPv6 Test Scope

49

CHAPTER-3.R Session Initiation protocol (SIP) Interoperability Specifications

1.0

Introduction
This chapter describes details of the SIP Interoperability specification to verify the interoperability
between SIP IPv6 equipment.

2.0

Reference standards
(i) (ii) (iii) (iv) (v) (vi) (vii) RFC3261: SIP: Session Initiation Protocol (http://www.ietf.org/rfc/rfc3261.txt) RFC3264: An Offer/Answer Model with Session Description Protocol (http://www.ietf.org/rfc/rfc3264.txt) RFC4566: SDP: Session Description Protocol (http://www.ietf.org/rfc/rfc4566.txt) RFC2617: HTTP Authentication: Basic and Digest Access Authentication (http://www.ietf.org/rfc/rfc2617.txt) RFC3665: SIP Basic Call Flow Examples (http://www.ietf.org/rfc/rfc3665.txt) Guidelines for Implementation (http://www.ipv6ready.org/about_phase2_test.html) IPv6 Ready Logo Phase 2 Policy for SIP (http://www.ipv6ready.org/about_phase2_test.html)

3.0

Interoperability Test Scenario

All BASIC functions must be supported in the viewpoint of interoperability, and each ADVANCED function can be selectively supported. The other SIP equipment that connects to a piece of applicant implementation on a network architecture must support the functions, regardless of BASIC or ADVANCED function. In the case of ADVANCED function, especially, confirm that all SIP equipment on the architecture support the same functions as those of the applicant implementation.

50

List of Interoperability test for BASIC and ADVANCED functions BASIC functions ADVANCED functions

- Registration (for Endpoint / Registrar) - Establishment, disconnection, and cancellation of Session - SDP Offer/Answer (INVITE-200) - Digest authentication (REGISTER, Initial INVITE)(for Endpoint) - Digest authentication (Initial INVITE) (for UA / B2BUA) - Hold (Using Re-INVITE) (for B2BUA)

- Registration and Digest authentication for REGISTER (for UA / B2BUA) - Hold (Using ReINVITE) (for UA / Endpoint) - Forking / Multiple responses - OPTIONS request

51

CHAPTER-3.S IP Multimedia Subsystem User Equipment (IMS-UE) Conformance Specifications

1.0

Introduction
The IP Multimedia Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia services. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), as a part of the vision for evolving mobile networks beyond GSM. Its original formulation (3GPP R5) represented an approach to delivering "Internet services" over GPRS. This vision was later updated by 3GPP, 3GPP2 and TISPAN by requiring support of networks other than GPRS, such as Wireless LAN, CDMA2000 and fixed line. To ease the integration with the Internet, IMS uses IETF protocols wherever possible, e.g. Session Initiation Protocol (SIP). According to the 3GPP, IMS is not intended to standardize applications but rather to aid the access of multimedia and voice applications from wireless and wireline terminals, i.e. create a form of fixed-mobile convergence (FMC). This is done by having a horizontal control layer that isolates the access network from the service layer. From a logical architecture perspective, services need not have their own control functions, as the control layer is a common horizontal layer. However in implementation this does not necessarily map into greater reduced cost and complexity. This chapter describes the IMS Conformance
Specifications for User Equipment when IPv6 is in use.

2.0

Reference standards
2.1
[IMS] 2.1.1 TS 24.229: IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3(Release 7), 3GPP TS 24.229 v7.8.0. (http://www.3gpp.org/ftp/Specs/html-info/24229.htm) [SIP/SDP] 2.2.1 RFC3261: SIP: Session Initiation Protocol (http://www.ietf.org/rfc/rfc3261.txt) (3) RFC3265: Session Initiation Protocol (SIP)-Specific Event Notification (http://www.ietf.org/rfc/rfc3265.txt) 2.2.2 RFC3327: Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts (http://www.ietf.org/rfc/rfc3327.txt) 2.2.3 RFC3455: Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) (http://www.ietf.org/rfc/rfc3455.txt) 2.2.4 RFC3608: Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration (http://www.ietf.org/rfc/rfc3608.txt)
52

2.2

2.2.5 2.2.6 2.2.7

RFC3680: A Session Initiation Protocol (SIP) Event Package for Registrations (http://www.ietf.org/rfc/rfc3680.txt) RFC4320: Actions addressing identified issues with the Session Initiation Protocol's non-INVITE Transaction (http://www.ietf.org/rfc/rfc4320.txt) RFC4566: SDP: Session Description Protocol (http://www.ietf.org/rfc/rfc4566.txt)

2.3

[SigComp] 2.3.1 RFC3320: Signaling Compression (SigComp) (http://www.ietf.org/rfc/rfc3320.txt) 2.3.2 RFC3485: The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) (http://www.ietf.org/rfc/rfc3485.txt) 2.3.3 RFC3486: Compressing the Session Initiation Protocol (http://www.ietf.org/rfc/rfc3486.txt) 2.3.4 RFC4896: Signaling Compression (SigComp) Corrections and Clarifications (http://www.ietf.org/rfc/rfc4896.txt) 2.3.5 RFC5049: Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) (http://www.ietf.org/rfc/rfc5049.txt) [IMS AKA and Security Association] 2.4.1 TS.33.203: 3G security; Access security for IP-based services (Release 7) (http://www.3gpp.org/ftp/Specs/html-info/33203.htm), 3GPP TS 33.203 v7.6.0. 2.4.2 RFC3310: Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) (http://www.ietf.org/rfc/rfc3310.txt) 2.4.3 RFC3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP) (http://www.ietf.org/rfc/rfc3329.txt)

2.4

3.0

User Equipment operation The following functions are to be tested for User Equipment (UE)

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Registration Session Establishment SDP OPTIONS SIP timer Sending Response Receiving Response SigComp

53

CHAPTER-3.T IP Multimedia Subsystem User Equipment (IMS-UE) Interoperability Specifications

1.0 Introduction
This chapter describes the IMS Interoperability Specifications.

2.0

Equipment Type
UE (User Equipment): A node that initiates and receives requests to exchange parameters between P-CSCF. IMS IPv6 UE must execute the interoperability test with two or more vendors equipments. Also, it is recommended to execute the interoperability test with UE2 (REF UE) which is the same vender as UE1 (TARTGET UE). Moreover, UE2 must support the same functions as UE1, and IMS CSCFs1/HSS1 (REF) must support all BASIC functions.

3.0

Reference Standards
[TS24.229] 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 7), 3GPP TS 24.229 v7.8.0. 3rd Generation Partnership Project Technical Specification Group Services and System Aspects; 3G security Access security for IP-based services (Release 7), 3GPP TS 33.203 v7.6.0. SIP: Session Initiation Protocol, RFC 3261, June 2002. SDP: Session Description Protocol, RFC 4566, July 2006. Session Initiation Protocol (SIP)-Specific Event Notification, RFC 3265, June 2002. Security Mechanism Agreement for the Session Initiation Protocol (SIP), RFC 3329, January 2003.

[TS33.203]

[SIP] [SDP] [SIPEVENT] [RFC3329]

54

CHAPTER-3.U Network Mobility (NEMO) Home Agent (HA) Self Test Conformance Specifications

1.0

Introduction
A mobile network (known also as a "network that moves," or NEMO) is defined as a network whose attachment point to the Internet varies with time. The router within the NEMO that connects to the Internet is called the Mobile Router (MR). It is assumed that the NEMO is assigned to a particular network, known as its Home Network (MR connects to a Home Agent HA- in the home network) where it resides when it is not moving. Because the NEMO is part of the home network, the mobile network has configured addresses belonging to one or more address blocks assigned to the home network: the Mobile Network Prefixes (MNPs). These addresses remain assigned to the NEMO when it is away from home. These addresses have topological meaning only when the NEMO is at home. When the NEMO is away from home, packets addressed to the nodes of the NEMO, known as Mobile Network Nodes (MNNs), are still routed to the home network. Additionally, when the NEMO is away from home, the mobile router acquires an address from the visited network, called the Care-of Address (CoA), where the routing architecture can deliver packets without additional mechanisms. This chapter describes the Home Agent (HA) Conformance Specifications.

2.0

Reference standards
The functions are specified in the IETF RFC and Mobile IPv6 Test Profile listed below. (i) (ii) (iii) (iv) (v) (vi) RFC3963: Network Mobility (NEMO) Basic Support Protocol (http://www.ietf.org/rfc/rfc3963.txt) RFC3775: Mobility Support in IPv6 (http://www.ietf.org/rfc/rfc3775.txt) RFC3776: Using IPSec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (http://www.ietf.org/rfc/rfc3776.txt) RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPSec Architecture (http://www.ietf.org/rfc/rfc4877.txt) IPv6 Ready Logo Phase-2 Network Mobility (NEMO) Policy (http://www.ipv6ready.org/about_phase2_test.html) IPv6 Ready Logo Phase-2 Network Mobility (NEMO) Test Specification Profile(http://www.ipv6ready.org/about_phase2_test.html).

55

CHAPTER-3.V Network Mobility (NEMO) Mobile Router (MR) Conformance Specifications

1.0

Introduction
This chapter describes the NEMO-MR Conformance Specifications.

2.0

Reference standards - The specified IETF RFC and Network Mobility Test
Profile RFCs are listed below. (i) (ii) (iii) (iv) (v) (vi) RFC3963: Network Mobility (NEMO) Basic Support Protocol (http://www.ietf.org/rfc/rfc3963.txt) RFC3775: Mobility Support in IPv6 (http://www.ietf.org/rfc/rfc3775.txt) RFC3776: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (http://www.ietf.org/rfc/rfc3776.txt) RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (http://www.ietf.org/rfc/rfc4877.txt) IPv6 Ready Logo Phase-2 Netowork Mobility (NEMO) Policy (http://www.ipv6ready.org/about_phase2_test.html) IPv6 Ready Logo Phase-2 Netowork Mobility (NEMO) Test Specification Profile (http://www.ipv6ready.org/about_phase2_test.html/)

3.0

Mobile Router operation The following components are to be tested 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 Generate CoA Movement Detection Mobile Prefix Registration Mobile Network Prefix Re-Registration Returning Home Neighbor Discovery Dynamic Home Agent Address Discovery Mobile Prefix Discovery Binding Error ICMP Error Payload Packet IPsec Security Associations

56

CHAPTER-3.W Network Mobility (NEMO) Interoperability Specifications

1.0

Introduction
This chapter gives scenarios for the interoperability between different implementations of Network
Mobility, in the form of Home Agents (HAs) and Mobile Routers (MRs).

2.0

Reference standards The relevant IETF RFC and Network Mobility Test Profile
are listed below. (i) (ii) (iii) (iv) (v) (vi) RFC3963: Network Mobility (NEMO) Basic Support Protocol RFC3775: Mobility Support in IPv6 RFC3776: Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents RFC4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (http://www.ietf.org/rfc/rfc4877.txt) Guidelines for Implementation (http://www.ipv6ready.org/about_phase2_test.html/) IPv6 Ready Logo Phase 2 Policy for NEMO (http://www.ipv6ready.org/about_phase2_test.html)

4.0

Requirements and References

Target Reference RFC (responding to Implementation Guideline) HA RFC3963 Basic Functions Requirements for IPv6 Home Agents Mobile network prefix registration 6.1.1 6.1.2 6.2 6.7 9 BU/BA 6 6.2 6.6 Encapsulation/ 6.4 6 Function Section number in RFC

57

decapsulatation / forwarding Advanced Functions DHAAD

6.5 9 7 7.1 7.2

Dynamic routing protocol

6.1.2 6.3 8

Advertising reachability IPsec Real HL RFC3775 Requirements for IPv6 Home Agents Home Registration 8.4 Encapsulation/ decapsulatation / forwarding Mobility Header BU/BA Home agent information option Mobile prefix advertisement IPsec ESP Multicast Stateful address autoconfiguration Basic Functions 10.3.1 Home Registration 8.4 10.1 8.4 8.4 8.4 8.4 Requirements 8.4 6.3 9 7.3

8.4 8.4 8.4

BU/BA (IPsec ESP)

4.1 4.2 4.3

58

Encapsulation/ decapsulatation

10.4.1 10.4.2 10.4.5

Advanced Functions

DHAAD MPD

10.5.1 10.6.2 10.6.3 4.1 4.2 4.3

Real HL

10.1 10.3.1 10.3.2 10.4.1 10.4.2 4.2

Advanced RFC4877 MR RFC3963 Function Basic Functions Fine-Grain Selectors Mobile router operation (including requirements for IPv6 Mobile Nodes) Home Registration BU/BA including error proccessing 5.3 5.4 Implicit mode 5.4.1 Explicit mode 5.4.2 5.8 Supporting both modes 5.2 5.4 5.2 5.2 5.2 5.1 9 4 5

59

Encapsulation/ decapsulatation / forwarding 5.5

Advanced Function

DHAAD

5.1 5.3 7 7.1-7.2

Neighbor Discovery

5.6 7.3

Dynamic routing protocol

8 9

Multicast Real HL

5.7 5.6 5.7 5.8

IPsec RFC3775 Requirements for IPv6 Mobile Nodes Requirements

8.5

Home Registration 8.5 Home address option IPsec Encapsulation/ decapsulatation / forwarding Binding Error ICMP Movement detection Returning home 8.5 8.5 8.5 8.5 8.5

60

Mobility Header RR BU/BA Mobile prefix advertisement DHAAD Route optimization Multicast Stateful address autoconfiguration Basic Function Home Registration

8.5 8.5 8.5 8.5 8.5 8.5 8.5 8.5 11.1 11.7.1 11.7.3

BU/BA (IPsec ESP)

11.7.3 4.1 4.2 4.3

Encapsulation / decapsulation Movement detection, CoA formation, visiting of FL 11.5.2 Advanced Function DHAAD MPD 11.4.1 11.4.2 11.7.3 4.1 4.2 4.3 4.4 Real HL 11.3.1 11.5.4 4.2 Advanced RFC4877 Function Fine-Grain Selectors 4 11.5.1 11.3.1

61

CHAPTER-4 IETF RFC Summary for IPv6

(1)

IPV6 BASIC REQUIREMENTS

IETF Specification

IPv6 Basic Requirements

RFC2460

IPv6 Specification IPv6 Packets: send, receive IPv6 packet forwarding Extension headers: processing Hop-by-Hop & unrecognized options Fragment headers: send, receive, process Destination Options extensions

RFC5095 RFC2711 RFC4443 RFC4884 RFC1981

Deprecation of Type 0 Routing Headers IPv6 Router Alert Option ICMPv6 Extended ICMP for Multi-Part Messages Path MTU Discovery for IPv6 Discovery Protocol Requirements

RFC2675 RFC4861

IPv6 Jumbograms Neighbor Discovery for IPv6 Router Discovery Prefix Discovery Address Resolution NA and NS processing

(RFC4862)

Duplicate Address Detection Neighbor Unreachability Detection Redirect functionality

62

RFC5175 RFC4191 RFC3971 RFC4862

IPv6 Router Advertisement Flags Option Default Router Preference Secure Neighbor Discovery IPv6 Stateless Address Autoconfig Creation of Link Local Addresses

(RFC4861)

Duplicate Address Detection Creation of Global Addresses Ability to Disable Creation of Global Address

RFC4941

Privacy Extensions for IPv6 SLAAC <2nd context for MIP Mobile Node>

RFC3633

Prefix Delegation

(2)

Addressing Requirements
IETF Addressing Requirements Specification

RFC4921 RFC4007

IPv6 Addressing Architecture IPv6 Scoped Address Architecture Ability to manually configure Addresses

RFC4193 RFC3879 RFC3484

Unique Local IPv6 Unicast Address Deprecating Site Local Addresses Default Address Selection for IPv6 Configurable Selection Policies

RFC2526 RFC3972 RFC4581 RFC4982

Reserved IPv6 Subnet Anycast Addresses Cryptographically Generated Addresses (CGA) CGA Extension Field Format CGA Support for Multiple Hash Algorithms.

(3)

Security Requirements
IETF Specification IPv6 Security Requirements

63

Ipsec-v3

RFC4301 RFC4303 RFC4302 RFC3948 RFC4835 RFC4308 RFC4869 RFC4809

IKEv2

Security Architecture for the IP Encapsulating Security Payload Authentication Header (AH) UDP Encapsulation of ESP Packets Cryptographic Algorithms for ESP and AH Cryptographic Suites for Ipsec Suite B Cryptographic Suites for Ipsec Requirements for an Ipsec Cert Mgmnt Profile

RFC4306 RFC4718 RFC4307 RFC3526 RFC5114 RFC4945

Internet Key Exchange (IKEv2) Protocol IKEv2 Clarifications & Impl. Guidelines Cryptographic Algorithms for IKEv2 More MODP DH Groups for IKE Additional DH Groups for Use with IETF Stds Internet Ipsec PKI Profile of IKEv1, IKEv2 & PKIX

Uses of Cryptographic Algorithms

RFC2410 RFC4835 RFC2451 RFC4835 RFC4307 RFC3602 RFC4835 RFC4307 RFC3686 RFC4835 RFC4307

NULL Encryption Cryptographic Algorithms for ESP and AH ESP CBC-mode Algorithms Cryptographic Algorithms for ESP and AH Cryptographic Algorithms for IKEv2 AES-CBC Cryptographic Algorithms for ESP and AH Cryptographic Algorithms for IKEv2 AES-CTR Cryptographic Algorithms for ESP and AH Cryptographic Algorithms for IKEv2

64

RFC4309 RFC4835 RFC4106 RFC4543 RFC2404 RFC4835 RFC4307 RFC4307 RFC4868 RFC3566 RFC4835 RFC4307 RFC4434 RFC4307

AES-CCM Cryptographic Algorithms for ESP and AH AES-GCM AES-GMAC HMAC-SHA-1-96 Cryptographic Algorithms for ESP and AH Cryptographic Algorithms for IKEv2 Cryptographic Algorithms for IKEv2 HMAC-SHA-256 AES-XCBC-MAC-96 Cryptographic Algorithms for ESP and AH Cryptographic Algorithms for IKEv2 AES-XCBC-PRF-128 Cryptographic Algorithms for IKEv2

Transition Mechanisms Requirements

RFC4213 RFC4891 RFC2473 RFC4798

Transition Mechanism for Hosts & Routers Using IPsec to Secure IPv6-in-IPv4 Tunnels Generic Packet Tunneling in IPv6 Connecting IPv6 islands over IPv4 MPLS (6PE)

(4)

Application Requirements
IETF Application Requirements Specification

RFC3596

DNS Extensions for IPv6

RFC2671

Extension Mechanisms for DNS (EDNS0)

RFC3226

DNSSEC and IPv6 DNS MSG Size Reqs

65

RFC3986

URI: Generic Syntax

RFC3493

Basic Socket API for IPv6

RFC3542

Advanced Socket API for IPv6

RFC4584

Extension to Sockets API for Mobile IPv6

RFC3678 RFC5014

Socket API Extensions Multicast Source Filters Socket API for Source Address Selection DHCPv6 Functions (If host supports DHCP, it

RFC3315 should also support DHCPv6)

(5)

Routing Protocol Requirements

IETF Routing Protocol Requirements Specification

RFC2740 RFC4552

OSPF for IPv6 Authentication/Confidentiality for OSPFv3 Use of OSI IS-IS for Routing in TCP/IP and Dual

RFC 1195 Environments RFC5187 RFC5329 RFC5838 OSPFv3 Graceful Restart Traffic Engineering Extensions to OSPF Version 3 Support of Address Families in OSPFv3 RIPng Protocol Applicability Statement RFC4271 RFC1772 RFC4760 Border Gateway Protocol 4 (BGP-4) BGP Application in the Internet BGP Multi-Protocol Extensions
66

RFC2545

BGP Multi-Protocol Extensions for IPv6 IDR BGP-MPLS IP Virtual Private Network (VPN)

RRC4659 Extension for IPv6 VPN RFC5701 RFC1772 RFC4760 RFC2545 IPv6 Address Specific BGP Extended Community Attribute BGP Application in the Internet BGP Multi-Protocol Extensions BGP Multi-Protocol Extensions for IPv6 IDR BGP-MPLS IP Virtual Private Network (VPN) RRC4659 Extension for IPv6 VPN IPv6 Address Specific BGP Extended Community RFC5701 Attribute

(6)

Transition Mechanism Requirements

IETF Specification Transition Mechanism Requirements

RFC4038 RFC4213

Application Aspects of IPv6 Transition Basic Transition Mechanisms for IPv6 Hosts and Routers

RFC4798 RFC4659 RFC3056 RFC 4380 RFC 5214

Connecting IPv6 Islands over IPv4 MPLS Using Ipv6 Provider Edge Routers (6PE) 6VPE 6to4 Teredo ISATAP describes an automatic tunneling technique for dual stack nodes which uses IPv4 network as link layer. NAT64

NAT64 (Draft)

67

DS-Lite (Draft) draft-ietf- softwiredual- stack-lite-05 RFC 2765 draft-ietfsoftwire-ipv6RFC2784 Generic Routing Encapsulation Dual Stack Lite

Stateless IP/ICMP Translation Algorithm (SIIT) 6RD

(7)

Network Management Requirements

IETF Specification Network Management Requirements Network Management Requirements

RFC3411 RFC3412 RFC3413

SNMP v3 Management Framework SNMP Message Process and Dispatch SNMP Applications Command Responder Notification Generator

RFC3414

User-based Security Model for SNMPv3

Management Information Bases

RFC4293 RFC4292 RFC4022 RFC4113 RFC4087 RFC4807 RFC4295 RFC3289

MIB for the IP MIB for the IP Forwarding Table MIB for TCP MIB for UDP MIB for IP Tunnels MIB for IPSec Policy Database Configuration MIB for Mobile IPv6 MIB for DiffServ

68

(8)

Multicasting Requirements
IETF Specification Multicasting Requirements

RFC2710

Multicast Listener Discovery (MLD) for IPv6

Source Address Selection for the Multicast RFC3590 Listener Discovery (MLD) Protocol RFC3810 RFC3306 RFC3307 RFC4607 RFC4604 RFC4601 RFC4609 RFC3956 RFC4489 RFC5059 MLD Version 2 for IPv6 Unicast-Prefix-based IPv6 Mcast Addresses Allocation Guidelines for IPv6 Mcast Addrs Source-Specific Multicast for IP MLDv2 for Source Specific Multicast (SSM) PIM Sparse Mode (SM) PIM-SM Security Issues / Enhancements Embedding Rendezvous Point (RP) Mcast Addr A Method for generating link-scoped IPv6 Multicast Address Bootstrap Router (BSR) Mechanism for PIM BiDirectional Protocol Independent Multicast (BIDIR-PIM)

RFC5015

(9)

Mobility Requirements
IETF Specification Mobility Requirements

RFC3775 RFC3963 RFC4282 RFC4283

Mobility Support in IPv6 Network Mobility (NEMO) Basic Support in IPv6 The Network Access Identifier Mobile Node Identifier option for MIPV6

69

RFC4877 RFC5213 RFC5380 RFC5555 RFC5844

MIPv6 Op with IKEv2 and Revised IPsec Architecture Proxy Mobile IPv6 Hierarchical Mobile IPv6 scheme Mobile IPv6 Support for Dual Stack Hosts and Routers IPv4 Support for Proxy Mobile IPv6

(10) Quality of Service Requirements

IETF Specification Quality of Service Requirements

RFC2474 (PS) RFC3140 (PS) RFC3168 (PS) RFC2597 (PS) RFC3246 (PS) RFC3247 (INF) RFC2475 (INF) RFC3260 (INF) RFC2983 (INF) RFC4594 (INF) RFC3086 (INF)

RFC2474 (DiffServ Header Field) RFC3140 (PHB Encoding - DiffServ) RFC3168 (Explicit Congestion Notification, ECN) RFC2597 (Assured Forwarding) RFC3246 (Expedited Forwarding) RFC3247 (Supplementary EF PHB) RFC2475 (DiffServ Architecture) RFC3260 (New Term & Clarification - DiffServ) RFC2983 (DiffServ and Tunnels) RFC4594 (Config guidelines DiffServ) RFC3086 (DiffServ per Domain Behaviour)

(11) Link Specific Requirements

IETF Specification

Link Specific Requirements

RFC2497 RFC2590 RFC3146 RFC3572

IPv6 over ARCnet IPv6 over Frame Relay IPv6 over IEEE 1394 Networks IPv6 over MAPOS (SONET/SDH)
70

RFC4338 RFC4944 RFC5072 RFC5121 RFC2507 RFC2508 RFC3173 RFC4995 RFC4996 RFC3095 RFC4815 RFC3843 RFC3241 RFC4362

IPv6, IPv4 and ARP packets over Fibre Channel IPv6 over IEEE 802.15.4 Networks IPv6 over PPP Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks IP Header Compression Compressing IP/UDP/RTP Headers for LowSpeed Serial Links IP Payload Compression Protocol (IPComp) Robust Header Compression (ROHC) framework ROHC Profile for TCP ROHC Profile for RTP,UDP, ESP and Uncomp Connections and Clarifications to RFC3095 ROHC Profile for IP Only ROHC over PPP ROHC Link Assisted for IP/UDP/RTP

71

ABBREVIATIONS
ASN.1
B2BUA BA BCE BE BLE BRR BU CN CoA Co-Reg CoT CoTI DAD De-Reg DHAAD EP FL HA HAAD HL HNP HoA HoA(from HNP) HoA(from MNP) HoT HoTI HSS HUT ICMPv6 I-CSCF IF LFN MIB MN MNP MPA MPD MPS MR MTU

Abstract Syntax Notation One

SIP Back to Back User Agent Binding Acknowlegement Binding Cache Entry Binding Error Binding Update List Entry Binding Refresh Request Binding Update Correspondent Node Care of Address Correspondent Registration Care of Test Care of Test Init Duplicate Addresss Detection De Registration Dynamic Home Agent Address Discovery SIP Endpoint Foreign Link Home Agent Home Agent Address Discovery Home Link Home Network Prefix Home Address Home Address derived from the Home Network Prefix Home Address derived from the Mobile Network Prefix Home Test Home Test Init Home Subscriber Server Host Under Test Internet Control Message Protocol for IPv6 IMS Interrogating- Call/Session Control Function Interface Local Fixed Node

Management Information Base

Mobile Node Mobile Network Prefix Mobile Prefix Advertisement Mobile Prefix Descovery Mobile Prefix Solicitation Mobile Router Maximum Transmission Unit

72

NCE NNI NUT NUT P-CSCF PDU PX Re-Reg RG RR RUT S-CSCF SMI SNMPv2C TCP TLLA TN TN TR UA UDP UE UNI VMN

Neighbor Cache Entry Network-Network Interface Node Under Test Node Under Test IMS Proxy- Call/Session Control Function

Protocol Data Unit

SIP Proxy Server Re-Registration SIP Registrar Server Return Routability Router Under Test IMS Serving- Call/Session Control Function

Structure of Management Information Simple Network Management Protocol Version 2 with Community Based Transmission Control Protocol
Target Link-layer Address Testing Node

Testing Node
Testing Router SIP User Agent

User Datagram Protocol

IMS User Equipment User-Network Interface Visited Mobile Node

73

GLOSSARY
Authentication: The process of determining whether some entity is who or what it is declared to be. Autonomous System: A collection of IP networks and routers under the control of one entity, that presents a common routing policy to the Internet, and as further defined in RFC 1930. Conformance Testing: Testing to determine if a device satisfies the criteria specified in a controlling document, such as an RFC. DISR: DoD Information Technology Standards Registry. Dual-Stack: An Internet Node capable of communicating using either or both of IPv4 and IPv6. Encryption: The process of translating a plaintext message into an encoded ciphertext message, usually accomplished using a secret key and a cryptographic cipher. Exterior Routing: Routing IP packets between Administrative Domains, or Autonomous Systems. Commonly achieved with a protocol such as the Border Gateway Protocol (BGP). Firewall: A device that acts as a barrier to prevent unauthorized or unwanted communications between sections of a computer network. Header: That portion at the beginning of a packet containing the information specific to a given protocol. Host: Any node that is not a Router. In general this profile is limited to discussions of general purpose computers, and not highly specialized devices. Integrity: Whether the transmitted information is reliable and can be trusted. Interoperability Testing: Testing to ensure that two or more communications devices can interwork and exchange data. IPv4 Address: The 32 bit address of a device, for nodes that communicate using the IPv4 protocol. IPv6 Address: The 128 bit address of a device, for Nodes that communicate using the IPv6 protocol. Interior Routing: Routing IP packets within a single Administrative Domain, or Autonomous System. Commonly achieved with a protocol such as OSPF or RIP. Multicasting: The transmission of an IP packet to a host group, a set of zero or more hosts identified by a single IP destination address. Network Protection Device: A device such as a Firewall or Intrusion Detection device that selectively blocks packet traffic based on configurable and emergent criteria. Packet Forwarding: The degenerate case of Routing where only a single outgoing link is available to forward the packet (different from the incoming link). Performance Testing: Testing to evaluate the compliance of a device to specified performance requirements. PRF: Pseudo Random Function. RFC: Request for Comments. A publication of the Internet Engineering Task Force (IETF). The basic Internet specifications are published as RFCs. Router: a Node that interconnects subnetworks by packet forwarding. 74

Tunnel: Two endpoints that communicate using an IP packet header or address space, through a network which uses another packet header or address space. This is usually achieved by encapsulating an IP packet (v4 or v6) within another IP packet (v4 or v6).

75

REFERENCES
[1] RFC1752 the Recommendation for the IP Next Generation Protocol. S. Bradner, A. Mankin. January 1995. [2] RFC1772 Application of the Border Gateway Protocol in the Internet, Y. Rekhter and P. Gross, March 1995. [3] RFC1981 Path MTU Discovery for IPv6, J. McCann, S. Deering and J. Mogul, August 1996. [4] RFC1997 BGP Communities Attribute, R. Chandra, P. Traina and T. Li, Proposed Standard, August 1996. [5] RFC2026 The Internet Standards Process -- Revision 3. S. Bradner. October 1996. [6] RFC2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. [7] RFC2185 Routing Aspects of IPv6 Transition R. Callon, D. Haskin September 1997. [8] RFC2401 Security Architecture for the Internet Protocol S. Kent, R. Atkinson November 1998. [9] RFC2402 IP Authentication Header S. Kent, R. Atkinson November 1998. [10] RFC2404 The Use of HMAC-SHA-1-96 within ESP and AH, C. Madson, R. Glenn, November 1998. [11] RFC2406 IP Encapsulating Security Payload (ESP) S. Kent, R. Atkinson November 1998. [12] RFC2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent. November 1998 [13] RFC2451 The ESP CBC-Mode Cipher Algorithms. R. Pereira, R. Adams. November 1998 [14] RFC2460 Internet Protocol Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1998. [15] RFC2464 Transmission of IPv6 Packets over Ethernet Networks M. Crawford December 1998. [16] RFC2467 Transmission of IPv6 Packets over FDDI Networks M. Crawford December 1998. [17] RFC2473 Generic Packet Tunneling in IPv6, Conta A and Deering S, December 1998. [18] RFC2474 Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers, K. Nichols, S. Blake, F. Baker, D. Black, December 1998. [19] RFC2475 An Architecture for Differentiated Service S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss December 1998. [20] RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks G. Armitage, P. Schulter, M. Jork, G. Harter January 1999. [21] RFC2492 IPv6 over ATM Networks G. Armitage, P. Schulter, M. Jork January 1999. [22] RFC2497 Transmission of IPv6 Packets over ARCnet Networks I. Souvatzis January 1999.
76

[23] RFC2507 IP Header Compression M. Degermark, B. Nordgren, S. Pink February 1999. [24] RFC2526 Reserved IPv6 Subnet Anycast Addresses, D. Johnson and S. Deering, March 1999. [25] RFC2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, P. Marques, F. Dupont, March 1999. [26] RFC2590 Transmission of IPv6 Packets over Frame Relay Networks Specification A. Conta, A. Malis, M. Mueller May 1999 [27] RFC2597 Assured Forwarding PHB Group J. Heinanen, F. Baker, W. Weiss, J. Wroclawski June 1999. [28] RFC2671 Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999 [29] RFC2675 IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. Obsoletes RFC2147 [30] RFC2711 IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999 [31] RFC2740 OSPF for IPv6, R. Coltun, D. Ferguson and J. Moy. December 1999. [32] RFC2784 Generic Routing Encapsulation (GRE) D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina March 2000 [33] RFC2918 Route Refresh Capability for BGP-4, E. Chen, Proposed Standard, September 2000. [34] RFC2983 Differentiated Services and Tunnels D. Black October 2000. [35] RFC3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification K. Nichols, B. Carpenter April 2001. [36] RFC3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng July 2001. [37] RFC3140 Per Hop Behavior Identification Codes D. Black, S. Brim, B. Carpenter, F. Le Faucheur June 2001. [38] RFC3146 Transmission of IPv6 Packets over IEEE 1394 Networks K. Fujisawa, A. Onoe October 2001 [39] RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP K. Ramakrishnan, S. Floyd, D. Black September 2001. [40] RFC3173 IP Payload Compression Protocol (IPComp) A. Shacham, B. Monsour, R. Pereira, M. Thomas September 2001. [41] RFC3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements, O. Gudmundsson, December 2001. [42] RFC3241 Robust Header Compression (ROHC) over PPP C. Bormann April 2002. [43] RFC3246 An Expedited Forwarding PHB (Per-Hop Behavior) B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis March 2002. [44] RFC3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding 77

Per-Hop Behavior) A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan March 2002. [45] RFC3260 New Terminology and Clarifications for Diffserv D. Grossman April 2002. [46] RFC3289 Management Information Base for the Differentiated Services Architecture F. Baker, K. Chan, A. Smith May 2002 [47] RFC3306 Unicast-Prefix-based IPv6 Multicast Addresses, B. Haberman, D. Thaler, August 2002 [48] RFC3307 Allocation Guidelines for IPv6 Multicast Addresses, B. Haberman, August 2002 [49] RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), R. Droms. Ed, J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney, July 2003. [50] RFC3392 Capabilities Advertisement with BGP-4, R. Chandra, J. Scudder, Draft Standard November 2002. [51] RFC3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. December 2002. [52] RFC3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case, D. Harrington, R. Presuhn, B. Wijnen December 2002 [53] RFC3413 SNMP Applications, D. Levi, P. Meyer and B. Stewart, Standard, December 2002. [54] RFC3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. December 2002. [55] RFC3484 Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves . February 2003 [56] RFC3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. [57] RFC3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). T. Kivinen, M. Kojo . May 2003 [58] RFC3542 Advanced Sockets Application Program Interface (API) for IPv6. W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. May 2003. [59] RFC3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec S. Frankel, H. Herbert September 2003. [60] RFC3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH) T. Ogura, M. Maruyama, T. Yoshida July 2003 [61] RFC3596 DNS Extensions to Support IP Version 6. S. Thomson, C. Huitema, V. Ksinant, M. Souissi. October 2003. [62] RFC3602 The AES-CBC Cipher Algorithm and Its Use with IPsec. S. Frankel, R. Glenn, S. Kelly. September 2003 [63] RFC3633 IPv6 Prefix options for Dynamic Host Configuration Protocol (DHCP) version 6, O. Troan and R. Droms, December 2003. [64] RFC3678 Socket Interface Extensions for Multicast Source Filters. D. Thaler, B. Fenner, B. Quinn.
78

January 2004. [65] RFC3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP). R. Housley. January 2004 [66] RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. [67] RFC3750 Unmanaged Networks IPv6 Transition Scenarios C. Huitema, R. Austein, S. Satapati, R. van der Pol April 2004 [68] RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats P. Nikander, Ed., J. Kempf, E. Nordmark May 2004 [69] RFC3775 Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. [70] RFC3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed.. June 2004. [71] RFC3843 RObust Header Compression (ROHC): A Compression Profile for IP L-E. Jonsson, G. Pelletier June 2004. [72] RFC3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. September 2004. [73] RFC3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks C. Huitema, R. Austein, S. Satapati, R. van der Pol September 2004. [74] RFC3948 UDP Encapsulation of IPsec ESP Packets. A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg. January 2005. [75] RFC3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address, P. Savola, B. Haberman November 2004. [76] RFC3963 Network Mobility (NEMO) Basic Support Protocol V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert January 2005 [77] RFC3971 SEcure Neighbor Discovery, J. Arkko (ed), J. Kempf, B. Zill, P. Nikander, March 2005. [78] RFC3972 Cryptographically Generated Addresses (CGA). T. Aura. March 2005 [79] RFC3986 Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. January 2005. [80] RFC4007 IPv6 Scoped Address Architecture, S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, March 2005. [81] RFC4022 Management Information Base for the Transmission Control Protocol (TCP) R. Raghunarayan, Ed. March 2005 [82] RFC4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks, M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola, March 2005. [83] RFC4038 Application Aspects of IPv6 Transition M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro March 2005. [84] RFC4057 IPv6 Enterprise Network Scenarios J. Bound, Ed. June
79

2005. [85] RFC4087 IP Tunnel MIB D. Thaler June 2005. [86] RFC4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP). J. Viega, D. McGrew. June 2005. [87] RFC4113 Management Information Base for the User Datagram Protocol (UDP) B. Fenner, J. Flick June 2005 [88] RFC4191 Default Router Preferences and More-Specific Routes. R. Draves, D. Thaler. November 2005 [89] RFC4193 Unique Local IPv6 Unicast Addresses, R. Hinden and B. Haberman, October 2005. [90] RFC4213 Basic Transition Mechanisms for IPv6 Hosts and Routers, E. Nordmark and R. Gilligan, October 2005. [91] RFC4271 A Border Gateway Protocol 4 (BGP-4), Y. Rekhter (ed), T. Li, S. Hares, January 2006. [92] RFC4282 The Network Access Identifier B. Aboba, M. Beadles, J. Arkko, P. Erone December 2005 [93] RFC4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6) A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury November 2005 [94] RFC4291 IP Version 6 Addressing Architecture, R. Hinden, S. Deering, February 2006. [95] RFC4292 IP Forwarding Table MIB B. Haberman April 2006 [96] RFC4293 Management Information Base for the Internet Protocol, S. Routhier (ed), April 2006. [97] RFC4294 IPv6 Node Requirements, Informational, J. Loughney (ed), April 2006. [98] RFC4295 Mobile IPv6 Management Information Base G. Keeni, K. Koide, K. Nagami, S. Gundavelli April 2006. [99] RFC4301 Security Architecture for the Internet Protocol, S. Kent and K. Seo, December 2005. [100] RFC4302 IP Authentication Header, S. Kent, December 2005. [101] RFC4303 IP Encapsulating Security Payload (ESP), S. Kent, December 2005. [102] RFC4306 Internet Key Exchange (IKEv2) Protocol, C. Kaufman (ed), December 2005. [103] RFC4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2). J. Schiller. December 2005. [104] RFC4308 Cryptographic Suites for IPsec, P. Hoffman, December 2005. [105] RFC4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP). R. Housley December 2005.
80

[106] RFC4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel C. DeSanti, C. Carlson, R. Nixon January 2006 [107] RFC4360 BGP Extended Communities Attribute, S. Sangli, D. Tappan, Y. Rekhter, February 2006. [108] RFC4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). T. Lemon, B. Sommerfeld. February 2006. [109] RFC4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson, G. Pelletier, K. Sandlund January 2006 [110] RFC4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman February 2006. [111] RFC4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, A. Conta, S. Deering, M. Gupta (ed), March 2006. [112] RFC4472 Operational Considerations and Issues with IPv6 DNS A. Durand, J. Ihren, P. Savola April 2006 [113] RFC4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH. D. McGrew, J. Viega. May 2006. [114] RFC4552 Authentication/Confidentiality for OSPFv3. M. Gupta, N. Melam. June 2006. [115] RFC4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks T. Chown June 2006. [116] RFC4581 Cryptographically Generated Addresses (CGA) Extension Field Format. Bagnulo, J. Arkko. October 2006. [117] RFC4584 Extension to Sockets API for Mobile IPv6. S. Chakrabarti, E. Nordmark. July 2006. [118] RFC4594 Configuration Guidelines for DiffServ Service Classes J. Babiarz, K. Chan, F. Baker August 2006 [119] RFC4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner, M. Handley, H. Holbrook, I. Kouvelas August 2006 [120] RFC4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast. H. Holbrook, B. Cain, B. Haberman. August 2006. [121] RFC4607 Source-Specific Multicast for IP H. Holbrook, B. Cain August 2006. [122] RFC4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements P. Savola, R. Lehtonen, D. Meyer October 2006. [123] RFC4718 IKEv2 Clarifications and Implementation Guidelines P. Eronen, P. Hoffman October 2006. [124] RFC4760 Dual Stack Multiprotocol BGP, T. Bates, R. Chandra, D. Katz, Y. Rekhter, January 2007.
81

[125] RFC4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE), J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur, February 2007. [126] RFC4807 IPsec Security Policy Database Configuration MIB M. Baer, R. Charlet, W. Hardaker, R. Story, C. Wang March 2007 [127] RFC4809 Requirements for an IPsec Certificate Management Profile, C. Bonatti, S. Turner, G. Lebovitz, February 2007. [128] RFC4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 L- E. Jonsson, K. Sandlund, G. Pelletier, P. Kremer February 2007. [129] RFC4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). V. Manral, April 2007. [130] RFC4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green April 2007 [131] RFC4861 Neighbor Discovery for IP version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson, H. Soliman. September 2007. Obsoletes RFC2461. [132] RFC4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei September 2007. Obsoletes RFC2462. [133] RFC4864 Local Network Protection for IPv6 G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein May 2007 [134] RFC4868 Using HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 with IPsec, S. Kelly and S. Frankel, May 2007. [135] RFC4869 Suite B Cryptographic Suites for IPsec, L.Law, J. Solinas, April 2007. [136] RFC4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture. V. Devarapalli, F. Dupont. April 2007 [137] RFC4884 Extended ICMP to Support Multi-Part Messages. R. Bonica, D. Gan, D. Tappan, C. Pignataro. April 2007. Updates RFC792, RFC4443, Errata [138] RFC4891 Using IPsec to Secure IPv6 in IPv4 Tunnels, R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig, May 2007. [139] RFC4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. [140] RFC4942 IPv6 Transition/Co-existence Security Considerations E. Davies, S. Krishnan, P. Savola September 2007 [141] RFC4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks G. Montenegro, N. Kushalnagar, J. Hui, D. Culler September 2007. [142] RFC4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2 and PKIX, B. Korver, August 2007.

82

[143] RFC4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs). M. Bagnulo, J. Arkko. July 2007. [144] RFC4995 The RObust Header Compression (ROHC) Framework L-E. Jonsson, G. Pelletier, K. Sandlund July 2007. [145] RFC4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier, K. Sandlund, L-E. Jonsson, M. West July 2007. [146] RFC5014 IPv6 Socket API for Source Address Selection. E. Nordmark, S. Chakrabarti, J. Laganier. September 2007. [147] RFC5075 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. November 2007 [148] RFC5095 Deprecation of Type 0 Routing Headers in IPv6. J. Abley, P. Savola, G. NevilleNeil. December 2007. [149] RFC5175 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. March 2008. [150] RFC5114 Additional Diffie-Hellman Groups for Use with IETF Standards S. Kent January 2008. [151] IPv6 Ready Logo Program. IPv6 Forum. 2010. [152] ETSI TC MTS-IPT: IPv6 Testing and eEurope Project, http://www.ipt.etsi.org/. [153] Go4IT: Advanced Tools and Services for IPv6 Testing, http://www.go4-it.eu/. [154] TAHI Project, Test and Verification for IPv6, http://www.tahi.org/.

83