/Documentation/rfc2732.txt

  1
  2
  3
  4
  5
  6
  7Network Working Group                                        R. Hinden
  8Request for Comments: 2732                                       Nokia
  9Category: Standards Track                                 B. Carpenter
 10                                                                   IBM
 11                                                           L. Masinter
 12                                                                  AT&T
 13                                                         December 1999
 14
 15
 16               Format for Literal IPv6 Addresses in URL's
 17
 18Status of this Memo
 19
 20   This document specifies an Internet standards track protocol for the
 21   Internet community, and requests discussion and suggestions for
 22   improvements.  Please refer to the current edition of the "Internet
 23   Official Protocol Standards" (STD 1) for the standardization state
 24   and status of this protocol.  Distribution of this memo is unlimited.
 25
 26Copyright Notice
 27
 28   Copyright (C) The Internet Society (1999).  All Rights Reserved.
 29
 30Abstract
 31
 32   This document defines the format for literal IPv6 Addresses in URL's
 33   for implementation in World Wide Web browsers.  This format has been
 34   implemented in the IPv6 versions of several widely deployed browsers
 35   including Microsoft Internet Explorer, Mozilla, and Lynx.  It is also
 36   intended to be used in the IPv6 version of the service location
 37   protocol.
 38
 39   This document incudes an update to the generic syntax for Uniform
 40   Resource Identifiers defined in RFC 2396 [URL].  It defines a syntax
 41   for IPv6 addresses and allows the use of "[" and "]" within a URI
 42   explicitly for this reserved purpose.
 43
 441. Introduction
 45
 46   The textual representation defined for literal IPv6 addresses in
 47   [ARCH] is not directly compatible with URL's.  Both use ":" and "."
 48   characters as delimiters.  This document defines the format for
 49   literal IPv6 Addresses in URL's for implementation in World Wide Web
 50   browsers.  The goal is to have a format that allows easy "cut" and
 51   "paste" operations with a minimum of editing of the literal address.
 52
 53
 54
 55
 56
 57
 58Hinden, et al.              Standards Track                     [Page 1]
 59
 60RFC 2732            IPv6 Literal Addresses in URL's        December 1999
 61
 62
 63   The format defined in this document has been implemented in the IPv6
 64   versions of several widely deployed browsers including Microsoft
 65   Internet Explorer, Mozilla, and Lynx.  It is also intended to be used
 66   in the IPv6 version of the service location protocol.
 67
 681.1 Requirements
 69
 70   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
 71   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, if and where they appear
 72   in this document, are to be interpreted as described in [KEYWORDS].
 73
 74   World Wide Web browsers SHOULD implement the format of IPv6 literals
 75   in URL's defined in this document.  Other types of applications and
 76   protocols that use URL's MAY use this format.
 77
 782. Literal IPv6 Address Format in URL's Syntax
 79
 80   To use a literal IPv6 address in a URL, the literal address should be
 81   enclosed in "[" and "]" characters.  For example the following
 82   literal IPv6 addresses:
 83
 84      FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
 85      1080:0:0:0:8:800:200C:4171
 86      3ffe:2a00:100:7031::1
 87      1080::8:800:200C:417A
 88      ::192.9.5.5
 89      ::FFFF:129.144.52.38
 90      2010:836B:4179::836B:4179
 91
 92   would be represented as in the following example URLs:
 93
 94      http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html
 95      http://[1080:0:0:0:8:800:200C:417A]/index.html
 96      http://[3ffe:2a00:100:7031::1]
 97      http://[1080::8:800:200C:417A]/foo
 98      http://[::192.9.5.5]/ipng
 99      http://[::FFFF:129.144.52.38]:80/index.html
100      http://[2010:836B:4179::836B:4179]
101
1023. Changes to RFC 2396
103
104   This document updates the generic syntax for Uniform Resource
105   Identifiers defined in RFC 2396 [URL].  It defines a syntax for IPv6
106   addresses and allows the use of "[" and "]" within a URI explicitly
107   for this reserved purpose.
108
109
110
111
112
113
114Hinden, et al.              Standards Track                     [Page 2]
115
116RFC 2732            IPv6 Literal Addresses in URL's        December 1999
117
118
119   The following changes to the syntax in RFC 2396 are made:
120   (1) change the 'host' non-terminal to add an IPv6 option:
121
122      host          = hostname | IPv4address | IPv6reference
123      ipv6reference = "[" IPv6address "]"
124
125   where IPv6address is defined as in RFC2373 [ARCH].
126
127   (2) Replace the definition of 'IPv4address' with that of RFC 2373, as
128   it correctly defines an IPv4address as consisting of at most three
129   decimal digits per segment.
130
131   (3) Add "[" and "]" to the set of 'reserved' characters:
132
133      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
134                    "$" | "," | "[" | "]"
135
136   and remove them from the 'unwise' set:
137
138      unwise      = "{" | "}" | "|" | "\" | "^" | "`"
139
1404. Security Considerations
141
142   The use of this approach to represent literal IPv6 addresses in URL's
143   does not introduce any known new security concerns.
144
1455. IANA Considerations
146
147   None.
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170Hinden, et al.              Standards Track                     [Page 3]
171
172RFC 2732            IPv6 Literal Addresses in URL's        December 1999
173
174
1756. Authors' Addresses
176
177   Robert M. Hinden
178   Nokia
179   313 Fairchild Drive
180   Mountain View, CA 94043
181   USA
182
183   Phone: +1 650 625 2004
184   EMail: hinden@iprg.nokia.com
185   Web: http://www.iprg.nokia.com/~hinden
186
187
188   Brian E. Carpenter
189   IBM
190   iCAIR, Suite 150
191   1890 Maple Avenue
192   Evanston IL 60201
193   USA
194
195   EMail: brian@icair.org
196
197
198   Larry Masinter
199   AT&T Labs
200   75 Willow Road
201   Menlo Park, CA 94025
202
203   EMail: LMM@acm.org
204   Web: http://larry.masinter.net
205
2067. References
207
208   [ARCH]     Hinden, R. and  S. Deering, "IP Version 6 Addressing
209              Architecture", RFC 2373, July 1998.
210
211   [STD-PROC] Bradner, S., The Internet Standards Process -- Revision 3,
212              BCP 9, RFC 2026, October 1996.
213
214   [URL]      Fielding, R., Masinter, L. and T. Berners-Lee, "Uniform
215              Resource Identifiers: Generic Syntax", RFC 2396, August
216              1998.
217
218
219
220
221
222
223
224
225
226Hinden, et al.              Standards Track                     [Page 4]
227
228RFC 2732            IPv6 Literal Addresses in URL's        December 1999
229
230
2318. Full Copyright Statement
232
233   Copyright (C) The Internet Society (1999).  All Rights Reserved.
234
235   This document and translations of it may be copied and furnished to
236   others, and derivative works that comment on or otherwise explain it
237   or assist in its implementation may be prepared, copied, published
238   and distributed, in whole or in part, without restriction of any
239   kind, provided that the above copyright notice and this paragraph are
240   included on all such copies and derivative works.  However, this
241   document itself may not be modified in any way, such as by removing
242   the copyright notice or references to the Internet Society or other
243   Internet organizations, except as needed for the purpose of
244   developing Internet standards in which case the procedures for
245   copyrights defined in the Internet Standards process must be
246   followed, or as required to translate it into languages other than
247   English.
248
249   The limited permissions granted above are perpetual and will not be
250   revoked by the Internet Society or its successors or assigns.
251
252   This document and the information contained herein is provided on an
253   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
254   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
255   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
256   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
257   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
258
259Acknowledgement
260
261   Funding for the RFC Editor function is currently provided by the
262   Internet Society.
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Hinden, et al.              Standards Track                     [Page 5]
283