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: 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: 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: 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]
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 (with long) was a
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: 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: 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: 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]
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: 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]
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-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: 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: Basic Socket Interface Extensions for IPv6, draft-ietf-ipngwg-rfc2553bis-03.txt
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: 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: (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]
