idnits 2.17.1 draft-melnikov-nsap-ipv6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 247. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC1277, updated by this document, for RFC5378 checks: 1991-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2006) is 6675 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPV6' is defined on line 168, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1888 (Obsoleted by RFC 4048) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Network Address to support OSI over IPv6 D. Wilson 3 Document: draft-melnikov-nsap-ipv6-02 S. Kille 4 Expires: July 2006 A. Melnikov 5 Intended category: Standard Track Isode Ltd. 6 Updates: RFC 1277 January 2006 8 Network Address to support OSI over IPv6 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 A revised version of this draft document will be submitted to the RFC 34 editor as a Proposed Standard for the Internet Community. Discussion 35 and suggestions for improvement are requested, and should be sent 36 directly to the authors. Distribution of this draft is unlimited. 38 Abstract 40 This document defines a format for OSI NSAP Addresses for use where 41 TCP or UDP is used to provide the OSI Network Service over IPv6, as 42 in RFC 2126 (ISO Transport Service on top of TCP (ITOT)). This 43 requires encoding of an IPv6 address and a port number in the NSAP. 44 RFC 1277 defines an NSAP format for use with IPv4 addresses, and this 45 document updates RFC 1277 to allow for IPv6 addresses. 47 1. Introduction 48 1.1. Conventions Used in this Document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 54 Editorial comments/questions or missing paragraphs are marked in the 55 text with << and >>. 57 1.2. Rationale 59 [ITOT] defines a mechanism for the OSI upper layers to use Transport 60 Classes 0 and 2 using TCP as the Network Service. In this case the 61 Network Service Access Point (NSAP) address is effectively defined by 62 the IP address and TCP port number. 64 It would be possible to have a local mechanism to map from arbitrary 65 network addresses to the required TCP/IP information. However, this 66 is not practical for wide-area connections. Therefore, a mechanism 67 which encodes the TCP/IP addressing information with the NSAP address 68 is to be preferred. [RFC1277] provides such an embedding mechanism. 69 However, it only supports IPv4 addresses. 71 There are places where NSAP addresses are carried in protocol. The 72 preferred concrete syntax for NSAP addresses uses 20 octets. IPv6 73 addresses are 16 octets long, and TCP port numbers require 2 octets. 74 Therefore there are only two octets free to define the address 75 ([ISO8348]). 77 [RFC1888] defines a format for embedding IPv6 addresses into NSAP 78 addresses. However, this format defines a IDI of two octets, leaving 79 one octet for the network selector. So there is insufficient space in 80 the network selector for the TCP port number. To use the domain 81 identifier for part of the TCP port number does not seem an elegant 82 solution. 84 However, this NSAP address format could be used if the default port 85 for the service is implied. Implementations of ITOT SHOULD interpret 86 NSAP addresses in this format as implying the use of IPv6 with the 87 default port. 89 The only other defined Authority and Format Indicator (AFI) which 90 leaves suffient space for both an IPv6 address and TCP port number is 91 the binary local AFI (49). However, using this format may conflict 92 with other uses of this AFI on some systems, if they support multiple 93 network services and the local AFI is use on one of these. 95 Therefore, in order to support OSI transport over IPv6 to non-default 96 ports we need a new NSAP address format. 98 2. NSAPA for IPv6 address and port 100 The Initial Domain Part (IDP) consists of one octet AFI (<>) and a one octet IDI. The IDI is used to 102 distinguish different uses of the address and port contained in the 103 Domain Specific Part. For ITOT, the IDI value of 0 is used. Further 104 values for this field are to be assigned by the IANA on an IETF 105 consensus basis [RFC2434]. 107 The Domain Specific Part (DSP) consists of two fields: 16 octet IPv6 108 address in network byte order, followed by 2 octet port number in 109 network byte order. The TCP port number takes over the function of 110 the network selector. If the port number field is 0, the port number 111 defaults to the value defined in [ITOT]. 113 An NSAPA with the <> AFI code is converted to an IPv6 address by 114 stripping off the first and the twentieth octets. 116 0 1 2 3 117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 0-3 | AFI = <> | IDI | IPv6 (byte 0-1) | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 4-7 | IPv6 (bytes 2-5) | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 8-11 | IPv6 (bytes 6-9) | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 12-15| IPv6 (bytes 10-13) | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 16-19| IPv6 (bytes 14-15) | Port (2 bytes) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 3. Security Considerations 132 <> 135 4. IANA Considerations 137 IANA is requested to add AFI <> to the registry of the OSI 138 NSAPAs: 139 . 141 The following IDI should be registered under this AFI: 143 IDI Value Address Encoding Format Definition 144 ---------- ----------------- ---------------------------- 145 '0' IPv6 , section 2 147 <> 150 Remaining decimal values '1' through '99'<> MUST be assigned on an 151 IETF consensus basis [RFC2434]. 153 5. Acknowledgments 155 This document borrows some text from RFC 1277 [RFC1277] and RFC 1888 156 [RFC1888]. 158 6. References 160 6.1. Normative references 162 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", RFC 2119, March 1997. 165 [RFC1277] Kille, S., "Encoding Network Addresses to support operation 166 over non-OSI lower layers", RFC 1277, November 1991. 168 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 169 (IPv6) Specification", RFC 2460, December 1998. 171 Hinden,, R., and S. Deeing, "IP Version 6 Addressing Architecture", 172 RFC 2373, April 2003. 174 [ITOT] Pouffary, Y. and A. Young, "ISO Transport Service on top of 175 TCP (ITOT)", RFC 2126, March 1997. 177 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 178 Internet Protocol", RFC 2401, November 1998. 180 [RFC2434] RFC 2434, "Guidelines for Writing an IANA Considerations 181 Section in RFCs", Thomas Narten and Harald Alvestrand, October 1998. 183 6.2. Informative references 185 [RFC1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. 186 and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. 188 [ISO8348] ISO. "International Standard 8348. Information Processing 189 Systems - Open Systems Interconnection: Network Service Definition." 190 [ITU Recommendation X.213] 192 7. Author's Addresses 194 David Wilson 195 Steve Kille 196 Alexey Melnikov 198 Isode Ltd. 199 5 Castle Business Village, 200 36 Station Road, 201 Hampton, Middlesex, 202 TW12 2BX, United Kingdom 204 8. Full Copyright Statement 206 Copyright (C) The Internet Society (2006). 208 This document is subject to the rights, licenses and restrictions 209 contained in BCP 78, and except as set forth therein, the authors 210 retain all their rights. 212 This document and the information contained herein are provided on an 213 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 214 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 215 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 216 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 217 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 218 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 220 Acknowledgement 222 Funding for the RFC Editor function is currently provided by the 223 Internet Society. 225 9. Intellectual Property 227 The IETF takes no position regarding the validity or scope of any 228 Intellectual Property Rights or other rights that might be claimed to 229 pertain to the implementation or use of the technology described in 230 this document or the extent to which any license under such rights 231 might or might not be available; nor does it represent that it has 232 made any independent effort to identify any such rights. Information 233 on the procedures with respect to rights in RFC documents can be 234 found in BCP 78 and BCP 79. 236 Copies of IPR disclosures made to the IETF Secretariat and any 237 assurances of licenses to be made available, or the result of an 238 attempt made to obtain a general license or permission for the use of 239 such proprietary rights by implementers or users of this 240 specification can be obtained from the IETF on-line IPR repository at 241 http://www.ietf.org/ipr. 243 The IETF invites any interested party to bring to its attention any 244 copyrights, patents or patent applications, or other proprietary 245 rights that may cover technology that may be required to implement 246 this standard. Please address the information to the IETF at ietf- 247 ipr@ietf.org.