MANET Autoconfiguration (AUTOCONF) K. Mase Internet-Draft Y. Owada Expires: January 10, 2008 Niigata University July 9, 2007 Gateway Aggregation Protocol (GAP) for Mobile Ad Hoc Networks draft-mase-autoconf-gap-01 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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Mase & Owada Expires January 10, 2008 [Page 1] Internet-Draft GAP July 2007 Abstract We consider Internet connectivity of a mobile ad hoc network (MANET), where two or more fixed or mobile nodes (MNs) may have a wired or wireless interface to the fixed Internet in addition to the wireless interface for the MANET. The points of attachment of MNs to the Internet are termed as "Access Routers (ARs)," A stationary MN, that has wired connection with the Internet may become an AR itself. Typically, only a single AR is used as the Internet Gateway (IGW) in a MANET. Two or more IGWs may be used, but the number of the IGWs should be kept to a minimim. This minimizing feature is named "Gateway Aggregation." MANET routing protocol runs on the MBGs, and both routing control messages and data packets of the MANET are tunneled between an MN and its associated AR, between an AR and its selected IGW, and also between an IGW and its peer IGW. The IGW advertises the network prefix for the MNs to configure their global care-of-addresses. An MN configures its care-of-address with the prefix advertised by one of the IGWs. Once it obtains its global address, it does not have to change it during its stay in the MANET. Mase & Owada Expires January 10, 2008 [Page 2] Internet-Draft GAP July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. GAP Packet and Message Format . . . . . . . . . . . . . . . . 10 4.1. Gateway Aggregation Request . . . . . . . . . . . . . . . 10 4.2. Gateway Aggregation Response . . . . . . . . . . . . . . . 10 4.3. Gateway Reconfigure Request . . . . . . . . . . . . . . . 10 5. Gateway Aggregation Information Base . . . . . . . . . . . . . 11 5.1. Gateway Aggregation Set . . . . . . . . . . . . . . . . . 11 6. Gateway Aggregation Information Base Changes . . . . . . . . . 12 7. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Protocol Operation Overview . . . . . . . . . . . . . . . 13 7.2. Global Prefix Assgnment to MN . . . . . . . . . . . . . . 13 7.3. Other MBG Detection . . . . . . . . . . . . . . . . . . . 13 7.4. Gateway Aggregation Request . . . . . . . . . . . . . . . 14 7.5. Gateway Aggregation Response . . . . . . . . . . . . . . . 14 7.6. Tunnel Establishment between MBGs . . . . . . . . . . . . 14 7.7. Data Packet Forwarding . . . . . . . . . . . . . . . . . . 14 7.8. Gateway Reconfiguration message generation . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 16 8.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Mase & Owada Expires January 10, 2008 [Page 3] Internet-Draft GAP July 2007 1. Introduction Mobile ad hoc networks (MANETs) may have temporary or continuous Internet connectivity so that the mobile nodes (MNs) can exchange data packets with the nodes in the Internet (Internet nodes). In the simplest case, a single MN also has the wired or wireless interface to the Internet and works as the Internet Gateway (IGW). It thus advertises the network prefix for the MNs to configure their care-of- addresses. In more complex cases, multiple nodes in the MANET may have an interface to the Internet and work as the IGW. In this case, each IGW advertises its network prefix to the MNs and an MN needs to select its IGW, when receiving gateway information from two or more IGWs [2], [3]. Typically, a node should select the closest IGW in terms of the number of hops for communication efficiency. It is therefore desirable for the node to re-select a different IGW when the current IGW is not appropriate as the result of roaming. The node then needs to configure its new care-of-address based on the network prefix advertised by the new IGW. However, firstly, it is not convenient for the node to change its IP address frequently for the purpose of maintaining its communication sessions. Secondly, it takes some time for the MANET to reconstruct routes in which this nodes is directly (as the source or destination) or indirectly (as the relay nodes) involved. With regard to the first issue, no previously proposed methods can completely avoid the possibility of address change. With regard to the second issue, two approaches have been recently proposed. In the first approach, each node configures multiple care-of-addresses based on the received prefixes and advertises all of them throughout the MANET so that the routing protocol maintains all routes to the multiple addresses [4]. When a node changes its address to one of the advertised addresses, all other nodes will already have maintained the route to this address. In the second approach, data packets are tunneled between the MNs and the selected GWs in both directions. MANET-local addresses are used for forwarding packets within the MANET [5]. The result is that no route reconstruction needs to be performed when any MANET node changes its global address. In this document, we propose a novel method, called "Gateway Aggregation Protocol (GAP)" to realize the Internet connectivity of a MANET, where the number of IGWs are kept minimized and the nodes in the MANET do not have to change their care-of-IP addresses regardless of roaming, simultaneously solving the two issues mentioned above. Note that the registration mechanisms and the related descriptions given in this document are mostly inspired by [5]. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Mase & Owada Expires January 10, 2008 [Page 4] Internet-Draft GAP July 2007 document are to be interpreted as described in [1]. Mase & Owada Expires January 10, 2008 [Page 5] Internet-Draft GAP July 2007 2. Terminology MANET: Mobile ad hoc network MN: A node located inside a MANET. Access router (AR): The point of attachment of an MN to the Internet. MBG: MANET Border Gateway. This node has two or more interfaces and has a connectivity both to a AR and to a MANET. Internet node: A node located within the Internet (outside MANET). Default route: All the packets for destinations not known by the router's routing table are sent to the default route. The default route address in IPv4 (in CIDR notation) is 0.0.0.0/0, and in IPv6 is given by ::/0. Anchor MBG: A MBG which is advertising the default route to the MANET. Internet gateway (IGW): A router which provides Internet connectivity for MNs. MANET-local address: A unique-local address having scope that is limited to the MANET. Global address: A node's IP address in the Internet, typically resolvable from a DNS name. The address identifies the mobile node, and is used for communication to the Internet. It can also be used for communication within the MANET. IGW advertisement: A message to disseminate IGW information to a MANET. Mase & Owada Expires January 10, 2008 [Page 6] Internet-Draft GAP July 2007 3. Overview We consider a MANET that MAY have one or more MNs, that have a wired or wireless interface to the fixed Internet in addition to the wireless interface to the MNs. The points of attachment of MNs to the Internet are termed as "MANET border gateways (MBGs)," and they are assigned global prefix from their Access Routers (ARs). In the conventional methods, any MBG is qualified to be an Internet gateway (IGW). On the other hand, in this document, only a subset of MBGs MAY work as the IGWs. This MBG is named Anhor MBG. Specifically, a MBG MAY work as the IGW for outbound (from the MANET to the Internet) traffic but MUST not work as the IGW for inbound (from the Internet to the MANET) traffic, except when it is Anchor MBG. When A MBG itself communicates as the source or destination with the Internet nodes, it SHOULD directly send and receive packets to and from the Internet nodes without depending on the Anchor MBG, since they are directly attached to the Internet. Typically, a single Anchor MBG is used for a MANET, even if multiple MBGs exist. This feature is called "Gateway Aggregation." In rare occasions, two or more MBGs MAY be used, but the number of the Anchor MBGs SHOULD be kept minimized. It is assumed that each MN has configured a MANET-local address. A MN needs a globally routable address (care-of-address) with prefix advertised by one of the ARs so that it can receive data packets from an Internet node. Some Autoconf protocol MAY be used for global prefix advertisement and address assignment to the MANET MNs. But global address assignment to the MANET MNs is out of scope of this specification. Unlike the conventional methods, MANET routing protocol runs not only on MNs but on MBGs as well and routing control messages and data packets within the MANET are tunneled between MBGs in both directions. This can be achieved by IP-in-IP encapsulation [6]. ARs advertise their global prefix and MBGs in turn advertise them to the MNs using some autoconf protocol. Upon receiving the prefix from an AR, an MN configures its care-of-address and can receive packets from an Internet node through the MBG. In the proposed method, multiple MBGs connected to the same MANET SHOULD select the same MBG named Anchor MBG in the distributed- fashion. When an MBG starts to work, it first becomes Anchor MBG, and at the same time, it continues monitoring whether there exists another Anchor MBG serving the MANET based on the default route information it receives through the MANET. If it is the case, it generate Gateway Aggregation Request and try to establishes a tunnel with the newly detected Anchor MBG through the Internet. In this architecture, MBGs, that are attached to the Internet, are not directly used as the IGWs unlike the conventional Internet access Mase & Owada Expires January 10, 2008 [Page 7] Internet-Draft GAP July 2007 architecture of the MANET and, therefore, a communication path between a MN and an Internet node may be longer since it has to pass through the selected IGW. However, it is natural that MNs exist in a geographically limited area and this path overhead can be negligible. It is possible that two independent MANETs, each of which has a different Anchor MBG, merges to form a single connected MANET. In this case, the MANET routing protocol of each Anchor MBG can be aware of each other by receiving the default route advertisements through the MANET. After that, they establish a tunnel to each other so that they are neighbors of each other in the MANET. It is also possible that two or more MBGs are installed in the same MANET simultaneously. In this case, each MBGs may become itself as Anchor MBG, but they soon detect and aggregate each other. as the results, single Anchor MBG remains in the MANET. Each MBG has its own prefix and distributes its prefix within the MANET by using some of Autoconf protocol. An MN may configure its care-of-address using Autoconf protocol from one of the MBGs. It then can continue to use this care-of-address throughout the MANET and no address change is required. There are notable differences between the conventional methods [2]-[5] and the GAP. First, in conventional methods, an MN with attachment to the Internet is simultaneously an IGW. On the other hand, in GAP, IGW is selected from ARs and the number of the IGWs is kept minimized. In the ideal case, only a single IGW is used to disseminate its own prefix. Second, in conventional method, an MN may change its global address for communication efficiency under multiple IGWs environment and special care must be taken to suppress route reconstruction [4], [5], giving rise to overhead within the MANET. On the other hand, in the GAP, an MN does not have to change its global address, once assigned, even if multiple IGWs exist and AR selection is automatically performed by making best use of the MANET routing protocol. As the result, no route reconstruction occurs. This benefit is brought at the cost of overhead within the Internet (possible detours and tunneling). This shift of the overhead for suppressing route reconstruction from within MANET to within the Internet is beneficial since bandwidth resource in the MANET is more expensive than that in the Internet. Network overview of GAP is shown in Fig. 1. and a procedure of gateway aggregation of MBGs is presented in Fig. 2. Mase & Owada Expires January 10, 2008 [Page 8] Internet-Draft GAP July 2007 +------------------------------------------------------+ | ====== Internet ====== | +----+-----//------\\-------+-------//------\\-----+---+ | || Tunnel || | || Tunnel || | +--+--+ || || +--+--+ || || +--+--+ | AR | || || | AR | || || | AR | +--+--+ || || +--+--+ || || +--+--+ | // \\ | // \\ | +--+--// \\----+----// \\--+--+ ......| MBG |.............|Anchor MBG |(IGW)........| MBG |... . +-----+ +-----------+ +-----+ . . +----+ . . +----+ | MN | +----+ . . | MN | +----+ +----+ | MN | . . +----+ | MN | +----+ . . +----+ . . +----+ +----+ . . | NM | | MN | . . +----+ Mobile Ad Hoc Network +----+ . .............................................................. Figure 1: Network overview of Gateway Aggregation Protocol. +------+ +------+ +------+ | MBG1 | | MBG2 | | MBG3 | +--+---+ +--+---+ +--+---+ | GA Request | Detect MBG1 | |<-----------------------+ | | GA Response | | +----------------------->| | | Create Tunnel | | |/----------------------\| | |\----------------------/| GA Request | Detect MBG2 + MANET protocol stops |<----------------------+ | advertising | GA Response | | default route +---------------------->| | | Create Tunnel | | |/---------------------\| | |\---------------------/| | | + MANET protocol | | | stops advertising | | | default route Figure 2: A procedure of global address configuration of a node. Mase & Owada Expires January 10, 2008 [Page 9] Internet-Draft GAP July 2007 4. GAP Packet and Message Format This section defines the format of the GAP packet and message format. Packet and message format used by this protocol is defined in [8]. This protocol specifies one message type, the GAP message. 4.1. Gateway Aggregation Request A GA request message must contain: o Originator Address o An address block o A message TLV block with TYPE = GA_REQUEST o A message TLV block with TYPE = NUM_OF_TUNNELS and VALUE 4.2. Gateway Aggregation Response A GA response message must contain: o Originator Address o An address block o A message TLV block with TYPE = GA_RESPONSE o An message TLV block with TYPE = NUM_OF_TUNNELS and VALUE 4.3. Gateway Reconfigure Request A Gateway reconfigure request message must contain: o Originator Address o An address block o A message TLV block with TYPE = GW_RECONFIGURE Mase & Owada Expires January 10, 2008 [Page 10] Internet-Draft GAP July 2007 5. Gateway Aggregation Information Base Each MBG maintains a Gateway Aggregation Information Base that records information about addresses of MBGs. 5.1. Gateway Aggregation Set A MBG's Gateway Aggregation Set records all originator addresses of MBGs that has a 1-hop connectivity through a tunnel. It consist of Gateway Aggregation tuples, each representing a MBG's originator address. (A_gateway_iface_address) where: A_gateway_iface_address is an address of a MBG whose tunnel is already established. Mase & Owada Expires January 10, 2008 [Page 11] Internet-Draft GAP July 2007 6. Gateway Aggregation Information Base Changes A change in the Gateawy Aggregation Set is detected when: Gateway Reconfiguration Request message is received and reconfigured tunnel. Tunnel breakage is detected. The Gateway Aggregation Set MUST be updated. Mase & Owada Expires January 10, 2008 [Page 12] Internet-Draft GAP July 2007 7. Protocol Operation 7.1. Protocol Operation Overview This protocol only specifies how to aggregate MBGs at a Internet connected MANET. Thus, how MNs in the MANET get global prefixes or how MBGs get global prefixes is out of scope in this specification. A MBG is assigned a global prefix from its AR by some way (i.e. router advertisement mechanism or DHCP might be used), and a MBG advertises its global prefix to the attached MANET. At the same time, the MANET routing protocol which is run on the MBGs are configured to announce to the MANET the default route and becomes Anchor MBG itself if there are no Anchor MBG exists in the MANET. The MANET routing protocol should always check whether there is another Anchor MBG that is announcing the default route in the MANET or not. If a Anchor MBG detects another Anchor MBG which is announcing the default route, the Anchor MBG sends a Gateway Aggregation Request message to the other Anchor MBG and tries to establish an IP-in-IP tunnel through the internet. After tunnel establishment, one of the Anchor MBG reconfigures its MANET routing protocol to stop announcing the default route and becomes normal MBG itself. The MANET messages are able to be exchanged through the tunnel and MNs can communicate to an Internet node by way of the nearest MBG that is selected by the MANET routing protocol. It is also possible for MNs that one global IP address first assigned from the nearest ARs can be used continuously even if the MN moves and MANET routing protocol changes the path betwem the MN and an Internet node through an alternative MBG. 7.2. Global Prefix Assgnment to MN MBG advertises global prefix to the attached MANET and MN can be assigned one or more global addresses by use of Autoconf protocol. How MN gets global address is out of scope of this specification. 7.3. Other MBG Detection In this protocol, MANET routing protocol is used to detect other Anchor MBGs that is announcing the default route. In proactive routing protocols such as OLSRv2 or OLSR, it is easy to know of other Anchor MBGs because proactive routing protocol advertises the default route continuously. But for reactive routing protocols such as DYMO or AODV, Anchor MBGs MAY be require to generate route requests to the default route periodically. When the MANET routing protocol newly detects other Anchor MBG, the MANET routing protocol gives the new Anchor MBG information (such as global IP address list of MBG) to the GAP protocol. Mase & Owada Expires January 10, 2008 [Page 13] Internet-Draft GAP July 2007 7.4. Gateway Aggregation Request Gateway Aggregation Request messages are generated by the Anchor MBG to the newly detected Anchor MBG from the interface that is connected to the AR when the Anchor MBG received a newly detected Anchor MBG information from MANET routing protocol. The Gateway Aggregation Request messages include the number of tunnels the request-originator MBG has. 7.5. Gateway Aggregation Response The MBG that received the Gateway Aggregation Request generates a Gateway Aggregation Response message in response to the Gateway Aggregation Request message. The Gateway Aggregation Response message also includes the number of tunnel information that the response-originator MBG has. 7.6. Tunnel Establishment between MBGs After exchanging Gateway Aggregation Request/Response messages, each of the corresponding Anchor MBGs create an IP-in-IP tunnel through the interface that is connected to their ARs. After the tunnel is established, the logical inner-tunnel interface is attached to the MANET interface list, and MANET control messages are transmitted through this tunnel. At the same time as this, one of these two Anchor MBGs which has less tunnels compared to the other stops advertising the default route to the MANET and becomes normal MBG. If these two Anchor MBGs have the same number of tunnels, then the MBG which generated the Gateway Aggregation Response message stops advertising the default route to the MANET. The ultimate result is that there will exist only one Anchor MBG that advertises the default route in the MANET. 7.7. Data Packet Forwarding Data packets are forwarded as determined by the MANET routing protocol. The nearest MBG is selected by the MANET routing protocol when the data packet to the Internet needs to be forwarded. The nearest MBG MAY forward the data packet to its AR, or MAY forward it to the Anchor MBG through the tunnel according to the MANET routing policy. 7.8. Gateway Reconfiguration message generation This message is generated only when the tunnels need to be reconfigured. This message should be generated in the following cases: Mase & Owada Expires January 10, 2008 [Page 14] Internet-Draft GAP July 2007 Two or more MANETs each having Anchor MBG and multiple MBG are merged. Tunnel breakage is detected. When a MBG receives this message, the MBG SHOULD send a Gateway Aggregate Request message to the originator of the message to reconfigure the tunnel between its originator and itself. If a candidate address is included in this message, the MBG SHOULD send a Gateway Aggregation Request message to the candidate address. Mase & Owada Expires January 10, 2008 [Page 15] Internet-Draft GAP July 2007 8. IANA Considerations 8.1. Message Types This specification defines three message types, which must be allocated from the "Assigned Message Types" repository of [1]. +----------------+----------+------------------------------------------+ | Name | Type | Description | +----------------+----------+------------------------------------------+ | GA_REQUEST | TBD | Gateway Aggregation Request message that | | | | is used for requesting tunnel creation. | | | | | | GA_RESPONSE | TBD | Gateway Aggregation Response message that| | | | is used for responding to the request. | | | | | | GW_RECONFIGURE | TBD | Gateway reconfigure message. | | | | When this message is received, the MBG | | | | MAY reconfigure the tunnel that is | | | | already established. | +----------------+----------+------------------------------------------+ 8.2. TLV Types This specification defines one Message TLV Block type, which must be allocated from the "Assigned Message TLV Types" repository of [1]. +----------------+----------+------------------------------------------+ | Name | Type | Description | +----------------+----------+------------------------------------------+ | TUNNEL_COUNT | TBD | Specifies how many tunnels the MBG has. | +----------------+----------+------------------------------------------+ Mase & Owada Expires January 10, 2008 [Page 16] Internet-Draft GAP July 2007 9. Security Considerations This document does not specify any special security measure. Mase & Owada Expires January 10, 2008 [Page 17] Internet-Draft GAP July 2007 10. Acknowledgements This work was funded by Strategic Information and Communications R&D Promotion Program (SCOPE), Ministry of Internal Affairs and Communications, Japan. Mase & Owada Expires January 10, 2008 [Page 18] Internet-Draft GAP July 2007 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [2] Wakikawa, R., "Global connectivity for IPv6 Mobile Ad Hoc Networks", draft-wakikawa-manet-globalv6-05 (work in progress), March 2006. [3] Jelger, C., "Gateway and address autoconfiguration for IPv6 adhoc networks", draft-jelger-manet-gateway-autoconf-v6-02 (work in progress), April 2004. [4] Ruffino, S. and P. Stupar, "Automatic configuration of IPv6 addresses for MANET with multiple gateways (AMG)", draft-ruffino-manet-autoconf-multigw-03 (work in progress), June 2006. [5] Hofmann, P., "Multihop Radio Access Network (MRAN) Protocol Specification", draft-hofmann-autoconf-mran-00 (work in progress), March 2006. [6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [7] Macker, J., "Simplified Multicast Forwarding for MANET", draft-ietf-manet-smf-05 (work in progress), June 2007. [8] Clausen, T., "Generalized MANET Packet/Message Format", draft-ietf-manet-packetbb-07 (work in progress), July 2007. Mase & Owada Expires January 10, 2008 [Page 19] Internet-Draft GAP July 2007 Authors' Addresses Kenichi Mase Niigata University Phone: +81 25 262 7446 Email: mase@ie.niigata-u.ac.jp URI: http://www.net.ie.niigata-u.ac.jp/ Yasunori Owada Niigata University Phone: +81 70 5458 7470 Email: owada@ie.niigata-u.ac.jp URI: http://www.net.ie.niigata-u.ac.jp/~yowada/ Mase & Owada Expires January 10, 2008 [Page 20] Internet-Draft GAP July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Mase & Owada Expires January 10, 2008 [Page 21]