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

2

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

3

Chapter-1

Introduction and Scope

4

designed as the successor to IP version 4 (IPv4). 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. to support more levels of addressing hierarchy. 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. a) b) c) d) e) 2. “real Authentication and privacy capabilities Extensions to support authentication. such as non-default flows” non quality of service or “real-time” service. The changes from IPv4 to IPv6 primarily fall into the following categories. a much greater number of addressable nodes and simpler autoauto configuration of the addresses. and greater flexibility for introducing new options in the future.CHAPTER-1 Introduction and Scope 1. Improved support for Extensions and options Changes in the way IP header options are encoded allows for more efficient forwarding. Introduction Internet Protocol version 6 (IPv6) is the new version of the Internet Protocol. IPv4 and IPv6 Addresses 5 . Expanded Addressing Abilities IPv6 increases the IP address size from 32 bits to 128 bits. data integrity and data confidentiality are specified for IPv6. less stringent limits on the length of options.

OSPF) instead. Packets consist of control information for addressing and routing. 6 . IPv6 Packets An IPv6 packet is the smallest message entity exchanged via the Internet Protocol across an Internet Protocol version 6 (IPv6) network.3. but may be data for an Internet Layer (e. ICMPv6) or Link Layer (e. All other information is carried through extension headers.g. The control information in IPv6 packets is subdivided into a mandatory fixed header and optional extension headers. 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. IPv6 packet headers contain many of the fields found in IPv4 packet headers.Indicates the version of the Internet Protocol. The payload of an IPv6 packet is typically a datagram or segment of the higher-level Transport Layer protocol.1 Header Comparison . some of these fields differ from IPv4. as they do for IPv4.g. 4. Hosts may use fragmentation to send packets larger than the observed path MTU.2 Fixed Header IPv4 has a variable header but in IPv6 the main header is fixed size of 40 bytes (320 bits).The comparison of headers in IPv4 and IPv6 is given below. The 40-byte IPv6 header consists of the following eight fields: (i) Version (4) . and a payload consisting of user data. Hosts are required to implement path MTU discovery to take advantage of MTUs greater than the smallest MTU of 1280 octets. 4. Routers do not fragment IPv6 packets... IPv6 packets are typically transmitted over a Link Layer protocol. IPv4 & IPv6 Headers 4.

Identifies the final destination node address for the packet. UDP header. extension headers are used to encode optional Internet-layer information. (v) Next header (8) .Previously the total length field in IPv4. These are covered in specific IETF RFCs not within the scope of this document. 7 . packet flows requiring a specific class of service [CoS]). 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. Government agencies. If there are no more extension headers.Identifies the address of the source node sending the packet. (ii) 4. the payload length field specifies the length of the IPv6 payload. ICMPv6 header. the traffic class field defines the class-of-service (CoS) priority of the packet. the semantics for this field (for example.Previously the protocol field in IPv4. The next header field. (vi) Hop limit (8) . Extension headers are placed between the IPv6 header and the upper-layer header in a packet. the Next Header field indicates the next extension header to examine. 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.The flow label identifies all packets belonging to a specific flow (that is. (viii) Destination address (128) . 5. Therefore. the hop limit indicates the maximum number of hops allowed. Scope of the Document a. This document is primarily based on the requirements specified by the IPv6 Forum. (iii) Flow label (20) . 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. diffserv code points) are identical to IPv4. b. IPv6 allows you to chain extension headers together by using the next header field. d. This document does not give details on transition strategies for moving from IPv4 based networks to IPv6 based networks. an encapsulated IP packet.Traffic class (8) . (iv) Payload length (16) . c.Previously the time-to-live (TTL) field in IPv4. the next header field indicates the upper-layer header (TCP header.3 Extension Headers In IPv6. routers can identify these packets and handle them in a similar fashion. (vii) Source address (128) . located in the IPv6 header. 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). However. interoperability will be a critical feature of IPv6 based networking equipments. or other items). These IETF specifications are given below which address issues in specific deployment and transition scenarios for Enterprise and ISPs. a large number of implementations are possible due to variations in interpretation. e. indicates to the router which extension header to expect next.Previously the type-of-service (ToS) field in IPv4.

Interoperation with IPv4 Infrastructure: [RFC4038] Application Aspects of IPv6 Transition [RFC4213] Basic Transition Mechanisms for IPv6 Hosts and Routers iv.IP Layer 3 Focus [RFC3750] Unmanaged Networks IPv6 Transition Scenarios [RFC3904] Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks ii.i. ISPs and Transit Network Infrastructure: [RFC4029] Scenarios and Analysis for Introducing IPv6 into ISP Networks [RFC2185] Routing Aspects of IPv6 Transition iii. Enterprise Networks: [RFC4057] IPv6 Enterprise Network Scenarios [RFC4852] IPv6 Enterprise Network Analysis . Security Issues: [RFC4942] IPv6 Transition/Co-existence Security Considerations [RFC4864] Local Network Protection for IPv6 8 .

A 2.B Core Protocols for IPv6 Conformance Core Protocols for IPv6 Interoperability 9 . Title 2.Chapter-2 Functional Requirements Chapter No.

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

and the Option Type and Option Data Length fields in IPv6 options. a node should generate the proper ICMPv6 message in response to invalid or unknown fields. The following are described in RFC 4861 11 . On any link that cannot convey a 1280-octetpacket in one piece. (ii) (iii) Fragmentation IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. Next Header. process stub fragments. nodes use the protocol to actively keep track of neighbors that are reachable and those that are not. and the effects of IPv6 on upper-layer protocols.3. a host actively searches for functioning alternates.0 Core Protocols for IPv6 Conformance (RFC4861) RFC4861 cover the Neighbor Discovery Specification for Internet Protocol version 6. (i) IPv6 Header Verify that a node properly processes and generates the Version. These descriptions will verify the readiness of an IPv6 implementation vis-à-vis the Neighbor Discovery specification. Destination Options. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf. and many extension headers or options in a single packet. Payload Length. particularly the Hop-by-Hop Options. The node should also generate the proper ICMPv6 messages. Verify that a node transmits the appropriate ICMPv6 Parameter Problem messages in response to invalid or unknown fields. 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. and Hop Limit fields in the IPv6 header. The node should properly time out fragment reassembly. It also discusses packet size issues. Flow Label.0 Core Protocols for IPv6 Conformance (RFC2460) The base specification specifies the basic IPv6 header and the initially defined IPv6 extension headers and options. In addition. 4. abandon reassembly on packets that exceed a maximum size. linkspecific fragmentation and reassembly must be provided at a layer below IPv6. The node should also correctly process header options in order. and Routing headers. the semantics of flow labels and traffic classes. A node should properly process and generate the Header Extension Length field in extension headers. Extension Headers and Options The descriptions cover the processing of options and extension headers. When a router or the path to a router fails. packets with a routing header destined for the node. and reassemble overlapping fragments. Traffic Class. These are the essential requirements specified under IPv6 Ready Logo Programme Phase-I of the IPv6 Forum. Finally.

0 Core Protocols for IPv6 Conformance (RFC4443) It describes the format of a set of control messages used in ICMPv6. the process for generating site-local and global addresses via stateless address autoconfiguration. These descriptions gives details on the process for generating a link-local address. 12 . 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. It does not describe the procedures for using these messages to achieve functions like Path MTU discovery. Upon receipt of such a message. and the Duplicate Address Detection procedure. The following are described in RFC 4862.0 Core Protocols for IPv6 Conformance (RFC4862) The following descriptions cover the IPv6 Stateless Address Autoconfiguration specification. The Path MTU Discovery process ends when the nodes’s estimate of the PMTU is less than or equal to the actual PMTU. The Path MTU Discovery protocol is a technique to dynamically discover the PMTU of a path. these procedures are described in other documents. 7.(i) (ii) (iii) Router and Prefix Discovery Address Resolution and Neighbor Unreachability Detection Redirect Function 5. that node will discard them and return ICMPv6 Packet Too Big messages. The following also verify that a host correctly processes a Router Advertisement and correctly assigns lifetimes.0 Core Protocols for IPv6 Conformance (RFC1981) The descriptions cover the Path MTU Discovery for IP version 6. If any of the packets sent on the path are too large to be forwarded by some node along the path. (i) (ii) Address Autoconfiguration and Duplicate Address Detection Router Advertisement Processing and Address Lifetime 6. 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.

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 4862 September 2007. Interoperability has always been considered as a critical feature in the Internet community. [IPv6-ARCH] 13 . Internet Protocol. o Ability to transmit Router Advertisements with a positive AdvDefaultLifetime. o If the device is a Special Device and it does not support configuring the automatically.CHAPTER-2. it is important to provide the market a strong signal proving the level of interoperability across various products. February 2006. Version 6 Addressing Architecture. RFC 4291. 3. Router o Ability to transmit Router Advertisements with a positive AdvValidLifetime. o If the device is a Special Device and it does not support setting the default router automatically. 2. the device must have the ability to set the Reference Router’s address as default router manually. RFC 4443. the device must have the ability to assign an address on the attached interface manually.0 General Node Requirements Host o Ability to configure a global address and default router by receipt of Router Advertisement.0 Relevant References [ADDRCONF] [ICMPv6] IPv6 Stateless Address Autoconfiguration.B (Core Protocols for IPv6 Interoperability) 1. the universality of IPv6 leads to a huge number of implementations.0 IPv6 Interoperability Specification Contrary to IPv4. Due to the large number of IPv6 implementations. The following specifications give the essential requirements for interoperability of diverse IPv6 products with each other. which started with a small closed group of implementers. o Ability to show multicast ping result indicating the receipt of each ICMPv6 Echo Reply. March 2006. Host and Router o Ability to use a ping6 application and print out results indicating the receipt of an ICMPv6 Echo Reply.

July 1994. RFC 1981. RFC 2460. RFC 5095.To verify that a successful ICMPv6 Echo Request. A tentative address that is determined to be a 14 (ii) . RFC 854. To ensure that all configured addresses are likely to be unique on a given link. 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. it performs stateless address autoconfiguration and Duplicate Address Detection. July 1992 Hypertext Transfer Protocol – HTTP/1. Address Autoconfiguration and Duplicate Address Detection . RFC 2710. RFC 959. When a host initializes on a given link.[IPv6-SPEC] Internet Protocol. for diagnostic purposes. October 1985. The source address of the reply MUST be a unicast address belonging to the interface on which the multicast Echo Request message was received. December 1998. TCP Extensions for Transactions Functional Specification. RFC 4861. The Duplicate Address Detection algorithm is performed on all addresses. In addition. An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast address.link partners. [RFC-5095] Deprecation of Type 0 Routing Headers in IPv6. Path MTU Discovery for IPv6. File Transfer Protocol (FTP). August 1996. routers perform Duplicate Address Detection on all addresses prior to assigning them to an interface. June 1999.To verify that a device can properly initialize on a network and communicate with other on. RFC 1644. RFC 1350.1. TFTP Protocol (Revision 2). December 2007 Multicast Listener Discovery (MLD) for IPv6. October 1999. TELNET Protocol Specification. September 2007. A node should also implement an applicationlayer interface for sending Echo Requests and receiving Echo Replies. independent of whether they are obtained via stateless or stateful autoconfiguration. hosts run the Duplicate Address Detection algorithm on addresses before assigning them to an interface. [MLD] [T/TCP] [FTP] [TELNET] [TFTP] [HTTP] 4. Version 6 (IPv6) Specification. Every node must Echo Reply exchange can be achieved in two directions. May 1983. implement an ICMPv6 Echo responder function that receives Echo Requests and sends corresponding Echo Replies.0 IPv6 Core Protocol and ICMPv6 Interoperability (i) ICMPv6 Echo Interoperability . [ND] [PMTU] Neighbor Discovery for IP Version 6 (IPv6).

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

A 3.I 3.K 3.T 3.U 3. 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 .M 3.Q 3.E 3.G 3.H 3.F 3.D 3.Chapter-3 Additional Specifications for Specific Protocols for Conformance and Interoperability Chapter Title 3.C 3.O 3.N 3.S 3.B 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).J 3.P 3.V 3.L 3.R 3.

It also provides a central database for keeping track of computers that have been connected to the network. particularly the IP addresses of local caching DNS resolvers. While both versions bear the same name and perform much the same purpose. The following tests will tell if the NUT supports the ADVANCED functions. Hosts that do not use DHCP for address configuration may still use it to obtain other configuration information. one for IPv4 and one for IPv6. DHCP also provides other configuration information. hosts may be manually configured with an IP address. and is on the same link as the client. This conformance specification consists mainly of four ADVANCED functions. (ii) c) DHCP relay agent (or relay agent): A node that acts as an intermediary to deliver DHCP messages between clients and servers. IPv4 hosts may use linklocal addressing to achieve limited local connectivity. and may or may not be on the same link as the client(s).CHAPTER-3. eliminating the need for intervention by a network administrator. This prevents two computers from accidentally being configured with the same IP address. Computers that are connected to IP networks must be configured before they can communicate with other computers on the network. 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. 17 . Alternatively IPv6 hosts may use stateless address autoconfiguration to generate an IP address.A DHCPv6 Conformance Specifications 1. In addition to IP addresses. In the absence of DHCP. the details of the protocol for IPv4 and IPv6 are sufficiently different that they can be considered separate protocols. DHCP allows a computer to be configured automatically. Introduction (i) The Dynamic Host Configuration Protocol (DHCP) is an auto configuration protocol used on IP networks. b) DHCP server (or server): A node that responds to requests from clients. There are two versions of DHCP.

DNS configuration in parallel with Address Assignment for Client device. Server Basic Behaviors. Advanced Functionality Tests Adv-1 Adv-2 Adv-3 Adv-4 Adv-5 References RFC3315 RFC3315+RFC3646 RFC3736 RFC3633 RFC3633+RFC3646 2. Client Message Reception The tests focus on the client’s implementation of DHCPv6 and the reception of valid and invalid DHCPv6 messages by a server device.Prefix Delegation for Requesting router (Client) device. 3. 3. The scope of the tests includes major functionality groups such as client behavior in client-initiated configuration exchange.1. 2. The scope of the tests includes major functionality groups such as server behavior in client-initiated configuration exchange. Client Basic Behaviors. Constants and Format The tests focus on the DHCP Basic behaviors.1. constants and format. Constants and Format Focus on the DHCP Basic Behaviors. client behavior in server-initiated configuration exchange.DNS configuration in parallel with Prefix Delegation for Requesting router (Client) device. Relay agent device b) Adv2. and message validation by client. server behavior in s e r v e r initiated configuration exchange and m e s s a g e validation by server. Server device. for Server device. constants and format. RFC 3315 .Server Specification It covers specifications for the server implementation of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Client Message Transmission The tests focus on the Client message creation.2. client behavior in server solicitation.Stateless DHCPv6 for DNS configuration for Client device. transmission and termination of DHCP IPv6 exchanges. for Relay agent device c) Adv3. 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. for Relay agent device d) Adv4.2. Server Message Transmission 18 . 2.Client Specification It covers the specifications for the client implementation of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).a) Adv1. 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. for Server device. for Delegating router (Server) device e) Adv5. 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. for Delegating router (Server) device.Address assignment for Client device. RFC 3315 . 2. 3.

Client Specification It covers specifications for the client implementation of the Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). 19 . RFC 3646 . 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 Stateless Dynamic Host Configuration Protocol for IPv6 specification (Focus on DNS recursive name servers and Domain search list option). They verify the readiness of a DHCPv6 client implementation vis-à-vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification. RFC 3646 . They implementation vis-à-vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification (Other configuration information function concurrently processing Address Assignment).Focus on the Server message creation. These tests verify the readiness of a DHCPv6 Relay agent implementation vis-à-vis base specifications of the Dynamic Host Configuration Protocol for IPv6. These tests verify the process for relaying specific messages regarding Address Assignment. 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. 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.3.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. 3. 4. 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). Server Message Reception Focus on the server’s implementation of DHCPv6 and the reception of valid and invalid DHCPv6 messages by a client device. RFC 3646 . RFC 3315 . 5. 6.Server Specification It covers specifications for the sever implementation of the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). transmission and termination of DHCP IPv6 exchanges.Relay Agent Specification It covers specifications for the relay agent implementation of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). RFC 3736 .Client Specification It covers specifications for the client implementation of the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). 7. 8.

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).1. The tests verify the process for receiving a list of available IPv6 Prefix options from a server in Dynamic Host Configuration Protocol for IPv6. The tests verify the process for transmitting a list of available IPv6 Prefix options from a server in Dynamic Host Configuration Protocol for IPv6. RFC 3736 . 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. transmission and termination of DHCP IPv6 exchanges. 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.2. Client Message Transmission The tests focus on the Requesting router (Client) message creation.9. 11. 11. Message Reception The tests focus on the requesting route’s (Client) implementation of DHCPv6 and the reception of valid and invalid DHCPv6 messages by a server device. constants and format.Server Specification It covers specifications for the server implementation of the Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Constants and Format The tests focus on the DHCP Basic behaviors.Relay Agent Specification It covers specifications for the Relay agent implementation of the Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). 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). RFC 3736 . 10. 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. 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 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. 12. 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. 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 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 Basic Behaviors. 20 .3. 11.

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. 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). Message Reception The tests focus on the requesting router’s implementation of DHCPv6 and the reception of valid and invalid DHCPv6 messages by a delegating router device. 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.2. 12. 13. Constants and Format The tests focus on the DHCP Basic Behaviors. 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).3. They verify the readiness of a Delegating Router (Server) implementation vis-à-vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification. transmission and termination of DHCP IPv6 exchanges. 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 DHCPv6 Requesting Router (client) implementation vis-à-vis the DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 specification. 12. Delegating Router (Server) Basic Behaviors. Server Message Transmission The tests focus on the delegating router message creation.12. constants and format. 21 . 14.1.

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. Must be tested against 2 Clients and 2 Relay-Agents 3.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. Interoperable device requirement: Each applicant must be tested against other devices according to the following (All Vendors MUST be different): 1. Must be tested against: 2 Clients. the vendor in each device 22 . 2. and 2 Relay-Agents b. Server Application a. and may or may not be on the same link as the client(s). and is on the same link as the client. c) DHCP server (or server): A node that responds to requests from clients. Introduction . Relay-Agent Application a. Must be tested against 2 Servers and 2 Relay-Agents 2. Client Application a. 4 Different vendors are required. 2 Servers. 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.B DHCPv6 Interoperability Specifications 1. Advanced Functionality .CHAPTER-3.

RFC 3315 To verify the readiness of DHCPv6 client.type must be different. Delegating Router Application a. server and relay agent interoperability visà-vis the base specifications of the Dynamic Host Configuration Protocol for IPv6. 4. 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. Requesting Router Application a. Must be tested against 2 Requesting Routers 4. 6. 7. RFC 3633 + RFC 3646 To cover basic interoperability of the IPv6 Prefix Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6-PD). Must be tested against 2 Delegating Routers 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. It relates to DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3646. 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 3736 To verify the readiness of DHCPv6 client and server interoperability vis-à-vis the specifications of the Stateless Dynamic Host Configuration Protocol for IPv6. 5. 23 .

it must pass all the Tunnel mode tests. SGW (Security Gateway) .r. If the NUT supports the Tunnel mode. IPSec– "The Use of HMAC-SHA-1-96 within ESP andAH". between a pair of security gateways (network-tonetwork). November 1998.CHAPTER-3. End Node .t. it must pass all the Transport mode tests. RFC2404 November 1998. (ii) 2. RFC 2451.0 Related References The following RFCs are required to be complied w..e.If the NUT is an End-Node. (i. September 2003. Host and Router can be an End-Node. 24 .A node which can provide IPsec tunnel mode for nodes behind it. "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec".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. RFC 2410. Mode .A node which can use IPsec only for itself. A Node Under Test (NUT) is required to satisfy following requirements. 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. RFC2410 RFC2451 RFC3566 RFC3602 "The NULL Encryption Algorithm and Its Use With IPsec".If the NUT is a SGW. RFC 2404. (ii) Security Protocol . "The ESP CBC-Mode Cipher Algorithms". b. (iii) a. It can be used in protecting data flows between a pair of hosts (host-to-host). (i) Equipment Type – A NUT can be of following 2 types – a. Tunnel mode is ADVANCED functionality for End-Node) b. RFC 3566. IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite.C IPsec (Internet Protocol Security) 1.The mode requirement depends on the type of NUT. SGW . End-Node . "The AES-CBC Cipher Algorithm and Its Use with IPsec". it also must pass all the Tunnel mode tests. or between a security gateway and a host (network-to-host). November 1998. Router can be a SGW.A NUT is required to pass all of the ESP tests regardless of the equipment type.

RFC 4312. September 2003. must pass all corresponding tests. AES-XCBC-MAC-96 b. HMAC-SHA1 ADVANCED ALGORITHMS: a.0 Authentication Algorithms IPv6 Forum has defined BASE ALGORITHM and ADVANCED ALGORITHM. which support the algorithms that are listed as ADVANCED ALGORITHM. HMAC-SHA-256 25 . (i) (ii) BASE ALGORITHM: a. RFC 3686. January 2004. NULL d. December 2005. AES-CTR c. "The Camellia Cipher Algorithm andIts Use With IPsec". December 2005. 4. December 2005. March 2006. December 2005. HMAC-SHA-384. "IP Encapsulating Security Payload (ESP)". 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. All NUTs have to pass all the tests of BASE ALGORITHM to confirm to the specifications. AES-CBC b. NULL c. RFC 4443. have to pass all the corresponding tests. The NUTs.RFC 3602. RFC 4301. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification". RFC4868. "Security Architecture for the Internet Protocol". A NUT which supports algorithms listed as ADVANCED ALGORITHM. RFC 4305. RFC 4303. RFC3686 "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)". and HMACSHA-512 with IPsec”. CAMELLIA-CBC ll NUTs must pass the BASE ALGORITHM tests to confirm to specifications given by the IPv6 Forum. 3DES-CBC ADVANCED ALGORITHM a. The algorithm requirement is independent from NUT type. May 2007. "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The algorithm requirement is independent from NUT type. “Using HMAC-SHA-256.

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.The following interoperability conditions required to be fulfilled.0 Required Tests The following table describes which tests are required for interoperability Focused Interface Test Device Type 26 .CHAPTER-3.0 Interoperable device requirement . 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.D IPsec Interoperability Specifications 1.

N/A 256 27 . 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.End-Node End-Node vs.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.

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 .

December. December. October. 2005.Internet Key Exchange (IKEv2) Protocol.0 The Following RFCs have to be complied • • RFC 4306 . 2005 RFC 4718 .IKEv2 Clarifications and Implementation Guidelines.Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2). RFC 4307 . 2006 • 33 .2.

SGW (Security Gateway): A node who can provide IKEv2 (IPsec tunnel mode) for nodes behind it.CHAPTER-3. 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. Router can be a SGW Function List (Basic/Advanced Functionality table) . the target device must satisfy all of the following requirements. (i) (ii) Equipment Type .F IKEv2 Interoperability 1. 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 . End-Node: . ADVANCED is required for all target devices which support ADVANCED function. Host and Router can be an End-Node b. Parameter BASIC Initial Exchanges (IKE_INIT.0 Introduction To pass the tests for IKEv2 interoperability.There are two possibilities for equipment types: a.A node who can use IKEv2 (IPsec transport mode and tunnel mode) only for itself.This interoperability test scenario consists following BASIC/ADVANCED functions.

RFC 4718. [Clarif] "IKEv2 Clarifications and Implementation Guidelines".0 Related References The following documents are referenced: [IKEV2] "Internet Key Exchange (IKEv2) Protocol". [RFC4307] "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)". RFC 4307. 35 .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. October 2006. RFC 4306. December 2005. December 2005.

and the appropriate netmask and default router.org/about_phase2_test.org/about_phase2_test. (i) RFC3775: Mobility Support in IPv6 (http://www. Routing mechanisms rely on the assumption that each network node will always have the same point of attachment to the Internet. routing protocols have no means of delivering datagram (packets).html) 36 .org/rfc/rfc3776.ipv6ready.org/rfc/rfc3775. When connecting through a foreign network. 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.0 Introduction Mobile IPv6 (MIPv6) is a protocol developed as a subset of Internet Protocol version 6 (IPv6) to support mobile connections. Otherwise.ietf. In this routing scheme. 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.ipv6ready. MIPv6 allows a mobile node to transparently maintain connections while moving from one subnet to another. because the device's network address doesn't contain the necessary information about the node's network point of attachment to the Internet.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). if you disconnect a mobile device from the Internet and want to reconnect through a different network.txt) (iii)IPv6 Ready Logo Phase-2 Mobile IPv6 Policy (http://www.html) (iv) IPv6 Ready Logo Phase-2 Mobile IPv6 Test Specification Profile (http://www. The following describes the specifications for Mobile IPv6 self test for a correspondent node (CN) 2. IP addresses represent a topology. and that each node's IP address identifies the network link where it is connected. In traditional IP routing.ietf. you have to configure the device with a new IP address.CHAPTER-3. 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. They are listed below.txt) (ii) RFC3776: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (http://www.G MIPv6 Self Test Specification for CN 1.

ietf.H MIPv6 Self Test Specification for HA 1.ipv6ready.org/rfc/rfc3776.org/rfc/rfc4877.org/rfc/rfc3775. 2.Chapter-3.org/about_phase2_test.ipv6ready.0 Introduction The following describes the specifications for the Home Agent (HA).ietf.txt) (iv) IPv6 Ready Logo Phase-2 Mobile IPv6 Policy (http://www.txt) (ii) RFC3776: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (http://www.html) 37 .txt) (iii)RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (http://www. (i) RFC3775: Mobility Support in IPv6 (http://www. These are listed below.html) (v) IPv6 Ready Logo Phase-2 Mobile IPv6 Test Specification Profile (http://www.ietf.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).org/about_phase2_test.

in the form of Correspondent Nodes (CNs).org/rfc/rfc4877.txt) RFC3776: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes (ii) and Home Agents (http://www.I MIPv6 Interoperability Test Specification 1. (i) RFC3775: Mobility Support in IPv6 (http://www.txt) (iv) Guidelines for Implementation (v) IPv6 Ready Logo Phase 2 Policy 38 . Home Agents (HAs).ietf.CHAPTER-3. and Mobile Nodes (MNs).txt) RFC4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (iii) (http://www.ietf.0 Reference standards This documentation covers the functions specified in the IETF RFC and Mobile IPv6 Test Profile listed below.0 Introduction This document describes test scenarios to verify the interoperability between Mobile IPv6 equipment.org/rfc/rfc3776.org/rfc/rfc3775.ietf. 2.

J MIPv6 Conformance MN Specification 1.CHAPTER-3. (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 . These are specified in RFC3775 (Mobility Support in IPv6).0 For MIPv6 conformance of the mobile node. the following have to be complied for the Mobile Node (MN) Operation.

and to inform itself and other neighboring multicast routers of its listening state on the other hand. and Group-and-Source Specific Queries. Note that a multicast router may itself be a listener of one or more multicast addresses. the Group Membership Interval. Finally. Max Response Code. Querier Election. The following describes the router Conformance specifications for MLDv2 (Multicast Listener Discovery Version 2. Reserved. 5. 4. verify Additional Data. (ii) [SSM] . Query transmission. RFC 3810. and that the Router properly handles unrecognized codes. validates the checksum. 40 . in this case it performs both the "multicast router part" and the "multicast address listener part" of the protocol. Also verify that the MLDv2 Router validates the IP Destination. and Querier’s Query Interval Code fields. 2. 3. the Other Querier Present Interval. These functionalities include value configuration. These values include the Robustness Variable.Multicast Listener Discovery Version 2 (MLDv2) for IPv6. GroupSpecific Queries.Using Internet Group Management Protocol Version 3 (IGMPV3) and Multicast Listener Discovery Protocol 2 (MLDv2) for Source-Specific Multicast. Also verify that timer expiration is handled correctly. Group Address.CHAPTER-3.. and to discover specifically which multicast addresses are of interest to those neighboring nodes.0 Basic Functionality To verify that the basic MLDv2 router functionalities are performed correctly on the RUT (Router Under Test). August 2006. to collect the multicast listener information needed by its multicast routing protocol on the one hand. nodes that wish to receive multicast packets) on their directly attached links. Report reception. RFC 4606.0 Message Format To verify that the MLDv2 packet types are properly formatted: General Queries.K MLDv2 Conformance Specification 1.e.0 Introduction The Multicast Listener Discovery Protocol (MLD) is used by IPv6routers to discover the presence of multicast listeners (i.0 Value Adoption and Timers To verify that an MLDv2 Router will adopt the appropriate values for certain timers when nonquerier. In particular check the formats of the Checksum. MLDv2 security. Querier’s Query Interval Code Adoption. and Router-Side Processing Suppression. June (i) 2004.0 References The following documents are referenced in this text: [MLD] . and Older Host Present Interval. and Auxiliary Data report reception.

Also verify the Router translates MLDv1 Reports into their corresponding MLDv2 Reports.B-A) Action(s) INCLUDE (A) TO_IN (B) EXCLUDE (X. that the Router has the appropriate Group Compatibility Mode scope.Y) BLOCK (A) EXCLUDE (X.Y-A) EXCLUDE (A-Y.4.Y) (A-X-Y)=Group Timer Send Q(G. updates times.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. and transmits queries as required.4. These specifically test the charts found in RFC 3376 Sections 6.Y) IS_IN (A) EXCLUDE (X.A-Y) EXCLUDE (A-Y. 41 .A-Y) Group Timer=GMI EXCLUDE (X+A.Y) ALLOW (A) EXCLUDE (X.Y) IS_EX (A) EXCLUDE (X+A.2 reproduced below for convenience.A-B) EXCLUDE (X+A.Y-A) (A)=GMI EXCLUDE (X+(A-Y).Y) TO_IN (A) (B)=GMI Send Q(G.0 Source Specific Multicast To verify that an MLDv2 Router accommodates source-specific multicast (SSM).X-A) Send Q(G) 7.A*B) Group Timer=GMI (B)=GMI INCLUDE (A+B) Send Q(G.Y*A) (A-X-Y)=Group Timer Delete (X-A) Delete (Y-A) Send Q(G. 8.1 and 6.6. and that the Other Host Present Interval expires and transitions modes as expected.A*B) (B-A)=0 Delete (A-B) Send Q(G.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.0 Report Reception To verify that when an MLDv2 Router receives a MLDv2 Report the router switches to the appropriate state.0 Version Interoperability To verify that an MLDv2 Router ignores the appropriate Reports when in MLDv1 Group Member Compatibility Modes.Y) TO_EX (A) EXCLUDE (X.Y-A) (A)=GMI Send Q(G. 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. Router State Report Rec'd New Router State INCLUDE (A) INCLUDE (A) IS_IN (B) IS_EX (B) INCLUDE (A+B) EXCLUDE (A*B.

August 2006.0 Introduction The chapter describes the router Interoperability specifications for MLDv2 (Multicast Listener Discovery Version 2. source records.0 42 . 5.0 Listener and Router Interoperability . version compatibility. (ii) [SSM] . 3.To verify that MLDv2 routers behave correctly when interacting with other routers on the network.To verify that an MLDv2 router and listener behave correctly when interacting with multicast address records. RFC 4604.Using Internet Group Management Protocol Version 3 (IGMPV3) and Multicast Listener Discovery Protocol 2 (MLDv2) for Source-Specific Multicast.CHAPTER-3. June 2004. 2.Multicast Listener Discovery Version 2 (MLDv2) for IPv6. and source specific multicast.0 References The following documents are referenced in this text: (i) [MLD] . RFC 3810.MLDv2 defines several timers and default values.0 . Router Interoperability .L MLDv2 Interoperability Specification 1. These defaults are taken or calculated from RFC3376: Timers and Default Values 4.

March 1991. 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. network management stations execute management applications which monitor and control gateways. 43 . [INA-TC] Textual Conventions for Internet Network Addresses. Internet Protocol.ipv6ready. March 2006.0 References The following RFCs are related – [ADDR] Internet Protocol Version 6 (IPv6) Addressing Architecture. 2. RFC 4001. [ICMPv6] Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.CHAPTER-3. December 1998. IPv6 Forum IPv6 (http://www. February 2005. and which have management agents for performing the network management functions requested by the network management stations. According to the SNMP architectural model.M SNMP / MIB Conformance Specifications 1. version 6 (IPv6) Specification. RFC 2460.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. RFC 4443. RFC 3315. [IPv6SPEC] [IPv6 Ready Phase II Test Specification Core Protocols] [MIB-DEF] Concise MIB definitions. RFC 1212. terminal servers and the like.org/) Ready Technical Documentation. April 2003.

[SIMI] [SMIv2] [SMIv2-CS] [SMIv2-TC] [SNMPv1] [SNMP] [SNMPv2] [SNMPv2C] [SNMPv2MIB] [SMIv2] 3. SNMPv3. Introduction to Community. RFC 2578. Conformance Statements for SMIv2. RFC 4293. RFC 3418. March 1991. April 1999. May 1990. April 1999. 1999. RFC 1157. A Simple Network Management Protocol (SNMPv1). SNMP. April 1999. RFC 1213. April 1999.based SNMPv2. over IPv6. as defined in RFC 3416. is the most prevalent management protocol on top to IPv4 network layer. May 1990. RFC 3416. RFC 2578. IETF’s recent RFC 4293 document integrates RFC2465 for the IPv6 Management Information Base (MIB) and RFC 2466 for IPv6 ICMP MIB into 44 . January 1996. Textual Conventions for SMIv2. Management Information Base for the Internet Protocol (IP). April 2006. Protocol Operations for version 2 of the Simple Network Management Protocol. Structure and Identification of Management Information for TCP/IPbased Internets.[MIB-II] [MIB for IP] Management Information Base for Network Management of TCP/IPbased internets MIB-II. Structure of Management Information version 2 (SMIv2). RFC 1155. 3rd ed. and RMON 1 and 2. Management Information Base (MIB) for the Simple Network Management Protocol (SNMP).0 Requirements This specification is intended to verify the SNMPv2C protocol behaviors. SNMPv2C. December 2002. SNMPv2. RFC 2579. December 2002. Structure of Management Information version 2 (SMIv2). as defined in RFC 3416.. RFC 2580. RFC 1901. To provide a more efficient network management perspective.

RFC 3416 SNMPv2(SNMPv2C) Protocol Operations T o v e r i f y SNMPv2C functionalities based in RFC 3416.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.Management Information Base for the Internet Protocol which will be used to manage network nodes in the IP Internet community using SNMP protocol. IETF specification by which management information for a network element may be inspected or altered by logically remote users.0 NUT as SNMPv2C Agent . 4. 45 . 5.

0 Introduction MIB (Management Information Base) Managed objects are accessed via a virtual information store.To verify the readiness of a new RFC 4293 MIB implementation. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP).0 Reference Standards (i) RFC 3418 SNMPv2 MIB .N SNMP / MIB Conformance Specification 1.Chapter-3. 46 .To verify the readiness of a SNMPv2 MIB implementation. (ii) RFC 4293 IP-MIB . termed the Management Information Base or MIB. 2.

0 Reference standards (i) (ii) (iii) (iv) (v) (vi) (vii) RFC3261: SIP: Session Initiation Protocol (http://www. presence information.ietf.txt) RFC2617: HTTP Authentication: Basic and Digest Access Authentication (http://www.org/rfc/rfc3665. and adding or deleting media streams. This chapter describes the SIP Conformance specification.org/rfc/rfc3264. modifying and terminating two-party (unicast) or multiparty (multicast) sessions consisting of one or several media streams.ietf.O Session Initiation protocol (SIP) Proxy Server Conformance Specifications 1.txt) RFC3665: SIP Basic Call Flow Examples (http://www.ietf.ietf. The modification can involve changing addresses or ports. 2. file transfer and online games.org/rfc/rfc4566. The protocol can be used for creating. inviting more participants.txt) RFC3264: An Offer/Answer Model with Session Description Protocol (http://www.org/rfc/rfc3261. Other feasible application examples include video conferencing.org/rfc/rfc2617. streaming multimedia distribution.txt) IPv6 Ready Logo Phase 2 Policy SIP IPv6 Test Scope 47 . instant messaging.txt) RFC4566: SDP: Session Description Protocol (http://www.ietf.CHAPTER-3. widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol(IP).0 Introduction The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol.

2.0 Introduction This chapter describes the SIP Conformance specifications for a Registrar Server.txt) RFC3665: SIP Basic Call Flow Examples (http://www.txt) RFC3264: An Offer/Answer Model with Session Description Protocol (http://www. A SIP registrar is a server in a Session Initiation Protocol (SIP) network that accepts and processes SIP REGISTER requests. although other protocol schemes are possible.ietf.CHAPTER-3.P Session Initiation protocol (SIP) Registrar Server Conformance Specifications 1.org/rfc/rfc3264.ietf.org/rfc/rfc4566. The SIP registrar provides a location service which registers one or more IP addresses to a certain SIP URI (Uniform Resource Identifier).0 Reference standards (i) (ii) (iii) (iv) (v) (vi) RFC3261: SIP: Session Initiation Protocol (http://www.txt) IPv6 Ready Logo Phase 2 Policy on SIP IPv6 Test Scope 48 .ietf. indicated by the sip scheme.org/rfc/rfc3665.org/rfc/rfc3261.org/rfc/rfc2617.txt) RFC2617: HTTP Authentication: Basic and Digest Access Authentication (http://www.txt) RFC4566: SDP: Session Description Protocol (http://www.ietf.ietf.

Back to Back User Agent (B2BUA) Conformance Specifications 1.txt) IPv6 Ready Logo Phase 2 Policy SIP IPv6 Test Scope 49 .org/rfc/rfc3264.org/rfc/rfc4566.0 Reference standards (i) (ii) (iii) (iv) (v) (vi) RFC3261: SIP: Session Initiation Protocol (http://www. Endpoint (EP).ietf.ietf.org/rfc/rfc2617.org/rfc/rfc3665.0 Introduction This chapter describes the SIP Conformance specification for User Agent.ietf.txt) RFC3665: SIP Basic Call Flow Examples (http://www.ietf.org/rfc/rfc3261.ietf.CHAPTER-3.txt) RFC3264: An Offer/Answer Model with Session Description Protocol (http://www.txt) RFC4566: SDP: Session Description Protocol (http://www. Endpoint and Back-toBack User Agent 2.txt) RFC2617: HTTP Authentication: Basic and Digest Access Authentication (http://www.Q Session Initiation protocol (SIP) User Agent (UA).

2.0 Reference standards (i) (ii) (iii) (iv) (v) (vi) (vii) RFC3261: SIP: Session Initiation Protocol (http://www. confirm that all SIP equipment on the architecture support the same functions as those of the applicant implementation. and each ADVANCED function can be selectively supported.org/rfc/rfc3665.0 Interoperability Test Scenario All BASIC functions must be supported in the viewpoint of interoperability. The other SIP equipment that connects to a piece of applicant implementation on a network architecture must support the functions. In the case of ADVANCED function.org/about_phase2_test.org/rfc/rfc4566.R Session Initiation protocol (SIP) Interoperability Specifications 1. regardless of BASIC or ADVANCED function.ipv6ready.org/rfc/rfc3261.ietf.org/rfc/rfc3264.0 Introduction This chapter describes details of the SIP Interoperability specification to verify the interoperability between SIP IPv6 equipment.txt) Guidelines for Implementation (http://www.ietf.CHAPTER-3. especially.txt) RFC2617: HTTP Authentication: Basic and Digest Access Authentication (http://www.txt) RFC3665: SIP Basic Call Flow Examples (http://www.ietf.txt) RFC3264: An Offer/Answer Model with Session Description Protocol (http://www.org/rfc/rfc2617.txt) RFC4566: SDP: Session Description Protocol (http://www.html) 3.ipv6ready.ietf.html) IPv6 Ready Logo Phase 2 Policy for SIP (http://www.ietf.org/about_phase2_test. 50 .

Establishment.Forking / Multiple responses .Registration (for Endpoint / Registrar) .Hold (Using ReINVITE) (for UA / Endpoint) .Digest authentication (REGISTER. disconnection.List of Interoperability test for BASIC and ADVANCED functions BASIC functions ADVANCED functions .Registration and Digest authentication for REGISTER (for UA / B2BUA) . Initial INVITE)(for Endpoint) .SDP Offer/Answer (INVITE-200) .Hold (Using Re-INVITE) (for B2BUA) .OPTIONS request 51 . and cancellation of Session .Digest authentication (Initial INVITE) (for UA / B2BUA) .

2. However in implementation this does not necessarily map into greater reduced cost and complexity.2.S IP Multimedia Subsystem – User Equipment (IMS-UE) Conformance Specifications 1. This vision was later updated by 3GPP.txt) 2.org/rfc/rfc3608.1 RFC3261: SIP: Session Initiation Protocol (http://www. Session Initiation Protocol (SIP). as the control layer is a common horizontal layer.8. Its original formulation (3GPP R5) represented an approach to delivering "Internet services" over GPRS.CHAPTER-3.1 TS 24. i.ietf.2 RFC3327: Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts (http://www.txt) (3) RFC3265: Session Initiation Protocol (SIP)-Specific Event Notification (http://www. CDMA2000 and fixed line.txt) 2.0.229: IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).0 Reference standards 2.txt) 52 2.htm) [SIP/SDP] 2. IMS is not intended to standardize applications but rather to aid the access of multimedia and voice applications from wireless and wireline terminals.3 RFC3455: Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) (http://www.org/rfc/rfc3327. According to the 3GPP. 3GPP TS 24.ietf. IMS uses IETF protocols wherever possible.4 RFC3608: Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration (http://www. This is done by having a horizontal control layer that isolates the access network from the service layer.org/rfc/rfc3265.1 [IMS] 2.txt) 2. e. From a logical architecture perspective. 3GPP2 and TISPAN by requiring support of networks other than GPRS.org/rfc/rfc3455.1.2. Stage 3(Release 7). To ease the integration with the Internet.e.ietf.org/rfc/rfc3261. such as Wireless LAN. This chapter describes the IMS Conformance Specifications for User Equipment when IPv6 is in use.2. services need not have their own control functions. 2.3gpp. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP).org/ftp/Specs/html-info/24229.g.ietf.2 . create a form of fixed-mobile convergence (FMC). as a part of the vision for evolving mobile networks beyond GSM.ietf. (http://www.0 Introduction The IP Multimedia Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia services.229 v7.

3gpp.txt) [IMS AKA and Security Association] 2.4 3.3.txt) RFC4566: SDP: Session Description Protocol (http://www.5 3.org/rfc/rfc4566.txt) RFC4320: Actions addressing identified issues with the Session Initiation Protocol's non-INVITE Transaction (http://www. 3GPP TS 33.8 Registration Session Establishment SDP OPTIONS SIP timer Sending Response Receiving Response SigComp 53 .org/rfc/rfc4896.2 RFC3310: Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) (http://www.txt) 2.ietf.org/rfc/rfc3320.1 3.6 2.203: 3G security. Access security for IP-based services (Release 7) (http://www.5 2.txt) 2.ietf.3 [SigComp] 2.7 3.org/rfc/rfc4320.org/rfc/rfc3485.1 TS.org/rfc/rfc5049.5 RFC5049: Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) (http://www.6.ietf.2.ietf.ietf.4.0.ietf.2.ietf.org/rfc/rfc3486.3.3 RFC3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP) (http://www.txt) 2.2 3.htm).3. 2.2 RFC3485: The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) (http://www.0 User Equipment operation – The following functions are to be tested for User Equipment (UE) 3.4.org/rfc/rfc3329.3.4.2.4 RFC4896: Signaling Compression (SigComp) Corrections and Clarifications (http://www.ietf.ietf.org/rfc/rfc3310.org/rfc/rfc3680.7 RFC3680: A Session Initiation Protocol (SIP) Event Package for Registrations (http://www.203 v7.3 RFC3486: Compressing the Session Initiation Protocol (http://www.1 RFC3320: Signaling Compression (SigComp) (http://www.org/ftp/Specs/html-info/33203.ietf.3.6 3.txt) 2.txt) 2.2.txt) 2.33.3 3.4 3.txt) 2.

T IP Multimedia Subsystem – User Equipment (IMS-UE) Interoperability Specifications 1.0 Introduction This chapter describes the IMS Interoperability Specifications. 3. Session Initiation Protocol (SIP)-Specific Event Notification. it is recommended to execute the interoperability test with UE2 (REF UE) which is the same vender as UE1 (TARTGET UE). RFC 3265. June 2002.203] [SIP] [SDP] [SIPEVENT] [RFC3329] 54 . Security Mechanism Agreement for the Session Initiation Protocol (SIP).0. July 2006. SIP: Session Initiation Protocol.8. 3G security Access security for IP-based services (Release 7). RFC 3329. [TS33. 2. Also. Stage 3 (Release 7). IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP). 3rd Generation Partnership Project Technical Specification Group Services and System Aspects.0 Equipment Type UE (User Equipment): A node that initiates and receives requests to exchange parameters between P-CSCF. 3GPP TS 24. and IMS CSCFs1/HSS1 (REF) must support all BASIC functions. RFC 4566. RFC 3261. January 2003. 3GPP TS 33.229 v7. June 2002.229] 3rd Generation Partnership Project. Moreover. UE2 must support the same functions as UE1.0 Reference Standards [TS24.6.0.203 v7. IMS IPv6 UE must execute the interoperability test with two or more vendor’s equipments. Technical Specification Group Core Network and Terminals.CHAPTER-3. SDP: Session Description Protocol.

org/rfc/rfc3775. Because the NEMO is part of the home network.org/rfc/rfc3776.txt) RFC3775: Mobility Support in IPv6 (http://www.0 Reference standards The functions are specified in the IETF RFC and Mobile IPv6 Test Profile listed below.ipv6ready. It is assumed that the NEMO is assigned to a particular network.org/rfc/rfc4877. are still routed to the home network. (i) (ii) (iii) (iv) (v) (vi) RFC3963: Network Mobility (NEMO) Basic Support Protocol (http://www.txt) RFC3776: Using IPSec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (http://www. 55 . 2. The router within the NEMO that connects to the Internet is called the Mobile Router (MR).CHAPTER-3. when the NEMO is away from home. known as Mobile Network Nodes (MNNs)." or NEMO) is defined as a network whose attachment point to the Internet varies with time. called the Care-of Address (CoA). known as its Home Network (MR connects to a Home Agent –HA. When the NEMO is away from home.txt) IPv6 Ready Logo Phase-2 Network Mobility (NEMO) Policy (http://www.txt) RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPSec Architecture (http://www. These addresses have topological meaning only when the NEMO is at home.ipv6ready. the mobile router acquires an address from the visited network.in the home network) where it resides when it is not moving.ietf.html) IPv6 Ready Logo Phase-2 Network Mobility (NEMO) Test Specification Profile(http://www. This chapter describes the Home Agent (HA) Conformance Specifications. packets addressed to the nodes of the NEMO.org/rfc/rfc3963.org/about_phase2_test.U Network Mobility (NEMO) – Home Agent (HA) Self Test Conformance Specifications 1.0 Introduction A mobile network (known also as a "network that moves.org/about_phase2_test. Additionally.ietf.html). These addresses remain assigned to the NEMO when it is away from home.ietf. where the routing architecture can deliver packets without additional mechanisms.ietf. the mobile network has configured addresses belonging to one or more address blocks assigned to the home network: the Mobile Network Prefixes (MNPs).

org/about_phase2_test.html) IPv6 Ready Logo Phase-2 Netowork Mobility (NEMO) Test Specification Profile (http://www.org/rfc/rfc3775.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 .txt) IPv6 Ready Logo Phase-2 Netowork Mobility (NEMO) Policy (http://www.org/rfc/rfc3963.7 3.org/about_phase2_test.ietf.txt) RFC3775: Mobility Support in IPv6 (http://www.ipv6ready.org/rfc/rfc3776.10 3.html/) 3.ipv6ready.5 3.The specified IETF RFC and Network Mobility Test Profile RFCs are listed below.4 3.2 3.ietf.txt) RFC3776: Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (http://www.0 Mobile Router operation – The following components are to be tested 3. (i) (ii) (iii) (iv) (v) (vi) RFC3963: Network Mobility (NEMO) Basic Support Protocol (http://www.V Network Mobility (NEMO) – Mobile Router (MR) Conformance Specifications 1.11 3.9 3.0 Introduction This chapter describes the NEMO-MR Conformance Specifications.1 3.ietf.txt) RFC4877: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (http://www. 2.6 3.ietf.8 3.org/rfc/rfc4877.0 Reference standards .CHAPTER-3.3 3.

ietf.org/about_phase2_test.ipv6ready.2 6.ipv6ready. 2. in the form of Home Agents (HAs) and Mobile Routers (MRs).html) 4.0 Introduction This chapter gives scenarios for the interoperability between different implementations of Network Mobility.2 6.0 Reference standards – The relevant IETF RFC and Network Mobility Test Profile are listed below.org/rfc/rfc4877.txt) Guidelines for Implementation (http://www.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.7 9 BU/BA 6 6. (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.1.html/) IPv6 Ready Logo Phase 2 Policy for NEMO (http://www.2 6.1 6.4 6 Function Section number in RFC 57 .CHAPTER-3.org/about_phase2_test.1.6 Encapsulation/ 6.W Network Mobility (NEMO) – Interoperability Specifications 1.

4 BU/BA (IPsec ESP) 4.4 8.4 8.decapsulatation / forwarding Advanced Functions DHAAD 6.4 6.3 8 Advertising reachability IPsec Real HL RFC3775 Requirements for IPv6 Home Agents Home Registration 8.2 4.1.3 8.3.4 10.4 8.4 8.5 9 7 7.4 8.3 58 .1 4.1 7.1 8.3 9 7.1 Home Registration 8.4 Requirements 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.2 Dynamic routing protocol 6.2 6.

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.1 10.5 Advanced Functions DHAAD MPD 10.6.2 5.1 10.8 Supporting both modes 5.6.1 10.1 10.4 5.3 4.1 4.4.3 5.2 4.2 5.3.4.4.3 Real HL 10.4.1 Explicit mode 5.2 10.2 4.Encapsulation/ decapsulatation 10.1 9 4 5 59 .4 Implicit mode 5.3.4.2 10.2 5.2 10.2 5.2 5.5.1 10.4.

5 9 Advanced Function DHAAD 5.5 Home address option IPsec Encapsulation/ decapsulatation / forwarding Binding Error ICMP Movement detection Returning home 8.3 Dynamic routing protocol 8 9 Multicast Real HL 5.1-7.5 8.6 7.5 8.8 IPsec RFC3775 Requirements for IPv6 Mobile Nodes Requirements 9 8.5 8.2 Neighbor Discovery 5.5 8.6 5.3 7 7.Encapsulation/ decapsulatation / forwarding 5.7 5.5 60 .5 Home Registration 8.1 5.7 5.

5 8.Mobility Header RR BU/BA Mobile prefix advertisement DHAAD Route optimization Multicast Stateful address autoconfiguration Basic Function Home Registration 8.1 4.5 11.1 4.3 Encapsulation / decapsulation Movement detection.7. visiting of FL 11.4.5.7.5.1 11.5 8.5 8.7.5 8.4 Real HL 11.1 11.3 4.2 11.3.2 Advanced Function DHAAD MPD 11. CoA formation.4 4.7.3 BU/BA (IPsec ESP) 11.1 11.5 8.2 4.5 8.2 4.5.4.3.5 8.1 61 .1 11.2 Advanced RFC4877 Function Fine-Grain Selectors 4 11.1 11.3 4.3 4.

receive. receive IPv6 packet forwarding Extension headers: processing Hop-by-Hop & unrecognized options Fragment headers: send.CHAPTER-4 IETF RFC Summary for IPv6 (1) IPV6 BASIC REQUIREMENTS IETF Specification IPv6 Basic Requirements RFC2460 IPv6 Specification IPv6 Packets: send. 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 .

(3) Security Requirements IETF Specification IPv6 Security Requirements 63 .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.

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 .

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 .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.

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 . 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 .DiffServ) RFC3168 (Explicit Congestion Notification.

ESP and Uncomp Connections and Clarifications to RFC3095 ROHC Profile for IP Only ROHC over PPP ROHC Link Assisted for IP/UDP/RTP 71 .4 Networks IPv6 over PPP Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.RFC4338 RFC4944 RFC5072 RFC5121 RFC2507 RFC2508 RFC3173 RFC4995 RFC4996 RFC3095 RFC4815 RFC3843 RFC3241 RFC4362 IPv6.15. IPv4 and ARP packets over Fibre Channel IPv6 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.

ABBREVIATIONS ASN.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 .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 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 .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.

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

75 . 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).Tunnel: Two endpoints that communicate using an IP packet header or address space.

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

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

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

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

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

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

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

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