idnits 2.17.1 draft-ietf-ipv6-scope-api-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2002) is 7953 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BASIC-API' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCOPE-ARCH' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group R.E. Gilligan 2 INTERNET-DRAFT: draft-ietf-ipv6-scope-api-00.txt Cache Flow 3 S. Thomson 4 Cisco 5 J. Bound 6 J. McCann 7 Hewlett-Packard 8 W. R. Stevens 9 July 2002 11 Scoped Address Extensions to the IPv6 Basic Socket API 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 This document is a submission by the Internet Protocol IPv6 Working 21 Group of the Internet Engineering Task Force (IETF). Comments should 22 be submitted to the ipng@sunroof.eng.sun.com mailing list. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document specifies a set of extensions to the basic IPv6 sockets 43 API for the support of scoped addresses. 45 Table of Contents: 47 1. Introduction.................................................3 48 2. API Extensions...............................................3 49 2.1. sin6_scope_id..............................................3 50 2.2. getaddrinfo()..............................................3 51 2.3. getnameinfo()..............................................3 52 3. Summary of New Definitions...................................4 53 4. Security Considerations......................................4 54 5. IANA Considerations..........................................4 55 Acknowledgments.................................................4 56 References......................................................4 57 Authors' Addresses..............................................4 59 1. Introduction 61 This document specifies a set of extensions to the basic IPv6 sockets 62 API for the support of scoped addresses. 64 The material contained in this document was originally specified in 65 [BASIC-API], causing [SCOPE-ARCH] to be a normative reference for 66 [BASIC-API]. To allow [BASIC-API] to proceed independently of 67 [SCOPE-ARCH], the relevant material was removed from [BASIC-API] and 68 moved to this document. 70 2. API Extensions 72 2.1. sin6_scope_id 74 The definition of the sin6_scope_id is extended as follows: 76 - The sin6_scope_id field of the sockaddr_in6 structure contains 77 a zone index [SCOPE-ARCH] as appropriate for the scope of the 78 address carried in the sin6_addr field. For a link scope 79 sin6_addr, sin6_scope_id would contain a link index. For a 80 site scope sin6_addr, sin6_scope_id would contain a site index. 81 The value zero in the sin6_scope_id field represents a default 82 zone. 84 2.2. getaddrinfo() 86 The definition of the getaddrinfo() function is extended as follows: 88 - If the specified address family is AF_INET6 or AF_UNSPEC, the 89 nodename argument may use the format defined for textual 90 representation of scoped IPv6 addresses [SCOPE-ARCH]. 92 2.3. getnameinfo() 94 The definition of the getnameinfo() function is extended as follows: 96 - When the numeric form of a node's address is returned, if the 97 sa argument is an IPv6 address, the returned nodename may use 98 the format defined for textual representation of scoped IPv6 99 addresses [SCOPE-ARCH]. 101 - If the flag bit NI_NUMERICSCOPE is set in the flags argument 102 of getnameinfo(), the numeric form of the scope identifier shall 103 be returned (for example, link index) instead of its name. 104 This flag is ignored if the sa argument is not an IPv6 address. 105 The NI_NUMERICSCOPE flag is defined in . 107 3. Summary of New Definitions 109 The following list summarizes the constants, structure, and extern 110 definitions discussed in this memo, sorted by header. 112 NI_NUMERICSCOPE 114 4. Security Considerations 116 None. 118 5. IANA Considerations 120 None. 122 Acknowledgments 124 This document contains material originally specified in [BASIC-API]. 125 The authors of and all contributors to that document are gratefully 126 acknowledged. 128 References 130 [BASIC-API] Gilligan, R., et al. "Basic Socket Interface Extensions 131 for IPv6", Work in Progress 133 [SCOPE-ARCH] Deering, S., et al. "IPv6 Scoped Address Architecture", 134 Work in Progress 136 Authors' Addresses 138 Bob Gilligan 139 Cacheflow, Inc. 140 650 Almanor Ave. 141 Sunnyvale, CA 94086 142 Telephone: 408-220-2084 (voice) 143 408-220-2250 (fax) 144 Email: gilligan@cacheflow.com 146 Susan Thomson 147 Cisco Systems 148 499 Thornall Street, 8th floor 149 Edison, NJ 08837 150 Telephone: 732-635-3086 151 Email: sethomso@cisco.com 152 Jim Bound 153 Hewlett-Packard Company 154 110 Spitbrook Road ZKO3-3/W20 155 Nashua, NH 03062 156 Telephone: 603-884-0062 157 Email: Jim.Bound@hp.com 159 Jack McCann 160 Hewlett-Packard Company 161 110 Spitbrook Road ZKO3-3/W20 162 Nashua, NH 03062 163 Telephone: 603-884-2608 164 Email: Jack.McCann@hp.com