From 31985cb5090f9afd30b99b4a854a5ea35b7580e2 Mon Sep 17 00:00:00 2001 From: Othmar Gsenger Date: Mon, 16 Apr 2007 14:08:42 +0000 Subject: namensgebung --- draft-gsenger-anycast-relay-00.txt | 672 ------------------------------------- internet-draft-anytun.txt | 672 +++++++++++++++++++++++++++++++++++++ 2 files changed, 672 insertions(+), 672 deletions(-) delete mode 100644 draft-gsenger-anycast-relay-00.txt create mode 100644 internet-draft-anytun.txt diff --git a/draft-gsenger-anycast-relay-00.txt b/draft-gsenger-anycast-relay-00.txt deleted file mode 100644 index 588d4d6..0000000 --- a/draft-gsenger-anycast-relay-00.txt +++ /dev/null @@ -1,672 +0,0 @@ - - - -Network Working Group O. Gsenger -Internet-Draft March 2007 -Expires: September 2, 2007 - - - Anycast stream relaying - draft-gsenger-anycast-relay-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 September 2, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 1] - -Internet-Draft Anycast stream relaying March 2007 - - -Abstract - - The anycast tunneling (anytun) protocol defines a protocol used for - communication between unicast clients and anycast servers. It can be - used for tunneling information between 2 clients over the servers or - in relay mode to transmit data form the client over the servers to a - third party not using the protocol and vice versa. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 2] - -Internet-Draft Anycast stream relaying March 2007 - - -1. Introduction - - anytun defines a Host Anycast Service as defined in rfc1546. It can - be used to build high scalable and redundant tunnel services. It - supports both UDP and TCP connections. Additionally to the - possibility of establashing an unicast TCP connection over an anycast - address as suggested in rfc1546, it supports real anycast TCP - connections with state syncronisation and heuristic state forecast. - It also has a relay mode, that makes it possible, that only one of - the connection endpoints has to use the anytun protocol. This can be - used to make connections through Firewalls or behind a NAT Router - - RFC3068 [1] DTD. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 3] - -Internet-Draft Anycast stream relaying March 2007 - - -2. Operation modes - - This section gives an overview of possible operation modes und usage - scenarios. Please note, that the protocols used in the figures are - only examples and that anytun itself does not care about either - transport protocols or encapsulated protocols. Routing and network - address translation is not done by anytun. Each implemetation MAY - choose it's own way of doing this task (e.g. using functions provided - by the operating system). Anytun is used to establish and controll - tunnnels, to encapsulate and encrypt data. - -2.1. Tunnel modes - -2.1.1. Tunneling Mode - - An example of anytun used in tunnel mode - - ----------- ----------- - | RTP | ---------- | RTP | - ----------- -> |server 1| -> ----------- - | UDP | ---------- | UDP | - ----------- ----------- - ----- | IPv6 | ---------- | IPv6 | ----- - | | -> ----------- -> |server 2| -> ----------- -> | | - ----- | anytun | ---------- | anytun | ----- - ##### ----------- ----------- ##### - | UDP | ---------- | UDP | - client 1 ----------- -> |server 3| -> ----------- client 2 - | IPv4 | ---------- | IPv4 | - ----------- ----------- - | ... | anycast | ... | - - Figure 1 - - In tunneling mode the payload of the anytun packet is transmitted - from one unicast host to the anycast server. This server makes a - routing descision based on the underlying protocol and transmits a - new anytun package to one or more clients depending on the routing - descition. The server MAY also route the packet to a directly - connected network or a service running on the server, but please - note, that this is only usefull for anycast host services like DNS - and that the services HAVE TO be running on all servers in order to - work. - - - - - - - - -Gsenger Expires September 2, 2007 [Page 4] - -Internet-Draft Anycast stream relaying March 2007 - - -2.1.2. Open tunnel mode - - An example of anytun used in open tunnel mode - - ----------- - | RTP | ---------- - ----------- -> |server 1| -> - | UDP | ---------- ----------- - ----------- | RTP | - ----- | IPv6 | ---------- ----------- ----- - | | -> ----------- -> |server 2| -> | UDP* | -> | | - ----- | anytun | ---------- ----------- ----- - ##### ----------- | IPv6* | ##### - | UDP | ---------- ----------- - client 1 ----------- -> |server 3| -> | ... | host - | IPv4 | ---------- not using - ----------- anytun - | ... | anycast - *changed source address - or port - - Figure 2 - - In open tunnel mode only one of two clients talking to each other - over the servers MUST use the anytun protocol. When a client using - the anytun protocol wants to tunnel data, it is building a connection - to the anycast servers using the anytun protocol. The anycast - servers relay the encapsulated packages directly to the destination - without using the anytun protocol. The source address of the - datagramm HAS TO be changed to the anycast address of the server. - The anytun servers act like a source NAT router, therefor for the - destination it saems that it is talking to the client directly. - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 5] - -Internet-Draft Anycast stream relaying March 2007 - - -2.1.3. relay mode - - An example of anytun used in relay mode - - ----------- - ----- | RTP | ---------- - | | -> ----------- -> |server 1| -> - ----- | UDP** | ---------- ----------- - ##### ----------- | RTP | - | IPv6**| ---------- ----------- ----- - host ----------- -> |server 2| -> | UDP* | -> | | - not using | ... | ---------- ----------- ----- - anytun | IPv6* | ##### - ---------- ----------- - ----------- -> |server 3| | ... | host - ----- | anytun | ---------- not using - | | -> ----------- anytun - ----- | IPv4 | anycast - ##### ----------- - connection| ... | - controller - - *changed source address or port - **changed destination address or port - - Figure 3 - - In relay mode the anycast serveres directly repaet the packetes of - clients, only the source and destination addresses are changed. The - anytun protocol is only used for controll messages, but not fr - encapsulation. - -2.2. Transport modes - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 6] - -Internet-Draft Anycast stream relaying March 2007 - - -2.2.1. anycast udp mode - - An example of anytun used with udp transport - - ----------- ----------- - | RTP | ---------- | RTP | - ----------- -> |server 1| -> ----------- - | UDP | ---------- | UDP | - ----------- ----------- - ----- | IPv6 | ---------- | IPv6 | ----- - | | -> ----------- -> |server 2| -> ----------- -> | | - ----- | anytun | ---------- | anytun | ----- - ##### ----------- ----------- ##### - | UDP | ---------- | UDP | - client 1 ----------- -> |server 3| -> ----------- client 2 - | IPv4 | ---------- | IPv4 | - ----------- ----------- - | ... | anycast | ... | - - Figure 4 - - In anycast udp mode the data between clients and anycast serveres is - carried by udp packets. Packets are routed by the serveres from one - client to another. Because udp is stateless no inforamtion has to be - syncronised - -2.2.2. anycast light udp mode - - An example of anytun used with udp transport - - ----------- ----------- - | RTP | ---------- | RTP | - ----------- -> |server 1| -> ----------- - | UDP | ---------- | UDP | - ----------- ----------- - ----- | IPv6 | ---------- | IPv6 | ----- - | | -> ----------- -> |server 2| -> ----------- -> | | - ----- | anytun | ---------- | anytun | ----- - ##### ----------- ----------- ##### - |lightUDP | ---------- |lightUDP | - client 1 ----------- -> |server 3| -> ----------- client 2 - | IPv4 | ---------- | IPv4 | - ----------- ----------- - | ... | anycast | ... | - - Figure 5 - - The light UDP mode is neerly the same as the normal UDP mode, the - - - -Gsenger Expires September 2, 2007 [Page 7] - -Internet-Draft Anycast stream relaying March 2007 - - - only difference is, that the udp size is set to the udp header lenght - and not to the length of the full packet and therefor the checksum is - only calculated for the udp header itself. So there is no error - correction or detection done on the payload. This can be usefull if - realtime data is beeing transimittet or the tunneled protocol does - error correction/detection by itself. - -2.2.3. Protocol specification - -2.2.3.1. Header format - -2.2.3.2. Protocol field - - The protocol field defines the payload protocol. ETHER TYPE protocol - numerbers are used. http://www.iana.org/assignments/ethernet-numbers - . The values 0000-05DC are reserverd and not used at the moment. - - Some exmples for protocol types - - HEX - 0000 Reserved - .... Reserved - 05DC Reserved - 0800 Internet IP (IPv4) - 6558 transparent ethernet bridging - 86DD IPv6 - - Figure 6 - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 8] - -Internet-Draft Anycast stream relaying March 2007 - - -Appendix A. The appan - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 9] - -Internet-Draft Anycast stream relaying March 2007 - - -3. References - - [1] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", - RFC 3068, June 2001. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 10] - -Internet-Draft Anycast stream relaying March 2007 - - -Author's Address - - Othmar Gsenger - Sporgasse 6 - Graz 8010 - AT - - Phone: - Email: otti@wirdorange.org - URI: http://anytun.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires September 2, 2007 [Page 11] - -Internet-Draft Anycast stream relaying March 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). - - - - - -Gsenger Expires September 2, 2007 [Page 12] - diff --git a/internet-draft-anytun.txt b/internet-draft-anytun.txt new file mode 100644 index 0000000..588d4d6 --- /dev/null +++ b/internet-draft-anytun.txt @@ -0,0 +1,672 @@ + + + +Network Working Group O. Gsenger +Internet-Draft March 2007 +Expires: September 2, 2007 + + + Anycast stream relaying + draft-gsenger-anycast-relay-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 September 2, 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 1] + +Internet-Draft Anycast stream relaying March 2007 + + +Abstract + + The anycast tunneling (anytun) protocol defines a protocol used for + communication between unicast clients and anycast servers. It can be + used for tunneling information between 2 clients over the servers or + in relay mode to transmit data form the client over the servers to a + third party not using the protocol and vice versa. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 2] + +Internet-Draft Anycast stream relaying March 2007 + + +1. Introduction + + anytun defines a Host Anycast Service as defined in rfc1546. It can + be used to build high scalable and redundant tunnel services. It + supports both UDP and TCP connections. Additionally to the + possibility of establashing an unicast TCP connection over an anycast + address as suggested in rfc1546, it supports real anycast TCP + connections with state syncronisation and heuristic state forecast. + It also has a relay mode, that makes it possible, that only one of + the connection endpoints has to use the anytun protocol. This can be + used to make connections through Firewalls or behind a NAT Router + + RFC3068 [1] DTD. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 3] + +Internet-Draft Anycast stream relaying March 2007 + + +2. Operation modes + + This section gives an overview of possible operation modes und usage + scenarios. Please note, that the protocols used in the figures are + only examples and that anytun itself does not care about either + transport protocols or encapsulated protocols. Routing and network + address translation is not done by anytun. Each implemetation MAY + choose it's own way of doing this task (e.g. using functions provided + by the operating system). Anytun is used to establish and controll + tunnnels, to encapsulate and encrypt data. + +2.1. Tunnel modes + +2.1.1. Tunneling Mode + + An example of anytun used in tunnel mode + + ----------- ----------- + | RTP | ---------- | RTP | + ----------- -> |server 1| -> ----------- + | UDP | ---------- | UDP | + ----------- ----------- + ----- | IPv6 | ---------- | IPv6 | ----- + | | -> ----------- -> |server 2| -> ----------- -> | | + ----- | anytun | ---------- | anytun | ----- + ##### ----------- ----------- ##### + | UDP | ---------- | UDP | + client 1 ----------- -> |server 3| -> ----------- client 2 + | IPv4 | ---------- | IPv4 | + ----------- ----------- + | ... | anycast | ... | + + Figure 1 + + In tunneling mode the payload of the anytun packet is transmitted + from one unicast host to the anycast server. This server makes a + routing descision based on the underlying protocol and transmits a + new anytun package to one or more clients depending on the routing + descition. The server MAY also route the packet to a directly + connected network or a service running on the server, but please + note, that this is only usefull for anycast host services like DNS + and that the services HAVE TO be running on all servers in order to + work. + + + + + + + + +Gsenger Expires September 2, 2007 [Page 4] + +Internet-Draft Anycast stream relaying March 2007 + + +2.1.2. Open tunnel mode + + An example of anytun used in open tunnel mode + + ----------- + | RTP | ---------- + ----------- -> |server 1| -> + | UDP | ---------- ----------- + ----------- | RTP | + ----- | IPv6 | ---------- ----------- ----- + | | -> ----------- -> |server 2| -> | UDP* | -> | | + ----- | anytun | ---------- ----------- ----- + ##### ----------- | IPv6* | ##### + | UDP | ---------- ----------- + client 1 ----------- -> |server 3| -> | ... | host + | IPv4 | ---------- not using + ----------- anytun + | ... | anycast + *changed source address + or port + + Figure 2 + + In open tunnel mode only one of two clients talking to each other + over the servers MUST use the anytun protocol. When a client using + the anytun protocol wants to tunnel data, it is building a connection + to the anycast servers using the anytun protocol. The anycast + servers relay the encapsulated packages directly to the destination + without using the anytun protocol. The source address of the + datagramm HAS TO be changed to the anycast address of the server. + The anytun servers act like a source NAT router, therefor for the + destination it saems that it is talking to the client directly. + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 5] + +Internet-Draft Anycast stream relaying March 2007 + + +2.1.3. relay mode + + An example of anytun used in relay mode + + ----------- + ----- | RTP | ---------- + | | -> ----------- -> |server 1| -> + ----- | UDP** | ---------- ----------- + ##### ----------- | RTP | + | IPv6**| ---------- ----------- ----- + host ----------- -> |server 2| -> | UDP* | -> | | + not using | ... | ---------- ----------- ----- + anytun | IPv6* | ##### + ---------- ----------- + ----------- -> |server 3| | ... | host + ----- | anytun | ---------- not using + | | -> ----------- anytun + ----- | IPv4 | anycast + ##### ----------- + connection| ... | + controller + + *changed source address or port + **changed destination address or port + + Figure 3 + + In relay mode the anycast serveres directly repaet the packetes of + clients, only the source and destination addresses are changed. The + anytun protocol is only used for controll messages, but not fr + encapsulation. + +2.2. Transport modes + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 6] + +Internet-Draft Anycast stream relaying March 2007 + + +2.2.1. anycast udp mode + + An example of anytun used with udp transport + + ----------- ----------- + | RTP | ---------- | RTP | + ----------- -> |server 1| -> ----------- + | UDP | ---------- | UDP | + ----------- ----------- + ----- | IPv6 | ---------- | IPv6 | ----- + | | -> ----------- -> |server 2| -> ----------- -> | | + ----- | anytun | ---------- | anytun | ----- + ##### ----------- ----------- ##### + | UDP | ---------- | UDP | + client 1 ----------- -> |server 3| -> ----------- client 2 + | IPv4 | ---------- | IPv4 | + ----------- ----------- + | ... | anycast | ... | + + Figure 4 + + In anycast udp mode the data between clients and anycast serveres is + carried by udp packets. Packets are routed by the serveres from one + client to another. Because udp is stateless no inforamtion has to be + syncronised + +2.2.2. anycast light udp mode + + An example of anytun used with udp transport + + ----------- ----------- + | RTP | ---------- | RTP | + ----------- -> |server 1| -> ----------- + | UDP | ---------- | UDP | + ----------- ----------- + ----- | IPv6 | ---------- | IPv6 | ----- + | | -> ----------- -> |server 2| -> ----------- -> | | + ----- | anytun | ---------- | anytun | ----- + ##### ----------- ----------- ##### + |lightUDP | ---------- |lightUDP | + client 1 ----------- -> |server 3| -> ----------- client 2 + | IPv4 | ---------- | IPv4 | + ----------- ----------- + | ... | anycast | ... | + + Figure 5 + + The light UDP mode is neerly the same as the normal UDP mode, the + + + +Gsenger Expires September 2, 2007 [Page 7] + +Internet-Draft Anycast stream relaying March 2007 + + + only difference is, that the udp size is set to the udp header lenght + and not to the length of the full packet and therefor the checksum is + only calculated for the udp header itself. So there is no error + correction or detection done on the payload. This can be usefull if + realtime data is beeing transimittet or the tunneled protocol does + error correction/detection by itself. + +2.2.3. Protocol specification + +2.2.3.1. Header format + +2.2.3.2. Protocol field + + The protocol field defines the payload protocol. ETHER TYPE protocol + numerbers are used. http://www.iana.org/assignments/ethernet-numbers + . The values 0000-05DC are reserverd and not used at the moment. + + Some exmples for protocol types + + HEX + 0000 Reserved + .... Reserved + 05DC Reserved + 0800 Internet IP (IPv4) + 6558 transparent ethernet bridging + 86DD IPv6 + + Figure 6 + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 8] + +Internet-Draft Anycast stream relaying March 2007 + + +Appendix A. The appan + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 9] + +Internet-Draft Anycast stream relaying March 2007 + + +3. References + + [1] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", + RFC 3068, June 2001. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 10] + +Internet-Draft Anycast stream relaying March 2007 + + +Author's Address + + Othmar Gsenger + Sporgasse 6 + Graz 8010 + AT + + Phone: + Email: otti@wirdorange.org + URI: http://anytun.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 11] + +Internet-Draft Anycast stream relaying March 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). + + + + + +Gsenger Expires September 2, 2007 [Page 12] + -- cgit v1.2.3