summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorfukachan <fukachan>2002-02-17 03:51:24 +0000
committerfukachan <fukachan>2002-02-17 03:51:24 +0000
commit1cf75fdb549aa3bd542048c2854c28ccdd9102b9 (patch)
treefbdc8cb601964482466ced35fd7978b50081ba96
parent93756d876d2fc4e2eb81f698d3eb46462bfdeb3e (diff)
downloadfml8-1cf75fdb549aa3bd542048c2854c28ccdd9102b9.tar.gz
fml8-1cf75fdb549aa3bd542048c2854c28ccdd9102b9.tar.bz2
fml8-1cf75fdb549aa3bd542048c2854c28ccdd9102b9.zip
update rfc(s) and the relations:
rfc3234.txt rfc2874.txt rfc1886.txt rfc3152.txt rfc3207.txt rfc2772.txt rfc2766.txt rfc2553.txt rfc2133.txt rfc2546.txt
Diffstat
-rw-r--r--Documentation/en/rfc/index.html62
-rw-r--r--Documentation/en/rfc/rfc-index.txt589
-rw-r--r--Documentation/en/rfc/rfc1886.txt268
-rw-r--r--Documentation/en/rfc/rfc2133.txt1795
-rw-r--r--Documentation/en/rfc/rfc2546.txt563
-rw-r--r--Documentation/en/rfc/rfc2553.txt2299
-rw-r--r--Documentation/en/rfc/rfc2766.txt1179
-rw-r--r--Documentation/en/rfc/rfc2772.txt787
-rw-r--r--Documentation/en/rfc/rfc2874.txt1123
-rw-r--r--Documentation/en/rfc/rfc3152.txt227
-rw-r--r--Documentation/en/rfc/rfc3207.txt507
-rw-r--r--Documentation/en/rfc/rfc3234.txt1515
12 files changed, 10639 insertions, 275 deletions
diff --git a/Documentation/en/rfc/index.html b/Documentation/en/rfc/index.html
index eaae1326..bd546e71 100644
--- a/Documentation/en/rfc/index.html
+++ b/Documentation/en/rfc/index.html
@@ -1,5 +1,10 @@
<UL>
<LI>
+<A NAME="RFC3234" HREF="rfc3234.txt">RFC3234</A>
+"Middleboxes: Taxonomy and Issues"
+<BR> Updates:
+none<BR>
+<LI>
<A NAME="RFC3226" HREF="rfc3226.txt">RFC3226</A>
"DNSSEC and IPv6 A6 aware server/resolver message size requirements"
<BR> Updates:
@@ -7,11 +12,13 @@
<A HREF="#RFC3008">RFC3008</A>
<A HREF="#RFC3007">RFC3007</A>
<A HREF="#RFC2931">RFC2931</A>
+<A HREF="#RFC2874">RFC2874</A>
<A HREF="#RFC2535">RFC2535</A>
<A HREF="#RFC2181">RFC2181</A>
<A HREF="#RFC2137">RFC2137</A>
<A HREF="#RFC2136">RFC2136</A>
<A HREF="#RFC2065">RFC2065</A>
+<A HREF="#RFC1886">RFC1886</A>
<A HREF="#RFC1123">RFC1123</A>
<A HREF="#RFC1035">RFC1035</A>
<A HREF="#RFC1034">RFC1034</A>
@@ -25,6 +32,12 @@
<BR> Updates:
none<BR>
<LI>
+<A NAME="RFC3207" HREF="rfc3207.txt">RFC3207</A>
+"SMTP Service Extension for Secure SMTP over Transport Layer Security"
+<BR> Updates:
+<A HREF="#RFC2487">RFC2487</A>
+<BR>
+<LI>
<A NAME="RFC3161" HREF="rfc3161.txt">RFC3161</A>
"Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)"
<BR> Updates:
@@ -36,6 +49,18 @@ none<BR>
<A HREF="#RFC2015">RFC2015</A>
<BR>
<LI>
+<A NAME="RFC3152" HREF="rfc3152.txt">RFC3152</A>
+"Delegation of IP6.ARPA"
+<BR> Updates:
+<A HREF="#RFC2874">RFC2874</A>
+<A HREF="#RFC2772">RFC2772</A>
+<A HREF="#RFC2766">RFC2766</A>
+<A HREF="#RFC2553">RFC2553</A>
+<A HREF="#RFC2546">RFC2546</A>
+<A HREF="#RFC2133">RFC2133</A>
+<A HREF="#RFC1886">RFC1886</A>
+<BR>
+<LI>
<A NAME="RFC3090" HREF="rfc3090.txt">RFC3090</A>
"DNS Security Extension Clarification on Zone Status"
<BR> Updates:
@@ -96,6 +121,11 @@ none<BR>
<BR> Updates:
none<BR>
<LI>
+<A NAME="RFC2874" HREF="rfc2874.txt">RFC2874</A>
+"DNS Extensions to Support IPv6 Address Aggregation and Renumbering"
+<BR> Updates:
+none<BR>
+<LI>
<A NAME="RFC2870" HREF="rfc2870.txt">RFC2870</A>
"Root Name Server Operational Requirements"
<BR> Updates:
@@ -134,6 +164,17 @@ none<BR>
<A HREF="#RFC0788">RFC0788</A>
<BR>
<LI>
+<A NAME="RFC2772" HREF="rfc2772.txt">RFC2772</A>
+"6Bone Backbone Routing Guidelines"
+<BR> Updates:
+<A HREF="#RFC2546">RFC2546</A>
+<BR>
+<LI>
+<A NAME="RFC2766" HREF="rfc2766.txt">RFC2766</A>
+"Network Address Translation - Protocol Translation (NAT-PT)"
+<BR> Updates:
+none<BR>
+<LI>
<A NAME="RFC2646" HREF="rfc2646.txt">RFC2646</A>
"The Text/Plain Format Parameter"
<BR> Updates:
@@ -148,6 +189,17 @@ none<BR>
<BR> Updates:
none<BR>
<LI>
+<A NAME="RFC2553" HREF="rfc2553.txt">RFC2553</A>
+"Basic Socket Interface Extensions for IPv6"
+<BR> Updates:
+<A HREF="#RFC2133">RFC2133</A>
+<BR>
+<LI>
+<A NAME="RFC2546" HREF="rfc2546.txt">RFC2546</A>
+"6Bone Routing Practice"
+<BR> Updates:
+none<BR>
+<LI>
<A NAME="RFC2535" HREF="rfc2535.txt">RFC2535</A>
"Domain Name System Security Extensions"
<BR> Updates:
@@ -252,6 +304,11 @@ none<BR>
<BR> Updates:
none<BR>
<LI>
+<A NAME="RFC2133" HREF="rfc2133.txt">RFC2133</A>
+"Basic Socket Interface Extensions for IPv6"
+<BR> Updates:
+none<BR>
+<LI>
<A NAME="RFC2065" HREF="rfc2065.txt">RFC2065</A>
"Domain Name System Security Extensions"
<BR> Updates:
@@ -359,6 +416,11 @@ none<BR>
<BR> Updates:
none<BR>
<LI>
+<A NAME="RFC1886" HREF="rfc1886.txt">RFC1886</A>
+"DNS Extensions to support IP version 6"
+<BR> Updates:
+none<BR>
+<LI>
<A NAME="RFC1876" HREF="rfc1876.txt">RFC1876</A>
"A Means for Expressing Location Information in the Domain Name System"
<BR> Updates:
diff --git a/Documentation/en/rfc/rfc-index.txt b/Documentation/en/rfc/rfc-index.txt
index 1f01397f..2d1dd1a6 100644
--- a/Documentation/en/rfc/rfc-index.txt
+++ b/Documentation/en/rfc/rfc-index.txt
@@ -5,7 +5,7 @@
RFC INDEX
-------------
-(CREATED ON: 01/16/2002.)
+(CREATED ON: 02/14/2002.)
This file contains citations for all RFCs in numeric order.
@@ -595,9 +595,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
May-19-1971. (Not online) (Obsoleted by RFC0495) (Updates RFC0139)
(Updated by RFC0318) (Also RFC0393) (Status: UNKNOWN)
-0160 RFC brief list. Network Information Center. Stanford Research
- Institute. May-18-1971. (Format: TXT=12173 bytes) (Obsoleted by
- RFC0200, RFC0999) (Updates NIC 6716) (Status: UNKNOWN)
+0160 RFC brief list. (unspec). May-18-1971. (Format: TXT=12173 bytes)
+ (Obsoleted by RFC0200, RFC0999) (Updates NIC 6716) (Status: UNKNOWN)
0161 Solution to the race condition in the ICP. A. Shoshani.
May-19-1971. (Format: TXT=2026 bytes) (Status: UNKNOWN)
@@ -632,9 +631,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
0169 Computer networks. S.D. Crocker. May-27-1971. (Not online)
(Status: UNKNOWN)
-0170 RFC List by Number. Network Information Center, Stanford Research
- Institute. Jun-01-1971. (Format: TXT=17670 bytes) (Obsoleted by
- RFC0200) (Status: UNKNOWN)
+0170 RFC List by Number. (unspec). Jun-01-1971. (Format: TXT=17670
+ bytes) (Obsoleted by RFC0200) (Status: UNKNOWN)
0171 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther,
E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D.
@@ -945,7 +943,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
0273 More on standard host names. R.W. Watson. Oct-18-1971. (Format:
TXT=4589 bytes) (Obsoletes RFC0237) (Status: UNKNOWN)
-0274 Establishing a local guide for network usage. E. Forman.
+0274 Establishing a local guide for network usage. E. FORMAN.
Nov-01-1971. (Format: TXT=7114 bytes) (Status: UNKNOWN)
0276 NIC course. R.W. Watson. Nov-08-1971. (Format: TXT=1183 bytes)
@@ -1033,9 +1031,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
0302 Exercising The ARPANET. R.F. Bryan. Feb-08-1972. (Format:
TXT=5452 bytes) (Status: UNKNOWN)
-0303 ARPA Network mailing lists. Network Information Center. Stanford
- Research Institute. Mar-03-1972. (Format: TXT=18193 bytes) (Obsoletes
- RFC0300) (Obsoleted by RFC0329) (Status: UNKNOWN)
+0303 ARPA Network mailing lists. (unspec). Mar-03-1972. (Format:
+ TXT=18193 bytes) (Obsoletes RFC0300) (Obsoleted by RFC0329) (Status:
+ UNKNOWN)
0304 Data management system proposal for the ARPA network. D.B. McKay.
Feb-17-1972. (Not online) (Status: UNKNOWN)
@@ -1120,9 +1118,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
0328 Suggested Telnet Protocol Changes. J. Postel. Apr-29-1972.
(Format: TXT=2685 bytes) (Status: UNKNOWN)
-0329 ARPA Network Mailing Lists. Network Information Center. Stanford
- Research Institute. May-17-1972. (Format: TXT=23861 bytes) (Obsoletes
- RFC0303) (Obsoleted by RFC0363) (Status: UNKNOWN)
+0329 ARPA Network Mailing Lists. (unspec). May-17-1972. (Format:
+ TXT=23861 bytes) (Obsoletes RFC0303) (Obsoleted by RFC0363) (Status:
+ UNKNOWN)
0330 Network Host Status. E. Westheimer. Apr-13-1972. (Format:
TXT=8085 bytes) (Obsoletes RFC0326) (Obsoleted by RFC0332) (Status:
@@ -1227,9 +1225,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
TXT=8631 bytes) (Obsoletes RFC0353) (Obsoleted by RFC0366) (Status:
UNKNOWN)
-0363 ARPA Network mailing lists. Network Information Center. Stanford
- Research Institute. Aug-08-1972. (Format: TXT=25356 bytes) (Obsoletes
- RFC0329) (Obsoleted by RFC0402) (Status: UNKNOWN)
+0363 ARPA Network mailing lists. (unspec). Aug-08-1972. (Format:
+ TXT=25356 bytes) (Obsoletes RFC0329) (Obsoleted by RFC0402) (Status:
+ UNKNOWN)
0364 Serving remote users on the ARPANET. M.D. Abrams. Jul-11-1972.
(Format: TXT=11253 bytes) (Status: UNKNOWN)
@@ -1277,7 +1275,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
0378 Traffic statistics (July 1972). A.M. McKenzie. Aug-10-1972.
(Format: TXT=5730 bytes) (Obsoleted by RFC0391) (Status: UNKNOWN)
-0379 Using TSO at CCN. R.T. Braden. Aug-11-1972. (Format: TXT=8674
+0379 Using TSO at CCN. R.T. BRADEN. Aug-11-1972. (Format: TXT=8674
bytes) (Status: UNKNOWN)
0381 Three aids to improved network operation. J.M. McQuillan.
@@ -1899,9 +1897,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
0597 Host status. N. Neigus, E.J. Feinler. Dec-12-1973. (Format:
TXT=11678 bytes) (Updated by RFC0603) (Status: UNKNOWN)
-0598 RFC index - December 5, 1973. Network Information Center.
- Stanford Research Institute. Dec-05-1973. (Not online) (Status:
- UNKNOWN)
+0598 RFC index - December 5, 1973. (unspec). Dec-05-1973. (Not online)
+ (Status: UNKNOWN)
0599 Update on NETRJS. R.T. Braden. Dec-13-1973. (Format: TXT=16590
bytes) (Obsoletes RFC0189) (Obsoleted by RFC0740) (Status: UNKNOWN)
@@ -2510,18 +2507,16 @@ See the RFC Editor Web page http://www.rfc-editor.org
O'Connor, D.L. Mills. Nov-02-1981. (Format: TXT=33826 bytes) (Status:
UNKNOWN)
-0804 CCITT draft recommendation T.4. International Telegraph and
- Telephone Consultative Committee of the International
- Telecommunication Union. Jan-01-1981. (Format: TXT=17025 bytes)
- (Status: UNKNOWN)
+0804 CCITT draft recommendation T.4. (unspec). Jan-01-1981. (Format:
+ TXT=17025 bytes) (Status: UNKNOWN)
0805 Computer mail meeting notes. J. Postel. Feb-08-1982. (Format:
TXT=12522 bytes) (Status: UNKNOWN)
0806 Proposed Federal Information Processing Standard: Specification
- for message format for computer based message systems. National
- Bureau of Standards. Sep-01-1981. (Format: TXT=216377 bytes)
- (Obsoleted by RFC0841) (Status: UNKNOWN)
+ for message format for computer based message systems. (unspec).
+ Sep-01-1981. (Format: TXT=216377 bytes) (Obsoleted by RFC0841)
+ (Status: UNKNOWN)
0807 Multimedia mail meeting notes. J. Postel. Feb-09-1982. (Format:
TXT=11633 bytes) (Status: UNKNOWN)
@@ -2636,8 +2631,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
bytes) (Obsoleted by RFC0880) (Status: HISTORIC)
0841 Specification for message format for Computer Based Message
- Systems. National Bureau of Standards. Jan-27-1983. (Format:
- TXT=231871 bytes) (Obsoletes RFC0806) (Status: UNKNOWN)
+ Systems. (unspec). Jan-27-1983. (Format: TXT=231871 bytes) (Obsoletes
+ RFC0806) (Status: UNKNOWN)
0842 Who talks TCP? - survey of 1 February 83. D. Smallberg.
Feb-03-1983. (Format: TXT=45962 bytes) (Obsoletes RFC0839) (Obsoleted
@@ -2810,9 +2805,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
0891 DCN local-network protocols. D.L. Mills. Dec-01-1983. (Format:
TXT=66769 bytes) (Also STD0044) (Status: STANDARD)
-0892 ISO Transport Protocol specification. International Organization
- for Standardization. Dec-01-1983. (Format: TXT=158151 bytes)
- (Obsoleted by RFC0905) (Status: UNKNOWN)
+0892 ISO Transport Protocol specification. (unspec). Dec-01-1983.
+ (Format: TXT=158151 bytes) (Obsoleted by RFC0905) (Status: UNKNOWN)
0893 Trailer encapsulations. S. Leffler, M.J. Karels. Apr-01-1984.
(Format: TXT=13353 bytes) (Status: UNKNOWN)
@@ -2866,9 +2860,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
0906 Bootstrap loading using TFTP. R. Finlayson. Jun-01-1984. (Format:
TXT=10102 bytes) (Status: UNKNOWN)
-0907 Host Access Protocol specification. Bolt, Beranek and Newman,
- Inc.. Jul-01-1984. (Format: TXT=129985 bytes) (Updated by RFC1221)
- (Also STD0040) (Status: STANDARD)
+0907 Host Access Protocol specification. (unspec). Jul-01-1984.
+ (Format: TXT=129985 bytes) (Updated by RFC1221) (Also STD0040)
+ (Status: STANDARD)
0908 Reliable Data Protocol. D. Velten, R.M. Hinden, J. Sax.
Jul-01-1984. (Format: TXT=97646 bytes) (Updated by RFC1151) (Status:
@@ -2932,8 +2926,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
TXT=31137 bytes) (Status: UNKNOWN)
0926 Protocol for providing the connectionless mode network services.
- International Organization for Standardization. Dec-01-1984. (Format:
- TXT=165895 bytes) (Obsoleted by RFC0994) (Status: UNKNOWN)
+ (unspec). Dec-01-1984. (Format: TXT=165895 bytes) (Obsoleted by
+ RFC0994) (Status: UNKNOWN)
0927 TACACS user identification Telnet option. B.A. Anderson.
Dec-01-1984. (Format: TXT=5474 bytes) (Status: PROPOSED STANDARD)
@@ -2976,20 +2970,18 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Status: EXPERIMENTAL)
0939 Executive summary of the NRC report on transport protocols for
- Department of Defense data networks. National Research Council.
- Feb-01-1985. (Format: TXT=42345 bytes) (Status: UNKNOWN)
+ Department of Defense data networks. (unspec). Feb-01-1985. (Format:
+ TXT=42345 bytes) (Status: UNKNOWN)
-0940 Toward an Internet standard scheme for subnetting. Gateway
- Algorithms and Data Structures Task Force. Apr-01-1985. (Format:
- TXT=6881 bytes) (Status: UNKNOWN)
+0940 Toward an Internet standard scheme for subnetting. (unspec).
+ Apr-01-1985. (Format: TXT=6881 bytes) (Status: UNKNOWN)
0941 Addendum to the network service definition covering network layer
- addressing. International Organization for Standardization.
- Apr-01-1985. (Format: TXT=68733 bytes) (Status: UNKNOWN)
+ addressing. (unspec). Apr-01-1985. (Format: TXT=68733 bytes) (Status:
+ UNKNOWN)
0942 Transport protocols for Department of Defense data networks.
- National Research Council. Feb-01-1985. (Format: TXT=217284 bytes)
- (Status: UNKNOWN)
+ (unspec). Feb-01-1985. (Format: TXT=217284 bytes) (Status: UNKNOWN)
0943 Assigned numbers. J.K. Reynolds, J. Postel. Apr-01-1985. (Format:
TXT=105234 bytes) (Obsoletes RFC0923) (Obsoleted by RFC0960) (Status:
@@ -3139,9 +3131,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
Clark, M.L. Lambert. May-01-1986. (Format: TXT=69333 bytes)
(Obsoleted by RFC0993) (Status: UNKNOWN)
-0985 Requirements for Internet gateways - draft. National Science
- Foundation, Network Technical Advisory Group. May-01-1986. (Format:
- TXT=59221 bytes) (Obsoleted by RFC1009) (Status: UNKNOWN)
+0985 Requirements for Internet gateways - draft. (unspec).
+ May-01-1986. (Format: TXT=59221 bytes) (Obsoleted by RFC1009)
+ (Status: UNKNOWN)
0986 Guidelines for the use of Internet-IP addresses in the ISO
Connectionless-Mode Network Protocol. R.W. Callon, H.W. Braun.
@@ -3178,14 +3170,12 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Obsoletes RFC0984) (Obsoleted by RFC1056) (Status: UNKNOWN)
0994 Final text of DIS 8473, Protocol for Providing the
- Connectionless-mode Network Service. International Organization for
- Standardization. Mar-01-1986. (Format: TXT=129006 bytes) (Obsoletes
- RFC0926) (Status: UNKNOWN)
+ Connectionless-mode Network Service. (unspec). Mar-01-1986. (Format:
+ TXT=129006 bytes) (Obsoletes RFC0926) (Status: UNKNOWN)
0995 End System to Intermediate System Routing Exchange Protocol for
- use in conjunction with ISO 8473. International Organization for
- Standardization. Apr-01-1986. (Format: TXT=94069 bytes) (Status:
- UNKNOWN)
+ use in conjunction with ISO 8473. (unspec). Apr-01-1986. (Format:
+ TXT=94069 bytes) (Status: UNKNOWN)
0996 Statistics server. D.L. Mills. Feb-01-1987. (Format: TXT=6127
bytes) (Status: HISTORIC)
@@ -3207,15 +3197,11 @@ See the RFC Editor Web page http://www.rfc-editor.org
UNKNOWN)
1001 Protocol standard for a NetBIOS service on a TCP/UDP transport:
- Concepts and methods. NetBIOS Working Group in the Defense Advanced
- Research Projects Agency, Internet Activities Board, End-to-End
- Services Task Force. Mar-01-1987. (Format: TXT=158437 bytes) (Also
- STD0019) (Status: STANDARD)
+ Concepts and methods. (unspec). Mar-01-1987. (Format: TXT=158437
+ bytes) (Also STD0019) (Status: STANDARD)
1002 Protocol standard for a NetBIOS service on a TCP/UDP transport:
- Detailed specifications. NetBIOS Working Group in the Defense
- Advanced Research Projects Agency, Internet Activities Board,
- End-to-End Services Task Force. Mar-01-1987. (Format: TXT=170262
+ Detailed specifications. (unspec). Mar-01-1987. (Format: TXT=170262
bytes) (Also STD0019) (Status: STANDARD)
1003 Issues in defining an equations representation standard. A.R.
@@ -3510,8 +3496,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1082 Post Office Protocol: Version 3: Extended service offerings. M.T.
Rose. Nov-01-1988. (Format: TXT=25423 bytes) (Status: UNKNOWN)
-1083 IAB official protocol standards. Defense Advanced Research
- Projects Agency, Internet Activities Board. Dec-01-1988. (Format:
+1083 IAB official protocol standards. (unspec). Dec-01-1988. (Format:
TXT=27128 bytes) (Obsoleted by RFC1100) (Status: HISTORIC)
1084 BOOTP vendor information extensions. J.K. Reynolds. Dec-01-1988.
@@ -3524,8 +3509,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1086 ISO-TP0 bridge between TCP and X.25. J.P. Onions, M.T. Rose.
Dec-01-1988. (Format: TXT=19934 bytes) (Status: UNKNOWN)
-1087 Ethics and the Internet. Defense Advanced Research Projects
- Agency, Internet Activities Board. Jan-01-1989. (Format: TXT=4582
+1087 Ethics and the Internet. (unspec). Jan-01-1989. (Format: TXT=4582
bytes) (Status: UNKNOWN)
1088 Standard for the transmission of IP datagrams over NetBIOS
@@ -3569,8 +3553,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1099 Request for Comments Summary: RFC Numbers 1000-1099. J. Reynolds.
December 1991. (Format: TXT=49108 bytes) (Status: INFORMATIONAL)
-1100 IAB official protocol standards. Defense Advanced Research
- Projects Agency, Internet Activities Board. Apr-01-1989. (Format:
+1100 IAB official protocol standards. (unspec). Apr-01-1989. (Format:
TXT=30101 bytes) (Obsoletes RFC1083) (Obsoleted by RFC1130) (Status:
HISTORIC)
@@ -3681,8 +3664,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
Mills. Oct-01-1989. (Format: TXT=298, PS=551697, PDF=197036 bytes)
(Also RFC1119) (Status: INFORMATIONAL)
-1130 IAB official protocol standards. Defense Advanced Research
- Projects Agency, Internet Activities Board. Oct-01-1989. (Format:
+1130 IAB official protocol standards. (unspec). Oct-01-1989. (Format:
TXT=33858 bytes) (Obsoletes RFC1100) (Obsoleted by RFC1140) (Status:
HISTORIC)
@@ -3722,8 +3704,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
TXT=14229 bytes) (Obsoleted by RFC1574, RFC1575) (Status: PROPOSED
STANDARD)
-1140 IAB official protocol standards. Defense Advanced Research
- Projects Agency, Internet Activities Board. May-01-1990. (Format:
+1140 IAB official protocol standards. (unspec). May-01-1990. (Format:
TXT=60501 bytes) (Obsoletes RFC1130) (Obsoleted by RFC1200) (Status:
HISTORIC)
@@ -3731,9 +3712,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
Kullberg. Jan-01-1990. (Format: TXT=3587 bytes) (Updates RFC1071)
(Updated by RFC1624) (Status: INFORMATIONAL)
-1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran. Feb-01-1990.
- (Format: TXT=425379, PS=1440951, PDF=490300 bytes) (Status:
- INFORMATIONAL)
+1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran, Ed..
+ Feb-01-1990. (Format: TXT=425379, PS=1440951, PDF=490300 bytes)
+ (Status: INFORMATIONAL)
1143 The Q Method of Implementing TELNET Option Negotiation. D.J.
Bernstein. Feb-01-1990. (Format: TXT=23331 bytes) (Status:
@@ -3953,8 +3934,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1199 Request for Comments Summary Notes: 1100-1199. J. Reynolds.
Dec-01-1991. (Format: TXT=46443 bytes) (Status: INFORMATIONAL)
-1200 IAB official protocol standards. Defense Advanced Research
- Projects Agency, Internet Activities Board. Apr-01-1991. (Format:
+1200 IAB official protocol standards. (unspec). Apr-01-1991. (Format:
TXT=67069 bytes) (Obsoletes RFC1140) (Obsoleted by RFC1250) (Status:
HISTORIC)
@@ -4169,8 +4149,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
Sep-01-1991. (Format: TXT=51103 bytes) (Obsoletes RFC1218) (Obsoleted
by RFC1417) (Status: INFORMATIONAL)
-1256 ICMP Router Discovery Messages. S. Deering. Sep-01-1991. (Format:
- TXT=43059 bytes) (Also RFC0792) (Status: PROPOSED STANDARD)
+1256 ICMP Router Discovery Messages. S. Deering, Ed.. Sep-01-1991.
+ (Format: TXT=43059 bytes) (Also RFC0792) (Status: PROPOSED STANDARD)
1257 Isochronous applications do not require jitter-controlled
networks. C. Partridge. Sep-01-1991. (Format: TXT=11075 bytes)
@@ -4268,16 +4248,15 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Obsoleted by RFC1418) (Status: EXPERIMENTAL)
1284 Definitions of Managed Objects for the Ethernet-like Interface
- Types. J. Cook. December 1991. (Format: TXT=43225 bytes) (Obsoleted
- by RFC1398) (Status: PROPOSED STANDARD)
+ Types. J. Cook, Ed.. December 1991. (Format: TXT=43225 bytes)
+ (Obsoleted by RFC1398) (Status: PROPOSED STANDARD)
1285 FDDI Management Information Base. J. Case. January 1992. (Format:
TXT=99747 bytes) (Updated by RFC1512) (Status: PROPOSED STANDARD)
-1286 Definitions of Managed Objects for Bridges. E. Decker, P.
- Langille, A. Rijsinghani, K. McCloghrie. December 1991. (Format:
- TXT=79104 bytes) (Obsoleted by RFC1493, RFC1525) (Status: PROPOSED
- STANDARD)
+1286 Definitions of Managed Objects for Bridges. P. Langille, A.
+ Rijsinghani, K. McCloghrie. December 1991. (Format: TXT=79104 bytes)
+ (Obsoleted by RFC1493, RFC1525) (Status: PROPOSED STANDARD)
1287 Towards the Future Internet Architecture. D. Clark, L. Chapin, V.
Cerf, R. Braden, R. Hobby. December 1991. (Format: TXT=59812 bytes)
@@ -4344,7 +4323,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
RFC1212, RFC1213, RFC1157) (Status: INFORMATIONAL)
1304 Definitions of Managed Objects for the SIP Interface Type. T.
- Cox, K. Tesink, Editors. February 1992. (Format: TXT=52491 bytes)
+ Cox, K. Tesink, Eds.. February 1992. (Format: TXT=52491 bytes)
(Obsoleted by RFC1694) (Status: PROPOSED STANDARD)
1305 Network Time Protocol (Version 3) Specification, Implementation.
@@ -4441,9 +4420,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
1330 Recommendations for the Phase I Deployment of OSI Directory
Services (X.500) and OSI Message Handling Services (X.400) within the
- ESNET Community. ESCC X.500/X.400 Task Force, ESnet Site Coordinating
- Committee (ESCC). May 1992. (Format: TXT=192925 bytes) (Status:
- INFORMATIONAL)
+ ESNET Community. (unspec). May 1992. (Format: TXT=192925 bytes)
+ (Status: INFORMATIONAL)
1331 The Point-to-Point Protocol (PPP) for the Transmission of
Multi-protocol Datagrams over Point-to-Point Links. W. Simpson. May
@@ -4637,8 +4615,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
1381 SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. November
1992. (Format: TXT=71253 bytes) (Status: PROPOSED STANDARD)
-1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop. November
- 1992. (Format: TXT=153877 bytes) (Status: PROPOSED STANDARD)
+1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop, Ed..
+ November 1992. (Format: TXT=153877 bytes) (Status: PROPOSED STANDARD)
1383 An Experiment in DNS Based IP Routing. C. Huitema. December 1992.
(Format: TXT=32680 bytes) (Status: EXPERIMENTAL)
@@ -4708,8 +4686,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Status: INFORMATIONAL)
1401 Correspondence between the IAB and DISA on the use of DNS.
- Internet Architecture Board. January 1993. (Format: TXT=12528 bytes)
- (Status: INFORMATIONAL)
+ (unspec). January 1993. (Format: TXT=12528 bytes) (Status:
+ INFORMATIONAL)
1402 There's Gold in them thar Networks! or Searching for Treasure in
all the Wrong Places. J. Martin. January 1993. (Format: TXT=71176
@@ -4727,7 +4705,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
RFC2162) (Status: EXPERIMENTAL)
1406 Definitions of Managed Objects for the DS1 and E1 Interface
- Types. F. Baker, J. Watt, Editors. January 1993. (Format: TXT=97559
+ Types. F. Baker, J. Watt, Eds.. January 1993. (Format: TXT=97559
bytes) (Obsoletes RFC1232) (Obsoleted by RFC2495) (Status: PROPOSED
STANDARD)
@@ -4735,18 +4713,18 @@ See the RFC Editor Web page http://www.rfc-editor.org
Cox, K. Tesink. January 1993. (Format: TXT=90682 bytes) (Obsoletes
RFC1233) (Obsoleted by RFC2496) (Status: PROPOSED STANDARD)
-1408 Telnet Environment Option. D. Borman, Editor. January 1993.
- (Format: TXT=13936 bytes) (Updated by RFC1571) (Status: HISTORIC)
+1408 Telnet Environment Option. D. Borman, Ed.. January 1993. (Format:
+ TXT=13936 bytes) (Updated by RFC1571) (Status: HISTORIC)
-1409 Telnet Authentication Option. D. Borman, Editor. January 1993.
+1409 Telnet Authentication Option. D. Borman, Ed.. January 1993.
(Format: TXT=13119 bytes) (Obsoleted by RFC1416) (Status:
EXPERIMENTAL)
-1410 IAB Official Protocol Standards. J. Postel, Editor. March 1993.
+1410 IAB Official Protocol Standards. J. Postel, Ed.. March 1993.
(Format: TXT=76524 bytes) (Obsoletes RFC1360) (Obsoleted by RFC1500)
(Status: HISTORIC)
-1411 Telnet Authentication: Kerberos Version 4. D. Borman, Editor.
+1411 Telnet Authentication: Kerberos Version 4. D. Borman, Ed..
January 1993. (Format: TXT=7967 bytes) (Status: EXPERIMENTAL)
1412 Telnet Authentication: SPX. K. Alagappan. January 1993. (Format:
@@ -4761,7 +4739,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1415 FTP-FTAM Gateway Specification. J. Mindel, R. Slaski. January
1993. (Format: TXT=128261 bytes) (Status: PROPOSED STANDARD)
-1416 Telnet Authentication Option. D. Borman, Editor. February 1993.
+1416 Telnet Authentication Option. D. Borman, Ed.. February 1993.
(Format: TXT=13270 bytes) (Obsoletes RFC1409) (Obsoleted by RFC2941)
(Status: EXPERIMENTAL)
@@ -4797,18 +4775,18 @@ See the RFC Editor Web page http://www.rfc-editor.org
Certification and Related Services. B. Kaliski. February 1993.
(Format: TXT=17537 bytes) (Status: PROPOSED STANDARD)
-1425 SMTP Service Extensions. J. Klensin, WG Chair, N. Freed, Editor,
- M. Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT=20932
+1425 SMTP Service Extensions. J. Klensin, WG Chair, N. Freed, Ed., M.
+ Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT=20932
bytes) (Obsoleted by RFC1651) (Status: PROPOSED STANDARD)
1426 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, WG
- Chair, N. Freed, Editor, M. Rose, E. Stefferud, D. Crocker. February
+ Chair, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. February
1993. (Format: TXT=11661 bytes) (Obsoleted by RFC1652) (Status:
PROPOSED STANDARD)
1427 SMTP Service Extension for Message Size Declaration. J. Klensin,
- WG Chair, N. Freed, Editor, K. Moore. February 1993. (Format:
- TXT=17856 bytes) (Obsoleted by RFC1653) (Status: PROPOSED STANDARD)
+ WG Chair, N. Freed, Ed., K. Moore. February 1993. (Format: TXT=17856
+ bytes) (Obsoleted by RFC1653) (Status: PROPOSED STANDARD)
1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME.
G. Vaudreuil. February 1993. (Format: TXT=12064 bytes) (Status:
@@ -5062,9 +5040,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
1492 An Access Control Protocol, Sometimes Called TACACS. C. Finseth.
July 1993. (Format: TXT=41880 bytes) (Status: INFORMATIONAL)
-1493 Definitions of Managed Objects for Bridges. E. Decker, P.
- Langille, A. Rijsinghani, K. McCloghrie. July 1993. (Format:
- TXT=74493 bytes) (Obsoletes RFC1286) (Status: DRAFT STANDARD)
+1493 Definitions of Managed Objects for Bridges. P. Langille, A.
+ Rijsinghani, K. McCloghrie. July 1993. (Format: TXT=74493 bytes)
+ (Obsoletes RFC1286) (Status: DRAFT STANDARD)
1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies. H.
Alvestrand, S. Thompson. August 1993. (Format: TXT=37273 bytes)
@@ -5287,7 +5265,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Format: TXT=111638 bytes) (Obsoletes RFC1331) (Obsoleted by RFC1661)
(Updated by RFC1570) (Status: DRAFT STANDARD)
-1549 PPP in HDLC Framing. W. Simpson. December 1993. (Format:
+1549 PPP in HDLC Framing. W. Simpson, Ed.. December 1993. (Format:
TXT=36352 bytes) (Obsoleted by RFC1662) (Status: DRAFT STANDARD)
1550 IP: Next Generation (IPng) White Paper Solicitation. S. Bradner,
@@ -5366,16 +5344,16 @@ See the RFC Editor Web page http://www.rfc-editor.org
-- Technical Procedures. M. Rose. January 1994. (Format: TXT=12597
bytes) (Obsoleted by RFC1703) (Status: INFORMATIONAL)
-1570 PPP LCP Extensions. W. Simpson. January 1994. (Format: TXT=35719
- bytes) (Updates RFC1548) (Updated by RFC2484) (Status: PROPOSED
- STANDARD)
+1570 PPP LCP Extensions. W. Simpson, Ed.. January 1994. (Format:
+ TXT=35719 bytes) (Updates RFC1548) (Updated by RFC2484) (Status:
+ PROPOSED STANDARD)
1571 Telnet Environment Option Interoperability Issues. D. Borman.
January 1994. (Format: TXT=8117 bytes) (Updates RFC1408) (Status:
INFORMATIONAL)
-1572 Telnet Environment Option. S. Alexander. January 1994. (Format:
- TXT=14676 bytes) (Status: PROPOSED STANDARD)
+1572 Telnet Environment Option. S. Alexander, Ed.. January 1994.
+ (Format: TXT=14676 bytes) (Status: PROPOSED STANDARD)
1573 Evolution of the Interfaces Group of MIB-II. K. McCloghrie, F.
Kastenholz. January 1994. (Format: TXT=123057 bytes) (Obsoletes
@@ -5461,7 +5439,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Obsoleted by RFC2558) (Status: PROPOSED STANDARD)
1596 Definitions of Managed Objects for Frame Relay Service. T. Brown,
- Editor. March 1994. (Format: TXT=88795 bytes) (Obsoleted by RFC1604)
+ Ed.. March 1994. (Format: TXT=88795 bytes) (Obsoleted by RFC1604)
(Status: PROPOSED STANDARD)
1597 Address Allocation for Private Internets. Y. Rekhter, B.
@@ -5482,8 +5460,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
March 1994. (Format: TXT=12424 bytes) (Obsoletes RFC1358) (Obsoleted
by RFC2850) (Status: INFORMATIONAL)
-1602 The Internet Standards Process -- Revision 2. Internet
- Architecture Board and Internet Engineering Steering Group. March
+1602 The Internet Standards Process -- Revision 2. (unspec). March
1994. (Format: TXT=88465 bytes) (Obsoletes RFC1310) (Obsoleted by
RFC2026) (Updated by RFC1871) (Status: INFORMATIONAL)
@@ -5492,7 +5469,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Updated by RFC1871) (Status: INFORMATIONAL)
1604 Definitions of Managed Objects for Frame Relay Service. T. Brown,
- Editor. March 1994. (Format: TXT=88770 bytes) (Obsoletes RFC1596)
+ Ed.. March 1994. (Format: TXT=88770 bytes) (Obsoletes RFC1596)
(Obsoleted by RFC2954) (Status: PROPOSED STANDARD)
1605 SONET to Sonnet Translation. W. Shakespeare. Apr-01-1994.
@@ -5532,8 +5509,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
May 1994. (Format: TXT=39693 bytes) (Status: INFORMATIONAL)
1616 X.400(1988) for the Academic and Research Community in Europe.
- RARE WG-MSG Task Force 88, E. Huizer, J. Romaguera, Editors. May
- 1994. (Format: TXT=107432 bytes) (Status: INFORMATIONAL)
+ RARE WG-MSG Task Force 88, E. Huizer, J. Romaguera, Eds.. May 1994.
+ (Format: TXT=107432 bytes) (Status: INFORMATIONAL)
1617 Naming and Structuring Guidelines for X.500 Directory Pilots. P.
Barker, S. Kille, T. Lenggenhager. May 1994. (Format: TXT=56739
@@ -5560,7 +5537,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
RFC1398) (Obsoleted by RFC1643) (Status: HISTORIC)
1624 Computation of the Internet Checksum via Incremental Update. A.
- Rijsinghani, Editor. May 1994. (Format: TXT=9836 bytes) (Updates
+ Rijsinghani, Ed.. May 1994. (Format: TXT=9836 bytes) (Updates
RFC1141) (Status: INFORMATIONAL)
1625 WAIS over Z39.50-1988. M. St. Pierre, J. Fullton, K. Gamiel, J.
@@ -5576,7 +5553,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Format: TXT=18823 bytes) (Obsoleted by RFC1918) (Status:
INFORMATIONAL)
-1628 UPS Management Information Base. J. Case. May 1994. (Format:
+1628 UPS Management Information Base. J. Case, Ed.. May 1994. (Format:
TXT=83439 bytes) (Status: PROPOSED STANDARD)
1629 Guidelines for OSI NSAP Allocation in the Internet. R. Colella,
@@ -5593,7 +5570,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
INFORMATIONAL)
1632 A Revised Catalog of Available X.500 Implementations. A.
- Getchell, S. Sataluri, Editors. May 1994. (Format: TXT=124111 bytes)
+ Getchell, S. Sataluri, Eds.. May 1994. (Format: TXT=124111 bytes)
(Obsoletes RFC1292) (Obsoleted by RFC2116) (Status: INFORMATIONAL)
1633 Integrated Services in the Internet Architecture: an Overview. R.
@@ -5677,12 +5654,12 @@ See the RFC Editor Web page http://www.rfc-editor.org
N. Freed, K. Moore. July 1994. (Format: TXT=17883 bytes) (Obsoletes
RFC1427) (Obsoleted by RFC1870) (Status: DRAFT STANDARD)
-1654 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li, Editors.
+1654 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li, Eds..
July 1994. (Format: TXT=130118 bytes) (Obsoleted by RFC1771) (Status:
PROPOSED STANDARD)
1655 Application of the Border Gateway Protocol in the Internet. Y.
- Rekhter, P. Gross, Editors. July 1994. (Format: TXT=43664 bytes)
+ Rekhter, P. Gross, Eds.. July 1994. (Format: TXT=43664 bytes)
(Obsoletes RFC1268) (Obsoleted by RFC1772) (Status: PROPOSED
STANDARD)
@@ -5692,7 +5669,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1657 Definitions of Managed Objects for the Fourth Version of the
Border Gateway Protocol (BGP-4) using SMIv2. S. Willis, J. Burruss,
- J. Chu, Editor. July 1994. (Format: TXT=45505 bytes) (Status: DRAFT
+ J. Chu, Ed.. July 1994. (Format: TXT=45505 bytes) (Status: DRAFT
STANDARD)
1658 Definitions of Managed Objects for Character Stream Devices using
@@ -5707,11 +5684,11 @@ See the RFC Editor Web page http://www.rfc-editor.org
Devices using SMIv2. B. Stewart. July 1994. (Format: TXT=16784 bytes)
(Obsoletes RFC1318) (Status: DRAFT STANDARD)
-1661 The Point-to-Point Protocol (PPP). W. Simpson, Editor. July 1994.
+1661 The Point-to-Point Protocol (PPP). W. Simpson, Ed.. July 1994.
(Format: TXT=103026 bytes) (Obsoletes RFC1548) (Updated by RFC2153)
(Also STD0051) (Status: STANDARD)
-1662 PPP in HDLC-like Framing. W. Simpson, Editor. July 1994. (Format:
+1662 PPP in HDLC-like Framing. W. Simpson, Ed.. July 1994. (Format:
TXT=48058 bytes) (Obsoletes RFC1549) (Also STD0051) (Status:
STANDARD)
@@ -5724,11 +5701,11 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Status: EXPERIMENTAL)
1665 Definitions of Managed Objects for SNA NAUs using SMIv2. Z.
- Kielczewski, D. Kostick, K. Shih, Editors. July 1994. (Format:
+ Kielczewski, D. Kostick, K. Shih, Eds.. July 1994. (Format:
TXT=133381 bytes) (Obsoleted by RFC1666) (Status: PROPOSED STANDARD)
1666 Definitions of Managed Objects for SNA NAUs using SMIv2. Z.
- Kielczewski, D. Kostick, K. Shih, Editors. August 1994. (Format:
+ Kielczewski, D. Kostick, K. Shih, Eds.. August 1994. (Format:
TXT=134385 bytes) (Obsoletes RFC1665) (Status: PROPOSED STANDARD)
1667 Modeling and Simulation Requirements for IPng. S. Symington, D.
@@ -5806,7 +5783,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
TXT=19151 bytes) (Status: INFORMATIONAL)
1689 A Status Report on Networked Information Retrieval: Tools and
- Groups. J. Foster. August 1994. (Format: TXT=375469 bytes) (Also
+ Groups. J. Foster, Ed.. August 1994. (Format: TXT=375469 bytes) (Also
FYI0025) (Status: INFORMATIONAL)
1690 Introducing the Internet Engineering and Planning Group (IEPG).
@@ -5826,11 +5803,11 @@ See the RFC Editor Web page http://www.rfc-editor.org
EXPERIMENTAL)
1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2.
- T. Brown, K. Tesink, Editors. August 1994. (Format: TXT=70856 bytes)
+ T. Brown, K. Tesink, Eds.. August 1994. (Format: TXT=70856 bytes)
(Obsoletes RFC1304) (Status: DRAFT STANDARD)
1695 Definitions of Managed Objects for ATM Management Version 8.0
- using SMIv2. M. Ahmed, K. Tesink, Editors. August 1994. (Format:
+ using SMIv2. M. Ahmed, K. Tesink, Eds.. August 1994. (Format:
TXT=175461 bytes) (Obsoleted by RFC2515) (Status: PROPOSED STANDARD)
1696 Modem Management Information Base (MIB) using SMIv2. J. Barnes,
@@ -5838,9 +5815,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
bytes) (Status: PROPOSED STANDARD)
1697 Relational Database Management System (RDBMS) Management
- Information Base (MIB) using SMIv2. D. Brower, Editor, B. Purvy,
- RDBMSMIB Working Group Chair, A. Daniel, M. Sinykin, J. Smith. August
- 1994. (Format: TXT=76202 bytes) (Status: PROPOSED STANDARD)
+ Information Base (MIB) using SMIv2. D. Brower, Ed., B. Purvy, A.
+ Daniel, M. Sinykin, J. Smith. August 1994. (Format: TXT=76202 bytes)
+ (Status: PROPOSED STANDARD)
1698 Octet Sequences for Upper-Layer OSI to Support Basic
Communications Applications. P. Furniss. October 1994. (Format:
@@ -5850,8 +5827,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
TXT=40674 bytes) (Status: INFORMATIONAL)
1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format:
- TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status:
- STANDARD)
+ TXT=458860 bytes) (Obsoletes RFC1340) (Obsoleted by RFC3232) (Also
+ STD0002) (Status: HISTORIC)
1701 Generic Routing Encapsulation (GRE). S. Hanks, T. Li, D.
Farinacci, P. Traina. October 1994. (Format: TXT=15460 bytes)
@@ -6025,16 +6002,16 @@ See the RFC Editor Web page http://www.rfc-editor.org
December 1994. (Format: TXT=46164 bytes) (Status: INFORMATIONAL)
1747 Definitions of Managed Objects for SNA Data Link Control (SDLC)
- using SMIv2. J. Hilgeman, Chair, S. Nix, A. Bartky, W. Clark, Editor.
+ using SMIv2. J. Hilgeman, Chair, S. Nix, A. Bartky, W. Clark, Ed..
January 1995. (Format: TXT=147388 bytes) (Status: PROPOSED STANDARD)
-1748 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December
- 1994. (Format: TXT=43224 bytes) (Obsoletes RFC1743, RFC1231) (Updated
- by RFC1749) (Status: DRAFT STANDARD)
+1748 IEEE 802.5 MIB using SMIv2. K. McCloghrie. December 1994.
+ (Format: TXT=43224 bytes) (Obsoletes RFC1743, RFC1231) (Updated by
+ RFC1749) (Status: DRAFT STANDARD)
1749 IEEE 802.5 Station Source Routing MIB using SMIv2. K. McCloghrie,
- F. Baker, E. Decker. December 1994. (Format: TXT=17563 bytes)
- (Updates RFC1748) (Status: PROPOSED STANDARD)
+ F. Baker. December 1994. (Format: TXT=17563 bytes) (Updates RFC1748)
+ (Status: PROPOSED STANDARD)
1750 Randomness Recommendations for Security. D. Eastlake, S. Crocker,
J. Schiller. December 1994. (Format: TXT=73842 bytes) (Status:
@@ -6122,7 +6099,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1773 Experience with the BGP-4 protocol. P. Traina. March 1995.
(Format: TXT=19936 bytes) (Obsoletes RFC1656) (Status: INFORMATIONAL)
-1774 BGP-4 Protocol Analysis. P. Traina, Editor. March 1995. (Format:
+1774 BGP-4 Protocol Analysis. P. Traina, Ed.. March 1995. (Format:
TXT=23823 bytes) (Status: INFORMATIONAL)
1775 To Be "On" the Internet. D. Crocker. March 1995. (Format:
@@ -6144,9 +6121,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
1995. (Format: TXT=12429 bytes) (Obsoletes RFC1485) (Obsoleted by
RFC2253) (Status: DRAFT STANDARD)
-1780 Internet Official Protocol Standards. J. Postel, Editor. March
- 1995. (Format: TXT=86594 bytes) (Obsoletes RFC1720) (Obsoleted by
- RFC1800) (Status: HISTORIC)
+1780 Internet Official Protocol Standards. J. Postel, Ed.. March 1995.
+ (Format: TXT=86594 bytes) (Obsoletes RFC1720) (Obsoleted by RFC1800)
+ (Status: HISTORIC)
1781 Using the OSI Directory to Achieve User Friendly Naming. S.
Kille. March 1995. (Format: TXT=47129 bytes) (Obsoletes RFC1484)
@@ -6200,7 +6177,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw
Closed Pages, DLSw Standard Version 1. L. Wells, Chair, A. Bartky,
- Editor. April 1995. (Format: TXT=214848 bytes) (Obsoletes RFC1434)
+ Ed.. April 1995. (Format: TXT=214848 bytes) (Obsoletes RFC1434)
(Status: INFORMATIONAL)
1796 Not All RFCs are Standards. C. Huitema, J. Postel, S. Crocker.
@@ -6216,9 +6193,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
1799 Request for Comments Summary RFC Numbers 1700-1799. M. Kennedy.
January 1997. (Format: TXT=42038 bytes) (Status: INFORMATIONAL)
-1800 Internet Official Protocol Standards. J. Postel, Editor. July
- 1995. (Format: TXT=83649 bytes) (Obsoletes RFC1780) (Obsoleted by
- RFC1880) (Status: HISTORIC)
+1800 Internet Official Protocol Standards. J. Postel, Ed.. July 1995.
+ (Format: TXT=83649 bytes) (Obsoletes RFC1780) (Obsoleted by RFC1880)
+ (Status: HISTORIC)
1801 MHS use of the X.500 Directory to support MHS Routing. S. Kille.
June 1995. (Format: TXT=156462 bytes) (Status: EXPERIMENTAL)
@@ -6261,7 +6238,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
Council. June 1995. (Format: TXT=6641 bytes) (Obsoleted by RFC1816)
(Status: INFORMATIONAL)
-1812 Requirements for IP Version 4 Routers. F. Baker. June 1995.
+1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
(Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated by
RFC2644) (Status: PROPOSED STANDARD)
@@ -6275,9 +6252,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
1815 Character Sets ISO-10646 and ISO-10646-J-1. M. Ohta. July 1995.
(Format: TXT=11823 bytes) (Status: INFORMATIONAL)
-1816 U.S. Government Internet Domain Names. Federal Networking
- Council. August 1995. (Format: TXT=17979 bytes) (Obsoletes RFC1811)
- (Obsoleted by RFC2146) (Status: INFORMATIONAL)
+1816 U.S. Government Internet Domain Names. (unspec). August 1995.
+ (Format: TXT=17979 bytes) (Obsoletes RFC1811) (Obsoleted by RFC2146)
+ (Status: INFORMATIONAL)
1817 CIDR and Classful Routing. Y. Rekhter. August 1995. (Format:
TXT=3416 bytes) (Status: INFORMATIONAL)
@@ -6287,7 +6264,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
PRACTICE)
1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification -
- Version ST2+. L. Delgrossi, L. Berger, Editors. August 1995. (Format:
+ Version ST2+. L. Delgrossi, L. Berger, Eds.. August 1995. (Format:
TXT=266875 bytes) (Obsoletes RFC1190, IEN 119) (Status: EXPERIMENTAL)
1820 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August
@@ -6504,10 +6481,10 @@ See the RFC Editor Web page http://www.rfc-editor.org
INFORMATIONAL)
1879 Class A Subnet Experiment Results and Recommendations. B.
- Manning. January 1996. (Format: TXT=10589 bytes) (Status:
+ Manning, Ed.. January 1996. (Format: TXT=10589 bytes) (Status:
INFORMATIONAL)
-1880 Internet Official Protocol Standards. J. Postel, Editor. November
+1880 Internet Official Protocol Standards. J. Postel, Ed.. November
1995. (Format: TXT=89153 bytes) (Obsoletes RFC1800) (Obsoleted by
RFC1920) (Status: HISTORIC)
@@ -6522,8 +6499,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
RFC2460) (Status: PROPOSED STANDARD)
1884 IP Version 6 Addressing Architecture. R. Hinden, S. Deering,
- Editors. December 1995. (Format: TXT=37860 bytes) (Obsoleted by
- RFC2373) (Status: HISTORIC)
+ Eds.. December 1995. (Format: TXT=37860 bytes) (Obsoleted by RFC2373)
+ (Status: HISTORIC)
1885 Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6). A. Conta, S. Deering. December 1995.
@@ -6535,7 +6512,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Status: PROPOSED STANDARD)
1887 An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter,
- T. Li, Editors. December 1995. (Format: TXT=66066 bytes) (Status:
+ T. Li, Eds.. December 1995. (Format: TXT=66066 bytes) (Status:
INFORMATIONAL)
1888 OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J.
@@ -6587,54 +6564,51 @@ See the RFC Editor Web page http://www.rfc-editor.org
1900 Renumbering Needs Work. B. Carpenter, Y. Rekhter. February 1996.
(Format: TXT=9528 bytes) (Status: INFORMATIONAL)
-1901 Introduction to Community-based SNMPv2. SNMPv2 Working Group, J.
- Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format:
- TXT=15903 bytes) (Status: EXPERIMENTAL)
+1901 Introduction to Community-based SNMPv2. J. Case, K. McCloghrie,
+ M. Rose, S. Waldbusser. January 1996. (Format: TXT=15903 bytes)
+ (Status: EXPERIMENTAL)
1902 Structure of Management Information for Version 2 of the Simple
- Network Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case,
- K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format:
- TXT=77453 bytes) (Obsoletes RFC1442) (Obsoleted by RFC2578) (Status:
- DRAFT STANDARD)
+ Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M.
+ Rose, S. Waldbusser. January 1996. (Format: TXT=77453 bytes)
+ (Obsoletes RFC1442) (Obsoleted by RFC2578) (Status: DRAFT STANDARD)
1903 Textual Conventions for Version 2 of the Simple Network
- Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K.
- McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=52652
- bytes) (Obsoletes RFC1443) (Obsoleted by RFC2579) (Status: DRAFT
- STANDARD)
+ Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S.
+ Waldbusser. January 1996. (Format: TXT=52652 bytes) (Obsoletes
+ RFC1443) (Obsoleted by RFC2579) (Status: DRAFT STANDARD)
1904 Conformance Statements for Version 2 of the Simple Network
- Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K.
- McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=47083
- bytes) (Obsoletes RFC1444) (Obsoleted by RFC2580) (Status: DRAFT
- STANDARD)
+ Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S.
+ Waldbusser. January 1996. (Format: TXT=47083 bytes) (Obsoletes
+ RFC1444) (Obsoleted by RFC2580) (Status: DRAFT STANDARD)
1905 Protocol Operations for Version 2 of the Simple Network
- Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K.
- McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=55526
- bytes) (Obsoletes RFC1448) (Status: DRAFT STANDARD)
+ Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S.
+ Waldbusser. January 1996. (Format: TXT=55526 bytes) (Obsoletes
+ RFC1448) (Status: DRAFT STANDARD)
1906 Transport Mappings for Version 2 of the Simple Network Management
- Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K. McCloghrie, M.
- Rose, S. Waldbusser. January 1996. (Format: TXT=27465 bytes)
- (Obsoletes RFC1449) (Status: DRAFT STANDARD)
+ Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser.
+ January 1996. (Format: TXT=27465 bytes) (Obsoletes RFC1449) (Status:
+ DRAFT STANDARD)
1907 Management Information Base for Version 2 of the Simple Network
- Management Protocol (SNMPv2). SNMPv2 Working Group, J. Case, K.
- McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=34881
- bytes) (Obsoletes RFC1450) (Status: DRAFT STANDARD)
+ Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S.
+ Waldbusser. January 1996. (Format: TXT=34881 bytes) (Obsoletes
+ RFC1450) (Status: DRAFT STANDARD)
1908 Coexistence between Version 1 and Version 2 of the
- Internet-standard Network Management Framework. SNMPv2 Working Group,
- J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996.
- (Format: TXT=21463 bytes) (Obsoletes RFC1452) (Obsoleted by RFC2576)
- (Status: DRAFT STANDARD)
+ Internet-standard Network Management Framework. J. Case, K.
+ McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT=21463
+ bytes) (Obsoletes RFC1452) (Obsoleted by RFC2576) (Status: DRAFT
+ STANDARD)
-1909 An Administrative Infrastructure for SNMPv2. K. McCloghrie.
+1909 An Administrative Infrastructure for SNMPv2. K. McCloghrie, Ed..
February 1996. (Format: TXT=45773 bytes) (Status: EXPERIMENTAL)
-1910 User-based Security Model for SNMPv2. G. Waters. February 1996.
- (Format: TXT=98252 bytes) (Status: EXPERIMENTAL)
+1910 User-based Security Model for SNMPv2. G. Waters, Ed.. February
+ 1996. (Format: TXT=98252 bytes) (Status: EXPERIMENTAL)
1911 Voice Profile for Internet Mail. G. Vaudreuil. February 1996.
(Format: TXT=50242 bytes) (Obsoleted by RFC2421, RFC2422, RFC2423)
@@ -6811,7 +6785,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(POP3). R. Nelson. June 1996. (Format: TXT=2325 bytes) (Updates
RFC1939) (Status: INFORMATIONAL)
-1958 Architectural Principles of the Internet. B. Carpenter. June
+1958 Architectural Principles of the Internet. B. Carpenter, Ed.. June
1996. (Format: TXT=17345 bytes) (Status: INFORMATIONAL)
1959 An LDAP URL Format. T. Howes, M. Smith. June 1996. (Format:
@@ -6840,8 +6814,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
EXPERIMENTAL)
1966 BGP Route Reflection An alternative to full mesh IBGP. T. Bates,
- R. Chandrasekeran. June 1996. (Format: TXT=14320 bytes) (Updated by
- RFC2796) (Status: EXPERIMENTAL)
+ R. Chandra. June 1996. (Format: TXT=14320 bytes) (Updated by RFC2796)
+ (Status: EXPERIMENTAL)
1967 PPP LZS-DCP Compression Protocol (LZS-DCP). K. Schneider, R.
Friend. August 1996. (Format: TXT=40039 bytes) (Status:
@@ -6901,7 +6875,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
TXT=14440 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED
STANDARD)
-1983 Internet Users' Glossary. G. Malkin. August 1996. (Format:
+1983 Internet Users' Glossary. G. Malkin, Ed.. August 1996. (Format:
TXT=123008 bytes) (Obsoletes RFC1392) (Also FYI0018) (Status:
INFORMATIONAL)
@@ -6969,7 +6943,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
1999 Request for Comments Summary RFC Numbers 1900-1999. J. Elliott.
January 1997. (Format: TXT=39819 bytes) (Status: INFORMATIONAL)
-2000 Internet Official Protocol Standards. J. Postel, Editor. February
+2000 Internet Official Protocol Standards. J. Postel, Ed.. February
1997. (Format: TXT=121356 bytes) (Obsoletes RFC1920) (Obsoleted by
RFC2200) (Status: HISTORIC)
@@ -6977,8 +6951,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
Recovery Algorithms. W. Stevens. January 1997. (Format: TXT=12981
bytes) (Obsoleted by RFC2581) (Status: PROPOSED STANDARD)
-2002 IP Mobility Support. C. Perkins. October 1996. (Format:
- TXT=193103 bytes) (Updated by RFC2290) (Status: PROPOSED STANDARD)
+2002 IP Mobility Support. C. Perkins, Ed.. October 1996. (Format:
+ TXT=193103 bytes) (Obsoleted by RFC3220) (Updated by RFC2290)
+ (Status: PROPOSED STANDARD)
2003 IP Encapsulation within IP. C. Perkins. October 1996. (Format:
TXT=30291 bytes) (Status: PROPOSED STANDARD)
@@ -7009,16 +6984,16 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Status: INFORMATIONAL)
2011 SNMPv2 Management Information Base for the Internet Protocol
- using SMIv2. K. McCloghrie. November 1996. (Format: TXT=31168 bytes)
- (Updates RFC1213) (Status: PROPOSED STANDARD)
+ using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT=31168
+ bytes) (Updates RFC1213) (Status: PROPOSED STANDARD)
2012 SNMPv2 Management Information Base for the Transmission Control
- Protocol using SMIv2. K. McCloghrie. November 1996. (Format:
+ Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format:
TXT=16792 bytes) (Updates RFC1213) (Status: PROPOSED STANDARD)
2013 SNMPv2 Management Information Base for the User Datagram Protocol
- using SMIv2. K. McCloghrie. November 1996. (Format: TXT=9333 bytes)
- (Updates RFC1213) (Status: PROPOSED STANDARD)
+ using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT=9333
+ bytes) (Updates RFC1213) (Status: PROPOSED STANDARD)
2014 IRTF Research Group Guidelines and Procedures. A. Weinrib, J.
Postel. October 1996. (Format: TXT=27507 bytes) (Also BCP0008)
@@ -7060,8 +7035,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
STANDARD)
2024 Definitions of Managed Objects for Data Link Switching using
- SMIv2. D. Chen, P. Gayek, S. Nix. October 1996. (Format: TXT=173952
- bytes) (Status: PROPOSED STANDARD)
+ SMIv2. D. Chen, Ed., P. Gayek, S. Nix. October 1996. (Format:
+ TXT=173952 bytes) (Status: PROPOSED STANDARD)
2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October
1996. (Format: TXT=101692 bytes) (Status: PROPOSED STANDARD)
@@ -7446,11 +7421,12 @@ See the RFC Editor Web page http://www.rfc-editor.org
Young. March 1997. (Format: TXT=51032 bytes) (Updates RFC1006)
(Status: PROPOSED STANDARD)
-2127 ISDN Management Information Base using SMIv2. G. Roeck. March
- 1997. (Format: TXT=95994 bytes) (Status: PROPOSED STANDARD)
+2127 ISDN Management Information Base using SMIv2. G. Roeck, Ed..
+ March 1997. (Format: TXT=95994 bytes) (Status: PROPOSED STANDARD)
-2128 Dial Control Management Information Base using SMIv2. G. Roeck.
- March 1997. (Format: TXT=66153 bytes) (Status: PROPOSED STANDARD)
+2128 Dial Control Management Information Base using SMIv2. G. Roeck,
+ Ed.. March 1997. (Format: TXT=66153 bytes) (Status: PROPOSED
+ STANDARD)
2129 Toshiba's Flow Attribute Notification Protocol (FANP)
Specification. K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S.
@@ -7519,9 +7495,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
Fielding, J. Gettys, H. Frystyk. May 1997. (Format: TXT=13659 bytes)
(Status: INFORMATIONAL)
-2146 U.S. Government Internet Domain Names. Federal Networking
- Council. May 1997. (Format: TXT=26564 bytes) (Obsoletes RFC1816)
- (Status: INFORMATIONAL)
+2146 U.S. Government Internet Domain Names. (unspec). May 1997.
+ (Format: TXT=26564 bytes) (Obsoletes RFC1816) (Status: INFORMATIONAL)
2147 TCP and UDP over IPv6 Jumbograms. D. Borman. May 1997. (Format:
TXT=1883 bytes) (Obsoleted by RFC2675) (Status: PROPOSED STANDARD)
@@ -7603,10 +7578,10 @@ See the RFC Editor Web page http://www.rfc-editor.org
bytes) (Obsoletes RFC1714) (Status: INFORMATIONAL)
2168 Resolution of Uniform Resource Identifiers using the Domain Name
- System. R. Danie1, M. Mealling. June 1997. (Format: TXT=46528 bytes)
+ System. R. Daniel, M. Mealling. June 1997. (Format: TXT=46528 bytes)
(Updated by RFC2915) (Status: EXPERIMENTAL)
-2169 A Trivial Convention for using HTTP in URN Resolution. R. Danie1.
+2169 A Trivial Convention for using HTTP in URN Resolution. R. Daniel.
June 1997. (Format: TXT=17763 bytes) (Status: EXPERIMENTAL)
2170 Application REQuested IP over ATM (AREQUIPA). W. Almesberger, J.
@@ -7656,9 +7631,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Also BCP0016) (Status: BEST CURRENT PRACTICE)
2183 Communicating Presentation Information in Internet Messages: The
- Content-Disposition Header Field. R. Troost, S. Dorner, K. Moore.
- August 1997. (Format: TXT=23150 bytes) (Updates RFC1806) (Updated by
- RFC2184, RFC2231) (Status: PROPOSED STANDARD)
+ Content-Disposition Header Field. R. Troost, S. Dorner, K. Moore,
+ Ed.. August 1997. (Format: TXT=23150 bytes) (Updates RFC1806)
+ (Updated by RFC2184, RFC2231) (Status: PROPOSED STANDARD)
2184 MIME Parameter Value and Encoded Word Extensions: Character Sets,
Languages, and Continuations. N. Freed, K. Moore. August 1997.
@@ -7839,8 +7814,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
RFC2047, RFC2183) (Status: PROPOSED STANDARD)
2232 Definitions of Managed Objects for DLUR using SMIv2. B. Clouston,
- B. Moore. November 1997. (Format: TXT=37955 bytes) (Status: PROPOSED
- STANDARD)
+ Ed., B. Moore, Ed.. November 1997. (Format: TXT=37955 bytes) (Status:
+ PROPOSED STANDARD)
2233 The Interfaces Group MIB using SMIv2. K. McCloghrie, F.
Kastenholz. November 1997. (Format: TXT=148033 bytes) (Obsoletes
@@ -7861,8 +7836,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
November 1997. (Format: TXT=11628 bytes) (Status: INFORMATIONAL)
2238 Definitions of Managed Objects for HPR using SMIv2. B. Clouston,
- B. Moore. November 1997. (Format: TXT=65498 bytes) (Status: PROPOSED
- STANDARD)
+ Ed., B. Moore, Ed.. November 1997. (Format: TXT=65498 bytes) (Status:
+ PROPOSED STANDARD)
2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment
Units (MAUs) using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K.
@@ -8179,8 +8154,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
2318 The text/css Media Type. H. Lie, B. Bos, C. Lilley. March 1998.
(Format: TXT=7819 bytes) (Status: INFORMATIONAL)
-2319 Ukrainian Character Set KOI8-U. KOI8-U Working Group. April 1998.
- (Format: TXT=18042 bytes) (Status: INFORMATIONAL)
+2319 Ukrainian Character Set KOI8-U. (unspec). April 1998. (Format:
+ TXT=18042 bytes) (Status: INFORMATIONAL)
2320 Definitions of Managed Objects for Classical IP and ARP Over ATM
Using SMIv2 (IPOA-MIB). M. Greene, J. Luciani, K. White, T. Kuo.
@@ -8270,7 +8245,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
2343 RTP Payload Format for Bundled MPEG. M. Civanlar, G. Cash, B.
Haskell. May 1998. (Format: TXT=16557 bytes) (Status: EXPERIMENTAL)
-2344 Reverse Tunneling for Mobile IP. G. Montenegro. May 1998.
+2344 Reverse Tunneling for Mobile IP. G. Montenegro, Ed.. May 1998.
(Format: TXT=39468 bytes) (Obsoleted by RFC3024) (Status: PROPOSED
STANDARD)
@@ -8411,7 +8386,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
bytes) (Status: PROPOSED STANDARD)
2382 A Framework for Integrated Services and RSVP over ATM. E.
- Crawley, L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk.
+ Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk.
August 1998. (Format: TXT=73865 bytes) (Status: INFORMATIONAL)
2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version. M.
@@ -8809,7 +8784,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
1999. (Format: TXT=14261 bytes) (Status: PROPOSED STANDARD)
2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman.
- January 1999. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD)
+ January 1999. (Format: TXT=15120 bytes) (Obsoleted by RFC3207)
+ (Status: PROPOSED STANDARD)
2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms.
M. Allman, D. Glover, L. Sanchez. January 1999. (Format: TXT=47857
@@ -8831,19 +8807,19 @@ See the RFC Editor Web page http://www.rfc-editor.org
January 1999. (Format: TXT=21199 bytes) (Status: PROPOSED STANDARD)
2493 Textual Conventions for MIB Modules Using Performance History
- Based on 15 Minute Intervals. K. Tesink, Ed. January 1999. (Format:
+ Based on 15 Minute Intervals. K. Tesink, Ed.. January 1999. (Format:
TXT=18749 bytes) (Status: PROPOSED STANDARD)
2494 Definitions of Managed Objects for the DS0 and DS0 Bundle
- Interface Type. D. Fowler, Ed. January 1999. (Format: TXT=47208
+ Interface Type. D. Fowler, Ed.. January 1999. (Format: TXT=47208
bytes) (Status: PROPOSED STANDARD)
2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2
- Interface Types. D. Fowler, Ed. January 1999. (Format: TXT=155560
+ Interface Types. D. Fowler, Ed.. January 1999. (Format: TXT=155560
bytes) (Obsoletes RFC1406) (Status: PROPOSED STANDARD)
2496 Definitions of Managed Object for the DS3/E3 Interface Type. D.
- Fowler, Ed. January 1999. (Format: TXT=124251 bytes) (Obsoletes
+ Fowler, Ed.. January 1999. (Format: TXT=124251 bytes) (Obsoletes
RFC1407) (Status: PROPOSED STANDARD)
2497 Transmission of IPv6 Packets over ARCnet Networks. I. Souvatzis.
@@ -8997,7 +8973,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008, RFC3090,
RFC3226) (Status: PROPOSED STANDARD)
-2536 DSA KEYs and SIGs in the Domain Name System (DNS). D. Eastlake.
+2536 DSA KEYs and SIGs in the Domain Name System (DNS). D. EastLake.
March 1999. (Format: TXT=11121 bytes) (Status: PROPOSED STANDARD)
2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). D.
@@ -9407,7 +9383,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
Gellens. August 1999. (Format: TXT=16302 bytes) (Status: PROPOSED
STANDARD)
-2646 The Text/Plain Format Parameter. R. Gellens. August 1999.
+2646 The Text/Plain Format Parameter. R. Gellens, Ed.. August 1999.
(Format: TXT=29175 bytes) (Updates RFC2046) (Status: PROPOSED
STANDARD)
@@ -9661,7 +9637,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Status: INFORMATIONAL)
2714 Schema for Representing CORBA Object References in an LDAP
- Directory. V. Ryan, S. Seligman, R. Lee. October 1999. (Format:
+ Directory. V. Ryan, R. Lee, S. Seligman. October 1999. (Format:
TXT=14709 bytes) (Status: INFORMATIONAL)
2715 Interoperability Rules for Multicast Routing Protocols. D.
@@ -9836,7 +9812,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
2759 Microsoft PPP CHAP Extensions, Version 2. G. Zorn. January 2000.
(Format: TXT=34178 bytes) (Status: INFORMATIONAL)
-2760 Ongoing TCP Research Related to Satellites. M. Allman, S.
+2760 Ongoing TCP Research Related to Satellites. M. Allman, Ed., S.
Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann,
J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. February 2000.
(Format: TXT=111141 bytes) (Status: INFORMATIONAL)
@@ -10061,11 +10037,11 @@ See the RFC Editor Web page http://www.rfc-editor.org
Blakley, P. Behera. May 2000. (Format: TXT=18172 bytes) (Status:
INFORMATIONAL)
-2821 Simple Mail Transfer Protocol. J. Klensin, Editor. April 2001.
+2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001.
(Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869)
(Status: PROPOSED STANDARD)
-2822 Internet Message Format. P. Resnick, Editor. April 2001. (Format:
+2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format:
TXT=110695 bytes) (Obsoletes RFC0822) (Status: PROPOSED STANDARD)
2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like
@@ -10081,7 +10057,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
Internet protocols. IAB, L. Daigle, ed.. May 2000. (Format: TXT=15612
bytes) (Status: INFORMATIONAL)
-2826 IAB Technical Comment on the Unique DNS Root. IAB. May 2000.
+2826 IAB Technical Comment on the Unique DNS Root. (unspec). May 2000.
(Format: TXT=13400 bytes) (Status: INFORMATIONAL)
2827 Network Ingress Filtering: Defeating Denial of Service Attacks
@@ -10171,9 +10147,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
PROPOSED STANDARD)
2850 Charter of the Internet Architecture Board (IAB). Internet
- Architecture Board, B. Carpenter, Editor. May 2000. (Format:
- TXT=15984 bytes) (Obsoletes RFC1601) (Also BCP0039) (Status: BEST
- CURRENT PRACTICE)
+ Architecture Board, B. Carpenter, Ed.. May 2000. (Format: TXT=15984
+ bytes) (Obsoletes RFC1601) (Also BCP0039) (Status: BEST CURRENT
+ PRACTICE)
2851 Textual Conventions for Internet Network Addresses. M. Daniele,
B. Haberman, S. Routhier, J. Schoenwaelder. June 2000. (Format:
@@ -10404,12 +10380,12 @@ See the RFC Editor Web page http://www.rfc-editor.org
2000. (Format: TXT=127278 bytes) (Status: EXPERIMENTAL)
2910 Internet Printing Protocol/1.1: Encoding and Transport. R.
- Herriot, S. Butler, P. Moore, R. Turner, J. Wenn. September 2000.
- (Format: TXT=100599 bytes) (Obsoletes RFC2565) (Status: PROPOSED
- STANDARD)
+ Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn. September
+ 2000. (Format: TXT=100599 bytes) (Obsoletes RFC2565) (Status:
+ PROPOSED STANDARD)
-2911 Internet Printing Protocol/1.1: Model and Semantics. R. deBry, T.
- Hastings, R. Herriot, S. Isaacson, P. Powell. September 2000.
+2911 Internet Printing Protocol/1.1: Model and Semantics. T. Hastings,
+ Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell. September 2000.
(Format: TXT=575805 bytes) (Obsoletes RFC2566) (Status: PROPOSED
STANDARD)
@@ -10517,9 +10493,9 @@ See the RFC Editor Web page http://www.rfc-editor.org
(COPS) Protocol Clients. A. Smith, D. Partain, J. Seligson. October
2000. (Format: TXT=52427 bytes) (Status: PROPOSED STANDARD)
-2941 Telnet Authentication Option. T. Ts'o, Editor, J. Altman.
- September 2000. (Format: TXT=52427 bytes) (Obsoletes RFC1416)
- (Status: PROPOSED STANDARD)
+2941 Telnet Authentication Option. T. Ts'o, Ed., J. Altman. September
+ 2000. (Format: TXT=52427 bytes) (Obsoletes RFC1416) (Status: PROPOSED
+ STANDARD)
2942 Telnet Authentication: Kerberos Version 5. T. Ts'o. September
2000. (Format: TXT=14562 bytes) (Status: PROPOSED STANDARD)
@@ -10661,12 +10637,12 @@ See the RFC Editor Web page http://www.rfc-editor.org
2980 Common NNTP Extensions. S. Barber. October 2000. (Format:
TXT=57165 bytes) (Status: INFORMATIONAL)
-2981 Event MIB. R. Kavasseri (Editor of this version). October 2000.
+2981 Event MIB. R. Kavasseri (Ed. of this version). October 2000.
(Format: TXT=98248 bytes) (Status: PROPOSED STANDARD)
-2982 Distributed Management Expression MIB. R. Kavasseri (Editor of
- this version). October 2000. (Format: TXT=81371 bytes) (Status:
- PROPOSED STANDARD)
+2982 Distributed Management Expression MIB. R. Kavasseri (Ed. of this
+ version). October 2000. (Format: TXT=81371 bytes) (Status: PROPOSED
+ STANDARD)
2983 Differentiated Services and Tunnels. D. Black. October 2000.
(Format: TXT=35644 bytes) (Status: INFORMATIONAL)
@@ -10715,10 +10691,10 @@ See the RFC Editor Web page http://www.rfc-editor.org
INFORMATIONAL)
2995 Pre-Spirits Implementations of PSTN-initiated Services. H. Lu,
- Editor, I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J.
- Hwang, S. Ago,. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S.
- Nyckelgard, J. Yoakum, L. Robart. November 2000. (Format: TXT=96427
- bytes) (Status: INFORMATIONAL)
+ Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J.
+ Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum,
+ L. Robart. November 2000. (Format: TXT=96427 bytes) (Status:
+ INFORMATIONAL)
2996 Format of the RSVP DCLASS Object. Y. Bernet. November 2000.
(Format: TXT=18929 bytes) (Status: PROPOSED STANDARD)
@@ -10758,7 +10734,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
TXT=5682 bytes) (Also BCP0045) (Status: BEST CURRENT PRACTICE)
3006 Integrated Services in the Presence of Compressible Flows. B.
- Davie, S. Casner, C. Iturralde, D. Oran, J. Wroclawski. November
+ Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski. November
2000. (Format: TXT=31588 bytes) (Status: PROPOSED STANDARD)
3007 Secure Domain Name System (DNS) Dynamic Update. B. Wellington.
@@ -10774,9 +10750,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
PROPOSED STANDARD)
3010 NFS version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R.
- Thurlow, C. Beame, M. Eisler, D. Noveck. December 2000. (Format:
- TXT=450434 bytes) (Obsoletes RFC1813, RFC1094) (Status: PROPOSED
- STANDARD)
+ Thurlow, C. Beame, M. Eisler. December 2000. (Format: TXT=450434
+ bytes) (Obsoletes RFC1813, RFC1094) (Status: PROPOSED STANDARD)
3011 The IPv4 Subnet Selection Option for DHCP. G. Waters. November
2000. (Format: TXT=13967 bytes) (Status: PROPOSED STANDARD)
@@ -10827,7 +10802,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Format: TXT=86011 bytes) (Obsoletes RFC2376) (Updates RFC2048)
(Status: PROPOSED STANDARD)
-3024 Reverse Tunneling for Mobile IP, revised. G. Montenegro, Editor.
+3024 Reverse Tunneling for Mobile IP, revised. G. Montenegro, Ed..
January 2001. (Format: TXT=63929 bytes) (Obsoletes RFC2344) (Status:
PROPOSED STANDARD)
@@ -11101,7 +11076,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
(Status: PROPOSED STANDARD)
3096 Requirements for robust IP/UDP/RTP header compression. M.
- Degermark. July 2001. (Format: TXT=15018 bytes) (Status:
+ Degermark, Ed.. July 2001. (Format: TXT=15018 bytes) (Status:
INFORMATIONAL)
3097 RSVP Cryptographic Authentication -- Updated Message Type Value.
@@ -11109,7 +11084,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
RFC2747) (Status: PROPOSED STANDARD)
3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how
- NOT to $$$$$ MAKE ENEMIES FAST! $$$$$. E. Gavin, D. Eastlake 3rd, S.
+ NOT to $$$$$ MAKE ENEMIES FAST! $$$$$. T. Gavin, D. Eastlake 3rd, S.
Hambridge. April 2001. (Format: TXT=64687 bytes) (Also FYI0038)
(Status: INFORMATIONAL)
@@ -11145,8 +11120,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
Klensin. May 2001. (Format: TXT=5841 bytes) (Status: INFORMATIONAL)
3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). D.
- Eastlake 3rd. May 2001. (Format: TXT=14587 bytes) (Obsoleted by
- RFC2537) (Status: PROPOSED STANDARD)
+ Eastlake 3rd. May 2001. (Format: TXT=14587 bytes) (Obsoletes RFC2537)
+ (Status: PROPOSED STANDARD)
3111 Service Location Protocol Modifications for IPv6. E. Guttman. May
2001. (Format: TXT=25543 bytes) (Status: PROPOSED STANDARD)
@@ -11168,9 +11143,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
3117 On the Design of Application Protocols. M. Rose. November 2001.
(Format: TXT=57279 bytes) (Status: INFORMATIONAL)
-3118 Authentication for DHCP Messages. R. Droms, Editor, W. Arbaugh,
- Editor. June 2001. (Format: TXT=35536 bytes) (Status: PROPOSED
- STANDARD)
+3118 Authentication for DHCP Messages. R. Droms, W. Arbaugh, Eds..
+ June 2001. (Format: TXT=35536 bytes) (Status: PROPOSED STANDARD)
3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R.
Finlayson. June 2001. (Format: TXT=37796 bytes) (Status: PROPOSED
@@ -11231,8 +11205,8 @@ See the RFC Editor Web page http://www.rfc-editor.org
Degradations. J. Border, M. Kojo, J. Griner, G. Montenegro, Z.
Shelby. June 2001. (Format: TXT=114825 bytes) (Status: INFORMATIONAL)
-3136 The SPIRITS Architecture. L. Slutsman, Editor, I. Faynberg, H.
- Lu, M. Weissman. June 2001. (Format: TXT=19241 bytes) (Status:
+3136 The SPIRITS Architecture. L. Slutsman, Ed., I. Faynberg, H. Lu,
+ M. Weissman. June 2001. (Format: TXT=19241 bytes) (Status:
INFORMATIONAL)
3137 OSPF Stub Router Advertisement. A. Retana, L. Nguyen, R. White,
@@ -11376,7 +11350,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
TXT=15389 bytes) (Also BCP0051) (Status: BEST CURRENT PRACTICE)
3172 Management Guidelines & Operational Requirements for the Address
- and Routing Parameter Area Domain ("arpa"). G. Huston. September
+ and Routing Parameter Area Domain ("arpa"). G. Huston, Ed.. September
2001. (Format: TXT=18097 bytes) (Also BCP0052) (Status: BEST CURRENT
PRACTICE)
@@ -11444,7 +11418,7 @@ See the RFC Editor Web page http://www.rfc-editor.org
Ogawa, S. Casner, C. Bormann. January 2002. (Format: TXT=25991 bytes)
(Status: PROPOSED STANDARD)
-3189 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear
+3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear
Sampled Audio. K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. January
2002. (Format: TXT=34977 bytes) (Status: PROPOSED STANDARD)
@@ -11495,6 +11469,17 @@ See the RFC Editor Web page http://www.rfc-editor.org
Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun. December
2001. (Format: TXT=19712 bytes) (Status: PROPOSED STANDARD)
+3205 On the use of HTTP as a Substrate. K. Moore. February 2002.
+ (Format: TXT=34785 bytes) (Also BCP0056) (Status: BEST CURRENT
+ PRACTICE)
+
+3206 The SYS and AUTH POP Response Codes. R. Gellens. February 2002.
+ (Format: TXT=9917 bytes) (Status: PROPOSED STANDARD)
+
+3207 SMTP Service Extension for Secure SMTP over Transport Layer
+ Security. P. Hoffman. February 2002. (Format: TXT=18679 bytes)
+ (Obsoletes RFC2487) (Status: PROPOSED STANDARD)
+
3208 PGM Reliable Transport Protocol Specification. T. Speakman, J.
Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby,
T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R.
@@ -11512,6 +11497,21 @@ See the RFC Editor Web page http://www.rfc-editor.org
3211 Password-based Encryption for CMS. P. Gutmann. December 2001.
(Format: TXT=30527 bytes) (Status: PROPOSED STANDARD)
+3212 Constraint-Based LSP Setup using LDP. B. Jamoussi, Ed., L.
+ Andersson, R. Callon, R. Dantu,. January 2002. (Format: TXT=87591
+ bytes) (Status: PROPOSED STANDARD)
+
+3213 Applicability Statement for CR-LDP. J. Ash, M. Girish, E. Gray,
+ B. Jamoussi, G. Wright. January 2002. (Format: TXT=14489 bytes)
+ (Status: INFORMATIONAL)
+
+3214 LSP Modification Using CR-LDP. J. Ash, Y. Lee, P. Ashwood-Smith,
+ B. Jamoussi, D. Fedyk, D. Skalecki, L. Li. January 2002. (Format:
+ TXT=25453 bytes) (Status: PROPOSED STANDARD)
+
+3215 LDP State Machine. C. Boscher, P. Cheval, L. Wu, E. Gray. January
+ 2002. (Format: TXT=117278 bytes) (Status: INFORMATIONAL)
+
3216 SMIng Objectives. C. Elliott, D. Harrington, J. Jason, J.
Schoenwaelder, F. Strauss, W. Weiss. December 2001. (Format:
TXT=58551 bytes) (Status: INFORMATIONAL)
@@ -11527,6 +11527,10 @@ See the RFC Editor Web page http://www.rfc-editor.org
Squire. January 2002. (Format: TXT=184618 bytes) (Status: PROPOSED
STANDARD)
+3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002.
+ (Format: TXT=238343 bytes) (Obsoletes RFC2002) (Status: PROPOSED
+ STANDARD)
+
3221 Commentary on Inter-Domain Routing in the Internet. G. Huston.
December 2001. (Format: TXT=66580 bytes) (Status: INFORMATIONAL)
@@ -11545,6 +11549,14 @@ See the RFC Editor Web page http://www.rfc-editor.org
requirements. O. Gudmundsson. December 2001. (Format: TXT=12078
bytes) (Updates RFC2535, RFC2874) (Status: PROPOSED STANDARD)
+3227 Guidelines for Evidence Collection and Archiving. D. Brezinski,
+ T. Killalea. February 2002. (Format: TXT=18468 bytes) (Also BCP0055)
+ (Status: BEST CURRENT PRACTICE)
+
+3228 IANA Considerations for IPv4 Internet Group Management Protocol
+ (IGMP). B. Fenner. February 2002. (Format: TXT=6473 bytes) (Also
+ BCP0057) (Status: BEST CURRENT PRACTICE)
+
3229 Delta encoding in HTTP. J. Mogul, B. Krishnamurthy, F. Douglis,
A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein. January 2002.
(Format: TXT=111953 bytes) (Status: PROPOSED STANDARD)
@@ -11555,3 +11567,30 @@ See the RFC Editor Web page http://www.rfc-editor.org
3231 Definitions of Managed Objects for Scheduling Management
Operations. D. Levi, J. Schoenwaelder. January 2002. (Format:
TXT=61308 bytes) (Obsoletes RFC2591) (Status: PROPOSED STANDARD)
+
+3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database. J.
+ Reynolds, Ed.. January 2002. (Format: TXT=3849 bytes) (Obsoletes
+ RFC1700) (Status: INFORMATIONAL)
+
+3234 Middleboxes: Taxonomy and Issues. B. Carpenter, S. Brim. February
+ 2002. (Format: TXT=62329 bytes) (Status: INFORMATIONAL)
+
+3235 Network Address Translator (NAT)-Friendly Application Design
+ Guidelines. D. Senie. January 2002. (Format: TXT=29588 bytes)
+ (Status: INFORMATIONAL)
+
+3236 The 'application/xhtml+xml' Media Type. M. Baker, P. Stark.
+ January 2002. (Format: TXT=16750 bytes) (Status: INFORMATIONAL)
+
+3237 Requirements for Reliable Server Pooling. M. Tuexen, Q. Xie, R.
+ Stewart, M. Shore, L. Ong, J. Loughney, M. Stillman. January 2002.
+ (Format: TXT=16986 bytes) (Status: INFORMATIONAL)
+
+3238 IAB Architectural and Policy Considerations for Open Pluggable
+ Edge Services. S. Floyd, L. Daigle. January 2002. (Format: TXT=42336
+ bytes) (Status: INFORMATIONAL)
+
+3240 Digital Imaging and Communications in Medicine (DICOM) -
+ Application/dicom MIME Sub-type Registration. D. Clunie, E.
+ Cordonnier. February 2002. (Format: TXT=9102 bytes) (Status:
+ INFORMATIONAL)
diff --git a/Documentation/en/rfc/rfc1886.txt b/Documentation/en/rfc/rfc1886.txt
new file mode 100644
index 00000000..9874fddb
--- /dev/null
+++ b/Documentation/en/rfc/rfc1886.txt
@@ -0,0 +1,268 @@
+
+
+
+
+
+
+Network Working Group S. Thomson
+Request for Comments: 1886 Bellcore
+Category: Standards Track C. Huitema
+ INRIA
+ December 1995
+
+
+ DNS Extensions to support IP version 6
+
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+
+Abstract
+
+ This document defines the changes that need to be made to the Domain
+ Name System to support hosts running IP version 6 (IPv6). The
+ changes include a new resource record type to store an IPv6 address,
+ a new domain to support lookups based on an IPv6 address, and updated
+ definitions of existing query types that return Internet addresses as
+ part of additional section processing. The extensions are designed
+ to be compatible with existing applications and, in particular, DNS
+ implementations themselves.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson & Huitema Standards Track [Page 1]
+
+RFC 1886 IPv6 DNS Extensions December 1995
+
+
+1. INTRODUCTION
+
+ Current support for the storage of Internet addresses in the Domain
+ Name System (DNS)[1,2] cannot easily be extended to support IPv6
+ addresses[3] since applications assume that address queries return
+ 32-bit IPv4 addresses only.
+
+ To support the storage of IPv6 addresses we define the following
+ extensions:
+
+ o A new resource record type is defined to map a domain name to an
+ IPv6 address.
+
+ o A new domain is defined to support lookups based on address.
+
+ o Existing queries that perform additional section processing to
+ locate IPv4 addresses are redefined to perform additional
+ section processing on both IPv4 and IPv6 addresses.
+
+ The changes are designed to be compatible with existing software. The
+ existing support for IPv4 addresses is retained. Transition issues
+ related to the co-existence of both IPv4 and IPv6 addresses in DNS
+ are discussed in [4].
+
+
+2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
+
+ A new record type is defined to store a host's IPv6 address. A host
+ that has more than one IPv6 address must have more than one such
+ record.
+
+
+2.1 AAAA record type
+
+ The AAAA resource record type is a new record specific to the
+ Internet class that stores a single IPv6 address.
+
+ The value of the type is 28 (decimal).
+
+
+2.2 AAAA data format
+
+ A 128 bit IPv6 address is encoded in the data portion of an AAAA
+ resource record in network byte order (high-order byte first).
+
+
+
+
+Thompson & Huitema Standards Track [Page 2]
+
+RFC 1886 IPv6 DNS Extensions December 1995
+
+
+2.3 AAAA query
+
+ An AAAA query for a specified domain name in the Internet class
+ returns all associated AAAA resource records in the answer section of
+ a response.
+
+ A type AAAA query does not perform additional section processing.
+
+
+2.4 Textual format of AAAA records
+
+ The textual representation of the data portion of the AAAA resource
+ record used in a master database file is the textual representation
+ of a IPv6 address as defined in [3].
+
+
+2.5 IP6.INT Domain
+
+ A special domain is defined to look up a record given an address. The
+ intent of this domain is to provide a way of mapping an IPv6 address
+ to a host name, although it may be used for other purposes as well.
+ The domain is rooted at IP6.INT.
+
+ An IPv6 address is represented as a name in the IP6.INT domain by a
+ sequence of nibbles separated by dots with the suffix ".IP6.INT". The
+ sequence of nibbles is encoded in reverse order, i.e. the low-order
+ nibble is encoded first, followed by the next low-order nibble and so
+ on. Each nibble is represented by a hexadecimal digit. For example,
+ the inverse lookup domain name corresponding to the address
+
+ 4321:0:1:2:3:4:567:89ab
+
+ would be
+
+b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
+
+
+
+3. MODIFICATIONS TO EXISTING QUERY TYPES
+
+ All existing query types that perform type A additional section
+ processing, i.e. name server (NS), mail exchange (MX) and mailbox
+ (MB) query types, must be redefined to perform both type A and type
+ AAAA additional section processing. These new definitions mean that a
+ name server must add any relevant IPv4 addresses and any relevant
+
+
+
+Thompson & Huitema Standards Track [Page 3]
+
+RFC 1886 IPv6 DNS Extensions December 1995
+
+
+ IPv6 addresses available locally to the additional section of a
+ response when processing any one of the above queries.
+
+
+4. SECURITY CONSIDERATIONS
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson & Huitema Standards Track [Page 4]
+
+RFC 1886 IPv6 DNS Extensions December 1995
+
+
+5. REFERENCES
+
+
+ [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+ [2] Mockapetris, P., "Domain Names - Implementation and Specifica-
+ tion", STD 13, RFC 1035, USC/Information Sciences Institute,
+ November 1987.
+
+ [3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
+ Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
+ 1995.
+
+
+ [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
+ Hosts and Routers", Work in Progress.
+
+
+Authors' Addresses
+
+ Susan Thomson
+ Bellcore
+ MRE 2P343
+ 445 South Street
+ Morristown, NJ 07960
+ U.S.A.
+
+ Phone: +1 201-829-4514
+ EMail: set@thumper.bellcore.com
+
+
+ Christian Huitema
+ INRIA, Sophia-Antipolis
+ 2004 Route des Lucioles
+ BP 109
+ F-06561 Valbonne Cedex
+ France
+
+ Phone: +33 93 65 77 15
+ EMail: Christian.Huitema@MIRSA.INRIA.FR
+
+
+
+
+
+
+
+Thompson & Huitema Standards Track [Page 5]
+
diff --git a/Documentation/en/rfc/rfc2133.txt b/Documentation/en/rfc/rfc2133.txt
new file mode 100644
index 00000000..ea66cf01
--- /dev/null
+++ b/Documentation/en/rfc/rfc2133.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group R. Gilligan
+Request for Comments: 2133 Freegate
+Category: Informational S. Thomson
+ Bellcore
+ J. Bound
+ Digital
+ W. Stevens
+ Consultant
+ April 1997
+
+ Basic Socket Interface Extensions for IPv6
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ The de facto standard application program interface (API) for TCP/IP
+ applications is the "sockets" interface. Although this API was
+ developed for Unix in the early 1980s it has also been implemented on
+ a wide variety of non-Unix systems. TCP/IP applications written
+ using the sockets API have in the past enjoyed a high degree of
+ portability and we would like the same portability with IPv6
+ applications. But changes are required to the sockets API to support
+ IPv6 and this memo describes these changes. These include a new
+ socket address structure to carry IPv6 addresses, new address
+ conversion functions, and some new socket options. These extensions
+ are designed to provide access to the basic IPv6 features required by
+ TCP and UDP applications, including multicasting, while introducing a
+ minimum of change into the system and providing complete
+ compatibility for existing IPv4 applications. Additional extensions
+ for advanced IPv6 features (raw sockets and access to the IPv6
+ extension headers) are defined in another document [5].
+
+Table of Contents
+
+ 1. Introduction ................................................ 2
+ 2. Design Considerations ....................................... 3
+ 2.1. What Needs to be Changed .................................. 3
+ 2.2. Data Types ................................................ 5
+ 2.3. Headers ................................................... 5
+ 2.4. Structures ................................................ 5
+ 3. Socket Interface ............................................ 5
+ 3.1. IPv6 Address Family and Protocol Family ................... 5
+ 3.2. IPv6 Address Structure .................................... 6
+
+
+
+Gilligan, et. al. Informational [Page 1]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ 3.3. Socket Address Structure for 4.3BSD-Based Systems ......... 6
+ 3.4. Socket Address Structure for 4.4BSD-Based Systems ......... 7
+ 3.5. The Socket Functions ...................................... 8
+ 3.6. Compatibility with IPv4 Applications ...................... 9
+ 3.7. Compatibility with IPv4 Nodes ............................. 9
+ 3.8. IPv6 Wildcard Address ..................................... 10
+ 3.9. IPv6 Loopback Address ..................................... 11
+ 4. Interface Identification .................................... 12
+ 4.1. Name-to-Index ............................................. 13
+ 4.2. Index-to-Name ............................................. 13
+ 4.3. Return All Interface Names and Indexes .................... 14
+ 4.4. Free Memory ............................................... 14
+ 5. Socket Options .............................................. 14
+ 5.1. Changing Socket Type ...................................... 15
+ 5.2. Unicast Hop Limit ......................................... 16
+ 5.3. Sending and Receiving Multicast Packets ................... 17
+ 6. Library Functions ........................................... 19
+ 6.1. Hostname-to-Address Translation ........................... 19
+ 6.2. Address To Hostname Translation ........................... 22
+ 6.3. Protocol-Independent Hostname and Service Name Translation 22
+ 6.4. Socket Address Structure to Hostname and Service Name ..... 25
+ 6.5. Address Conversion Functions .............................. 27
+ 6.6. Address Testing Macros .................................... 28
+ 7. Summary of New Definitions .................................. 29
+ 8. Security Considerations ..................................... 31
+ 9. Acknowledgments ............................................. 31
+ 10. References ................................................. 31
+ 11. Authors' Addresses ......................................... 32
+
+1. Introduction
+
+ While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
+ by 128-bit addresses. The socket interface make the size of an IP
+ address quite visible to an application; virtually all TCP/IP
+ applications for BSD-based systems have knowledge of the size of an
+ IP address. Those parts of the API that expose the addresses must be
+ changed to accommodate the larger IPv6 address size. IPv6 also
+ introduces new features (e.g., flow label and priority), some of
+ which must be made visible to applications via the API. This memo
+ defines a set of extensions to the socket interface to support the
+ larger address size and new features of IPv6.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 2]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+2. Design Considerations
+
+ There are a number of important considerations in designing changes
+ to this well-worn API:
+
+ - The API changes should provide both source and binary
+ compatibility for programs written to the original API. That is,
+ existing program binaries should continue to operate when run on
+ a system supporting the new API. In addition, existing
+ applications that are re-compiled and run on a system supporting
+ the new API should continue to operate. Simply put, the API
+ changes for IPv6 should not break existing programs.
+
+ - The changes to the API should be as small as possible in order to
+ simplify the task of converting existing IPv4 applications to
+ IPv6.
+
+ - Where possible, applications should be able to use this API to
+ interoperate with both IPv6 and IPv4 hosts. Applications should
+ not need to know which type of host they are communicating with.
+
+ - IPv6 addresses carried in data structures should be 64-bit
+ aligned. This is necessary in order to obtain optimum
+ performance on 64-bit machine architectures.
+
+ Because of the importance of providing IPv4 compatibility in the API,
+ these extensions are explicitly designed to operate on machines that
+ provide complete support for both IPv4 and IPv6. A subset of this
+ API could probably be designed for operation on systems that support
+ only IPv6. However, this is not addressed in this memo.
+
+2.1. What Needs to be Changed
+
+ The socket interface API consists of a few distinct components:
+
+ - Core socket functions.
+
+ - Address data structures.
+
+ - Name-to-address translation functions.
+
+ - Address conversion functions.
+
+ The core socket functions -- those functions that deal with such
+ things as setting up and tearing down TCP connections, and sending
+ and receiving UDP packets -- were designed to be transport
+ independent. Where protocol addresses are passed as function
+ arguments, they are carried via opaque pointers. A protocol-specific
+
+
+
+Gilligan, et. al. Informational [Page 3]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ address data structure is defined for each protocol that the socket
+ functions support. Applications must cast pointers to these
+ protocol-specific address structures into pointers to the generic
+ "sockaddr" address structure when using the socket functions. These
+ functions need not change for IPv6, but a new IPv6-specific address
+ data structure is needed.
+
+ The "sockaddr_in" structure is the protocol-specific data structure
+ for IPv4. This data structure actually includes 8-octets of unused
+ space, and it is tempting to try to use this space to adapt the
+ sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in
+ structure is not large enough to hold the 16-octet IPv6 address as
+ well as the other information (address family and port number) that
+ is needed. So a new address data structure must be defined for IPv6.
+
+ The name-to-address translation functions in the socket interface are
+ gethostbyname() and gethostbyaddr(). These must be modified to
+ support IPv6 and the semantics defined must provide 100% backward
+ compatibility for all existing IPv4 applications, along with IPv6
+ support for new applications. Additionally, the POSIX 1003.g work in
+ progress [4] specifies a new hostname-to-address translation function
+ which is protocol independent. This function can also be used with
+ IPv6.
+
+ The address conversion functions -- inet_ntoa() and inet_addr() --
+ convert IPv4 addresses between binary and printable form. These
+ functions are quite specific to 32-bit IPv4 addresses. We have
+ designed two analogous functions that convert both IPv4 and IPv6
+ addresses, and carry an address type parameter so that they can be
+ extended to other protocol families as well.
+
+ Finally, a few miscellaneous features are needed to support IPv6.
+ New interfaces are needed to support the IPv6 flow label, priority,
+ and hop limit header fields. New socket options are needed to
+ control the sending and receiving of IPv6 multicast packets.
+
+ The socket interface will be enhanced in the future to provide access
+ to other IPv6 features. These extensions are described in [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 4]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+2.2. Data Types
+
+ The data types of the structure elements given in this memo are
+ intended to be examples, not absolute requirements. Whenever
+ possible, POSIX 1003.1g data types are used: u_intN_t means an
+ unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t
+ means an unsigned integer of at least N bits (e.g., u_int32m_t). We
+ also assume the argument data types from 1003.1g when possible (e.g.,
+ the final argument to setsockopt() is a size_t value). Whenever
+ buffer sizes are specified, the POSIX 1003.1 size_t data type is used
+ (e.g., the two length arguments to getnameinfo()).
+
+2.3. Headers
+
+ When function prototypes and structures are shown we show the headers
+ that must be #included to cause that item to be defined.
+
+2.4. Structures
+
+ When structures are described the members shown are the ones that
+ must appear in an implementation. Additional, nonstandard members
+ may also be defined by an implementation.
+
+ The ordering shown for the members of a structure is the recommended
+ ordering, given alignment considerations of multibyte members, but an
+ implementation may order the members differently.
+
+3. Socket Interface
+
+ This section specifies the socket interface changes for IPv6.
+
+3.1. IPv6 Address Family and Protocol Family
+
+ A new address family name, AF_INET6, is defined in <sys/socket.h>.
+ The AF_INET6 definition distinguishes between the original
+ sockaddr_in address data structure, and the new sockaddr_in6 data
+ structure.
+
+ A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
+ Like most of the other protocol family names, this will usually be
+ defined to have the same value as the corresponding address family
+ name:
+
+ #define PF_INET6 AF_INET6
+
+ The PF_INET6 is used in the first argument to the socket() function
+ to indicate that an IPv6 socket is being created.
+
+
+
+
+Gilligan, et. al. Informational [Page 5]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+3.2. IPv6 Address Structure
+
+ A new data structure to hold a single IPv6 address is defined as
+ follows:
+
+ #include <netinet/in.h>
+
+ struct in6_addr {
+ u_int8_t s6_addr[16]; /* IPv6 address */
+ }
+
+ This data structure contains an array of sixteen 8-bit elements,
+ which make up one 128-bit IPv6 address. The IPv6 address is stored
+ in network byte order.
+
+3.3. Socket Address Structure for 4.3BSD-Based Systems
+
+ In the socket interface, a different protocol-specific data structure
+ is defined to carry the addresses for each protocol suite. Each
+ protocol-specific data structure is designed so it can be cast into a
+ protocol-independent data structure -- the "sockaddr" structure.
+ Each has a "family" field that overlays the "sa_family" of the
+ sockaddr data structure. This field identifies the type of the data
+ structure.
+
+ The sockaddr_in structure is the protocol-specific address data
+ structure for IPv4. It is used to pass addresses between
+ applications and the system in the socket functions. The following
+ structure is defined to carry IPv6 addresses:
+
+ #include <netinet/in.h>
+
+ struct sockaddr_in6 {
+ u_int16m_t sin6_family; /* AF_INET6 */
+ u_int16m_t sin6_port; /* transport layer port # */
+ u_int32m_t sin6_flowinfo; /* IPv6 flow information */
+ struct in6_addr sin6_addr; /* IPv6 address */
+ };
+
+ This structure is designed to be compatible with the sockaddr data
+ structure used in the 4.3BSD release.
+
+ The sin6_family field identifies this as a sockaddr_in6 structure.
+ This field overlays the sa_family field when the buffer is cast to a
+ sockaddr data structure. The value of this field must be AF_INET6.
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 6]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The sin6_port field contains the 16-bit UDP or TCP port number. This
+ field is used in the same way as the sin_port field of the
+ sockaddr_in structure. The port number is stored in network byte
+ order.
+
+ The sin6_flowinfo field is a 32-bit field that contains two pieces of
+ information: the 24-bit IPv6 flow label and the 4-bit priority field.
+ The contents and interpretation of this member is unspecified at this
+ time.
+
+ The sin6_addr field is a single in6_addr structure (defined in the
+ previous section). This field holds one 128-bit IPv6 address. The
+ address is stored in network byte order.
+
+ The ordering of elements in this structure is specifically designed
+ so that the sin6_addr field will be aligned on a 64-bit boundary.
+ This is done for optimum performance on 64-bit architectures.
+
+ Notice that the sockaddr_in6 structure will normally be larger than
+ the generic sockaddr structure. On many existing implementations the
+ sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
+ being 16 bytes. Any existing code that makes this assumption needs
+ to be examined carefully when converting to IPv6.
+
+3.4. Socket Address Structure for 4.4BSD-Based Systems
+
+ The 4.4BSD release includes a small, but incompatible change to the
+ socket interface. The "sa_family" field of the sockaddr data
+ structure was changed from a 16-bit value to an 8-bit value, and the
+ space saved used to hold a length field, named "sa_len". The
+ sockaddr_in6 data structure given in the previous section cannot be
+ correctly cast into the newer sockaddr data structure. For this
+ reason, the following alternative IPv6 address data structure is
+ provided to be used on systems based on 4.4BSD:
+
+ #include <netinet/in.h>
+
+ #define SIN6_LEN
+
+ struct sockaddr_in6 {
+ u_char sin6_len; /* length of this struct */
+ u_char sin6_family; /* AF_INET6 */
+ u_int16m_t sin6_port; /* transport layer port # */
+ u_int32m_t sin6_flowinfo; /* IPv6 flow information */
+ struct in6_addr sin6_addr; /* IPv6 address */
+ };
+
+
+
+
+
+Gilligan, et. al. Informational [Page 7]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The only differences between this data structure and the 4.3BSD
+ variant are the inclusion of the length field, and the change of the
+ family field to a 8-bit data type. The definitions of all the other
+ fields are identical to the structure defined in the previous
+ section.
+
+ Systems that provide this version of the sockaddr_in6 data structure
+ must also declare SIN6_LEN as a result of including the
+ <netinet/in.h> header. This macro allows applications to determine
+ whether they are being built on a system that supports the 4.3BSD or
+ 4.4BSD variants of the data structure.
+
+3.5. The Socket Functions
+
+ Applications call the socket() function to create a socket descriptor
+ that represents a communication endpoint. The arguments to the
+ socket() function tell the system which protocol to use, and what
+ format address structure will be used in subsequent functions. For
+ example, to create an IPv4/TCP socket, applications make the call:
+
+ s = socket(PF_INET, SOCK_STREAM, 0);
+
+ To create an IPv4/UDP socket, applications make the call:
+
+ s = socket(PF_INET, SOCK_DGRAM, 0);
+
+ Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
+ the constant PF_INET6 instead of PF_INET in the first argument. For
+ example, to create an IPv6/TCP socket, applications make the call:
+
+ s = socket(PF_INET6, SOCK_STREAM, 0);
+
+ To create an IPv6/UDP socket, applications make the call:
+
+ s = socket(PF_INET6, SOCK_DGRAM, 0);
+
+ Once the application has created a PF_INET6 socket, it must use the
+ sockaddr_in6 address structure when passing addresses in to the
+ system. The functions that the application uses to pass addresses
+ into the system are:
+
+ bind()
+ connect()
+ sendmsg()
+ sendto()
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 8]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The system will use the sockaddr_in6 address structure to return
+ addresses to applications that are using PF_INET6 sockets. The
+ functions that return an address from the system to an application
+ are:
+
+ accept()
+ recvfrom()
+ recvmsg()
+ getpeername()
+ getsockname()
+
+ No changes to the syntax of the socket functions are needed to
+ support IPv6, since all of the "address carrying" functions use an
+ opaque address pointer, and carry an address length as a function
+ argument.
+
+3.6. Compatibility with IPv4 Applications
+
+ In order to support the large base of applications using the original
+ API, system implementations must provide complete source and binary
+ compatibility with the original API. This means that systems must
+ continue to support PF_INET sockets and the sockaddr_in address
+ structure. Applications must be able to create IPv4/TCP and IPv4/UDP
+ sockets using the PF_INET constant in the socket() function, as
+ described in the previous section. Applications should be able to
+ hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
+ sockets simultaneously within the same process.
+
+ Applications using the original API should continue to operate as
+ they did on systems supporting only IPv4. That is, they should
+ continue to interoperate with IPv4 nodes.
+
+3.7. Compatibility with IPv4 Nodes
+
+ The API also provides a different type of compatibility: the ability
+ for IPv6 applications to interoperate with IPv4 applications. This
+ feature uses the IPv4-mapped IPv6 address format defined in the IPv6
+ addressing architecture specification [2]. This address format
+ allows the IPv4 address of an IPv4 node to be represented as an IPv6
+ address. The IPv4 address is encoded into the low-order 32 bits of
+ the IPv6 address, and the high-order 96 bits hold the fixed prefix
+ 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows:
+
+ ::FFFF:<IPv4-address>
+
+ These addresses are often generated automatically by the
+ gethostbyname() function when the specified host has only IPv4
+ addresses (as described in Section 6.1).
+
+
+
+Gilligan, et. al. Informational [Page 9]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ Applications may use PF_INET6 sockets to open TCP connections to IPv4
+ nodes, or send UDP packets to IPv4 nodes, by simply encoding the
+ destination's IPv4 address as an IPv4-mapped IPv6 address, and
+ passing that address, within a sockaddr_in6 structure, in the
+ connect() or sendto() call. When applications use PF_INET6 sockets
+ to accept TCP connections from IPv4 nodes, or receive UDP packets
+ from IPv4 nodes, the system returns the peer's address to the
+ application in the accept(), recvfrom(), or getpeername() call using
+ a sockaddr_in6 structure encoded this way.
+
+ Few applications will likely need to know which type of node they are
+ interoperating with. However, for those applications that do need to
+ know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is
+ provided.
+
+3.8. IPv6 Wildcard Address
+
+ While the bind() function allows applications to select the source IP
+ address of UDP packets and TCP connections, applications often want
+ the system to select the source address for them. With IPv4, one
+ specifies the address as the symbolic constant INADDR_ANY (called the
+ "wildcard" address) in the bind() call, or simply omits the bind()
+ entirely.
+
+ Since the IPv6 address type is a structure (struct in6_addr), a
+ symbolic constant can be used to initialize an IPv6 address variable,
+ but cannot be used in an assignment. Therefore systems provide the
+ IPv6 wildcard address in two forms.
+
+ The first version is a global variable named "in6addr_any" that is an
+ in6_addr structure. The extern declaration for this variable is
+ defined in <netinet/in.h>:
+
+ extern const struct in6_addr in6addr_any;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 10]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ Applications use in6addr_any similarly to the way they use INADDR_ANY
+ in IPv4. For example, to bind a socket to port number 23, but let
+ the system select the source address, an application could use the
+ following code:
+
+ struct sockaddr_in6 sin6;
+ . . .
+ sin6.sin6_family = AF_INET6;
+ sin6.sin6_flowinfo = 0;
+ sin6.sin6_port = htons(23);
+ sin6.sin6_addr = in6addr_any; /* structure assignment */
+ . . .
+ if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+ . . .
+
+ The other version is a symbolic constant named IN6ADDR_ANY_INIT and
+ is defined in <netinet/in.h>. This constant can be used to
+ initialize an in6_addr structure:
+
+ struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
+
+ Note that this constant can be used ONLY at declaration time. It can
+ not be used to assign a previously declared in6_addr structure. For
+ example, the following code will not work:
+
+ /* This is the WRONG way to assign an unspecified address */
+ struct sockaddr_in6 sin6;
+ . . .
+ sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
+
+ Be aware that the IPv4 INADDR_xxx constants are all defined in host
+ byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
+ in6addr_xxx externals are defined in network byte order.
+
+3.9. IPv6 Loopback Address
+
+ Applications may need to send UDP packets to, or originate TCP
+ connections to, services residing on the local node. In IPv4, they
+ can do this by using the constant IPv4 address INADDR_LOOPBACK in
+ their connect(), sendto(), or sendmsg() call.
+
+ IPv6 also provides a loopback address to contact local TCP and UDP
+ services. Like the unspecified address, the IPv6 loopback address is
+ provided in two forms -- a global variable and a symbolic constant.
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 11]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The global variable is an in6_addr structure named
+ "in6addr_loopback." The extern declaration for this variable is
+ defined in <netinet/in.h>:
+
+ extern const struct in6_addr in6addr_loopback;
+
+ Applications use in6addr_loopback as they would use INADDR_LOOPBACK
+ in IPv4 applications (but beware of the byte ordering difference
+ mentioned at the end of the previous section). For example, to open
+ a TCP connection to the local telnet server, an application could use
+ the following code:
+
+ struct sockaddr_in6 sin6;
+ . . .
+ sin6.sin6_family = AF_INET6;
+ sin6.sin6_flowinfo = 0;
+ sin6.sin6_port = htons(23);
+ sin6.sin6_addr = in6addr_loopback; /* structure assignment */
+ . . .
+ if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+ . . .
+
+ The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
+ in <netinet/in.h>. It can be used at declaration time ONLY; for
+ example:
+
+ struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
+
+ Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
+ to a previously declared IPv6 address variable.
+
+4. Interface Identification
+
+ This API uses an interface index (a small positive integer) to
+ identify the local interface on which a multicast group is joined
+ (Section 5.3). Additionally, the advanced API [5] uses these same
+ interface indexes to identify the interface on which a datagram is
+ received, or to specify the interface on which a datagram is to be
+ sent.
+
+ Interfaces are normally known by names such as "le0", "sl1", "ppp2",
+ and the like. On Berkeley-derived implementations, when an interface
+ is made known to the system, the kernel assigns a unique positive
+ integer value (called the interface index) to that interface. These
+ are small positive integers that start at 1. (Note that 0 is never
+ used for an interface index.) There may be gaps so that there is no
+ current interface for a particular positive interface index.
+
+
+
+
+Gilligan, et. al. Informational [Page 12]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ This API defines two functions that map between an interface name and
+ index, a third function that returns all the interface names and
+ indexes, and a fourth function to return the dynamic memory allocated
+ by the previous function. How these functions are implemented is
+ left up to the implementation. 4.4BSD implementations can implement
+ these functions using the existing sysctl() function with the
+ NET_RT_LIST command. Other implementations may wish to use ioctl()
+ for this purpose.
+
+4.1. Name-to-Index
+
+ The first function maps an interface name into its corresponding
+ index.
+
+ #include <net/if.h>
+
+ unsigned int if_nametoindex(const char *ifname);
+
+ If the specified interface does not exist, the return value is 0.
+
+4.2. Index-to-Name
+
+ The second function maps an interface index into its corresponding
+ name.
+
+ #include <net/if.h>
+
+ char *if_indextoname(unsigned int ifindex, char *ifname);
+
+ The ifname argument must point to a buffer of at least IFNAMSIZ bytes
+ into which the interface name corresponding to the specified index is
+ returned. (IFNAMSIZ is also defined in <net/if.h> and its value
+ includes a terminating null byte at the end of the interface name.)
+ This pointer is also the return value of the function. If there is
+ no interface corresponding to the specified index, NULL is returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 13]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+4.3. Return All Interface Names and Indexes
+
+ The final function returns an array of if_nameindex structures, one
+ structure per interface.
+
+ #include <net/if.h>
+
+ struct if_nameindex {
+ unsigned int if_index; /* 1, 2, ... */
+ char *if_name; /* null terminated name: "le0", ... */
+ };
+
+ struct if_nameindex *if_nameindex(void);
+
+ The end of the array of structures is indicated by a structure with
+ an if_index of 0 and an if_name of NULL. The function returns a NULL
+ pointer upon an error.
+
+ The memory used for this array of structures along with the interface
+ names pointed to by the if_name members is obtained dynamically.
+ This memory is freed by the next function.
+
+4.4. Free Memory
+
+ The following function frees the dynamic memory that was allocated by
+ if_nameindex().
+
+ #include <net/if.h>
+
+ void if_freenameindex(struct if_nameindex *ptr);
+
+ The argument to this function must be a pointer that was returned by
+ if_nameindex().
+
+5. Socket Options
+
+ A number of new socket options are defined for IPv6. All of these
+ new options are at the IPPROTO_IPV6 level. That is, the "level"
+ parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
+ when using these options. The constant name prefix IPV6_ is used in
+ all of the new socket options. This serves to clearly identify these
+ options as applying to IPv6.
+
+ The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
+ related constants defined in this section are obtained by including
+ the header <netinet/in.h>.
+
+
+
+
+
+Gilligan, et. al. Informational [Page 14]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+5.1. Changing Socket Type
+
+ Unix allows open sockets to be passed between processes via the
+ exec() call and other means. It is a relatively common application
+ practice to pass open sockets across exec() calls. Thus it is
+ possible for an application using the original API to pass an open
+ PF_INET socket to an application that is expecting to receive a
+ PF_INET6 socket. Similarly, it is possible for an application using
+ the extended API to pass an open PF_INET6 socket to an application
+ using the original API, which would be equipped only to deal with
+ PF_INET sockets. Either of these cases could cause problems, because
+ the application that is passed the open socket might not know how to
+ decode the address structures returned in subsequent socket
+ functions.
+
+ To remedy this problem, a new setsockopt() option is defined that
+ allows an application to "convert" a PF_INET6 socket into a PF_INET
+ socket and vice versa.
+
+ An IPv6 application that is passed an open socket from an unknown
+ process may use the IPV6_ADDRFORM setsockopt() option to "convert"
+ the socket to PF_INET6. Once that has been done, the system will
+ return sockaddr_in6 address structures in subsequent socket
+ functions.
+
+ An IPv6 application that is about to pass an open PF_INET6 socket to
+ a program that is not be IPv6 capable can "downgrade" the socket to
+ PF_INET before calling exec(). After that, the system will return
+ sockaddr_in address structures to the application that was exec()'ed.
+ Be aware that you cannot downgrade an IPv6 socket to an IPv4 socket
+ unless all nonwildcard addresses already associated with the IPv6
+ socket are IPv4-mapped IPv6 addresses.
+
+ The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and
+ IPPROTO_IPV6 levels. The only valid option values are PF_INET6 and
+ PF_INET. For example, to convert a PF_INET6 socket to PF_INET, a
+ program would call:
+
+ int addrform = PF_INET;
+
+ if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
+ (char *) &addrform, sizeof(addrform)) == -1)
+ perror("setsockopt IPV6_ADDRFORM");
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 15]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ An application may use IPV6_ADDRFORM with getsockopt() to learn
+ whether an open socket is a PF_INET of PF_INET6 socket. For example:
+
+ int addrform;
+ size_t len = sizeof(addrform);
+
+ if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
+ (char *) &addrform, &len) == -1)
+ perror("getsockopt IPV6_ADDRFORM");
+ else if (addrform == PF_INET)
+ printf("This is an IPv4 socket.\n");
+ else if (addrform == PF_INET6)
+ printf("This is an IPv6 socket.\n");
+ else
+ printf("This system is broken.\n");
+
+5.2. Unicast Hop Limit
+
+ A new setsockopt() option controls the hop limit used in outgoing
+ unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS,
+ and it is used at the IPPROTO_IPV6 layer. The following example
+ illustrates how it is used:
+
+ int hoplimit = 10;
+
+ if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+ (char *) &hoplimit, sizeof(hoplimit)) == -1)
+ perror("setsockopt IPV6_UNICAST_HOPS");
+
+ When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
+ option value given is used as the hop limit for all subsequent
+ unicast packets sent via that socket. If the option is not set, the
+ system selects a default value. The integer hop limit value (called
+ x) is interpreted as follows:
+
+ x < -1: return an error of EINVAL
+ x == -1: use kernel default
+ 0 <= x <= 255: use x
+ x >= 256: return an error of EINVAL
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 16]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The IPV6_UNICAST_HOPS option may be used with getsockopt() to
+ determine the hop limit value that the system will use for subsequent
+ unicast packets sent via that socket. For example:
+
+ int hoplimit;
+ size_t len = sizeof(hoplimit);
+
+ if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+ (char *) &hoplimit, &len) == -1)
+ perror("getsockopt IPV6_UNICAST_HOPS");
+ else
+ printf("Using %d for hop limit.\n", hoplimit);
+
+5.3. Sending and Receiving Multicast Packets
+
+ IPv6 applications may send UDP multicast packets by simply specifying
+ an IPv6 multicast address in the address argument of the sendto()
+ function.
+
+ Three socket options at the IPPROTO_IPV6 layer control some of the
+ parameters for sending multicast packets. Setting these options is
+ not required: applications may send multicast packets without using
+ these options. The setsockopt() options for controlling the sending
+ of multicast packets are summarized below:
+
+ IPV6_MULTICAST_IF
+
+ Set the interface to use for outgoing multicast packets. The
+ argument is the index of the interface to use.
+
+ Argument type: unsigned int
+
+ IPV6_MULTICAST_HOPS
+
+ Set the hop limit to use for outgoing multicast packets.
+ (Note a separate option - IPV6_UNICAST_HOPS - is provided to
+ set the hop limit to use for outgoing unicast packets.) The
+ interpretation of the argument is the same as for the
+ IPV6_UNICAST_HOPS option:
+
+ x < -1: return an error of EINVAL
+ x == -1: use kernel default
+ 0 <= x <= 255: use x
+ x >= 256: return an error of EINVAL
+
+ Argument type: int
+
+
+
+
+
+Gilligan, et. al. Informational [Page 17]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ IPV6_MULTICAST_LOOP
+
+ Controls whether outgoing multicast packets sent should be
+ delivered back to the local application. A toggle. If the
+ option is set to 1, multicast packets are looped back. If it
+ is set to 0, they are not.
+
+ Argument type: unsigned int
+
+ The reception of multicast packets is controlled by the two
+ setsockopt() options summarized below:
+
+ IPV6_ADD_MEMBERSHIP
+
+ Join a multicast group on a specified local interface. If
+ the interface index is specified as 0, the kernel chooses the
+ local interface. For example, some kernels look up the
+ multicast group in the normal IPv6 routing table and using
+ the resulting interface.
+
+ Argument type: struct ipv6_mreq
+
+ IPV6_DROP_MEMBERSHIP
+
+ Leave a multicast group on a specified interface.
+
+ Argument type: struct ipv6_mreq
+
+ The argument type of both of these options is the ipv6_mreq
+ structure, defined as:
+
+ #include <netinet/in.h>
+
+ struct ipv6_mreq {
+ struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
+ unsigned int ipv6mr_interface; /* interface index */
+ };
+
+ Note that to receive multicast datagrams a process must join the
+ multicast group and bind the UDP port to which datagrams will be
+ sent. Some processes also bind the multicast group address to the
+ socket, in addition to the port, to prevent other datagrams destined
+ to that same port from being delivered to the socket.
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 18]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+6. Library Functions
+
+ New library functions are needed to perform a variety of operations
+ with IPv6 addresses. Functions are needed to lookup IPv6 addresses
+ in the Domain Name System (DNS). Both forward lookup (hostname-to-
+ address translation) and reverse lookup (address-to-hostname
+ translation) need to be supported. Functions are also needed to
+ convert IPv6 addresses between their binary and textual form.
+
+6.1. Hostname-to-Address Translation
+
+ The commonly used function gethostbyname() remains unchanged as does
+ the hostent structure to which it returns a pointer. Existing
+ applications that call this function continue to receive only IPv4
+ addresses that are the result of a query in the DNS for A records.
+ (We assume the DNS is being used; some environments may be using a
+ hosts file or some other name resolution system, either of which may
+ impede renumbering. We also assume that the RES_USE_INET6 resolver
+ option is not set, which we describe in more detail shortly.)
+
+ Two new changes are made to support IPv6 addresses. First, the
+ following function is new:
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ struct hostent *gethostbyname2(const char *name, int af);
+
+ The af argument specifies the address family. The default operation
+ of this function is simple:
+
+ - If the af argument is AF_INET, then a query is made for A
+ records. If successful, IPv4 addresses are returned and the
+ h_length member of the hostent structure will be 4, else the
+ function returns a NULL pointer.
+
+ - If the af argument is AF_INET6, then a query is made for AAAA
+ records. If successful, IPv6 addresses are returned and the
+ h_length member of the hostent structure will be 16, else the
+ function returns a NULL pointer.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 19]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The second change, that provides additional functionality, is a new
+ resolver option RES_USE_INET6, which is defined as a result of
+ including the <resolv.h> header. (This option is provided starting
+ with the BIND 4.9.4 release.) There are three ways to set this
+ option.
+
+ - The first way is
+
+ res_init();
+ _res.options |= RES_USE_INET6;
+
+ and then call either gethostbyname() or gethostbyname2(). This
+ option then affects only the process that is calling the
+ resolver.
+
+ - The second way to set this option is to set the environment
+ variable RES_OPTIONS, as in RES_OPTIONS=inet6. (This example is
+ for the Bourne and Korn shells.) This method affects any
+ processes that see this environment variable.
+
+ - The third way is to set this option in the resolver configuration
+ file (normally /etc/resolv.conf) and the option then affects all
+ applications on the host. This final method should not be done
+ until all applications on the host are capable of dealing with
+ IPv6 addresses.
+
+ There is no priority among these three methods. When the
+ RES_USE_INET6 option is set, two changes occur:
+
+ - gethostbyname(host) first calls gethostbyname2(host, AF_INET6)
+ looking for AAAA records, and if this fails it then calls
+ gethostbyname2(host, AF_INET) looking for A records.
+
+ - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6
+ addresses with the h_length member of the hostent structure set
+ to 16.
+
+ An application must not enable the RES_USE_INET6 option until it is
+ prepared to deal with 16-byte addresses in the returned hostent
+ structure.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 20]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The following table summarizes the operation of the existing
+ gethostbyname() function, the new function gethostbyname2(), along
+ with the new resolver option RES_USE_INET6.
+
++------------------+---------------------------------------------------+
+| | RES_USE_INET6 option |
+| +-------------------------+-------------------------+
+| | off | on |
++------------------+-------------------------+-------------------------+
+| |Search for A records. |Search for AAAA records. |
+| gethostbyname | If found, return IPv4 | If found, return IPv6 |
+| (host) | addresses (h_length=4). | addresses (h_length=16).|
+| | Else error. | Else search for A |
+| | | records. If found, |
+| |Provides backward | return IPv4-mapped IPv6 |
+| | compatibility with all | addresses (h_length=16).|
+| | existing IPv4 appls. | Else error. |
++------------------+-------------------------+-------------------------+
+| |Search for A records. |Search for A records. |
+| gethostbyname2 | If found, return IPv4 | If found, return |
+| (host, AF_INET) | addresses (h_length=4). | IPv4-mapped IPv6 |
+| | Else error. | addresses (h_length=16).|
+| | | Else error. |
++------------------+-------------------------+-------------------------+
+| |Search for AAAA records. |Search for AAAA records. |
+| gethostbyname2 | If found, return IPv6 | If found, return IPv6 |
+| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).|
+| | Else error. | Else error. |
++------------------+-------------------------+-------------------------+
+
+ It is expected that when a typical naive application that calls
+ gethostbyname() today is modified to use IPv6, it simply changes the
+ program to use IPv6 sockets and then enables the RES_USE_INET6
+ resolver option before calling gethostbyname(). This application
+ will then work with either IPv4 or IPv6 peers.
+
+ Note that gethostbyname() and gethostbyname2() are not thread-safe,
+ since both return a pointer to a static hostent structure. But
+ several vendors have defined a thread-safe gethostbyname_r() function
+ that requires four additional arguments. We expect these vendors to
+ also define a gethostbyname2_r() function.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 21]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+6.2. Address To Hostname Translation
+
+ The existing gethostbyaddr() function already requires an address
+ family argument and can therefore work with IPv6 addresses:
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ struct hostent *gethostbyaddr(const char *src, int len, int af);
+
+ One possible source of confusion is the handling of IPv4-mapped IPv6
+ addresses and IPv4-compatible IPv6 addresses. This is addressed in
+ [6] and involves the following logic:
+
+ 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address
+ is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6
+ address, then skip over the first 12 bytes of the IPv6 address,
+ set af to AF_INET, and set len to 4.
+
+ 2. If af is AF_INET, then query for a PTR record in the in-
+ addr.arpa domain.
+
+ 3. If af is AF_INET6, then query for a PTR record in the ip6.int
+ domain.
+
+ 4. If the function is returning success, and if af equals AF_INET,
+ and if the RES_USE_INET6 option was set, then the single address
+ that is returned in the hostent structure (a copy of the first
+ argument to the function) is returned as an IPv4-mapped IPv6
+ address and the h_length member is set to 16.
+
+ All four steps listed are performed, in order. The same caveats
+ regarding a thread-safe version of gethostbyname() that were made at
+ the end of the previous section apply here as well.
+
+6.3. Protocol-Independent Hostname and Service Name Translation
+
+ Hostname-to-address translation is done in a protocol-independent
+ fashion using the getaddrinfo() function that is taken from the
+ Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
+ (Protocol Independent Interfaces) work in progress specification [4].
+
+ The official specification for this function will be the final POSIX
+ standard. We are providing this independent description of the
+ function because POSIX standards are not freely available (as are
+ IETF documents). Should there be any discrepancies between this
+ description and the POSIX description, the POSIX description takes
+ precedence.
+
+
+
+Gilligan, et. al. Informational [Page 22]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ int getaddrinfo(const char *hostname, const char *servname,
+ const struct addrinfo *hints,
+ struct addrinfo **res);
+
+ The addrinfo structure is defined as:
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ struct addrinfo {
+ int ai_flags; /* AI_PASSIVE, AI_CANONNAME */
+ int ai_family; /* PF_xxx */
+ int ai_socktype; /* SOCK_xxx */
+ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
+ size_t ai_addrlen; /* length of ai_addr */
+ char *ai_canonname; /* canonical name for hostname */
+ struct sockaddr *ai_addr; /* binary address */
+ struct addrinfo *ai_next; /* next structure in linked list */
+ };
+
+ The return value from the function is 0 upon success or a nonzero
+ error code. The following names are the nonzero error codes from
+ getaddrinfo(), and are defined in <netdb.h>:
+
+ EAI_ADDRFAMILY address family for hostname not supported
+ EAI_AGAIN temporary failure in name resolution
+ EAI_BADFLAGS invalid value for ai_flags
+ EAI_FAIL non-recoverable failure in name resolution
+ EAI_FAMILY ai_family not supported
+ EAI_MEMORY memory allocation failure
+ EAI_NODATA no address associated with hostname
+ EAI_NONAME hostname nor servname provided, or not known
+ EAI_SERVICE servname not supported for ai_socktype
+ EAI_SOCKTYPE ai_socktype not supported
+ EAI_SYSTEM system error returned in errno
+
+ The hostname and servname arguments are pointers to null-terminated
+ strings or NULL. One or both of these two arguments must be a non-
+ NULL pointer. In the normal client scenario, both the hostname and
+ servname are specified. In the normal server scenario, only the
+ servname is specified. A non-NULL hostname string can be either a
+ host name or a numeric host address string (i.e., a dotted-decimal
+ IPv4 address or an IPv6 hex address). A non-NULL servname string can
+ be either a service name or a decimal port number.
+
+
+
+
+Gilligan, et. al. Informational [Page 23]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The caller can optionally pass an addrinfo structure, pointed to by
+ the third argument, to provide hints concerning the type of socket
+ that the caller supports. In this hints structure all members other
+ than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
+ or a NULL pointer. A value of PF_UNSPEC for ai_family means the
+ caller will accept any protocol family. A value of 0 for ai_socktype
+ means the caller will accept any socket type. A value of 0 for
+ ai_protocol means the caller will accept any protocol. For example,
+ if the caller handles only TCP and not UDP, then the ai_socktype
+ member of the hints structure should be set to SOCK_STREAM when
+ getaddrinfo() is called. If the caller handles only IPv4 and not
+ IPv6, then the ai_family member of the hints structure should be set
+ to PF_INET when getaddrinfo() is called. If the third argument to
+ getaddrinfo() is a NULL pointer, this is the same as if the caller
+ had filled in an addrinfo structure initialized to zero with
+ ai_family set to PF_UNSPEC.
+
+ Upon successful return a pointer to a linked list of one or more
+ addrinfo structures is returned through the final argument. The
+ caller can process each addrinfo structure in this list by following
+ the ai_next pointer, until a NULL pointer is encountered. In each
+ returned addrinfo structure the three members ai_family, ai_socktype,
+ and ai_protocol are the corresponding arguments for a call to the
+ socket() function. In each addrinfo structure the ai_addr member
+ points to a filled-in socket address structure whose length is
+ specified by the ai_addrlen member.
+
+ If the AI_PASSIVE bit is set in the ai_flags member of the hints
+ structure, then the caller plans to use the returned socket address
+ structure in a call to bind(). In this case, if the hostname
+ argument is a NULL pointer, then the IP address portion of the socket
+ address structure will be set to INADDR_ANY for an IPv4 address or
+ IN6ADDR_ANY_INIT for an IPv6 address.
+
+ If the AI_PASSIVE bit is not set in the ai_flags member of the hints
+ structure, then the returned socket address structure will be ready
+ for a call to connect() (for a connection-oriented protocol) or
+ either connect(), sendto(), or sendmsg() (for a connectionless
+ protocol). In this case, if the hostname argument is a NULL pointer,
+ then the IP address portion of the socket address structure will be
+ set to the loopback address.
+
+ If the AI_CANONNAME bit is set in the ai_flags member of the hints
+ structure, then upon successful return the ai_canonname member of the
+ first addrinfo structure in the linked list will point to a null-
+ terminated string containing the canonical name of the specified
+ hostname.
+
+
+
+
+Gilligan, et. al. Informational [Page 24]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ All of the information returned by getaddrinfo() is dynamically
+ allocated: the addrinfo structures, and the socket address structures
+ and canonical host name strings pointed to by the addrinfo
+ structures. To return this information to the system the function
+ freeaddrinfo() is called:
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ void freeaddrinfo(struct addrinfo *ai);
+
+ The addrinfo structure pointed to by the ai argument is freed, along
+ with any dynamic storage pointed to by the structure. This operation
+ is repeated until a NULL ai_next pointer is encountered.
+
+ To aid applications in printing error messages based on the EAI_xxx
+ codes returned by getaddrinfo(), the following function is defined.
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ char *gai_strerror(int ecode);
+
+ The argument is one of the EAI_xxx values defined earlier and the
+ eturn value points to a string describing the error. If the argument
+ is not one of the EAI_xxx values, the function still returns a
+ pointer to a string whose contents indicate an unknown error.
+
+6.4. Socket Address Structure to Hostname and Service Name
+
+ The POSIX 1003.1g specification includes no function to perform the
+ reverse conversion from getaddrinfo(): to look up a hostname and
+ service name, given the binary address and port. Therefore, we
+ define the following function:
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ int getnameinfo(const struct sockaddr *sa, size_t salen,
+ char *host, size_t hostlen,
+ char *serv, size_t servlen,
+ int flags);
+
+ This function looks up an IP address and port number provided by the
+ caller in the DNS and system-specific database, and returns text
+ strings for both in buffers provided by the caller. The function
+ indicates successful completion by a zero return value; a non-zero
+ return value indicates failure.
+
+
+
+Gilligan, et. al. Informational [Page 25]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The first argument, sa, points to either a sockaddr_in structure (for
+ IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
+ address and port number. The salen argument gives the length of the
+ sockaddr_in or sockaddr_in6 structure.
+
+ The function returns the hostname associated with the IP address in
+ the buffer pointed to by the host argument. The caller provides the
+ size of this buffer via the hostlen argument. The service name
+ associated with the port number is returned in the buffer pointed to
+ by serv, and the servlen argument gives the length of this buffer.
+ The caller specifies not to return either string by providing a zero
+ value for the hostlen or servlen arguments. Otherwise, the caller
+ must provide buffers large enough to hold the hostname and the
+ service name, including the terminating null characters.
+
+ Unfortunately most systems do not provide constants that specify the
+ maximum size of either a fully-qualified domain name or a service
+ name. Therefore to aid the application in allocating buffers for
+ these two returned strings the following constants are defined in
+ <netdb.h>:
+
+ #define NI_MAXHOST 1025
+ #define NI_MAXSERV 32
+
+ The first value is actually defined as the constant MAXDNAME in
+ recent versions of BIND's <arpa/nameser.h> header (older versions of
+ BIND define this constant to be 256) and the second is a guess based
+ on the services listed in the current Assigned Numbers RFC.
+
+ The final argument is a flag that changes the default actions of this
+ function. By default the fully-qualified domain name (FQDN) for the
+ host is looked up in the DNS and returned. If the flag bit NI_NOFQDN
+ is set, only the hostname portion of the FQDN is returned for local
+ hosts.
+
+ If the flag bit NI_NUMERICHOST is set, or if the host's name cannot
+ be located in the DNS, the numeric form of the host's address is
+ returned instead of its name (e.g., by calling inet_ntop() instead of
+ gethostbyaddr()). If the flag bit NI_NAMEREQD is set, an error is
+ returned if the host's name cannot be located in the DNS.
+
+ If the flag bit NI_NUMERICSERV is set, the numeric form of the
+ service address is returned (e.g., its port number) instead of its
+ name. The two NI_NUMERICxxx flags are required to support the "-n"
+ flag that many commands provide.
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 26]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
+ service, and causes getservbyport() to be called with a second
+ argument of "udp" instead of its default of "tcp". This is required
+ for the few ports (512-514) that have different services for UDP and
+ TCP.
+
+ These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
+ flags already defined for getaddrinfo().
+
+6.5. Address Conversion Functions
+
+ The two functions inet_addr() and inet_ntoa() convert an IPv4 address
+ between binary and text form. IPv6 applications need similar
+ functions. The following two functions convert both IPv6 and IPv4
+ addresses:
+
+ #include <sys/socket.h>
+ #include <arpa/inet.h>
+
+ int inet_pton(int af, const char *src, void *dst);
+
+ const char *inet_ntop(int af, const void *src,
+ char *dst, size_t size);
+
+ The inet_pton() function converts an address in its standard text
+ presentation form into its numeric binary form. The af argument
+ specifies the family of the address. Currently the AF_INET and
+ AF_INET6 address families are supported. The src argument points to
+ the string being passed in. The dst argument points to a buffer into
+ which the function stores the numeric address. The address is
+ returned in network byte order. Inet_pton() returns 1 if the
+ conversion succeeds, 0 if the input is not a valid IPv4 dotted-
+ decimal string or a valid IPv6 address string, or -1 with errno set
+ to EAFNOSUPPORT if the af argument is unknown. The calling
+ application must ensure that the buffer referred to by dst is large
+ enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
+ bytes for AF_INET6).
+
+ If the af argument is AF_INET, the function accepts a string in the
+ standard IPv4 dotted-decimal form:
+
+ ddd.ddd.ddd.ddd
+
+ where ddd is a one to three digit decimal number between 0 and 255.
+ Note that many implementations of the existing inet_addr() and
+ inet_aton() functions accept nonstandard input: octal numbers,
+ hexadecimal numbers, and fewer than four numbers. inet_pton() does
+ not accept these formats.
+
+
+
+Gilligan, et. al. Informational [Page 27]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ If the af argument is AF_INET6, then the function accepts a string in
+ one of the standard IPv6 text forms defined in Section 2.2 of the
+ addressing architecture specification [2].
+
+ The inet_ntop() function converts a numeric address into a text
+ string suitable for presentation. The af argument specifies the
+ family of the address. This can be AF_INET or AF_INET6. The src
+ argument points to a buffer holding an IPv4 address if the af
+ argument is AF_INET, or an IPv6 address if the af argument is
+ AF_INET6. The dst argument points to a buffer where the function
+ will store the resulting text string. The size argument specifies
+ the size of this buffer. The application must specify a non-NULL dst
+ argument. For IPv6 addresses, the buffer must be at least 46-octets.
+ For IPv4 addresses, the buffer must be at least 16-octets. In order
+ to allow applications to easily declare buffers of the proper size to
+ store IPv4 and IPv6 addresses in string form, the following two
+ constants are defined in <netinet/in.h>:
+
+ #define INET_ADDRSTRLEN 16
+ #define INET6_ADDRSTRLEN 46
+
+ The inet_ntop() function returns a pointer to the buffer containing
+ the text string if the conversion succeeds, and NULL otherwise. Upon
+ failure, errno is set to EAFNOSUPPORT if the af argument is invalid
+ or ENOSPC if the size of the result buffer is inadequate.
+
+6.6. Address Testing Macros
+
+ The following macros can be used to test for special IPv6 addresses.
+
+ #include <netinet/in.h>
+
+ int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
+ int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
+ int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
+ int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
+ int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
+ int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
+ int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
+
+ int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+ int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+ int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+ int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
+ int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 28]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ The first seven macros return true if the address is of the specified
+ type, or false otherwise. The last five test the scope of a
+ multicast address and return true if the address is a multicast
+ address of the specified scope or false if the address is either not
+ a multicast address or not of the specified scope.
+
+7. Summary of New Definitions
+
+ The following list summarizes the constants, structure, and extern
+ definitions discussed in this memo, sorted by header.
+
+ <net/if.h> IFNAMSIZ
+ <net/if.h> struct if_nameindex{};
+
+ <netdb.h> AI_CANONNAME
+ <netdb.h> AI_PASSIVE
+ <netdb.h> EAI_ADDRFAMILY
+ <netdb.h> EAI_AGAIN
+ <netdb.h> EAI_BADFLAGS
+ <netdb.h> EAI_FAIL
+ <netdb.h> EAI_FAMILY
+ <netdb.h> EAI_MEMORY
+ <netdb.h> EAI_NODATA
+ <netdb.h> EAI_NONAME
+ <netdb.h> EAI_SERVICE
+ <netdb.h> EAI_SOCKTYPE
+ <netdb.h> EAI_SYSTEM
+ <netdb.h> NI_DGRAM
+ <netdb.h> NI_MAXHOST
+ <netdb.h> NI_MAXSERV
+ <netdb.h> NI_NAMEREQD
+ <netdb.h> NI_NOFQDN
+ <netdb.h> NI_NUMERICHOST
+ <netdb.h> NI_NUMERICSERV
+ <netdb.h> struct addrinfo{};
+
+ <netinet/in.h> IN6ADDR_ANY_INIT
+ <netinet/in.h> IN6ADDR_LOOPBACK_INIT
+ <netinet/in.h> INET6_ADDRSTRLEN
+ <netinet/in.h> INET_ADDRSTRLEN
+ <netinet/in.h> IPPROTO_IPV6
+ <netinet/in.h> IPV6_ADDRFORM
+ <netinet/in.h> IPV6_ADD_MEMBERSHIP
+ <netinet/in.h> IPV6_DROP_MEMBERSHIP
+ <netinet/in.h> IPV6_MULTICAST_HOPS
+ <netinet/in.h> IPV6_MULTICAST_IF
+ <netinet/in.h> IPV6_MULTICAST_LOOP
+ <netinet/in.h> IPV6_UNICAST_HOPS
+
+
+
+Gilligan, et. al. Informational [Page 29]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ <netinet/in.h> SIN6_LEN
+ <netinet/in.h> extern const struct in6_addr in6addr_any;
+ <netinet/in.h> extern const struct in6_addr in6addr_loopback;
+ <netinet/in.h> struct in6_addr{};
+ <netinet/in.h> struct ipv6_mreq{};
+ <netinet/in.h> struct sockaddr_in6{};
+
+ <resolv.h> RES_USE_INET6
+
+ <sys/socket.h> AF_INET6
+ <sys/socket.h> PF_INET6
+
+
+ The following list summarizes the function and macro prototypes
+ discussed in this memo, sorted by header.
+
+<arpa/inet.h> int inet_pton(int, const char *, void *);
+<arpa/inet.h> const char *inet_ntop(int, const void *,
+ char *, size_t);
+
+<net/if.h> char *if_indextoname(unsigned int, char *);
+<net/if.h> unsigned int if_nametoindex(const char *);
+<net/if.h> void if_freenameindex(struct if_nameindex *);
+<net/if.h> struct if_nameindex *if_nameindex(void);
+
+<netdb.h> int getaddrinfo(const char *, const char *,
+ const struct addrinfo *,
+ struct addrinfo **);
+<netdb.h> int getnameinfo(const struct sockaddr *, size_t,
+ char *, size_t, char *, size_t, int);
+<netdb.h> void freeaddrinfo(struct addrinfo *);
+<netdb.h> char *gai_strerror(int);
+<netdb.h> struct hostent *gethostbyname(const char *);
+<netdb.h> struct hostent *gethostbyaddr(const char *, int, int);
+<netdb.h> struct hostent *gethostbyname2(const char *, int);
+
+<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+
+
+
+Gilligan, et. al. Informational [Page 30]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+8. Security Considerations
+
+ IPv6 provides a number of new security mechanisms, many of which need
+ to be accessible to applications. A companion memo detailing the
+ extensions to the socket interfaces to support IPv6 security is being
+ written [3].
+
+9. Acknowledgments
+
+ Thanks to the many people who made suggestions and provided feedback
+ to to the numerous revisions of this document, including: Werner
+ Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson,
+ Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont,
+ Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-
+ Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan
+ Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas
+ Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc
+ Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
+ Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
+ Waitzman, Carl Williams, and Kazuhiko Yamamoto,
+
+ The getaddrinfo() and getnameinfo() functions are taken from an
+ earlier Work in Progress by Keith Sklower. As noted in that
+ document, William Durst, Steven Wise, Michael Karels, and Eric Allman
+ provided many useful discussions on the subject of protocol-
+ independent name-to-address translation, and reviewed early versions
+ of Keith Sklower's original proposal. Eric Allman implemented the
+ first prototype of getaddrinfo(). The observation that specifying
+ the pair of name and service would suffice for connecting to a
+ service independent of protocol details was made by Marshall Rose in
+ a proposal to X/Open for a "Uniform Network Interface".
+
+ Craig Metz made many contributions to this document. Ramesh Govindan
+ made a number of contributions and co-authored an earlier version of
+ this memo.
+
+10. References
+
+ [1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 1883, December 1995.
+
+ [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
+ RFC 1884, December 1995.
+
+ [3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets",
+ Work in Progress.
+
+
+
+
+
+Gilligan, et. al. Informational [Page 31]
+
+RFC 2133 IPv6 Socket Interface Extensions April 1997
+
+
+ [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
+ 6.3, November 1995.
+
+ [5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6",
+ Work in Progress.
+
+ [6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in
+ IPv6", Work in Progress.
+
+11. Authors' Addresses
+
+ Robert E. Gilligan
+ Freegate Corporation
+ 710 Lakeway Dr. STE 230
+ Sunnyvale, CA 94086
+
+ Phone: +1 408 524 4804
+ EMail: gilligan@freegate.net
+
+
+ Susan Thomson
+ Bell Communications Research
+ MRE 2P-343, 445 South Street
+ Morristown, NJ 07960
+
+ Phone: +1 201 829 4514
+ EMail: set@thumper.bellcore.com
+
+
+ Jim Bound
+ Digital Equipment Corporation
+ 110 Spitbrook Road ZK3-3/U14
+ Nashua, NH 03062-2698
+
+ Phone: +1 603 881 0400
+ Email: bound@zk3.dec.com
+
+
+ W. Richard Stevens
+ 1202 E. Paseo del Zorro
+ Tucson, AZ 85718-2826
+
+ Phone: +1 520 297 9416
+ EMail: rstevens@kohala.com
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 32]
+
diff --git a/Documentation/en/rfc/rfc2546.txt b/Documentation/en/rfc/rfc2546.txt
new file mode 100644
index 00000000..eee60218
--- /dev/null
+++ b/Documentation/en/rfc/rfc2546.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group A. Durand
+Request for Comments: 2546 IMAG
+Category: Informational B. Buclin
+ AT&T Labs Europe
+ March 1999
+
+
+ 6Bone Routing Practice
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+1. Introduction
+
+ The 6Bone is an environment supporting experimentation with the IPv6
+ protocols and products implementing it. As the network grows, the
+ need for common operation rules emerged. In particular, operation of
+ the 6Bone backbone is a challenge due to the frequent insertion of
+ bogus routes by leaf or even backbone sites.
+
+ This memo identifies guidelines on how 6Bone sites might operate, so
+ that the 6Bone can remain a quality experimentation environment and
+ to avoid pathological situations that have been encountered in the
+ past. It defines the 'best current practice' acceptable in the 6Bone
+ for the configuration of both Interior Gateway Protocols (such as
+ RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC
+ 2283]).
+
+ 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].
+
+2. Basic principles
+
+ The 6Bone is structured as a hierarchical network with pseudo Top
+ Level Aggregator (pTLA) sites, pseudo Next Level Aggregator (pNLA)
+ sites and leaf sites. This topology supports the IPv6 address
+ aggregation architecture as described in [1]. The 6Bone backbone is
+ made of a mesh interconnecting pTLAs only. pNLAs connect to one or
+ more pTLAs and provide transit service for leaf sites.
+
+
+
+
+Durand & Buclin Informational [Page 1]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+ pTLA sites MUST use BGP4+ [RFC 2283] as the mandatory routing
+ protocol for exchanging routing information among them.
+
+ Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY
+ use a simple default route to their ISP.
+
+3. Common Rules
+
+ This section details common rules governing the routing on the 6Bone.
+ They are derived from issues encountered on the 6Bone, with respect
+ to the routes advertised, handling of special addresses, and
+ aggregation:
+
+ 1) link local prefixes
+
+ 2) site local prefixes
+
+ 3) loopback prefix & unspecified prefix
+
+ 4) multicast prefixes
+
+ 5) IPv4-compatible prefixes
+
+ 6) IPv4-mapped prefixes
+
+ 7) default routes
+
+ 8) Yet undefined unicast prefixes (from a different /3 prefix)
+
+ 9) Inter site links issues
+
+ 10) aggregation & advertisement issues
+
+3.1 Link-local prefix
+
+ The link-local prefix (FE80::/10) MUST NOT be advertised through
+ either an IGP or an EGP.
+
+ By definition, the link-local prefix has a scope limited to a
+ specific link. Since the prefix is the same on all IPv6 links,
+ advertising it in any routing protocol does not make sense and,
+ worse, may introduce nasty error conditions.
+
+ Well known cases where link local prefixes could be advertised by
+ mistake include:
+
+
+
+
+
+
+Durand & Buclin Informational [Page 2]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+ - a router advertising all directly connected network prefixes
+ including the link-local one.
+
+ - Subnetting of the link-local prefix.
+
+ In such cases, vendors should be urged to correct their code.
+
+3.2 Site-local prefixes
+
+ Site local prefixes (in the FEC0::/10 range) MAY be advertized by
+ IGPs or EGPs within a site. The precise definition of a site is
+ ongoing work discussed in the IPng working group.
+
+ Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs.
+
+3.3 Loopback and unspecified prefixes
+
+ The loopback prefix (::1/128) and the unspecified prefix (::0/128)
+ MUST NOT be advertised by any routing protocol.
+
+3.4 Multicast prefixes
+
+ Multicast prefixes MUST NOT be advertised by any unicast routing
+ protocol. Multicast routing protocols are designed to respect the
+ semantics of multicast and MUST therefore be used to route packets
+ with multicast destination addresses (in the range FF00::/8).
+
+ Multicast address scopes MUST be respected on the 6Bone. Only global
+ scope multicast addresses MAY be routed across transit pNLAs and
+ pTLAs. There is no requirement on a pTLA to route multicast packets.
+
+ Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges)
+ MAY be routed across a pNLA to its leaf sites.
+
+ Site-local multicasts MUST NOT be routed toward transit pNLAs or
+ pTLAs.
+
+ Obviously, link-local multicasts and node-local multicasts MUST NOT
+ be routed at all.
+
+3.5 IPv4-compatible prefixes
+
+ Sites may choose to use IPv4 compatible addresses (::a.b.c.d)
+ internally. As there is no real rationale today for doing that,
+ these addresses SHOULD
+
+ NOT be used in the 6Bone.
+
+
+
+
+Durand & Buclin Informational [Page 3]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+ The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
+
+ IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit
+ pNLAs or pTLAs.
+
+3.6 IPv4-mapped prefixes
+
+ IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is an IPv4
+ address) MAY be advertised by IGPs within a site. It may be useful
+ for some IPv6 only nodes within a site to have such a route pointing
+ to a translation device.
+
+ IPv4-mapped prefixes MUST NOT be advertised by EGPs.
+
+3.7 Default routes
+
+ 6Bone core pTLA routers MUST be default-free.
+
+ pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY
+ do the same for their leaf sites.
+
+3.8 Yet undefined unicast prefixes
+
+ Yet undefined unicast prefixes from a format prefix other than
+ 2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone.
+ In particular, RFC 2471 test addresses MUST NOT be advertised on the
+ 6Bone.
+
+ Routing of global unicast prefixes outside of the 6Bone range
+ (3FFE::/16) is discussed in section 4, Routing policies, below.
+
+3.9 Inter-site links
+
+ Global IPv6 addresses MUST be used for the end points of the inter-
+ site links. In particular, IPv4 compatible addresses MUST NOT be used
+ for tunnels.
+
+ Prefixes for those links MUST NOT be injected in the global routing
+ tables.
+
+3.10 Aggregation & advertisement issues
+
+ Route aggregation MUST be performed by any border router.
+
+ Sites or pNLAs MUST only advertise to their upstream provider the
+ prefixes assigned by that ISP unless otherwise agreed.
+
+
+
+
+
+Durand & Buclin Informational [Page 4]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+ Site border router MUST NOT advertise prefixes more specific than the
+ /48 ones allocated by their ISP.
+
+ pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless
+ special peering agreements are implemented. When such special peering
+ agreements are in place between any two or more pTLAs, care MUST be
+ taken not to leak the more specific prefixes to other pTLAs not
+ participating in the peering agreement.
+
+4. Routing policies
+
+ 6Bone backbone sites maintain the mesh into the backbone and provide
+ an as reliable as possible service, granted the 6Bone is an
+ experimentation tool. To achieve their mission, 6Bone backbone sites
+ MUST maintain peerings with at least 3 (three) other back bone sites.
+
+ The peering agreements across the 6Bone are by nature non-commercial,
+ and therefore SHOULD allow transit traffic through.
+
+ Eventually, the Internet registries will assign other TLAs than the
+ 6Bone one (currently 3FFE::/16). The organizations bearing those TLAs
+ will establish a new IPv6 network, parallel to the 6Bone. The 6Bone
+ MIGHT interconnect with this new IPv6 Internet, b ut transit across
+ the 6Bone will not be guaranteed. It will be left to each 6Bone
+ backbone site to decide whether it will carry traffic to or from the
+ IPv6 Internet.
+
+5. The 6Bone registry
+
+ The 6Bone registry is a RIPE-181 database with IPv6 extensions used
+ to store information about the 6Bone. Each 6Bone site MUST maintain
+ the relevant entries in the 6Bone registry (whois.6bone.net). In
+ particular, the following objects MUST be present:
+
+ - IPv6-site: site description
+
+ - Inet6num: prefix delegation
+
+ - Mntner: coordinate of site maintenance staff
+
+ Other objects MAY be maintained at the discretion of the sites, such
+ as routing policy descriptors, person or role objects. The Mntner
+ object MUST make reference to a role or person object, but those must
+ not necessarily reside in the 6Bone registry, they can be stored
+ within any of the Internet registry databases (RIPE, InterNIC, APNIC,
+
+
+
+
+
+
+Durand & Buclin Informational [Page 5]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+6. Guidelines for new sites joining the 6Bone
+
+ New sites joining the 6Bone should seek to connect to a transit pNLA
+ or a pTLA within their region, and preferably as close as possible to
+ their existing IPv4 physical and routing path for Internet service.
+ The 6Bone registry is available to find out candidate ISPs.
+
+ Any site connected to the 6Bone MUST maintain a DNS server for
+ forward name looking and reverse address translation. The joining
+ site MUST maintain the 6Bone registry objects relative to its site,
+ and in particular the IPv6- site and the MNTNER objects.
+
+ The upstream ISP MUST delegate the reverse address translation zone
+ in DNS to the joining site. The ISP MUST also create 6Bone registry
+ objects reflecting the delegated address space (inet6num:).
+
+ Up to date information about how to join the 6Bone is available on
+ the 6Bone Web site at http://www.6bone.net.
+
+7. Guidelines for 6Bone pTLA sites
+
+ 6Bone pTLA sites are altogether forming the backbone of the 6Bone. In
+ order to ensure the highest level possible of availability and
+ stability for the 6Bone environment, a few constraints are placed
+ onto sites wishing to become or stay a 6Bone pTLA:
+
+ 1. The site MUST have experience with IPv6 on the 6Bone, at least as
+ a leaf site and preferably as a transit pNLA under an existing
+ pTLA.
+
+ 2. The site MUST have the ability and intent to provide "production-
+ like" 6Bone backbone service to provide a robust and operationally
+ reliable 6Bone backbone.
+
+ 3. The site MUST have a potential "user community" that would be
+ served by becoming a pTLA, e.g., the requester is a major player
+ in a region, country or focus of interest.
+
+ 4. Must commit to abide by the 6Bone backbone operational rules and
+ policies as defined in the present document.
+
+ When a candidate site seeks to become a pTLA site, it will apply for
+ it to the 6Bone Operations group (see below) by bringing evidences it
+ meets the above criteria.
+
+
+
+
+
+
+
+Durand & Buclin Informational [Page 6]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+8. 6Bone Operations group
+
+ The 6Bone Operations group is the body in charge of monitoring the
+ adherence to the present rules, and will take the appropriate actions
+ to correct deviations. Membership in the 6Bone Operations group is
+ mandatory for, and restricted to, any site connected to the 6Bone.
+
+ The 6Bone Operations group is currently defined by those members of
+ the existing 6Bone mailing list, i.e., 6bone@isi.edu, who represent
+ sites participating on the 6Bone. Therefore it is incumbent on
+ relevant site contacts to join the mailing list. Instructions on how
+ to join the list are maintained on the 6Bone web site at
+ http://www.6bone.net.
+
+9. Common rules enforcement
+
+ Participation in the 6Bone is a voluntary and benevolent undertaking.
+ However, participating sites are expected to adhere to the rules
+ described in this document, in order to maintain the 6Bone as quality
+ tool for experimenting with the IPv6 protocols and products
+ implementing them.
+
+ The following processes are proposed to help enforcing the 6Bone
+ rules:
+
+ - Each pTLA site has committed when requesting their pTLA to
+ implement the rules, and to ensure they are respected by sites
+ within their administrative control (i.e. those to who prefixes
+ have been delegated).
+
+ - When a site detects an issue, it will first use the 6Bone registry
+ to contact the site maintainer and work the issue.
+
+ - If nothing happens, or there is disagreement on what the right
+ solution is, the issue can be brought to the 6Bone Operations
+ group.
+
+ - When the problem is related to a product issue, the site(s)
+ involved is responsible for contact the product vendor and work
+ toward its resolution.
+
+ - When an issue causes major operational problems, backbone sites may
+ decide to temporarily set filters in order to restore service.
+
+
+
+
+
+
+
+
+Durand & Buclin Informational [Page 7]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+10. Security Considerations
+
+ The result of bogus entries in routing tables is usually
+ unreachable sites. Having guidelines to aggregate or reject routes
+ will clean up the routing tables. It is expected that using these
+ guidelines, routing on the 6Bone will be less sensitive to denial
+ of service attacks due to misleading routes.
+
+ The 6Bone is a test network. Therefore, denial of service, packet
+ disclosure, are to be expected.
+
+11. Acknowledgements
+
+ This document is the result of shared experience on the 6Bone.
+ Special thanks go to Bob Fink for the hard work make to date to
+ direct the 6Bone effort, to David Kessens for the 6Bone registry,
+ and to Guy Davies for his insightful contributions.
+
+12. References
+
+ [1] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6
+ Testing Address Allocation", RFC 2471, December 1998.
+
+ [RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
+ January 1997.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
+ "Multiprotocol Extensions for BGP-4", RFC 2283, March
+ 1998.
+
+ [RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J.,
+ Karrenberg, D., Terpstra, M. and J. Yu, Representation
+ of IP Routing Policies in a Routing Registry. Technical
+ Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands,
+ October 1994.
+
+
+
+
+
+
+
+
+
+
+Durand & Buclin Informational [Page 8]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+13. Authors' Addresses
+
+ Alain Durand
+ Institut d'Informatique et de Mathematiques Appliquees de Grenoble
+ IMAG BP 53
+ 38041 Grenoble CEDEX 9 France
+
+ Phone : +33 4 76 63 57 03
+ Fax : +33 4 76 51 49 64
+ EMail: Alain.Durand@imag.fr
+
+
+ Bertrand Buclin
+ AT&T International S.A.
+ Route de l'aeroport 31, CP 72
+ CH-1215 Geneve 15 (Switzerland)
+
+ Phone : +41 22 929 37 40
+ Fax : +41 22 929 39 84
+ EMail: Bertrand.Buclin@ch.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand & Buclin Informational [Page 9]
+
+RFC 2546 6Bone Routing Practice March 1999
+
+
+14. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand & Buclin Informational [Page 10]
+
diff --git a/Documentation/en/rfc/rfc2553.txt b/Documentation/en/rfc/rfc2553.txt
new file mode 100644
index 00000000..6989bf30
--- /dev/null
+++ b/Documentation/en/rfc/rfc2553.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group R. Gilligan
+Request for Comments: 2553 FreeGate
+Obsoletes: 2133 S. Thomson
+Category: Informational Bellcore
+ J. Bound
+ Compaq
+ W. Stevens
+ Consultant
+ March 1999
+
+
+ Basic Socket Interface Extensions for IPv6
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ The de facto standard application program interface (API) for TCP/IP
+ applications is the "sockets" interface. Although this API was
+ developed for Unix in the early 1980s it has also been implemented on
+ a wide variety of non-Unix systems. TCP/IP applications written
+ using the sockets API have in the past enjoyed a high degree of
+ portability and we would like the same portability with IPv6
+ applications. But changes are required to the sockets API to support
+ IPv6 and this memo describes these changes. These include a new
+ socket address structure to carry IPv6 addresses, new address
+ conversion functions, and some new socket options. These extensions
+ are designed to provide access to the basic IPv6 features required by
+ TCP and UDP applications, including multicasting, while introducing a
+ minimum of change into the system and providing complete
+ compatibility for existing IPv4 applications. Additional extensions
+ for advanced IPv6 features (raw sockets and access to the IPv6
+ extension headers) are defined in another document [4].
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 1]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+Table of Contents
+
+ 1. Introduction.................................................3
+ 2. Design Considerations........................................3
+ 2.1 What Needs to be Changed....................................4
+ 2.2 Data Types..................................................5
+ 2.3 Headers.....................................................5
+ 2.4 Structures..................................................5
+ 3. Socket Interface.............................................6
+ 3.1 IPv6 Address Family and Protocol Family.....................6
+ 3.2 IPv6 Address Structure......................................6
+ 3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
+ 3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
+ 3.5 The Socket Functions........................................9
+ 3.6 Compatibility with IPv4 Applications.......................10
+ 3.7 Compatibility with IPv4 Nodes..............................10
+ 3.8 IPv6 Wildcard Address......................................11
+ 3.9 IPv6 Loopback Address......................................12
+ 3.10 Portability Additions.....................................13
+ 4. Interface Identification....................................16
+ 4.1 Name-to-Index..............................................16
+ 4.2 Index-to-Name..............................................17
+ 4.3 Return All Interface Names and Indexes.....................17
+ 4.4 Free Memory................................................18
+ 5. Socket Options..............................................18
+ 5.1 Unicast Hop Limit..........................................18
+ 5.2 Sending and Receiving Multicast Packets....................19
+ 6. Library Functions...........................................21
+ 6.1 Nodename-to-Address Translation............................21
+ 6.2 Address-To-Nodename Translation............................24
+ 6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
+ 6.4 Protocol-Independent Nodename and Service Name Translation.26
+ 6.5 Socket Address Structure to Nodename and Service Name......29
+ 6.6 Address Conversion Functions...............................31
+ 6.7 Address Testing Macros.....................................32
+ 7. Summary of New Definitions..................................33
+ 8. Security Considerations.....................................35
+ 9. Year 2000 Considerations....................................35
+ Changes From RFC 2133..........................................35
+ Acknowledgments................................................38
+ References.....................................................39
+ Authors' Addresses.............................................40
+ Full Copyright Statement.......................................41
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 2]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+1. Introduction
+
+ While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
+ by 128-bit addresses. The socket interface makes the size of an IP
+ address quite visible to an application; virtually all TCP/IP
+ applications for BSD-based systems have knowledge of the size of an
+ IP address. Those parts of the API that expose the addresses must be
+ changed to accommodate the larger IPv6 address size. IPv6 also
+ introduces new features (e.g., traffic class and flowlabel), some of
+ which must be made visible to applications via the API. This memo
+ defines a set of extensions to the socket interface to support the
+ larger address size and new features of IPv6.
+
+2. Design Considerations
+
+ There are a number of important considerations in designing changes
+ to this well-worn API:
+
+ - The API changes should provide both source and binary
+ compatibility for programs written to the original API. That
+ is, existing program binaries should continue to operate when
+ run on a system supporting the new API. In addition, existing
+ applications that are re-compiled and run on a system supporting
+ the new API should continue to operate. Simply put, the API
+ changes for IPv6 should not break existing programs. An
+ additonal mechanism for implementations to verify this is to
+ verify the new symbols are protected by Feature Test Macros as
+ described in IEEE Std 1003.1. (Such Feature Test Macros are not
+ defined by this RFC.)
+
+ - The changes to the API should be as small as possible in order
+ to simplify the task of converting existing IPv4 applications to
+ IPv6.
+
+ - Where possible, applications should be able to use this API to
+ interoperate with both IPv6 and IPv4 hosts. Applications should
+ not need to know which type of host they are communicating with.
+
+ - IPv6 addresses carried in data structures should be 64-bit
+ aligned. This is necessary in order to obtain optimum
+ performance on 64-bit machine architectures.
+
+ Because of the importance of providing IPv4 compatibility in the API,
+ these extensions are explicitly designed to operate on machines that
+ provide complete support for both IPv4 and IPv6. A subset of this
+ API could probably be designed for operation on systems that support
+ only IPv6. However, this is not addressed in this memo.
+
+
+
+
+Gilligan, et. al. Informational [Page 3]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+2.1 What Needs to be Changed
+
+ The socket interface API consists of a few distinct components:
+
+ - Core socket functions.
+
+ - Address data structures.
+
+ - Name-to-address translation functions.
+
+ - Address conversion functions.
+
+ The core socket functions -- those functions that deal with such
+ things as setting up and tearing down TCP connections, and sending
+ and receiving UDP packets -- were designed to be transport
+ independent. Where protocol addresses are passed as function
+ arguments, they are carried via opaque pointers. A protocol-specific
+ address data structure is defined for each protocol that the socket
+ functions support. Applications must cast pointers to these
+ protocol-specific address structures into pointers to the generic
+ "sockaddr" address structure when using the socket functions. These
+ functions need not change for IPv6, but a new IPv6-specific address
+ data structure is needed.
+
+ The "sockaddr_in" structure is the protocol-specific data structure
+ for IPv4. This data structure actually includes 8-octets of unused
+ space, and it is tempting to try to use this space to adapt the
+ sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in
+ structure is not large enough to hold the 16-octet IPv6 address as
+ well as the other information (address family and port number) that
+ is needed. So a new address data structure must be defined for IPv6.
+
+ IPv6 addresses are scoped [2] so they could be link-local, site,
+ organization, global, or other scopes at this time undefined. To
+ support applications that want to be able to identify a set of
+ interfaces for a specific scope, the IPv6 sockaddr_in structure must
+ support a field that can be used by an implementation to identify a
+ set of interfaces identifying the scope for an IPv6 address.
+
+ The name-to-address translation functions in the socket interface are
+ gethostbyname() and gethostbyaddr(). These are left as is and new
+ functions are defined to support IPv4 and IPv6. Additionally, the
+ POSIX 1003.g draft [3] specifies a new nodename-to-address
+ translation function which is protocol independent. This function
+ can also be used with IPv4 and IPv6.
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 4]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ The address conversion functions -- inet_ntoa() and inet_addr() --
+ convert IPv4 addresses between binary and printable form. These
+ functions are quite specific to 32-bit IPv4 addresses. We have
+ designed two analogous functions that convert both IPv4 and IPv6
+ addresses, and carry an address type parameter so that they can be
+ extended to other protocol families as well.
+
+ Finally, a few miscellaneous features are needed to support IPv6.
+ New interfaces are needed to support the IPv6 traffic class, flow
+ label, and hop limit header fields. New socket options are needed to
+ control the sending and receiving of IPv6 multicast packets.
+
+ The socket interface will be enhanced in the future to provide access
+ to other IPv6 features. These extensions are described in [4].
+
+2.2 Data Types
+
+ The data types of the structure elements given in this memo are
+ intended to be examples, not absolute requirements. Whenever
+ possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are
+ used: uintN_t means an unsigned integer of exactly N bits (e.g.,
+ uint16_t). We also assume the argument data types from 1003.1g when
+ possible (e.g., the final argument to setsockopt() is a size_t
+ value). Whenever buffer sizes are specified, the POSIX 1003.1 size_t
+ data type is used (e.g., the two length arguments to getnameinfo()).
+
+2.3 Headers
+
+ When function prototypes and structures are shown we show the headers
+ that must be #included to cause that item to be defined.
+
+2.4 Structures
+
+ When structures are described the members shown are the ones that
+ must appear in an implementation. Additional, nonstandard members
+ may also be defined by an implementation. As an additional
+ precaution nonstandard members could be verified by Feature Test
+ Macros as described in IEEE Std 1003.1. (Such Feature Test Macros
+ are not defined by this RFC.)
+
+ The ordering shown for the members of a structure is the recommended
+ ordering, given alignment considerations of multibyte members, but an
+ implementation may order the members differently.
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 5]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+3. Socket Interface
+
+ This section specifies the socket interface changes for IPv6.
+
+3.1 IPv6 Address Family and Protocol Family
+
+ A new address family name, AF_INET6, is defined in <sys/socket.h>.
+ The AF_INET6 definition distinguishes between the original
+ sockaddr_in address data structure, and the new sockaddr_in6 data
+ structure.
+
+ A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
+ Like most of the other protocol family names, this will usually be
+ defined to have the same value as the corresponding address family
+ name:
+
+ #define PF_INET6 AF_INET6
+
+ The PF_INET6 is used in the first argument to the socket() function
+ to indicate that an IPv6 socket is being created.
+
+3.2 IPv6 Address Structure
+
+ A new in6_addr structure holds a single IPv6 address and is defined
+ as a result of including <netinet/in.h>:
+
+ struct in6_addr {
+ uint8_t s6_addr[16]; /* IPv6 address */
+ };
+
+ This data structure contains an array of sixteen 8-bit elements,
+ which make up one 128-bit IPv6 address. The IPv6 address is stored
+ in network byte order.
+
+ The structure in6_addr above is usually implemented with an embedded
+ union with extra fields that force the desired alignment level in a
+ manner similar to BSD implementations of "struct in_addr". Those
+ additional implementation details are omitted here for simplicity.
+
+ An example is as follows:
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 6]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ struct in6_addr {
+ union {
+ uint8_t _S6_u8[16];
+ uint32_t _S6_u32[4];
+ uint64_t _S6_u64[2];
+ } _S6_un;
+ };
+ #define s6_addr _S6_un._S6_u8
+
+3.3 Socket Address Structure for 4.3BSD-Based Systems
+
+ In the socket interface, a different protocol-specific data structure
+ is defined to carry the addresses for each protocol suite. Each
+ protocol- specific data structure is designed so it can be cast into a
+ protocol- independent data structure -- the "sockaddr" structure.
+ Each has a "family" field that overlays the "sa_family" of the
+ sockaddr data structure. This field identifies the type of the data
+ structure.
+
+ The sockaddr_in structure is the protocol-specific address data
+ structure for IPv4. It is used to pass addresses between applications
+ and the system in the socket functions. The following sockaddr_in6
+ structure holds IPv6 addresses and is defined as a result of including
+ the <netinet/in.h> header:
+
+struct sockaddr_in6 {
+ sa_family_t sin6_family; /* AF_INET6 */
+ in_port_t sin6_port; /* transport layer port # */
+ uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */
+ struct in6_addr sin6_addr; /* IPv6 address */
+ uint32_t sin6_scope_id; /* set of interfaces for a scope */
+};
+
+ This structure is designed to be compatible with the sockaddr data
+ structure used in the 4.3BSD release.
+
+ The sin6_family field identifies this as a sockaddr_in6 structure.
+ This field overlays the sa_family field when the buffer is cast to a
+ sockaddr data structure. The value of this field must be AF_INET6.
+
+ The sin6_port field contains the 16-bit UDP or TCP port number. This
+ field is used in the same way as the sin_port field of the
+ sockaddr_in structure. The port number is stored in network byte
+ order.
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 7]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ The sin6_flowinfo field is a 32-bit field that contains two pieces of
+ information: the traffic class and the flow label. The contents and
+ interpretation of this member is specified in [1]. The sin6_flowinfo
+ field SHOULD be set to zero by an implementation prior to using the
+ sockaddr_in6 structure by an application on receive operations.
+
+ The sin6_addr field is a single in6_addr structure (defined in the
+ previous section). This field holds one 128-bit IPv6 address. The
+ address is stored in network byte order.
+
+ The ordering of elements in this structure is specifically designed
+ so that when sin6_addr field is aligned on a 64-bit boundary, the
+ start of the structure will also be aligned on a 64-bit boundary.
+ This is done for optimum performance on 64-bit architectures.
+
+ The sin6_scope_id field is a 32-bit integer that identifies a set of
+ interfaces as appropriate for the scope of the address carried in the
+ sin6_addr field. For a link scope sin6_addr sin6_scope_id would be
+ an interface index. For a site scope sin6_addr, sin6_scope_id would
+ be a site identifier. The mapping of sin6_scope_id to an interface
+ or set of interfaces is left to implementation and future
+ specifications on the subject of site identifiers.
+
+ Notice that the sockaddr_in6 structure will normally be larger than
+ the generic sockaddr structure. On many existing implementations the
+ sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
+ being 16 bytes. Any existing code that makes this assumption needs
+ to be examined carefully when converting to IPv6.
+
+3.4 Socket Address Structure for 4.4BSD-Based Systems
+
+ The 4.4BSD release includes a small, but incompatible change to the
+ socket interface. The "sa_family" field of the sockaddr data
+ structure was changed from a 16-bit value to an 8-bit value, and the
+ space saved used to hold a length field, named "sa_len". The
+ sockaddr_in6 data structure given in the previous section cannot be
+ correctly cast into the newer sockaddr data structure. For this
+ reason, the following alternative IPv6 address data structure is
+ provided to be used on systems based on 4.4BSD. It is defined as a
+ result of including the <netinet/in.h> header.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 8]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+struct sockaddr_in6 {
+ uint8_t sin6_len; /* length of this struct */
+ sa_family_t sin6_family; /* AF_INET6 */
+ in_port_t sin6_port; /* transport layer port # */
+ uint32_t sin6_flowinfo; /* IPv6 flow information */
+ struct in6_addr sin6_addr; /* IPv6 address */
+ uint32_t sin6_scope_id; /* set of interfaces for a scope */
+};
+
+ The only differences between this data structure and the 4.3BSD
+ variant are the inclusion of the length field, and the change of the
+ family field to a 8-bit data type. The definitions of all the other
+ fields are identical to the structure defined in the previous
+ section.
+
+ Systems that provide this version of the sockaddr_in6 data structure
+ must also declare SIN6_LEN as a result of including the
+ <netinet/in.h> header. This macro allows applications to determine
+ whether they are being built on a system that supports the 4.3BSD or
+ 4.4BSD variants of the data structure.
+
+3.5 The Socket Functions
+
+ Applications call the socket() function to create a socket descriptor
+ that represents a communication endpoint. The arguments to the
+ socket() function tell the system which protocol to use, and what
+ format address structure will be used in subsequent functions. For
+ example, to create an IPv4/TCP socket, applications make the call:
+
+ s = socket(PF_INET, SOCK_STREAM, 0);
+
+ To create an IPv4/UDP socket, applications make the call:
+
+ s = socket(PF_INET, SOCK_DGRAM, 0);
+
+ Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
+ the constant PF_INET6 instead of PF_INET in the first argument. For
+ example, to create an IPv6/TCP socket, applications make the call:
+
+ s = socket(PF_INET6, SOCK_STREAM, 0);
+
+ To create an IPv6/UDP socket, applications make the call:
+
+ s = socket(PF_INET6, SOCK_DGRAM, 0);
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 9]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ Once the application has created a PF_INET6 socket, it must use the
+ sockaddr_in6 address structure when passing addresses in to the
+ system. The functions that the application uses to pass addresses
+ into the system are:
+
+ bind()
+ connect()
+ sendmsg()
+ sendto()
+
+ The system will use the sockaddr_in6 address structure to return
+ addresses to applications that are using PF_INET6 sockets. The
+ functions that return an address from the system to an application
+ are:
+
+ accept()
+ recvfrom()
+ recvmsg()
+ getpeername()
+ getsockname()
+
+ No changes to the syntax of the socket functions are needed to
+ support IPv6, since all of the "address carrying" functions use an
+ opaque address pointer, and carry an address length as a function
+ argument.
+
+3.6 Compatibility with IPv4 Applications
+
+ In order to support the large base of applications using the original
+ API, system implementations must provide complete source and binary
+ compatibility with the original API. This means that systems must
+ continue to support PF_INET sockets and the sockaddr_in address
+ structure. Applications must be able to create IPv4/TCP and IPv4/UDP
+ sockets using the PF_INET constant in the socket() function, as
+ described in the previous section. Applications should be able to
+ hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
+ sockets simultaneously within the same process.
+
+ Applications using the original API should continue to operate as
+ they did on systems supporting only IPv4. That is, they should
+ continue to interoperate with IPv4 nodes.
+
+3.7 Compatibility with IPv4 Nodes
+
+ The API also provides a different type of compatibility: the ability
+ for IPv6 applications to interoperate with IPv4 applications. This
+ feature uses the IPv4-mapped IPv6 address format defined in the IPv6
+ addressing architecture specification [2]. This address format
+
+
+
+Gilligan, et. al. Informational [Page 10]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ allows the IPv4 address of an IPv4 node to be represented as an IPv6
+ address. The IPv4 address is encoded into the low-order 32 bits of
+ the IPv6 address, and the high-order 96 bits hold the fixed prefix
+ 0:0:0:0:0:FFFF. IPv4- mapped addresses are written as follows:
+
+ ::FFFF:<IPv4-address>
+
+ These addresses can be generated automatically by the
+ getipnodebyname() function when the specified host has only IPv4
+ addresses (as described in Section 6.1).
+
+ Applications may use PF_INET6 sockets to open TCP connections to IPv4
+ nodes, or send UDP packets to IPv4 nodes, by simply encoding the
+ destination's IPv4 address as an IPv4-mapped IPv6 address, and
+ passing that address, within a sockaddr_in6 structure, in the
+ connect() or sendto() call. When applications use PF_INET6 sockets
+ to accept TCP connections from IPv4 nodes, or receive UDP packets
+ from IPv4 nodes, the system returns the peer's address to the
+ application in the accept(), recvfrom(), or getpeername() call using
+ a sockaddr_in6 structure encoded this way.
+
+ Few applications will likely need to know which type of node they are
+ interoperating with. However, for those applications that do need to
+ know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
+ provided.
+
+3.8 IPv6 Wildcard Address
+
+ While the bind() function allows applications to select the source IP
+ address of UDP packets and TCP connections, applications often want
+ the system to select the source address for them. With IPv4, one
+ specifies the address as the symbolic constant INADDR_ANY (called the
+ "wildcard" address) in the bind() call, or simply omits the bind()
+ entirely.
+
+ Since the IPv6 address type is a structure (struct in6_addr), a
+ symbolic constant can be used to initialize an IPv6 address variable,
+ but cannot be used in an assignment. Therefore systems provide the
+ IPv6 wildcard address in two forms.
+
+ The first version is a global variable named "in6addr_any" that is an
+ in6_addr structure. The extern declaration for this variable is
+ defined in <netinet/in.h>:
+
+ extern const struct in6_addr in6addr_any;
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 11]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ Applications use in6addr_any similarly to the way they use INADDR_ANY
+ in IPv4. For example, to bind a socket to port number 23, but let
+ the system select the source address, an application could use the
+ following code:
+
+ struct sockaddr_in6 sin6;
+ . . .
+ sin6.sin6_family = AF_INET6;
+ sin6.sin6_flowinfo = 0;
+ sin6.sin6_port = htons(23);
+ sin6.sin6_addr = in6addr_any; /* structure assignment */
+ . . .
+ if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+ . . .
+
+ The other version is a symbolic constant named IN6ADDR_ANY_INIT and
+ is defined in <netinet/in.h>. This constant can be used to
+ initialize an in6_addr structure:
+
+ struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
+
+ Note that this constant can be used ONLY at declaration time. It can
+ not be used to assign a previously declared in6_addr structure. For
+ example, the following code will not work:
+
+ /* This is the WRONG way to assign an unspecified address */
+ struct sockaddr_in6 sin6;
+ . . .
+ sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
+
+ Be aware that the IPv4 INADDR_xxx constants are all defined in host
+ byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
+ in6addr_xxx externals are defined in network byte order.
+
+3.9 IPv6 Loopback Address
+
+ Applications may need to send UDP packets to, or originate TCP
+ connections to, services residing on the local node. In IPv4, they
+ can do this by using the constant IPv4 address INADDR_LOOPBACK in
+ their connect(), sendto(), or sendmsg() call.
+
+ IPv6 also provides a loopback address to contact local TCP and UDP
+ services. Like the unspecified address, the IPv6 loopback address is
+ provided in two forms -- a global variable and a symbolic constant.
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 12]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ The global variable is an in6_addr structure named
+ "in6addr_loopback." The extern declaration for this variable is
+ defined in <netinet/in.h>:
+
+ extern const struct in6_addr in6addr_loopback;
+
+ Applications use in6addr_loopback as they would use INADDR_LOOPBACK
+ in IPv4 applications (but beware of the byte ordering difference
+ mentioned at the end of the previous section). For example, to open
+ a TCP connection to the local telnet server, an application could use
+ the following code:
+
+ struct sockaddr_in6 sin6;
+ . . .
+ sin6.sin6_family = AF_INET6;
+ sin6.sin6_flowinfo = 0;
+ sin6.sin6_port = htons(23);
+ sin6.sin6_addr = in6addr_loopback; /* structure assignment */
+ . . .
+ if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+ . . .
+
+ The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
+ in <netinet/in.h>. It can be used at declaration time ONLY; for
+ example:
+
+ struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
+
+ Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
+ to a previously declared IPv6 address variable.
+
+3.10 Portability Additions
+
+ One simple addition to the sockets API that can help application
+ writers is the "struct sockaddr_storage". This data structure can
+ simplify writing code portable across multiple address families and
+ platforms. This data structure is designed with the following goals.
+
+ - It has a large enough implementation specific maximum size to
+ store the desired set of protocol specific socket address data
+ structures. Specifically, it is at least large enough to
+ accommodate sockaddr_in and sockaddr_in6 and possibly other
+ protocol specific socket addresses too.
+ - It is aligned at an appropriate boundary so protocol specific
+ socket address data structure pointers can be cast to it and
+ access their fields without alignment problems. (e.g. pointers
+ to sockaddr_in6 and/or sockaddr_in can be cast to it and access
+ fields without alignment problems).
+
+
+
+Gilligan, et. al. Informational [Page 13]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ - It has the initial field(s) isomorphic to the fields of the
+ "struct sockaddr" data structure on that implementation which
+ can be used as a discriminants for deriving the protocol in use.
+ These initial field(s) would on most implementations either be a
+ single field of type "sa_family_t" (isomorphic to sa_family
+ field, 16 bits) or two fields of type uint8_t and sa_family_t
+ respectively, (isomorphic to sa_len and sa_family_t, 8 bits
+ each).
+
+ An example implementation design of such a data structure would be as
+ follows.
+
+/*
+ * Desired design of maximum size and alignment
+ */
+#define _SS_MAXSIZE 128 /* Implementation specific max size */
+#define _SS_ALIGNSIZE (sizeof (int64_t))
+ /* Implementation specific desired alignment */
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t))
+#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
+ _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+ sa_family_t __ss_family; /* address family */
+ /* Following fields are implementation specific */
+ char __ss_pad1[_SS_PAD1SIZE];
+ /* 6 byte pad, this is to make implementation
+ /* specific pad up to alignment field that */
+ /* follows explicit in the data structure */
+ int64_t __ss_align; /* field to force desired structure */
+ /* storage alignment */
+ char __ss_pad2[_SS_PAD2SIZE];
+ /* 112 byte pad to achieve desired size, */
+ /* _SS_MAXSIZE value minus size of ss_family */
+ /* __ss_pad1, __ss_align fields is 112 */
+};
+
+ On implementations where sockaddr data structure includes a "sa_len",
+ field this data structure would look like this:
+
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
+ (sizeof (uint8_t) + sizeof (sa_family_t))
+#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
+
+
+
+Gilligan, et. al. Informational [Page 14]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+ uint8_t __ss_len; /* address length */
+ sa_family_t __ss_family; /* address family */
+ /* Following fields are implementation specific */
+ char __ss_pad1[_SS_PAD1SIZE];
+ /* 6 byte pad, this is to make implementation
+ /* specific pad up to alignment field that */
+ /* follows explicit in the data structure */
+ int64_t __ss_align; /* field to force desired structure */
+ /* storage alignment */
+ char __ss_pad2[_SS_PAD2SIZE];
+ /* 112 byte pad to achieve desired size, */
+ /* _SS_MAXSIZE value minus size of ss_len, */
+ /* __ss_family, __ss_pad1, __ss_align fields is 112 */
+};
+
+ The above example implementation illustrates a data structure which
+ will align on a 64 bit boundary. An implementation specific field
+ "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment
+ which covers proper alignment good enough for needs of sockaddr_in6
+ (IPv6), sockaddr_in (IPv4) address data structures. The size of
+ padding fields __ss_pad1 depends on the chosen alignment boundary.
+ The size of padding field __ss_pad2 depends on the value of overall
+ size chosen for the total size of the structure. This size and
+ alignment are represented in the above example by implementation
+ specific (not required) constants _SS_MAXSIZE (chosen value 128) and
+ _SS_ALIGNMENT (with chosen value 8). Constants _SS_PAD1SIZE (derived
+ value 6) and _SS_PAD2SIZE (derived value 112) are also for
+ illustration and not required. The implementation specific
+ definitions and structure field names above start with an underscore
+ to denote implementation private namespace. Portable code is not
+ expected to access or reference those fields or constants.
+
+ The sockaddr_storage structure solves the problem of declaring
+ storage for automatic variables which is large enough and aligned
+ enough for storing socket address data structure of any family. For
+ example, code with a file descriptor and without the context of the
+ address family can pass a pointer to a variable of this type where a
+ pointer to a socket address structure is expected in calls such as
+ getpeername() and determine the address family by accessing the
+ received content after the call.
+
+ The sockaddr_storage structure may also be useful and applied to
+ certain other interfaces where a generic socket address large enough
+ and aligned for use with multiple address families may be needed. A
+ discussion of those interfaces is outside the scope of this document.
+
+
+
+
+Gilligan, et. al. Informational [Page 15]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ Also, much existing code assumes that any socket address structure
+ can fit in a generic sockaddr structure. While this has been true
+ for IPv4 socket address structures, it has always been false for Unix
+ domain socket address structures (but in practice this has not been a
+ problem) and it is also false for IPv6 socket address structures
+ (which can be a problem).
+
+ So now an application can do the following:
+
+ struct sockaddr_storage __ss;
+ struct sockaddr_in6 *sin6;
+ sin6 = (struct sockaddr_in6 *) &__ss;
+
+4. Interface Identification
+
+ This API uses an interface index (a small positive integer) to
+ identify the local interface on which a multicast group is joined
+ (Section 5.3). Additionally, the advanced API [4] uses these same
+ interface indexes to identify the interface on which a datagram is
+ received, or to specify the interface on which a datagram is to be
+ sent.
+
+ Interfaces are normally known by names such as "le0", "sl1", "ppp2",
+ and the like. On Berkeley-derived implementations, when an interface
+ is made known to the system, the kernel assigns a unique positive
+ integer value (called the interface index) to that interface. These
+ are small positive integers that start at 1. (Note that 0 is never
+ used for an interface index.) There may be gaps so that there is no
+ current interface for a particular positive interface index.
+
+ This API defines two functions that map between an interface name and
+ index, a third function that returns all the interface names and
+ indexes, and a fourth function to return the dynamic memory allocated
+ by the previous function. How these functions are implemented is
+ left up to the implementation. 4.4BSD implementations can implement
+ these functions using the existing sysctl() function with the
+ NET_RT_IFLIST command. Other implementations may wish to use ioctl()
+ for this purpose.
+
+4.1 Name-to-Index
+
+ The first function maps an interface name into its corresponding
+ index.
+
+ #include <net/if.h>
+
+ unsigned int if_nametoindex(const char *ifname);
+
+
+
+
+Gilligan, et. al. Informational [Page 16]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ If the specified interface name does not exist, the return value is
+ 0, and errno is set to ENXIO. If there was a system error (such as
+ running out of memory), the return value is 0 and errno is set to the
+ proper value (e.g., ENOMEM).
+
+4.2 Index-to-Name
+
+ The second function maps an interface index into its corresponding
+ name.
+
+ #include <net/if.h>
+
+ char *if_indextoname(unsigned int ifindex, char *ifname);
+
+ The ifname argument must point to a buffer of at least IF_NAMESIZE
+ bytes into which the interface name corresponding to the specified
+ index is returned. (IF_NAMESIZE is also defined in <net/if.h> and
+ its value includes a terminating null byte at the end of the
+ interface name.) This pointer is also the return value of the
+ function. If there is no interface corresponding to the specified
+ index, NULL is returned, and errno is set to ENXIO, if there was a
+ system error (such as running out of memory), if_indextoname returns
+ NULL and errno would be set to the proper value (e.g., ENOMEM).
+
+4.3 Return All Interface Names and Indexes
+
+ The if_nameindex structure holds the information about a single
+ interface and is defined as a result of including the <net/if.h>
+ header.
+
+ struct if_nameindex {
+ unsigned int if_index; /* 1, 2, ... */
+ char *if_name; /* null terminated name: "le0", ... */
+ };
+
+ The final function returns an array of if_nameindex structures, one
+ structure per interface.
+
+ struct if_nameindex *if_nameindex(void);
+
+ The end of the array of structures is indicated by a structure with
+ an if_index of 0 and an if_name of NULL. The function returns a NULL
+ pointer upon an error, and would set errno to the appropriate value.
+
+ The memory used for this array of structures along with the interface
+ names pointed to by the if_name members is obtained dynamically.
+ This memory is freed by the next function.
+
+
+
+
+Gilligan, et. al. Informational [Page 17]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+4.4 Free Memory
+
+ The following function frees the dynamic memory that was allocated by
+ if_nameindex().
+
+ #include <net/if.h>
+
+ void if_freenameindex(struct if_nameindex *ptr);
+
+ The argument to this function must be a pointer that was returned by
+ if_nameindex().
+
+ Currently net/if.h doesn't have prototype definitions for functions
+ and it is recommended that these definitions be defined in net/if.h
+ as well and the struct if_nameindex{}.
+
+5. Socket Options
+
+ A number of new socket options are defined for IPv6. All of these
+ new options are at the IPPROTO_IPV6 level. That is, the "level"
+ parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
+ when using these options. The constant name prefix IPV6_ is used in
+ all of the new socket options. This serves to clearly identify these
+ options as applying to IPv6.
+
+ The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
+ related constants defined in this section are obtained by including
+ the header <netinet/in.h>.
+
+5.1 Unicast Hop Limit
+
+ A new setsockopt() option controls the hop limit used in outgoing
+ unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS,
+ and it is used at the IPPROTO_IPV6 layer. The following example
+ illustrates how it is used:
+
+ int hoplimit = 10;
+
+ if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+ (char *) &hoplimit, sizeof(hoplimit)) == -1)
+ perror("setsockopt IPV6_UNICAST_HOPS");
+
+ When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
+ option value given is used as the hop limit for all subsequent
+ unicast packets sent via that socket. If the option is not set, the
+ system selects a default value. The integer hop limit value (called
+ x) is interpreted as follows:
+
+
+
+
+Gilligan, et. al. Informational [Page 18]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ x < -1: return an error of EINVAL
+ x == -1: use kernel default
+ 0 <= x <= 255: use x
+ x >= 256: return an error of EINVAL
+
+ The IPV6_UNICAST_HOPS option may be used with getsockopt() to
+ determine the hop limit value that the system will use for subsequent
+ unicast packets sent via that socket. For example:
+
+ int hoplimit;
+ size_t len = sizeof(hoplimit);
+
+ if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+ (char *) &hoplimit, &len) == -1)
+ perror("getsockopt IPV6_UNICAST_HOPS");
+ else
+ printf("Using %d for hop limit.\n", hoplimit);
+
+5.2 Sending and Receiving Multicast Packets
+
+ IPv6 applications may send UDP multicast packets by simply specifying
+ an IPv6 multicast address in the address argument of the sendto()
+ function.
+
+ Three socket options at the IPPROTO_IPV6 layer control some of the
+ parameters for sending multicast packets. Setting these options is
+ not required: applications may send multicast packets without using
+ these options. The setsockopt() options for controlling the sending
+ of multicast packets are summarized below. These three options can
+ also be used with getsockopt().
+
+ IPV6_MULTICAST_IF
+
+ Set the interface to use for outgoing multicast packets. The
+ argument is the index of the interface to use.
+
+ Argument type: unsigned int
+
+ IPV6_MULTICAST_HOPS
+
+ Set the hop limit to use for outgoing multicast packets. (Note
+ a separate option - IPV6_UNICAST_HOPS - is provided to set the
+ hop limit to use for outgoing unicast packets.)
+
+ The interpretation of the argument is the same as for the
+ IPV6_UNICAST_HOPS option:
+
+
+
+
+
+Gilligan, et. al. Informational [Page 19]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ x < -1: return an error of EINVAL
+ x == -1: use kernel default
+ 0 <= x <= 255: use x
+ x >= 256: return an error of EINVAL
+
+ If IPV6_MULTICAST_HOPS is not set, the default is 1
+ (same as IPv4 today)
+
+ Argument type: int
+
+ IPV6_MULTICAST_LOOP
+
+ If a multicast datagram is sent to a group to which the sending
+ host itself belongs (on the outgoing interface), a copy of the
+ datagram is looped back by the IP layer for local delivery if
+ this option is set to 1. If this option is set to 0 a copy
+ is not looped back. Other option values return an error of
+ EINVAL.
+
+ If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
+ same as IPv4 today).
+
+ Argument type: unsigned int
+
+ The reception of multicast packets is controlled by the two
+ setsockopt() options summarized below. An error of EOPNOTSUPP is
+ returned if these two options are used with getsockopt().
+
+ IPV6_JOIN_GROUP
+
+ Join a multicast group on a specified local interface. If the
+ interface index is specified as 0, the kernel chooses the local
+ interface. For example, some kernels look up the multicast
+ group in the normal IPv6 routing table and using the resulting
+ interface.
+
+ Argument type: struct ipv6_mreq
+
+ IPV6_LEAVE_GROUP
+
+ Leave a multicast group on a specified interface.
+
+ Argument type: struct ipv6_mreq
+
+ The argument type of both of these options is the ipv6_mreq structure,
+ defined as a result of including the <netinet/in.h> header;
+
+
+
+
+
+Gilligan, et. al. Informational [Page 20]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ struct ipv6_mreq {
+ struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
+ unsigned int ipv6mr_interface; /* interface index */
+ };
+
+ Note that to receive multicast datagrams a process must join the
+ multicast group and bind the UDP port to which datagrams will be
+ sent. Some processes also bind the multicast group address to the
+ socket, in addition to the port, to prevent other datagrams destined
+ to that same port from being delivered to the socket.
+
+6. Library Functions
+
+ New library functions are needed to perform a variety of operations
+ with IPv6 addresses. Functions are needed to lookup IPv6 addresses
+ in the Domain Name System (DNS). Both forward lookup (nodename-to-
+ address translation) and reverse lookup (address-to-nodename
+ translation) need to be supported. Functions are also needed to
+ convert IPv6 addresses between their binary and textual form.
+
+ We note that the two existing functions, gethostbyname() and
+ gethostbyaddr(), are left as-is. New functions are defined to handle
+ both IPv4 and IPv6 addresses.
+
+6.1 Nodename-to-Address Translation
+
+ The commonly used function gethostbyname() is inadequate for many
+ applications, first because it provides no way for the caller to
+ specify anything about the types of addresses desired (IPv4 only,
+ IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
+ implementations of this function are not thread safe. RFC 2133
+ defined a function named gethostbyname2() but this function was also
+ inadequate, first because its use required setting a global option
+ (RES_USE_INET6) when IPv6 addresses were required, and second because
+ a flag argument is needed to provide the caller with additional
+ control over the types of addresses required.
+
+ The following function is new and must be thread safe:
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ struct hostent *getipnodebyname(const char *name, int af, int flags
+ int *error_num);
+
+ The name argument can be either a node name or a numeric address
+ string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address).
+ The af argument specifies the address family, either AF_INET or
+
+
+
+Gilligan, et. al. Informational [Page 21]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ AF_INET6. The error_num value is returned to the caller, via a
+ pointer, with the appropriate error code in error_num, to support
+ thread safe error code returns. error_num will be set to one of the
+ following values:
+
+ HOST_NOT_FOUND
+
+ No such host is known.
+
+ NO_ADDRESS
+
+ The server recognised the request and the name but no address is
+ available. Another type of request to the name server for the
+ domain might return an answer.
+
+ NO_RECOVERY
+
+ An unexpected server failure occurred which cannot be recovered.
+
+ TRY_AGAIN
+
+ A temporary and possibly transient error occurred, such as a
+ failure of a server to respond.
+
+ The flags argument specifies the types of addresses that are searched
+ for, and the types of addresses that are returned. We note that a
+ special flags value of AI_DEFAULT (defined below) should handle most
+ applications.
+
+ That is, porting simple applications to use IPv6 replaces the call
+
+ hptr = gethostbyname(name);
+
+ with
+
+ hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
+
+ and changes any subsequent error diagnosis code to use error_num
+ instead of externally declared variables, such as h_errno.
+
+ Applications desiring finer control over the types of addresses
+ searched for and returned, can specify other combinations of the
+ flags argument.
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 22]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ A flags of 0 implies a strict interpretation of the af argument:
+
+ - If flags is 0 and af is AF_INET, then the caller wants only
+ IPv4 addresses. A query is made for A records. If successful,
+ the IPv4 addresses are returned and the h_length member of the
+ hostent structure will be 4, else the function returns a NULL
+ pointer.
+
+ - If flags is 0 and if af is AF_INET6, then the caller wants only
+ IPv6 addresses. A query is made for AAAA records. If
+ successful, the IPv6 addresses are returned and the h_length
+ member of the hostent structure will be 16, else the function
+ returns a NULL pointer.
+
+ Other constants can be logically-ORed into the flags argument, to
+ modify the behavior of the function.
+
+ - If the AI_V4MAPPED flag is specified along with an af of
+ AF_INET6, then the caller will accept IPv4-mapped IPv6
+ addresses. That is, if no AAAA records are found then a query
+ is made for A records and any found are returned as IPv4-mapped
+ IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is
+ ignored unless af equals AF_INET6.
+
+ - The AI_ALL flag is used in conjunction with the AI_V4MAPPED
+ flag, and is only used with the IPv6 address family. When AI_ALL
+ is logically or'd with AI_V4MAPPED flag then the caller wants
+ all addresses: IPv6 and IPv4-mapped IPv6. A query is first made
+ for AAAA records and if successful, the IPv6 addresses are
+ returned. Another query is then made for A records and any found
+ are returned as IPv4-mapped IPv6 addresses. h_length will be 16.
+ Only if both queries fail does the function return a NULL pointer.
+ This flag is ignored unless af equals AF_INET6.
+
+ - The AI_ADDRCONFIG flag specifies that a query for AAAA records
+ should occur only if the node has at least one IPv6 source
+ address configured and a query for A records should occur only
+ if the node has at least one IPv4 source address configured.
+
+ For example, if the node has no IPv6 source addresses
+ configured, and af equals AF_INET6, and the node name being
+ looked up has both AAAA and A records, then:
+
+ (a) if only AI_ADDRCONFIG is specified, the function
+ returns a NULL pointer;
+ (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
+ records are returned as IPv4-mapped IPv6 addresses;
+
+
+
+
+Gilligan, et. al. Informational [Page 23]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ The special flags value of AI_DEFAULT is defined as
+
+ #define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG)
+
+ We noted that the getipnodebyname() function must allow the name
+ argument to be either a node name or a literal address string (i.e.,
+ a dotted-decimal IPv4 address or an IPv6 hex address). This saves
+ applications from having to call inet_pton() to handle literal
+ address strings.
+
+ There are four scenarios based on the type of literal address string
+ and the value of the af argument.
+
+ The two simple cases are:
+
+ When name is a dotted-decimal IPv4 address and af equals AF_INET, or
+ when name is an IPv6 hex address and af equals AF_INET6. The members
+ of the returned hostent structure are: h_name points to a copy of the
+ name argument, h_aliases is a NULL pointer, h_addrtype is a copy of
+ the af argument, h_length is either 4 (for AF_INET) or 16 (for
+ AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte
+ binary address, and h_addr_list[1] is a NULL pointer.
+
+ When name is a dotted-decimal IPv4 address and af equals AF_INET6,
+ and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is
+ returned: h_name points to an IPv6 hex address containing the IPv4-
+ mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is
+ AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte
+ binary address, and h_addr_list[1] is a NULL pointer. If AI_V4MAPPED
+ is set (with or without AI_ALL) return IPv4-mapped otherwise return
+ NULL.
+
+ It is an error when name is an IPv6 hex address and af equals
+ AF_INET. The function's return value is a NULL pointer and error_num
+ equals HOST_NOT_FOUND.
+
+6.2 Address-To-Nodename Translation
+
+ The following function has the same arguments as the existing
+ gethostbyaddr() function, but adds an error number.
+
+ #include <sys/socket.h> #include <netdb.h>
+
+ struct hostent *getipnodebyaddr(const void *src, size_t len,
+ int af, int *error_num);
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 24]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ As with getipnodebyname(), getipnodebyaddr() must be thread safe.
+ The error_num value is returned to the caller with the appropriate
+ error code, to support thread safe error code returns. The following
+ error conditions may be returned for error_num:
+
+ HOST_NOT_FOUND
+
+ No such host is known.
+
+ NO_ADDRESS
+
+ The server recognized the request and the name but no address
+ is available. Another type of request to the name server for
+ the domain might return an answer.
+
+ NO_RECOVERY
+
+ An unexpected server failure occurred which cannot be
+ recovered.
+
+ TRY_AGAIN
+
+ A temporary and possibly transient error occurred, such as a
+ failure of a server to respond.
+
+ One possible source of confusion is the handling of IPv4-mapped IPv6
+ addresses and IPv4-compatible IPv6 addresses, but the following logic
+ should apply.
+
+ 1. If af is AF_INET6, and if len equals 16, and if the IPv6
+ address is an IPv4-mapped IPv6 address or an IPv4-compatible
+ IPv6 address, then skip over the first 12 bytes of the IPv6
+ address, set af to AF_INET, and set len to 4.
+
+ 2. If af is AF_INET, lookup the name for the given IPv4 address
+ (e.g., query for a PTR record in the in-addr.arpa domain).
+
+ 3. If af is AF_INET6, lookup the name for the given IPv6 address
+ (e.g., query for a PTR record in the ip6.int domain).
+
+ 4. If the function is returning success, then the single address
+ that is returned in the hostent structure is a copy of the
+ first argument to the function with the same address family
+ that was passed as an argument to this function.
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 25]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ All four steps listed are performed, in order. Also note that the
+ IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
+ compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
+ be returned and a query of the address not performed.
+
+ Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
+ false for "::" and "::1".
+
+6.3 Freeing memory for getipnodebyname and getipnodebyaddr
+
+ The hostent structure does not change from its existing definition.
+ This structure, and the information pointed to by this structure, are
+ dynamically allocated by getipnodebyname and getipnodebyaddr. The
+ following function frees this memory:
+
+ #include <netdb.h>
+
+ void freehostent(struct hostent *ptr);
+
+6.4 Protocol-Independent Nodename and Service Name Translation
+
+ Nodename-to-address translation is done in a protocol-independent
+ fashion using the getaddrinfo() function that is taken from the
+ Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
+ (Protocol Independent Interfaces) draft specification [3].
+
+ The official specification for this function will be the final POSIX
+ standard, with the following additional requirements:
+
+ - getaddrinfo() (along with the getnameinfo() function described
+ in the next section) must be thread safe.
+
+ - The AI_NUMERICHOST is new with this document.
+
+ - All fields in socket address structures returned by
+ getaddrinfo() that are not filled in through an explicit
+ argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
+ (This makes it easier to compare socket address structures.)
+
+ - getaddrinfo() must fill in the length field of a socket address
+ structure (e.g., sin6_len) on systems that support this field.
+
+ We are providing this independent description of the function because
+ POSIX standards are not freely available (as are IETF documents).
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+
+
+
+Gilligan, et. al. Informational [Page 26]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ int getaddrinfo(const char *nodename, const char *servname,
+ const struct addrinfo *hints,
+ struct addrinfo **res);
+
+ The addrinfo structure is defined as a result of including the
+ <netdb.h> header.
+
+ struct addrinfo {
+ int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
+ int ai_family; /* PF_xxx */
+ int ai_socktype; /* SOCK_xxx */
+ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
+ size_t ai_addrlen; /* length of ai_addr */
+ char *ai_canonname; /* canonical name for nodename */
+ struct sockaddr *ai_addr; /* binary address */
+ struct addrinfo *ai_next; /* next structure in linked list */
+ };
+
+ The return value from the function is 0 upon success or a nonzero
+ error code. The following names are the nonzero error codes from
+ getaddrinfo(), and are defined in <netdb.h>:
+
+ EAI_ADDRFAMILY address family for nodename not supported
+ EAI_AGAIN temporary failure in name resolution
+ EAI_BADFLAGS invalid value for ai_flags
+ EAI_FAIL non-recoverable failure in name resolution
+ EAI_FAMILY ai_family not supported
+ EAI_MEMORY memory allocation failure
+ EAI_NODATA no address associated with nodename
+ EAI_NONAME nodename nor servname provided, or not known
+ EAI_SERVICE servname not supported for ai_socktype
+ EAI_SOCKTYPE ai_socktype not supported
+ EAI_SYSTEM system error returned in errno
+
+ The nodename and servname arguments are pointers to null-terminated
+ strings or NULL. One or both of these two arguments must be a non-
+ NULL pointer. In the normal client scenario, both the nodename and
+ servname are specified. In the normal server scenario, only the
+ servname is specified. A non-NULL nodename string can be either a
+ node name or a numeric host address string (i.e., a dotted-decimal
+ IPv4 address or an IPv6 hex address). A non-NULL servname string can
+ be either a service name or a decimal port number.
+
+ The caller can optionally pass an addrinfo structure, pointed to by
+ the third argument, to provide hints concerning the type of socket
+ that the caller supports. In this hints structure all members other
+ than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
+ or a NULL pointer. A value of PF_UNSPEC for ai_family means the
+
+
+
+Gilligan, et. al. Informational [Page 27]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ caller will accept any protocol family. A value of 0 for ai_socktype
+ means the caller will accept any socket type. A value of 0 for
+ ai_protocol means the caller will accept any protocol. For example,
+ if the caller handles only TCP and not UDP, then the ai_socktype
+ member of the hints structure should be set to SOCK_STREAM when
+ getaddrinfo() is called. If the caller handles only IPv4 and not
+ IPv6, then the ai_family member of the hints structure should be set
+ to PF_INET when getaddrinfo() is called. If the third argument to
+ getaddrinfo() is a NULL pointer, this is the same as if the caller
+ had filled in an addrinfo structure initialized to zero with
+ ai_family set to PF_UNSPEC.
+
+ Upon successful return a pointer to a linked list of one or more
+ addrinfo structures is returned through the final argument. The
+ caller can process each addrinfo structure in this list by following
+ the ai_next pointer, until a NULL pointer is encountered. In each
+ returned addrinfo structure the three members ai_family, ai_socktype,
+ and ai_protocol are the corresponding arguments for a call to the
+ socket() function. In each addrinfo structure the ai_addr member
+ points to a filled-in socket address structure whose length is
+ specified by the ai_addrlen member.
+
+ If the AI_PASSIVE bit is set in the ai_flags member of the hints
+ structure, then the caller plans to use the returned socket address
+ structure in a call to bind(). In this case, if the nodename
+ argument is a NULL pointer, then the IP address portion of the socket
+ address structure will be set to INADDR_ANY for an IPv4 address or
+ IN6ADDR_ANY_INIT for an IPv6 address.
+
+ If the AI_PASSIVE bit is not set in the ai_flags member of the hints
+ structure, then the returned socket address structure will be ready
+ for a call to connect() (for a connection-oriented protocol) or
+ either connect(), sendto(), or sendmsg() (for a connectionless
+ protocol). In this case, if the nodename argument is a NULL pointer,
+ then the IP address portion of the socket address structure will be
+ set to the loopback address.
+
+ If the AI_CANONNAME bit is set in the ai_flags member of the hints
+ structure, then upon successful return the ai_canonname member of the
+ first addrinfo structure in the linked list will point to a null-
+ terminated string containing the canonical name of the specified
+ nodename.
+
+ If the AI_NUMERICHOST bit is set in the ai_flags member of the hints
+ structure, then a non-NULL nodename string must be a numeric host
+ address string. Otherwise an error of EAI_NONAME is returned. This
+ flag prevents any type of name resolution service (e.g., the DNS)
+ from being called.
+
+
+
+Gilligan, et. al. Informational [Page 28]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ All of the information returned by getaddrinfo() is dynamically
+ allocated: the addrinfo structures, and the socket address structures
+ and canonical node name strings pointed to by the addrinfo
+ structures. To return this information to the system the function
+ freeaddrinfo() is called:
+
+ #include <sys/socket.h> #include <netdb.h>
+
+ void freeaddrinfo(struct addrinfo *ai);
+
+ The addrinfo structure pointed to by the ai argument is freed, along
+ with any dynamic storage pointed to by the structure. This operation
+ is repeated until a NULL ai_next pointer is encountered.
+
+ To aid applications in printing error messages based on the EAI_xxx
+ codes returned by getaddrinfo(), the following function is defined.
+
+ #include <sys/socket.h> #include <netdb.h>
+
+ char *gai_strerror(int ecode);
+
+ The argument is one of the EAI_xxx values defined earlier and the
+ return value points to a string describing the error. If the
+ argument is not one of the EAI_xxx values, the function still returns
+ a pointer to a string whose contents indicate an unknown error.
+
+6.5 Socket Address Structure to Nodename and Service Name
+
+ The POSIX 1003.1g specification includes no function to perform the
+ reverse conversion from getaddrinfo(): to look up a nodename and
+ service name, given the binary address and port. Therefore, we
+ define the following function:
+
+ #include <sys/socket.h>
+ #include <netdb.h>
+
+ int getnameinfo(const struct sockaddr *sa, socklen_t salen,
+ char *host, size_t hostlen,
+ char *serv, size_t servlen,
+ int flags);
+
+ This function looks up an IP address and port number provided by the
+ caller in the DNS and system-specific database, and returns text
+ strings for both in buffers provided by the caller. The function
+ indicates successful completion by a zero return value; a non-zero
+ return value indicates failure.
+
+
+
+
+
+Gilligan, et. al. Informational [Page 29]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ The first argument, sa, points to either a sockaddr_in structure (for
+ IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
+ address and port number. The salen argument gives the length of the
+ sockaddr_in or sockaddr_in6 structure.
+
+ The function returns the nodename associated with the IP address in
+ the buffer pointed to by the host argument. The caller provides the
+ size of this buffer via the hostlen argument. The service name
+ associated with the port number is returned in the buffer pointed to
+ by serv, and the servlen argument gives the length of this buffer.
+ The caller specifies not to return either string by providing a zero
+ value for the hostlen or servlen arguments. Otherwise, the caller
+ must provide buffers large enough to hold the nodename and the
+ service name, including the terminating null characters.
+
+ Unfortunately most systems do not provide constants that specify the
+ maximum size of either a fully-qualified domain name or a service
+ name. Therefore to aid the application in allocating buffers for
+ these two returned strings the following constants are defined in
+ <netdb.h>:
+
+ #define NI_MAXHOST 1025
+ #define NI_MAXSERV 32
+
+ The first value is actually defined as the constant MAXDNAME in recent
+ versions of BIND's <arpa/nameser.h> header (older versions of BIND
+ define this constant to be 256) and the second is a guess based on the
+ services listed in the current Assigned Numbers RFC.
+
+ The final argument is a flag that changes the default actions of this
+ function. By default the fully-qualified domain name (FQDN) for the
+ host is looked up in the DNS and returned. If the flag bit NI_NOFQDN
+ is set, only the nodename portion of the FQDN is returned for local
+ hosts.
+
+ If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
+ located in the DNS, the numeric form of the host's address is returned
+ instead of its name (e.g., by calling inet_ntop() instead of
+ getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is
+ returned if the host's name cannot be located in the DNS.
+
+ If the flag bit NI_NUMERICSERV is set, the numeric form of the service
+ address is returned (e.g., its port number) instead of its name. The
+ two NI_NUMERICxxx flags are required to support the "-n" flag that
+ many commands provide.
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 30]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
+ service, and causes getservbyport() to be called with a second
+ argument of "udp" instead of its default of "tcp". This is required
+ for the few ports (e.g. 512-514) that have different services for UDP
+ and TCP.
+
+ These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
+ flags already defined for getaddrinfo().
+
+6.6 Address Conversion Functions
+
+ The two functions inet_addr() and inet_ntoa() convert an IPv4 address
+ between binary and text form. IPv6 applications need similar
+ functions. The following two functions convert both IPv6 and IPv4
+ addresses:
+
+ #include <sys/socket.h>
+ #include <arpa/inet.h>
+
+ int inet_pton(int af, const char *src, void *dst);
+
+ const char *inet_ntop(int af, const void *src,
+ char *dst, size_t size);
+
+ The inet_pton() function converts an address in its standard text
+ presentation form into its numeric binary form. The af argument
+ specifies the family of the address. Currently the AF_INET and
+ AF_INET6 address families are supported. The src argument points to
+ the string being passed in. The dst argument points to a buffer into
+ which the function stores the numeric address. The address is
+ returned in network byte order. Inet_pton() returns 1 if the
+ conversion succeeds, 0 if the input is not a valid IPv4 dotted-
+ decimal string or a valid IPv6 address string, or -1 with errno set
+ to EAFNOSUPPORT if the af argument is unknown. The calling
+ application must ensure that the buffer referred to by dst is large
+ enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
+ bytes for AF_INET6).
+
+ If the af argument is AF_INET, the function accepts a string in the
+ standard IPv4 dotted-decimal form:
+
+ ddd.ddd.ddd.ddd
+
+ where ddd is a one to three digit decimal number between 0 and 255.
+ Note that many implementations of the existing inet_addr() and
+ inet_aton() functions accept nonstandard input: octal numbers,
+ hexadecimal numbers, and fewer than four numbers. inet_pton() does
+ not accept these formats.
+
+
+
+Gilligan, et. al. Informational [Page 31]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ If the af argument is AF_INET6, then the function accepts a string in
+ one of the standard IPv6 text forms defined in Section 2.2 of the
+ addressing architecture specification [2].
+
+ The inet_ntop() function converts a numeric address into a text
+ string suitable for presentation. The af argument specifies the
+ family of the address. This can be AF_INET or AF_INET6. The src
+ argument points to a buffer holding an IPv4 address if the af
+ argument is AF_INET, or an IPv6 address if the af argument is
+ AF_INET6, the address must be in network byte order. The dst
+ argument points to a buffer where the function will store the
+ resulting text string. The size argument specifies the size of this
+ buffer. The application must specify a non-NULL dst argument. For
+ IPv6 addresses, the buffer must be at least 46-octets. For IPv4
+ addresses, the buffer must be at least 16-octets. In order to allow
+ applications to easily declare buffers of the proper size to store
+ IPv4 and IPv6 addresses in string form, the following two constants
+ are defined in <netinet/in.h>:
+
+ #define INET_ADDRSTRLEN 16
+ #define INET6_ADDRSTRLEN 46
+
+ The inet_ntop() function returns a pointer to the buffer containing
+ the text string if the conversion succeeds, and NULL otherwise. Upon
+ failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
+ ENOSPC if the size of the result buffer is inadequate.
+
+6.7 Address Testing Macros
+
+ The following macros can be used to test for special IPv6 addresses.
+
+ #include <netinet/in.h>
+
+ int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
+ int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
+ int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
+ int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
+ int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
+ int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
+ int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
+
+ int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+ int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+ int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+ int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
+ int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
+
+
+
+
+
+Gilligan, et. al. Informational [Page 32]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ The first seven macros return true if the address is of the specified
+ type, or false otherwise. The last five test the scope of a
+ multicast address and return true if the address is a multicast
+ address of the specified scope or false if the address is either not
+ a multicast address or not of the specified scope. Note that
+ IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for
+ the two local-use IPv6 unicast addresses. These two macros do not
+ return true for IPv6 multicast addresses of either link-local scope
+ or site-local scope.
+
+7. Summary of New Definitions
+
+ The following list summarizes the constants, structure, and extern
+ definitions discussed in this memo, sorted by header.
+
+ <net/if.h> IF_NAMESIZE
+ <net/if.h> struct if_nameindex{};
+
+ <netdb.h> AI_ADDRCONFIG
+ <netdb.h> AI_DEFAULT
+ <netdb.h> AI_ALL
+ <netdb.h> AI_CANONNAME
+ <netdb.h> AI_NUMERICHOST
+ <netdb.h> AI_PASSIVE
+ <netdb.h> AI_V4MAPPED
+ <netdb.h> EAI_ADDRFAMILY
+ <netdb.h> EAI_AGAIN
+ <netdb.h> EAI_BADFLAGS
+ <netdb.h> EAI_FAIL
+ <netdb.h> EAI_FAMILY
+ <netdb.h> EAI_MEMORY
+ <netdb.h> EAI_NODATA
+ <netdb.h> EAI_NONAME
+ <netdb.h> EAI_SERVICE
+ <netdb.h> EAI_SOCKTYPE
+ <netdb.h> EAI_SYSTEM
+ <netdb.h> NI_DGRAM
+ <netdb.h> NI_MAXHOST
+ <netdb.h> NI_MAXSERV
+ <netdb.h> NI_NAMEREQD
+ <netdb.h> NI_NOFQDN
+ <netdb.h> NI_NUMERICHOST
+ <netdb.h> NI_NUMERICSERV
+ <netdb.h> struct addrinfo{};
+
+ <netinet/in.h> IN6ADDR_ANY_INIT
+ <netinet/in.h> IN6ADDR_LOOPBACK_INIT
+ <netinet/in.h> INET6_ADDRSTRLEN
+
+
+
+Gilligan, et. al. Informational [Page 33]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ <netinet/in.h> INET_ADDRSTRLEN
+ <netinet/in.h> IPPROTO_IPV6
+ <netinet/in.h> IPV6_JOIN_GROUP
+ <netinet/in.h> IPV6_LEAVE_GROUP
+ <netinet/in.h> IPV6_MULTICAST_HOPS
+ <netinet/in.h> IPV6_MULTICAST_IF
+ <netinet/in.h> IPV6_MULTICAST_LOOP
+ <netinet/in.h> IPV6_UNICAST_HOPS
+ <netinet/in.h> SIN6_LEN
+ <netinet/in.h> extern const struct in6_addr in6addr_any;
+ <netinet/in.h> extern const struct in6_addr in6addr_loopback;
+ <netinet/in.h> struct in6_addr{};
+ <netinet/in.h> struct ipv6_mreq{};
+ <netinet/in.h> struct sockaddr_in6{};
+
+ <sys/socket.h> AF_INET6
+ <sys/socket.h> PF_INET6
+ <sys/socket.h> struct sockaddr_storage;
+
+ The following list summarizes the function and macro prototypes
+ discussed in this memo, sorted by header.
+
+<arpa/inet.h> int inet_pton(int, const char *, void *);
+<arpa/inet.h> const char *inet_ntop(int, const void *,
+ char *, size_t);
+
+<net/if.h> char *if_indextoname(unsigned int, char *);
+<net/if.h> unsigned int if_nametoindex(const char *);
+<net/if.h> void if_freenameindex(struct if_nameindex *);
+<net/if.h> struct if_nameindex *if_nameindex(void);
+
+<netdb.h> int getaddrinfo(const char *, const char *,
+ const struct addrinfo *,
+ struct addrinfo **);
+<netdb.h> int getnameinfo(const struct sockaddr *, socklen_t,
+ char *, size_t, char *, size_t, int);
+<netdb.h> void freeaddrinfo(struct addrinfo *);
+<netdb.h> char *gai_strerror(int);
+<netdb.h> struct hostent *getipnodebyname(const char *, int, int,
+ int *);
+<netdb.h> struct hostent *getipnodebyaddr(const void *, size_t,
+ int, int *);
+<netdb.h> void freehostent(struct hostent *);
+
+<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+
+
+
+Gilligan, et. al. Informational [Page 34]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+
+8. Security Considerations
+
+ IPv6 provides a number of new security mechanisms, many of which need
+ to be accessible to applications. Companion memos detailing the
+ extensions to the socket interfaces to support IPv6 security are
+ being written.
+
+9. Year 2000 Considerations
+
+ There are no issues for this memo concerning the Year 2000 issue
+ regarding the use of dates.
+
+Changes From RFC 2133
+
+ Changes made in the March 1998 Edition (-01 draft):
+
+ Changed all "hostname" to "nodename" for consistency with other
+ IPv6 documents.
+
+ Section 3.3: changed comment for sin6_flowinfo to be "traffic
+ class & flow info" and updated corresponding text description to
+ current definition of these two fields.
+
+ Section 3.10 ("Portability Additions") is new.
+
+ Section 6: a new paragraph was added reiterating that the existing
+ gethostbyname() and gethostbyaddr() are not changed.
+
+ Section 6.1: change gethostbyname3() to getnodebyname(). Add
+ AI_DEFAULT to handle majority of applications. Renamed
+ AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
+ IPv4 addresses too. Defined exactly what getnodebyname() must
+ return if the name argument is a numeric address string.
+
+ Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword
+ items 2 and 3 in the description of how to handle IPv4-mapped and
+ IPv4- compatible addresses to "lookup a name" for a given address,
+ instead of specifying what type of DNS query to issue.
+
+
+
+
+Gilligan, et. al. Informational [Page 35]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ Section 6.3: added two more requirements to getaddrinfo().
+
+ Section 7: added the following constants to the list for
+ <netdb.h>: AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union
+ sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
+
+ Updated references.
+
+ Changes made in the November 1997 Edition (-00 draft):
+
+ The data types have been changed to conform with Draft 6.6 of the
+ Posix 1003.1g standard.
+
+ Section 3.2: data type of s6_addr changed to "uint8_t".
+
+ Section 3.3: data type of sin6_family changed to "sa_family_t".
+ data type of sin6_port changed to "in_port_t", data type of
+ sin6_flowinfo changed to "uint32_t".
+
+ Section 3.4: same as Section 3.3, plus data type of sin6_len
+ changed to "uint8_t".
+
+ Section 6.2: first argument of gethostbyaddr() changed from "const
+ char *" to "const void *" and second argument changed from "int"
+ to "size_t".
+
+ Section 6.4: second argument of getnameinfo() changed from
+ "size_t" to "socklen_t".
+
+ The wording was changed when new structures were defined, to be
+ more explicit as to which header must be included to define the
+ structure:
+
+ Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
+ 3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
+ (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
+
+ Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
+
+ Section 5.1: The IPV6_ADDRFORM socket option was removed.
+
+ Section 5.3: Added a note that an option value other than 0 or 1
+ for IPV6_MULTICAST_LOOP returns an error. Added a note that
+ IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
+ can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
+ IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
+
+
+
+
+
+Gilligan, et. al. Informational [Page 36]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ Section 6.1: Removed the description of gethostbyname2() and its
+ associated RES_USE_INET6 option, replacing it with
+ gethostbyname3().
+
+ Section 6.2: Added requirement that gethostbyaddr() be thread
+ safe. Reworded step 4 to avoid using the RES_USE_INET6 option.
+
+ Section 6.3: Added the requirement that getaddrinfo() and
+ getnameinfo() be thread safe. Added the AI_NUMERICHOST flag.
+
+ Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
+ IN6_IS_ADDR_SITELOCAL macros.
+
+ Changes made to the draft -01 specification Sept 98
+
+ Changed priority to traffic class in the spec.
+
+ Added the need for scope identification in section 2.1.
+
+ Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
+ 3.4.
+
+ Changed 3.10 to use generic storage structure to support holding
+ IPv6 addresses and removed the SA_LEN macro.
+
+ Distinguished between invalid input parameters and system failures
+ for Interface Identification in Section 4.1 and 4.2.
+
+ Added defaults for multicast operations in section 5.2 and changed
+ the names from ADD to JOIN and DROP to LEAVE to be consistent with
+ IPv6 multicast terminology.
+
+ Changed getnodebyname to getipnodebyname, getnodebyaddr to
+ getipnodebyaddr, and added MT safe error code to function
+ parameters in section 6.
+
+ Moved freehostent to its own sub-section after getipnodebyaddr now
+ 6.3 (so this bumps all remaining sections in section 6.
+
+ Clarified the use of AI_ALL and AI_V4MAPPED that these are
+ dependent on the AF parameter and must be used as a conjunction in
+ section 6.1.
+
+ Removed the restriction that literal addresses cannot be used with
+ a flags argument in section 6.1.
+
+ Added Year 2000 Section to the draft
+
+
+
+
+Gilligan, et. al. Informational [Page 37]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ Deleted Reference to the following because the attached is deleted
+ from the ID directory and has expired. But the logic from the
+ aforementioned draft still applies, so that was kept in Section
+ 6.2 bullets after 3rd paragraph.
+
+ [7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
+ Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
+ ipv4ptr-00.txt>, May 1996.
+
+ Deleted the following reference as it is no longer referenced.
+ And the draft has expired.
+
+ [3] D. McDonald, "A Simple IP Security API Extension to BSD
+ Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
+ 01.txt>, March 1997.
+
+ Deleted the following reference as it is no longer referenced.
+
+ [4] C. Metz, "Network Security API for Sockets",
+ Internet-Draft, <draft-metz-net-security-api-01.txt>, January
+ 1998.
+
+ Update current references to current status.
+
+ Added alignment notes for in6_addr and sin6_addr.
+
+ Clarified further that AI_V4MAPPED must be used with a dotted IPv4
+ literal address for getipnodebyname(), when address family is
+ AF_INET6.
+
+ Added text to clarify "::" and "::1" when used by
+ getipnodebyaddr().
+
+Acknowledgments
+
+ Thanks to the many people who made suggestions and provided feedback
+ to this document, including: Werner Almesberger, Ran Atkinson, Fred
+ Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve
+ Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom
+ Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada,
+ Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave
+ Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc
+ Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
+ Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
+ Waitzman, Carl Williams, and Kazu Yamamoto,
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 38]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+ The getaddrinfo() and getnameinfo() functions are taken from an
+ earlier Internet Draft by Keith Sklower. As noted in that draft,
+ William Durst, Steven Wise, Michael Karels, and Eric Allman provided
+ many useful discussions on the subject of protocol-independent name-
+ to-address translation, and reviewed early versions of Keith
+ Sklower's original proposal. Eric Allman implemented the first
+ prototype of getaddrinfo(). The observation that specifying the pair
+ of name and service would suffice for connecting to a service
+ independent of protocol details was made by Marshall Rose in a
+ proposal to X/Open for a "Uniform Network Interface".
+
+ Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
+ Kacker made many contributions to this document. Ramesh Govindan
+ made a number of contributions and co-authored an earlier version of
+ this memo.
+
+References
+
+ [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 2460, December 1998.
+
+ [2] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [3] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
+ 6.6, March 1997.
+
+ [4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
+ 2292, February 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 39]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+Authors' Addresses
+
+ Robert E. Gilligan
+ FreeGate Corporation
+ 1208 E. Arques Ave.
+ Sunnyvale, CA 94086
+
+ Phone: +1 408 617 1004
+ EMail: gilligan@freegate.com
+
+
+ Susan Thomson
+ Bell Communications Research
+ MRE 2P-343, 445 South Street
+ Morristown, NJ 07960
+
+ Phone: +1 201 829 4514
+ EMail: set@thumper.bellcore.com
+
+
+ Jim Bound
+ Compaq Computer Corporation
+ 110 Spitbrook Road ZK3-3/U14
+ Nashua, NH 03062-2698
+
+ Phone: +1 603 884 0400
+ EMail: bound@zk3.dec.com
+
+
+ W. Richard Stevens
+ 1202 E. Paseo del Zorro
+ Tucson, AZ 85718-2826
+
+ Phone: +1 520 297 9416
+ EMail: rstevens@kohala.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 40]
+
+RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al. Informational [Page 41]
+
diff --git a/Documentation/en/rfc/rfc2766.txt b/Documentation/en/rfc/rfc2766.txt
new file mode 100644
index 00000000..73710309
--- /dev/null
+++ b/Documentation/en/rfc/rfc2766.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group G. Tsirtsis
+Request for Comments: 2766 BT
+Category: Standards Track P. Srisuresh
+ Campio Communications
+ February 2000
+
+
+ Network Address Translation - Protocol Translation (NAT-PT)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document specifies an IPv4-to-IPv6 transition mechanism, in
+ addition to those already specified in [TRANS]. This solution
+ attempts to provide transparent routing, as defined in [NAT-TERM], to
+ end-nodes in V6 realm trying to communicate with end-nodes in V4
+ realm and vice versa. This is achieved using a combination of Network
+ Address Translation and Protocol Translation. The scheme described
+ does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol
+ support) or special purpose routing requirements (such as requiring
+ tunneling support) on end nodes. This scheme is based on a
+ combination of address translation theme as described in [NAT-TERM]
+ and V6/V4 protocol translation theme as described in [SIIT].
+
+Acknowledgements
+
+ Special thanks to Pedro Marques for reviewing an earlier version of
+ this memo. Also, many thanks to Alan O'Neill and Martin Tatham, as
+ the mechanism described in this document was initially developed
+ through discussions with them.
+
+
+
+
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 1]
+
+RFC 2766 NAT-PT February 2000
+
+
+Table of Contents
+
+ 1. Introduction.................................................. 2
+ 2. Terminology................................................... 3
+ 2.1 Network Address Translation (NAT)......................... 4
+ 2.2 NAT-PT flavors............................................ 4
+ 2.2.1 Traditional-NAT-PT................................... 4
+ 2.2.2 Bi-directional-NAT-PT................................ 5
+ 2.3 Protocol Translation (PT)................................. 5
+ 2.4 Application Level Gateway (ALG)........................... 5
+ 2.5 Requirements.............................................. 5
+ 3. Traditional-NAT-PT operation (V6 to V4)....................... 6
+ 3.1 NAT-PT Outgoing Sessions.................................. 6
+ 3.2 NAPT-PT Outgoing Sessions................................. 7
+ 4. Use of DNS-ALG for Address assignment......................... 8
+ 4.1 V4 Address Assignment for Incoming Connections (V4 to V6). 9
+ 4.2 V4 Address Assignment for Outgoing Connections (V6 to V4). 11
+ 5. Protocol Translation Details.................................. 12
+ 5.1 Translating IPv4 Headers to IPv6 Headers.................. 13
+ 5.2 Translating IPv6 Headers to IPv4 Headers.................. 13
+ 5.3 TCP/UDP/ICMP Checksum Update.............................. 13
+ 6. FTP Application Level Gateway (FTP-ALG) Support............... 14
+ 6.1 Payload modifications for V4 originated FTP sessions...... 15
+ 6.2 Payload modifications for V6 originated FTP sessions...... 16
+ 6.3 Header updates for FTP control packets.................... 16
+ 7. NAT-PT Limitations and Future Work............................ 17
+ 7.1 Topology Limitations...................................... 17
+ 7.2 Protocol Translation Limitations.......................... 17
+ 7.3 Impact of Address Translation............................. 18
+ 7.4 Lack of End-to-End Security............................... 18
+ 7.5 DNS Translation and DNSSEC................................ 18
+ 8. Applicability Statement....................................... 18
+ 9. Security Considerations....................................... 19
+ 10. References................................................... 19
+ Authors' Addresses............................................... 20
+ Full Copyright Statement......................................... 21
+
+1. Introduction
+
+ IPv6 is a new version of the IP protocol designed to modernize IPv4
+ which was designed in the 1970s. IPv6 has a number of advantages over
+ IPv4 that will allow for future Internet growth and will simplify IP
+ configuration and administration. IPv6 has a larger address space
+ than IPv4, an addressing model that promotes aggressive route
+ aggregation and a powerful autoconfiguration mechanism. In time, it
+ is expected that Internet growth and a need for a plug-and-play
+ solution will result in widespread adoption of IPv6.
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 2]
+
+RFC 2766 NAT-PT February 2000
+
+
+ There is expected to be a long transition period during which it will
+ be necessary for IPv4 and IPv6 nodes to coexist and communicate. A
+ strong, flexible set of IPv4-to-IPv6 transition and coexistence
+ mechanisms will be required during this transition period.
+
+ The SIIT proposal [SIIT] describes a protocol translation mechanism
+ that allows communication between IPv6-only and IPv4-only nodes via
+ protocol independent translation of IPv4 and IPv6 datagrams,
+ requiring no state information for the session. The SIIT proposal
+ assumes that V6 nodes are assigned a V4 address for communicating
+ with V4 nodes, and does not specify a mechanism for the assignment of
+ these addresses.
+
+ NAT-PT uses a pool of V4 addresses for assignment to V6 nodes on a
+ dynamic basis as sessions are initiated across V4-V6 boundaries. The
+ V4 addresses are assumed to be globally unique. NAT-PT with private
+ V4 addresses is outside the scope of this document and for further
+ study. NAT-PT binds addresses in V6 network with addresses in V4
+ network and vice versa to provide transparent routing [NAT-TERM] for
+ the datagrams traversing between address realms. This requires no
+ changes to end nodes and IP packet routing is completely transparent
+ [NAT-TERM] to end nodes. It does, however, require NAT-PT to track
+ the sessions it supports and mandates that inbound and outbound
+ datagrams pertaining to a session traverse the same NAT-PT router.
+ You will note that the topology restrictions on NAT-PT are the same
+ with those described for V4 NATs in [NAT-TERM]. Protocol translation
+ details specified in [SIIT] would be used to extend address
+ translation with protocol syntax/semantics translation. A detailed
+ applicability statement for NAT-PT may be found at the end of this
+ document in section 7.
+
+ By combining SIIT protocol translation with the dynamic address
+ translation capabilities of NAT and appropriate ALGs, NAT-PT provides
+ a complete solution that would allow a large number of commonly used
+ applications to interoperate between IPv6-only nodes and IPv4-only
+
+ A fundamental assumption for NAT-PT is only to be use when no other
+ native IPv6 or IPv6 over IPv4 tunneled means of communication is
+ possible. In other words the aim is to only use translation between
+ IPv6 only nodes and IPv4 only nodes, while translation between IPv6
+ only nodes and the IPv4 part of a dual stack node should be avoided
+ over other alternatives.
+
+2. Terminology
+
+ The majority of terms used in this document are borrowed almost as is
+ from [NAT-TERM]. The following lists terms specific to this document.
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 3]
+
+RFC 2766 NAT-PT February 2000
+
+
+2.1 Network Address Translation (NAT)
+
+ The term NAT in this document is very similar to the IPv4 NAT
+ described in [NAT-TERM], but is not identical. IPv4 NAT translates
+ one IPv4 address into another IPv4 address. In this document, NAT
+ refers to translation of an IPv4 address into an IPv6 address and
+ vice versa.
+
+ While the V4 NAT [NAT-TERM] provides routing between private V4 and
+ external V4 address realms, NAT in this document provides routing
+ between a V6 address realm and an external V4 address realm.
+
+2.2 NAT-PT flavors
+
+ Just as there are various flavors identified with V4 NAT in [NAT-
+ TERM], the following NAT-PT variations may be identified in this
+ document.
+
+2.2.1 Traditional NAT-PT
+
+ Traditional-NAT-PT would allow hosts within a V6 network to access
+ hosts in the V4 network. In a traditional-NAT-PT, sessions are uni-
+ directional, outbound from the V6 network. This is in contrast with
+ Bi-directional-NAT-PT, which permits sessions in both inbound and
+ outbound directions.
+
+ Just as with V4 traditional-NAT, there are two variations to
+ traditional-NAT-PT, namely Basic-NAT-PT and NAPT-PT.
+
+ With Basic-NAT-PT, a block of V4 addresses are set aside for
+ translating addresses of V6 hosts as they originate sessions to the
+ V4 hosts in external domain. For packets outbound from the V6 domain,
+ the source IP address and related fields such as IP, TCP, UDP and
+ ICMP header checksums are translated. For inbound packets, the
+ destination IP address and the checksums as listed above are
+ translated.
+
+ NAPT-PT extends the notion of translation one step further by also
+ translating transport identifier (e.g., TCP and UDP port numbers,
+ ICMP query identifiers). This allows the transport identifiers of a
+ number of V6 hosts to be multiplexed into the transport identifiers
+ of a single assigned V4 address. NAPT-PT allows a set of V6 hosts to
+ share a single V4 address. Note that NAPT-PT can be combined with
+ Basic-NAT-PT so that a pool of external addresses are used in
+ conjunction with port translation.
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 4]
+
+RFC 2766 NAT-PT February 2000
+
+
+ For packets outbound from the V6 network, NAPT-PT would translate the
+ source IP address, source transport identifier and related fields
+ such as IP, TCP, UDP and ICMP header checksums. Transport identifier
+ can be one of TCP/UDP port or ICMP query ID. For inbound packets, the
+ destination IP address, destination transport identifier and the IP
+ and transport header checksums are translated.
+
+2.2.2 Bi-Directional-NAT-PT
+
+ With Bi-directional-NAT-PT, sessions can be initiated from hosts in
+ V4 network as well as the V6 network. V6 network addresses are bound
+ to V4 addresses, statically or dynamically as connections are
+ established in either direction. The name space (i.e., their Fully
+ Qualified Domain Names) between hosts in V4 and V6 networks is
+ assumed to be end-to-end unique. Hosts in V4 realm access V6-realm
+ hosts by using DNS for address resolution. A DNS-ALG [DNS-ALG] must
+ be employed in conjunction with Bi-Directional-NAT-PT to facilitate
+ name to address mapping. Specifically, the DNS-ALG must be capable
+ of translating V6 addresses in DNS Queries and responses into their
+ V4-address bindings, and vice versa, as DNS packets traverse between
+ V6 and V4 realms.
+
+2.3 Protocol Translation (PT)
+
+ PT in this document refers to the translation of an IPv4 packet into
+ a semantically equivalent IPv6 packet and vice versa. Protocol
+ translation details are described in [SIIT].
+
+2.4 Application Level Gateway (ALG)
+
+ Application Level Gateway (ALG) [NAT-TERM] is an application specific
+ agent that allows a V6 node to communicate with a V4 node and vice
+ versa. Some applications carry network addresses in payloads. NAT-PT
+ is application unaware and does not snoop the payload. ALG could work
+ in conjunction with NAT-PT to provide support for many such
+ applications.
+
+2.5 Requirements
+
+ The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+ SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+ document, are to be interpreted as described in [KEYWORDS].
+
+
+
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 5]
+
+RFC 2766 NAT-PT February 2000
+
+
+3. Traditional-NAT-PT Operation (V6 to V4)
+
+ NAT-PT offers a straight forward solution based on transparent
+ routing [NAT-TERM] and address/protocol translation, allowing a large
+ number of applications in V6 and V4 realms to inter-operate without
+ requiring any changes to these applications.
+
+ In the following paragraphs we describe the operation of
+ traditional-NAT-PT and the way that connections can be initiated from
+ a host in IPv6 domain to a host in IPv4 domain through a
+ traditional-NAT-PT
+
+3.1 Basic-NAT-PT Operation
+
+ [IPv6-B]-+
+ | +==============+
+ [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
+ | +==============+
+ (pool of v4 addresses)
+
+ Figure 1: IPv6 to IPv4 communication
+ Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
+ Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
+ Node IPv4-C has an IPv4 address -> 132.146.243.30
+
+ NAT-PT has a pool of addresses including the IPv4 subnet
+ 120.130.26/24
+
+ The V4 addresses in the address pool could be allocated one-to-one to
+ the V6 addresses of the V6 end nodes in which case one needs as many
+ V4 addresses as V6 end points. In this document we assume that the V6
+ network has less V4 addresses than V6 end nodes and thus dynamic
+ address allocation is required for at least some of them.
+
+ Say the IPv6 Node A wants to communicate with the IPv4 Node C. Node
+ A creates a packet with:
+
+ Source Address, SA=FEDC:BA98::7654:3210 and Destination
+ Address, DA = PREFIX::132.146.243.30
+
+ NOTE: The prefix PREFIX::/96 is advertised in the stub domain by the
+ NAT-PT, and packets addressed to this PREFIX will be routed to the
+ NAT-PT. The pre-configured PREFIX only needs to be routable within
+ the IPv6 stub domain and as such it can be any routable prefix that
+ the network administrator chooses.
+
+ The packet is routed via the NAT-PT gateway, where it is translated
+ to IPv4.
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 6]
+
+RFC 2766 NAT-PT February 2000
+
+
+ If the outgoing packet is not a session initialisation packet, the
+ NAT-PT SHOULD already have stored some state about the related
+ session, including assigned IPv4 address and other parameters for the
+ translation. If this state does not exist, the packet SHOULD be
+ silently discarded.
+
+ If the packet is a session initialisation packet, the NAT-PT locally
+ allocates an address (e.g: 120.130.26.10) from its pool of
+ addresses and the packet is translated to IPv4. The translation
+ parameters are cached for the duration of the session and the IPv6 to
+ IPv4 mapping is retained by NAT-PT.
+
+ The resulting IPv4 packet has SA=120.130.26.10 and DA=132.146.243.30.
+ Any returning traffic will be recognised as belonging to the same
+ session by NAT-PT. NAT-PT will use the state information to translate
+ the packet, and the resulting addresses will be
+ SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that this
+ packet can now be routed inside the IPv6-only stub network as normal.
+
+3.2 NAPT-PT Operation
+
+ NAPT-PT, which stands for "Network Address Port Translation +
+ Protocol Translation", would allow V6 nodes to communicate with the
+ V4 nodes transparently using a single V4 address. The TCP/UDP ports
+ of the V6 nodes are translated into TCP/UDP ports of the registered
+ V4 address.
+
+ While NAT-PT support is limited to TCP, UDP and other port
+ multiplexing type of applications, NAPT-PT solves a problem that is
+ inherent with NAT-PT. That is, NAT-PT would fall flat when the pool
+ of V4 addresses assigned for translation purposes is exhausted. Once
+ the address pool is exhausted, newer V6 nodes cannot establish
+ sessions with the outside world anymore. NAPT-PT, on the other hand,
+ will allow for a maximum of 63K TCP and 63K UDP sessions per IPv4
+ address before having no TCP and UDP ports left to assign.
+
+ To modify the example sited in figure 1, we could have NAPT-PT on the
+ border router (instead of NAT-PT) and all V6 addresses could be
+ mapped to a single v4 address 120.130.26.10.
+
+ IPv6 Node A would establish a TCP session with the IPv4 Node C as
+ follows:
+
+ Node A creates a packet with:
+
+ Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017 and
+ Destination Address, DA = PREFIX::132.146.243.30, destination TCP
+ port = 23.
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 7]
+
+RFC 2766 NAT-PT February 2000
+
+
+ When the packet reaches the NAPT-PT box, NAPT-PT would assign one of
+ the TCP ports from the assigned V4 address to translate the tuple of
+ (Source Address, Source TCP port) as follows:
+
+ SA=120.130.26.10, source TCP port = 1025 and
+ DA=132.146.243.30, destination TCP port = 23.
+
+ The returning traffic from 132.146.243.30, TCP port 23 will be
+ recognised as belonging to the same session and will be translated
+ back to V6 as follows:
+
+ SA = PREFIX::132.146.243.30, source TCP port = 23;
+ DA = FEDC:BA98::7654:3210 , destination TCP port = 3017
+
+ Inbound NAPT-PT sessions are restricted to one server per service,
+ assigned via static TCP/UDP port mapping. For example, the Node
+ [IPv6-A] in figure 1 may be the only HTTP server (port 80) in the V6
+ domain. Node [IPv4-C] sends a packet:
+
+ SA=132.146.243.30, source TCP port = 1025 and
+ DA=120.130.26.10, destination TCP port = 80
+
+ NAPT-PT will translate this packet to:
+
+ SA=PREFIX::132.146.243.30, source TCP port = 1025
+ DA=FEDC:BA98::7654:3210, destination TCP port = 80
+
+ In the above example, note that all sessions which reach NAPT-PT with
+ a destination port of 80 will be redirected to the same node [IPv6-
+ A].
+
+4. Use of DNS-ALG for Address Assignment
+
+ An IPv4 address is assigned by NAT-PT to a V6 node when NAT-PT
+ identifies the start of session, inbound or outbound. Identification
+ of the start of a new inbound session is performed differently than
+ for outbound sessions. However, the same V4 address pool is used for
+ assignment to V6 nodes, irrespective of whether a session is
+ initiated outbound from a V6 node or initiated inbound from a V4
+ node.
+
+ Policies determining what type of sessions are allowed and in which
+ direction and from/to which nodes is out of the scope of this
+ document.
+
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 8]
+
+RFC 2766 NAT-PT February 2000
+
+
+ IPv4 name to address mappings are held in the DNS with "A" records.
+ IPv6 name to address mappings are at the moment held in the DNS with
+ "AAAA" records. "A6" records have also been defined but at the time
+ of writing they are neither fully standardized nor deployed.
+
+ In any case, the DNS-ALG's principle of operation described in this
+ section is the same with either "AAAA" or "A6" records. The only
+ difference is that a name resolution using "A6" records may require
+ more than one query - reply pairs. The DNS-ALG SHOULD, in that case,
+ track all the replies in the transaction before translating an "A6"
+ record to an "A" record.
+
+ One of the aims of NAT-PT design is to only use translation when
+ there is no other means of communication, such as native IPv6 or some
+ form of tunneling. For the following discussion NAT-PT, in addition
+ to the IPv4 connectivity that it has it may also have a native IPv6
+ and/or a tunneled IPv6 connection.
+
+4.1 V4 Address assignment for incoming connections (V4 to V6)
+
+ [DNS]--+
+ | [DNS]------[DNS]-------[DNS]
+ [IPv6-B]-+ | |
+ | +==============+ |
+ [IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C]
+ | +==============+
+ (pool of v4 addresses)
+
+ Figure 2: IPv4 to IPv6 communication
+ Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
+ Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
+ Node IPv4-C has an IPv4 address -> 132.146.243.30
+
+ NAT-PT has a pool of addresses including the IPv4 subnet
+ 120.130.26/24
+
+ In figure 2 above, when Node C's name resolver sends a name look up
+ request for Node A, the lookup query is directed to the DNS server on
+ the V6 network. Considering that NAT-PT is residing on the border
+ router between V4 and V6 networks, this request datagram would
+ traverse through the NAT-PT router. The DNS-ALG on the NAT-PT device
+ would modify DNS Queries for A records going into the V6 domain as
+ follows: (Note that a TCP/UDP DNS packet is recognised by the fact
+ that its source or destination port number is 53)
+
+ a) For Node Name to Node Address Query requests: Change the Query
+ type from "A" to "AAAA" or "A6".
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 9]
+
+RFC 2766 NAT-PT February 2000
+
+
+ b) For Node address to Node name query requests: Replace the
+ string "IN-ADDR.ARPA" with the string "IP6.INT". Replace the
+ V4 address octets (in reverse order) preceding the string "IN-
+ ADDR.ARPA" with the corresponding V6 address (if there exists a
+ map) octets in reverse order.
+
+ In the opposite direction, when a DNS response traverses from the DNS
+ server on the V6 network to the V4 node, the DNS-ALG once again
+ intercepts the DNS packet and would:
+
+ a) Translate DNS responses for "AAAA" or "A6" records into "A"
+ records, (only translate "A6" records when the name has
+ completely been resolved)
+ b) Replace the V6 address resolved by the V6 DNS with the V4
+ address internally assigned by the NAT-PT router.
+
+ If a V4 address is not previously assigned to this V6 node, NAT-PT
+ would assign one at this time. As an example say IPv4-C attempts to
+ initialise a session with node IPv6-A by making a name lookup ("A"
+ record) for Node-A . The name query goes to the local DNS and from
+ there it is propagated to the DNS server of the IPv6 network. The
+ DNS-ALG intercepts and translates the "A" query to "AAAA" or "A6"
+ query and then forwards it to the DNS server in the IPv6 network
+ which replies as follows: (The example uses AAAA records for
+ convenience)
+
+ Node-A AAAA FEDC:BA98::7654:3210,
+
+ this is returned by the DNS server and gets intercepted and
+ translated by the DNS-ALG to:
+
+ Node-A A 120.130.26.1
+
+ The DNS-ALG also holds the mapping between FEDC:BA98::7654:3210 and
+ 120.130.26.1 in NAT-PT. The "A" record is then returned to Node-C.
+ Node-C can now initiate a session as follows:
+
+ SA=132.146.243.30, source TCP port = 1025 and
+ DA=120.130.26.1, destination TCP port = 80
+
+ the packet will be routed to NAT-PT, which since it already holds a
+ mapping between FEDC:BA98::7654:3210 and 120.130.26.1 can translate
+ the packet to:
+
+ SA=PREFIX::132.146.243.30, source TCP port = 1025
+ DA=FEDC:BA98::7654:3210, destination TCP port = 80
+
+ the communication can now proceed as normal.
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 10]
+
+RFC 2766 NAT-PT February 2000
+
+
+ The TTL values on all DNS resource records (RRs) passing through
+ NAT-PT SHOULD be set to 0 so that DNS servers/clients do not cache
+ temporarily assigned RRs. Note, however, that due to some buggy DNS
+ client implementations a value of 1 might in some cases work better.
+ The TTL values should be left unchanged for statically mapped
+ addresses.
+
+ Address mappings for incoming sessions, as described above, are
+ subject to denial of service attacks since one can make multiple
+ queries for nodes residing in the V6 network causing the DNS-ALG to
+ map all V4 addresses in NAT-PT and thus block legitimate incoming
+ sessions. Thus, address mappings for incoming sessions should time
+ out to minimise the effect of denial of service attacks.
+ Additionally, one IPv4 address (using NAPT-PT, see 3.2) could be
+ reserved for outgoing sessions only to minimise the effect of such
+ attacks to outgoing sessions.
+
+4.2 V4 Address assignment for outgoing connections (V6 to V4)
+
+ V6 nodes learn the address of V4 nodes from the DNS server in the V4
+ domain or from the DNS server internal to the V6 network. We
+ recommend that DNS servers internal to V6 domains maintain a mapping
+ of names to IPv6 addresses for internal nodes and possibly cache
+ mappings for some external nodes. In the case where the DNS server in
+ the v6 domain contains the mapping for external V4 nodes, the DNS
+ queries will not cross the V6 domain and that would obviate the need
+ for DNS-ALG intervention. Otherwise, the queries will cross the V6
+ domain and are subject to DNS-ALG intervention. We recommend
+ external DNS servers in the V4 domain cache name mapping for external
+ nodes (i.e., V4 nodes) only. Zone transfers across IPv4 - IPv6
+ boundaries are strongly discouraged.
+
+ In the case of NAPT-PT, a TCP/UDP source port is assigned from the
+ registered V4 address upon detection of each new outbound session.
+
+ We saw that a V6 node that needs to communicate with a V4 node needs
+ to use a specific prefix (PREFIX::/96) in front of the IPv4 address
+ of the V4 node. The above technique allows the use of this PREFIX
+ without any configuration in the nodes.
+
+ To create another example from Figure 2 say Node-A wants to set up a
+ session with Node-C. For this Node-A starts by making a name look-up
+ ("AAAA" or "A6" record) for Node-C.
+
+ Since Node-C may have IPv6 and/or IPv4 addresses, the DNS-ALG on the
+ NAT-PT device forwards the original AAAA/A6 query to the external DNS
+ system unchanged, as well as an A query for the same node. If an
+ AAAA/A6 record exists for the destination, this will be returned to
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 11]
+
+RFC 2766 NAT-PT February 2000
+
+
+ NAT-PT which will forward it, also unchanged, to the originating
+ host.
+
+ If there is an A record for Node-C the reply also returns to the
+ NAT-PT. The DNS-ALG then, translates the reply adding the appropriate
+ PREFIX and forwards it to the originating device with any IPv6
+ addresses that might have learned. So, if the reply is
+
+ NodeC A 132.146.243.30, it is translated to
+ NodeC AAAA PREFIX::132.146.243.30 or to
+ NodeC A6 PREFIX::132.146.243.30
+
+ Now Node A can use this address like any other IPv6 address and the
+ V6 DNS server can even cache it as long as the PREFIX does not
+ change.
+
+ An issue here is how the V6 DNS server in the V6 stub domain talks to
+ the V4 domain outside the V6 stub domain. Remember that there are no
+ dual stack nodes here. The external V4 DNS server needs to point to a
+ V4 address, part of the V4 pool of addresses, available to NAT-PT.
+ NAT-PT keeps a one-to-one mapping between this V4 address and the V6
+ address of the internal V6 DNS server. In the other direction, the V6
+ DNS server points to a V6 address formed by the IPv4 address of the
+ external V4 DNS servers and the prefix (PREFIX::/96) that indicates
+ non IPv6 nodes. This mechanism can easily be extended to accommodate
+ secondary DNS servers.
+
+ Note that the scheme described in this section impacts DNSSEC. See
+ section 7.5 of this document for details.
+
+5. Protocol Translation Details
+
+ The IPv4 and ICMPv4 headers are similar to their V6 counterparts but
+ a number of field are either missing, have different meaning or
+ different length. NAT-PT SHOULD translate all IP/ICMP headers from v4
+ to v6 and vice versa in order to make end-to-end IPv6 to IPv4
+ communication possible. Due to the address translation function and
+ possible port multiplexing, NAT-PT SHOULD also make appropriate
+ adjustments to the upper layer protocol (TCP/UDP) headers. A separate
+ section on FTP-ALG describes the changes FTP-ALG would make to FTP
+ payload as an FTP packet traverses from V4 to V6 realm or vice versa.
+
+ Protocol Translation details are described in [SIIT], but there are
+ some modifications required to SIIT because of the fact that NAT-PT
+ also performs Network Address Translation.
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 12]
+
+RFC 2766 NAT-PT February 2000
+
+
+5.1 Translating IPv4 headers to IPv6 headers
+
+ This is done exactly the same as in SIIT apart from the following
+ fields:
+
+ Source Address:
+ The low-order 32 bits is the IPv4 source address. The high-
+ order 96 bits is the designated PREFIX for all v4
+ communications. Addresses using this PREFIX will be routed
+ to the NAT-PT gateway (PREFIX::/96)
+
+ Destination Address:
+ NAT-PT retains a mapping between the IPv4 destination
+ address and the IPv6 address of the destination node. The
+ IPv4 destination address is replaced by the IPv6 address
+ retained in that mapping.
+
+5.2 Translating IPv6 headers to IPv4 headers
+
+ This is done exactly the same as in SIIT apart from the Source
+ Address which should be determined as follows:
+
+ Source Address:
+ The NAT-PT retains a mapping between the IPv6 source address
+ and an IPv4 address from the pool of IPv4 addresses
+ available. The IPv6 source address is replaced by the IPv4
+ address retained in that mapping.
+
+ Destination Address:
+ IPv6 packets that are translated have a destination address
+ of the form PREFIX::IPv4/96. Thus the low-order 32 bits of
+ the IPv6 destination address is copied to the IPv4
+ destination address.
+
+5.3 TCP/UDP/ICMP Checksum Update
+
+ NAT-PT retains mapping between IPv6 address and an IPv4 address from
+ the pool of IPv4 addresses available. This mapping is used in the
+ translation of packets that go through NAT-PT.
+
+ The following sub-sections describe TCP/UDP/ICMP checksum update
+ procedure in NAT-PT, as packets are translated from V4 to V6 and vice
+ versa.
+
+
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 13]
+
+RFC 2766 NAT-PT February 2000
+
+
+5.3.1 TCP/UDP/ICMP Checksum Update from IPv4 to IPv6
+
+ UDP checksums, when set to a non-zero value, and TCP checksum SHOULD
+ be recalculated to reflect the address change from v4 to v6. The
+ incremental checksum adjustment algorithm may be borrowed from [NAT].
+ In the case of NAPT-PT, TCP/UDP checksum should be adjusted to
+ account for the address and TCP/UDP port changes, going from V4 to V6
+ address.
+
+ When the checksum of a V4 UDP packet is set to zero, NAT-PT MUST
+ evaluate the checksum in its entirety for the V6-translated UDP
+ packet. If a V4 UDP packet with a checksum of zero arrives in
+ fragments, NAT-PT MUST await all the fragments until they can be
+ assembled into a single non-fragmented packet and evaluate the
+ checksum prior to forwarding the translated V6 UDP packet.
+
+ ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP and TCP
+ during checksum computation. As a result, when the ICMPv6 header
+ checksum is computed [SIIT], the checksum needs to be adjusted to
+ account for the additional pseudo-header. Note, there may also be
+ adjustments required to the checksum due to changes in the source and
+ destination addresses (and changes in TCP/UDP/ICMP identifiers in the
+ case of NAPT-PT) of the payload carried within ICMP.
+
+5.3.2 TCP/UDP/ICMP Checksum Update from IPv6 to IPv4
+
+ TCP and UDP checksums SHOULD be recalculated to reflect the address
+ change from v6 to v4. The incremental checksum adjustment algorithm
+ may be borrowed from [NAT]. In the case of NAPT-PT, TCP/UDP checksums
+ should be adjusted to account for the address and TCP/UDP port
+ changes, going from V6 to V4 addresses. For UDP packets, optionally,
+ the checksum may simply be changed to zero.
+
+ The checksum calculation for a V4 ICMP header needs to be derived
+ from the V6 ICMP header by running the checksum adjustment algorithm
+ [NAT] to remove the V6 pseudo header from the computation. Note, the
+ adjustment must additionally take into account changes to the
+ checksum as a result of updates to the source and destination
+ addresses (and transport ports in the case of NAPT-PT) made to the
+ payload carried within ICMP.
+
+6. FTP Application Level Gateway (FTP-ALG) Support
+
+ Because an FTP control session carries, in its payload, the IP
+ address and TCP port information for the data session, an FTP-ALG is
+ required to provide application level transparency for this popular
+ Internet application.
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 14]
+
+RFC 2766 NAT-PT February 2000
+
+
+ In the FTP application running on a legacy V4 node, arguments to the
+ FTP PORT command and arguments in PASV response(successful) include
+ an IP V4 address and a TCP port, both represented in ASCII as
+ h1,h2,h3,h4,p1,p2. However, [FTP-IPV6] suggests EPRT and EPSV command
+ extensions to FTP, with an intent to eventually retire the use of
+ PORT and PASV commands. These extensions may be used on a V4 or V6
+ node. FTP-ALG, facilitating transparent FTP between V4 and V6 nodes,
+ works as follows.
+
+6.1 Payload modifications for V4 originated FTP sessions
+
+ A V4 host may or may not have the EPRT and EPSV command extensions
+ implemented in its FTP application. If a V4 host originates the FTP
+ session and uses PORT or PASV command, the FTP-ALG will translate
+ these commands into EPRT and EPSV commands respectively prior to
+ forwarding to the V6 node. Likewise, EPSV response from V6 nodes will
+ be translated into PASV response prior to forwarding to V4 nodes.
+ The format of EPRT and EPSV commands and EPSV response may be
+ specified as follows[FTP-IPV6].
+
+ EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
+ EPSV<space><net-prt>
+ (or)
+ EPSV<space>ALL
+
+ Format of EPSV response(Positive): 229 <text indicating
+ extended passive mode> (<d><d><d><tcp-port><d>)
+
+ PORT command from a V4 node is translated into EPRT command, by
+ setting the protocol <net-prt> field to AF #2 (IPV6) and translating
+ the V4 host Address (represented as h1,h2,h3,h4) into its NAT-PT
+ assigned V6 address in string notation, as defined in [V6ADDR] in the
+ <net-addr> field. TCP port represented by p1,p2 in PORT command must
+ be specified as a decimal <tcp-port> in the EPRT command. Further,
+ <tcp-port> translation may also be required in the case of NAPT-PT.
+ PASV command from a V4 node is be translated into a EPSV command with
+ the <net-prt> argument set to AF #2. EPSV response from a V6 node is
+ translated into PASV response prior to forwarding to the target V4
+ host.
+
+ If a V4 host originated the FTP session and was using EPRT and EPSV
+ commands, the FTP-ALG will simply translate the parameters to these
+ commands, without altering the commands themselves. The protocol
+ Number <net-prt> field will be translated from AF #1 to AF #2.
+ <net-addr> will be translated from the V4 address in ASCII to its
+ NAT-PT assigned V6 address in string notation as defined in [V6ADDR].
+ <tcp-port> argument in EPSV response requires translation only in the
+ case of NAPT-PT.
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 15]
+
+RFC 2766 NAT-PT February 2000
+
+
+6.2 Payload modifications for V6 originated FTP sessions
+
+ If a V6 host originates the FTP session, however, the FTP-ALG has two
+ approaches to pursue. In the first approach, the FTP-ALG will leave
+ the command strings "EPRT" and "EPSV" unaltered and simply translate
+ the <net-prt>, <net-addr> and <tcp-port> arguments from V6 to its
+ NAT-PT (or NAPT-PT) assigned V4 information. <tcp-port> is translated
+ only in the case of NAPT-PT. Same goes for EPSV response from V4
+ node. This is the approach we recommend to ensure forward support for
+ RFC 2428. However, with this approach, the V4 hosts are mandated to
+ have their FTP application upgraded to support EPRT and EPSV
+ extensions to allow access to V4 and V6 hosts, alike.
+
+ In the second approach, the FTP-ALG will translate the command
+ strings "EPRT" and "EPSV" and their parameters from the V6 node into
+ their equivalent NAT-PT assigned V4 node info and attach to "PORT"
+ and "PASV" commands prior to forwarding to V4 node. Likewise, PASV
+ response from V4 nodes is translated into EPSV response prior to
+ forwarding to the target V6 nodes. However, the FTP-ALG would be
+ unable to translate the command "EPSV<space>ALL" issued by V6 nodes.
+ In such a case, the V4 host, which receives the command, may return
+ an error code indicating unsupported function. This error response
+ may cause many RFC 2428 compliant FTP applications to simply fail,
+ because EPSV support is mandated by RFC 2428. The benefit of this
+ approach, however, is that is does not impose any FTP upgrade
+ requirements on V4 hosts.
+
+6.3 Header updates for FTP control packets
+
+ All the payload translations considered in the previous sections are
+ based on ASCII encoded data. As a result, these translations may
+ result in a change in the size of packet.
+
+ If the new size is the same as the previous, only the TCP checksum
+ needs adjustment as a result of the payload translation. If the new
+ size is different from the previous, TCP sequence numbers should also
+ be changed to reflect the change in the length of the FTP control
+ session payload. The IP packet length field in the V4 header or the
+ IP payload length field in the V6 header should also be changed to
+ reflect the new payload size. A table is used by the FTP-ALG to
+ correct the TCP sequence and acknowledgement numbers in the TCP
+ header for control packets in both directions.
+
+ The table entries should have the source address, source data port,
+ destination address and destination data port for V4 and V6 portions
+ of the session, sequence number delta for outbound control packets
+ and sequence number delta for inbound control packets.
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 16]
+
+RFC 2766 NAT-PT February 2000
+
+
+ The sequence number for an outbound control packet is increased by
+ the outbound sequence number delta, and the acknowledgement number
+ for the same outbound packet is decreased by the inbound sequence
+ number delta. Likewise, the sequence number for an inbound packet is
+ increased by the inbound sequence number delta and the
+ acknowledgement number for the same inbound packet is decreased by
+ the outbound sequence number delta.
+
+7. NAT-PT Limitations and Future Work
+
+ All limitations associated to NAT [NAT-TERM] are also associated to
+ NAT-PT. Here are the most important of them in detail, as well as
+ some unique to NAT-PT.
+
+7.1 Topology limitations
+
+ There are limitations to using the NAT-PT translation method. It is
+ mandatory that all requests and responses pertaining to a session be
+ routed via the same NAT-PT router. One way to guarantee this would be
+ to have NAT-PT based on a border router that is unique to a stub
+ domain, where all IP packets are either originated from the domain or
+ destined to the domain. This is a generic problem with NAT and it is
+ fully described in [NAT-TERM].
+
+ Note, this limitation does not apply to packets originating from or
+ directed to dual-stack nodes that do not require packet translation.
+ This is because in a dual-stack set-up, IPv4 addresses implied in a
+ V6 address can be identified from the address format PREFIX::x.y.z.w
+ and a dual-stack router can accordingly route a packet between v4 and
+ dual-stack nodes without tracking state information.
+
+ This should also not affect IPv6 to IPv6 communication and in fact
+ only actually use translation when no other means of communication is
+ possible. For example NAT-PT may also have a native IPv6 connection
+ and/or some kind of tunneled IPv6 connection. Both of the above
+ connections should be preferred over translation when possible. The
+ above makes sure that NAT-PT is a tool only to be used to assist
+ transition to native IPv6 to IPv6 communication.
+
+7.2 Protocol Translation Limitations
+
+ A number of IPv4 fields have changed meaning in IPv6 and translation
+ is not straightforward. For example, the option headers semantics and
+ syntax have changed significantly in IPv6. Details of IPv4 to IPv6
+ Protocol Translation can be found in [SIIT].
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 17]
+
+RFC 2766 NAT-PT February 2000
+
+
+7.3 Impact of Address Translation
+
+ Since NAT-PT performs address translation, applications that carry
+ the IP address in the higher layers will not work. In this case
+ Application Layer Gateways (ALG) need to be incorporated to provide
+ support for those applications. This is a generic problem with NAT
+ and it is fully described in [NAT-TERM].
+
+7.4 Lack of end-to-end security
+
+ One of the most important limitations of the NAT-PT proposal is the
+ fact that end-to-end network layer security is not possible. Also
+ transport and application layer security may not be possible for
+ applications that carry IP addresses to the application layer. This
+ is an inherent limitation of the Network Address Translation
+ function.
+
+ Independent of NAT-PT, end-to-end IPSec security is not possible
+ across different address realms. The two end-nodes that seek IPSec
+ network level security must both support one of IPv4 or IPv6.
+
+7.5 DNS Translation and DNSSEC
+
+ The scheme described in section 4.2 involves translation of DNS
+ messages. It is clear that this scheme can not be deployed in
+ combination with secure DNS. I.e., an authoritative DNS name server
+ in the V6 domain cannot sign replies to queries that originate from
+ the V4 world. As a result, an V4 end-node that demands DNS replies
+ to be signed will reject replies that have been tampered with by
+ NAT-PT.
+
+ The good news, however, is that only servers in V6 domain that need
+ to be accessible from the V4 world pay the price for the above
+ limitation, as V4 end-nodes may not access V6 servers due to DNS
+ replies not being signed.
+
+ Also note that zone transfers between DNS-SEC servers within the same
+ V6 network are not impacted.
+
+ Clearly, with DNS SEC deployment in DNS servers and end-host
+ resolvers, the scheme suggested in this document would not work.
+
+8. Applicability Statement
+
+ NAT-PT can be a valuable transition tool at the border of a stub
+ network that has been deployed as an IPv6 only network when it is
+ connected to an Internet that is either V4-only or a combination of
+ V4 and V6.
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 18]
+
+RFC 2766 NAT-PT February 2000
+
+
+ NAT-PT, in its simplest form, without the support of DNS-ALG,
+ provides one way connectivity between an IPv6 stub domain and the
+ IPv4 world meaning that only sessions initialised by IPv6 nodes
+ internal to the IPv6 stub domain can be translated, while sessions
+ initiated by IPv4 nodes are dropped. This makes NAT-PT a useful
+ tool to IPv6 only stub networks that need to be able to maintain
+ connectivity with the IPv4 world without the need to deploy servers
+ visible to the IPv4 world.
+
+ NAT-PT combined with a DNS-ALG provides bi-directional connectivity
+ between the IPv6 stub domain and the IPv4 world allowing sessions to
+ be initialised by IPv4 nodes outside the IPv6 stub domain. This
+ makes NAT-PT useful for IPv6 only stub networks that need to deploy
+ servers visible to the IPv4 world.
+
+ Some applications count on a certain degree of address stability for
+ their operation. Dynamic address reuse by NAT-PT might not be
+ agreeable for these applications. For hosts running such address
+ critical applications, NAT-PT may be configured to provide static
+ address mapping between the host's V6 address and a specific V4
+ address. This will ensure that address related changes by NAT-PT do
+ not become a significant source of operational failure.
+
+9. Security Considerations
+
+ Section 7.4 of this document states that end-to-end network and
+ transport layer security are not possible when a session is
+ intercepted by a NAT-PT. Also application layer security may not be
+ possible for applications that carry IP addresses in the application
+ layer.
+
+ Section 7.5 of this document states that the DNS-ALG can not be
+ deployed in combination with secure DNS.
+
+ Finally, all of the security considerations described in [NAT-TERM]
+ are applicable to this document as well.
+
+10. REFERENCES
+
+ [DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
+ Heffernan, "DNS extensions to Network Address Translators
+ (DNS_ALG)", RFC 2694, September 1999.
+
+ [DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2065, March 1999.
+
+ [FTP-IPV6] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for
+ IPv6 and NATs", RFC 2428, September 1998.
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 19]
+
+RFC 2766 NAT-PT February 2000
+
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [NAT] Egevang, K. and P. Francis, "The IP Network Address
+ Translator (NAT)", RFC 1631, May 1994.
+
+ [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations", RFC
+ 2663, August 1999.
+
+ [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC
+ 2765, February 2000.
+
+ [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+ IPv6 Hosts and Routers", RFC 1933, April 1996.
+
+ [V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+Authors' Addresses
+
+ George Tsirtsis
+ Internet Futures
+ B29 Room 129
+ BT Adastral Park
+ IPSWICH IP5 3RE
+ England
+
+ Phone: +44 181 8260073
+ Fax: +44 181 8260073
+ EMail: george.tsirtsis@bt.com
+ EMail (alternative): gtsirt@hotmail.com
+
+
+ Pyda Srisuresh
+ 630 Alder Drive
+ Milpitas, CA 95035
+ U.S.A.
+
+ Phone: (408) 519-3849
+ EMail: srisuresh@yahoo.com
+
+
+
+
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 20]
+
+RFC 2766 NAT-PT February 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsirtsis & Srisuresh Standards Track [Page 21]
+
diff --git a/Documentation/en/rfc/rfc2772.txt b/Documentation/en/rfc/rfc2772.txt
new file mode 100644
index 00000000..78e84ecb
--- /dev/null
+++ b/Documentation/en/rfc/rfc2772.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group R. Rockell
+Request for Comments: 2772 Sprint
+Obsoletes: 2546 R. Fink
+Category: Informational ESnet
+ February 2000
+
+
+ 6Bone Backbone Routing Guidelines
+
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ The 6Bone is an Ipv6 testbed to assist in the evolution and
+ deployment of IPv6. Because of this, it is important that the core
+ backbone of the IPv6 network maintain stability, and that all
+ operators have a common set of rules and guidelines by which to
+ deploy IPv6 routing equipment.
+
+ This document provides a set of guidelines for all 6bone routing
+ equipment operators to use as a reference for efficient and stable
+ deployment of 6bone routing systems. As the complexity of the 6Bone
+ grows,the adherence to a common set of rules becomes increasingly
+ important in order for an efficient, scalable backbone to exist.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rockell & Fink Informational [Page 1]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+Table of Contents
+
+ 1. Introduction.................................................. 2
+ 2. Scope of this document........................................ 3
+ 3. Common Rules for the 6bone.................................... 3
+ 3.1 Link-local prefixes...................................... 3
+ 3.2 Site-local prefixes...................................... 4
+ 3.3 Loopback and unspecified prefixes........................ 5
+ 3.4 Multicast prefixes....................................... 5
+ 3.5 IPv4 compatible prefixes................................. 5
+ 3.6 IPv4-mapped prefixes..................................... 6
+ 3.7 Default routes........................................... 6
+ 3.8 Yet undefined unicast prefixes........................... 6
+ 3.9 Inter-site links......................................... 6
+ 3.10 6to4 Prefixes........................................... 7
+ 3.11 Aggregation & advertisement issues...................... 7
+ 4. Routing Policies for the 6bone................................ 7
+ 5. The 6Bone Registry............................................ 8
+ 6. Guidelines for new sites joining the 6Bone.................... 9
+ 7. Guidelines for 6Bone pTLA sites............................... 9
+ 8. 6Bone Operations group........................................ 11
+ 9. Common rules enforcement for the 6bone........................ 11
+ 10. Security Considerations...................................... 12
+ 11. References................................................... 12
+ 12. Authors' Addresses........................................... 13
+ 13. Full Copyright Statement..................................... 14
+
+1. Introduction
+
+ The 6Bone is an IPv6 testbed to assist in the evolution and
+ deployment of IPv6. Because of this, it is important that the core
+ backbone of the IPv6 network maintain stability, and that all
+ operators have a common set of rules and guidelines by which to
+ deploy IPv6 routing equipment.
+
+ This document provides a set of guidelines for all 6bone routing
+ equipment operators to use as a reference for efficient and stable
+ deployment of 6bone routing systems. As the complexity of the 6Bone
+ grows,the adherence to a common set of rules becomes increasingly
+ important in order for an efficient, scalable backbone to exist.
+
+ This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as
+ defined [RFC 2283], commonly referred to as BGP4+, as the currently
+ accepted EGP.
+
+ 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].
+
+
+
+Rockell & Fink Informational [Page 2]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+2. Scope of this document
+
+ This document is a best-practices Informational document aimed at
+ IPv6 entities which operate under the 6Bone IPv6 testbed TLA
+ allocation.
+
+3. Common Rules for the 6bone
+
+ This section details common rules governing the routing of the 6Bone.
+ They are derived from the issues encountered on the 6Bone, with
+ respect to the routes advertised, handling of special addresses, and
+ aggregation:
+
+ 1) link local prefixes
+
+ 2) site local prefixes
+
+ 3) loopback and unspecified prefixes
+
+ 4) multicast prefixes
+
+ 5) IPv4-compatible prefixes
+
+ 6) IPv4-mapped prefixes
+
+ 7) default routes
+
+ 8) yet undefined unicast prefixes (from a different /3 prefix)
+
+ 9) inter-site links issues
+
+ 10) 6to4 prefixes
+
+ 11) aggregation & advertisement issues
+
+3.1 Link-local prefixes
+
+ This link-local prefix (FE80::/10) MUST NOT be advertised through
+ either an IGP or an EGP. Under no circumstance should this prefix be
+ seen in the 6Bone backbone routing table.
+
+ By definition, the link-local prefix has a scope limited to a
+ specific link. Since the prefix is the same on all IPv6 links,
+ advertising it in any routing protocol does not make sense and,
+ worse, may introduce nasty error conditions.
+
+ Well known cases where link-local prefixes could be advertised by
+ mistake include, but are not limited to:
+
+
+
+Rockell & Fink Informational [Page 3]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+ - a router advertising all directly connected network prefixes
+ including the link-local one
+
+ - subnetting of the link-local prefix
+
+ In such cases, vendors should be urged to correct their code. While
+ vendors should be encouraged to fix the problem, the ultimate
+ responsibility lies on the operator of that IPv6 site to correct the
+ problem through whatever means necessary.
+
+ Should a pTLA discover link-local prefixes coming from another pTLA,
+ it is the responsibility of the pTLA leaking the routes to filter
+ these, and correct the problem in a timely fashion. Should a pTLA
+ discover that a downstream of that pTLA is leaking link-local
+ prefixes, it is the pTLA's responsibility to ensure that these
+ prefixes are not leaked to other pTLA's, or to other downstreams of
+ that pTLA.
+
+ Failure to filter such routes in a timely fashion may result in the
+ manual shutting down of BGP4+ sessions to that pTLA, from other
+ pTLA's.
+
+ (Also, it is each pTLA, pNLA, and end-site's responsibility to not
+ only filter their own BGP4+ sessions appropriately to peers, but to
+ filter routes coming from peers as well, and to only allow those
+ routes that fit the aggregation model, and do not cause operational
+ problems).
+
+3.2 Site-local prefixes
+
+ Site local prefixes (in the FEC0::/10 range) MAY be advertised by
+ IGP's or EGP's within a site. The precise definition of a site is
+ ongoing work of the IPng working group, but should generally include
+ a group of nodes that are operating under one administrator or group
+ of administrators, or a group of nodes which are used for a common
+ purpose.
+
+ Site-local prefixes MUST NOT be advertised across transit pNLAs,
+ pTLAs, or leaf-sites.
+
+ Again, should site-local prefixes be leaked outside of a given site,
+ it is the responsibility of the site to fix the problem in a timely
+ manner, either through filters, or via other means which remove the
+ operational impact that those prefixes had on the peering sites
+ involved. However, every site SHOULD filter not only outbound on
+ their EGP, but also inbound, in order to ensure proper routing
+ announcements are not only sent, but also received.
+
+
+
+
+Rockell & Fink Informational [Page 4]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+3.3 Loopback and unspecified prefixes
+
+ The loopback prefix (::1/128) and the unspecified prefix (::0/128)
+ MUST NOT be advertised by any routing protocol.
+
+ The same responsibility lies with the party guilty of advertising the
+ loopback or unspecified prefix as in Section 3.1 and 3.2.
+
+3.4 Multicast prefixes
+
+ Multicast prefixes MUST NOT be advertised by any unicast routing
+ protocol. Multicast routing protocols are designed to respect the
+ semantics of multicast and MUST therefore be used to route packets
+ with multicast destination addresses (in the range of FF00::/8).
+
+ Multicast address scopes MUST be respected on the 6Bone. Only global
+ scope multicast addresses MAY be routed across transit pNLAs and
+ pTLAs. There is no requirement on a pTLA to route multicast packets
+ at the time of the writing of this memo.
+
+ Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges)
+ MAY be routed across a pNLA to its leaf sites.
+
+ Site-local multicasts MUST NOT be routed toward transit pNLAs or
+ pTLAs.
+
+ Link-local multicasts and node-local multicasts MUST NOT be routed at
+ all.
+
+3.5 IPv4 compatible prefixes
+
+ Sites may choose to use IPv4 compatible addresses (::a.b.c.d where
+ a.b.c.d represents the octets of an IPv4 address) internally. As
+ there is no real rationale today for doing so, these address SHOULD
+ NOT be used or routed in the 6Bone.
+
+ The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
+
+ IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit
+ pNLAs or pTLAs.
+
+ Should ::/96 IPv4-compatible prefixes be leaked into an EGP, it is
+ the responsibility of the party who is advertising the route to fix
+ the problem, either through proper filters, or through other means,
+ while it remains in the best interest of all particiapants of the
+ 6Bone to filter both outbound and inbound at their IGP borders.
+
+
+
+
+
+Rockell & Fink Informational [Page 5]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+3.6 IPv4-mapped prefixes
+
+ IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d represents the
+ octets of an IPv4 address) MAY be advertised by IGPs within a site.
+ It may be useful for some IPv6 only nodes within a site to have such
+ a route pointing to a translation device, to aid in deployment of
+ IPv6.
+
+ IPv4-mapped prefixes MUST NOT be advertised by EGPs.
+
+3.7 Default routes
+
+ 6Bone core pTLA routers MUST be default-free.
+
+ pTLAs MAY advertise a default route to any downstream peer (non-pTLA
+ site). Transit pNLAs MAY advertise a default route to any of their
+ downstreams (other transit pNLA or leaf site).
+
+ Should a default route be redistributed into an EGP and found on any
+ pTLA EGP sessions, it is the responsibility of the pTLA to fix this
+ problem immediately upon realization of the route's existence, and
+ the responsibility of the guilty pTLA to push the entity from which
+ the default route was originated, should the default route have
+ originated from downstream of a pTLA.
+
+3.8 Yet undefined unicast prefixes
+
+ Yet undefined unicast prefixes from a format prefix other than
+ 2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone.
+ In particular, RFC 2471 test addresses MUST NOT be advertised on the
+ 6Bone.
+
+ Routing of global unicast prefixes outside the 6Bone range
+ (3ffe::/16), and routing of global unicast prefixes yet undelegated
+ in the range (3ffe::/16) are discussed in section 4, Routing
+ policies, below.
+
+3.9 Inter-site links
+
+ Global IPv6 addresses must be used for the end points of inter-site
+ links. In particular, IPv4 compatible addresses MUST NOT be used for
+ tunnels.
+
+ Sites MAY use Other addressing schemes for Inter-site links, but
+ these addresses MUST NOT be advertised into the IPv6 global routing
+ table.
+
+
+
+
+
+Rockell & Fink Informational [Page 6]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+ Prefixes for inter-site links MUST NOT be injected in the global
+ routing tables.
+
+3.10 6to4 Prefixes
+
+ The 6to4 prefix, or some portion thereof, MAY be announced by any
+ pTLA which has a current implementation of 6to4 in their IPv6
+ network. However, as 6to4 implementors gain more operational
+ experience, it MAY be necessary to change this in some way. At the
+ time of the writing of this docuement, any pTLA MAY announce the 6to4
+ prefix into global EBGP. However, in order to announce this block,
+ the pTLA MUST have a 6to4 router active, sourcing this prefix
+ announcement.
+
+ This section subject to change, and MAY vary, depending on 6to4
+ progress within the NGTRANS working group.
+
+3.11 Aggregation & advertisement issues
+
+ Route aggregation MUST be performed by any border router talking EGP
+ with any other IPv6 sites. More-specifics MUST NOT be leaked into or
+ across the IPv6 6Bone backbone.
+
+4. Routing Policies for the 6bone
+
+ Leaf sites or pNLAs MUST only advertise to an upstream provider the
+ prefixes assigned by that provider. Advertising a prefix assigned by
+ another provider to a provider is not acceptable, and breaks the
+ aggregation model. A site MUST NOT advertise a prefix from another
+ provider to a provider as a way around the multi-homing problem.
+ However, in the interest of testing new solutions, one may break this
+ policy, so long as ALL affected parties are aware of this test, and
+ all agree to support this testing. These policy breaks MUST NOT
+ affect the 6bone routing table globally.
+
+ To clarify, if one has two upstream pNLA or pTLA providers, (A and B
+ for this example), one MUST only announce the prefix delegated to one
+ by provider A to provider A, and one MUST only announce the prefeix
+ delegated by one from provider B upstream to provider B. There exists
+ no circumstance where this should be violated, as it breaks the
+ aggregation model, and could globally affect routing decisions if
+ downstreams are able to leak other providers' more specific
+ delegations up to a pTLA. As the IPNG working group works through the
+ multi-homing problem, there may be a need to alter this rule
+ slightly, to test new strategies for deployment. However, in the case
+ of current specifications at the time of this writing, there is no
+ reason to advertise more specifics, and pTLA's MUST adhere to the
+ current aggregation model.
+
+
+
+Rockell & Fink Informational [Page 7]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+ Site border routers for pNLA or leaf sites MUST NOT advertise
+ prefixes more specific (longer) than the prefix that was allocated by
+ their upstream provider.
+
+ All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA
+ delegation (currently /24 or /28) to other 6bone pTLAs unless special
+ peering arrangements are implemented. When such special peering
+ aggreements are in place between any two or more 6bone pTLAs, care
+ MUST be taken not to leak the more specifics to other 6bone pTLAs not
+ participating in the peering aggreement. 6bone pTLAs which have such
+ agreements in place MUST NOT advertise other 6bone pTLA more
+ specifics to downstream 6bone pNLAs or leaf sites, as this will break
+ the best-path routing decision.
+
+ The peering agreements across the 6Bone may be by nature non-
+ commercial, and therefore MAY allow transit traffic, if peering
+ agreements of this nature are made. However, no pTLA is REQUIRED to
+ give or receive transit service from another pTLA.
+
+ Eventually, the Internet registries will assign prefixes under other
+ than the 6Bone TLA (3FFE::/16). As of the time this document was
+ written in 1999, the Internet registries were starting to assign /35
+ sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly
+ be used in the future.
+
+ The organizations receiving prefixes under these newer TLAs would be
+ expected to want to establish peering and connectivity relationships
+ with other IPv6 networks, both in the newer TLA space and in the
+ 6bone pTLA space. Peering between new TLA's and the current 6Bone
+ pTLA's MAY occur, and details such as transit, and what routes are
+ received by each, are outside of general peering rules as stated in
+ this memo, and are left up to the members of those TLA's and pTLA's
+ that are establishing said peerings. However, it is expected that
+ most of the rules discussed here are equally applicable to new TLAs.
+
+5. The 6Bone Registry
+
+ The 6Bone registry is a RIPE-181 database with IPv6 extensions used
+ to store information about the 6Bone, and its sites. The 6bone is
+ accessible at:
+
+ <http://www.6bone.net/whois.html>)
+
+ Each 6Bone site MUST maintain the relevant entries in the 6Bone
+ registry. In particular, the following object MUST be present for all
+ 6Bone leaf sites, pNLAs and pTLAs:
+
+
+
+
+
+Rockell & Fink Informational [Page 8]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+ - IPv6-site: site description
+
+ - Inet6num: prefix delegation (one record MUST exist for each
+ delegation)
+
+ - Mntner: contact info for site maintance/administration staff.
+
+ Other object MAY be maintained at the discretion of the sites such as
+ routing policy descriptors, person, or role objects. The Mntner
+ object MUST make reference to a role or person object, but those MAY
+ NOT necessarily reside in the 6Bone registry. They can be stored
+ within any of the Internet registry databases (ARIN, APNIC, RIPE-NCC,
+ etc.)
+
+6. Guidelines for new sites joining the 6Bone
+
+ New sites joining the 6Bone should seek to connect to a transit pNLA
+ or a pTLA within their region, and preferably as close as possible to
+ their existing IPv4 physical and routing path for Internet service.
+ The 6Bone web site at <http://www.6bone.net> has various information
+ and tools to help find candidate 6bone networks.
+
+ Any site connected to the 6Bone MUST maintain a DNS server for
+ forward name lookups and reverse address lookups. The joining site
+ MUST maintain the 6Bone objects relative to its site, as describe in
+ section 5.
+
+ The upstream provider MUST delegate the reverse address translation
+ zone in DNS to the joining site, or have an agreement in place to
+ perform primary DNS for that downstream. The provider MUST also
+ create the 6Bone registry inet6num object reflecting the delegated
+ address space.
+
+ Up to date informatino about how to join the 6Bone is available on
+ the 6Bone Web site at <http://www.6bone.net>.
+
+7. Guidelines for 6Bone pTLA sites
+
+ The following rules apply to qualify for a 6Bone pTLA allocation. It
+ should be recognized that holders of 6Bone pTLA allocations are
+ expected to provide production quality backbone network services for
+ the 6Bone.
+
+ 1. The pTLA Applicant must have a minimum of three (3) months
+ qualifying experience as a 6Bone end-site or pNLA transit. During
+ the entire qualifying period the Applicant must be operationally
+ providing the following:
+
+
+
+
+Rockell & Fink Informational [Page 9]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+ a. Fully maintained, up to date, 6Bone Registry entries for their
+ ipv6-site inet6num, mntner, and person objects, including each
+ tunnel that the Applicant has.
+
+ b. Fully maintained, and reliable, BGP4+ peering and connectivity
+ between the Applicant's boundary router and the appropriate
+ connection point into the 6Bone. This router must be IPv6
+ pingable. This criteria is judged by members of the 6Bone
+ Operations Group at the time of the Applicant's pTLA request.
+
+ c. Fully maintained DNS forward (AAAA) and reverse (ip6.int)
+ entries for the Applicant's router(s) and at least one host
+ system.
+
+ d. A fully maintained, and reliable, IPv6-accessible system
+ providing, at a mimimum, one or more web pages, describing the
+ Applicant's IPv6 services. This server must be IPv6 pingable.
+
+ 2. The pTLA Applicant MUST have the ability and intent to provide
+ "production-quality" 6Bone backbone service. Applicants must
+ provide a statement and information in support of this claim.
+ This MUST include the following:
+
+ a. A support staff of two persons minimum, three preferable, with
+ person attributes registered for each in the ipv6-site object
+ for the pTLA applicant.
+
+ b. A common mailbox for support contact purposes that all support
+ staff have acess to, pointed to with a notify attribute in the
+ ipv6-site object for the pTLA Applicant.
+
+ 3. The pTLA Applicant MUST have a potential "user community" that
+ would be served by its becoming a pTLA, e.g., the Applicant is a
+ major provider of Internet service in a region, country, or focus
+ of interest. Applicant must provide a statement and information in
+ support this claim.
+
+ 4. The pTLA Applicant MUST commit to abide by the current 6Bone
+ operational rules and policies as they exist at time of its
+ application, and agree to abide by future 6Bone backbone
+ operational rules and policies as they evolve by consensus of the
+ 6Bone backbone and user community.
+
+ When an Applicant seeks to receive a pTLA allocation, it will apply
+ to the 6Bone Operations Group (see section 8 below) by providing to
+ the Group information in support of its claims that it meets the
+ criteria above.
+
+
+
+
+Rockell & Fink Informational [Page 10]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+8. 6Bone Operations Group
+
+ The 6Bone Operations Group is the group in charge of monitoring and
+ policing adherence to the current rules. Membership in the 6Bone
+ Operations Group is mandatory for, and restricted to, sites connected
+ to the 6Bone.
+
+ The 6Bone Operations Group is currently defined by those members of
+ the existing 6Bone mailing list who represent sites participating in
+ the 6Bone. Therefore it is incumbent on relevant site contacts to
+ join the 6Bone mailing list. Instructions on how to join the list are
+ maintained on the 6Bone web site at < http://www.6bone.net>.
+
+9. Common rules enforcement for the 6bone
+
+ Participation in the 6Bone is a voluntary and benevolent undertaking.
+ However, participating sites are expected to adhere to the rules and
+ policies described in this document in order to maintain the 6Bone as
+ a quality tool for the deployment of, and transition to, IPv6
+ protocols and the products implementing them.
+
+ The following is in support of policing adherence to 6Bone rules and
+ policies:
+
+ 1. Each pTLA site has committed to implement the 6Bone's rules and
+ policies, and SHOULD try to ensure they are adhered to by sites
+ within their administrative control, i.e. those to who prefixes
+ under their respective pTLA prefix have been delegated.
+
+ 2. When a site detects an issue, it SHOULD first use the 6Bone
+ registry to contact the site maintainer and work the issue.
+
+ 3. If nothing happens, or there is disagreement on what the right
+ solution is, the issue SHOULD be brought to the 6Bone Operations
+ Group.
+
+ 4. When the problem is related to a product issue, the site(s)
+ involved SHOULD be responsible for contacting the product vendor
+ and work toward its resolution.
+
+ 5. When an issue causes major operational problems, backbone sites
+ SHOULD decide to temporarily set filters in order to restore
+ service.
+
+
+
+
+
+
+
+
+Rockell & Fink Informational [Page 11]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+10. Security Considerations
+
+ The result of incorrect entries in routing tables is usually
+ unreachable sites. Having guidelines to aggregate or reject routes
+ will clean up the routing tables. It is expected that using these
+ rules and policies, routing on the 6Bone will be less sensitive to
+ denial of service attacks due to misleading routes.
+
+ The 6Bone is an IPv6 testbed to assist in the evolution and
+ deployment of IPv6. Therefore, denial of service or packet disclosure
+ are to be expected. However, it is the pTLA from where the attack
+ originated who has ultimate responsibility for isolating and fixing
+ problems of this nature. It is also every 6Bone site's responsibility
+ to safely introduce new test systems into the 6Bone, by placing them
+ at a strategically safe places which will have minimal impact on
+ other 6Bone sites, should bugs or misconfigurations occur.
+
+11. References
+
+ [RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [RFC 2471] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address
+ Allocation", RFC 2471, December 1998.
+
+ [RFC 2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC
+ 2546, March 1999
+
+ [RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
+ January 1997.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
+ "Multiprotocol Extensions for BGP-4", RFC 2283, March
+ 1998.
+
+ [RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J.,
+ Karrenberg, D., Terpstra, M. and J. Yu, Representation
+ of IP Routing Policies in a Routing Registry. Technical
+ Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands,
+ October 1994.
+
+
+
+
+
+
+
+
+Rockell & Fink Informational [Page 12]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+12. Authors' Addresses
+
+ Rob Rockell
+ EMail: rrockell@sprint.net
+
+
+ Bob Fink
+ EMail: fink@es.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rockell & Fink Informational [Page 13]
+
+RFC 2772 6Bone Backbone Routing Guidelines February 2000
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rockell & Fink Informational [Page 14]
+
diff --git a/Documentation/en/rfc/rfc2874.txt b/Documentation/en/rfc/rfc2874.txt
new file mode 100644
index 00000000..915c104a
--- /dev/null
+++ b/Documentation/en/rfc/rfc2874.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group M. Crawford
+Request for Comments: 2874 Fermilab
+Category: Standards Track C. Huitema
+ Microsoft Corporation
+ July 2000
+
+
+ DNS Extensions to Support IPv6 Address Aggregation and Renumbering
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document defines changes to the Domain Name System to support
+ renumberable and aggregatable IPv6 addressing. The changes include a
+ new resource record type to store an IPv6 address in a manner which
+ expedites network renumbering and updated definitions of existing
+ query types that return Internet addresses as part of additional
+ section processing.
+
+ For lookups keyed on IPv6 addresses (often called reverse lookups),
+ this document defines a new zone structure which allows a zone to be
+ used without modification for parallel copies of an address space (as
+ for a multihomed provider or site) and across network renumbering
+ events.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al. Standards Track [Page 1]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+Table of Contents
+
+ 1. Introduction ............................................... 2
+ 2. Overview ................................................... 3
+ 2.1. Name-to-Address Lookup ............................... 4
+ 2.2. Underlying Mechanisms for Reverse Lookups ............ 4
+ 2.2.1. Delegation on Arbitrary Boundaries ............. 4
+ 2.2.2. Reusable Zones ................................. 5
+ 3. Specifications ............................................. 5
+ 3.1. The A6 Record Type ................................... 5
+ 3.1.1. Format ......................................... 6
+ 3.1.2. Processing ..................................... 6
+ 3.1.3. Textual Representation ......................... 7
+ 3.1.4. Name Resolution Procedure ...................... 7
+ 3.2. Zone Structure for Reverse Lookups ................... 7
+ 4. Modifications to Existing Query Types ...................... 8
+ 5. Usage Illustrations ........................................ 8
+ 5.1. A6 Record Chains ..................................... 9
+ 5.1.1. Authoritative Data ............................. 9
+ 5.1.2. Glue ........................................... 10
+ 5.1.3. Variations ..................................... 12
+ 5.2. Reverse Mapping Zones ................................ 13
+ 5.2.1. The TLA level .................................. 13
+ 5.2.2. The ISP level .................................. 13
+ 5.2.3. The Site Level ................................. 13
+ 5.3. Lookups .............................................. 14
+ 5.4. Operational Note ..................................... 15
+ 6. Transition from RFC 1886 and Deployment Notes .............. 15
+ 6.1. Transition from AAAA and Coexistence with A Records .. 16
+ 6.2. Transition from Nibble Labels to Binary Labels ....... 17
+ 7. Security Considerations .................................... 17
+ 8. IANA Considerations ........................................ 17
+ 9. Acknowledgments ............................................ 18
+ 10. References ................................................ 18
+ 11. Authors' Addresses ........................................ 19
+ 12. Full Copyright Statement .................................. 20
+
+1. Introduction
+
+ Maintenance of address information in the DNS is one of several
+ obstacles which have prevented site and provider renumbering from
+ being feasible in IP version 4. Arguments about the importance of
+ network renumbering for the preservation of a stable routing system
+ and for other purposes may be read in [RENUM1, RENUM2, RENUM3]. To
+ support the storage of IPv6 addresses without impeding renumbering we
+ define the following extensions.
+
+
+
+
+
+Crawford, et al. Standards Track [Page 2]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ o A new resource record type, "A6", is defined to map a domain name
+ to an IPv6 address, with a provision for indirection for leading
+ "prefix" bits.
+
+ o Existing queries that perform additional section processing to
+ locate IPv4 addresses are redefined to do that processing for both
+ IPv4 and IPv6 addresses.
+
+ o A new domain, IP6.ARPA, is defined to support lookups based on
+ IPv6 address.
+
+ o A new prefix-delegation method is defined, relying on new DNS
+ features [BITLBL, DNAME].
+
+ The changes are designed to be compatible with existing application
+ programming interfaces. The existing support for IPv4 addresses is
+ retained. Transition issues related to the coexistence of both IPv4
+ and IPv6 addresses in DNS are discussed in [TRANS].
+
+ This memo proposes a replacement for the specification in RFC 1886
+ [AAAA] and a departure from current implementation practices. The
+ changes are designed to facilitate network renumbering and
+ multihoming. Domains employing the A6 record for IPv6 addresses can
+ insert automatically-generated AAAA records in zone files to ease
+ transition. It is expected that after a reasonable period, RFC 1886
+ will become Historic.
+
+ The next three major sections of this document are an overview of the
+ facilities defined or employed by this specification, the
+ specification itself, and examples of use.
+
+ 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 [KWORD]. The key word
+ "SUGGESTED" signifies a strength between MAY and SHOULD: it is
+ believed that compliance with the suggestion has tangible benefits in
+ most instances.
+
+2. Overview
+
+ This section provides an overview of the DNS facilities for storage
+ of IPv6 addresses and for lookups based on IPv6 address, including
+ those defined here and elsewhere.
+
+
+
+
+
+
+
+
+Crawford, et al. Standards Track [Page 3]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+2.1. Name-to-Address Lookup
+
+ IPv6 addresses are stored in one or more A6 resource records. A
+ single A6 record may include a complete IPv6 address, or a contiguous
+ portion of an address and information leading to one or more
+ prefixes. Prefix information comprises a prefix length and a DNS
+ name which is in turn the owner of one or more A6 records defining
+ the prefix or prefixes which are needed to form one or more complete
+ IPv6 addresses. When the prefix length is zero, no DNS name is
+ present and all the leading bits of the address are significant.
+ There may be multiple levels of indirection and the existence of
+ multiple A6 records at any level multiplies the number of IPv6
+ addresses which are formed.
+
+ An application looking up an IPv6 address will generally cause the
+ DNS resolver to access several A6 records, and multiple IPv6
+ addresses may be returned even if the queried name was the owner of
+ only one A6 record. The authenticity of the returned address(es)
+ cannot be directly verified by DNS Security [DNSSEC]. The A6 records
+ which contributed to the address(es) may of course be verified if
+ signed.
+
+ Implementers are reminded of the necessity to limit the amount of
+ work a resolver will perform in response to a client request. This
+ principle MUST be extended to also limit the generation of DNS
+ requests in response to one name-to-address (or address-to-name)
+ lookup request.
+
+2.2. Underlying Mechanisms for Reverse Lookups
+
+ This section describes the new DNS features which this document
+ exploits. This section is an overview, not a specification of those
+ features. The reader is directed to the referenced documents for
+ more details on each.
+
+2.2.1. Delegation on Arbitrary Boundaries
+
+ This new scheme for reverse lookups relies on a new type of DNS label
+ called the "bit-string label" [BITLBL]. This label compactly
+ represents an arbitrary string of bits which is treated as a
+ hierarchical sequence of one-bit domain labels. Resource records can
+ thereby be stored at arbitrary bit-boundaries.
+
+ Examples in section 5 will employ the following textual
+ representation for bit-string labels, which is a subset of the syntax
+ defined in [BITLBL]. A base indicator "x" for hexadecimal and a
+ sequence of hexadecimal digits is enclosed between "\[" and "]". The
+ bits denoted by the digits represent a sequence of one-bit domain
+
+
+
+Crawford, et al. Standards Track [Page 4]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ labels ordered from most to least significant. (This is the opposite
+ of the order they would appear if listed one bit at a time, but it
+ appears to be a convenient notation.) The digit string may be
+ followed by a slash ("/") and a decimal count. If omitted, the
+ implicit count is equal to four times the number of hexadecimal
+ digits.
+
+ Consecutive bit-string labels are equivalent (up to the limit imposed
+ by the size of the bit count field) to a single bit-string label
+ containing all the bits of the consecutive labels in the proper
+ order. As an example, either of the following domain names could be
+ used in a QCLASS=IN, QTYPE=PTR query to find the name of the node
+ with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
+
+ \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
+
+ \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
+
+2.2.2. Reusable Zones
+
+ DNS address space delegation is implemented not by zone cuts and NS
+ records, but by a new analogue to the CNAME record, called the DNAME
+ resource record [DNAME]. The DNAME record provides alternate naming
+ to an entire subtree of the domain name space, rather than to a
+ single node. It causes some suffix of a queried name to be
+ substituted with a name from the DNAME record's RDATA.
+
+ For example, a resolver or server providing recursion, while looking
+ up a QNAME a.b.c.d.e.f may encounter a DNAME record
+
+ d.e.f. DNAME w.xy.
+
+ which will cause it to look for a.b.c.w.xy.
+
+3. Specifications
+
+3.1. The A6 Record Type
+
+ The A6 record type is specific to the IN (Internet) class and has
+ type number 38 (decimal).
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al. Standards Track [Page 5]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+3.1.1. Format
+
+ The RDATA portion of the A6 record contains two or three fields.
+
+ +-----------+------------------+-------------------+
+ |Prefix len.| Address suffix | Prefix name |
+ | (1 octet) | (0..16 octets) | (0..255 octets) |
+ +-----------+------------------+-------------------+
+
+ o A prefix length, encoded as an eight-bit unsigned integer with
+ value between 0 and 128 inclusive.
+
+ o An IPv6 address suffix, encoded in network order (high-order octet
+ first). There MUST be exactly enough octets in this field to
+ contain a number of bits equal to 128 minus prefix length, with 0
+ to 7 leading pad bits to make this field an integral number of
+ octets. Pad bits, if present, MUST be set to zero when loading a
+ zone file and ignored (other than for SIG [DNSSEC] verification)
+ on reception.
+
+ o The name of the prefix, encoded as a domain name. By the rules of
+ [DNSIS], this name MUST NOT be compressed.
+
+ The domain name component SHALL NOT be present if the prefix length
+ is zero. The address suffix component SHALL NOT be present if the
+ prefix length is 128.
+
+ It is SUGGESTED that an A6 record intended for use as a prefix for
+ other A6 records have all the insignificant trailing bits in its
+ address suffix field set to zero.
+
+3.1.2. Processing
+
+ A query with QTYPE=A6 causes type A6 and type NS additional section
+ processing for the prefix names, if any, in the RDATA field of the A6
+ records in the answer section. This processing SHOULD be recursively
+ applied to the prefix names of A6 records included as additional
+ data. When space in the reply packet is a limit, inclusion of
+ additional A6 records takes priority over NS records.
+
+ It is an error for an A6 record with prefix length L1 > 0 to refer to
+ a domain name which owns an A6 record with a prefix length L2 > L1.
+ If such a situation is encountered by a resolver, the A6 record with
+ the offending (larger) prefix length MUST be ignored. Robustness
+ precludes signaling an error if addresses can still be formed from
+ valid A6 records, but it is SUGGESTED that zone maintainers from time
+ to time check all the A6 records their zones reference.
+
+
+
+
+Crawford, et al. Standards Track [Page 6]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+3.1.3. Textual Representation
+
+ The textual representation of the RDATA portion of the A6 resource
+ record in a zone file comprises two or three fields separated by
+ whitespace.
+
+ o A prefix length, represented as a decimal number between 0 and 128
+ inclusive,
+
+ o the textual representation of an IPv6 address as defined in
+ [AARCH] (although some leading and/or trailing bits may not be
+ significant),
+
+ o a domain name, if the prefix length is not zero.
+
+ The domain name MUST be absent if the prefix length is zero. The
+ IPv6 address MAY be be absent if the prefix length is 128. A number
+ of leading address bits equal to the prefix length SHOULD be zero,
+ either implicitly (through the :: notation) or explicitly, as
+ specified in section 3.1.1.
+
+3.1.4. Name Resolution Procedure
+
+ To obtain the IPv6 address or addresses which belong to a given name,
+ a DNS client MUST obtain one or more complete chains of A6 records,
+ each chain beginning with a record owned by the given name and
+ including a record owned by the prefix name in that record, and so on
+ recursively, ending with an A6 record with a prefix length of zero.
+ One IPv6 address is formed from one such chain by taking the value of
+ each bit position from the earliest A6 record in the chain which
+ validly covers that position, as indicated by the prefix length. The
+ set of all IPv6 addresses for the given name comprises the addresses
+ formed from all complete chains of A6 records beginning at that name,
+ discarding records which have invalid prefix lengths as defined in
+ section 3.1.2.
+
+ If some A6 queries fail and others succeed, a client might obtain a
+ non-empty but incomplete set of IPv6 addresses for a host. In many
+ situations this may be acceptable. The completeness of a set of A6
+ records may always be determined by inspection.
+
+3.2. Zone Structure for Reverse Lookups
+
+ Very little of the new scheme's data actually appears under IP6.ARPA;
+ only the first level of delegation needs to be under that domain.
+ More levels of delegation could be placed under IP6.ARPA if some
+ top-level delegations were done via NS records instead of DNAME
+ records, but this would incur some cost in renumbering ease at the
+
+
+
+Crawford, et al. Standards Track [Page 7]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ level of TLAs [AGGR]. Therefore, it is declared here that all
+ address space delegations SHOULD be done by the DNAME mechanism
+ rather than NS.
+
+ In addition, since uniformity in deployment will simplify maintenance
+ of address delegations, it is SUGGESTED that address and prefix
+ information be stored immediately below a DNS label "IP6". Stated
+ another way, conformance with this suggestion would mean that "IP6"
+ is the first label in the RDATA field of DNAME records which support
+ IPv6 reverse lookups.
+
+ When any "reserved" or "must be zero" bits are adjacent to a
+ delegation boundary, the higher-level entity MUST retain those bits
+ in its own control and delegate only the bits over which the lower-
+ level entity has authority.
+
+ To find the name of a node given its IPv6 address, a DNS client MUST
+ perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the
+ 128 bit address as one or more bit-string labels [BITLBL], followed
+ by the two standard labels "IP6.ARPA". If recursive service was not
+ obtained from a server and the desired PTR record was not returned,
+ the resolver MUST handle returned DNAME records as specified in
+ [DNAME], and NS records as specified in [DNSCF], and iterate.
+
+4. Modifications to Existing Query Types
+
+ All existing query types that perform type A additional section
+ processing, i.e. the name server (NS), mail exchange (MX), and
+ mailbox (MB) query types, and the experimental AFS data base (AFSDB)
+ and route through (RT) types, must be redefined to perform type A, A6
+ and AAAA additional section processing, with type A having the
+ highest priority for inclusion and type AAAA the lowest. This
+ redefinition means that a name server may add any relevant IPv4 and
+ IPv6 address information available locally to the additional section
+ of a response when processing any one of the above queries. The
+ recursive inclusion of A6 records referenced by A6 records already
+ included in the additional section is OPTIONAL.
+
+5. Usage Illustrations
+
+ This section provides examples of use of the mechanisms defined in
+ the previous section. All addresses and domains mentioned here are
+ intended to be fictitious and for illustrative purposes only.
+ Example delegations will be on 4-bit boundaries solely for
+ readability; this specification is indifferent to bit alignment.
+
+ Use of the IPv6 aggregatable address format [AGGR] is assumed in the
+ examples.
+
+
+
+Crawford, et al. Standards Track [Page 8]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+5.1. A6 Record Chains
+
+ Let's take the example of a site X that is multi-homed to two
+ "intermediate" providers A and B. The provider A is itself multi-
+ homed to two "transit" providers, C and D. The provider B gets its
+ transit service from a single provider, E. For simplicity suppose
+ that C, D and E all belong to the same top-level aggregate (TLA) with
+ identifier (including format prefix) '2345', and the TLA authority at
+ ALPHA-TLA.ORG assigns to C, D and E respectively the next level
+ aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and
+ 2345:000E::/32.
+
+ C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
+ prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
+ B.
+
+ A assigns to X the subscriber identification '11' and B assigns the
+ subscriber identification '22'. As a result, the site X inherits
+ three address prefixes:
+
+ o 2345:00C1:CA11::/48 from A, for routes through C.
+ o 2345:00D2:DA11::/48 from A, for routes through D.
+ o 2345:000E:EB22::/48 from B, for routes through E.
+
+ Let us suppose that N is a node in the site X, that it is assigned to
+ subnet number 1 in this site, and that it uses the interface
+ identifier '1234:5678:9ABC:DEF0'. In our configuration, this node
+ will have three addresses:
+
+ o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
+ o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
+ o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
+
+5.1.1. Authoritative Data
+
+ We will assume that the site X is represented in the DNS by the
+ domain name X.EXAMPLE, while A, B, C, D and E are represented by
+ A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we
+ assume a subdomain "IP6" that will hold the corresponding prefixes.
+ The node N is identified by the domain name N.X.EXAMPLE. The
+ following records would then appear in X's DNS.
+
+ $ORIGIN X.EXAMPLE.
+ N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
+ SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
+ IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
+ IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
+
+
+
+
+Crawford, et al. Standards Track [Page 9]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ And elsewhere there would appear
+
+ SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
+ SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
+
+ SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
+
+ A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
+
+ A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
+
+ B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
+
+ C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
+ D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
+ E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
+
+5.1.2. Glue
+
+ When, as is common, some or all DNS servers for X.EXAMPLE are within
+ the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
+ enough "glue" information to enable DNS clients to reach those
+ nameservers. This is true in IPv6 just as in IPv4. However, the A6
+ record affords the DNS administrator some choices. The glue could be
+ any of
+
+ o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
+
+ o a (possibly smaller) set of records which collapse the structure
+ of that minimal set,
+
+ o or a set of A6 records with prefix length zero, giving the entire
+ global addresses of the servers.
+
+ The trade-off is ease of maintenance against robustness. The best
+ and worst of both may be had together by implementing either the
+ first or second option together with the third. To illustrate the
+ glue options, suppose that X.EXAMPLE is served by two nameservers
+ NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
+ ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
+ Then the top-level zone EXAMPLE would include one (or more) of the
+ following sets of A6 records as glue.
+
+
+
+
+
+
+
+
+
+Crawford, et al. Standards Track [Page 10]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ $ORIGIN EXAMPLE. ; first option
+ X NS NS1.X
+ NS NS2.X
+ NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
+ NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
+ SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
+ SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
+ IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
+ IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
+
+
+ $ORIGIN EXAMPLE. ; second option
+ X NS NS1.X
+ NS NS2.X
+ NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
+ A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
+ NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
+ A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
+
+
+ $ORIGIN EXAMPLE. ; third option
+ X NS NS1.X
+ NS NS2.X
+ NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
+ A6 0 2345:00D2:DA11:1:1:11:111:1111
+ A6 0 2345:000E:EB22:1:1:11:111:1111
+ NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
+ A6 0 2345:00D2:DA11:2:2:22:222:2222
+ A6 0 2345:000E:EB22:2:2:22:222:2222
+
+ The first and second glue options are robust against renumbering of
+ X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
+ those providers' own DNS is unreachable. The glue records of the
+ third option are robust against DNS failures elsewhere than the zones
+ EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
+ address space is renumbered.
+
+ If the EXAMPLE zone includes redundant glue, for instance the union
+ of the A6 records of the first and third options, then under normal
+ circumstances duplicate IPv6 addresses will be derived by DNS
+ clients. But if provider DNS fails, addresses will still be obtained
+ from the zero-prefix-length records, while if the EXAMPLE zone lags
+ behind a renumbering of X.EXAMPLE, half of the addresses obtained by
+ DNS clients will still be up-to-date.
+
+ The zero-prefix-length glue records can of course be automatically
+ generated and/or checked in practice.
+
+
+
+
+Crawford, et al. Standards Track [Page 11]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+5.1.3. Variations
+
+ Several more-or-less arbitrary assumptions are reflected in the above
+ structure. All of the following choices could have been made
+ differently, according to someone's notion of convenience or an
+ agreement between two parties.
+
+ First, that site X has chosen to put subnet information in a
+ separate A6 record rather than incorporate it into each node's A6
+ records.
+
+ Second, that site X is referred to as "SUBSCRIBER-X" by both of
+ its providers A and B.
+
+ Third, that site X chose to indirect its provider information
+ through A6 records at IP6.X.EXAMPLE containing no significant
+ bits. An alternative would have been to replicate each subnet
+ record for each provider.
+
+ Fourth, B and E used a slightly different prefix naming convention
+ between themselves than did A, C and D. Each hierarchical pair of
+ network entities must arrange this naming between themselves.
+
+ Fifth, that the upward prefix referral chain topped out at ALPHA-
+ TLA.ORG. There could have been another level which assigned the
+ TLA values and holds A6 records containing those bits.
+
+ Finally, the above structure reflects an assumption that address
+ fields assigned by a given entity are recorded only in A6 records
+ held by that entity. Those bits could be entered into A6 records in
+ the lower-level entity's zone instead, thus:
+
+ IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
+ IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
+
+ IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
+ and so on.
+
+ Or the higher-level entities could hold both sorts of A6 records
+ (with different DNS owner names) and allow the lower-level entities
+ to choose either mode of A6 chaining. But the general principle of
+ avoiding data duplication suggests that the proper place to store
+ assigned values is with the entity that assigned them.
+
+ It is possible, but not necessarily recommended, for a zone
+ maintainer to forego the renumbering support afforded by the chaining
+ of A6 records and to record entire IPv6 addresses within one zone
+ file.
+
+
+
+Crawford, et al. Standards Track [Page 12]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+5.2. Reverse Mapping Zones
+
+ Supposing that address space assignments in the TLAs with Format
+ Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
+ zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
+ the IP6.ARPA zone would include
+
+ $ORIGIN IP6.ARPA.
+ \[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
+ \[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
+ \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
+
+ Eight trailing zero bits have been included in each TLA ID to reflect
+ the eight reserved bits in the current aggregatable global unicast
+ addresses format [AGGR].
+
+5.2.1. The TLA level
+
+ ALPHA-TLA's assignments to network providers C, D and E are reflected
+ in the reverse data as follows.
+
+ \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
+ \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
+ \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
+
+5.2.2. The ISP level
+
+ The providers A through E carry the following delegation information
+ in their zone files.
+
+ \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
+ \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
+ \[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
+ \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
+ \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
+
+ Note that some domain names appear in the RDATA of more than one
+ DNAME record. In those cases, one zone is being used to map multiple
+ prefixes.
+
+5.2.3. The Site Level
+
+ Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
+ name translations. This domain is now referenced by two different
+ DNAME records held by two different providers.
+
+
+
+
+
+
+Crawford, et al. Standards Track [Page 13]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ $ORIGIN IP6.X.EXAMPLE.
+ \[x0001/16] DNAME SUBNET-1
+ \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
+ and so on.
+
+ SUBNET-1 need not have been named in a DNAME record; the subnet bits
+ could have been joined with the interface identifier. But if subnets
+ are treated alike in both the A6 records and in the reverse zone, it
+ will always be possible to keep the forward and reverse definition
+ data for each prefix in one zone.
+
+5.3. Lookups
+
+ A DNS resolver looking for a hostname for the address
+ 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
+ DNAME records shown above and would form new queries. Assuming that
+ it began the process knowing servers for IP6.ARPA, but that no server
+ it consulted provided recursion and none had other useful additional
+ information cached, the sequence of queried names and responses would
+ be (all with QCLASS=IN, QTYPE=PTR):
+
+ To a server for IP6.ARPA:
+ QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
+
+ Answer:
+ \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
+
+ To a server for IP6.ALPHA-TLA.ORG:
+ QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
+
+ Answer:
+ \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
+
+ To a server for IP6.C.NET.:
+ QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
+
+ Answer:
+ \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
+
+ To a server for IP6.A.NET.:
+ QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
+
+ Answer:
+ \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
+
+ To a server for IP6.X.EXAMPLE.:
+ QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
+
+
+
+
+Crawford, et al. Standards Track [Page 14]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ Answer:
+ \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
+ \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
+
+ All the DNAME (and NS) records acquired along the way can be cached
+ to expedite resolution of addresses topologically near to this
+ address. And if another global address of N.X.EXAMPLE were resolved
+ within the TTL of the final PTR record, that record would not have to
+ be fetched again.
+
+5.4. Operational Note
+
+ In the illustrations in section 5.1, hierarchically adjacent
+ entities, such as a network provider and a customer, must agree on a
+ DNS name which will own the definition of the delegated prefix(es).
+ One simple convention would be to use a bit-string label representing
+ exactly the bits which are assigned to the lower-level entity by the
+ higher. For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
+ This would place the A6 record(s) defining the delegated prefix at
+ exactly the same point in the DNS tree as the DNAME record associated
+ with that delegation. The cost of this simplification is that the
+ lower-level zone must update its upward-pointing A6 records when it
+ is renumbered. This cost may be found quite acceptable in practice.
+
+6. Transition from RFC 1886 and Deployment Notes
+
+ When prefixes have been "delegated upward" with A6 records, the
+ number of DNS resource records required to establish a single IPv6
+ address increases by some non-trivial factor. Those records will
+ typically, but not necessarily, come from different DNS zones (which
+ can independently suffer failures for all the usual reasons). When
+ obtaining multiple IPv6 addresses together, this increase in RR count
+ will be proportionally less -- and the total size of a DNS reply
+ might even decrease -- if the addresses are topologically clustered.
+ But the records could still easily exceed the space available in a
+ UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
+ SRV query, for example. The possibilities for overall degradation of
+ performance and reliability of DNS lookups are numerous, and increase
+ with the number of prefix delegations involved, especially when those
+ delegations point to records in other zones.
+
+ DNS Security [DNSSEC] addresses the trustworthiness of cached data,
+ which is a problem intrinsic to DNS, but the cost of applying this to
+ an IPv6 address is multiplied by a factor which may be greater than
+ the number of prefix delegations involved if different signature
+ chains must be verified for different A6 records. If a trusted
+ centralized caching server (as in [TSIG], for example) is used, this
+ cost might be amortized to acceptable levels. One new phenomenon is
+
+
+
+Crawford, et al. Standards Track [Page 15]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ the possibility that IPv6 addresses may be formed from a A6 records
+ from a combination of secure and unsecured zones.
+
+ Until more deployment experience is gained with the A6 record, it is
+ recommended that prefix delegations be limited to one or two levels.
+ A reasonable phasing-in mechanism would be to start with no prefix
+ delegations (all A6 records having prefix length 0) and then to move
+ to the use of a single level of delegation within a single zone. (If
+ the TTL of the "prefix" A6 records is kept to an appropriate duration
+ the capability for rapid renumbering is not lost.) More aggressively
+ flexible delegation could be introduced for a subset of hosts for
+ experimentation.
+
+6.1. Transition from AAAA and Coexistence with A Records
+
+ Administrators of zones which contain A6 records can easily
+ accommodate deployed resolvers which understand AAAA records but not
+ A6 records. Such administrators can do automatic generation of AAAA
+ records for all of a zone's names which own A6 records by a process
+ which mimics the resolution of a hostname to an IPv6 address (see
+ section 3.1.4). Attention must be paid to the TTL assigned to a
+ generated AAAA record, which MUST be no more than the minimum of the
+ TTLs of the A6 records that were used to form the IPv6 address in
+ that record. For full robustness, those A6 records which were in
+ different zones should be monitored for changes (in TTL or RDATA)
+ even when there are no changes to zone for which AAAA records are
+ being generated. If the zone is secure [DNSSEC], the generated AAAA
+ records MUST be signed along with the rest of the zone data.
+
+ A zone-specific heuristic MAY be used to avoid generation of AAAA
+ records for A6 records which record prefixes, although such
+ superfluous records would be relatively few in number and harmless.
+ Examples of such heuristics include omitting A6 records with a prefix
+ length less than the largest value found in the zone file, or records
+ with an address suffix field with a certain number of trailing zero
+ bits.
+
+ On the client side, when looking up and IPv6 address, the order of A6
+ and AAAA queries MAY be configurable to be one of: A6, then AAAA;
+ AAAA, then A6; A6 only; or both in parallel. The default order (or
+ only order, if not configurable) MUST be to try A6 first, then AAAA.
+ If and when the AAAA becomes deprecated a new document will change
+ the default.
+
+ The guidelines and options for precedence between IPv4 and IPv6
+ addresses are specified in [TRANS]. All mentions of AAAA records in
+ that document are henceforth to be interpreted as meaning A6 and/or
+ AAAA records in the order specified in the previous paragraph.
+
+
+
+Crawford, et al. Standards Track [Page 16]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+6.2. Transition from Nibble Labels to Binary Labels
+
+ Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
+ as follows:
+
+ An IPv6 address is represented as a name in the IP6.INT domain by
+ a sequence of nibbles separated by dots with the suffix
+ ".IP6.INT". The sequence of nibbles is encoded in reverse order,
+ i.e. the low-order nibble is encoded first, followed by the next
+ low-order nibble and so on. Each nibble is represented by a
+ hexadecimal digit. For example, a name for the address
+ 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
+ 5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
+ 8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
+
+ Implementations conforming to this specification will perform a
+ lookup of a binary label in IP6.ARPA as specified in Section 3.2. It
+ is RECOMMENDED that for a transition period implementations first
+ lookup the binary label in IP6.ARPA and if this fails try to lookup
+ the 'nibble' label in IP6.INT.
+
+7. Security Considerations
+
+ The signing authority [DNSSEC] for the A6 records which determine an
+ IPv6 address is distributed among several entities, reflecting the
+ delegation path of the address space which that address occupies.
+ DNS Security is fully applicable to bit-string labels and DNAME
+ records. And just as in IPv4, verification of name-to-address
+ mappings is logically independent of verification of address-to-name
+ mappings.
+
+ With or without DNSSEC, the incomplete but non-empty address set
+ scenario of section 3.1.4 could be caused by selective interference
+ with DNS lookups. If in some situation this would be more harmful
+ than complete DNS failure, it might be mitigated on the client side
+ by refusing to act on an incomplete set, or on the server side by
+ listing all addresses in A6 records with prefix length 0.
+
+8. IANA Considerations
+
+ The A6 resource record has been assigned a Type value of 38.
+
+
+
+
+
+
+
+
+
+
+Crawford, et al. Standards Track [Page 17]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+9. Acknowledgments
+
+ The authors would like to thank the following persons for valuable
+ discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, Randy
+ Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
+ Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
+ Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
+ Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
+
+10. References
+
+ [AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP
+ version 6, RFC 1886, December 1995.
+
+ [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
+ Aggregatable Global Unicast Address Format", RFC 2374, July
+ 1998.
+
+ [BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
+ RFC 2673, August 1999.
+
+ [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+ 2672, August 1999.
+
+ [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [DNSIS] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
+ Security Extensions", RFC 2535, March 1999.
+
+ [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
+ 1900, February 1996.
+
+ [RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering
+ Overview: Why would I want it and what is it anyway?", RFC
+ 2071, January 1997.
+
+ [RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
+ Behaviour Today", RFC 2101, February 1997.
+
+
+
+Crawford, et al. Standards Track [Page 18]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+ [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+ IPv6 Hosts and Routers", RFC 1933, April 1996.
+
+ [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+11. Authors' Addresses
+
+ Matt Crawford
+ Fermilab
+ MS 368
+ PO Box 500
+ Batavia, IL 60510
+ USA
+
+ Phone: +1 630 840-3461
+ EMail: crawdad@fnal.gov
+
+
+ Christian Huitema
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+
+ EMail: huitema@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al. Standards Track [Page 19]
+
+RFC 2874 IPv6 DNS July 2000
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al. Standards Track [Page 20]
+
diff --git a/Documentation/en/rfc/rfc3152.txt b/Documentation/en/rfc/rfc3152.txt
new file mode 100644
index 00000000..b226ce64
--- /dev/null
+++ b/Documentation/en/rfc/rfc3152.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group R. Bush
+Request for Comments: 3152 RGnet
+BCP: 49 August 2001
+Updates: 2874, 2772, 2766, 2553, 1886
+Category: Best Current Practice
+
+
+ Delegation of IP6.ARPA
+
+Status of this Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document discusses the need for delegation of the IP6.ARPA DNS
+ zone, and specifies a plan for the technical operation thereof.
+
+1. Why IP6.ARPA?
+
+ In the IPv6 address space, there is a need for 'reverse mapping' of
+ addresses to DNS names analogous to that provided by the IN-ADDR.ARPA
+ zone for IPv4.
+
+ The IAB recommended that the ARPA top level domain (the name is now
+ considered an acronym for "Address and Routing Parameters Area") be
+ used for technical infrastructure sub-domains when possible. It is
+ already in use for IPv4 reverse mapping and has been established as
+ the location for E.164 numbering on the Internet [RFC2916 RFC3026].
+
+ IETF consensus was reached that the IP6.ARPA domain be used for
+ address to DNS name mapping for the IPv6 address space [RFC2874].
+
+2. Obsoleted Usage
+
+ This document deprecates references to IP6.INT in [RFC1886] section
+ 2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772]
+ section 7.1.c, and [RFC2874] section 2.5.
+
+ In this context, 'deprecate' means that the old usage is not
+ appropriate for new implementations, and IP6.INT will likely be
+ phased out in an orderly fashion.
+
+
+
+Bush Best Current Practice [Page 1]
+
+RFC 3152 Delegation of IP6.ARPA August 2001
+
+
+3. IANA Considerations
+
+ This memo requests that the IANA delegate the IP6.ARPA domain
+ following instructions to be provided by the IAB. Names within this
+ zone are to be further delegated to the regional IP registries in
+ accordance with the delegation of IPv6 address space to those
+ registries. The names allocated should be hierarchic in accordance
+ with the address space assignment.
+
+4. Security Considerations
+
+ While DNS spoofing of address to name mapping has been exploited in
+ IPv4, delegation of the IP6.ARPA zone creates no new threats to the
+ security of the internet.
+
+5. References
+
+ [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
+ version 6", RFC 1886, December 1995.
+
+ [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
+ "Basic Socket Interface Extensions for IPv6", RFC 2553,
+ March 1999.
+
+ [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
+ Translation - Protocol Translation (NAT-PT)", RFC 2766,
+ February 2000.
+
+ [RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing
+ Guidelines", RFC 2772, February 2000.
+
+ [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
+ IPv6 Address Aggregation and Renumbering", RFC 2874, July
+ 2001.
+
+ [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
+ September 2000.
+
+ [RFC3026] Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026,
+ January 2001.
+
+
+
+
+
+
+
+
+
+
+
+Bush Best Current Practice [Page 2]
+
+RFC 3152 Delegation of IP6.ARPA August 2001
+
+
+6. Author's Address
+
+ Randy Bush
+ 5147 Crystal Springs
+ Bainbridge Island, WA US-98110
+
+ Phone: +1 206 780 0431
+ EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Best Current Practice [Page 3]
+
+RFC 3152 Delegation of IP6.ARPA August 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Best Current Practice [Page 4]
+
diff --git a/Documentation/en/rfc/rfc3207.txt b/Documentation/en/rfc/rfc3207.txt
new file mode 100644
index 00000000..dfcd36b8
--- /dev/null
+++ b/Documentation/en/rfc/rfc3207.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group P. Hoffman
+Request for Comments: 3207 Internet Mail Consortium
+Obsoletes: 2487 February 2002
+Category: Standards Track
+
+
+ SMTP Service Extension for
+ Secure SMTP over Transport Layer Security
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document describes an extension to the SMTP (Simple Mail
+ Transfer Protocol) service that allows an SMTP server and client to
+ use TLS (Transport Layer Security) to provide private, authenticated
+ communication over the Internet. This gives SMTP agents the ability
+ to protect some or all of their communications from eavesdroppers and
+ attackers.
+
+1. Introduction
+
+ SMTP [RFC2821] servers and clients normally communicate in the clear
+ over the Internet. In many cases, this communication goes through
+ one or more router that is not controlled or trusted by either
+ entity. Such an untrusted router might allow a third party to
+ monitor or alter the communications between the server and client.
+
+ Further, there is often a desire for two SMTP agents to be able to
+ authenticate each others' identities. For example, a secure SMTP
+ server might only allow communications from other SMTP agents it
+ knows, or it might act differently for messages received from an
+ agent it knows than from one it doesn't know.
+
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 1]
+
+RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002
+
+
+ TLS [TLS], more commonly known as SSL, is a popular mechanism for
+ enhancing TCP communications with privacy and authentication. TLS is
+ in wide use with the HTTP protocol, and is also being used for adding
+ security to many other common protocols that run over TCP.
+
+ This document obsoletes RFC 2487.
+
+1.1 Terminology
+
+ 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 [RFC2119].
+
+2. STARTTLS Extension
+
+ The STARTTLS extension to SMTP is laid out as follows:
+
+ (1) the name of the SMTP service defined here is STARTTLS;
+
+ (2) the EHLO keyword value associated with the extension is STARTTLS;
+
+ (3) the STARTTLS keyword has no parameters;
+
+ (4) a new SMTP verb, "STARTTLS", is defined;
+
+ (5) no additional parameters are added to any SMTP command.
+
+3. The STARTTLS Keyword
+
+ The STARTTLS keyword is used to tell the SMTP client that the SMTP
+ server is currently able to negotiate the use of TLS. It takes no
+ parameters.
+
+4. The STARTTLS Command
+
+ The format for the STARTTLS command is:
+
+ STARTTLS
+
+ with no parameters.
+
+ After the client gives the STARTTLS command, the server responds with
+ one of the following reply codes:
+
+ 220 Ready to start TLS
+ 501 Syntax error (no parameters allowed)
+ 454 TLS not available due to temporary reason
+
+
+
+
+Hoffman Standards Track [Page 2]
+
+RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002
+
+
+ If the client receives the 454 response, the client must decide
+ whether or not to continue the SMTP session. Such a decision is
+ based on local policy. For instance, if TLS was being used for
+ client authentication, the client might try to continue the session,
+ in case the server allows it even with no authentication. However,
+ if TLS was being negotiated for encryption, a client that gets a 454
+ response needs to decide whether to send the message anyway with no
+ TLS encryption, whether to wait and try again later, or whether to
+ give up and notify the sender of the error.
+
+ A publicly-referenced SMTP server MUST NOT require use of the
+ STARTTLS extension in order to deliver mail locally. This rule
+ prevents the STARTTLS extension from damaging the interoperability of
+ the Internet's SMTP infrastructure. A publicly-referenced SMTP
+ server is an SMTP server which runs on port 25 of an Internet host
+ listed in the MX record (or A record if an MX record is not present)
+ for the domain name on the right hand side of an Internet mail
+ address.
+
+ Any SMTP server may refuse to accept messages for relay based on
+ authentication supplied during the TLS negotiation. An SMTP server
+ that is not publicly referenced may refuse to accept any messages for
+ relay or local delivery based on authentication supplied during the
+ TLS negotiation.
+
+ A SMTP server that is not publicly referenced may choose to require
+ that the client perform a TLS negotiation before accepting any
+ commands. In this case, the server SHOULD return the reply code:
+
+ 530 Must issue a STARTTLS command first
+
+ to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the
+ client and server are using the ENHANCEDSTATUSCODES ESMTP extension
+ [RFC2034], the status code to be returned SHOULD be 5.7.0.
+
+ After receiving a 220 response to a STARTTLS command, the client MUST
+ start the TLS negotiation before giving any other SMTP commands. If,
+ after having issued the STARTTLS command, the client finds out that
+ some failure prevents it from actually starting a TLS handshake, then
+ it SHOULD abort the connection.
+
+ If the SMTP client is using pipelining as defined in RFC 2920, the
+ STARTTLS command must be the last command in a group.
+
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 3]
+
+RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002
+
+
+4.1 Processing After the STARTTLS Command
+
+ After the TLS handshake has been completed, both parties MUST
+ immediately decide whether or not to continue based on the
+ authentication and privacy achieved. The SMTP client and server may
+ decide to move ahead even if the TLS negotiation ended with no
+ authentication and/or no privacy because most SMTP services are
+ performed with no authentication and no privacy, but some SMTP
+ clients or servers may want to continue only if a particular level of
+ authentication and/or privacy was achieved.
+
+ If the SMTP client decides that the level of authentication or
+ privacy is not high enough for it to continue, it SHOULD issue an
+ SMTP QUIT command immediately after the TLS negotiation is complete.
+ If the SMTP server decides that the level of authentication or
+ privacy is not high enough for it to continue, it SHOULD reply to
+ every SMTP command from the client (other than a QUIT command) with
+ the 554 reply code (with a possible text string such as "Command
+ refused due to lack of security").
+
+ The decision of whether or not to believe the authenticity of the
+ other party in a TLS negotiation is a local matter. However, some
+ general rules for the decisions are:
+
+ - A SMTP client would probably only want to authenticate an SMTP
+ server whose server certificate has a domain name that is the
+ domain name that the client thought it was connecting to.
+ - A publicly-referenced SMTP server would probably want to accept
+ any verifiable certificate from an SMTP client, and would possibly
+ want to put distinguishing information about the certificate in
+ the Received header of messages that were relayed or submitted
+ from the client.
+
+4.2 Result of the STARTTLS Command
+
+ Upon completion of the TLS handshake, the SMTP protocol is reset to
+ the initial state (the state in SMTP after a server issues a 220
+ service ready greeting). The server MUST discard any knowledge
+ obtained from the client, such as the argument to the EHLO command,
+ which was not obtained from the TLS negotiation itself. The client
+ MUST discard any knowledge obtained from the server, such as the list
+ of SMTP service extensions, which was not obtained from the TLS
+ negotiation itself. The client SHOULD send an EHLO command as the
+ first command after a successful TLS negotiation.
+
+ The list of SMTP service extensions returned in response to an EHLO
+ command received after the TLS handshake MAY be different than the
+ list returned before the TLS handshake. For example, an SMTP server
+
+
+
+Hoffman Standards Track [Page 4]
+
+RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002
+
+
+ might not want to advertise support for a particular SASL mechanism
+ [SASL] unless a client has sent an appropriate client certificate
+ during a TLS handshake.
+
+ Both the client and the server MUST know if there is a TLS session
+ active. A client MUST NOT attempt to start a TLS session if a TLS
+ session is already active. A server MUST NOT return the STARTTLS
+ extension in response to an EHLO command received after a TLS
+ handshake has completed.
+
+4.3 STARTTLS on the Submission Port
+
+ STARTTLS is a valid ESMTP extension when used on the Submission port,
+ as defined in [RFC2476]. In fact, since the submission port is by
+ definition not a publicly referenced SMTP server, the STARTTLS
+ extension can be particularly useful by providing security and
+ authentication for this service.
+
+5. Usage Example
+
+ The following dialog illustrates how a client and server can start a
+ TLS session:
+
+ S: <waits for connection on TCP port 25>
+ C: <opens connection>
+ S: 220 mail.imc.org SMTP service ready
+ C: EHLO mail.example.com
+ S: 250-mail.imc.org offers a warm hug of welcome
+ S: 250-8BITMIME
+ S: 250-STARTTLS
+ S: 250 DSN
+ C: STARTTLS
+ S: 220 Go ahead
+ C: <starts TLS negotiation>
+ C & S: <negotiate a TLS session>
+ C & S: <check result of negotiation>
+ C: EHLO mail.example.com
+ S: 250-mail.imc.org touches your hand gently for a moment
+ S: 250-8BITMIME
+ S: 250 DSN
+
+6. Security Considerations
+
+ It should be noted that SMTP is not an end-to-end mechanism. Thus,
+ if an SMTP client/server pair decide to add TLS privacy, they are not
+ securing the transport from the originating mail user agent to the
+ recipient. Further, because delivery of a single piece of mail may
+ go between more than two SMTP servers, adding TLS privacy to one pair
+
+
+
+Hoffman Standards Track [Page 5]
+
+RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002
+
+
+ of servers does not mean that the entire SMTP chain has been made
+ private. Further, just because an SMTP server can authenticate an
+ SMTP client, it does not mean that the mail from the SMTP client was
+ authenticated by the SMTP client when the client received it.
+
+ Both the SMTP client and server must check the result of the TLS
+ negotiation to see whether an acceptable degree of authentication and
+ privacy was achieved. Ignoring this step completely invalidates
+ using TLS for security. The decision about whether acceptable
+ authentication or privacy was achieved is made locally, is
+ implementation-dependent, and is beyond the scope of this document.
+
+ The SMTP client and server should note carefully the result of the
+ TLS negotiation. If the negotiation results in no privacy, or if it
+ results in privacy using algorithms or key lengths that are deemed
+ not strong enough, or if the authentication is not good enough for
+ either party, the client may choose to end the SMTP session with an
+ immediate QUIT command, or the server may choose to not accept any
+ more SMTP commands.
+
+ A man-in-the-middle attack can be launched by deleting the "250
+ STARTTLS" response from the server. This would cause the client not
+ to try to start a TLS session. Another man-in-the-middle attack is
+ to allow the server to announce its STARTTLS capability, but to alter
+ the client's request to start TLS and the server's response. In
+ order to defend against such attacks both clients and servers MUST be
+ able to be configured to require successful TLS negotiation of an
+ appropriate cipher suite for selected hosts before messages can be
+ successfully transferred. The additional option of using TLS when
+ possible SHOULD also be provided. An implementation MAY provide the
+ ability to record that TLS was used in communicating with a given
+ peer and generating a warning if it is not used in a later session.
+
+ If the TLS negotiation fails or if the client receives a 454
+ response, the client has to decide what to do next. There are three
+ main choices: go ahead with the rest of the SMTP session, retry TLS
+ at a later time, or give up and return the mail to the sender. If a
+ failure or error occurs, the client can assume that the server may be
+ able to negotiate TLS in the future, and should try negotiate TLS in
+ a later session, until some locally-chosen timeout occurs, at which
+ point, the client should return the mail to the sender. However, if
+ the client and server were only using TLS for authentication, the
+ client may want to proceed with the SMTP session, in case some of the
+ operations the client wanted to perform are accepted by the server
+ even if the client is unauthenticated.
+
+ Before the TLS handshake has begun, any protocol interactions are
+ performed in the clear and may be modified by an active attacker.
+
+
+
+Hoffman Standards Track [Page 6]
+
+RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002
+
+
+ For this reason, clients and servers MUST discard any knowledge
+ obtained prior to the start of the TLS handshake upon completion of
+ the TLS handshake.
+
+ The STARTTLS extension is not suitable for authenticating the author
+ of an email message unless every hop in the delivery chain, including
+ the submission to the first SMTP server, is authenticated. Another
+ proposal [SMTP-AUTH] can be used to authenticate delivery and MIME
+ security multiparts [MIME-SEC] can be used to authenticate the author
+ of an email message. In addition, the [SMTP-AUTH] proposal offers
+ simpler and more flexible options to authenticate an SMTP client and
+ the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with
+ the STARTTLS command to provide an authorization identity.
+
+7. References
+
+ [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+ April 2001.
+
+ [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
+ Error Codes", RFC 2034, October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC
+ 2476, December 1998.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
+ RFC 2554, March 1999.
+
+ [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 7]
+
+RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002
+
+
+Appendix
+
+ This document is a revision of RFC 2487, which is a Proposed
+ Standard. The changes from that document are:
+
+ - Section 5 and 7: More discussion of the man-in-the-middle attacks
+ - Section 5: Additional discussion of when a server should and
+ should not advertise the STARTTLS extension
+ - Section 5: Changed the requirements on SMTP clients after
+ receiving a 220 response.
+ - Section 5.1: Clarified description of verifying certificates.
+ - Section 5.3: Added the section on "STARTTLS on the Submission
+ Port"
+ - Section 6: Bug fix in the example to indicate that the client
+ needs to issue a new EHLO command, as already is described in
+ section 5.2.
+ - Section 7: Clarification of the paragraph on acceptable degree of
+ privacy. Significant change to the discussion of how to avoid a
+ man-in-the-middle attack.
+ - Section A: Update reference from RFC 821 to RFC 2821.
+
+Author's Address
+
+ Paul Hoffman
+ Internet Mail Consortium
+ 127 Segre Place
+ Santa Cruz, CA 95060
+
+ Phone: (831) 426-9827
+ EMail: phoffman@imc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 8]
+
+RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman Standards Track [Page 9]
+
diff --git a/Documentation/en/rfc/rfc3234.txt b/Documentation/en/rfc/rfc3234.txt
new file mode 100644
index 00000000..52049911
--- /dev/null
+++ b/Documentation/en/rfc/rfc3234.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group B. Carpenter
+Request for Comments: 3234 IBM Zurich Research Laboratory
+Category: Informational S. Brim
+ February 2002
+
+
+ Middleboxes: Taxonomy and Issues
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document is intended as part of an IETF discussion about
+ "middleboxes" - defined as any intermediary box performing functions
+ apart from normal, standard functions of an IP router on the data
+ path between a source host and destination host. This document
+ establishes a catalogue or taxonomy of middleboxes, cites previous
+ and current IETF work concerning middleboxes, and attempts to
+ identify some preliminary conclusions. It does not, however, claim
+ to be definitive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 1]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+Table of Contents
+
+ 1. Introduction and Goals......................................... 3
+ 1.1. Terminology.................................................. 3
+ 1.2. The Hourglass Model, Past and Future......................... 3
+ 1.4. Goals of this Document....................................... 4
+ 2. A catalogue of middleboxes..................................... 5
+ 2.1 NAT........................................................... 6
+ 2.2 NAT-PT........................................................ 7
+ 2.3 SOCKS gateway................................................. 7
+ 2.4 IP Tunnel Endpoints........................................... 8
+ 2.5. Packet classifiers, markers and schedulers................... 8
+ 2.6 Transport relay............................................... 9
+ 2.7. TCP performance enhancing proxies............................ 10
+ 2.8. Load balancers that divert/munge packets..................... 10
+ 2.9. IP Firewalls................................................. 11
+ 2.10. Application Firewalls....................................... 11
+ 2.11. Application-level gateways.................................. 12
+ 2.12. Gatekeepers/ session control boxes.......................... 12
+ 2.13. Transcoders................................................. 12
+ 2.14. Proxies..................................................... 13
+ 2.15. Caches...................................................... 14
+ 2.16. Modified DNS servers........................................ 14
+ 2.17. Content and applications distribution boxes................. 15
+ 2.18. Load balancers that divert/munge URLs....................... 16
+ 2.19. Application-level interceptors.............................. 16
+ 2.20. Application-level multicast................................. 16
+ 2.21. Involuntary packet redirection.............................. 16
+ 2.22. Anonymisers................................................. 17
+ 2.23. Not included................................................ 17
+ 2.24. Summary of facets........................................... 17
+ 3. Ongoing work in the IETF and elsewhere......................... 18
+ 4. Comments and Issues............................................ 19
+ 4.1. The end to end principle under challenge..................... 19
+ 4.2. Failure handling............................................. 20
+ 4.3. Failures at multiple layers.................................. 21
+ 4.4. Multihop application protocols............................... 21
+ 4.5. Common features.............................................. 22
+ 5. Security Considerations........................................ 22
+ 6. Acknowledgements............................................... 23
+ 7. References..................................................... 23
+ Authors' Addresses................................................ 26
+ Acknowledgement................................................... 26
+ Full Copyright Statement.......................................... 27
+
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 2]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+1. Introduction and Goals
+
+1.1. Terminology
+
+ The phrase "middlebox" was coined by Lixia Zhang as a graphic
+ description of a recent phenomenon in the Internet. A middlebox is
+ defined as any intermediary device performing functions other than
+ the normal, standard functions of an IP router on the datagram path
+ between a source host and destination host.
+
+ In some discussions, especially those concentrating on HTTP traffic,
+ the word "intermediary" is used. For the present document, we prefer
+ the more graphic phrase. Of course, a middlebox can be virtual,
+ i.e., an embedded function of some other box. It should not be
+ interpreted as necessarily referring to a separate physical box. It
+ may be a device that terminates one IP packet flow and originates
+ another, or a device that transforms or diverts an IP packet flow in
+ some way, or a combination. In any case it is never the ultimate
+ end-system of an applications session.
+
+ Normal, standard IP routing functions (i.e., the route discovery and
+ selection functions described in [RFC 1812], and their equivalent for
+ IPv6) are not considered to be middlebox functions; a standard IP
+ router is essentially transparent to IP packets. Other functions
+ taking place within the IP layer may be considered to be middlebox
+ functions, but functions below the IP layer are excluded from the
+ definition.
+
+ There is some discrepancy in the way the word "routing" is used in
+ the community. Some people use it in the narrow, traditional sense
+ of path selection based on IP address, i.e., the decision-making
+ action of an IP router. Others use it in the sense of higher layer
+ decision-making (based perhaps on a URL or other applications layer
+ string). In either case it implies a choice of outbound direction,
+ not the mere forwarding of a packet in the only direction available.
+ In this document, the traditional sense is always qualified as "IP
+ routing."
+
+1.2. The Hourglass Model, Past and Future
+
+ The classical description of the Internet architecture is based
+ around the hourglass model [HOURG] and the end-to-end principle
+ [Clark88, Saltzer]. The hourglass model depicts the protocol
+ architecture as a narrow-necked hourglass, with all upper layers
+ riding over a single IP protocol, which itself rides over a variety
+ of hardware layers.
+
+
+
+
+
+Carpenter & Brim Informational [Page 3]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ The end-to-end principle asserts that some functions (such as
+ security and reliability) can only be implemented completely and
+ correctly end-to-end, with the help of the end points. The end-to-
+ end principle notes that providing an incomplete version of such
+ functions in the network itself can sometimes be useful as a
+ performance enhancement, but not as a substitute for the end-to-end
+ implementation of the function. The references above, and [RFC
+ 1958], go into more detail.
+
+ In this architecture, the only boxes in the neck of the hourglass are
+ IP routers, and their only function is to determine routes and
+ forward packets (while also updating fields necessary for the
+ forwarding process). This is why they are not classed as
+ middleboxes.
+
+ Today, we observe deviations from this model, caused by the insertion
+ in the network of numerous middleboxes performing functions other
+ than IP forwarding. Viewed in one way, these boxes are a challenge
+ to the transparency of the network layer [RFC 2775]. Viewed another
+ way, they are a challenge to the hourglass model: although the IP
+ layer does not go away, middleboxes dilute its significance as the
+ single necessary feature of all communications sessions. Instead of
+ concentrating diversity and function at the end systems, they spread
+ diversity and function throughout the network.
+
+ This is a matter of concern for several reasons:
+
+ * New middleboxes challenge old protocols. Protocols designed
+ without consideration of middleboxes may fail, predictably or
+ unpredictably, in the presence of middleboxes.
+
+ * Middleboxes introduce new failure modes; rerouting of IP packets
+ around crashed routers is no longer the only case to consider.
+ The fate of sessions involving crashed middleboxes must also be
+ considered.
+
+ * Configuration is no longer limited to the two ends of a session;
+ middleboxes may also require configuration and management.
+
+ * Diagnosis of failures and misconfigurations is more complex.
+
+1.4. Goals of this Document
+
+ The principle goal of this document is to describe and analyse the
+ current impact of middleboxes on the architecture of the Internet and
+ its applications. From this, we attempt to identify some general
+ conclusions.
+
+
+
+
+Carpenter & Brim Informational [Page 4]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ Goals that might follow on from this work are:
+
+ * to identify harmful and harmless practices,
+
+ * to suggest architectural guidelines for application protocol and
+ middlebox design,
+
+ * to identify requirements and dependencies for common functions in
+ the middlebox environment,
+
+ * to derive a system design for standardisation of these functions,
+
+ * to identify additional work that should be done in the IETF and
+ IRTF.
+
+ An implied goal is to identify any necessary updates to the
+ Architectural Principles of the Internet [RFC 1958].
+
+ The document initially establishes a catalogue of middleboxes, and
+ cites previous or current IETF work concerning middleboxes, before
+ proceeding to discussion and conclusions.
+
+2. A catalogue of middleboxes
+
+ The core of this document is a catalogue of a number of types of
+ middlebox. There is no obvious way of classifying them to form a
+ hierarchy or other simple form of taxonomy. Middleboxes have a
+ number of facets that might be used to classify them in a
+ multidimensional taxonomy.
+
+ DISCLAIMER: These facets, many of distinctions between different
+ types of middlebox, and the decision to include or exclude a
+ particular type of device, are to some extent subjective. Not
+ everyone who commented on drafts of this document agrees with our
+ classifications and descriptions. We do not claim that the following
+ catalogue is mathematically complete and consistent, and in some
+ cases purely arbitrary choices have been made, or ambiguity remains.
+ Thus, this document makes no claim to be definitive.
+
+ The facets considered are:
+
+ 1. Protocol layer. Does the box act at the IP layer, the transport
+ layer, the upper layers, or a mixture?
+
+ 2. Explicit versus implicit. Is the middlebox function an explicit
+ design feature of the protocol(s) in use, like an SMTP relay? Or
+ is it an add-on not foreseen by the protocol design, probably
+ attempting to be invisible, like a network address translator?
+
+
+
+Carpenter & Brim Informational [Page 5]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ 3. Single hop versus multi-hop. Can there be only one box in the
+ path, or can there be several?
+
+ 4. In-line versus call-out. The middlebox function may be executed
+ in-line on the datapath, or it may involve a call-out to an
+ ancillary box.
+
+ 5. Functional versus optimising. Does the box perform a function
+ without which the application session cannot run, or is the
+ function only an optimisation?
+
+ 6. Routing versus processing. Does the box simply choose which way
+ to send the packets of a session, or does it actually process them
+ in some way (i.e., change them or create a side-effect)?
+
+ 7. Soft state versus hard state. If the box loses its state
+ information, does the session continue to run in a degraded mode
+ while reconstructing necessary state (soft state), or does it
+ simply fail (hard state)?
+
+ 8. Failover versus restart. In the event that a hard state box
+ fails, is the session redirected to an alternative box that has a
+ copy of the state information, or is it forced to abort and
+ restart?
+
+ One possible classification is deliberately excluded: "good" versus
+ "evil". While analysis shows that some types of middlebox come with
+ a host of complications and disadvantages, no useful purpose would be
+ served by simply deprecating them. They have been invented for
+ compelling reasons, and it is instructive to understand those
+ reasons.
+
+ The types of box listed below are in an arbitrary order, although
+ adjacent entries may have some affinity. At the end of each entry is
+ an attempt to characterise it in terms of the facets identified
+ above. These characterisations should not be interpreted as rigid;
+ in many cases they are a gross simplification.
+
+ Note: many types of middlebox may need to perform IP packet
+ fragmentation and re-assembly. This is mentioned only in certain
+ cases.
+
+2.1 NAT
+
+ Network Address Translator. A function, often built into a router,
+ that dynamically assigns a globally unique address to a host that
+ doesn't have one, without that host's knowledge. As a result, the
+ appropriate address field in all packets to and from that host is
+
+
+
+Carpenter & Brim Informational [Page 6]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ translated on the fly. Because NAT is incompatible with application
+ protocols with IP address dependencies, a NAT is in practice always
+ accompanied by an ALG (Application Level Gateway - see below). It
+ also touches the transport layer to the extent of fixing up
+ checksums.
+
+ NATs have been extensively analysed in the IETF [RFC 2663, RFC 2993,
+ RFC 3022, RFC 3027, etc.]
+
+ The experimental RSIP proposal complements NAT with a dynamic tunnel
+ mechanism inserting a stateful RSIP server in place of the NAT
+ [RSIP].
+
+ {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
+ processing, 7 hard, 8 restart}
+
+2.2 NAT-PT
+
+ NAT with Protocol Translator. A function, normally built into a
+ router, that performs NAT between an IPv6 host and an IPv4 network,
+ additionally translating the entire IP header between IPv6 and IPv4
+ formats.
+
+ NAT-PT itself depends on the Stateless IP/ICMP Translation Algorithm
+ (SIIT) mechanism [RFC 2765] for its protocol translation function.
+ In practice, SIIT and NAT-PT will both need an associated ALG and
+ will need to touch transport checksums. Due to the permitted absence
+ of a UDP checksum in IPv4, translation of fragmented unchecksummed
+ UDP from IPv4 to IPv6 is hopeless. NAT-PT and SIIT also have other
+ potential fragmentation/MTU problems, particularly when dealing with
+ endpoints that don't do path MTU discovery (or when transiting other
+ middleboxes that break path MTU discovery). ICMP translation also
+ has some intractable difficulties.
+
+ NAT-PT is a Proposed Standard from the NGTRANS WG [RFC 2766]. The
+ Dual Stack Transition Mechanism adds a second related middlebox, the
+ DSTM server [DSTM].
+
+ {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
+ processing, 7 hard, 8 restart}
+
+2.3 SOCKS gateway
+
+ SOCKSv5 [RFC 1928] is a stateful mechanism for authenticated firewall
+ traversal, in which the client host must communicate first with the
+ SOCKS server in the firewall before it is able to traverse the
+ firewall. It is the SOCKS server, not the client, that determines
+ the source IP address and port number used outside the firewall. The
+
+
+
+Carpenter & Brim Informational [Page 7]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ client's stack must be "SOCKSified" to take account of this, and
+ address-sensitive applications may get confused, rather as with NAT.
+ However, SOCKS gateways do not require ALGs.
+
+ SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG.
+
+ {1 multi-layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6
+ routing, 7 hard, 8 restart}
+
+2.4 IP Tunnel Endpoints
+
+ Tunnel endpoints, including virtual private network endpoints, use
+ basic IP services to set up tunnels with their peer tunnel endpoints
+ which might be anywhere in the Internet. Tunnels create entirely new
+ "virtual" networks and network interfaces based on the Internet
+ infrastructure, and thereby open up a number of new services. Tunnel
+ endpoints base their forwarding decisions at least partly on their
+ own policies, and only partly if at all on information visible to
+ surrounding routers.
+
+ To the extent that they deliver packets intact to their destinations,
+ tunnel endpoints appear to follow the end-to-end principle in the
+ outer Internet. However, the destination may be completely different
+ from what a router near the tunnel entrance might expect. Also, the
+ per-hop treatment a tunneled packet receives, for example in terms of
+ QoS, may not be what it would have received had the packet traveled
+ untunneled [RFC2983].
+
+ Tunnels also cause difficulties with MTU size (they reduce it) and
+ with ICMP replies (they may lack necessary diagnostic information).
+
+ When a tunnel fails for some reason, this may cause the user session
+ to abort, or an alternative IP route may prove to be available, or in
+ some cases the tunnel may be re-established automatically.
+
+ {1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
+ processing, 7 hard, 8 restart or failover}
+
+2.5. Packet classifiers, markers and schedulers
+
+ Packet classifiers classify packets flowing through them according to
+ policy and either select them for special treatment or mark them, in
+ particular for differentiated services [Clark95, RFC 2475]. They may
+ alter the sequence of packet flow through subsequent hops, since they
+ control the behaviour of traffic conditioners.
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 8]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ Schedulers or traffic conditioners (in routers, hosts, or specialist
+ boxes inserted in the data path) may alter the time sequence of
+ packet flow, the order in which packets are sent, and which packets
+ are dropped. This can significantly impact end-to-end performance.
+ It does not, however, fundamentally change the unreliable datagram
+ model of the Internet.
+
+ When a classifier or traffic conditioner fails, the user session may
+ see any result between complete loss of connectivity (all packets are
+ dropped), through best-effort service (all packets are given default
+ QOS), up to automatic restoration of the original service level.
+
+ {1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising, 6
+ processing, 7 soft, 8 failover or restart}
+
+2.6 Transport relay
+
+ Transport relays are basically the transport layer equivalent of an
+ ALG; another (less common) name for them is a TLG. As with ALGs,
+ they're used for a variety of purposes, some well established and
+ meeting needs not otherwise met. Early examples of transport relays
+ were those that ran on MIT's ITS and TOPS-20 PDP-10s on the ARPANET
+ and allowed Chaosnet-only hosts to make outgoing connections from
+ Chaosnet onto TCP/IP. Later there were some uses of TCP-TP4 relays.
+ A transport relay between IPv6-only and IPv4-only hosts is one of the
+ tools of IPv6 transition [TRANS64]. TLGs are sometimes used in
+ combination with simple packet filtering firewalls to enforce
+ restrictions on which hosts can talk to the outside world or to
+ kludge around strange IP routing configurations. TLGs are also
+ sometimes used to gateway between two instances of the same transport
+ protocol with significantly different connection characteristics; it
+ is in this sense that a TLG may also be called a TCP or transport
+ spoofer. In this role, the TLG may shade into being an optimising
+ rather than a functional middlebox, but it is distinguished from
+ Transport Proxies (next section) by the fact that it makes its
+ optimisations only by creating back-to- back connections, and not by
+ modification or re-timing of TCP messages.
+
+ Terminating one TCP connection and starting another mid-path means
+ that the TCP checksum does not cover the sender's data end-to-end.
+ Data corruptions or modifications may be introduced in the processing
+ when the data is transferred from the first to the second connection.
+ Some TCP relays are split relays and have even more possibility of
+ lost data integrity, because the there may be more than two TCP
+ connections, and multiple nodes and network paths involved. In all
+ cases, the sender has less than the expected assurance of data
+ integrity that is the TCP reliable byte stream service. Note that
+
+
+
+
+Carpenter & Brim Informational [Page 9]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ this problem is not unique to middleboxes, but can also be caused by
+ checksum offloading TCP implementations within the sender, for
+ example.
+
+ In some such cases, other session layer mechanisms such as SSH or
+ HTTPS would detect any loss of data integrity at the TCP level,
+ leading not to retransmission as with TCP, but to session failure.
+ However, there is no general session mechanism to add application
+ data integrity so one can detect or mitigate possible lack of TCP
+ data integrity.
+
+ {1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 functional
+ (mainly), 6 routing, 7 hard, 8 restart}
+
+2.7. TCP performance enhancing proxies
+
+ "TCP spoofer" is often used as a term for middleboxes that modify the
+ timing or action of the TCP protocol in flight for the purposes of
+ enhancing performance. Another, more accurate name is TCP
+ performance enhancing proxy (PEP). Many TCP PEPs are proprietary and
+ have been characterised in the open Internet primarily when they
+ introduce interoperability errors with standard TCP. As with TLGs,
+ there are circumstances in which a TCP PEP is seen to meet needs not
+ otherwise met. For example, a TCP PEP may provide re-spacing of ACKs
+ that have been bunched together by a link with bursty service, thus
+ avoiding undesireable data segment bursts. The PILC (Performance
+ Implications of Link Characteristics) working group has analyzed
+ types of TCP PEPs and their applicability [PILCPEP]. TCP PEPs can
+ introduce not only TCP errors, but also unintended changes in TCP
+ adaptive behavior.
+
+ {1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising,
+ 6 routing, 7 hard, 8 restart}
+
+2.8. Load balancers that divert/munge packets.
+
+ There is a variety of techniques that divert packets from their
+ intended IP destination, or make that destination ambiguous. The
+ motivation is typically to balance load across servers, or even to
+ split applications across servers by IP routing based on the
+ destination port number. Except for rare instances of one-shot UDP
+ protocols, these techniques are inevitably stateful as all packets
+ from the same application session need to be directed to the same
+ physical server. (However, a sophisticated solution would also be
+ able to handle failover.)
+
+ To date these techniques are proprietary and can therefore only be
+ applied in closely managed environments.
+
+
+
+Carpenter & Brim Informational [Page 10]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ {1 multi-layer, 2 implicit, 3 single hop, 4 in-line, 5 optimising, 6
+ routing, 7 hard, 8 restart}
+
+2.9. IP Firewalls
+
+ The simplest form of firewall is a router that screens and rejects
+ packets based purely on fields in the IP and Transport headers (e.g.,
+ disallow incoming traffic to certain port numbers, disallow any
+ traffic to certain subnets, etc.)
+
+ Although firewalls have not been the subject of standardisation, some
+ analysis has been done [RFC 2979].
+
+ Although a pure IP firewall does not alter the packets flowing
+ through it, by rejecting some of them it may cause connectivity
+ problems that are very hard for a user to understand and diagnose.
+
+ "Stateless" firewalls typically allow all IP fragments through since
+ they do not contain enough upper-layer header information to make a
+ filtering decision. Many "stateful" firewalls therefore reassemble
+ IP fragments (and re-fragment if necessary) in order to avoid leaking
+ fragments, particularly fragments that may exploit bugs in the
+ reassembly implementations of end receivers.
+
+ {1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
+ routing, 7 hard, 8 restart}
+
+2.10. Application Firewalls
+
+ Application-level firewalls act as a protocol end point and relay
+ (e.g., an SMTP client/server or a Web proxy agent). They may
+
+ (1) implement a "safe" subset of the protocol,
+
+ (2) perform extensive protocol validity checks,
+
+ (3) use an implementation methodology designed to minimize the
+ likelihood of bugs,
+
+ (4) run in an insulated, "safe" environment, or
+
+ (5) use some combination of these techniques in tandem.
+
+ Although firewalls have not been the subject of standardisation, some
+ analysis has been done [RFC 2979]. The issue of firewall traversal
+ using HTTP has been discussed [HTTPSUB].
+
+
+
+
+
+Carpenter & Brim Informational [Page 11]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ {1 Application layer, 2 implicit, 3 multihop, 4 in-line, 5
+ functional, 6 processing, 7 hard, 8 restart}
+
+2.11. Application-level gateways
+
+ These come in many shapes and forms. NATs require ALGs for certain
+ address-dependent protocols such as FTP; these do not change the
+ semantics of the application protocol, but carry out mechanical
+ substitution of fields. At the other end of the scale, still using
+ FTP as an example, gateways have been constructed between FTP and
+ other file transfer protocols such as the OSI and DECnet (R)
+ equivalents. In any case, such gateways need to maintain state for
+ the sessions they are handling, and if this state is lost, the
+ session will normally break irrevocably.
+
+ Some ALGs are also implemented in ways that create fragmentation
+ problems, although in this case the problem is arguably the result of
+ a deliberate layer violation (e.g., mucking with the application data
+ stream of an FTP control connection by twiddling TCP segments on the
+ fly).
+
+ {1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line,
+ 5 functional, 6 processing, 7 hard, 8 restart}
+
+2.12. Gatekeepers/ session control boxes
+
+ Particularly with the rise of IP Telephony, the need to create and
+ manage sessions other than TCP connections has arisen. In a
+ multimedia environment that has to deal with name lookup,
+ authentication, authorization, accounting, firewall traversal, and
+ sometimes media conversion, the establishment and control of a
+ session by a third-party box seems to be the inevitable solution.
+ Examples include H.323 gatekeepers [H323], SIP servers [RFC 2543] and
+ MEGACO controllers [RFC 3015].
+
+ {1 Application layer, 2 explicit, 3 multihop, 4 in-line or call-out,
+ 5 functional, 6 processing, 7 hard, 8 restart?}
+
+2.13. Transcoders
+
+ Transcoders are boxes performing some type of on-the-fly conversion
+ of application level data. Examples include the transcoding of
+ existing web pages for display on hand-held wireless devices, and
+ transcoding between various audio formats for interconnecting digital
+ mobile phones with voice-over-IP services. In many cases, such
+ transcoding cannot be done by the end-systems, and at least in the
+ case of voice, it must be done in strict real time with extremely
+ rapid failure recovery.
+
+
+
+Carpenter & Brim Informational [Page 12]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ Not all media translators are mandatory. They may simply be an
+ optimisation. For example, in the case of multicast, if all the
+ low-bandwidth receivers sit in one "corner" of the network, it would
+ be inefficient for the sender to generate two streams or send both
+ stream all the way across the network if the "thin" one is only
+ needed far away from the sender. Generally, media translators are
+ only useful if the two end systems don't have overlapping codecs or
+ if the overlapping set is not a good network match.
+
+ {1 Application layer, 2 explicit or implicit, 3 single hop, 4 in-
+ line, 5 functional, 6 processing, 7 hard?, 8 restart or failover}
+
+2.14. Proxies
+
+ HTTP1.1 [RFC 2616] defines a Web proxy as follows:
+
+ "An intermediary program which acts as both a server and a client
+ for the purpose of making requests on behalf of other clients.
+ Requests are serviced internally or by passing them on, with
+ possible translation, to other servers. A proxy MUST implement
+ both the client and server requirements of this specification. A
+ "transparent proxy" is a proxy that does not modify the request or
+ response beyond what is required for proxy authentication and
+ identification. A "non-transparent proxy" is a proxy that
+ modifies the request or response in order to provide some added
+ service to the user agent, such as group annotation services,
+ media type transformation, protocol reduction, or anonymity
+ filtering."
+
+ A Web proxy may be associated with a firewall, when the firewall does
+ not allow outgoing HTTP packets. However, HTTP makes the use of a
+ proxy "voluntary": the client must be configured to use the proxy.
+
+ Note that HTTP proxies do in fact terminate an IP packet flow and
+ recreate another one, but they fall under the definition of
+ "middlebox" given in Section 1.1 because the actual applications
+ sessions traverse them.
+
+ SIP proxies [RFC 2543] also raise some interesting issues, since they
+ can "bend" the media pipe to also serve as media translators. (A
+ proxy can modify the session description so that media no longer
+ travel end-to-end but to a designated intermediate box.)
+
+ {1 Application layer, 2 explicit (HTTP) or implicit (interception), 3
+ multihop, 4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}.
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 13]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ Note: Some so-called Web proxies have been implemented as
+ "interception" devices that intercept HTTP packets and re-issue them
+ with their own source address; like NAT and SOCKs, this can disturb
+ address-sensitive applications. Unfortunately some vendors have
+ caused confusion by mis-describing these as "transparent" proxies.
+ Interception devices are anything but transparent. See [WREC] for a
+ full discussion.
+
+2.15. Caches
+
+ Caches are of course used in many shapes and forms in the Internet,
+ and are in principle distinct from proxies. Here we refer mainly to
+ content caches, intended to optimise user response times. HTTP makes
+ provision for proxies to act as caches, by providing for both
+ expiration and re-validation mechanisms for cached content. These
+ mechanisms may be used to guarantee that specific content is not
+ cached, which is a requirement for transient content, particularly in
+ transactional applications. HTTP caching is well described in
+ Section 13 of [RFC 2616], and in the HTTP case caches and proxies are
+ inextricably mixed.
+
+ To improve optimisation, caching is not uniquely conducted between
+ the origin server and the proxy cache directly serving the user. If
+ there is a network of caches, the nearest copy of the required
+ content may be in a peer cache. For this an inter-cache protocol is
+ required. At present the most widely deployed solution is Internet
+ Cache Protocol (ICP) [RFC 2186] although there have been alternative
+ proposals such as [RFC 2756].
+
+ It can be argued that caches terminate the applications sessions, and
+ should not be counted as middleboxes (any more than we count SMTP
+ relays). However, we have arbitrarily chosen to include them since
+ they do in practice re-issue the client's HTTP request in the case of
+ a cache miss, and they are not the ultimate source of the application
+ data.
+
+ {1 Application layer, 2 explicit (if HTTP proxy caches), 3 multihop,
+ 4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}
+
+2.16. Modified DNS servers
+
+ DNS servers can play games. As long as they appear to deliver a
+ syntactically correct response to every query, they can fiddle the
+ semantics. For example, names can be made into "anycast" names by
+ arranging for them to resolve to different IP addresses in different
+ parts of the network. Or load can be shared among different members
+ of a server farm by having the local DNS server return the address of
+
+
+
+
+Carpenter & Brim Informational [Page 14]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ different servers in turn. In a NAT environment, it is not uncommon
+ for the FQDN-to-address mapping to be quite different outside and
+ inside the NAT ("two-faced DNS").
+
+ Modified DNS servers are not intermediaries in the application data
+ flow of interest. They are included here because they mean that
+ independent sessions that at one level appear to involve a single
+ host actually involve multiple hosts, which can have subtle effects.
+ State created in host A.FOR.EXAMPLE by one session may turn out not
+ to be there when a second session apparently to the same host is
+ started, because the DNS server has directed the second session
+ elsewhere.
+
+ If such a DNS server fails, users may fail over to an alternate DNS
+ server that doesn't know the same tricks, with unpredicatble results.
+
+ {1 Application layer, 2 implicit, 3 multihop, 4 in-line (on DNS query
+ path), 5 functional or optimising, 6 processing, 7 soft, 8 failover}
+
+2.17. Content and applications distribution boxes
+
+ An emerging generalisation of caching is content distribution and
+ application distribution. In this model, content (such as static web
+ content or streaming multimedia content) is replicated in advance to
+ many widely distributed servers. Further, interactive or even
+ transactional applications may be remotely replicated, with some of
+ their associated data. Since this is a recent model, it cannot be
+ said that there is an industry standard practice in this area. Some
+ of the issues are discussed in [WREC] and several new IETF activities
+ have been proposed in this area.
+
+ Content distribution solutions tend to play with URLs in one way or
+ another, and often involve a system of middleboxes - for example
+ using HTTP redirects to send a request for WWW.EXAMPLE.COM off to
+ WWW.EXAMPLE.NET, where the latter name may be an "anycast" name as
+ mentioned above, and will actually resolve in DNS to the nearest
+ instance of a content distribution box.
+
+ As with caches, it is an arbitrary choice to include these devices,
+ on the grounds that although they terminate the client session, they
+ are not the ultimate origin of the applications data.
+
+ {1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line
+ or call-out, 5 optimising, 6 routing or processing, 7 soft, 8
+ restart?}
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 15]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+2.18. Load balancers that divert/munge URLs
+
+ Like DNS tricks, URL redirects can be used to balance load among a
+ pool of servers - essentially a local version of a content
+ distribution network. Alternatively, an HTTP proxy can rewrite HTTP
+ requests to direct them to a particular member of a pool of servers.
+
+ These devices are included as middleboxes because they divert an
+ applications session in an arbitrary way.
+
+ {1 Application layer, 2 explicit, 3 single hop, 4 in-line, 5
+ functional, 6 routing, 7 soft, 8 restart}
+
+2.19. Application-level interceptors
+
+ Some forms of pseudo-proxy intercept HTTP packets and deliver them to
+ a local proxy server instead of forwarding them to the intended
+ destination. Thus the destination IP address in the packet is
+ ignored. It is hard to state whether this is a functional box (i.e.,
+ a non-standard proxy) or an optimising box (i.e., a way of forcing
+ the user to use a cache). Like any non-standard proxy, it has
+ undefined consequences in the case of dynamic or non-cacheable
+ content.
+
+ {1 Application layer, 2 implicit, 3 single hop, 4 in-line, 5
+ functional or optimising, 6 routing, 7 hard, 8 restart}
+
+2.20. Application-level multicast
+
+ Some (mainly proprietary) applications, including some approaches to
+ instant messaging, use an application-level mechanism to replicate
+ packets to multiple destinations.
+
+ An example is given in [CHU].
+
+ {1 Application layer, 2 explicit, 3 multihop, 4 in-line, 5
+ functional, 6 routing, 7 hard, 8 restart}
+
+2.21. Involuntary packet redirection
+
+ There appear to be a few instances of boxes that (based on
+ application level content or other information above the network
+ layer) redirect packets for functional reasons. For example, more
+ than one "high speed Internet" service offered in hotel rooms
+ intercepts initial HTTP requests and diverts them to an HTTP server
+ that demands payment before opening access to the Internet. These
+ boxes usually also perform NAT functions.
+
+
+
+
+Carpenter & Brim Informational [Page 16]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ {1 multi-layer, 2 implicit, 3 single hop, 4 call-out, 5 functional, 6
+ routing, 7 hard, 8 restart}
+
+2.22. Anonymisers
+
+ Anonymiser boxes can be implemented in various ways that hide the IP
+ address of the data sender or receiver. Although the implementation
+ may be distinct, this is in practice very similar to a NAT plus ALG.
+
+ {1 multi-layer, 2 implicit or explicit, 3 multihop, 4 in-line, 5
+ functional, 6 processing, 7 hard, 8 restart}
+
+2.23. Not included
+
+ Some candidates suggested for the above list were excluded for the
+ reasons given below. In general, they do not fundamentally change
+ the architectural model of packet delivery from source to
+ destination.
+
+ Bridges and switches that snoop ARP, IGMP etc. These are below the
+ IP layer, but use a layer violation to emulate network layer
+ functions. They do not change IP layer functions.
+
+ Wiretaps and snoopers in general - if they are working correctly,
+ they have no impact on traffic, so do not require analysis.
+
+ Mobile IP home agents are intended to assist packet delivery to the
+ originally desired destination, so they are excluded on the same
+ grounds as standard routers.
+
+ Relays in interplanetary networks - although these would certainly
+ appear to be middleboxes, they are not currently deployed.
+
+2.24. Summary of facets
+
+ By tabulating the rough classifications above, we observe that of the
+ 22 classes of middlebox described:
+
+ 17 are application or multi-layer
+ 16 are implicit (and others are explicit OR implicit)
+ 17 are multi-hop
+ 21 are in-line; call-out is rare
+ 18 are functional; pure optimisation is rare
+ Routing & processing are evenly split
+ 16 have hard state
+ 21 must restart session on failure
+
+
+
+
+
+Carpenter & Brim Informational [Page 17]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ We can deduce that current types of middlebox are predominantly
+ application layer devices not designed as part of the relevant
+ protocol, performing required functions, maintaining hard state, and
+ aborting user sessions when they crash. Indeed this represents a
+ profound challenge to the end-to-end hourglass model.
+
+3. Ongoing work in the IETF and elsewhere
+
+ Apart from work cited in references above, current or planned work in
+ the IETF includes:
+
+ MIDCOM - a working group with focus on the architectural framework
+ and the requirements for the protocol between a requesting device and
+ a middlebox and the architectural framework for the interface between
+ a middlebox and a policy entity [MIDFRAME, MIDARCH]. This may
+ interact with session control issues [SIPFIRE].
+
+ Work is also proceeding outside the MIDCOM group on middlebox
+ discovery [MIDDISC].
+
+ WEBI (Web Intermediaries) - a working group that addresses specific
+ issues in the world wide web infrastructure (as identified by the
+ WREC working group), by providing generic mechanisms which are useful
+ in several application domains (e.g., proxies, content delivery
+ surrogates). Specific mechanisms will be Intermediary Discovery and
+ Description and a Resource Update Protocol.
+
+ Intermediaries are also an important focus in the development of XML
+ Protocol by the World-Wide Web Consortium, who have published an
+ interesting analysis [XMLPI].
+
+ OPES (Open Pluggable Extension Services) - a proposed working group
+ whose output will enable construction of services executed on
+ application data by participating transit intermediaries. Caching is
+ the most basic intermediary service, one that requires a basic
+ understanding of application semantics by the cache server.
+
+ CDI (Content Distribution Internetworking) is a potential working
+ group for allowing cooperation between different Content Distribution
+ Networks and cache clusters [CDNP].
+
+ RSERPOOL (Reliable Server Pooling) is a working group that will
+ define architecture and requirements for management and access to
+ server pools, including requirements from a variety of applications,
+ building blocks and interfaces, different styles of pooling, security
+ requirements and performance requirements, such as failover times and
+ coping with heterogeneous latencies.
+
+
+
+
+Carpenter & Brim Informational [Page 18]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+4. Comments and Issues
+
+ A review of the list in Section 2 suggests that middleboxes fit into
+ one or more of three broad categories:
+
+ 1) mechanisms to connect dissimilar networks to enable cross-protocol
+ interoperability;
+
+ 2) mechanisms to separate similar networks into zones, especially
+ security zones;
+
+ 3) performance enhancement.
+
+ As observed in [RFC 2775], the rise of middleboxes puts into question
+ the general applicability of the end-to-end principle [RFC 1958].
+ Middleboxes introduce dependencies and hidden points of failure that
+ violate the fate-sharing aspect of the end-to-end principle. Can we
+ define architectural principles that guarantee robustness in the
+ presence of middleboxes?
+
+4.1. The end to end principle under challenge
+
+ Many forms of middlebox are explicitly addressed at the IP level, and
+ terminate a transport connection (or act as a final destination for
+ UDP packets) in a normal way. Although they are potential single
+ points of failure, they do not otherwise interfere with the end to
+ end principle [RFC 1958]. (This statement does not apply to
+ transport relays or TCP spoofers; they do not terminate a transport
+ connection at the expected destination in the normal way.)
+
+ However, there is a general feeling that middleboxes that divert an
+ IP packet from its intended destination, or substantively modify its
+ content on the fly, are fundamentally different from those that
+ correctly terminate a transport connection and carry out their
+ manipulations at applications level. Such diversion or modification
+ violates the basic architectural assumption that packets flow from
+ source to destination essentially unchanged (except for time-to-live
+ and QOS-related fields). The effects of such changes on transport
+ and applications is unpredictable in the general case. Much of the
+ analysis that applies to NAT [RFC 2993, RFC 3027] will also apply to
+ RSIP, NAT-PT, DSTM, SOCKS, and involuntary packet redirectors.
+ Interception proxies, anonymisers, and some types of load balancer
+ can also have subtle effects on address-sensitive applications, when
+ they cause packets to be delivered to or from a different address.
+ Transport relays and TCP spoofers may deceive applications by
+ delivering an unreliable service on a TCP socket.
+
+
+
+
+
+Carpenter & Brim Informational [Page 19]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ We conclude that:
+
+ Although the rise of middleboxes has negative impact on the end to
+ end principle at the packet level, it does not nullify it as a
+ useful or desirable principle of applications protocol design.
+ However, future application protocols should be designed in
+ recognition of the likely presence of network address translation,
+ packet diversion, and packet level firewalls, along the data path.
+
+4.2. Failure handling
+
+ If a middlebox fails, it is desirable that the effect on sessions
+ currently in progress should be inconvenient rather than
+ catastrophic. There appear to be three approaches to achieve this:
+
+ Soft state mechanisms. The session continues in the absence of
+ the box, probably with reduced performance, until the necessary
+ session state is recreated automatically in an alternative box (or
+ the original one, restarted). In other words the state
+ information optimises the user session but is not essential. An
+ example might be a true caching mechanism, whose temporary failure
+ only reduces performance.
+
+ Rapid failover mechanisms. The session is promptly redirected to
+ a hot spare box, which already has a copy of the necessary session
+ state.
+
+ Rapid restart mechanisms. The two ends of the session promptly
+ detect the failure and themselves restart the session via a spare
+ box, without being externally redirected. Enough session state is
+ kept at each end to recover from the glitch.
+
+ It appears likely that "optimising" middleboxes are suitable
+ candidates for the soft state approach and for non-real-time data
+ streams, since the consequence of failure of the box is not
+ catastrophic for the user. (Configured HTTP proxies used as caches
+ are an awkward case, as their failure causes client failure.) On the
+ other hand, "functional" middleboxes must be present for the session
+ to continue, so they are candidates for rapid failover or rapid
+ restart mechanisms. We conclude that:
+
+ Middlebox design should include a clear mechanism for dealing with
+ failure.
+
+
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 20]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+4.3. Failures at multiple layers
+
+ Difficulties occur when middlebox functions occur at different
+ layers, for example the following situation, where B and C are not in
+ the same physical box:
+
+ Apps layer: A ------------------------> C ------> D
+
+ Lower layer: A -----> B -------------------------> D
+
+ When all is well, i.e., there is an IP path from A to B to C to D and
+ both B and C are working, this may appear quite workable. But the
+ failure modes are very challenging. For example, if there is a
+ network failure between C and D, how is B instructed to divert the
+ session to a backup box for C?. Since C and B function at different
+ protocol layers, there is no expectation that they will have
+ coordinated failure recovery mechanisms. Unless this is remedied in
+ some general way, we conclude that
+
+ Middlebox failure recovery mechanisms cannot currently assume they
+ will get any help from other layers, and must have their own means
+ of dealing with failures in other layers.
+
+ In the long term future, we should be able to state clearly for
+ each middlebox function what it expects from its environment, and
+ make recommendations about which middlebox functions should be
+ bound together if deployed.
+
+4.4. Multihop application protocols
+
+ We can also observe that protocols such as SMTP, UUCP, and NNTP have
+ always worked hop-by-hop, i.e., via multiple middleboxes. Nobody
+ considers this to be an issue or a problem. Difficulties arise when
+ inserting a middlebox in an application protocol stream that was not
+ designed for it. We conclude that:
+
+ New application protocol designs should include explicit
+ mechanisms for the insertion of middleboxes, and should consider
+ the facets identified in Section 2 above as part of the design.
+
+ A specific challenge is how to make interactive or real-time
+ applications ride smoothly over middleboxes. This will put
+ particular stress on the failure handling aspects.
+
+
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 21]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+4.5. Common features
+
+ Given that the IP layer - the neck of the hourglass - is no longer
+ alone in its role supporting end-to-end connectivity, it would be
+ desirable to define requirements and features that are common to
+ middlebox intermediaries. It would then be possible to implement
+ middleboxes, and in particular the protocols that communicate with
+ them, fully from the stance of supporting the end-to-end principle.
+ Conceptually, this would extend the neck of the hourglass upwards to
+ include a set of common features available to all (or many)
+ applications. In the context of middleboxes and multihop protocols,
+ this would require common features addressing at least:
+
+ Middlebox discovery and monitoring
+ Middlebox configuration and control
+ Call-out
+ Routing preferences
+ Failover and restart handling
+ Security, including mutual authentication
+
+ As far as possible, the solutions in these areas being developed in
+ the IETF and W3C should be sufficiently general to cover all types of
+ middlebox; if not, the work will be done several times.
+
+5. Security Considerations
+
+ Security risks are specific to each type of middlebox, so little can
+ be said in general. Of course, adding extra boxes in the
+ communication path creates extra points of attack, reduces or
+ eliminates the ability to perform end to end encryption, and
+ complicates trust models and key distribution models. Thus, every
+ middlebox design requires particular attention to security analysis.
+ A few general points can be made:
+
+ 1. The interference with end-to-end packet transmission by many types
+ of middlebox is a crippling impediment to generalised use of IPSEC
+ in its present form, and also invalidates transport layer security
+ in many scenarios.
+
+ 2. Middleboxes require us to move definitively from a two-way to an
+ N-way approach to trust relationships and key sharing.
+
+ 3. The management and configuration mechanisms of middleboxes are a
+ tempting point of attack, and must be strongly defended.
+
+ These points suggest that we need a whole new approach to security
+ solutions as the middlebox paradigm ends up being deployed in lots of
+ different technologies, if only to avoid each new technology
+
+
+
+Carpenter & Brim Informational [Page 22]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ designing a end-to-end security solution appropriate to its
+ particular impact on the data stream.
+
+ Additionally, content caches and content distribution mechanisms
+ raise the issue of access control for content that is subject to
+ copyright or other rights. Distributed authentication, authorisation
+ and accounting are required.
+
+6. Acknowledgements
+
+ Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik Faltstrom,
+ Henning Schulzrinne, and Lixia Zhang all gave valuable feedback on
+ early versions of this document. Rob Austein and Allison Mankin
+ drafted the text on transport relays and TCP spoofers, and Rob
+ Austein made other substantial contributions. Participants in the
+ MIDTAX BOF at the 50th IETF and on the MIDTAX mailing list, including
+ Harald Alverstrand, Stanislav Shalunov, Michael Smirnov, Jeff Parker,
+ Sandy Murphy, David Martin, Phil Neumiller, Eric Travis, Ed Bowen,
+ Sally Floyd, Ian Cooper, Mike Fisk and Eric Fleischman gave
+ invaluable input. Mark Nottingham brought the W3C work to our
+ attention. Melinda Shore suggested using a facet-based
+ categorization. Patrik Faltstrom inspired section 4.3.
+
+7. References
+
+ [RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
+ 1812, June 1995.
+
+ [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and
+ L. Jones, "SOCKS Protocol Version 5", March 1996.
+
+ [RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
+ RFC 1958, June 1996.
+
+ [RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
+ version 2", RFC 2186, September 1997.
+
+ [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
+ and W. Weiss, "An Architecture for Differentiated
+ Service", RFC 2475, December 1998.
+
+ [RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
+ Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
+ March 1999.
+
+ [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+
+
+Carpenter & Brim Informational [Page 23]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations", RFC
+ 2663, August 1999.
+
+ [RFC 2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
+ (HTCP/0.0)", RFC 2756, January 2000.
+
+ [RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address
+ Translation - Protocol Translation (NAT-PT)", RFC 2766,
+ February 2000.
+
+ [RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February
+ 2000.
+
+ [RFC 2979] Freed, N., "Behavior of and Requirements for Internet
+ Firewalls", RFC 2979, October 2000.
+
+ [RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC
+ 2983, October 2000.
+
+ [RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
+ November 2000.
+
+ [RFC 3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B.
+ and J. Segers, "Megaco Protocol 1.0", RFC 3015, November
+ 2000.
+
+ [RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
+ Address Translator (Traditional NAT)", RFC 3022, January
+ 2001.
+
+ [RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
+ with the IP Network Address Translator", RFC 3027, January
+ 2001.
+
+ [CHU] Y. Chu, S. Rao, and H. Zhang, A Case for End System
+ Multicast, SIGMETRICS, June 2000.
+ http://citeseer.nj.nec.com/chu00case.html
+
+ [CLARK88] The Design Philosophy of the DARPA Internet Protocols,
+ D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4,
+ August 1988, pages 106-114 (reprinted in ACM CCR Vol 25,
+ Number 1, January 1995, pages 102-111).
+
+ [CLARK95] "Adding Service Discrimination to the Internet", D.D.
+ Clark, Proceedings of the 23rd Annual Telecommunications
+ Policy Research Conference (TPRC), Solomons, MD, October
+ 1995.
+
+
+
+Carpenter & Brim Informational [Page 24]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ [CDNP] M. Day, et al., "A Model for Content Internetworking
+ (CDI)", Work in Progress.
+
+ [DSTM] J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A.
+ Durand, "Dual Stack Transition Mechanism (DSTM)", Work in
+ Progress.
+
+ [H323] ITU-T Recommendation H.323: "Packet Based Multimedia
+ Communication Systems".
+
+ [HOURG] "Realizing the Information Future: The Internet and
+ Beyond", Computer Science and Telecommunications Board,
+ National Research Council, Washington, D.C., National
+ Academy Press, 1994. However, the "hourglass" metaphor was
+ first used by John Aschenbrenner in 1979, with reference
+ to the ISO Open Systems Interconnection model.
+
+ [HTTPSUB] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
+ RFC 3205, February 2002.
+
+ [MIDARCH] E. Lear, "A Middlebox Architectural Framework", Work in
+ Progress.
+
+ [MIDDISC] E. Lear, "Requirements for Discovering Middleboxes", Work
+ in Progress.
+
+ [MIDFRAME] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A.
+ Rayhan, "Middlebox Communication: Framework and
+ Requirements", Work in Progress.
+
+ [PILCPEP] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
+ Shelby, "Performance Enhancing Proxies Intended to
+ Mitigate Link-Related Degradations", RFC 3135, June 2001.
+
+ [RSIP] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
+ "Realm Specific IP: Framework", RFC 3102, October 2001.
+
+ [SALTZER] End-To-End Arguments in System Design, J.H. Saltzer,
+ D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November
+ 1984, pp 277-288.
+
+ [SIPFIRE] S. Moyer, D. Marples, S. Tsang, J. Katz, P. Gurung, T.
+ Cheng, A. Dutta, H. Schulzrinne, A. Roychowdhury,
+ "Framework Draft for Networked Appliances Using the
+ Session Initiation Protocol", Work in Progress.
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 25]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+ [SOCKS6] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
+ RFC 3089, April 2001.
+
+ [TRANS64] "Overview of Transition Techniques for IPv6-only to Talk
+ to IPv4-only Communication", Work in Progress.
+
+ [WREC] Cooper, I, Melve, I. and G. Tomlinson, "Internet Web
+ Replication and Caching Taxonomy", RFC 3040, January 2001.
+
+ [XMLPI] Intermediaries and XML Protocol, Mark Nottingham, Work in
+ Progress at http://lists.w3.org/Archives/Public/xml-dist-
+ app/2001Mar/0045.html
+
+Authors' Addresses
+
+ Brian E. Carpenter
+ IBM Zurich Research Laboratory
+ Saeumerstrasse 4 / Postfach
+ 8803 Rueschlikon
+ Switzerland
+
+ EMail: brian@hursley.ibm.com
+
+
+ Scott W. Brim
+ 146 Honness Lane
+ Ithaca, NY 14850
+ USA
+
+ EMail: sbrim@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 26]
+
+RFC 3234 Middleboxes: Taxonomy and Issues February 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter & Brim Informational [Page 27]
+
generated by cgit v1.2.1 (git 2.18.0) at 2026-11-02 04:52:40 +0000