Network Working Group M-K. Shin Internet-Draft ETRI Expires: August 27, 2006 H-J. Jang Samsung AIT February 23, 2006 Transmission of IPv6 Packets over IEEE 802.16 draft-shin-16ng-ipv6-transmission-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.16 networks. It also specifies how to send IPv6 unicast and multicast packets over IEEE 802.16 networks. Shin & Jang Expires August 27, 2006 [Page 1] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5 4. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Stateless Autoconfiguration and Link-Local Addresses . . . . . 8 6. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 9 7. Packet Transmission . . . . . . . . . . . . . . . . . . . . . 10 7.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1.1. Unicast Transmission . . . . . . . . . . . . . . . . . 11 7.1.2. Multicast Transmission . . . . . . . . . . . . . . . . 11 7.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2.1. Unicast Transmission . . . . . . . . . . . . . . . . . 12 7.2.2. Multicast Transmission . . . . . . . . . . . . . . . . 12 7.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3.1. Unicast Transmission . . . . . . . . . . . . . . . . . 13 7.3.2. Multicast Transmission . . . . . . . . . . . . . . . . 13 7.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 13 7.4.1. Unicast Transmission . . . . . . . . . . . . . . . . . 14 7.4.2. Multicast Transmission . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Shin & Jang Expires August 27, 2006 [Page 2] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 1. Introduction Recently, broadband wireless access network is emerging for wireless communication for user requirements such as high quality data/voice service, fast mobility, wide coverage, etc. The IEEE 802.16 Working Group on broadband wireless access standards develops standards and recommended practices to support the development and deployment of broadband wireless metropolitan area networks. As the deployment of wireless broadband access network progresses, users will be connected to IPv6 networks. This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.16 networks. It also specifies how to send IPv6 unicast and multicast packets over IEEE 802.16 networks. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Shin & Jang Expires August 27, 2006 [Page 3] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 2. Terminology SS: Subscriber Station. A general equipment set providing connectivity between subscriber equipment and a BS. MS: Mobile Station. A station in the mobile service intended to be used while in motion or during halts at unspecified points. A mobile station (MS) is always a subscriber station (SS). BS: Base Station. A generalized equipment set providing connectivity, management and control of MS connections. A unidirectional mapping between BS and MS medium access control (MAC) peers for the purpose of transporting a service flow's traffic. Connections are identified by a connection identifier (CID). All traffic is carried on a connection. PHS : Payload Header Suppression. PDU : Protocol Data Unit. This refers to the data format passed from the lower edge of the 802.16 MAC to the 802.16 PHY, which typically contains SDU data after fragmentation, encryption, etc. SDU : Service Data Unit. This refers to the data format passed to the upper edge of the 802.16 MAC Shin & Jang Expires August 27, 2006 [Page 4] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 3. Maximum Transmission Unit IEEE 802.16 permits fragmentation and reassembly. This capabilities are compleletely different from IP fragmentation and reassembly process. Fragmentation is the process by which a MAC SDU is divided into one or more MAC PDU. This process is undertaken to allow efficient use of availabe bandwidth relative to the QoS requirements of connection's service flow. The default MTU size for IPv6 packets over IEEE 802.16 is not defined in [IEEE802.16]. Fragmentation frame size can be variable according to the bandwidth relative to the QoS requirements of connection's service flow. Also, it may be dependent on type of Convergence Sublayers (CS). For example, the default MTU size for IPv6 packets on an Ethernet CS would be 1500 octets. Mannual configuration of each node may be required, if necessary. Shin & Jang Expires August 27, 2006 [Page 5] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 4. Frame Format IEEE 802.16 [IEEE802.16] defines the MAC and PHY layers for OFDM and OFDMA-based broadband wireless access. IEEE 802.16 PDU (Protocol Data Unit) which is the data format passed from the lower edge of the 802.16 MAC to the 802.16 PHY, which typically contains SDU data after fragmentation, encryption, etc. consists of a 6-byte MAC header, various optional subheaders, and a data payload. The 802.16 6-byte MAC header carries the Connection Identifer (CID) of the connection with which the PDU is associated. It is importmant to see that there is no source or destination MAC address in IEEE 802.16 the MAC header format. Similar to general point-to-point links, the MAC address is not used for link-layer transmission. Hence, mapping unicast or multicast addresses to IEEE 802.16 MAC addresses is unnecessary. Also, link-local addressess may be not needed for transmission of link-local destination packets. Instead, CID is used to identify connections to equivalent peers in the MAC of the BS and the MS in IEEE 802.16 networks. IEEE 820.16 SDU (Service Data Unit) which is the data format passed to the upper edge of the 802.16 MAC. IEEE 802.16 Convergence Sublayer (CS) provides the tunneling of IP(v6) packets over IEEE 802.16 air-link. The tunnels are identified by the Connection Identifier (CID). Generally, CS performs the following functions in terms of IP packet transmission: 1) Receipt of protocol data units (PDUs) from the higher layer, 2) Performing classification and CID mapping of the PDUs, 3) Delivering the PDUs to the appropriate MAC SAP, 4) Receipt of PDUs from the peer MAC SAP. [IEEE802.16] defines several CSs for carrying IP packets. The several CSs are classified into two types of CS: IP CS and Ethernet CS. Frame formats are different accordding to the CS types. IPv6 packets can be transmitted in 802.16 frames. In case of IP CS type, the data field contains the IPv6 header and payload, as shown in Fig 1. With Ethernet CS, Ethernet header MUST be included in 802.16 frame's data field, as shown in Fig 2. Shin & Jang Expires August 27, 2006 [Page 6] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H|E| Type |R|C|EKS|R|LEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LEN LSB | CID MSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID LSB | HCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +- -+ | header | +- -+ | and | +- -+ / payload ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 1 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H|E| Type |R|C|EKS|R|LEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LEN LSB | CID MSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID LSB | HCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet | +- -+ / header / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +- -+ | header | +- -+ | and | +- -+ / payload ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2 Shin & Jang Expires August 27, 2006 [Page 7] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 5. Stateless Autoconfiguration and Link-Local Addresses Like other IEEE 802 interfaces, the Interface Identifier for an IEEE 802.16 interface is based on the EUI-64 identifier derived from the interface's built-in 48-bit IEEE 802 address. The Interface Identifier is then formed from the EUI-64 by complementing the "Universal/Local" (U/L) bit, which is the next-to- lowest order bit of the first octet of the EUI-64. For example, the Interface Identifier for an IEEE 802.16 interface whose built-in address is, in hexadecimal, "34-56-78-9A-BC-DE" would be "36-56-78-FF-FE-9A-BC-DE". A different MAC address set manually or by software should not be used to derive the Interface Identifier. If such a MAC address must be used, its global uniqueness property should be reflected in the value of the U/L bit. An IPv6 address prefix used for stateless autoconfiguration of an IEEE 820.16 interface must have a length of 64 bits. The IPv6 link-local address for an IEEE 802.16 interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+ Fig. 3 Shin & Jang Expires August 27, 2006 [Page 8] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 6. Address Mapping In general, the procedure for mapping IPv6 unicast addresses into IEEE 802.16 link-layer addresses is directly not applied as described in [RFC1972], since IEEE 802.16 MAC header does not contain any source or destination 802 MAC addresses. In case of IP CS type, mapping unicast or multicast addresses to IEEE 802.16 MAC addresses is unnecessary. Instead, in order to identify connections to equivalent peers in the MAC of the BS/router and the MS, CID is used. In certain cases, multicast CID may be provided for in the downlink. It can be useful to tranmit efficiently link-local multicast destination packets (e.g, Router Advertisements) from BS/router to MSs. So, CID or multicast CID may be mapped to IPv6 unicast or multicast addresses with TCP/UDP ports. This mapping is dependent on how to implement it. However, in case of Ethernet CS type, source and Ethernet addresses are required to form the frame for Ethernet CS. In such case, address mapping is the same as [RFC1972]. Shin & Jang Expires August 27, 2006 [Page 9] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 7. Packet Transmission IEEE 802.16 is different from existing wireless access technologies such as IEEE 802.11, and, while 802.16 defines the encapsulation of an IP datagram in an IEEE 802.16 MAC payload, complete description of IPv6 operation is not present and can benefit from IETF input and specification. Classification is the process by which a MAC SDU is mapped onto a particular connection for transmission between MAC peers. This mapping process associates a MAC SDU with a connection based on some criteria such as protocol-specific packet information, which is called as classification parameters according to [Section 5.2 802.16- 2004]. For IP CS, the packet may be classified by IP source/ destination addresses, etc. For Ethernet CS (IP over Ethernet CS), the packet may be classified by Ethernet source/destination addresses and IP source/destination addresses, source/destination port numbers, etc. This is dependent on how to implement it. Base Station (BS) generates the flow based on the classification (IP CS or Ethernet CS). It also decides where to send the packet, since IEEE 802.16 connection always ends at BS while IPv6 connection terminates at a default router. This operation and limitation may be dependent on subnet model. While deploying IPv6 in the approach described in earlier sections, there are four possible typical scenarios as discussed below [I-D.shin-v6ops-802.16-deployment-scenarios]. 7.1. Scenario A Scenario A represents IEEE 802.16 access network deployment where a BS is integrated with a router, composing one box in view of implementation. In this scenario, a subnet consists of only single BS/router and single MS. +-----+ | MS1 |<-------------+ +-----+ v +-----+ +-------+ +--------+ | MS2 |<---------->|BS/AR1 |---------| Edge | ISP +-----+ +-------+ | Router +==>Network +--------+ +-----+ +-------+ | | Ms3 |<---------->|BS/AR2 |-----------+ +-----+ +-------+ <---> IP termination Fig. 4 Scenario A Shin & Jang Expires August 27, 2006 [Page 10] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 7.1.1. Unicast Transmission o Outbound unicast packet from MS is always forwarded on a particular transport connection in the uplink direction to the BS/AR. o When BS/AR receives the packet destined to same subnet (as MS) from MS, it does not relay the packet anymore. o Otherwise, BS/AR forwards the packet to the edge router, which forwards the packet accordingly based on its routing table such as IGP. 7.1.2. Multicast Transmission Link-local and Non-link-local Multicast packet could be classified based on destination Ethernet address in Ethernet header (Ethernet CS) or IPv6 destination address in IP header. (IP or Ethernet CS) o Outbound multicast packet from the MS is always forwarded on a particular transport connection in the uplink direction to the BS/AR. o When BS/AR receives the multicast packet with link-local scope from MS, it does not forward the packet anymore. o When BS/AR receives the multicast packet with non-link-local scope from MS, it looks up the IPv6 ulticasting routing table and forwards the packets to the edge router according to the result. 7.2. Scenario B Scenario B represents IEEE 802.16 access network deployment where a BS is integrated with a router, composing one box in view of implementation, and a subnet consists of only single BS/AR and multiple MSs. +-----+ | MS1 |<------+ +-----+ | +-----+ | +-------+ +--------+ | MS2 |<------+--->|BS/AR1 |---------| Edge | ISP +-----+ +-------+ | Router +==>Network +--------+ +-----+ +-------+ | | Ms3 |<---------->|BS/AR2 |-----------+ +-----+ +-------+ <---> IP termination Fig. 5 Scenario B Shin & Jang Expires August 27, 2006 [Page 11] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 7.2.1. Unicast Transmission o Outbound unicast packet from the MS is always forwarded on a particular transport connection in the uplink direction to the BS/AR. o When BS/AR receives the packet destined to same subnet from MS but not to itself, it forwards to downlink after uplink CID is replaced with the corresponding downlink CID (which may be associated with the specified Ethernet addresses in Ethernet CS or IP addresses in Ethernet/IP CS). o When BS/AR receives the packet destined to other subnet from MS, it forwards the packet to the edge router, which forwards the packet accordingly based on its routing table such as IGP. 7.2.2. Multicast Transmission o Outbound unicast packet from the MS is always forwarded on a particular transport connection in the uplink direction to the BS/AR. o When BS/AR receives the multicast packet with link-local scope from MS, it sends back the packet to the downlink by using CID for multicast. o When BS/AR receives the multicast packet with non-link-local scope from MS, BS/AR looks up the IPv6 multicasting routing table and forwards the packets to the edge router according to the result. 7.3. Scenario C Scenario C represents IEEE 802.16 access network deployment where a BS is separated from a router, and a subnet consists of only single BS and single router and multiple MSs. +-----+ | MS1 |<------+ +-----+ | +-----+ | +-----+ +-----+ +--------+ | MSs |<------+----| BS1 |---->| AR |----| Edge | ISP +-----+ +-----+ +-----+ | Router +==>Network ^ +--------+ +-----+ +-----+ | | Mss |<-----------| BS2 |--------+ +-----+ +-----+ <---> IP termination Fig. 6 Scenario C Shin & Jang Expires August 27, 2006 [Page 12] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 7.3.1. Unicast Transmission o Outbound unicast packet from the MS is always forwarded on a particular transport connection in the uplink direction to the BS. o When BS receives the packet destined to same subnet from MS but not to AR, the uplink CID is replaced with the corresponding downlink CID (which may be associated with the specified Ethernet addresses in Ethernet CS or IP addresses in Ethernet/IP CS), then forwarded to downlink. o Otherwise, BS decapsulates the 802.16 header and forwards the packet to AR. . In case of Ethernet CS, it will be delivered to the AR naturally since the destination address in Ethernet header is the AR's address. In case of IP CS, the BS is responsible to deliver it with the proper Ethernet header. AR performs routing and then forwards it to other BS or edge router according to the routing result. 7.3.2. Multicast Transmission o Outbound unicast packets from the MS are always forwarded on a particular transport connection in the uplink direction to the BS. o When BS/AR receives the multicast packet with link-local scope from MS, it sends back the packet to the downlink by using CID for multicast. It also sends the packet to an AR after decapsulating 802.16 header. o When BS/AR receives the multicast packet with non-link-local scope from MS, the packet is sent back to the downlink by using CID for multicast. It is also sent to the AR based after decapsulating 802.16 header. In case of Ethernet CS, it will be delivered to the AR naturally since the destination address in Ethernet header is the multicast address. In case of IP CS, the BS is responsible to deliver it with the proper Ethernet header. AR looks up the IPv6 multicasting routing table and then forwards the packets to other BSs or edge router according to the result. 7.4. Scenario D Scenario D represents IEEE 802.16 network deployment where a BS is separated from a router, and a subnet consists of multiple BS and multiple MSs. Shin & Jang Expires August 27, 2006 [Page 13] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 +-----+ +-----+ +-----+ ISP 1 | MS1 |<-----+ +->| AR1 |----| ER1 |===>Network +-----+ | | +-----+ +-----+ +-----+ | +-----+ | | MS2 |<-----+-----| BS1 |--| +-----+ +-----+ | +-----+ +-----+ ISP 2 +->| AR2 |----| ER2 |===>Network +-----+ +-----+ | +-----+ +-----+ | Ms3 |<-----------| BS2 |--+ +-----+ +-----+ <---> IP termination Fig. 7 Scenario D 7.4.1. Unicast Transmission o Outbound unicast packet from the MS is always forwarded on a particular transport connection in the uplink direction to the BS. o If BS receives the packet destined to same subnet and to MS under the serving BS, the uplink CID is replaced with the corresponding downlink CID (which may be associated with the specified Ethernet addresses in Ethernet CS or IP addresses in Ethernet/IP CS), o Otherwise, BS decapsulates the 802.16 header and forwards the packet onto the wired network. In case of Ethernet CS, if the packet is destined to one of ARs, it will be delivered to the AR naturally since the destination address in Ethernet header is the AR's address. If the packet is destined to MS under other BS, the target BS under which the MS exists should catch this packet instead by acting as a proxy of the MS and send it to MS by using corresponding downlink CID. In case of IP CS, if the packet is destined to one of ARs, the BS is responsible to deliver it with the proper Ethernet header. If the packet is destined to MS under other BS, the target BS should catch this packet instead by acting as a proxy of the MS and send it to MS by using corresponding downlink CID. 7.4.2. Multicast Transmission o Outbound unicast packets from the MS are always forwarded on a particular transport connection in the uplink direction to the BS. o When BS receives the multicast packet with link-local scope from MS, it sends back the packet to the downlink by using CID for multicast. It also sends the packet onto the wired network after decapsulating 802.16 header. ARs will get this, and other BSs will receive this and send it by using CID for multicast. o When BS receives the multicast packet with non-link-local scope Shin & Jang Expires August 27, 2006 [Page 14] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 from MS, it sends back the packet to the downlink by using CID for multicast. It also sends the packet onto the wired network after decapsulating the 802.16 header. Other BSs will receive this and send it by using CID for multicast. The multicast router receiving this will look up the IPv6 multicasting routing table and then forwards the packets to edge router according to the result. Shin & Jang Expires August 27, 2006 [Page 15] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 8. IANA Considerations This document requests no action by IANA. Shin & Jang Expires August 27, 2006 [Page 16] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 9. Security Considerations TBD Shin & Jang Expires August 27, 2006 [Page 17] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996. 10.2. Informative References [I-D.shin-ipv6-ieee802.16] Shin, M., "Scenarios and Considerations of IPv6 in IEEE 802.16 Networks", draft-shin-ipv6-ieee802.16-01 (work in progress), October 2005. [I-D.mandin-ip-over-80216-ethcs] Mandin, J., "Transport of IP over 802.16", draft-mandin-ip-over-80216-ethcs-00 (work in progress), October 2005. [IEEE802.16] "IEEE 802.16-2004, IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed broadband wireless access systems", October 2004. [IEEE802.16e] "IEEE 802.16e/D10 Draft, IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", August 2005. Shin & Jang Expires August 27, 2006 [Page 18] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 Authors' Addresses Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 4847 Email: myungki.shin@gmail.com Hee-Jin Jang Samsung AIT P.O. Box 111 Suwon 440-600 Korea Email: heejin.jang@samsung.com Shin & Jang Expires August 27, 2006 [Page 19] Internet-Draft IPv6 Packet Transmission over IEEE 802.16 February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shin & Jang Expires August 27, 2006 [Page 20]