>>>>> On Tue, 26 Jun 2001 14:20:48 +0200 (CEST), >>>>> Erik Nordmark <[EMAIL PROTECTED]> said: >> If possible, I'd like to see the next revision of the draft before the >> next IETF meeting in London. So my question is: >> >> does anyone (especially in the authors) try to revise the draft now? > I'd like to see the document finished. But I don't have any cycles > to actually drive the open issues to conclusion. > If folks can agree on text to add/change I can do the editing of the document. > Or I can take on a co-author that will help drive this to conclusion > and also do the edits. Okay, then I'll try to drive the discussion, and, if necessary, will contribute the result as text. >> - Add credits for UDP MTU stuff >> - Move information about mapping from inet6_opt to setsockopt and >> cmsg. >> >> What exactly do these two items mean? > The issue about UDP MTU for DNS servers was brought up > by somebody on this list and there was a separate I-D (expired long time ago) > which had one proposal for this. The document should give due credit to > that individual. I searched for the materials in the web, and got the following items: Subject: (IPng 1494) BSD API spec/Path MTU From: "Thomas Narten" <[EMAIL PROTECTED]> Date: Wed, 28 Feb 1996 09:22:43 -0400 http://www.wcug.wwu.edu/lists/ipng/199602/msg00158.html "Forcing Fragmentation to Network MTU" by Mark Andrews <draft-ietf-ipngwg-bsd-frag-01.txt> which can be found at http://www.join.uni-muenster.de/JOIN/ipv6/drafts/draft-ietf-ipngwg-bsd-frag-01.txt Are these the ones we are looking for? > The second one is about the structure of the document. > The inet6_opt routines are described as having to do with ancillary data > and in a separate place it is pointed out that the routines > also apply to the same information in setsockopt. This organization could > be better. I'm still not sure about it, but (for example) are you talking about the following paragraph, When using ancillary data a Hop-by-hop options is passed between the application and the kernel as follows: The cmsg_level member will be IPPROTO_IPV6 and the cmsg_type member will be IPV6_HOPOPTS. These options are then processed by calling the inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_val() functions, described in Section 10.6. (in Section 8.1) intending that we should mention socket option cases as well? By the way, I found some typo in the 02 version: 8.2. Sending Hop-by-Hop Options All the Hop-by-Hop options must specified by a single ancillary data object. The cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is set to IPV6_HOPOPTS. The option is normally constructed using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_set_val() functions, described in inet6_set_val() should be inet6_opt_set_val(). 9.2. Sending Destination Options The Destination options are normally constructed using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_set_val() functions, described in Section 10. Same here. >> - Fix Authors address wrt Rich. >> >> It's an editorial issue. (But what is the best "address" for him?) > I don't know what is traditionally done in cases like this > thus any guidance would be quite helpful. If he is listed > as an author we need to say something in the address section. > Alternatively we can list him at the top of the acknowldgement section > e.g. with something like > Previous versions of this document [RFC 2292] was co-authored by > the late Rich Stevens. I don't know a common sense in such a case, either. rfc2553bis has the same issue, and the latest draft simply removed his address. >> - Specify "change" for TCP especially when there are multiple HBH >> option headers etc. >> >> ??? what does "multiple HBH option headers" mean? The IPv6 spec >> requirs a HBH option header appear only once in a single packet. Is >> this a typo, and should this be "multiple DST option headers"? > I guess the comment is generic - applies indepedently of the type of > repeated extension headers. > Is there really something in RFC 2460 which says that packets with multiple > HBH headers should be dropped? I believe the last sentence of the following paragraph in RFC2460 specifies the behavior: If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. So, we should be able to assume we'll never see multiple hop-by-hop options headers in the API layer. BTW, I mentioned a same kind of issue for the sending size far back in the past, and your answer was "implentation defined", with which I'm okay (see a comment about Section 8.2 in the attached message below.) >> - If the home address option passed out in If so >> what address value does it contain? >> >> As I said above, I'd prefer a separate option if we really need to >> pass the home address to applications. > I'd be fine with that approach. This means adding some text to say that > the home address option should not be passed to the application when > the application has specified IPV6_RECVDSTOPTS?, right? > Or do you envision two different mechanisms by which the application can > receive this information? Oops, sorry, I was a bit confused. I meant how to pass the care-of address to the application. As for the home address, it should be passed to the application as if it was really in the source address field of the IPv6 header (e.g. in the "from" address returned by recvmsg, or through the getpeername function), if I remember correclty a succeeding discussion. Anyway, the home address option (if any) should be passed 'as is' to the application that specifies IPV6_RECVDSTOPTS, IMO. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED]
Thanks for all the careful comments. I'll fix the ones I'm not explicitly including in the reply (and most of the ones below as well - I just thought I should respond to your comments explicitly on these ones). > 2.1.2. IPv6 Extension Headers > > I think it would be useful to define a generic structure to specify > IPv6 extension headers, since we sometimes encounter a situation where > we can't detect the type of an extension header but should deal with > the header. As an example, here is the KAME's structure for this > purpose: > > struct ip6_ext { > u_char ip6e_nxt; > u_char ip6e_len; > }; I will add that unless somebody disagrees. > 2.1.3. IPv6 Options > (snip) > /* IPv6 options */ > structip6_opt { > uint8_tip6o_type; > uint8_tip6o_len; > }; > > There seems to be lack of white spaces in the above code. Yes, lots of whitespace is missing in the structures. I sent an email about this to ipng back in November when I realized the bug. > 2.2.1. ICMPv6 Type and Code Values > ... > #define ICMP6_MEMBERSHIP_QUERY 130 > #define ICMP6_MEMBERSHIP_REPORT 131 > #define ICMP6_MEMBERSHIP_REDUCTION 132 > > These macro names are based on terms of IGMPv2, not MLD. So I prefer > the names like the followings: > > #define MLD_LISTENER_QUERY 130 > #define MLD_LISTENER_REPORT 131 > #define MLD_LISTENER_DONE 132 > > I don't necessarily argue that the old names should be removed. I'm > glad if the latter names are *added* in the specification. I'll switch to the new ones. If implementations want to provide the old as well as new they can do that. But we don't want to clutter up the specification. > 2.2.2. ICMPv6 Neighbor Discovery Type and Code Values > > #define ND_OPT_PI_FLAG_ONLINK 0x80 > #define ND_OPT_PI_FLAG_AUTO 0x40 > > We may have to define macro names for the "Router Address bit" used in > mobile-ipv6 and the "Site Prefix flag" used in the > ipngwg-site-prefixes draft. > (I'm not sure this is good since they are not officially > standardized. This is just a comment.) My take is that if we are pretty sure that things will become a standard we can add it to the API. Thus I added router renumbering stuff and I should add the mobile IPv6 pieces. But I might hold off for a while on icmp name lookups and site prefixes so we can see what will happen with those. If somebody wants to convince me that the WG will approve of that work I'm game to add it to the API spec. So I'll add ND_OPT_PI_FLAG_ROUTER. Is there something else missing from the mobile IPv6 specification? > 2.2.3. Multicast Listener Discovery Type and Code Values > > Although the section title contains "Type and Code Values", there are > no such definitions in this section. Only a struture for MLD headers > and short cut macros are defined. Is this your intention? > (it may be good to define MLD_LISTENER_QUERY, etc in this section.) OK. I'll move the type definition down to be consistent across the section. > 2.2.4. ICMPv6 Router Renumbering Type and Code Values > > Again, there are no "Type and Code Values" definitions in this > section. > > FYI, we use the following definition to specify the type of router > renumbering in the KAME implementation: > > #define ICMP6_ROUTER_RENUMBERING 138 /* router renumbering */ I'll add that one. > /* PCI code values */ > #define RPM_PCO_ADD 1 > #define RPM_PCO_CHANGE 2 > #define RPM_PCO_SETGLOBAL 3 > > I think that "PCI" in the comment line is misspelled and should be > "PCO" (Prefix Control Operations). Ack. > 4. Access to IPv6 and Extension Headers > > Two different mechanisms exist for sending this optional information: > > 1. Using setsockopt to specify the option content for a socket. > These are known an "sticky" options since they affect all > transmitted packets on the socket until either the a new > setsockopt is done or the options are overridden using ancillary > data. > > When an error occurs during a process of setting a sticky option > (e.g. length mismatch), should a previously specified value of the > option (if any) be kept or be cleared anyway? I guess it should be > kept, but I'm not sure about this point from the draft. (Note that > IPv4 implementation in 4.4 BSD always clears existing IPv4 options > regardless of the result of overriding procedure.) What do others think? Should we specify this amount of detail? > 6. Packet Information > > An > application can clear any sticky IPV6_PKTINFO option by either doing > a setsockopt for option with optlen being zero, or by doing a > "regular" setsockopt with ipi6_addr being in6addr_any and > ipi6_ifindex being zero. > > Is the latter way necessary? This prohibits implementation from > specifing the unspecified address as source address. (I'm not sure if > it should be allowed, but it might be useful for some purposes.) Since PKTINFO contains two pieces of information (ifindex and source address) and applications might only want to set one of the two the semantics of ipi6_ifindex = X (X != 0) and ipi6_addr is all zero (unpspecified) must mean "the application does not want to control the source address". Thus you can't really use this to set the source address to the unspecified address. > 6.1. Specifying/Receiving the Interface > > When the IPV6_PKTINFO socket option is enabled, the received > interface index is always returned as the ipi6_ifindex member of the > in6_pktinfo structure. > > Is the option name (IPV6_PKTINFO) correct? Shouldn't it be > IPV6_RECVPKTINFO? Yes. Good catch. I'll fix. > 6.3. Specifying/Receiving the Hop Limit > > In this section, there is no (explicit) description of how to clear an > existing IPV6_HOPLIMIT sticky option. If specifying -1 is the only > way, it would be better to clearly state the fact in the draft. I'll add that. Using a zero length option should also work. > 6.4. Specifying the Next Hop Address > > There is no description of how to remove an existing IPV6_NEXTHOP > sticky option in this section. I guess that it can be removed by > specifying the option with optlen being zero. I'll add that. > Three functions build a Routing header: > > inet6_rth_space() - return #bytes required for Routing header > inet6_rth_init() - initialize buffer data for Routing header > inet6_rth_add() - add one IPv6 address to the Routing header > > It might be better to define an additional function to finalize a > Routing header, since we don't necessary know the number of > intermediate hops when initialization. Actually, I encountered such a > situtaion when implementing source routing in traceroute. Note that we > don't necessarily have to define a new function; we can extend > inet6_rth_add() so that the function updates all fields (at least > including the header length field) of the routing header each time it > is called. If you don't know the number of hops before starting to build the routing header you don't know how much memory to allocate for the option/ancillary data. Thus I think applications like traceroute first need to parse its arguments to get a list of hops (e.g. stored in an array) and then build the routing header. > To receive a Routing header the application must enable the > IPV6_RECVRTHDR socket option: > > int on = 1; > setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); > > There chould be two or more routing headers in a received packet > (although this wouldn't usually happen). How can we access the second, > third, ... routing headers? Is the each routing header stored in a > separate ancillary data object? Or are all the routing headers stored > in a single object? If the latter is the case, how do we access the > second, third, ... routing headers in the single ancillary data object > (with the defined library functions only)? The API isn't really designed to deal with anything but the recommended way of doing extension headers i.e. at most one hbh header, at most one destination header before a routing header, at most one routing header, and at most one destination header after the routing header. For transmitting it is impossible to construct something different than the above using the API. While the receive side could provide more I don't see any reason to specify that in the API. (But if I ever felt the urge to implement something like that having one ancillary data item per extension header would make the most sense - and keeping the ancillary data items in the order the extension headers were received in the packet.) > Also, the description of the function is a bit unclear to me. It only > mentions how the address fields are changed. Are other fields > (especially the segment-left field) also updated? Or should a caller > adjust the fields by itself in order to reuse (e.g. resend) the > header? In our implementation, I took the former approach; the value > of the segment-left field will be changed to the number of segments in > the function procedure. The intent was the former. I will add: The function reverses the order of the addresses and sets the segleft member in the new Routing header to the number of segments. > 8.2. Sending Hop-by-Hop Options > > All the Hop-by-Hop options must specified by a single ancillary data > object. > > What should the kernel do if an ancillary data contains multiple > IPV6_HOPOPTS objects? Should it take just one of them or should it > discard the entire ancillary data and return an error? If the former > is the case, which one should the kernel take? I don't really care and I don't see a good reason for nailing down this behavior in the specification. "Implementation defined". > 9.1. Receiving Destination Options > > All the Destination options appearing before a Routing header are > returned as one ancillary data object described by a cmsghdr > structure (with cmsg_type set to IPV6_RTHDRDSTOPTS) and all the > Destination options appearing after a Routing header (or in a packet > without a Routing header) are returned as another ancillary data > object described by a cmsghdr structure (with cmsg_type set to > IPV6_DSTOPTS). > > A same kind of question of receiving multiple routing headers can be > applied to the destination options header as well; How can we access > the second, third, ... destination options headers before/after a > routing header? Also, if there is more than one routing header in a > received packet and there is a destination options header between two > routing headers, which part is the destination options header > regarded as, before a routing header or after? And the same type of answer applies. > 9.2. Sending Destination Options > > As described in Section 6 one set of Destination options can appear > before a Routing header, and one set can appear after a Routing > header (or in a packet with no Routing header). Each set can consist > of one or more options but each set is a single extension header. > > What should the kernel do if an ancillary data contains multiple > IPV6_DSTOPTS or IPV6_RTHDRDSTOPTS objects? Should it take just one of > them or should it discard the entire ancillary data and return an > error? If the former is the case, which one should the kernel take? Implementation defined. > 10.1. inet6_opt_init > > int inet6_opt_init(void *extbuf, size_t extlen); > > This function returns the number of bytes needed for the empty > extension header i.e. without any options. If extbuf is not NULL it > also initializes the extension header to have the correct length > field. If the extlen value is not a positive (i.e., non-zero) > multiple of 8 the function fails and returns -1. > > In spite of the last sentence, the sample code in section 24.1 passes > 0 as the second argument of the function: The intent is that is extbuf is not NULL then extlen has to satisfy the above requirement. I'll clarify. > The align parameter must have a value of 1, 2, 4, or 8. The align > value can not exceed the value of len. > > Is this enough to implement all "Xn + Y" alignment requirements? For > example, can we specify "4n + 3" as alignment requirement using a > single alignment parameter? It is sufficient to specify all alignments according to the rules of appendix B in the IPv6 specification. In addition on Xn+Y that spec says "order the fields from smallest to largest". If you have an option with alignment 4n+3 it's size must be 4m+1 to follow the rules in appendix B. In that case you set len to 4m+1 and align to 4. (The rules in appendix B requires an option with alignment Xn+Y to end at a multiple of X bytes, which is why Y doesn't have to be specified.) > 10.4. inet6_opt_set_val > > Databuf should be a pointer returned by inet6_opt_append(). This > function inserts data items of various sizes (1, 2, 4, or 8 bytes) in > the data portion of the option. > > "(1, 2, 4, or 8 bytes)" seems confusing; it can be interpreted that > only the 4 sizes can be specified. I think it would be better to > simply remove the parenthesis. While I see the point this statement in RFC 2460 o One desirable feature is that any multi-octet fields within the Option Data area of an option be aligned on their natural boundaries, i.e., fields of width n octets should be placed at an integer multiple of n octets from the start of the Hop-by- Hop or Destination Options header, for n = 1, 2, 4, or 8. seems to imply that those are the only supported sizes of the option data. If we don't have that constraint you could interpret the above to mean that a 5 octet value should be aligned on its natural boundary i.e. a 5 octet alignment. While I think you could align it on a multiple of 5 from the beginning of the option that carries that value, you can't both do this and have it be aligned on a multiple of 5 bytes from the beginning of the option header or from the beginning of the packet. So if somebody is designing options with data items that are not a power of two in size they need to decide which power of two they need for alignment. But I guess your point is that they should be able to use inet6_opt_set_val to set e.g. a 5 byte value. Point taken. I just have to think about how to describe this in a concise way. > 10.5. inet6_opt_next > > This function parses received extension headers returning the next > option. > > Since the function is used only for HbH/Destination options headers, > it would be better to replace "received extension headers" with "(a) > received options header(s)". > > When there are no more options the return value is -1. > > What if an error occurs? Also -1. I'll add that. > 10.7. inet6_opt_get_val > > This function extracts data items of various sizes > (1, 2, 4, or 8 bytes) in the data portion of the option. > > Again, I think it would be better to remove the parenthesis (see the > first comment on section 10.4.) I'll try to come up with concise text. > XXX Perhaps we should add a note to point out that > robust receivers should verify alignment before calling > inet6_opt_get_val(). XXX Or check alignment and fail by returning > -1? > > I think the former is better, since we can't assume that the function > knows the alignment requirements for all options (including ones > defined in the future and unstandardized options.) While the function doesn't know the alignment of future option content it could verify that they have natural alignment i.e. that an N octet field (for N = 1,2,4,8) is aligned on an N octet boundary. > In our implementation the function always uses memcpy to copy the data > (i.e. not using cast to a specific type) for safety. My draft implementation also uses bcopy. > 15. Summary of New Definitions > > <netinet/in.h> int inet6_opt_append(void *, size_t, int, > uint8_t, size_t, uint_8, void > **); > > I think the type of the sixth argument should be "uint8_t", not > "uint_8". Actually, uint_t is the correct type. > 23.1. Sending a Routing Header > > The six values in the column beneath node S are the values in the > Routing header specified by the sending application using sendmsg() > of setsockopt(). The function calls by the sender would look like: > > void *extptr; > int extlen; > struct msghdr msg; > ... > > The variable "extptr" is declared but unused in the example. This > should be "optptr", or all the occurrences of "optptr" should be > replaced with "extptr". Ack. optlen/extlen has the same issue. I'll use "ext*" since it is the length and pointer to the extension header. Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
