2553bis (Basic API) status and plan
2553bis (Basic API) status and plan: As mentioned in Margaret's recent mail about the IPv6 WG Priority List: >Basic Sockets Extensions >Status: In IESG for Informational, update may be > required to resolve normative reference The current Basic API draft (draft-ietf-ipngwg-rfc2553bis-05.txt) contains normative references to the Scoped Addressing Architecture (draft-ietf-ipngwg-scoping-arch-04.txt). In particular, it relies on the definition of zone indices, and on the scoped address text format defined in that document. This was flagged as an issue during IESG review. To allow 2553bis to move forward and be published as an RFC without having to wait on the scoping-arch document, we've proposed to move those portions of the Basic API that rely on scoping-arch into a separate document that can advance alongside the scoping-arch document. There are 4 items that will move from 2553bis to the new "scoping api" document: 1. References to the terms "link index" and "site index" in the definition of the sin6_scope_id field. Note that the sin6_scope_id field will remain in 2553bis. 2. Use of the scoped address text format with getaddrinfo(). 3. Use of the scoped address text format with getnameinfo(). 4. The NI_NUMERICSCOPE flag. Note that these items were added in 2553bis after RFC 2553 was published, so we won't be regressing from that RFC. This will also have the effect of bringing 2553bis closer to the Single UNIX Specification version 3 (a.k.a. "Austin"), which does not specify the use of the scoped address text format with getaddrinfo/getnameinfo. We can present the new "scoping api" document to the Austin standards process for incorporation in a future revision of that standard. Unless there is substantial objection to this approach, you will see two drafts pop out after the IETF next week: another revision of 2553bis (should be the final revision), and a new, very short, draft containing the api extensions for the scoped address architecture. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: WG Last Call for Basic Sockets API: draft-ietf-ipngwg-rfc2553bis-06.txt
Here is summary of major changes from rfc2553bis-05 to rfc2553bis-06: . Add brief description of the evolution of this API and its relation to the Open Group/IEEE/ISO standards. . More alignments with [3]: - [3] does not contain protocol family definitions (PF_xxx). Replaced PF_INET6 with AF_INET6, or removed as appropriate. . Remove references to the DNS A6 resource record type. . Fix argument names in getnameinfo() prototype to match text. . Add description text for the getnameinfo() salen argument. . Remove scoped addressing support, which will be published in a separate document. . Modified change history to reflect changes from RFC 2553 only. In preparation for publication as new RFC, the change history was modified to show changes from RFC 2553, rather than changes from bis-01 to bis-02, bis-02 to bis-03, etc. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Comment on RFC 1981-Path MTU Discovery for IPV6
>Referring to item 5.3, we think that the timestamp value need not be set >to "Reserved". The text in question is a suggestion, not a requirement. The use of a "Reserved" timestamp value is just one possible implementation of PMTU aging. Other implementations are also possible, as you have seen. FYI this text was taken from RFC 1191. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Comments on draft-ietf-ipngwg-rfc2553bis-06.txt
>>On many pages, null (the C null pointer constant) is sometimes written >>as null and sometimes NULL. Also, the ASCII NUL terminated C strings >>have different written forms. Currently the text has at least these >>variants of null/NULL: >> >> o NULL pointer >> o NULL >> o null pointer >> o null terminated name >> o null-terminated string >> o null byte >> o null >> >>For clarity, maybe all C null pointers could be written as "NULL". >>When ASCII NUL byte terminated C strings are discussed, they could all >>be written as "null-terminated string(s)". > >I'll see what I can do about this. Upon further reflection, I'd like to leave the null/NULL usage as is. Most of it is taken verbatim from the IEEE/OpenGroup/ISO standard, that would be the place to fix it. And in all cases I believe the meaning is clear (NULL pointer vs. null-terminated string). - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt
Changes from 2553bis-06 to 2553bis-07, in response to comments from IESG review and on mailing list: - section 3.3 removed the following sentence: 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. - section 3.10 fix typos: _ss_pad1 -> __ss_pad1 _ss_pad2 -> __ss_pad2 _ss_align -> __ss_align _SS_ALIGNMENT -> _SS_ALIGNSIZE - section 3.10 fix _SS_PAD2SIZE calculation for sockaddr with sa_len - section 4.4. delete this sentence: 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 as the struct if_nameindex{}. - section 5.3 fix this printf printf("IPV6_V6ONLY set0); - section 6.1 reference inet_pton instead of inet_ntop in this sentence: If the specified address family is AF_INET6 or AF_UNSPEC, standard IPv6 text forms described in inet_ntop() are valid. - section 6.1 clarify associated storage freed by freeaddrinfo includes storage pointed to by ai_canonname and ai_addr IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt
Thomas Narten wrote: >I'm asking about the second. I wonder, for example, whether someone >familiar with the POSIX/Austin Group work has reviewed the document. >My concern is that there may be some fairly trivial inconsistencies >with this document and the basic API. It would be nice to try and fix >those (if they exist). Can anyone speak to this point? So I took a look at 2292bis-07. Please note I am not speaking on behalf of posix/austin group, but rather simply as someone who has been witness to the standardization efforts there. I reviewed primarily for alignment with 2553bis and the latest posix/austin standard. I did not review, for example, correctness of constant values and data structures for match against IPv6 protocol RFCs (hopefully there have already been enough eyes that have done that). Some comments for alignment with the latest POSIX standard: - I suggest you update the Posix references, using the same reference as 2553bis, which I show below (note the spec has now also been approved by ISO): IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX) Open Group Technical Standard: Base Specifications, Issue 6 December 2001 ISO/IEC 9945-1:2002, 9945-2:2002, 9945-3:2002, 9945-4:2002 Information technology -- Portable Operating System Interface (POSIX) -- Parts 1, 2, 3 and 4 http://www.opengroup.org/austin - protocol family constants (PF_xxx) are not defined in this latest POSIX standard, replace all PF_xxx with AF_xxx (e.g. PF_INET -> AF_INET) - section 21.1 shows msg_iovlen as type size_t, the latest POSIX defines msg_iovlen as type int Some editorial comments: - section 7.1 in this sentence, CMSG_LEN should be CMSG_SPACE (see the nice diagram on page 67, an "ancillary data object" includes the padding at the end) "When the application uses ancillary data it must pass the returned length to CMSG_LEN() to determine how much memory is needed for the ancillary data object (including the cmsghdr structure)." - section 8 typo in first paragraph last sentence "Hob-by-Hop" - section 10.5 inet6_opt_next, the statement "Typep points the option type field" does not seem right, for typep to point to the option type field, it would have to be passed as 'uint8_t **typep'; I think you mean it points to a buffer into which the option type is stored, or using wording similar to lenp, "typep stores the option type" - section 11.1 you should cite one or more references upon which this statement is based: "Also, path MTU discovery for multicast has severe scalability limitations and should thus be avoided by default." - the data type usage in the example code could be cleaner, for example in section 22 page 72: int extlen; int cmsglen; extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3); cmsglen = CMSG_SPACE(extlen); inet6_rth_space() returns a size_t into int extlen. int extlen is passed to CMSG_SPACE which expects unsigned int. CMSG_SPACE returns unsigned int into int cmsglen. and so on. A minor technical comment: - There is an inconsistency in the inet6_opt_set_val and inet6_opt_get_val functions. In both functions, the offset argument is type size_t, but the function return value (also an offset) is type int. Given the intended usage of these functions, where the return value of one call can be used as the offset argument on the next call, the data type of the offset argument should be type int. I also want to point out an issue that might be raised if this API is ever brought to the Austin group (IEEE/OpenGroup/ISO) for standardization. The functions and macros listed below use a variety of data types for things that represent a "size", including int, unsigned int, and size_t. All these items, or at least those of type size_t, could instead be of type socklen_t. Note that some of the items identified are for use with msg_controllen and cmsg_len, which are type socklen_t. Here is the rationale for socklen_t from the latest POSIX standard: The type socklen_t was invented to cover the range of implementations seen in the field. The intent of socklen_t is to be the type for all lengths that are naturally bounded in size; that is, that they are the length of a buffer which cannot sensibly become of massive size: network addresses, host names, string representations of these, ancillary data, control messages, and socket options are examples. Truly boundless sizes are represented by size_t as in read(), write(), and so on. All socklen_t types were originally (in BSD UNIX) of type int. During the development of IEEE Std 1003.1-2001, it was decided to change all buffer lengths to size_t, which appears at face value to make sense. When dual mode 32/64-bit systems came along, this choice unnecessarily complicated system interfaces because size_t
Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt
> - CMSG_SPACE >- return type could be socklen_t to match msg_controllen >- argument type could also be socklen_t > > - CMSG_LEN >- return type could be socklen_t to match cmsg_len type >- argument type could also be socklen_t > >Short of a changing all of these to socklen_t, we should at least >consider changing the occurances of the size_t type to either >socklen_t or int or unsigned int. This would avoid the complications >raised by size_t on systems having to support both ILP32 and LP64 models. Given that CMSG_SPACE and CMSG_LEN were defined in RFC 2292, and that their definitions have not changed in 2292bis, and that they do not used size_t, I'd vote for leaving them as is. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: one more IESG question about RFC 2553bis or 2292bis
Thomas Narten wrote: >As Jack has completed his updates to RFC 2553, I've put it back on the >IESG for consideration for publication. That prompted the following >comment from Bill Fenner. Yes, I mentioned this in my response to the last round of iesg comments on 2553bis: c. The use of sin6_flowinfo is rather underspecified. Of the 32 bits, which ones contain the traffic class and which ones contain the flow label? What's in the other 4 bits? Can I use it to set the traffic class and/or flow label for outbound packets (e.g. on a connect(), sendto() or sendmsg()? What is behavior of this field on accept/recvfrom/recvmsg? What is behavior with TCP? What is interaction with IPV6_TCLASS option from rfc2292bis? I checked the Austin spec, it does not describe the contents of the sin6_flowinfo field, other than this comment beside the field definition: uint32_t sin6_flowinfo IPv6 traffic class and flow information JINMEI Tatuya wrote: >Thus, I think the best way is > >- to remove the paragraph of 2553bis in question, and >- (if necessary) to clarify the detailed usage of sin6_flowinfo is not > defined in 2553bis because the protocol specification of flow labels > is still unclear. I agree with the latter statement, I suggest we treat it as we did the sin6_scope_id field. Change this paragraph: 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]. to this: The sin6_flowinfo field is a 32-bit field intended to contain flow-related information. The exact use of this field is not currently specified. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
rfc2553bis-07 to rfc2553bis-08 changes
There was one change from rfc2553bis-07 to rfc2553bis-08. In response to a comment from the IESG, the description of the sin6_flowinfo field was changed from: 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]. to: The sin6_flowinfo field is a 32-bit field intended to contain flow-related information. The exact use of this field is not currently specified. This in essence matches the IEEE spec, which is silent on the subject of sin6_flowinfo. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: rfc2553bis-07 to rfc2553bis-08 changes
Brian, >> There was one change from rfc2553bis-07 to rfc2553bis-08. In response >> to a comment from the IESG, the description of the sin6_flowinfo field >> was changed from: >> >> 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]. >> >> to: >> >> The sin6_flowinfo field is a 32-bit field intended to contain >> flow-related information. The exact use of this field is not >> currently specified. >> >> This in essence matches the IEEE spec, which is silent on the >> subject of sin6_flowinfo. > >I understand the problem with the old language, but the new language >is a bit disturbing too. RFC 2474 and RFC 3168 do specify 8 of these >bits, and 4 of them are inoperative in the API (the version number bits). First let me say I'm open to suggestions for better wording. While RFC 2474 and RFC 3168 specify bits in the IPv4 and IPv6 headers, they do not specify anything about the use of sin6_flowinfo to affect or retrieve those bits. The same problem exists with the original reference to RFC 2460, which specifies the format of the IPv6 header, but does not specify anything about sin6_flowinfo. Even if we assume the sin6_flowinfo field is formatted in the same way as the first 4 bytes of the IPv6 header (i.e. version, class, and flow), we still have not specified how the sin6_flowinfo field is used. So we have two choices: hold rfc2553bis while we define the use of the sin6_flowinfo field, or defer that definition to another spec as we did with sin6_scope_id (rfc2553bis-08 reflects the latter choice). - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: rfc2553bis-07 to rfc2553bis-08 changes
One more try on sin6_flowinfo for 2553bis, adopting Brian's verbage and laying the foundation for application compatibility with future use of the field: The sin6_flowinfo field is a 32-bit field intended to contain flow-related information. The exact way this field is mapped to or from a packet is not currently specified. Until such time as its use is specified, applications should set this field to zero when constructing a sockaddr_in6, and ignore this field in a sockaddr_in6 structure constructed by the system. I also propose to change the comment next to the sin6_flowinfo field in the sockaddr_in6 structure definition from: uint32_tsin6_flowinfo; /* IPv6 traffic class & flow info */ to: uint32_tsin6_flowinfo; /* IPv6 flow information */ Barring further objections, I'll plan to update the spec after tlanta IETF. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipngwg-rfc2553bis-10.txt
Itojun, > minor nit: > NI_NUMERICSCOPE appears in the text (page 24) but not in section 7. Thanks for catching that. The reference to NI_NUMERICSCOPE on page 24 should be removed, it was part of the stuff that moved to draft-ietf-ipv6-scope-api-00.txt. It may be too late to fix this... - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: (retry) rfc2553bis-00: nai_strerror() ?
>>I am sure this has been asked before. But anyway. After writing >>some code according to RFC 2553, I was wondering why there is no >>nai_strerror() function which works similar to gai_strerror(). > >We don't need an nai_strerror. We could put gai_sterror after >getnameinfo and have it apply to both set of EAI_xxx error code sets. > >Comments. We discussed this in XNET and arrived at the same conclusion: use the EAI_xxx error codes for both getaddrinfo and getnameinfo, and make the error descriptions from netdb.h/gai_strerror() generic enough to apply to both. I believe this is reflected in the update to rfc2553 (draft-ietf-ipngwg-rfc2553bis-00.txt). - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: New "IP Version 6 Addressing Architecture" draft
During w.g. last call, I suggested a change of wording in the definition of IPv4-mapped addresses (mail attached below). I see the suggestion was not incorporated in addr-arch-v3-01. Let me offer an example of what motivated my suggestion. Suppose we have 2 IPv6/IPv4 nodes: Node A has IPv6 address A::A and IPv4 address 1.2.3.4. Node B has IPv6 address B::B and IPv4 address 5.6.7.8. Node A is running a server which is listening for both IPv4 and IPv6 connections on an AF_INET6 socket. A client on node B connects to node A's IPv4 address (1.2.3.4), with packets sourced from B's IPv4 address (5.6.7.8). (Why does the client use A's IPv4 address? Perhaps it is an AF_INET application that has not yet been upgraded, or perhaps the user entered 1.2.3.4.) The server on node A accepts the connection, and because it is using AF_INET6 sockets, accept() returns B's IPv4 address as :::5.6.7.8. In this example, an IPv4-mapped address (:::5.6.7.8) is used to represent the address of an IPv6/IPv4 node (B). Is this correct usage of IPv4-mapped addresses? Or is it a violation of the architecture? - Jack >From [EMAIL PROTECTED] Thu Mar 30 13:22:09 2000 Date: Thu, 30 Mar 2000 13:16:21 -0500 (EST) From: Jack McCann <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" IPv4-mapped addresses are defined as: A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address is used to represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address"... IPv4-mapped addresses are not limited to IPv4-only nodes. They can also be used to represent the IPv4 address of an IPv6/IPv4 node, or more generally, to represent any IPv4 address in an IPv6 address format. I suggest replacing this sentence: This address is used to represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. with something like this: This address is used to represent an IPv4 address (for example, the IPv4 address of an IPv4-only or IPv6/IPv4 node) in an IPv6 address format. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPV6_USEMTU socket option
>> > struct ip6_mtuinfo { >> >struct sockaddr_in6 ip6m_addr; /* dst IPv6 address including scope */ >> >unsigned intip6m_mtu; /* path MTU in host byte order */ >> >> Is "unsigned int" appropriate here (I'm just wondering, not sure on >> this)? > >What would you like to see instead? >uint32_t? uint16_t? An observation: both icmp6_mtu and nd_opt_mtu_mtu are uint32_t. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Basic Socket Interface Extensions for IPv6,
> At the moment IBM does not plan to include NI_NUMERICSCOPE in our > implementation of getnameinfo. Comments on this interpretation of > the draft would be appreciated. I think the idea is that getnameinfo() will attempt to translate the value in the sin6_scope_id field into a text string. See section 12 in draft-ietf-ipngwg-scoping-arch-02.txt. The NI_NUMERICSCOPE flag says don't bother trying to lookup the zone name (e.g. "fe80::abc%link1"), just display the numeric form of the sin6_scope_id (e.g. "fe80::abc%1"). [As an aside, NI_NUMERICSCOPE seems like a bit of overkill, I wonder why we didn't just extend NI_NUMERICHOST to cover the scope id...] >Further, can anyone elaborate on the meaning of NI_DGRAM. The draft does >not provide an >explanation of what this flag means. Again thanks for any comments. Did you see this text in the draft, just a few lines below the NI_DGRAM definition? 2. The NI_DGRAM flag is required for the new AF_INET/AF_INET6 port numbers (for example, 512-514) that represent different services for UDP and TCP. Without the flag, what value do you return for port 512: biff or exec? - Jack McCann Compaq Tru64 UNIX Networking IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: a tiny comment on getnameinfo (rfc2553bis-03)
This is fixed in the Austin spec (http://www.opengroup.org/austin) and so should get folded back into rfc2553bis when the two specs are aligned. >Section 6.2 of draft-ietf-ipngwg-rfc2553bis-03.txt has the following >text: > > If the argument node is non-NULL and the argument nodelen is nonzero, > then the argument node points to a buffer able to contain up to nodelen > characters that will receive the node name as a null-terminated string. > If the argument node is NULL or the argument nodelen is zero, the node > name will not be returned. If the node's name cannot be located, the > numeric form of the nodes address is returned instead of its name. If > the sa argument is an IPv6 address the returned nodename may be in the > format as defined in [5]. > >However, the corresponding function prototype just described before >the paragraph does not contain the arguments "node" and "nodelen": > > int getnameinfo(const struct sockaddr *sa, socklen_t salen, > char *host, socklen_t hostlen, > char *serv, socklen_t servlen, > int flags); > >I think the notation should be consistent; if we leave the function >prototype as is, then the text should be rewritten using "host" >instead of "node", and "hostlen" instead of "nodelen". > >Similarly, a succeeding paragraph has a same kind of problem: > > If the argument service is non-NULL and the argument servicelen is > nonzero, then the argument service points to a buffer able to contain up > to servicelen characters that will receive the service name as a null- > terminated string. If the argument service is NULL or the argument > servicelen is zero, the service name will not be returned. If the > service name cannot be located, the numeric form of the service address > (for example, its port number) is returned instead of its name. > >there are no variables "service" and "servicelen" in the prototype. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-hinden-ipv6-host-load-sharing-00.txt
draft-hinden-ipv6-host-load-sharing-00.txt states: > An implementation MUST cycle through the router list in a round- > robin fashion while making sure it always returns a reachable or > a probably reachable router when one is available. I can see encouraging implementations to do some sort of load sharing, but why does it have to be round-robin, and why MUST and not SHOULD? - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: sockaddr_in6::sin6_scope_id use
>The current basic socket enhancements draft >(draft-ietf-ipngwg-2553bis-05.txt) specifies that this 32-bit integer >"identifies a set of interfaces". More specifically, a "interface index" >for a link-local scope sin6_addr, or a "site identifier" for a site-local >sin6_addr. (section 3.3) (More thoughts follow, in the draft, with no >mention of zones or zoneid.) This got fixed in IEEE Std 1003.1-2001, which says: 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, the application shall ensure that sin6_scope_id is a link index. For a site scope sin6_addr, the application shall ensure that sin6_scope_id is a site index. The mapping of sin6_scope_id to an interface or set of interfaces is implementation-defined. but I missed it when I did the 1003.1 alignment edits in 2553bis-04. 2553bis should say a "link index" for a link-local scope sin6_addr, or a "site index" for a site-local sin6_addr. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments
>While making a related change in NetBSD I noticed that although >getnameinfo() was correctly aligned with POSIX with respect to size_t >vs. socklen_t, it was apparently missed to change its `flags' argument >from int to unsigned int as part of that edit. Yes, I noticed this discrepancy between posix and rfc2553 about a year ago, and have been actively trying to "fix" the posix spec in this regard. The 'unsigned' flags argument occurred at some point during the incorporation of the IPv6 API into the Open Group's Networking Services issue 5.2 spec in 1999, and was propagated from there into the posix 1003.1-2001 spec. We've been looking back at archives to see how this change was introduced, but have not completed the e-paper trail yet. >From what I can tell, most implementations have implemented type 'int' as per the RFC, including Solaris, Windows XP, AIX, Tru64 UNIX, HP-UX, FreeBSD, OpenBSD, NetBSD, and OpenVMS. The only implementation I have seen that uses 'unsigned int' is GNU libc, which originally implemented using type 'int', but which changed to 'unsigned int' in January 2001 (I speculate this was done to align with XNS 5.2 or perhaps one of the early drafts of 1003.1-2001). Given the widespread implementation of 'int', I believe the right thing to do is get the posix spec changed, and leave rfc2553bis as is. Stay tuned, Technical Corrigenda 1 (TC1) for 1003.1-2001 is active right now, I hope to have this fixed in TC1. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipngwg-rfc2553bis-05: getnameinfo() arguments
>> Stay tuned, Technical Corrigenda 1 (TC1) for 1003.1-2001 is >> active right now, I hope to have this fixed in TC1. > >I didn't occur to me to look there earlier (shame on me), but I just >noticed your Aardvarks on that subject; unfortunately they (XBD ERN >24, XSH ERN 22) were rejected at the May meeting. In any case, I'll >be watching austin-group-l. Yup. But we have a few more days before the results are finalized, to "take issue with any decisions of the review team". - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]