From owner-ipng@sunroof.eng.sun.com Mon Jan 3 09:43:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e03HeTZ06840 for ipng-dist; Mon, 3 Jan 2000 09:40:29 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e03HeOY06833 for ; Mon, 3 Jan 2000 09:40:24 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA29432 for ipng@sunroof.eng.sun.com; Mon, 3 Jan 2000 09:39:30 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBSFD7Y04617 for ; Tue, 28 Dec 1999 07:13:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA09329 for ; Tue, 28 Dec 1999 07:13:07 -0800 (PST) Received: from fep10-svc.tin.it (mta10-acc.tin.it [212.216.176.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14066 for ; Tue, 28 Dec 1999 08:13:06 -0700 (MST) Received: from ieee.org ([212.216.1.103]) by fep10-svc.tin.it (InterMail v4.01.01.02 201-229-111-106) with ESMTP id <19991228151304.NDKX9522.fep10-svc@ieee.org> for ; Tue, 28 Dec 1999 16:13:04 +0100 Message-ID: <3868D317.D39F593E@ieee.org> Date: Tue, 28 Dec 1999 16:11:19 +0100 From: Giuseppe Federico Rossi Organization: Studio Ing. G. F. Rossi X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Fragmentation in RFC1981 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Suppose there is an IPv6 host receiving an ICMPv6 "Packet Too Big" message with a next-hop MTU that is less than the IPv6 minimum link MTU (1280). According to RFC1981 the host must include the "Fragment Header" in the successive datagrams. In this case I do not understand if: - the fragmentation is performed by the sending host (as explained in RFC2460) or - the fragmentation is performed by the node generating the "Packet Too Big" message (where the next MTU is < 1280). In any case, does the fragmenting node generate IPv6 datagrams less than 1280 byte long ? If yes, what is the minimum (allowed) length for an IPv6 fragment ? Many thanks to all members of ipng community Best Regards Giuseppe -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 3 09:59:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e03HuUO06955 for ipng-dist; Mon, 3 Jan 2000 09:56:30 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e03HuKY06948 for ; Mon, 3 Jan 2000 09:56:20 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA02166; Mon, 3 Jan 2000 09:56:20 -0800 (PST) Date: Mon, 3 Jan 2000 09:56:20 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Fragmentation in RFC1981 To: Giuseppe Federico Rossi Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3868D317.D39F593E@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Suppose there is an IPv6 host receiving an ICMPv6 "Packet Too Big" > message with a next-hop MTU that is less than the IPv6 minimum link MTU > (1280). According to RFC1981 the host must include the "Fragment Header" > in the successive datagrams. In this case I do not understand if: > - the fragmentation is performed by the sending host (as explained in > RFC2460) > or > - the fragmentation is performed by the node generating the "Packet Too > Big" message (where the next MTU is < 1280). > In any case, does the fragmenting node generate IPv6 datagrams less than > 1280 byte long ? If yes, what is the minimum (allowed) length for an > IPv6 fragment ? The support for less than 1280 in the packet too big is there to make life a lot easier for boxes that translate between IPv6 and IPv4. Examples of such boxes/algorithms are specified in draft-ietf-ngtrans-siit-* and draft-ietf-ngtrans-natpt-*. In that case the fragmentation to less than 1280 bytes will occur on the IPv4 side of the translator. The sole purpose of the sending IPv6 node including the fragment header is to have that node assign an unique Identification value (in the fragment header) which will be carried end-to-end i.e. "translated" to the 16-bit IPv4 ID value. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 4 08:14:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e04GBxJ07598 for ipng-dist; Tue, 4 Jan 2000 08:11:59 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e04GBoY07591; Tue, 4 Jan 2000 08:11:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA01920; Tue, 4 Jan 2000 08:11:50 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01956; Tue, 4 Jan 2000 08:11:50 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id E79AF9A825; Tue, 4 Jan 2000 10:11:49 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id D753A90D82; Tue, 4 Jan 2000 10:11:49 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 6DF874FB01; Tue, 4 Jan 2000 10:11:42 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 88D374C902; Tue, 4 Jan 2000 10:11:41 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000007759; Tue, 4 Jan 2000 11:11:48 -0500 (EST) From: Jim Bound Message-Id: <200001041611.LAA0000007759@quarry.zk3.dec.com> To: members@ipv6forum.com, deployment@ipv6.org, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, Michael.Carney@east.sun.com, ipv6imp@munnari.oz.au Cc: cmj@3com.com, us-summit@ipv6forum.com, tech@ipv6forum.com Subject: IPv6 Interoperability Testing Connectathon and IPv6 US Summit Date: Tue, 04 Jan 2000 11:11:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk PLEASE DO NOT REPLY TO THIS MAIL SEND TO INDIVIDUAL LISTS ONLY OR TO CYNDI JUNG and/or I. THANK YOU......... Folks, The University of New Hampshire (UNH) will be supporting the testing of IPv6 and interoperability testing of IPv6 between multiple independent implementations at Sun Connectathon March 6-8 and the IPv6 Forum U.S. Summit at Teluride Colorado March 13-15. If implementors can make both events that would be great, but it would be ideal if the routing vendors could attend Teluride for this testing. Cyndi Jung at 3Com is driving this with UNH so please try to give IPv6 this support for the U.S. Summit. We are hoping live and breathing end user decision makers attend this event at Teluride. More details and logistics will follow later. Also UNH has added new IPv6 Mobility spec tests and Routing tests for the events too, for those that can test these parts. Implementor support is appreciated. Theme: for testing is "Lets find the bugs when all the players are on the same net with different implementations, do we all work, do some only work in their own lab, and the results are not for public consumption at either event so you can't get into marketing trouble, only implementor attendees will know the results of doing the interoperability testing, the press will not be allowed in the testing area at Telluride". thanks /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 4 23:50:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e057mFg08534 for ipng-dist; Tue, 4 Jan 2000 23:48:15 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e057m6Y08527 for ; Tue, 4 Jan 2000 23:48:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA25102 for ; Tue, 4 Jan 2000 23:48:07 -0800 (PST) Received: from experteach.de (Mail.Experteach.de [193.22.120.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15899 for ; Wed, 5 Jan 2000 00:48:04 -0700 (MST) Received: from experteach.de (195.27.89.118) by experteach.de with SMTP (Eudora Internet Mail Server 2.2.2); Wed, 5 Jan 2000 08:47:32 +0100 Received: from DE#u#ET-Message_Server by experteach.de with Novell_GroupWise; Wed, 05 Jan 2000 08:47:47 +0100 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 05 Jan 2000 08:47:04 +0100 From: "Christopher Balzereit" To: ipng@sunroof.eng.sun.com Subject: L-Bit Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e057m7Y08528 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Another painful question concerning ND-Router advertisements: For what reason should an router advertise an prefix which cannot be used for on link determination, i.e. with the L-bit in the prefix option set to zero? Does this mean that the scope of such an prefix reaches beyond the link? Thanks in advance, Christopher ####################### Dr. Christopher Balzereit, ExperTeach Gesellschaft für Netzwerkkompetenz mbH, Waldstraße 92, 63128 Dietzenbach, Tel.: 06074/858-918, Email: cbalzere@experteach.de ####################### -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 5 09:53:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e05Ho6p09060 for ipng-dist; Wed, 5 Jan 2000 09:50:06 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e05Ho1Y09053 for ; Wed, 5 Jan 2000 09:50:01 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA00643 for ipng@sunroof.eng.sun.com; Wed, 5 Jan 2000 09:49:05 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e058nZY08609 for ; Wed, 5 Jan 2000 00:49:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA13571; Wed, 5 Jan 2000 00:49:34 -0800 (PST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA21384; Wed, 5 Jan 2000 00:49:26 -0800 (PST) Received: from localhost (kame201.kame.net [203.178.141.201]) by orange.kame.net (8.9.1+3.1W/3.7W) with ESMTP id RAA21288; Wed, 5 Jan 2000 17:48:16 +0900 (JST) Date: Wed, 05 Jan 2000 17:53:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@eng.sun.com Cc: matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: comments on ipngwg-rfc2292bis-01 User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 426 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've implemented several parts of rfc2292bis-01 and would like to comment on the draft based on the implementation experiences. I don't remember all discussions about this draft in this list or in the past IETF ipngwg meetings, so some of my comments might have already been discussed. If so, I apologize in advance. Note: In the rest of this mail, lines beginning with white spaces or tab characters are citation from the draft. Other lines are comments. 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; }; 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. This should be, for example, as follows: /* IPv6 options */ struct ip6_opt { uint8_t ip6o_type; uint8_t ip6o_len; }; Moreover, all definitions of macros and structures specified in this section (2.1.3) have this kind of mistypes. 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. 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.) 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.) 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 */ /* 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). 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.) 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.) 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? 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. 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. 7. Routing Header Option This IPv6 API, however, defines eight functions that the application calls to build and examine a Routing header, and the ability to use sticky options or ancillary data to communicate this information between the application and the kernel using the IPV6_RTHDR option. "eight" in the 1st line should be "six". Though there are eight functions defined in RFC2292 to handle a routing header, we have only six functions in rfc2292bis. 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. 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)? 7.2. inet6_rth_init This function initializes the buffer pointed to by bp to contain a Routing header of the specified type and sets ip6r0_len based on the segments parameter. bp_len is only used to verify that the buffer is large enough. The ip6r0_segleft field is set to zero; inet6_rth_add() will increment it. It would be better to change all the "ip6r0_xxx" in the above paragraph to "ip6r_xxx", since ip6r0_xxx members are specific to the type-0 routing header. Though we officially have the Type 0 routing header only, I think the function specification should be as generic as possible. Upon success the return value is the pointer to the buffer (bp), and this is then used as the first argument to the next two functions. "two" in the second line should be removed, because we have only one more function (i.e. inet6_rth_add) for building the header. The current text seems to be a relic in RFC2292. 7.4. inet6_rth_reverse int inet6_rth_reverse(const void *in, void *out) This line should be terminated by a semi-colon (`;') if we try to be consistent with other prototypes in the draft. 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. 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? 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? 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? Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently ignore when sending packets unless a Routing header is also "ignore" in the second line seems to be a typo and should be "ignored". 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: currentlen = inet6_opt_init(NULL, 0); In our implementation, I allowed 0 only when the first argument is NULL. But I'm not sure this is the correct behavior. This should be clarified in the next draft, anyway. 10.2. inet6_opt_append type is the 8-bit option type. len is the length of the option data (i.e. excluding the option type and option length fields). "type" and "len" at the beginning of the sentences might have to be capitalized (I'm not sure this is really correct, but many other sentences in the draft begin with capitalized variable names.) 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? 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. val should point to the data to be inserted. Offset specifies where in the data portion of the option ... "val" might have to be capitalized (see the first comment on 10.2). 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? 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.) val should point to the destination for the extracted data. "val" might have to be capitalized (see the first comment on 10.2). 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.) In our implementation the function always uses memcpy to copy the data (i.e. not using cast to a specific type) for safety. 11.1. Sending with the Minimum MTU This specification defines a mechanism to avoid fragmentation by sending at the minimum IPv6 MTU (1280 bytes). "avoid fragmentation" seems to contradict with the motivation of the socket option. Shouldn't this be "avoid path MTU discovery"? Also, it would be better to just refer a specification of the minimum MTU (maybe RFC2460) rather than to state a specific value (i.e. 1280 bytes.) 15. Summary of New Definitions 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". 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". 23.2. Receiving Routing Headers if (msg.msg_controllen != 0 && cmsgptr->cmsg_level == IPPROTO_IPV6 && cmsgptr->cmsg_type == IPV6_RTHDR) { struct in6_addr *in6; char asciiname[INET6_ADDRSTRLEN]; struct ip6_rthdr0 *rthdr; rthdr = (struct ip6_rthdr0 *)optptr; ... I think the type of the variable "rthdr" should be "struct ip6_rthdr *" instead of "struct ip6_rthdr0 *" for the same reason of the first comment on section 7.2. 24.2. Parsing received options int print_opt(void *extbuf, size_t extlen) { ip6_dest_t *ext; ... ext = (ip6_dest_t *)extbuf; The type "ip6_dest_t" is not standardized. Why not just use "struct ip6_dest" here? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 5 12:49:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e05Kjff09297 for ipng-dist; Wed, 5 Jan 2000 12:45:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e05KjUY09290 for ; Wed, 5 Jan 2000 12:45:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA27152 for ; Wed, 5 Jan 2000 12:45:29 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04837 for ; Wed, 5 Jan 2000 12:45:29 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA05160; Wed, 5 Jan 2000 12:45:14 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA08989; Wed, 5 Jan 2000 12:45:14 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id MAA03764; Wed, 5 Jan 2000 12:45:12 -0800 (PST) Date: Wed, 5 Jan 2000 12:45:12 -0800 (PST) From: Tim Hartrick Message-Id: <200001052045.MAA03764@feller.mentat.com> To: jinmei@kame.net Subject: Re: comments on ipngwg-rfc2292bis-01 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > 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 am not sure how useful this really is given the fact that there is no requirement that all extension headers be structured in this way. It is fine for hop-by-hop options, destination options and routing headers but it is not generally useful. > > 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.) > Indeed. If someone wants to implement DAD in user space then they need to be able to specify IN6ADDR_ANY as the source. One could always use ancillary data for that purpose and avoid sticky options I suppose, but it would be best I think, if we didn't have corner cases that behaved differently between ancillary data and sticky options. tim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 5 16:31:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e060SXV09536 for ipng-dist; Wed, 5 Jan 2000 16:28:33 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e060SMY09529 for ; Wed, 5 Jan 2000 16:28:22 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA22775; Wed, 5 Jan 2000 16:28:05 -0800 (PST) Date: Wed, 5 Jan 2000 16:27:42 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on ipngwg-rfc2292bis-01 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: erik.nordmark@eng.sun.com, matt@3am-software.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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 > > 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 6 07:28:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06FPiS09978 for ipng-dist; Thu, 6 Jan 2000 07:25:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06FPYY09971 for ; Thu, 6 Jan 2000 07:25:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28419; Thu, 6 Jan 2000 07:25:34 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14476; Thu, 6 Jan 2000 08:25:02 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA18087; Fri, 7 Jan 2000 00:13:14 +0900 (JST) Date: Fri, 07 Jan 2000 00:29:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 In-Reply-To: In your message of "Wed, 5 Jan 2000 16:27:42 -0800 (PST)" References: User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 317 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 5 Jan 2000 16:27:42 -0800 (PST), >>>>> Erik Nordmark said: >> 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. I've found it in my mailbox. I missed it, sorry. >> 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. Okay, I personally don't mind to nuke old ones. > 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. Okay, I can live without official definitions for name lookups and site prefixes. > So I'll add ND_OPT_PI_FLAG_ROUTER. > Is there something else missing from the mobile IPv6 specification? Sorry, I'm not an expert in mobile ip6...maybe some other people can answer this. >> 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. Hmm...okay. But I'm still confused. If an application call setsockopt(IPV6_PKTINFO) with ipi6_addr being in6addr_any and ipi6_ifindex being zero, and then call getsockopt(IPV6_PKTINFO), what should happen? Should an application get an in6_pktinfo structure with all zero values, or should it get a zero-length value? >> 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. On the second thought, I now suspect that specifying -1 can't be used for removing the option. It should mean "the kernel must always use the system default value regardless of values specified by weaker options". For example, if the IPV6_HOPLIMIT option should be stronger than IPV6_UNICAST_HOPS (we'll have to clarify such things...), specifying -1 by IPV6_HOPLIMIT means the kernel should still use the system default regardless of the value specified by IPV6_UNICAST_HOPS. So I think using a zero length option should be the only way to remove the option. >> 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. Right, but an application can first allocate an appropriate amount of space (e.g. 127 * sizeof(struct in6_addr)) and realloc when inet6_rth_add fails. But, okay, > 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. we can take this kind of approach. I don't strongly stick to the idea of a finalization function. >> 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. Exactly. > While the receive side could provide more I don't see any reason to specify > that in the API. Okay, I'm convinced. I'll note that such cases are out of scope of the API specificaiton in our documents. > (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.) Sounds reasonable, and in fact, that's the way of our current implementation. >> 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. Okay, good. >> 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". I see. I'll state our kernel's behavior (and that it's implementation dependent) in our own document. >> 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. Okay. >> 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. Okay. >> 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.) Hmm, I understand. Then it would be helpful to refer the appendix and to (more) clarify the semantics of the align parameter in the function specification. By the way, it seems to me that the Home Address Option of mobile ipv6 does not follow the guideline of Appendix B of RFC2460. According to mobileip-ipv6-09 the format is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- and its alignment requirement is 8n+6. If the length of a sub-option is smaller than 16 (and I think it is very possible), the format would break the guideline. How do you think of it? >> 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. Hmm...maybe. > 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. That's my point. The constraint seems to me too restrictive. Also, it's not an official requirement but just an appendix. If we keep the constraint in the function specification, we may need to refer the appendix and to state the restriction more clearly. > I just have to think about how to describe this in a concise way. Okay. >> 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. Ah, that's right. Maybe this depends on how we treat the constraint of the vallen parameter for inet6_opt_{get,set}_val. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 6 07:49:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06Fkkp10042 for ipng-dist; Thu, 6 Jan 2000 07:46:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06FkbY10035 for ; Thu, 6 Jan 2000 07:46:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA17856 for ; Thu, 6 Jan 2000 07:46:37 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24770 for ; Thu, 6 Jan 2000 08:46:28 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA18170; Fri, 7 Jan 2000 00:34:31 +0900 (JST) Date: Fri, 07 Jan 2000 00:50:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 In-Reply-To: In your message of "Wed, 5 Jan 2000 12:45:12 -0800 (PST)" <200001052045.MAA03764@feller.mentat.com> References: <200001052045.MAA03764@feller.mentat.com> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 78 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 5 Jan 2000 12:45:12 -0800 (PST), >>>>> Tim Hartrick said: >> 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 am not sure how useful this really is given the fact that there is no > requirement that all extension headers be structured in this way. It is > fine for hop-by-hop options, destination options and routing headers but > it is not generally useful. That's right, but (currently) the only exception is the fragment header and I think if we defined a new (variable length) extension header it would probably be formatted as above. Anyway, we are using the structure in chasing a header chain like this: while (len < off) { ip6e = (struct ip6_ext *)(packetbuf + len); switch(nxt) { case IPPROTO_FRAGMENT: len += sizeof(struct ip6_frag); break; case IPPROTO_AH: len += (ip6e->ip6e_len + 2) << 2; break; default: len += (ip6e->ip6e_len + 1) << 3; break; } nxt = ip6e->ip6e_nxt; } Despite the exception, I still believe the generic structure is useful in such a situation. But I don't strongly argue that it should be incorporated to the draft. I'd like to follow the authors' decision. >> 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.) >> > Indeed. If someone wants to implement DAD in user space then they need > to be able to specify IN6ADDR_ANY as the source. One could always use > ancillary data for that purpose and avoid sticky options I suppose, but it > would be best I think, if we didn't have corner cases that behaved differently > between ancillary data and sticky options. As I said in the previous mail, I'm now about to change my mind on this point. In6addr_any in the ipi6_addr field has already another semantics, i.e. the user doesn't want to specify the address. So we may not be able to specify the unspecified address as source using IN6_PKTINFO option/ancillary data... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 6 09:40:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06HbwG10195 for ipng-dist; Thu, 6 Jan 2000 09:37:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06HblY10188 for ; Thu, 6 Jan 2000 09:37:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA20528; Thu, 6 Jan 2000 09:37:46 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26792; Thu, 6 Jan 2000 09:37:45 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA08918; Thu, 6 Jan 2000 09:38:11 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA29757; Thu, 6 Jan 2000 09:38:10 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA04014; Thu, 6 Jan 2000 09:38:09 -0800 (PST) Date: Thu, 6 Jan 2000 09:38:09 -0800 (PST) From: Tim Hartrick Message-Id: <200001061738.JAA04014@feller.mentat.com> To: Erik.Nordmark@eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > So I'll add ND_OPT_PI_FLAG_ROUTER. > > Is there something else missing from the mobile IPv6 specification? > > Sorry, I'm not an expert in mobile ip6...maybe some other people can > answer this. > I don't have the spec in front of me but I believe that mobile IPv6 has added some options, some of which MUST be supported by implementations. I think it would be a good idea to add those option code points to the list of well known option code points. tim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 6 09:51:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06HmIp10249 for ipng-dist; Thu, 6 Jan 2000 09:48:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06Hm9Y10239 for ; Thu, 6 Jan 2000 09:48:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA23020 for ; Thu, 6 Jan 2000 09:48:08 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01897 for ; Thu, 6 Jan 2000 10:48:01 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA07052 for ; Thu, 6 Jan 2000 09:47:56 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA12766 for ; Thu, 6 Jan 2000 09:47:55 -0800 X-Virus-Scanned: Thu, 6 Jan 2000 09:47:55 -0800 Nokia Silicon Valley AntiVirus Appliance Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma012598; Thu, 6 Jan 00 09:47:46 -0800 Message-Id: <4.2.2.20000106094541.03d17030@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jan 2000 09:47:35 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Fwd: IPv6 Policy Document Review - Call for comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Not sure everyone has seen this. Bob --------------------------------------------- >Date: Wed, 8 Dec 1999 10:48:39 +1000 (EST) >From: Anne Lord >X-Sender: anne@hadrian >Reply-To: Anne Lord >To: hinden@iprg.nokia.com, deering@cisco.com >Subject: IPv6 Policy Document Review - Call for comments > > >Dear Bob, Steve, > >In collaboration with the other RIRs, APNIC is about to issue >the following 'Call for Comments' on the: Provisional IPv6 >Assignment and Allocation Policy Document - as this document >is now scheduled for public review. > >The text of the announcement is appended to this email. >However, in commencing this review, we would specifically welcome >comments from you, and members of the IPng working group. >In so doing, please feel free to distribute the text of this email to >relevant parties. > >We look forward to hearing from you. > >Best wishes, > > >Anne >Manager, Member Services >APNIC-- > > >*************************************************************************** > CALL FOR COMMENTS > FIRST REVISION OF > "PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT" >*************************************************************************** > >On 28 May 1999, the three Regional Internet Registries (APNIC, ARIN, and >RIPE NCC) made available a draft of the "Provisional IPv6 Assignment and >Allocation Policy Document". Following feedback and review from the >community, the document was amended and jointly released on 14 July 1999. >(see http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html). > >The policies contained in that document are the result of a collaborative >effort of the RIRs and their respective communities to provide a >responsible, globally consistent framework for the management of IPv6 >address space. In July 1999, on the basis of that document, IANA made the >first formal delegations of IPv6 address space to the RIRs. > >A formal review of the document was scheduled to start in October 1999, so >that early experiences of IPv6 operation and administration could be fully >evaluated and any necessary amendments made. > >APNIC now calls for comments to assist in this first review. We encourage >you, as a member of the Internet community, to re-visit this document and >we invite you to make any comments you feel would be constructive to the >development of the next version. > >In particular, APNIC seeks your comments on the following sections of the >document: > >* 4.2.3.2 Multihomed Sites > >This section was left unwritten in the first release, as there was >insufficient experience to draw on in formulating a policy. We encourage >any members of the community who have operational experience or interest in >IPv6 and multi-homing to contribute suggestions for this section. > >* 4.2.8 Allocations to NLA Registries >* 4.3.1 Assignments to End-users > >Review of these two sections is sought from members of the community who >have relevant operational experience. > >* Definition of 'transit provider' > >A definition for the above term was not included in the current document. >Comments and suggestions for an appropriate definition are encouraged. > >Finally, we also encourage you to consider the "IPv6 sub-TLA Request Form" > (http://www.apnic.net/apnic-bin/ipv6-subtla-request.pl) and provide any >comments or suggestions for improvements. > >PLEASE SEND COMMENTS BY FRIDAY 21ST JANUARY 2000. > >Discussion will take place on the "ipv6-registry" mailing list. To >subscribe to that list, send an email to with the >words "subscribe ipv6-registry" in the body of the message. If you would >prefer to make private comments, please contact Anne Lord . > >+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + >APNIC Secretariat > Tel: +61-7-3367-0490 >Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 >Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia >+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 6 10:44:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06IfmC10432 for ipng-dist; Thu, 6 Jan 2000 10:41:48 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06IfXY10425 for ; Thu, 6 Jan 2000 10:41:34 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA07010; Thu, 6 Jan 2000 10:41:16 -0800 (PST) Date: Thu, 6 Jan 2000 10:40:53 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on ipngwg-rfc2292bis-01 To: Tim Hartrick Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200001061738.JAA04014@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > I don't have the spec in front of me but I believe that mobile IPv6 has > added some options, some of which MUST be supported by implementations. I > think it would be a good idea to add those option code points to the > list of well known option code points. Those are already in 2292bis-01. But I hadn't checked the spec for the ND extensions. I found one more flag and I will add ND_RA_FLAG_HOME_AGENT and I found two more ND options and will add them and their structures #define ND_OPT_ADVINTERVAL 7 #define ND_OPT_HOMEAGENT_INFO 8 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 06:53:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07Enx511182 for ipng-dist; Fri, 7 Jan 2000 06:49:59 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07EnnY11175 for ; Fri, 7 Jan 2000 06:49:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA18720 for ; Fri, 7 Jan 2000 06:49:49 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23326 for ; Fri, 7 Jan 2000 07:49:47 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA06467; Fri, 7 Jan 2000 23:48:55 +0900 (JST) To: dhaskin@baynetworks.com, sonishi@baynetworks.com cc: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: IPv6 mib question (ipv6RouteEntry) From: itojun@iijlab.net Date: Fri, 07 Jan 2000 23:48:55 +0900 Message-ID: <6465.947256535@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have an update request about RFC2465 (IPv6 MIB), specifically ipv6RouteEntry. Due to scoped nature of some of IPv6 address (like link-local unicast, site-local unicast, and multicasts), there can be multiple IPv6 scoped address/prefix with exactly the same value can appear on IPv6 routing table. For example, I have the following IPv6 routing table (sorry for long line) on the node I'm typing this email. There are multiple entries with "fe80::/64", and "ff02::/32". They are disambiguated by its interface only. If we try to view those entries via SNMP, >fe80::@sm1/64 link#1 >fe80::@lo0/64 fe80::1@lo0 they would appear like below, at *exactly* the same MIB tree: ipv6RouteTable.ipv6RouteEntry.ipv6RouteDest.254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.0.64.0 = fe80:0:0:0:0:0:0:0 ipv6RouteTable.ipv6RouteEntry.ipv6RoutePfxLength.254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.0.64.0 = 64 bits The collision is from non-unqueness of ipv6RouteEntry, since it does not include ipv6RouteIfIndex. > ipv6RouteEntry OBJECT-TYPE > SYNTAX Ipv6RouteEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A routing entry." > INDEX { ipv6RouteDest, > ipv6RoutePfxLength, > ipv6RouteIndex } > ::= { ipv6RouteTable 1 } Is it possible to include ipv6RouteIfIndex when next revision is made? All INDEX definitions should include interface index to disambiguate MIB tree, if it is indexed by IPv6 address. Good example: ipv6UdpEntry in RFC2454 includes ipv6UdpIfIndex in INDEX entry, and there will be no collision even if you have two UDP socket listening on ff02::9 on different interface. It seems ipv6RouteEntry is the only one which does not include interface index. itojun Internet6: Destination Gateway Flags Refs Use Mtu Interface ::/96 ::1 UGRS 0 0 32976 lo0 => default fe80::240:5ff:fea0:8e08@sm1 UG 1 1886 1500 sm1 ::1 ::1 UH 4 8771 32976 lo0 ::ffff:0.0.0.0/96 ::1 UGRS 0 0 32976 lo0 3ffe:501:410::/64 link#1 UC 0 0 1500 sm1 3ffe:501:410:0:200:86ff:fe05:80fa 00:00:86:05:80:fa UHL 0 0 1500 lo0 3ffe:501:410:0:240:5ff:fea0:8e08 00:40:05:a0:8e:08 UHL 0 6 1500 sm1 3ffe:507:1:1::/64 link#1 UC 0 0 1500 sm1 3ffe:507:1:1:200:86ff:fe05:80fa 00:00:86:05:80:fa UHL 0 0 1500 lo0 3ffe:507:1:1:240:5ff:fea0:8e08 00:40:05:a0:8e:08 UHL 0 17 1500 sm1 3ffe:8020:10ff:1::/64 link#1 UC 0 0 1500 sm1 fe80::/10 ::1 UGRS 0 0 32976 lo0 fe80::@sm1/64 link#1 UC 0 0 1500 sm1 fe80::200:86ff:fe05:80fa@sm1 00:00:86:05:80:fa UHL 1 0 1500 lo0 fe80::240:5ff:fea0:8e08@sm1 00:40:05:a0:8e:08 UHL 1 44 1500 sm1 fe80::@lo0/64 fe80::1@lo0 U 0 8 32976 lo0 fec0::/10 ::1 UGRS 0 0 32976 lo0 ff01::/32 ::1 U 0 0 32976 lo0 ff02::@sm1/32 link#1 UC 0 0 1500 sm1 ff02::@lo0/32 fe80::1@lo0 UC 0 0 32976 lo0 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 09:51:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07HmqV11342 for ipng-dist; Fri, 7 Jan 2000 09:48:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07HmfY11335 for ; Fri, 7 Jan 2000 09:48:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA10187 for ; Fri, 7 Jan 2000 09:48:41 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00330 for ; Fri, 7 Jan 2000 09:48:39 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA10074; Sat, 8 Jan 2000 02:47:20 +0900 (JST) To: Dan Joyal cc: ipng@sunroof.eng.sun.com In-reply-to: djoyal's message of Fri, 07 Jan 2000 12:37:46 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 mib question (ipv6RouteEntry) From: itojun@iijlab.net Date: Sat, 08 Jan 2000 02:47:20 +0900 Message-ID: <10072.947267240@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Doesn't the INDEX component ipv6RouteIndex disambiguate the entries? I believe ipv6RouteIndex and ipv6RouteIfIndex are different thing. From what I understand from the following part, - ipv6RouteIndex is for identifying equal-cost multi path routes and - ipv6RouteIfIndex identifies interface. I do not think ipv6RouteIndex includes meaning of ipv6RouteIfIndex Why do we have to have two similar values separately? "Same network layer destination" below is a bit tricky wording. In scoped address world, I tend to believe"fe80::1 on interface 1" and "fe80::1 on interface 2" are different destination for network layer. Some may object it though... itojun --- ipv6RouteIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value which uniquely identifies the route among the routes to the same network layer destination. The way this value is chosen is implementation specific but it must be unique for ipv6RouteDest/ipv6RoutePfxLength pair and remain constant for the life of the route." ::= { ipv6RouteEntry 3 } ipv6RouteIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of ipv6IfIndex. For routes of the discard type this value can be zero." ::= { ipv6RouteEntry 4 } -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 10:04:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07I0rS11379 for ipng-dist; Fri, 7 Jan 2000 10:00:53 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07I0aY11372 for ; Fri, 7 Jan 2000 10:00:36 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA02569 for ipng@sunroof.eng.sun.com; Fri, 7 Jan 2000 09:59:39 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07Hc6Y11322 for ; Fri, 7 Jan 2000 09:38:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA10543 for ; Fri, 7 Jan 2000 09:38:05 -0800 (PST) Received: from scallop.baynetworks.com (ns5.baynetworks.com [194.133.90.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24978 for ; Fri, 7 Jan 2000 09:38:03 -0800 (PST) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id SAA00783; Fri, 7 Jan 2000 18:41:06 +0100 (MET) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id MAA11498; Fri, 7 Jan 2000 12:33:09 -0500 (EST) Received: from milwaukee.engeast (milwaukee [192.32.148.56]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA21636; Fri, 7 Jan 2000 12:37:47 -0500 for Received: from localhost by milwaukee.engeast (SMI-8.6/SMI-SVR4) id MAA24762; Fri, 7 Jan 2000 12:37:46 -0500 Date: Fri, 7 Jan 2000 12:37:46 -0500 (EST) From: Dan Joyal X-Sender: djoyal@milwaukee To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 mib question (ipv6RouteEntry) In-Reply-To: <6465.947256535@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun, Doesn't the INDEX component ipv6RouteIndex disambiguate the entries? -Dan On Fri, 7 Jan 2000 itojun@iijlab.net wrote: > > Hello, I have an update request about RFC2465 (IPv6 MIB), specifically > ipv6RouteEntry. > > Due to scoped nature of some of IPv6 address (like link-local unicast, > site-local unicast, and multicasts), there can be multiple IPv6 > scoped address/prefix with exactly the same value can appear on > IPv6 routing table. > For example, I have the following IPv6 routing table (sorry for long > line) on the node I'm typing this email. > There are multiple entries with "fe80::/64", and "ff02::/32". They > are disambiguated by its interface only. > > If we try to view those entries via SNMP, > >fe80::@sm1/64 link#1 > >fe80::@lo0/64 fe80::1@lo0 > > they would appear like below, at *exactly* the same MIB tree: > ipv6RouteTable.ipv6RouteEntry.ipv6RouteDest.254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.0.64.0 = fe80:0:0:0:0:0:0:0 > ipv6RouteTable.ipv6RouteEntry.ipv6RoutePfxLength.254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.0.64.0 = 64 bits > > > The collision is from non-unqueness of ipv6RouteEntry, since it does > not include ipv6RouteIfIndex. > > > ipv6RouteEntry OBJECT-TYPE > > SYNTAX Ipv6RouteEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "A routing entry." > > INDEX { ipv6RouteDest, > > ipv6RoutePfxLength, > > ipv6RouteIndex } > > ::= { ipv6RouteTable 1 } > > Is it possible to include ipv6RouteIfIndex when next revision is made? > > All INDEX definitions should include interface index to disambiguate > MIB tree, if it is indexed by IPv6 address. Good example: > ipv6UdpEntry in RFC2454 includes ipv6UdpIfIndex in INDEX entry, > and there will be no collision even if you have two UDP socket > listening on ff02::9 on different interface. > It seems ipv6RouteEntry is the only one which does not include > interface index. > > itojun > > > Internet6: > Destination Gateway Flags Refs Use Mtu Interface > ::/96 ::1 UGRS 0 0 32976 lo0 => > default fe80::240:5ff:fea0:8e08@sm1 UG 1 1886 1500 sm1 > ::1 ::1 UH 4 8771 32976 lo0 > ::ffff:0.0.0.0/96 ::1 UGRS 0 0 32976 lo0 > 3ffe:501:410::/64 link#1 UC 0 0 1500 sm1 > 3ffe:501:410:0:200:86ff:fe05:80fa 00:00:86:05:80:fa UHL 0 0 1500 lo0 > 3ffe:501:410:0:240:5ff:fea0:8e08 00:40:05:a0:8e:08 UHL 0 6 1500 sm1 > 3ffe:507:1:1::/64 link#1 UC 0 0 1500 sm1 > 3ffe:507:1:1:200:86ff:fe05:80fa 00:00:86:05:80:fa UHL 0 0 1500 lo0 > 3ffe:507:1:1:240:5ff:fea0:8e08 00:40:05:a0:8e:08 UHL 0 17 1500 sm1 > 3ffe:8020:10ff:1::/64 link#1 UC 0 0 1500 sm1 > fe80::/10 ::1 UGRS 0 0 32976 lo0 > fe80::@sm1/64 link#1 UC 0 0 1500 sm1 > fe80::200:86ff:fe05:80fa@sm1 00:00:86:05:80:fa UHL 1 0 1500 lo0 > fe80::240:5ff:fea0:8e08@sm1 00:40:05:a0:8e:08 UHL 1 44 1500 sm1 > fe80::@lo0/64 fe80::1@lo0 U 0 8 32976 lo0 > fec0::/10 ::1 UGRS 0 0 32976 lo0 > ff01::/32 ::1 U 0 0 32976 lo0 > ff02::@sm1/32 link#1 UC 0 0 1500 sm1 > ff02::@lo0/32 fe80::1@lo0 UC 0 0 32976 lo0 > > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 10:56:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07IrJB11500 for ipng-dist; Fri, 7 Jan 2000 10:53:19 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07IrAY11493 for ; Fri, 7 Jan 2000 10:53:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA28094 for ; Fri, 7 Jan 2000 10:53:08 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20219 for ; Fri, 7 Jan 2000 11:53:08 -0700 (MST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 13:53:08 -0500 Message-ID: From: Dimitry Haskin To: itojun@iijlab.net, Dan Joyal Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 mib question (ipv6RouteEntry) Date: Fri, 7 Jan 2000 13:53:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan is correct -- ipv6RouteIndex is provided to disambiguate the mib records with the same values in the ipv6RouteDest and ipv6RoutePfxLength attributes. Let me note that just adding the ipv6RouteIfIndex to the INDEX definition may not be sufficient in some cases; e.g. consider routes with the same outgoing interface but different next hops. The way ipv6RouteIndex value is chosen is implementation specific as long as it is unique for ipv6RouteDest/ipv6RoutePfxLength pair, i.e. you can't have two records with same ipv6RouteDest, ipv6RoutePfxLength, and ipv6RouteIndex in ipv6RouteTable. If you wish you can have ipv6RouteIndex equal to ipv6RouteIfIndex as long as there is a guarantee that you wouldn't get more than a single route to the same network pointing to the same outgoing interface. ---------------------------------------------------------------------- Dimitry Haskin Lucent Technologies Internetworking Systems > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Friday, January 07, 2000 12:47 PM > To: Dan Joyal > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 mib question (ipv6RouteEntry) > > > > Doesn't the INDEX component ipv6RouteIndex disambiguate the entries? > > I believe ipv6RouteIndex and ipv6RouteIfIndex are > different thing. > From what I understand from the following part, > - ipv6RouteIndex is for identifying equal-cost multi > path routes and > - ipv6RouteIfIndex identifies interface. > > I do not think ipv6RouteIndex includes meaning of > ipv6RouteIfIndex > Why do we have to have two similar values separately? > > "Same network layer destination" below is a bit tricky wording. > In scoped address world, I tend to believe"fe80::1 on > interface 1" > and "fe80::1 on interface 2" are different destination > for network > layer. Some may object it though... > > itojun > > > --- > ipv6RouteIndex OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The value which uniquely identifies the route > among the routes to the same network layer > destination. The way this value is chosen is > implementation specific but it must be unique for > ipv6RouteDest/ipv6RoutePfxLength pair and remain > constant for the life of the route." > ::= { ipv6RouteEntry 3 } > > ipv6RouteIfIndex OBJECT-TYPE > SYNTAX Ipv6IfIndexOrZero > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The index value which uniquely identifies the local > interface through which the next hop of this > route should be reached. The interface identified > by a particular value of this index is the same > interface as identified by the same value of > ipv6IfIndex. For routes of the discard type this > value can be zero." > ::= { ipv6RouteEntry 4 } > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 11:28:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07JQOL11554 for ipng-dist; Fri, 7 Jan 2000 11:26:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07JQEY11547 for ; Fri, 7 Jan 2000 11:26:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA06972 for ; Fri, 7 Jan 2000 11:26:13 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07754 for ; Fri, 7 Jan 2000 12:26:12 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id EAA13237; Sat, 8 Jan 2000 04:21:18 +0900 (JST) To: Dimitry Haskin cc: Dan Joyal , ipng@sunroof.eng.sun.com In-reply-to: dhaskin's message of Fri, 07 Jan 2000 13:53:02 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 mib question (ipv6RouteEntry) From: itojun@iijlab.net Date: Sat, 08 Jan 2000 04:21:18 +0900 Message-ID: <13235.947272878@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Dan is correct -- ipv6RouteIndex is provided to disambiguate the mib records >with the same values in the ipv6RouteDest and ipv6RoutePfxLength attributes. > >Let me note that just adding the ipv6RouteIfIndex to the INDEX definition >may not be sufficient in some cases; e.g. consider routes with the same >outgoing interface but different next hops. The way ipv6RouteIndex value is >chosen is implementation specific as long as it is unique for >ipv6RouteDest/ipv6RoutePfxLength pair, i.e. you can't have two records with >same ipv6RouteDest, ipv6RoutePfxLength, and ipv6RouteIndex in >ipv6RouteTable. > >If you wish you can have ipv6RouteIndex equal to ipv6RouteIfIndex as long as >there is a guarantee that you wouldn't get more than a single route to the >same network pointing to the same outgoing interface. Thanks for clarification. I think I needed more explicit description for ipv6RouteIndex. Please update if there'll be any revision for the document. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 18:57:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e082t2g11872 for ipng-dist; Fri, 7 Jan 2000 18:55:02 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e082soY11865 for ; Fri, 7 Jan 2000 18:54:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA16693 for ; Fri, 7 Jan 2000 18:54:49 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA01201 for ; Fri, 7 Jan 2000 19:54:47 -0700 (MST) Received: (qmail 32279 invoked by uid 8079); 8 Jan 2000 02:38:06 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Wed Dec 22 05:41:29 1999 X-UIDL: 443b42c42e9cf1dd04c31c88323014a4 Delivered-To: ry@internexus.net Received: (qmail 26666 invoked from network); 22 Dec 1999 05:41:24 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 22 Dec 1999 05:41:24 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA13927; Tue, 21 Dec 1999 21:39:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA26565; Tue, 21 Dec 1999 21:39:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM5Zja00071 for ipng-dist; Tue, 21 Dec 1999 21:35:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM5ZZY00064 for ; Tue, 21 Dec 1999 21:35:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA21915 for ; Tue, 21 Dec 1999 21:35:33 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA08673 for ; Tue, 21 Dec 1999 21:35:32 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id OAA25279; Wed, 22 Dec 1999 14:35:20 +0900 (JST) To: Mark.Andrews@iengines.com cc: ipng@sunroof.eng.sun.com In-reply-to: Mark.Andrews's message of Wed, 22 Dec 1999 15:33:27 +1100. <199912220433.PAA22627@bsdi.dv.isc.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: AI_ADDRCONFIG From: itojun@iijlab.net Date: Wed, 22 Dec 1999 14:35:20 +0900 Message-ID: <25277.945840920@coconut.itojun.org> Status: RO X-Keywords: X-UID: 1694 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Separate issue: AI_ADDRCONFIG does not seem very useful for me, as >> AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) >> configured on my host. In this case I will not be able to reach >> anyone outside via IPv6. We'd better have more text in 2553bis, that >> describes background/goal of AI_ADDRCONFIG. > Why isn't it useful? You may be looking up "localhost". > The worst that will happen is you will get network unreachable > when you try to connect / send. AI_ADDRCONFIG is an optimisation. AI_ADDRCONFIG checks list of local addresses to determine which family to return. I'm not sure if it optimizes it. It highly depends on what kind of behavior the OS kernel takes. There can be several choices in design principle level: - getaddrinfo(3) is name resolution function, this should not change behavior based on what kernel supports, what configured onto my interfaces. getaddrinfo(3) can simply return anything it have resolved via DNS. socket(2) or connect(2) may fail, user application should make a loop over whatever getaddrinfo(3) returned. - getaddrinfo(3) should mask address families that are not supported by kernel, to save from unnecessary socket(2) in user code. - getaddrinfo(3) should mask address families that are not configured onto my interfaces. this is what AI_ADDRCONFIG does. rfc2553 does not really state which is the intended behavior. I'm not sure which is the best one. I'm not sure which is the way to go. Actually kame getaddrinfo(3) implements 2nd case, but I don't really think it to be a good solution. > I do however agree that AI_ADDRCONFIG and the error states than > can result need to be better documented. agreed. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 18:58:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e082tW411881 for ipng-dist; Fri, 7 Jan 2000 18:55:32 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e082tFY11874 for ; Fri, 7 Jan 2000 18:55:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA16760 for ; Fri, 7 Jan 2000 18:55:14 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA01278 for ; Fri, 7 Jan 2000 19:55:12 -0700 (MST) Received: (qmail 32349 invoked by uid 8079); 8 Jan 2000 02:38:12 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Wed Dec 22 07:13:57 1999 X-UIDL: c81deedb8a187eebf5588af14610dd24 Delivered-To: ry@internexus.net Received: (qmail 28713 invoked from network); 22 Dec 1999 07:13:56 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 22 Dec 1999 07:13:56 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA23803; Tue, 21 Dec 1999 23:06:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA00889; Tue, 21 Dec 1999 23:06:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM72lr00122 for ipng-dist; Tue, 21 Dec 1999 23:02:47 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM72aY00115 for ; Tue, 21 Dec 1999 23:02:37 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA10129; Tue, 21 Dec 1999 23:02:34 -0800 (PST) Date: Tue, 21 Dec 1999 21:58:16 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: API suggestion To: itojun@iijlab.net Cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <23786.945834815@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO X-Keywords: X-UID: 1722 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Separate issue: AI_ADDRCONFIG does not seem very useful for me, as > AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) > configured on my host. In this case I will not be able to reach > anyone outside via IPv6. We'd better have more text in 2553bis, that > describes background/goal of AI_ADDRCONFIG. We actually had the opportunity to play with this exact issue at Sun a while back. For a while we thought we should really make AI_ADDRCONFIG mean "have addresses that can be used to communicate outside the box" but this is a bit tricky to clearly define. So instead we took the path of not configuring the IPv6 loopback address unless there is some other interface being configured for IPv6. That seems to solve the ::1 issue. But keep in mind that AI_ADDRCONFIG should really be viewed as an optimization and nothing more - avoid returning addresses to the application which we know are useless. A robust application should try all addresses that are returned from getipnodebyname/getaddrinfo. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 18:58:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e082skV11863 for ipng-dist; Fri, 7 Jan 2000 18:54:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e082sbY11856 for ; Fri, 7 Jan 2000 18:54:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA00054 for ; Fri, 7 Jan 2000 18:54:35 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA01152 for ; Fri, 7 Jan 2000 19:54:33 -0700 (MST) Received: (qmail 32259 invoked by uid 8079); 8 Jan 2000 02:38:05 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Wed Dec 22 04:41:26 1999 X-UIDL: 9fb7d95a512271bff28f6cc5fe1bf404 Delivered-To: ry@internexus.net Received: (qmail 24172 invoked from network); 22 Dec 1999 04:41:25 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 22 Dec 1999 04:41:25 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07031; Tue, 21 Dec 1999 20:39:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA22971; Tue, 21 Dec 1999 20:39:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM4aAN00046 for ipng-dist; Tue, 21 Dec 1999 20:36:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM4a1Y00039 for ; Tue, 21 Dec 1999 20:36:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA10493 for ; Tue, 21 Dec 1999 20:36:00 -0800 (PST) Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [130.155.191.233]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA20497 for ; Tue, 21 Dec 1999 20:35:58 -0800 (PST) Received: from isc.org (marka@localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.8.5/8.8.5) with ESMTP id PAA22627; Wed, 22 Dec 1999 15:33:39 +1100 (EST) Message-Id: <199912220433.PAA22627@bsdi.dv.isc.org> To: itojun@iijlab.net cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com From: Mark.Andrews@iengines.com Subject: Re: API suggestion In-reply-to: Your message of "Wed, 22 Dec 1999 12:53:35 +0900." <23786.945834815@coconut.itojun.org> Date: Wed, 22 Dec 1999 15:33:27 +1100 Status: RO X-Keywords: X-UID: 1684 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Separate issue: AI_ADDRCONFIG does not seem very useful for me, as > AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) > configured on my host. In this case I will not be able to reach > anyone outside via IPv6. We'd better have more text in 2553bis, that > describes background/goal of AI_ADDRCONFIG. Why isn't it useful? You may be looking up "localhost". The worst that will happen is you will get network unreachable when you try to connect / send. AI_ADDRCONFIG is an optimisation. I do however agree that AI_ADDRCONFIG and the error states than can result need to be better documented. Mark -- Mark Andrews, Internet Engines Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@iengines.com -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 19:11:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0838iF12759 for ipng-dist; Fri, 7 Jan 2000 19:08:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0835PY12570 for ; Fri, 7 Jan 2000 19:07:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA15935 for ; Fri, 7 Jan 2000 19:05:20 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA03735 for ; Fri, 7 Jan 2000 20:05:18 -0700 (MST) Received: (qmail 2091 invoked by uid 8079); 8 Jan 2000 02:40:34 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Dec 23 08:49:19 1999 Delivered-To: ry@internexus.net Received: (qmail 16544 invoked from network); 23 Dec 1999 08:49:17 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 23 Dec 1999 08:49:17 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA22310; Thu, 23 Dec 1999 01:45:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA18539; Thu, 23 Dec 1999 00:44:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBN8eLI02127 for ipng-dist; Thu, 23 Dec 1999 00:40:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBN8eCY02120 for ; Thu, 23 Dec 1999 00:40:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA18373 for ; Thu, 23 Dec 1999 00:40:12 -0800 (PST) Received: from experteach.de (Mail.Experteach.de [193.22.120.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA01561 for ; Thu, 23 Dec 1999 00:39:43 -0800 (PST) Received: from experteach.de (195.27.89.118) by experteach.de with SMTP (Eudora Internet Mail Server 2.2.2); Thu, 23 Dec 1999 08:38:26 +0100 Received: from DE#u#ET-Message_Server by experteach.de with Novell_GroupWise; Thu, 23 Dec 1999 08:38:41 +0100 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 23 Dec 1999 08:36:44 +0100 From: "Christopher Balzereit" To: ipng@sunroof.eng.sun.com Subject: dynamic dns Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id dBN8eDY02121 Status: O X-Keywords: X-UID: 2653 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello IPng, I apologize for the following (maybe stupid) question: If an IPv6 host is allowed to autoconfigure its machine with an arbitrary Interface ID learnig the network prefixes via ND-Router Advertisements, is there any mechanism foreseen to adjust the corresponding A6/AAAA-RR in the hosts NS (similar to DNS-Update in IPv4)? Thanks in advance, Christopher Balzereit. ####################### Dr. Christopher Balzereit, ExperTeach Gesellschaft für Netzwerkkompetenz mbH, Waldstraße 92, 63128 Dietzenbach, Tel.: 06074/858-918, Email: cbalzere@experteach.de ####################### -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 19:16:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e083Fk313348 for ipng-dist; Fri, 7 Jan 2000 19:15:46 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e083FWY13333 for ; Fri, 7 Jan 2000 19:15:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA18326 for ; Fri, 7 Jan 2000 19:15:30 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA05854 for ; Fri, 7 Jan 2000 20:15:28 -0700 (MST) Received: (qmail 3505 invoked by uid 8079); 8 Jan 2000 02:42:02 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Fri Dec 24 00:17:53 1999 Delivered-To: ry@internexus.net Received: (qmail 19741 invoked from network); 24 Dec 1999 00:17:52 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 24 Dec 1999 00:17:52 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20093; Thu, 23 Dec 1999 16:07:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA13215; Thu, 23 Dec 1999 16:06:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBO03E402721 for ipng-dist; Thu, 23 Dec 1999 16:03:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBO035Y02714 for ; Thu, 23 Dec 1999 16:03:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA01267 for ; Thu, 23 Dec 1999 16:03:05 -0800 (PST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06829 for ; Thu, 23 Dec 1999 16:03:04 -0800 (PST) Received: from ix.netcom.com (user-33qscij.dialup.mindspring.com [199.174.50.83]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA10829; Thu, 23 Dec 1999 19:02:52 -0500 (EST) Message-ID: <3862D206.EBB787CD@ix.netcom.com> Date: Thu, 23 Dec 1999 17:53:11 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Karl Auerbach CC: DOMAIN-POLICY@LISTS.INTERNIC.NET, IFWP , "ipng@sunroof.eng.sun.com" , ISI IPv6 list <6bone@ISI.EDU>, ietf@ietf.org Subject: Re: RRP Specs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O X-Keywords: X-UID: 3278 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karl and all, Karl Auerbach wrote: > > NSI has made an I-D of the RRP Protocol. > > > > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-hollenbeck-rrp-00.txt > > Am I missing something? I looked through that and I see neither > transaction identifiers nor timestamps. That alone could make > reconcilation of logs and post-mortem review of race conditions nearly > impossible. Precisely correct here Karl, and one of many deficiencies in this design document. But of course this is one of several I had pointed our some time ago before this document was published. To no avail of course. It reminds me of the lame leading the blind. And I believe I amongst a few others made this reference before as well. > > > And given the absence of a clear exchange between an existing registrar > and a new one I see a HUGE door in the transfer mechanism for registrars > to engage in what the long distance folks call "slamming" - the silent > transfer of customers from one long-distance company or registry to > another. And we have already seen this with respect to Register.com in this context already. More to come I am sure. > > > And text based? Wow, that's an open inviation to attacks based on buffer > overrun and packets split at cr-lf boundaries. Not to mention several other text based security attacks. The hack in these instances is child's play really. > > > And it is text based without any concern for internationalization. Good point here also. And one that slipped my mind... >;) > > > And its expiration date representation, although it is measured to the > millisecond, fails to include a reference to any time zone. Tisk, tisk, indeed this is a good point as well. > > > Nor does it handle IPv6. How true. > > > Seems like a rather deficient design. Looks like a design by committee, and a very poorly technically informed or knowledgeable one at that. > > > --karl-- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 19:24:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e083MbF13786 for ipng-dist; Fri, 7 Jan 2000 19:22:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e083MPY13779 for ; Fri, 7 Jan 2000 19:22:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA02018 for ; Fri, 7 Jan 2000 19:22:24 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA07191 for ; Fri, 7 Jan 2000 20:22:23 -0700 (MST) Received: (qmail 3830 invoked by uid 8079); 8 Jan 2000 02:42:25 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Fri Dec 24 09:24:09 1999 Delivered-To: ry@internexus.net Received: (qmail 2993 invoked from network); 24 Dec 1999 09:24:09 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 24 Dec 1999 09:24:09 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA29355; Fri, 24 Dec 1999 01:17:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA12074; Fri, 24 Dec 1999 01:17:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBO9DC502859 for ipng-dist; Fri, 24 Dec 1999 01:13:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBO9D2Y02852 for ; Fri, 24 Dec 1999 01:13:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA09586 for ; Fri, 24 Dec 1999 01:12:59 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA06757 for ; Fri, 24 Dec 1999 02:12:56 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA32718; Fri, 24 Dec 1999 20:12:37 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: "Christopher Balzereit" Cc: ipng@sunroof.eng.sun.com Subject: Re: dynamic dns In-Reply-To: Your message of "Thu, 23 Dec 1999 08:36:44 BST." Date: Fri, 24 Dec 1999 20:12:37 +1100 Message-Id: <27365.946026757@munnari.OZ.AU> Status: O X-Keywords: X-UID: 3424 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 23 Dec 1999 08:36:44 +0100 From: "Christopher Balzereit" Message-ID: | is there any mechanism foreseen to adjust the corresponding A6/AAAA-RR | in the hosts NS (similar to DNS-Update in IPv4)? DNS-Update isn't in IPv4, it is in the DNS. The DNS will run over both IPv6 and IPv4 in essentially the same way. DNS Update should work just as well with IPv6 as it does with IPv4. kre -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 19:51:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e083nAW14234 for ipng-dist; Fri, 7 Jan 2000 19:49:10 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e083mrY14219 for ; Fri, 7 Jan 2000 19:48:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA20342 for ; Fri, 7 Jan 2000 19:48:51 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA29955 for ; Fri, 7 Jan 2000 19:48:51 -0800 (PST) Received: (qmail 8317 invoked by uid 8079); 8 Jan 2000 02:48:59 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Tue Dec 28 19:08:02 1999 Delivered-To: ry@internexus.net Received: (qmail 22995 invoked from network); 28 Dec 1999 19:08:01 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 28 Dec 1999 19:08:01 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12706; Tue, 28 Dec 1999 12:05:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA09361; Tue, 28 Dec 1999 11:04:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBSIxun04720 for ipng-dist; Tue, 28 Dec 1999 10:59:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBSIxmY04713 for ; Tue, 28 Dec 1999 10:59:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA09053 for ; Tue, 28 Dec 1999 10:59:46 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11156 for ; Tue, 28 Dec 1999 11:59:46 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id TAA14339; Tue, 28 Dec 1999 19:59:43 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id TAA06529; Tue, 28 Dec 1999 19:59:42 +0100 (MET) Message-Id: <199912281859.TAA06529@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: "'IPng List'" Subject: Re: API suggestion In-reply-to: Your message of Tue, 21 Dec 1999 16:49:22 +0900. <5755.945762562@coconut.itojun.org> Date: Tue, 28 Dec 1999 19:59:41 +0100 Status: O X-Keywords: X-UID: 5144 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Separately, => I'd like to get standard function/macros to set/get the port field too (I already have some but they are not (yet?) standardized). we may need some function/macro that manipulates sockaddr, for: - comparing two sockaddrs at ease. family and length must match. i can think of: - address (and scope) match - port match - address (and scope) and port match - address (and scope) with certain prefix length match only. - masking address with prefix length. cmetz and francis wanted these. => I still want these (:-)! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 19:51:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e083nC314235 for ipng-dist; Fri, 7 Jan 2000 19:49:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e083muY14227 for ; Fri, 7 Jan 2000 19:48:56 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA18333 for ; Fri, 7 Jan 2000 19:48:55 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA29966 for ; Fri, 7 Jan 2000 19:48:53 -0800 (PST) Received: (qmail 8326 invoked by uid 8079); 8 Jan 2000 02:48:59 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Tue Dec 28 19:11:06 1999 Delivered-To: ry@internexus.net Received: (qmail 23156 invoked from network); 28 Dec 1999 19:11:04 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 28 Dec 1999 19:11:04 -0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23352; Tue, 28 Dec 1999 11:09:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA20274; Tue, 28 Dec 1999 11:09:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBSJ71p04754 for ipng-dist; Tue, 28 Dec 1999 11:07:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBSJ6qY04747 for ; Tue, 28 Dec 1999 11:06:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA09606 for ; Tue, 28 Dec 1999 11:06:51 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07254 for ; Tue, 28 Dec 1999 11:06:50 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id UAA14654; Tue, 28 Dec 1999 20:06:46 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA15878; Tue, 28 Dec 1999 20:06:42 +0100 (MET) Message-Id: <199912281906.UAA15878@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com Subject: Re: API suggestion In-reply-to: Your message of Wed, 22 Dec 1999 12:53:35 +0900. <23786.945834815@coconut.itojun.org> Date: Tue, 28 Dec 1999 20:06:27 +0100 Status: O X-Keywords: X-UID: 5148 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Separate issue: AI_ADDRCONFIG does not seem very useful for me, as AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) configured on my host. In this case I will not be able to reach anyone outside via IPv6. => Jean-Luc Richier has asked how to implement this and our current solution is to say IPv6 is available when the IPv6 routing table is not empty. Another solution was to use to use something like in6_interfaces (which counts non-loopback interfaces with an IPv6 address) but it was more complex and the whole issue not very clear... We'd better have more text in 2553bis, that describes background/goal of AI_ADDRCONFIG. => I *agree*! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 20:08:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0845tU15283 for ipng-dist; Fri, 7 Jan 2000 20:05:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0845fY15276 for ; Fri, 7 Jan 2000 20:05:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA16491 for ; Fri, 7 Jan 2000 20:05:41 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA04417 for ; Fri, 7 Jan 2000 20:05:39 -0800 (PST) Received: (qmail 12889 invoked by uid 8079); 8 Jan 2000 02:55:27 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Dec 30 11:57:43 1999 Delivered-To: ry@internexus.net Received: (qmail 21093 invoked from network); 30 Dec 1999 11:57:42 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 30 Dec 1999 11:57:42 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10272; Thu, 30 Dec 1999 03:54:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA20313; Thu, 30 Dec 1999 03:53:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBUBnRo05391 for ipng-dist; Thu, 30 Dec 1999 03:49:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBUBnFY05384 for ; Thu, 30 Dec 1999 03:49:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA08467 for ; Thu, 30 Dec 1999 03:49:15 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA09589 for ; Thu, 30 Dec 1999 03:49:14 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23177; Thu, 30 Dec 1999 06:49:13 -0500 (EST) Message-Id: <199912301149.GAA23177@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-iana-tla-02.txt Date: Thu, 30 Dec 1999 06:49:12 -0500 Status: O X-Keywords: X-UID: 6834 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Initial IPv6 Sub-TLA ID Assignments Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain Filename : draft-ietf-ipngwg-iana-tla-02.txt Pages : 6 Date : 29-Dec-99 This document defines initial assignments of IPv6 Sub-TLA Aggregation Identifiers (Sub-TLA ID) to the Address Registries and continued management of the IP6.INT domain. It is intended as technical input to the IANA from the IETF IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses. The IAB and IESG have authorized the Internet Assigned Numbers Authority (IANA) as the appropriate entity to have the responsibility for the management of the IPv6 address space as defined in [ALLOC]. The proposed initial assignment described in the document is consistent with: - RFC 2373,'IP Version 6 Addressing Architecture' [ARCH] - RFC 2374 'An Aggregatable Global Unicast Address Format' [AGGR] - RFC 2450 'Proposed TLA and NLA Assignment Rules' [TLA-RULES]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-iana-tla-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991229111810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iana-tla-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991229111810.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 20:30:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e084Sbo15727 for ipng-dist; Fri, 7 Jan 2000 20:28:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e084SOY15720 for ; Fri, 7 Jan 2000 20:28:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA05498 for ; Fri, 7 Jan 2000 20:28:23 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA24508 for ; Fri, 7 Jan 2000 21:28:21 -0700 (MST) Received: (qmail 19132 invoked by uid 8079); 8 Jan 2000 03:03:12 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Mon Jan 03 18:02:47 2000 Delivered-To: ry@internexus.net Received: (qmail 8992 invoked from network); 3 Jan 2000 18:02:46 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 3 Jan 2000 18:02:46 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25895; Mon, 3 Jan 2000 11:02:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA04628; Mon, 3 Jan 2000 10:01:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e03HuUO06955 for ipng-dist; Mon, 3 Jan 2000 09:56:30 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e03HuKY06948 for ; Mon, 3 Jan 2000 09:56:20 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA02166; Mon, 3 Jan 2000 09:56:20 -0800 (PST) Date: Mon, 3 Jan 2000 09:56:20 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Fragmentation in RFC1981 To: Giuseppe Federico Rossi Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3868D317.D39F593E@ieee.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: O X-Keywords: X-UID: 9181 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Suppose there is an IPv6 host receiving an ICMPv6 "Packet Too Big" > message with a next-hop MTU that is less than the IPv6 minimum link MTU > (1280). According to RFC1981 the host must include the "Fragment Header" > in the successive datagrams. In this case I do not understand if: > - the fragmentation is performed by the sending host (as explained in > RFC2460) > or > - the fragmentation is performed by the node generating the "Packet Too > Big" message (where the next MTU is < 1280). > In any case, does the fragmenting node generate IPv6 datagrams less than > 1280 byte long ? If yes, what is the minimum (allowed) length for an > IPv6 fragment ? The support for less than 1280 in the packet too big is there to make life a lot easier for boxes that translate between IPv6 and IPv4. Examples of such boxes/algorithms are specified in draft-ietf-ngtrans-siit-* and draft-ietf-ngtrans-natpt-*. In that case the fragmentation to less than 1280 bytes will occur on the IPv4 side of the translator. The sole purpose of the sending IPv6 node including the fragment header is to have that node assign an unique Identification value (in the fragment header) which will be carried end-to-end i.e. "translated" to the 16-bit IPv4 ID value. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 20:30:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e084SK015718 for ipng-dist; Fri, 7 Jan 2000 20:28:20 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e084SAY15711 for ; Fri, 7 Jan 2000 20:28:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA05484 for ; Fri, 7 Jan 2000 20:28:09 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA24433 for ; Fri, 7 Jan 2000 21:28:08 -0700 (MST) Received: (qmail 19047 invoked by uid 8079); 8 Jan 2000 03:03:03 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Mon Jan 03 17:47:04 2000 Delivered-To: ry@internexus.net Received: (qmail 8450 invoked from network); 3 Jan 2000 17:47:04 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 3 Jan 2000 17:47:04 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18500; Mon, 3 Jan 2000 10:45:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA01342; Mon, 3 Jan 2000 09:44:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e03HeTZ06840 for ipng-dist; Mon, 3 Jan 2000 09:40:29 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e03HeOY06833 for ; Mon, 3 Jan 2000 09:40:24 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA29432 for ipng@sunroof.eng.sun.com; Mon, 3 Jan 2000 09:39:30 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBSFD7Y04617 for ; Tue, 28 Dec 1999 07:13:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA09329 for ; Tue, 28 Dec 1999 07:13:07 -0800 (PST) Received: from fep10-svc.tin.it (mta10-acc.tin.it [212.216.176.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14066 for ; Tue, 28 Dec 1999 08:13:06 -0700 (MST) Received: from ieee.org ([212.216.1.103]) by fep10-svc.tin.it (InterMail v4.01.01.02 201-229-111-106) with ESMTP id <19991228151304.NDKX9522.fep10-svc@ieee.org> for ; Tue, 28 Dec 1999 16:13:04 +0100 Message-ID: <3868D317.D39F593E@ieee.org> Date: Tue, 28 Dec 1999 16:11:19 +0100 From: Giuseppe Federico Rossi Organization: Studio Ing. G. F. Rossi X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Fragmentation in RFC1981 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O X-Keywords: X-UID: 9152 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Suppose there is an IPv6 host receiving an ICMPv6 "Packet Too Big" message with a next-hop MTU that is less than the IPv6 minimum link MTU (1280). According to RFC1981 the host must include the "Fragment Header" in the successive datagrams. In this case I do not understand if: - the fragmentation is performed by the sending host (as explained in RFC2460) or - the fragmentation is performed by the node generating the "Packet Too Big" message (where the next MTU is < 1280). In any case, does the fragmenting node generate IPv6 datagrams less than 1280 byte long ? If yes, what is the minimum (allowed) length for an IPv6 fragment ? Many thanks to all members of ipng community Best Regards Giuseppe -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 23:36:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e087XZ016713 for ipng-dist; Fri, 7 Jan 2000 23:33:35 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e087X5Y16698 for ; Fri, 7 Jan 2000 23:33:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA23937 for ; Fri, 7 Jan 2000 23:33:05 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA29257 for ; Sat, 8 Jan 2000 00:33:03 -0700 (MST) Received: (qmail 14912 invoked by uid 8079); 8 Jan 2000 07:32:34 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Tue Jan 04 16:17:49 2000 X-UIDL: 7735ea6d980d8413e1efe661063e42eb Delivered-To: ry@internexus.net Received: (qmail 17102 invoked from network); 4 Jan 2000 16:17:48 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 4 Jan 2000 16:17:48 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05512; Tue, 4 Jan 2000 08:16:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA17611; Tue, 4 Jan 2000 08:15:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e04GBxJ07598 for ipng-dist; Tue, 4 Jan 2000 08:11:59 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e04GBoY07591; Tue, 4 Jan 2000 08:11:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA01920; Tue, 4 Jan 2000 08:11:50 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01956; Tue, 4 Jan 2000 08:11:50 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id E79AF9A825; Tue, 4 Jan 2000 10:11:49 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id D753A90D82; Tue, 4 Jan 2000 10:11:49 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 6DF874FB01; Tue, 4 Jan 2000 10:11:42 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 88D374C902; Tue, 4 Jan 2000 10:11:41 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000007759; Tue, 4 Jan 2000 11:11:48 -0500 (EST) From: Jim Bound Message-Id: <200001041611.LAA0000007759@quarry.zk3.dec.com> To: members@ipv6forum.com, deployment@ipv6.org, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, Michael.Carney@east.sun.com, ipv6imp@munnari.oz.au Cc: cmj@3com.com, us-summit@ipv6forum.com, tech@ipv6forum.com Subject: IPv6 Interoperability Testing Connectathon and IPv6 US Summit Date: Tue, 04 Jan 2000 11:11:47 -0500 X-Mts: smtp Status: RO X-Keywords: X-UID: 337 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk PLEASE DO NOT REPLY TO THIS MAIL SEND TO INDIVIDUAL LISTS ONLY OR TO CYNDI JUNG and/or I. THANK YOU......... Folks, The University of New Hampshire (UNH) will be supporting the testing of IPv6 and interoperability testing of IPv6 between multiple independent implementations at Sun Connectathon March 6-8 and the IPv6 Forum U.S. Summit at Teluride Colorado March 13-15. If implementors can make both events that would be great, but it would be ideal if the routing vendors could attend Teluride for this testing. Cyndi Jung at 3Com is driving this with UNH so please try to give IPv6 this support for the U.S. Summit. We are hoping live and breathing end user decision makers attend this event at Teluride. More details and logistics will follow later. Also UNH has added new IPv6 Mobility spec tests and Routing tests for the events too, for those that can test these parts. Implementor support is appreciated. Theme: for testing is "Lets find the bugs when all the players are on the same net with different implementations, do we all work, do some only work in their own lab, and the results are not for public consumption at either event so you can't get into marketing trouble, only implementor attendees will know the results of doing the interoperability testing, the press will not be allowed in the testing area at Telluride". thanks /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 23:56:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e087reV17939 for ipng-dist; Fri, 7 Jan 2000 23:53:40 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e087rBY17928 for ; Fri, 7 Jan 2000 23:53:11 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA00297 for ; Fri, 7 Jan 2000 23:53:11 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA16358 for ; Fri, 7 Jan 2000 23:53:09 -0800 (PST) Received: (qmail 19097 invoked by uid 8079); 8 Jan 2000 07:39:35 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Wed Dec 22 07:13:57 1999 X-UIDL: c81deedb8a187eebf5588af14610dd24 Delivered-To: ry@internexus.net Received: (qmail 28713 invoked from network); 22 Dec 1999 07:13:56 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 22 Dec 1999 07:13:56 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA23803; Tue, 21 Dec 1999 23:06:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA00889; Tue, 21 Dec 1999 23:06:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM72lr00122 for ipng-dist; Tue, 21 Dec 1999 23:02:47 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM72aY00115 for ; Tue, 21 Dec 1999 23:02:37 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA10129; Tue, 21 Dec 1999 23:02:34 -0800 (PST) Date: Tue, 21 Dec 1999 21:58:16 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: API suggestion Cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <23786.945834815@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO X-Keywords: X-UID: 1722 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Separate issue: AI_ADDRCONFIG does not seem very useful for me, as > AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) > configured on my host. In this case I will not be able to reach > anyone outside via IPv6. We'd better have more text in 2553bis, that > describes background/goal of AI_ADDRCONFIG. We actually had the opportunity to play with this exact issue at Sun a while back. For a while we thought we should really make AI_ADDRCONFIG mean "have addresses that can be used to communicate outside the box" but this is a bit tricky to clearly define. So instead we took the path of not configuring the IPv6 loopback address unless there is some other interface being configured for IPv6. That seems to solve the ::1 issue. But keep in mind that AI_ADDRCONFIG should really be viewed as an optimization and nothing more - avoid returning addresses to the application which we know are useless. A robust application should try all addresses that are returned from getipnodebyname/getaddrinfo. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 23:56:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e087rch17937 for ipng-dist; Fri, 7 Jan 2000 23:53:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e087r4Y17914 for ; Fri, 7 Jan 2000 23:53:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA13669 for ; Fri, 7 Jan 2000 23:53:03 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA16338 for ; Fri, 7 Jan 2000 23:53:01 -0800 (PST) Received: (qmail 19020 invoked by uid 8079); 8 Jan 2000 07:39:31 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Wed Dec 22 04:41:26 1999 X-UIDL: 9fb7d95a512271bff28f6cc5fe1bf404 Delivered-To: ry@internexus.net Received: (qmail 24172 invoked from network); 22 Dec 1999 04:41:25 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 22 Dec 1999 04:41:25 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07031; Tue, 21 Dec 1999 20:39:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA22971; Tue, 21 Dec 1999 20:39:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM4aAN00046 for ipng-dist; Tue, 21 Dec 1999 20:36:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM4a1Y00039 for ; Tue, 21 Dec 1999 20:36:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA10493 for ; Tue, 21 Dec 1999 20:36:00 -0800 (PST) Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [130.155.191.233]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA20497 for ; Tue, 21 Dec 1999 20:35:58 -0800 (PST) Received: from isc.org (marka@localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.8.5/8.8.5) with ESMTP id PAA22627; Wed, 22 Dec 1999 15:33:39 +1100 (EST) Message-Id: <199912220433.PAA22627@bsdi.dv.isc.org> cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com From: Mark.Andrews@iengines.com Subject: Re: API suggestion In-reply-to: Your message of "Wed, 22 Dec 1999 12:53:35 +0900." <23786.945834815@coconut.itojun.org> Date: Wed, 22 Dec 1999 15:33:27 +1100 Status: RO X-Keywords: X-UID: 1684 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Separate issue: AI_ADDRCONFIG does not seem very useful for me, as > AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) > configured on my host. In this case I will not be able to reach > anyone outside via IPv6. We'd better have more text in 2553bis, that > describes background/goal of AI_ADDRCONFIG. Why isn't it useful? You may be looking up "localhost". The worst that will happen is you will get network unreachable when you try to connect / send. AI_ADDRCONFIG is an optimisation. I do however agree that AI_ADDRCONFIG and the error states than can result need to be better documented. Mark -- Mark Andrews, Internet Engines Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@iengines.com -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 7 23:56:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e087rc817938 for ipng-dist; Fri, 7 Jan 2000 23:53:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e087r6Y17918 for ; Fri, 7 Jan 2000 23:53:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA24942 for ; Fri, 7 Jan 2000 23:53:06 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA16344 for ; Fri, 7 Jan 2000 23:53:04 -0800 (PST) Received: (qmail 19041 invoked by uid 8079); 8 Jan 2000 07:39:32 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Wed Dec 22 05:41:29 1999 X-UIDL: 443b42c42e9cf1dd04c31c88323014a4 Delivered-To: ry@internexus.net Received: (qmail 26666 invoked from network); 22 Dec 1999 05:41:24 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 22 Dec 1999 05:41:24 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA13927; Tue, 21 Dec 1999 21:39:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA26565; Tue, 21 Dec 1999 21:39:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM5Zja00071 for ipng-dist; Tue, 21 Dec 1999 21:35:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM5ZZY00064 for ; Tue, 21 Dec 1999 21:35:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA21915 for ; Tue, 21 Dec 1999 21:35:33 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA08673 for ; Tue, 21 Dec 1999 21:35:32 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id OAA25279; Wed, 22 Dec 1999 14:35:20 +0900 (JST) cc: ipng@sunroof.eng.sun.com In-reply-to: Mark.Andrews's message of Wed, 22 Dec 1999 15:33:27 +1100. <199912220433.PAA22627@bsdi.dv.isc.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: AI_ADDRCONFIG From: itojun@iijlab.net Date: Wed, 22 Dec 1999 14:35:20 +0900 Message-ID: <25277.945840920@coconut.itojun.org> Status: RO X-Keywords: X-UID: 1694 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Separate issue: AI_ADDRCONFIG does not seem very useful for me, as >> AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) >> configured on my host. In this case I will not be able to reach >> anyone outside via IPv6. We'd better have more text in 2553bis, that >> describes background/goal of AI_ADDRCONFIG. > Why isn't it useful? You may be looking up "localhost". > The worst that will happen is you will get network unreachable > when you try to connect / send. AI_ADDRCONFIG is an optimisation. AI_ADDRCONFIG checks list of local addresses to determine which family to return. I'm not sure if it optimizes it. It highly depends on what kind of behavior the OS kernel takes. There can be several choices in design principle level: - getaddrinfo(3) is name resolution function, this should not change behavior based on what kernel supports, what configured onto my interfaces. getaddrinfo(3) can simply return anything it have resolved via DNS. socket(2) or connect(2) may fail, user application should make a loop over whatever getaddrinfo(3) returned. - getaddrinfo(3) should mask address families that are not supported by kernel, to save from unnecessary socket(2) in user code. - getaddrinfo(3) should mask address families that are not configured onto my interfaces. this is what AI_ADDRCONFIG does. rfc2553 does not really state which is the intended behavior. I'm not sure which is the best one. I'm not sure which is the way to go. Actually kame getaddrinfo(3) implements 2nd case, but I don't really think it to be a good solution. > I do however agree that AI_ADDRCONFIG and the error states than > can result need to be better documented. agreed. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:02:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e087ubt17966 for ipng-dist; Fri, 7 Jan 2000 23:56:37 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e087u6Y17945 for ; Fri, 7 Jan 2000 23:56:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA00400 for ; Fri, 7 Jan 2000 23:56:04 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA02865 for ; Sat, 8 Jan 2000 00:56:03 -0700 (MST) Received: (qmail 22105 invoked by uid 8079); 8 Jan 2000 07:42:56 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Fri Dec 24 00:17:53 1999 Delivered-To: ry@internexus.net Received: (qmail 19741 invoked from network); 24 Dec 1999 00:17:52 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 24 Dec 1999 00:17:52 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20093; Thu, 23 Dec 1999 16:07:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA13215; Thu, 23 Dec 1999 16:06:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBO03E402721 for ipng-dist; Thu, 23 Dec 1999 16:03:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBO035Y02714 for ; Thu, 23 Dec 1999 16:03:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA01267 for ; Thu, 23 Dec 1999 16:03:05 -0800 (PST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06829 for ; Thu, 23 Dec 1999 16:03:04 -0800 (PST) Received: from ix.netcom.com (user-33qscij.dialup.mindspring.com [199.174.50.83]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA10829; Thu, 23 Dec 1999 19:02:52 -0500 (EST) Message-ID: <3862D206.EBB787CD@ix.netcom.com> Date: Thu, 23 Dec 1999 17:53:11 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 CC: DOMAIN-POLICY@LISTS.INTERNIC.NET, IFWP , "ipng@sunroof.eng.sun.com" , ISI IPv6 list <6bone@ISI.EDU>, ietf@ietf.org Subject: Re: RRP Specs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: O X-Keywords: X-UID: 3278 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karl and all, Karl Auerbach wrote: > > NSI has made an I-D of the RRP Protocol. > > > > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-hollenbeck-rrp-00.txt > > Am I missing something? I looked through that and I see neither > transaction identifiers nor timestamps. That alone could make > reconcilation of logs and post-mortem review of race conditions nearly > impossible. Precisely correct here Karl, and one of many deficiencies in this design document. But of course this is one of several I had pointed our some time ago before this document was published. To no avail of course. It reminds me of the lame leading the blind. And I believe I amongst a few others made this reference before as well. > > > And given the absence of a clear exchange between an existing registrar > and a new one I see a HUGE door in the transfer mechanism for registrars > to engage in what the long distance folks call "slamming" - the silent > transfer of customers from one long-distance company or registry to > another. And we have already seen this with respect to Register.com in this context already. More to come I am sure. > > > And text based? Wow, that's an open inviation to attacks based on buffer > overrun and packets split at cr-lf boundaries. Not to mention several other text based security attacks. The hack in these instances is child's play really. > > > And it is text based without any concern for internationalization. Good point here also. And one that slipped my mind... >;) > > > And its expiration date representation, although it is measured to the > millisecond, fails to include a reference to any time zone. Tisk, tisk, indeed this is a good point as well. > > > Nor does it handle IPv6. How true. > > > Seems like a rather deficient design. Looks like a design by committee, and a very poorly technically informed or knowledgeable one at that. > > > --karl-- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:02:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e087v4g17971 for ipng-dist; Fri, 7 Jan 2000 23:57:04 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e087uIY17955 for ; Fri, 7 Jan 2000 23:56:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA13752 for ; Fri, 7 Jan 2000 23:56:18 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA16696 for ; Fri, 7 Jan 2000 23:56:16 -0800 (PST) Received: (qmail 22368 invoked by uid 8079); 8 Jan 2000 07:43:17 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Fri Dec 24 09:24:09 1999 Delivered-To: ry@internexus.net Received: (qmail 2993 invoked from network); 24 Dec 1999 09:24:09 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 24 Dec 1999 09:24:09 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA29355; Fri, 24 Dec 1999 01:17:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA12074; Fri, 24 Dec 1999 01:17:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBO9DC502859 for ipng-dist; Fri, 24 Dec 1999 01:13:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBO9D2Y02852 for ; Fri, 24 Dec 1999 01:13:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA09586 for ; Fri, 24 Dec 1999 01:12:59 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA06757 for ; Fri, 24 Dec 1999 02:12:56 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA32718; Fri, 24 Dec 1999 20:12:37 +1100 (from kre@munnari.OZ.AU) From: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: dynamic dns In-Reply-To: Your message of "Thu, 23 Dec 1999 08:36:44 BST." Date: Fri, 24 Dec 1999 20:12:37 +1100 Message-Id: <27365.946026757@munnari.OZ.AU> Status: O X-Keywords: X-UID: 3424 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 23 Dec 1999 08:36:44 +0100 From: "Christopher Balzereit" Message-ID: | is there any mechanism foreseen to adjust the corresponding A6/AAAA-RR | in the hosts NS (similar to DNS-Update in IPv4)? DNS-Update isn't in IPv4, it is in the DNS. The DNS will run over both IPv6 and IPv4 in essentially the same way. DNS Update should work just as well with IPv6 as it does with IPv4. kre -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:09:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0885WT18583 for ipng-dist; Sat, 8 Jan 2000 00:05:35 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e08801Y18274 for ; Sat, 8 Jan 2000 00:01:11 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA00686 for ; Sat, 8 Jan 2000 00:00:01 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA17288 for ; Sat, 8 Jan 2000 00:00:00 -0800 (PST) Received: (qmail 27028 invoked by uid 8079); 8 Jan 2000 07:50:22 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Tue Dec 28 19:08:02 1999 Delivered-To: ry@internexus.net Received: (qmail 22995 invoked from network); 28 Dec 1999 19:08:01 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 28 Dec 1999 19:08:01 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12706; Tue, 28 Dec 1999 12:05:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA09361; Tue, 28 Dec 1999 11:04:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBSIxun04720 for ipng-dist; Tue, 28 Dec 1999 10:59:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBSIxmY04713 for ; Tue, 28 Dec 1999 10:59:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA09053 for ; Tue, 28 Dec 1999 10:59:46 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11156 for ; Tue, 28 Dec 1999 11:59:46 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id TAA14339; Tue, 28 Dec 1999 19:59:43 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id TAA06529; Tue, 28 Dec 1999 19:59:42 +0100 (MET) Message-Id: <199912281859.TAA06529@givry.inria.fr> From: Francis Dupont cc: "'IPng List'" Subject: Re: API suggestion In-reply-to: Your message of Tue, 21 Dec 1999 16:49:22 +0900. <5755.945762562@coconut.itojun.org> Date: Tue, 28 Dec 1999 19:59:41 +0100 Status: O X-Keywords: X-UID: 5144 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Separately, => I'd like to get standard function/macros to set/get the port field too (I already have some but they are not (yet?) standardized). we may need some function/macro that manipulates sockaddr, for: - comparing two sockaddrs at ease. family and length must match. i can think of: - address (and scope) match - port match - address (and scope) and port match - address (and scope) with certain prefix length match only. - masking address with prefix length. cmetz and francis wanted these. => I still want these (:-)! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:09:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e08865518601 for ipng-dist; Sat, 8 Jan 2000 00:06:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e08807Y18285 for ; Sat, 8 Jan 2000 00:02:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA00704 for ; Sat, 8 Jan 2000 00:00:06 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA03690 for ; Sat, 8 Jan 2000 01:00:00 -0700 (MST) Received: (qmail 27037 invoked by uid 8079); 8 Jan 2000 07:50:23 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Tue Dec 28 19:11:06 1999 Delivered-To: ry@internexus.net Received: (qmail 23156 invoked from network); 28 Dec 1999 19:11:04 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 28 Dec 1999 19:11:04 -0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23352; Tue, 28 Dec 1999 11:09:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA20274; Tue, 28 Dec 1999 11:09:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBSJ71p04754 for ipng-dist; Tue, 28 Dec 1999 11:07:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBSJ6qY04747 for ; Tue, 28 Dec 1999 11:06:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA09606 for ; Tue, 28 Dec 1999 11:06:51 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07254 for ; Tue, 28 Dec 1999 11:06:50 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id UAA14654; Tue, 28 Dec 1999 20:06:46 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA15878; Tue, 28 Dec 1999 20:06:42 +0100 (MET) Message-Id: <199912281906.UAA15878@givry.inria.fr> From: Francis Dupont cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com Subject: Re: API suggestion In-reply-to: Your message of Wed, 22 Dec 1999 12:53:35 +0900. <23786.945834815@coconut.itojun.org> Date: Tue, 28 Dec 1999 20:06:27 +0100 Status: O X-Keywords: X-UID: 5148 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Separate issue: AI_ADDRCONFIG does not seem very useful for me, as AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) configured on my host. In this case I will not be able to reach anyone outside via IPv6. => Jean-Luc Richier has asked how to implement this and our current solution is to say IPv6 is available when the IPv6 routing table is not empty. Another solution was to use to use something like in6_interfaces (which counts non-loopback interfaces with an IPv6 address) but it was more complex and the whole issue not very clear... We'd better have more text in 2553bis, that describes background/goal of AI_ADDRCONFIG. => I *agree*! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:14:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088Ad218828 for ipng-dist; Sat, 8 Jan 2000 00:10:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0880rY18351 for ; Sat, 8 Jan 2000 00:05:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA00860 for ; Sat, 8 Jan 2000 00:00:52 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA17456 for ; Sat, 8 Jan 2000 00:00:50 -0800 (PST) Received: (qmail 6632 invoked by uid 8079); 8 Jan 2000 07:58:21 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Dec 30 11:57:43 1999 Delivered-To: ry@internexus.net Received: (qmail 21093 invoked from network); 30 Dec 1999 11:57:42 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 30 Dec 1999 11:57:42 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10272; Thu, 30 Dec 1999 03:54:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA20313; Thu, 30 Dec 1999 03:53:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBUBnRo05391 for ipng-dist; Thu, 30 Dec 1999 03:49:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBUBnFY05384 for ; Thu, 30 Dec 1999 03:49:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA08467 for ; Thu, 30 Dec 1999 03:49:15 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA09589 for ; Thu, 30 Dec 1999 03:49:14 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23177; Thu, 30 Dec 1999 06:49:13 -0500 (EST) Message-Id: <199912301149.GAA23177@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-iana-tla-02.txt Date: Thu, 30 Dec 1999 06:49:12 -0500 Status: O X-Keywords: X-UID: 6834 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Initial IPv6 Sub-TLA ID Assignments Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain Filename : draft-ietf-ipngwg-iana-tla-02.txt Pages : 6 Date : 29-Dec-99 This document defines initial assignments of IPv6 Sub-TLA Aggregation Identifiers (Sub-TLA ID) to the Address Registries and continued management of the IP6.INT domain. It is intended as technical input to the IANA from the IETF IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses. The IAB and IESG have authorized the Internet Assigned Numbers Authority (IANA) as the appropriate entity to have the responsibility for the management of the IPv6 address space as defined in [ALLOC]. The proposed initial assignment described in the document is consistent with: - RFC 2373,'IP Version 6 Addressing Architecture' [ARCH] - RFC 2374 'An Aggregatable Global Unicast Address Format' [AGGR] - RFC 2450 'Proposed TLA and NLA Assignment Rules' [TLA-RULES]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-iana-tla-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991229111810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iana-tla-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991229111810.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:15:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088B9a18850 for ipng-dist; Sat, 8 Jan 2000 00:11:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e08886Y18694 for ; Sat, 8 Jan 2000 00:08:11 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA14240 for ; Sat, 8 Jan 2000 00:08:03 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA18512 for ; Sat, 8 Jan 2000 00:08:02 -0800 (PST) Received: (qmail 26100 invoked by uid 8079); 8 Jan 2000 08:07:38 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Wed Jan 05 20:52:14 2000 Delivered-To: ry@internexus.net Received: (qmail 2668 invoked from network); 5 Jan 2000 20:52:13 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 5 Jan 2000 20:52:13 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10742; Wed, 5 Jan 2000 13:52:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA28472; Wed, 5 Jan 2000 12:51:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e05Kjff09297 for ipng-dist; Wed, 5 Jan 2000 12:45:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e05KjUY09290 for ; Wed, 5 Jan 2000 12:45:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA27152 for ; Wed, 5 Jan 2000 12:45:29 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04837 for ; Wed, 5 Jan 2000 12:45:29 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA05160; Wed, 5 Jan 2000 12:45:14 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA08989; Wed, 5 Jan 2000 12:45:14 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id MAA03764; Wed, 5 Jan 2000 12:45:12 -0800 (PST) Date: Wed, 5 Jan 2000 12:45:12 -0800 (PST) From: Tim Hartrick Message-Id: <200001052045.MAA03764@feller.mentat.com> Subject: Re: comments on ipngwg-rfc2292bis-01 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Status: O X-Keywords: X-UID: 4460 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > 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 am not sure how useful this really is given the fact that there is no requirement that all extension headers be structured in this way. It is fine for hop-by-hop options, destination options and routing headers but it is not generally useful. > > 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.) > Indeed. If someone wants to implement DAD in user space then they need to be able to specify IN6ADDR_ANY as the source. One could always use ancillary data for that purpose and avoid sticky options I suppose, but it would be best I think, if we didn't have corner cases that behaved differently between ancillary data and sticky options. tim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:21:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088Dfv19004 for ipng-dist; Sat, 8 Jan 2000 00:13:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0889IY18781 for ; Sat, 8 Jan 2000 00:09:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA01171 for ; Sat, 8 Jan 2000 00:09:14 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA18655 for ; Sat, 8 Jan 2000 00:09:11 -0800 (PST) Received: (qmail 27010 invoked by uid 8079); 8 Jan 2000 08:08:02 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Jan 06 00:33:17 2000 Delivered-To: ry@internexus.net Received: (qmail 12332 invoked from network); 6 Jan 2000 00:33:16 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 6 Jan 2000 00:33:16 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24144; Wed, 5 Jan 2000 17:33:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA11663; Wed, 5 Jan 2000 16:33:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e060SXV09536 for ipng-dist; Wed, 5 Jan 2000 16:28:33 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e060SMY09529 for ; Wed, 5 Jan 2000 16:28:22 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA22775; Wed, 5 Jan 2000 16:28:05 -0800 (PST) Date: Wed, 5 Jan 2000 16:27:42 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on ipngwg-rfc2292bis-01 Cc: erik.nordmark@eng.sun.com, matt@3am-software.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: O X-Keywords: X-UID: 4638 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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 > > 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:23:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088G7S19137 for ipng-dist; Sat, 8 Jan 2000 00:16:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e088AMY18847 for ; Sat, 8 Jan 2000 00:11:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA25769 for ; Sat, 8 Jan 2000 00:10:19 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA18860 for ; Sat, 8 Jan 2000 00:10:15 -0800 (PST) Received: (qmail 30817 invoked by uid 8079); 8 Jan 2000 08:09:50 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Jan 06 17:52:15 2000 Delivered-To: ry@internexus.net Received: (qmail 16098 invoked from network); 6 Jan 2000 17:52:14 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 6 Jan 2000 17:52:14 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06614; Thu, 6 Jan 2000 09:42:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA05711; Thu, 6 Jan 2000 09:42:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06HbwG10195 for ipng-dist; Thu, 6 Jan 2000 09:37:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06HblY10188 for ; Thu, 6 Jan 2000 09:37:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA20528; Thu, 6 Jan 2000 09:37:46 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26792; Thu, 6 Jan 2000 09:37:45 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA08918; Thu, 6 Jan 2000 09:38:11 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA29757; Thu, 6 Jan 2000 09:38:10 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA04014; Thu, 6 Jan 2000 09:38:09 -0800 (PST) Date: Thu, 6 Jan 2000 09:38:09 -0800 (PST) From: Tim Hartrick Message-Id: <200001061738.JAA04014@feller.mentat.com> Subject: Re: comments on ipngwg-rfc2292bis-01 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Status: O X-Keywords: X-UID: 5388 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > So I'll add ND_OPT_PI_FLAG_ROUTER. > > Is there something else missing from the mobile IPv6 specification? > > Sorry, I'm not an expert in mobile ip6...maybe some other people can > answer this. > I don't have the spec in front of me but I believe that mobile IPv6 has added some options, some of which MUST be supported by implementations. I think it would be a good idea to add those option code points to the list of well known option code points. tim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:23:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088ITJ19214 for ipng-dist; Sat, 8 Jan 2000 00:18:32 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e088BmY18939 for ; Sat, 8 Jan 2000 00:12:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA01274 for ; Sat, 8 Jan 2000 00:11:47 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA19159 for ; Sat, 8 Jan 2000 00:11:47 -0800 (PST) Received: (qmail 1826 invoked by uid 8079); 8 Jan 2000 08:11:22 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Fri Jan 07 17:53:28 2000 Delivered-To: ry@internexus.net Received: (qmail 3927 invoked from network); 7 Jan 2000 17:53:22 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 7 Jan 2000 17:53:22 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18255; Fri, 7 Jan 2000 10:53:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA14344; Fri, 7 Jan 2000 09:53:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07HmqV11342 for ipng-dist; Fri, 7 Jan 2000 09:48:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07HmfY11335 for ; Fri, 7 Jan 2000 09:48:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA10187 for ; Fri, 7 Jan 2000 09:48:41 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00330 for ; Fri, 7 Jan 2000 09:48:39 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA10074; Sat, 8 Jan 2000 02:47:20 +0900 (JST) cc: ipng@sunroof.eng.sun.com In-reply-to: djoyal's message of Fri, 07 Jan 2000 12:37:46 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 mib question (ipv6RouteEntry) From: itojun@iijlab.net Date: Sat, 08 Jan 2000 02:47:20 +0900 Message-ID: <10072.947267240@coconut.itojun.org> Status: O X-Keywords: X-UID: 6371 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Doesn't the INDEX component ipv6RouteIndex disambiguate the entries? I believe ipv6RouteIndex and ipv6RouteIfIndex are different thing. From what I understand from the following part, - ipv6RouteIndex is for identifying equal-cost multi path routes and - ipv6RouteIfIndex identifies interface. I do not think ipv6RouteIndex includes meaning of ipv6RouteIfIndex Why do we have to have two similar values separately? "Same network layer destination" below is a bit tricky wording. In scoped address world, I tend to believe"fe80::1 on interface 1" and "fe80::1 on interface 2" are different destination for network layer. Some may object it though... itojun --- ipv6RouteIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value which uniquely identifies the route among the routes to the same network layer destination. The way this value is chosen is implementation specific but it must be unique for ipv6RouteDest/ipv6RoutePfxLength pair and remain constant for the life of the route." ::= { ipv6RouteEntry 3 } ipv6RouteIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of ipv6IfIndex. For routes of the discard type this value can be zero." ::= { ipv6RouteEntry 4 } -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:23:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088I6b19189 for ipng-dist; Sat, 8 Jan 2000 00:18:09 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e088C3Y18956 for ; Sat, 8 Jan 2000 00:13:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA14465 for ; Sat, 8 Jan 2000 00:12:03 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA05518 for ; Sat, 8 Jan 2000 01:12:02 -0700 (MST) Received: (qmail 2350 invoked by uid 8079); 8 Jan 2000 08:11:38 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Fri Jan 07 19:38:44 2000 Delivered-To: ry@internexus.net Received: (qmail 12404 invoked from network); 7 Jan 2000 19:38:43 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 7 Jan 2000 19:38:43 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01091; Fri, 7 Jan 2000 11:30:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA02374; Fri, 7 Jan 2000 11:29:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07JQOL11554 for ipng-dist; Fri, 7 Jan 2000 11:26:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07JQEY11547 for ; Fri, 7 Jan 2000 11:26:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA06972 for ; Fri, 7 Jan 2000 11:26:13 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07754 for ; Fri, 7 Jan 2000 12:26:12 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id EAA13237; Sat, 8 Jan 2000 04:21:18 +0900 (JST) cc: Dan Joyal , ipng@sunroof.eng.sun.com In-reply-to: dhaskin's message of Fri, 07 Jan 2000 13:53:02 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 mib question (ipv6RouteEntry) From: itojun@iijlab.net Date: Sat, 08 Jan 2000 04:21:18 +0900 Message-ID: <13235.947272878@coconut.itojun.org> Status: O X-Keywords: X-UID: 6470 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Dan is correct -- ipv6RouteIndex is provided to disambiguate the mib records >with the same values in the ipv6RouteDest and ipv6RoutePfxLength attributes. > >Let me note that just adding the ipv6RouteIfIndex to the INDEX definition >may not be sufficient in some cases; e.g. consider routes with the same >outgoing interface but different next hops. The way ipv6RouteIndex value is >chosen is implementation specific as long as it is unique for >ipv6RouteDest/ipv6RoutePfxLength pair, i.e. you can't have two records with >same ipv6RouteDest, ipv6RoutePfxLength, and ipv6RouteIndex in >ipv6RouteTable. > >If you wish you can have ipv6RouteIndex equal to ipv6RouteIfIndex as long as >there is a guarantee that you wouldn't get more than a single route to the >same network pointing to the same outgoing interface. Thanks for clarification. I think I needed more explicit description for ipv6RouteIndex. Please update if there'll be any revision for the document. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:23:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088J9F19238 for ipng-dist; Sat, 8 Jan 2000 00:19:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e088BNY18916 for ; Sat, 8 Jan 2000 00:11:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA25820 for ; Sat, 8 Jan 2000 00:11:24 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA05421 for ; Sat, 8 Jan 2000 01:11:21 -0700 (MST) Received: (qmail 872 invoked by uid 8079); 8 Jan 2000 08:10:57 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Fri Jan 07 14:56:25 2000 Delivered-To: ry@internexus.net Received: (qmail 29203 invoked from network); 7 Jan 2000 14:56:24 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 7 Jan 2000 14:56:24 -0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13675 for ; Fri, 7 Jan 2000 06:56:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA19714; Fri, 7 Jan 2000 06:54:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07Enx511182 for ipng-dist; Fri, 7 Jan 2000 06:49:59 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07EnnY11175 for ; Fri, 7 Jan 2000 06:49:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA18720 for ; Fri, 7 Jan 2000 06:49:49 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23326 for ; Fri, 7 Jan 2000 07:49:47 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA06467; Fri, 7 Jan 2000 23:48:55 +0900 (JST) cc: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: IPv6 mib question (ipv6RouteEntry) From: itojun@iijlab.net Date: Fri, 07 Jan 2000 23:48:55 +0900 Message-ID: <6465.947256535@coconut.itojun.org> Status: O X-Keywords: X-UID: 6187 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have an update request about RFC2465 (IPv6 MIB), specifically ipv6RouteEntry. Due to scoped nature of some of IPv6 address (like link-local unicast, site-local unicast, and multicasts), there can be multiple IPv6 scoped address/prefix with exactly the same value can appear on IPv6 routing table. For example, I have the following IPv6 routing table (sorry for long line) on the node I'm typing this email. There are multiple entries with "fe80::/64", and "ff02::/32". They are disambiguated by its interface only. If we try to view those entries via SNMP, >fe80::@sm1/64 link#1 >fe80::@lo0/64 fe80::1@lo0 they would appear like below, at *exactly* the same MIB tree: ipv6RouteTable.ipv6RouteEntry.ipv6RouteDest.254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.0.64.0 = fe80:0:0:0:0:0:0:0 ipv6RouteTable.ipv6RouteEntry.ipv6RoutePfxLength.254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.0.64.0 = 64 bits The collision is from non-unqueness of ipv6RouteEntry, since it does not include ipv6RouteIfIndex. > ipv6RouteEntry OBJECT-TYPE > SYNTAX Ipv6RouteEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A routing entry." > INDEX { ipv6RouteDest, > ipv6RoutePfxLength, > ipv6RouteIndex } > ::= { ipv6RouteTable 1 } Is it possible to include ipv6RouteIfIndex when next revision is made? All INDEX definitions should include interface index to disambiguate MIB tree, if it is indexed by IPv6 address. Good example: ipv6UdpEntry in RFC2454 includes ipv6UdpIfIndex in INDEX entry, and there will be no collision even if you have two UDP socket listening on ff02::9 on different interface. It seems ipv6RouteEntry is the only one which does not include interface index. itojun Internet6: Destination Gateway Flags Refs Use Mtu Interface ::/96 ::1 UGRS 0 0 32976 lo0 => default fe80::240:5ff:fea0:8e08@sm1 UG 1 1886 1500 sm1 ::1 ::1 UH 4 8771 32976 lo0 ::ffff:0.0.0.0/96 ::1 UGRS 0 0 32976 lo0 3ffe:501:410::/64 link#1 UC 0 0 1500 sm1 3ffe:501:410:0:200:86ff:fe05:80fa 00:00:86:05:80:fa UHL 0 0 1500 lo0 3ffe:501:410:0:240:5ff:fea0:8e08 00:40:05:a0:8e:08 UHL 0 6 1500 sm1 3ffe:507:1:1::/64 link#1 UC 0 0 1500 sm1 3ffe:507:1:1:200:86ff:fe05:80fa 00:00:86:05:80:fa UHL 0 0 1500 lo0 3ffe:507:1:1:240:5ff:fea0:8e08 00:40:05:a0:8e:08 UHL 0 17 1500 sm1 3ffe:8020:10ff:1::/64 link#1 UC 0 0 1500 sm1 fe80::/10 ::1 UGRS 0 0 32976 lo0 fe80::@sm1/64 link#1 UC 0 0 1500 sm1 fe80::200:86ff:fe05:80fa@sm1 00:00:86:05:80:fa UHL 1 0 1500 lo0 fe80::240:5ff:fea0:8e08@sm1 00:40:05:a0:8e:08 UHL 1 44 1500 sm1 fe80::@lo0/64 fe80::1@lo0 U 0 8 32976 lo0 fec0::/10 ::1 UGRS 0 0 32976 lo0 ff01::/32 ::1 U 0 0 32976 lo0 ff02::@sm1/32 link#1 UC 0 0 1500 sm1 ff02::@lo0/32 fe80::1@lo0 UC 0 0 32976 lo0 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:23:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088ISf19188 for ipng-dist; Sat, 8 Jan 2000 00:18:29 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e088BuY18951 for ; Sat, 8 Jan 2000 00:12:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA14454 for ; Sat, 8 Jan 2000 00:11:56 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA19191 for ; Sat, 8 Jan 2000 00:11:54 -0800 (PST) Received: (qmail 2124 invoked by uid 8079); 8 Jan 2000 08:11:31 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Fri Jan 07 18:59:28 2000 Delivered-To: ry@internexus.net Received: (qmail 10856 invoked from network); 7 Jan 2000 18:59:27 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 7 Jan 2000 18:59:27 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17975; Fri, 7 Jan 2000 10:57:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA25739; Fri, 7 Jan 2000 10:57:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e07IrJB11500 for ipng-dist; Fri, 7 Jan 2000 10:53:19 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e07IrAY11493 for ; Fri, 7 Jan 2000 10:53:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA28094 for ; Fri, 7 Jan 2000 10:53:08 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20219 for ; Fri, 7 Jan 2000 11:53:08 -0700 (MST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 13:53:08 -0500 Message-ID: From: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 mib question (ipv6RouteEntry) Date: Fri, 7 Jan 2000 13:53:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Status: O X-Keywords: X-UID: 6426 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan is correct -- ipv6RouteIndex is provided to disambiguate the mib records with the same values in the ipv6RouteDest and ipv6RoutePfxLength attributes. Let me note that just adding the ipv6RouteIfIndex to the INDEX definition may not be sufficient in some cases; e.g. consider routes with the same outgoing interface but different next hops. The way ipv6RouteIndex value is chosen is implementation specific as long as it is unique for ipv6RouteDest/ipv6RoutePfxLength pair, i.e. you can't have two records with same ipv6RouteDest, ipv6RoutePfxLength, and ipv6RouteIndex in ipv6RouteTable. If you wish you can have ipv6RouteIndex equal to ipv6RouteIfIndex as long as there is a guarantee that you wouldn't get more than a single route to the same network pointing to the same outgoing interface. ---------------------------------------------------------------------- Dimitry Haskin Lucent Technologies Internetworking Systems > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Friday, January 07, 2000 12:47 PM > To: Dan Joyal > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 mib question (ipv6RouteEntry) > > > > Doesn't the INDEX component ipv6RouteIndex disambiguate the entries? > > I believe ipv6RouteIndex and ipv6RouteIfIndex are > different thing. > From what I understand from the following part, > - ipv6RouteIndex is for identifying equal-cost multi > path routes and > - ipv6RouteIfIndex identifies interface. > > I do not think ipv6RouteIndex includes meaning of > ipv6RouteIfIndex > Why do we have to have two similar values separately? > > "Same network layer destination" below is a bit tricky wording. > In scoped address world, I tend to believe"fe80::1 on > interface 1" > and "fe80::1 on interface 2" are different destination > for network > layer. Some may object it though... > > itojun > > > --- > ipv6RouteIndex OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The value which uniquely identifies the route > among the routes to the same network layer > destination. The way this value is chosen is > implementation specific but it must be unique for > ipv6RouteDest/ipv6RoutePfxLength pair and remain > constant for the life of the route." > ::= { ipv6RouteEntry 3 } > > ipv6RouteIfIndex OBJECT-TYPE > SYNTAX Ipv6IfIndexOrZero > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The index value which uniquely identifies the local > interface through which the next hop of this > route should be reached. The interface identified > by a particular value of this index is the same > interface as identified by the same value of > ipv6IfIndex. For routes of the discard type this > value can be zero." > ::= { ipv6RouteEntry 4 } > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:31:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088Frh19124 for ipng-dist; Sat, 8 Jan 2000 00:15:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e088ATY18855 for ; Sat, 8 Jan 2000 00:11:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA25780 for ; Sat, 8 Jan 2000 00:10:30 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA05281 for ; Sat, 8 Jan 2000 01:10:27 -0700 (MST) Received: (qmail 31245 invoked by uid 8079); 8 Jan 2000 08:10:03 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Jan 06 18:49:53 2000 Delivered-To: ry@internexus.net Received: (qmail 18143 invoked from network); 6 Jan 2000 18:49:52 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 6 Jan 2000 18:49:52 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03916; Thu, 6 Jan 2000 10:47:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA07096; Thu, 6 Jan 2000 10:46:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06IfmC10432 for ipng-dist; Thu, 6 Jan 2000 10:41:48 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06IfXY10425 for ; Thu, 6 Jan 2000 10:41:34 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA07010; Thu, 6 Jan 2000 10:41:16 -0800 (PST) Date: Thu, 6 Jan 2000 10:40:53 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on ipngwg-rfc2292bis-01 Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200001061738.JAA04014@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: O X-Keywords: X-UID: 5447 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > I don't have the spec in front of me but I believe that mobile IPv6 has > added some options, some of which MUST be supported by implementations. I > think it would be a good idea to add those option code points to the > list of well known option code points. Those are already in 2292bis-01. But I hadn't checked the spec for the ND extensions. I found one more flag and I will add ND_RA_FLAG_HOME_AGENT and I found two more ND options and will add them and their structures #define ND_OPT_ADVINTERVAL 7 #define ND_OPT_HOMEAGENT_INFO 8 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 00:45:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088DJL18999 for ipng-dist; Sat, 8 Jan 2000 00:13:21 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0889uY18814 for ; Sat, 8 Jan 2000 00:10:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA14333 for ; Sat, 8 Jan 2000 00:09:55 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA05197 for ; Sat, 8 Jan 2000 01:09:54 -0700 (MST) Received: (qmail 29999 invoked by uid 8079); 8 Jan 2000 08:09:30 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Jan 06 15:52:56 2000 Delivered-To: ry@internexus.net Received: (qmail 11375 invoked from network); 6 Jan 2000 15:52:56 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 6 Jan 2000 15:52:56 -0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16158; Thu, 6 Jan 2000 07:51:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA15988; Thu, 6 Jan 2000 07:50:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06Fkkp10042 for ipng-dist; Thu, 6 Jan 2000 07:46:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06FkbY10035 for ; Thu, 6 Jan 2000 07:46:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA17856 for ; Thu, 6 Jan 2000 07:46:37 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24770 for ; Thu, 6 Jan 2000 08:46:28 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA18170; Fri, 7 Jan 2000 00:34:31 +0900 (JST) Date: Fri, 07 Jan 2000 00:50:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 In-Reply-To: In your message of "Wed, 5 Jan 2000 12:45:12 -0800 (PST)" <200001052045.MAA03764@feller.mentat.com> References: <200001052045.MAA03764@feller.mentat.com> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 78 Status: O X-Keywords: X-UID: 5223 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 5 Jan 2000 12:45:12 -0800 (PST), >>>>> Tim Hartrick said: >> 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 am not sure how useful this really is given the fact that there is no > requirement that all extension headers be structured in this way. It is > fine for hop-by-hop options, destination options and routing headers but > it is not generally useful. That's right, but (currently) the only exception is the fragment header and I think if we defined a new (variable length) extension header it would probably be formatted as above. Anyway, we are using the structure in chasing a header chain like this: while (len < off) { ip6e = (struct ip6_ext *)(packetbuf + len); switch(nxt) { case IPPROTO_FRAGMENT: len += sizeof(struct ip6_frag); break; case IPPROTO_AH: len += (ip6e->ip6e_len + 2) << 2; break; default: len += (ip6e->ip6e_len + 1) << 3; break; } nxt = ip6e->ip6e_nxt; } Despite the exception, I still believe the generic structure is useful in such a situation. But I don't strongly argue that it should be incorporated to the draft. I'd like to follow the authors' decision. >> 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.) >> > Indeed. If someone wants to implement DAD in user space then they need > to be able to specify IN6ADDR_ANY as the source. One could always use > ancillary data for that purpose and avoid sticky options I suppose, but it > would be best I think, if we didn't have corner cases that behaved differently > between ancillary data and sticky options. As I said in the previous mail, I'm now about to change my mind on this point. In6addr_any in the ipi6_addr field has already another semantics, i.e. the user doesn't want to specify the address. So we may not be able to specify the unspecified address as source using IN6_PKTINFO option/ancillary data... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 01:00:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088E7s19022 for ipng-dist; Sat, 8 Jan 2000 00:14:11 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0889qY18809 for ; Sat, 8 Jan 2000 00:10:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA14329 for ; Sat, 8 Jan 2000 00:09:51 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA18727 for ; Sat, 8 Jan 2000 00:09:49 -0800 (PST) Received: (qmail 29865 invoked by uid 8079); 8 Jan 2000 08:09:26 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Jan 06 15:32:32 2000 Delivered-To: ry@internexus.net Received: (qmail 10666 invoked from network); 6 Jan 2000 15:32:31 -0000 Received: from mercury.sun.com (192.9.25.1) by internexus.net with SMTP; 6 Jan 2000 15:32:31 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05961; Thu, 6 Jan 2000 07:29:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29202; Thu, 6 Jan 2000 07:29:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e06FPiS09978 for ipng-dist; Thu, 6 Jan 2000 07:25:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e06FPYY09971 for ; Thu, 6 Jan 2000 07:25:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28419; Thu, 6 Jan 2000 07:25:34 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14476; Thu, 6 Jan 2000 08:25:02 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA18087; Fri, 7 Jan 2000 00:13:14 +0900 (JST) Date: Fri, 07 Jan 2000 00:29:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 In-Reply-To: In your message of "Wed, 5 Jan 2000 16:27:42 -0800 (PST)" References: User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 317 Status: O X-Keywords: X-UID: 5198 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 5 Jan 2000 16:27:42 -0800 (PST), >>>>> Erik Nordmark said: >> 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. I've found it in my mailbox. I missed it, sorry. >> 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. Okay, I personally don't mind to nuke old ones. > 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. Okay, I can live without official definitions for name lookups and site prefixes. > So I'll add ND_OPT_PI_FLAG_ROUTER. > Is there something else missing from the mobile IPv6 specification? Sorry, I'm not an expert in mobile ip6...maybe some other people can answer this. >> 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. Hmm...okay. But I'm still confused. If an application call setsockopt(IPV6_PKTINFO) with ipi6_addr being in6addr_any and ipi6_ifindex being zero, and then call getsockopt(IPV6_PKTINFO), what should happen? Should an application get an in6_pktinfo structure with all zero values, or should it get a zero-length value? >> 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. On the second thought, I now suspect that specifying -1 can't be used for removing the option. It should mean "the kernel must always use the system default value regardless of values specified by weaker options". For example, if the IPV6_HOPLIMIT option should be stronger than IPV6_UNICAST_HOPS (we'll have to clarify such things...), specifying -1 by IPV6_HOPLIMIT means the kernel should still use the system default regardless of the value specified by IPV6_UNICAST_HOPS. So I think using a zero length option should be the only way to remove the option. >> 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. Right, but an application can first allocate an appropriate amount of space (e.g. 127 * sizeof(struct in6_addr)) and realloc when inet6_rth_add fails. But, okay, > 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. we can take this kind of approach. I don't strongly stick to the idea of a finalization function. >> 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. Exactly. > While the receive side could provide more I don't see any reason to specify > that in the API. Okay, I'm convinced. I'll note that such cases are out of scope of the API specificaiton in our documents. > (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.) Sounds reasonable, and in fact, that's the way of our current implementation. >> 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. Okay, good. >> 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". I see. I'll state our kernel's behavior (and that it's implementation dependent) in our own document. >> 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. Okay. >> 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. Okay. >> 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.) Hmm, I understand. Then it would be helpful to refer the appendix and to (more) clarify the semantics of the align parameter in the function specification. By the way, it seems to me that the Home Address Option of mobile ipv6 does not follow the guideline of Appendix B of RFC2460. According to mobileip-ipv6-09 the format is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- and its alignment requirement is 8n+6. If the length of a sub-option is smaller than 16 (and I think it is very possible), the format would break the guideline. How do you think of it? >> 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. Hmm...maybe. > 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. That's my point. The constraint seems to me too restrictive. Also, it's not an official requirement but just an appendix. If we keep the constraint in the function specification, we may need to refer the appendix and to state the restriction more clearly. > I just have to think about how to describe this in a concise way. Okay. >> 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. Ah, that's right. Maybe this depends on how we treat the constraint of the vallen parameter for inet6_opt_{get,set}_val. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 8 01:42:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e089WsN22537 for ipng-dist; Sat, 8 Jan 2000 01:33:34 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e089NqY22321 for ; Sat, 8 Jan 2000 01:24:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA01886 for ; Sat, 8 Jan 2000 01:23:46 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA15669 for ; Sat, 8 Jan 2000 02:23:43 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA11842; Sat, 8 Jan 2000 20:23:04 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: tim@mentat.com, ipng@sunroof.eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 In-Reply-To: Your message of "Fri, 07 Jan 2000 00:50:50 +0900." Date: Sat, 08 Jan 2000 20:23:03 +1100 Message-Id: <5352.947323383@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 07 Jan 2000 00:50:50 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | > I am not sure how useful this really is given the fact that there is no | > requirement that all extension headers be structured in this way. It is | > fine for hop-by-hop options, destination options and routing headers but | > it is not generally useful. | | That's right, but (currently) the only exception is the fragment | header and I think if we defined a new (variable length) extension | header it would probably be formatted as above. Only if the length fits in a byte, which is by no means certain. | Anyway, we are using the structure in chasing a header chain like | this: As I recall, the intent was always very explicitly, that as soon as an unknown header is detected, packet parsing must cease. You are explicitly not supposed to be able to step over an unknown header. kre -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 10 05:15:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0ADCna26744 for ipng-dist; Mon, 10 Jan 2000 05:12:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0ADCdY26737 for ; Mon, 10 Jan 2000 05:12:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA07798 for ; Mon, 10 Jan 2000 05:12:39 -0800 (PST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04802 for ; Mon, 10 Jan 2000 05:12:38 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Mon, 10 Jan 2000 07:11:45 -0600 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CKF40V1T; Mon, 10 Jan 2000 07:11:05 -0600 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z4V1KLZB; Mon, 10 Jan 2000 08:11:06 -0500 Message-ID: <3879D9CC.926BDBDD@nortelnetworks.com> Date: Mon, 10 Jan 2000 08:08:28 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Updated MLD MIB draft Content-Type: multipart/mixed; boundary="------------9FBC63214743CB2FC5C25A3C" X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------9FBC63214743CB2FC5C25A3C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have updated the MLD MIB draft and submitted it to the editor. Questions and/or comments can be directed to me or the mailing list. Brian -- Brian Haberman Advanced Network Research Nortel Networks haberman@nortelnetworks.com --------------9FBC63214743CB2FC5C25A3C Content-Type: text/plain; charset=us-ascii; name="mld-mib.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mld-mib.txt" IPNGWG Working Group B. Haberman Internet Draft Nortel Networks draft-ietf-ipngwg-mld-mib-02.txt R. Worzella December 1999 IBM Expires June 2000 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [MLD]. 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 Haberman, Worzella 1 Internet Draft MIB for MLD November 1999 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580[RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573[RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine- readable information is not considered to change the semantics of the MIB. 3. Object Definition Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine- readable information is not considered to change the semantics of the MIB. 4. Overview Haberman, Worzella 2 Internet Draft MIB for MLD November 1999 This MIB module contains two tables: 1. The MLD Interface Table, which contains one row for each interface on which MLD is enabled. 2. The MLD Cache Table which contains one row for each IPv6 Multicast group for which there are members on a particular interface. Both tables are intended to be implemented by hosts and routers. Some objects in each table apply to routers only. 5. Definitions MLD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Integer32, TimeTicks, mib-2 FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC Ipv6Address, Ipv6IfIndexOrZero FROM IPV6-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; mldMIB MODULE-IDENTITY LAST-UPDATED "9912171600Z" ORGANIZATION "IETF IPNGWG Working Group." CONTACT-INFO " Brian Haberman Nortel Networks 4309 Emperor Blvd. Durham, NC 27703 USA Phone: +1 919 992 4439 e-mail: haberman@nortelnetworks.com" DESCRIPTION "The MIB module for MLD Management." REVISION "9912171600Z" ::= { mib-2 xx } mldMIBObjects OBJECT IDENTIFIER ::= { mldMIB 1 } mld OBJECT IDENTIFIER ::= { mldMIBObjects 1 } -- -- The MLD Interface Table -- mldInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF MldInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the interfaces on which MLD is enabled." ::= { mld 1 } Haberman, Worzella 3 Internet Draft MIB for MLD November 1999 mldInterfaceEntry OBJECT-TYPE SYNTAX MldInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an interface on which MLD is enabled." INDEX { mldInterfaceIfIndex } ::= { mldInterfaceTable 1 } MldInterfaceEntry ::= SEQUENCE { mldInterfaceIfIndex Ipv6IfIndexOrZero, mldInterfaceQueryInterval Integer32, mldInterfaceStatus RowStatus, mldInterfaceQuerier Ipv6Address, mldInterfaceQueryMaxResponseDelay Integer32, mldInterfaceJoins Counter32, mldInterfaceGroups Gauge32, mldInterfaceRobustness Integer32, mldInterfaceLastListenQueryIntvl Integer32, mldInterfaceQuerierUpTime TimeTicks, mldInterfaceQuerierExpiryTime TimeTicks } mldInterfaceIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex value of the interface for which MLD is enabled." ::= { mldInterfaceEntry 1 } mldInterfaceQueryInterval OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency at which MLD Host-Query packets are transmitted on this interface." DEFVAL { 125 } ::= { mldInterfaceEntry 2 } mldInterfaceStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The activation of a row enables MLD on the interface. The destruction of a row disables MLD on the interface." ::= { mldInterfaceEntry 3 } mldInterfaceQuerier OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS read-only STATUS current DESCRIPTION Haberman, Worzella 4 Internet Draft MIB for MLD November 1999 "The address of the MLD Querier on the IPv6 subnet to which this interface is attached." ::= { mldInterfaceEntry 4 } mldInterfaceQueryMaxResponseDelay OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum query response time advertised in MLD queries on this interface." DEFVAL { 10 } ::= { mldInterfaceEntry 5 } mldInterfaceJoins OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times a group membership has been added on this interface; that is, the number of times an entry for this interface has been added to the Cache Table. This object gives an indication of the amount of MLD activity over time." ::= { mldInterfaceEntry 6 } mldInterfaceGroups OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries for this interface in the Cache Table." ::= { mldInterfaceEntry 7 } mldInterfaceRobustness OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Robustness Variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the Robustness Variable may be increased. MLD is robust to (Robustness Variable-1) packet losses." DEFVAL { 2 } ::= { mldInterfaceEntry 8 } mldInterfaceLastListenQueryIntvl OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The Last Member Query Interval is the Max Response Delay inserted into Group-Specific Queries sent in response to Leave Group messages, and is also the amount of time between Group-Specific Query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last Haberman, Worzella 5 Internet Draft MIB for MLD November 1999 member of a group." DEFVAL { 1 } ::= { mldInterfaceEntry 9 } mldInterfaceQuerierUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since mldInterfaceQuerier was last changed." ::= { mldInterfaceEntry 10 } mldInterfaceQuerierExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the Other Querier Present Timer expires. If the local system is the querier, the value of this object is zero." ::= { mldInterfaceEntry 11 } -- -- The MLD Cache Table -- mldCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF MldCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the IPv6 multicast groups for which there are members on a particular interface." ::= { mld 2 } mldCacheEntry OBJECT-TYPE SYNTAX MldCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) in the mldCacheTable." INDEX { mldCacheAddress, mldCacheIfIndex } ::= { mldCacheTable 1 } MldCacheEntry ::= SEQUENCE { mldCacheAddress Ipv6Address, mldCacheIfIndex Ipv6IfIndexOrZero, mldCacheSelf TruthValue, mldCacheLastReporter Ipv6Address, mldCacheUpTime TimeTicks, mldCacheExpiryTime TimeTicks, mldCacheStatus RowStatus } mldCacheAddress OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS not-accessible STATUS current DESCRIPTION Haberman, Worzella 6 Internet Draft MIB for MLD November 1999 "The IPv6 multicast group address for which this entry contains information." ::= { mldCacheEntry 1 } mldCacheIfIndex OBJECT-TYPE SYNTAX Ipv6IfIndexOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface for which this entry contains information for an IPv6 multicast group address." ::= { mldCacheEntry 2 } mldCacheSelf OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of whether the local system is a member of this group address on this interface." DEFVAL { true } ::= { mldCacheEntry 3 } mldCacheLastReporter OBJECT-TYPE SYNTAX Ipv6Address MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 address of the source of the last membership report received for this IPv6 Multicast group address on this interface. If no membership report has been received, this object has the value 0::0. ::= { mldCacheEntry 4 } mldCacheUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time elapsed since this entry was created." ::= { mldCacheEntry 5 } mldCacheExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum amount of time remaining before this entry will be aged out. A value of 0 indicates that the entry is only present because mldCacheSelf is true and that if the router left the group, this entry would be aged out immediately. Note that some implementations may process membership Reports from the local system in the same way as reports From other hosts, so a value of 0 is not required." ::= { mldCacheEntry 6 } mldCacheStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current Haberman, Worzella 7 Internet Draft MIB for MLD November 1999 DESCRIPTION "The status of this entry." ::= { mldCacheEntry 7 } -- conformance information mldMIBConformance OBJECT IDENTIFIER ::= { mldMIB 2 } mldMIBCompliances OBJECT IDENTIFIER ::= { mldMIBConformance 1 } MldMIBGroups OBJECT IDENTIFIER ::= { mldMIBConformance 2 } -- compliance statements mldHostMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for hosts running MLD and implementing the MLD MIB." MODULE -- this module MANDATORY-GROUPS { mldBaseMIBGroup, mldHostMIBGroup } OBJECT mldInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mldMIBCompliances 1 } mldRouterMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for routers running MLD and implementing the MLD MIB." MODULE -- this module MANDATORY-GROUPS { mldBaseMIBGroup, mldRouterMIBGroup } OBJECT mldInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { mldMIBCompliances 2 } -- units of conformance mldBaseMIBGroup OBJECT-GROUP OBJECTS { mldCacheSelf, mldCacheStatus, mldInterfaceStatus } STATUS current DESCRIPTION Haberman, Worzella 8 Internet Draft MIB for MLD November 1999 "The basic collection of objects providing management of MLD." ::= { mldMIBGroups 1 } mldRouterMIBGroup OBJECT-GROUP OBJECTS { mldCacheUpTime, mldCacheExpiryTime, mldInterfaceQueryInterval, mldInterfaceJoins, mldInterfaceGroups, mldCacheLastReporter, mldInterfaceQuerierUpTime, mldInterfaceQuerierExpiryTime, mldInterfaceQuerier, mldInterfaceQueryMaxResponseTime, mldInterfaceRobustness, mldInterfaceLastMemQueryIntvl } STATUS current DESCRIPTION "A collection of additional objects for management of MLD in routers." ::= { mldMIBGroups 2 } mldHostMIBGroup OBJECT-GROUP OBJECTS { mldInterfaceQuerier } STATUS current DESCRIPTION "A collection of additional objects for management of MLD in hosts." ::= { mldMIBGroups 3 } END 6. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain sensitive information. These are: o mldCacheSelf o mldCacheLastReporter It is thus important to control even GET access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. Haberman, Worzella 9 Internet Draft MIB for MLD November 1999 It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User- based Security Model RFC 2574 [RFC2574] and the View-based Access Control Model RFC 2575 [RFC2575] are recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Certain management information defined in this MIB MAY be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. The method for this authentication is a function of the SNMP Administrative Framework, and has not been expanded by this MIB. Several objects in this MIB allow write access or provide for row creation. Allowing this support in a non-secure environment can have a negative effect on network operations. It is RECOMMENDED that implementers seriously consider whether set operations or row creation be allowed without providing, at a minimum, authentication of request origin. It is RECOMMENDED that without such support that objects be implemented as read-only. 7. Acknowledgements This MIB module is based on the IGMP MIB authored by Keith McCloghrie, Dino Farinacci, and Dave Thaler. It was updated based on feedback from the IPNGWG working group, Bert Wijnen, and Peder Norgaard. 8. References [MLD] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1997. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Haberman, Worzella 10 Internet Draft MIB for MLD November 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. Authors' Addresses Brian Haberman Nortel Networks 4309 Emperor Blvd. Durham, NC 27703 USA +1 haberman@nortelnetworks.com -919-992-4439 Haberman, Worzella 11 Internet Draft MIB for MLD November 1999 Randy Worzella IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA +1 worzella@us.ibm.com -919-254-2202 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Haberman, Worzella 12 --------------9FBC63214743CB2FC5C25A3C-- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 10 05:17:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0ADGIo26763 for ipng-dist; Mon, 10 Jan 2000 05:16:18 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0ADG8Y26756 for ; Mon, 10 Jan 2000 05:16:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA09110 for ; Mon, 10 Jan 2000 05:16:07 -0800 (PST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05630 for ; Mon, 10 Jan 2000 05:16:06 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Mon, 10 Jan 2000 08:15:33 -0500 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y69588VK; Mon, 10 Jan 2000 08:15:34 -0500 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z4V1KLZP; Mon, 10 Jan 2000 08:15:33 -0500 Message-ID: <3879DAD7.DBC8C7E4@nortelnetworks.com> Date: Mon, 10 Jan 2000 08:12:55 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Multicast Address Architecture draft Content-Type: multipart/mixed; boundary="------------B3C64868B09FEC961C85E0B8" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------B3C64868B09FEC961C85E0B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I have just submitted the following individual draft to the editor. It is a proposed update to the multicast address architecture meant to improve the capability of multicast address allocation. I would like to see this become a WG document. Please direct questions to me or the mailing list. Brian -- Brian Haberman Advanced Network Research Nortel Networks haberman@nortelnetworks.com --------------B3C64868B09FEC961C85E0B8 Content-Type: text/plain; charset=us-ascii; name="mcast-arch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mcast-arch.txt" IPNGWG Working Group B. Haberman Internet Draft Nortel Networks draft-haberman-ipngwg-mcast-arch-00.txt December 1999 Expires June 2000 IP Version 6 Multicast Addressing Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC 2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This specification defines the multicast addressing architecture of the IP Version 6 protocol [RFC 2460]. The updated multicast address architecture presented in this document allows for prefix-based allocation of multicast addresses. It is an update of section 2.7 of the RFC 2373 [RFC 2373]. 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Introduction This document specifies an update to the IPv6 multicast addressing architecture. The current architecture does not contain any built-in support for dynamic address allocation. This proposal introduces encoded information in the multicast address to allow for dynamic, network prefix-based allocation of IPv6 multicast addresses. 3. Multicast Address Format Haberman 1 Internet Draft IPv6 Multicast Address Architecture December 1999 An IPv6 multicast address is an identifier for a group of nodes. A node may belong to any number of multicast groups. Multicast addresses have the following format: | 8 | 4 | 4 | 8 | plen | 104 - plen | +--------+----+----+--------+--------------------+--------------------+ |11111111|flgs|scop| plen | network prefix | group ID | +--------+ + ---- ----+--------+--------------------+--------------------+ 11111111 at the start of the address identifies the address as being a multicast address. +-+-+-+-+ flgs is a set of 4 flags: |0|0|P|T| +-+-+-+-+ o The high-order 2 flags are reserved, and must be initialized to 0. o P = 0 indicates a multicast address that is not assigned based on the network prefix. When P = 0, the plen field and the network prefix portion of the address are a part of the group ID. o P = 1 indicates a multicast address that is assigned based on the network prefix. o T = 0 indicates a permanently assigned (_well-known_) multicast address, assigned by the global Internet numbering authority. o T = 1 indicates a non-permanently-assigned (_transient_) multicast address. scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are: 0 reserved 1 node-local scope 2 link-local scope 3 (unassigned) 4 (unassigned) 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope F reserved plen indicates the length of the network prefix embedded in the address when P = 1. When P = 0, this field is considered a part of the group ID. network prefix identifies the network prefix of the unicast subnet owning the multicast address. If P = 0, this field is considered a part of the group ID. If P = 1, this field contains the unicast network prefix defined in [RFC 2374] and assigned to the domain owning the multicast address. Haberman 2 Internet Draft IPv6 Multicast Address Architecture December 1999 group ID identifies the multicast group, either permanent or transient, within the given scope. The _meaning_ of a permanently assigned multicast address is independent of the scope value. For example, if the _NTP servers group_ is assigned a permanent multicast address with a group ID of 101 (hex), then: FF01::101 means all NTP servers on the same node as the sender. FF02::101 means all NTP servers on the same link as the sender. FF05::101 means all NTP servers in the same site as the sender. FF0E::101 means all NTP servers in the Internet. Non-permanently-assigned multicast addresses are meaningful only within a given scope. For example, a group identified by the non-permanent, site-local multicast address FF15::101 at one site bears no relationship to a group using the same address at a different site, or to a non-permanent group using the same group ID with a different scope, nor to a permanent group with the same group ID. Multicast addresses must not be used as source addresses in IPv6 packets or appear in any routing header. 4. Pre-Defined Multicast Addresses The following well-known multicast addresses are pre-defined: Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 FF01:0:0:0:0:0:0:0 FF02:0:0:0:0:0:0:0 FF03:0:0:0:0:0:0:0 FF04:0:0:0:0:0:0:0 FF05:0:0:0:0:0:0:0 FF06:0:0:0:0:0:0:0 FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0 FF09:0:0:0:0:0:0:0 FF0A:0:0:0:0:0:0:0 FF0B:0:0:0:0:0:0:0 FF0C:0:0:0:0:0:0:0 FF0D:0:0:0:0:0:0:0 FF0E:0:0:0:0:0:0:0 FF0F:0:0:0:0:0:0:0 The above multicast addresses are reserved and shall never be assigned to any multicast group. All Nodes Addresses: FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1 The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (node-local) or 2 (link-local). All Routers Addresses: FF01:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:2 Haberman 3 Internet Draft IPv6 Multicast Address Architecture December 1999 FF05:0:0:0:0:0:0:2 The above multicast addresses identify the group of all IPv6 routers, within scope 1 (node-local), 2 (link-local), or 5 (site-local). Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX The above multicast address is computed as a function of a node's unicast and anycast addresses. The solicited-node multicast address is formed by taking the low-order 24 bits of the address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the range FF02:0:0:0:0:1:FF00:0000 to FF02:0:0:0:01:FFFF:FFFF. For example, the solicited node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C:6C. IPv6 addresses that differ only in the high-order bits, e.g. due to multiple high-order prefixes associated with different aggregations, will map to the same solicited-node address thereby reducing the number of multicast addresses a node must join. A node is required to compute and join the associated Solicited-Node multicast addresses for every unicast and anycast address it is assigned. 5. Assignment of New IPv6 Multicast Addresses The current approach [RFC 2464] to map IPv6 multicast addresses into IEEE 802 MAC addresses takes that low order 32 bits of the IPv6 multicast address and uses it to create a MAC address. Note that Token Ring networks are handled differently. This is defined in [RFC 2470]. Group ID's less than or equal to 32 bits will generate unique MAC addresses. Due to this, new IPv6 multicast addresses that are not network prefix- based should be assigned so that the group identifier is always in the low order 32 bits as shown in the following: | 8 | 4 | 4 | 80 bits | 32 bits | +--------+----+----+------------------------------+-------------------+ |11111111|flgs|scop| reserved must be zero | group ID | +--------+----+----+------------------------------+-------------------+ Any new IPv6 multicast addresses that are network prefix-based will have the following format: | 8 | 4 | 4 | 8 | plen bits | 72 _ plen | 32 bits | +--------+----+----+--------+----------------+-----------+------------+ |11111111|flgs|scop| plen | Network prefix | reserved | group ID | +--------+----+----+--------+----------------+-----------+------------+ While this limits the number of permanent IPv6 multicast groups to 2^32 this is unlikely to be a limitation in the future. If it becomes necessary to exceed this limit in the future multicast will still work but the processing will be slightly slower. With the network prefix-based architecture and the current unicast address architecture [RFC 2374], the network prefix portion of the Haberman 4 Internet Draft IPv6 Multicast Address Architecture December 1999 multicast address will be at most 64 bits. This allows for the group ID field to be 40 bits. Additional IPv6 multicast addresses are defined and registered by the IANA [RFC 2375]. 6. Security Considerations This document does not have any direct impact on Internet infrastructure security. 7. References [RFC 2026] S. Bradner, _The Internet Standards Process -- Revision 3_, BCP 9, RFC 2026, October 1996. [RFC 2460] S. Deering and R. Hinden, _Internet Protocol, Version 6 (IPv6) Specification_, RFC 2460, December 1998. [RFC 2373] R. Hinden and S. Deering, _IP Version 6 Addressing Architecture_, RFC 2373, July 1998. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1999. [RFC 2374] R. Hinden, M. O'Dell, and S. Deering, _An IPv6 Aggregatable Global Unicast Address Format_, RFC 2374, July 1998. [RFC 2464] M. Crawford, _Transmission of IPv6 Packets over Ethernet Networks_, RFC 2464, December 1998. [RFC 2470] M. Crawford, T. Narten, and S. Thomas, _Transmission of IPv6 Packets over Token Ring Networks_, RFC 2470, December 1998. [RFC 2375] R. Hinden and S. Deering, _IPv6 Multicast Address Assignments_, RFC 2375, July 1998. Haberman 5 Author's Address Brian Haberman Nortel Networks 4309 Emperor Blvd. Suite 200 Durham, NC 27703 1-919-992-4439 Email : haberman@nortelnetworks.com Haberman 6 --------------B3C64868B09FEC961C85E0B8-- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 10 08:17:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0AGEdh26893 for ipng-dist; Mon, 10 Jan 2000 08:14:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0AGERY26886 for ; Mon, 10 Jan 2000 08:14:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA20923 for ; Mon, 10 Jan 2000 08:14:28 -0800 (PST) Received: from lychee.itojun.org (206-175-160-20.vpnworkshop.com [206.175.160.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17078 for ; Mon, 10 Jan 2000 08:14:27 -0800 (PST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA10506 for ; Tue, 11 Jan 2000 01:14:18 +0900 (JST) To: IPng Mailing List Subject: iruserok() with address-family independence X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Mon, 10 Jan 2000 08:14:14 -0800 Message-ID: <10486.947520854@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk *BSD and linux (I heard) uses iruserok() and friends as backend to ruserok(). the function is publically visible and used from rlogind/rshd/whatever, though not well-documented (no manpage on *BSD). iruserok has prototype like below and it is IPv4 only: >int >iruserok(raddr, superuser, ruser, luser) > u_int32_t raddr; <-- struct in_addr > int superuser; > const char *ruser, *luser; I would like to propose the following variant, which takes sockaddr *, for address-family independence: >int >iruserok_sa(ra, rlen, superuser, ruser, luser) > const void *ra; <-- const struct sockaddr * > int rlen; > int superuser; > const char *ruser, *luser; first argument is typed as const void *, just to avoid dependency between unistd.h and sys/socket.h. it really is (and should be) const struct sockaddr *. I've been using it on KAME kit and having no problem with it. Any opinions on this? should this be included into future 2292bis variant? (i'll write up a section if it should be included). itojun --- 2292bis 14. Extended interfaces for rresvport, rcmd and rexec ............... 45 14.1. rresvport_af .............................................. 45 14.2. rcmd_af ................................................... 45 14.3. rexec_af .................................................. 46 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 10 08:39:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0AGaeG26951 for ipng-dist; Mon, 10 Jan 2000 08:36:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0AGaVY26944 for ; Mon, 10 Jan 2000 08:36:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA02547 for ; Mon, 10 Jan 2000 08:36:31 -0800 (PST) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15823 for ; Mon, 10 Jan 2000 09:36:20 -0700 (MST) Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id RAA20704; Mon, 10 Jan 2000 17:36:16 +0100 (MET) Received: (from nisse@localhost) by sanna.lysator.liu.se (8.8.8/8.8.7) id RAA03349; Mon, 10 Jan 2000 17:36:11 +0100 (MET) To: Jun-ichiro itojun Hagino Cc: IPng Mailing List Subject: Re: iruserok() with address-family independence References: <10486.947520854@lychee.itojun.org> From: nisse@lysator.liu.se (Niels Möller) Date: 10 Jan 2000 17:36:10 +0100 In-Reply-To: Jun-ichiro itojun Hagino's message of "Mon, 10 Jan 2000 08:14:14 -0800" Message-ID: Lines: 21 X-Mailer: Gnus v5.4.59/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino writes: > >int > >iruserok_sa(ra, rlen, superuser, ruser, luser) > > const void *ra; <-- const struct sockaddr * > > int rlen; > > int superuser; > > const char *ruser, *luser; > > first argument is typed as const void *, just to avoid dependency > between unistd.h and sys/socket.h. it really is (and should be) > const struct sockaddr *. To me, using void *, for this reason, sounds like a bizarre hack. Wouldn't it be better to add a forward declaration struct sockaddr; to unistd.h? There's no reason to include sys/socket.h just for that. /Niels -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 10 08:45:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0AGili26992 for ipng-dist; Mon, 10 Jan 2000 08:44:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0AGicY26985 for ; Mon, 10 Jan 2000 08:44:38 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA25064 for ; Mon, 10 Jan 2000 08:44:39 -0800 (PST) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04157 for ; Mon, 10 Jan 2000 08:44:37 -0800 (PST) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id BAA12073; Tue, 11 Jan 2000 01:44:30 +0900 To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: iruserok() with address-family independence From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <10486.947520854@lychee.itojun.org> References: <10486.947520854@lychee.itojun.org> X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000111014430K.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Tue, 11 Jan 2000 01:44:30 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <10486.947520854@lychee.itojun.org> (at Mon, 10 Jan 2000 08:14:14 -0800), Jun-ichiro itojun Hagino says: > >int > >iruserok_sa(ra, rlen, superuser, ruser, luser) > > const void *ra; <-- const struct sockaddr * > > int rlen; > > int superuser; > > const char *ruser, *luser; > I've been using it on KAME kit and having no problem with it. [Q] What is the meaning of the head letter 'i'? If it means "IP", protocol-independent "ruserok_sa" is more preferable, isn't it? -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 10 08:51:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0AGmwU27073 for ipng-dist; Mon, 10 Jan 2000 08:48:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0AGmkY27063 for ; Mon, 10 Jan 2000 08:48:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA06416 for ; Mon, 10 Jan 2000 08:48:46 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21469 for ; Mon, 10 Jan 2000 09:48:44 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA26908; Tue, 11 Jan 2000 01:48:36 +0900 (JST) To: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) cc: ipng@sunroof.eng.sun.com In-reply-to: yoshfuji's message of Tue, 11 Jan 2000 01:44:30 JST. <20000111014430K.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: iruserok() with address-family independence From: itojun@iijlab.net Date: Tue, 11 Jan 2000 01:48:36 +0900 Message-ID: <26906.947522916@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I've been using it on KAME kit and having no problem with it. > >[Q] What is the meaning of the head letter 'i'? > >If it means "IP", protocol-independent "ruserok_sa" is more >preferable, isn't it? I'm not the one who invented iruserok(). ruserok() itself is completely protocol independent as it takes string as hostname part. iruserok() is used as backend for ruserok() for IPv4 only. I just wanted to make sure iruserok() is usable for IPv4 and IPv6. For actual code path please visit the source code. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 10 09:36:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e0AHY0N27181 for ipng-dist; Mon, 10 Jan 2000 09:34:00 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0AHXnY27174 for ; Mon, 10 Jan 2000 09:33:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA12728 for ; Mon, 10 Jan 2000 09:33:49 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16773 for ; Mon, 10 Jan 2000 09:38:33 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA26763; Tue, 11 Jan 2000 01:38:17 +0900 (JST) To: nisse@lysator.liu.se (Niels Mller) cc: IPng Mailing List In-reply-to: nisse's message of 10 Jan 2000 17:36:10 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: iruserok() with address-family independence From: itojun@iijlab.net Date: Tue, 11 Jan 2000 01:38:17 +0900 Message-ID: <26761.947522297@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >int >> >iruserok_sa(ra, rlen, superuser, ruser, luser) >> > const void *ra; <-- const struct sockaddr * >> > int rlen; >> > int superuser; >> > const char *ruser, *luser; >> first argument is typed as const void *, just to avoid dependency >> between unistd.h and sys/socket.h. it really is (and should be) >> const struct sockaddr *. >To me, using void *, for this reason, sounds like a bizarre hack. >Wouldn't it be better to add a forward declaration > struct sockaddr; >to unistd.h? There's no reason to include sys/socket.h just for that. I'm not sure about the include file dependency issue, and not sure if I'm allowed to include forward decl for it. there should be some un*x standards issue. I need clarification from some POSIX/xopen gurus. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 11 03:41:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0BBdUH28446 for ipng-dist; Tue, 11 Jan 2000 03:39:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0BBdKw28439 for ; Tue, 11 Jan 2000 03:39:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA21896 for ; Tue, 11 Jan 2000 03:39:19 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15593 for ; Tue, 11 Jan 2000 03:39:18 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03604; Tue, 11 Jan 2000 06:39:19 -0500 (EST) Message-Id: <200001111139.GAA03604@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-mld-mib-02.txt Date: Tue, 11 Jan 2000 06:39:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol Author(s) : B. Haberman, R. Worzella Filename : draft-ietf-ipngwg-mld-mib-02.txt Pages : 12 Date : 10-Jan-00 This document defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module which defines managed objects for implementations of the Multicast Listener Discovery Protocol [MLD]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-mld-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000110111207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000110111207.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 11 05:37:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0BDZea28553 for ipng-dist; Tue, 11 Jan 2000 05:35:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0BDZVw28546 for ; Tue, 11 Jan 2000 05:35:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA14423 for ; Tue, 11 Jan 2000 05:35:32 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11840 for ; Tue, 11 Jan 2000 06:35:31 -0700 (MST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id IAA01286; Tue, 11 Jan 2000 08:34:29 -0500 Message-Id: <200001111334.IAA01286@hygro.adsl.duke.edu> To: "Brian Haberman" cc: IPng Mailing List Subject: Re: Multicast Address Architecture draft In-Reply-To: Message from "Brian Haberman" of "Mon, 10 Jan 2000 08:12:55 EST." <3879DAD7.DBC8C7E4@nortelnetworks.com> Date: Tue, 11 Jan 2000 08:34:28 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, This document has an interesting feature that the WG needs to think about. Namely, it defines multicast addresses as follows: > An IPv6 multicast address is an identifier for a group of nodes. A > node may belong to any number of multicast groups. Multicast addresses > have the following format: > > | 8 | 4 | 4 | 8 | plen | 104 - plen | > +--------+----+----+--------+--------------------+--------------------+ > |11111111|flgs|scop| plen | network prefix | group ID | > +--------+ + > ---- ----+--------+--------------------+--------------------+ > The network prefix is defined as: > network prefix identifies the network prefix of the unicast subnet > owning the multicast address. If P = 0, this field is considered a > part of the group ID. If P = 1, this field contains the unicast > network prefix defined in [RFC 2374] and assigned to the domain owning > the multicast address. Up until now, the internal bits of a multicast addresses have by design been all zeros, in order to minimize collisions of link-layer multicast addresses when IP multicast addresses are mapped into link-layer addresses. RFC 2373 specifically says: > 2.7.2 Assignment of New IPv6 Multicast Addresses > > The current approach [ETHER] to map IPv6 multicast addresses into > IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 > multicast address and uses it to create a MAC address. Note that > Token Ring networks are handled differently. This is defined in > [TOKEN]. Group ID's less than or equal to 32 bits will generate > unique MAC addresses. Due to this new IPv6 multicast addresses > should be assigned so that the group identifier is always in the low > order 32 bits as shown in the following: > > | 8 | 4 | 4 | 80 bits | 32 bits | > +------ -+----+----+---------------------------+-----------------+ > |11111111|flgs|scop| reserved must be zero | group ID | > +--------+----+----+---------------------------+-----------------+ > > While this limits the number of permanent IPv6 multicast groups to > 2^32 this is unlikely to be a limitation in the future. If it > becomes necessary to exceed this limit in the future multicast will > still work but the processing will be sightly slower. Brian's draft would likely result in more collisions. Whether or not that is a significant problem is a matter of debate. Another area where the middle bits of a multicast address might be something other than all zeros is with administratively scoped multicast addresses (RFC 2365). That document doesn't come right out and say it applies to IPv6, but it can be read that way. The implication of that document is that scope-relative addresses will have a bunch of middle bits of all 1s. I believe this WG needs to think about administratively scoped addresses and decide whether the approach outlined in 2365 is what should be done in IPv6. If so, a short document is probably needed. For one thing, IANA has not been asked to reserve a range of IPv6 addresses for this purpose. Thomas -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 11 05:53:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0BDops28600 for ipng-dist; Tue, 11 Jan 2000 05:50:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0BDogw28593 for ; Tue, 11 Jan 2000 05:50:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA15280 for ; Tue, 11 Jan 2000 05:50:42 -0800 (PST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17837 for ; Tue, 11 Jan 2000 06:50:42 -0700 (MST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 11 Jan 2000 07:50:33 -0600 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CKFVAMWC; Tue, 11 Jan 2000 07:49:52 -0600 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z4V1K3MM; Tue, 11 Jan 2000 08:49:53 -0500 Message-ID: <387B345E.584F0B6B@nortelnetworks.com> Date: Tue, 11 Jan 2000 08:47:10 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: IPng Mailing List Subject: Re: Multicast Address Architecture draft References: <200001111334.IAA01286@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Thomas Narten wrote: > Up until now, the internal bits of a multicast addresses have by > design been all zeros, in order to minimize collisions of link-layer > multicast addresses when IP multicast addresses are mapped into > link-layer addresses. RFC 2373 specifically says: > > > 2.7.2 Assignment of New IPv6 Multicast Addresses > > > > The current approach [ETHER] to map IPv6 multicast addresses into > > IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 > > multicast address and uses it to create a MAC address. Note that > > Token Ring networks are handled differently. This is defined in > > [TOKEN]. Group ID's less than or equal to 32 bits will generate > > unique MAC addresses. Due to this new IPv6 multicast addresses > > should be assigned so that the group identifier is always in the low > > order 32 bits as shown in the following: > > > > | 8 | 4 | 4 | 80 bits | 32 bits | > > +------ -+----+----+---------------------------+-----------------+ > > |11111111|flgs|scop| reserved must be zero | group ID | > > +--------+----+----+---------------------------+-----------------+ > > > > While this limits the number of permanent IPv6 multicast groups to > > 2^32 this is unlikely to be a limitation in the future. If it > > becomes necessary to exceed this limit in the future multicast will > > still work but the processing will be sightly slower. > > Brian's draft would likely result in more collisions. Whether or not > that is a significant problem is a matter of debate. > There is actually a companion document in the works that specifies how the network prefix portion of the address should be used as a seed into a hash algorithm to compute the actual group ID. This will help minimize the collisions. The upcoming document is targeted towards the MALLOC working group due to the dynamic allocation properties that this change was designed for. > > Another area where the middle bits of a multicast address might be > something other than all zeros is with administratively scoped > multicast addresses (RFC 2365). That document doesn't come right out > and say it applies to IPv6, but it can be read that way. The > implication of that document is that scope-relative addresses will > have a bunch of middle bits of all 1s. I believe this WG needs to > think about administratively scoped addresses and decide whether the > approach outlined in 2365 is what should be done in IPv6. If so, a > short document is probably needed. For one thing, IANA has not been > asked to reserve a range of IPv6 addresses for this purpose. > I may be mistaken, but I thought that administrative scoping in IPv6 is supposed to be handled by the scope field. Even so, this approach can work with 2365. Brian -- Brian Haberman Advanced Network Research Nortel Networks haberman@nortelnetworks.com -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 11 09:36:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0BHXhA28793 for ipng-dist; Tue, 11 Jan 2000 09:33:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0BHXYw28786 for ; Tue, 11 Jan 2000 09:33:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA29634 for ; Tue, 11 Jan 2000 09:33:33 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09056 for ; Tue, 11 Jan 2000 09:33:32 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA30446; Tue, 11 Jan 2000 12:30:17 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA25816; Tue, 11 Jan 2000 12:30:22 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id MAA03190; Tue, 11 Jan 2000 12:29:36 -0500 Message-Id: <200001111729.MAA03190@rotala.raleigh.ibm.com> To: "Brian Haberman" cc: IPng Mailing List Subject: Re: Multicast Address Architecture draft In-Reply-To: Message from "Brian Haberman" of "Tue, 11 Jan 2000 08:47:10 EST." <387B345E.584F0B6B@nortelnetworks.com> Date: Tue, 11 Jan 2000 12:29:36 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > There is actually a companion document in the works that specifies how > the network prefix portion of the address should be used as a seed into > a hash algorithm to compute the actual group ID. ^^^^^^^^^^^^^^^ Clarification: are you refering to link-layer group ID above, or something else? > I may be mistaken, but I thought that administrative scoping in IPv6 is > supposed to be handled by the scope field. Even so, this approach > can work with 2365. Yes. But the adminstratively scoped "well known" services are specified as offsets relative to a base address. When one looks at the actual multicast addresses that these offsets correspond to, they are full of 1's in the middle of the address. That may be fine, but it is a point the WG should think about, since it conflicts somewhat with the text in the addressing architecture document. Thomas -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 11 10:34:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0BIUMb28887 for ipng-dist; Tue, 11 Jan 2000 10:30:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0BIUCw28880 for ; Tue, 11 Jan 2000 10:30:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA05772 for ; Tue, 11 Jan 2000 10:30:11 -0800 (PST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18181 for ; Tue, 11 Jan 2000 10:30:09 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 11 Jan 2000 12:30:34 -0600 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CKFVAVVJ; Tue, 11 Jan 2000 12:29:53 -0600 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z4V1KP20; Tue, 11 Jan 2000 13:29:54 -0500 Message-ID: <387B75FE.378626DD@nortelnetworks.com> Date: Tue, 11 Jan 2000 13:27:11 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: IPng Mailing List Subject: Re: Multicast Address Architecture draft References: <200001111729.MAA03190@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Thomas Narten wrote: > > There is actually a companion document in the works that specifies how > > the network prefix portion of the address should be used as a seed into > > a hash algorithm to compute the actual group ID. > ^^^^^^^^^^^^^^^ > > Clarification: are you refering to link-layer group ID above, or > something else? I am referring to the group ID portion of the IPv6 multicast address which gets mapped into the link-layer group ID. > > > > I may be mistaken, but I thought that administrative scoping in IPv6 is > > supposed to be handled by the scope field. Even so, this approach > > can work with 2365. > > Yes. But the adminstratively scoped "well known" services are > specified as offsets relative to a base address. When one looks at the > actual multicast addresses that these offsets correspond to, they are > full of 1's in the middle of the address. That may be fine, but it is > a point the WG should think about, since it conflicts somewhat with > the text in the addressing architecture document. Even so, they will not have the 'p' bit set, unless the network admin decides to setup an administratively scoped multicast group to be allocated by MADCAP or AAP. Where exactly in the addressing architecture document does it conflict? Brian -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 11 11:21:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0BJJ7Q28972 for ipng-dist; Tue, 11 Jan 2000 11:19:07 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0BJIvw28964 for ; Tue, 11 Jan 2000 11:18:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA03697 for ; Tue, 11 Jan 2000 11:18:56 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21367 for ; Tue, 11 Jan 2000 11:18:54 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA28766; Tue, 11 Jan 2000 14:13:33 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA34674; Tue, 11 Jan 2000 14:13:37 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA03668; Tue, 11 Jan 2000 14:12:51 -0500 Message-Id: <200001111912.OAA03668@rotala.raleigh.ibm.com> To: "Brian Haberman" cc: IPng Mailing List Subject: Re: Multicast Address Architecture draft In-Reply-To: Message from "Brian Haberman" of "Tue, 11 Jan 2000 13:27:11 EST." <387B75FE.378626DD@nortelnetworks.com> Date: Tue, 11 Jan 2000 14:12:51 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Where exactly in the addressing architecture document does it > conflict? My main point is that at one point in the distant past, an attempt was made to keep the middle bits 0's in IP multicast addresses, in order to minimize collisions that might occur when two different IP multicast addresses map into the same link-layer address. This is reflected in the RFC 2373 text I quoted in my original message. Your proposal will use bits other than zero in the middle of the multicast address. I'm not sure this is a big deal, but just wanted to point it out to the WG as something that should be thought about. Thomas -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 11 12:12:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0BKADM29217 for ipng-dist; Tue, 11 Jan 2000 12:10:13 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0BKA3w29210 for ; Tue, 11 Jan 2000 12:10:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA12398 for ; Tue, 11 Jan 2000 12:10:02 -0800 (PST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24624 for ; Tue, 11 Jan 2000 12:10:00 -0800 (PST) Received: from smtprtp.ntcom.nortel.net (actually zrtph06n) by smtprtp1.ntcom.nortel.net; Tue, 11 Jan 2000 14:56:49 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Tue, 11 Jan 2000 14:44:23 -0500 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y6950A3T; Tue, 11 Jan 2000 14:44:06 -0500 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z4V1KPQ3; Tue, 11 Jan 2000 14:43:22 -0500 Message-ID: <387B8737.9C8EE7A5@nortelnetworks.com> Date: Tue, 11 Jan 2000 14:40:39 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: IPng Mailing List Subject: Re: Multicast Address Architecture draft References: <200001111912.OAA03668@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > My main point is that at one point in the distant past, an attempt was > made to keep the middle bits 0's in IP multicast addresses, in order > to minimize collisions that might occur when two different IP > multicast addresses map into the same link-layer address. This is > reflected in the RFC 2373 text I quoted in my original message. Your > proposal will use bits other than zero in the middle of the multicast > address. > This was actually discussed in the MALLOC meeting in Oslo where I first presented this idea. That was where the concept of using the network prefix as a seed into a hash to generate the lowest 32 bits of the address. That would help minimize the collisions. I am still working on the details, but should have something soon. Brian -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 13 09:44:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0DHfJ200718 for ipng-dist; Thu, 13 Jan 2000 09:41:19 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0DHf8w00711 for ; Thu, 13 Jan 2000 09:41:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02312 for ; Thu, 13 Jan 2000 09:41:08 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09999 for ; Thu, 13 Jan 2000 09:41:06 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA15327 for ; Fri, 14 Jan 2000 02:41:04 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Tue, 11 Jan 2000 01:48:36 JST. <26906.947522916@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: iruserok() with address-family independence From: itojun@iijlab.net Date: Fri, 14 Jan 2000 02:41:04 +0900 Message-ID: <15325.947785264@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> I've been using it on KAME kit and having no problem with it. >>[Q] What is the meaning of the head letter 'i'? >>If it means "IP", protocol-independent "ruserok_sa" is more >>preferable, isn't it? > I'm not the one who invented iruserok(). > ruserok() itself is completely protocol independent as it takes string > as hostname part. > iruserok() is used as backend for ruserok() for IPv4 only. > I just wanted to make sure iruserok() is usable for IPv4 and IPv6. > For actual code path please visit the source code. In a second thought ruserok_sa looks okay to me. I still think iruserok_sa makes sense, as I'm still not quite sure if we ever need to use "ruserok" familiy for non-IP protocols (not IPv4 nor IPv6). do we really have such requiement? also i see couple of supporting functions, like ivaliduser() and icheckhost(), used in iruserok(). this suggest me not to play with the function name too much (for historical/least-surprise). I need more insight from someone familier with un*x API standards (and this is why I posted it here). To summarize the question: - are ruserok() and iruserok() in any of standards? NetBSD manpage says they were from 4.2BSD, nothing more. - if we supply address-family neutral version of iruserok (takes sockaddr but I doubt this would be used with non-IP protocol), which is preferable? iruserok_sa ruserok_sa and question to ipngwg: - do we need iruserok_sa (or ruserok_sa) in 2292bis? itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 13 13:56:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0DLsPi01242 for ipng-dist; Thu, 13 Jan 2000 13:54:25 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0DLsEw01235 for ; Thu, 13 Jan 2000 13:54:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA28387 for ; Thu, 13 Jan 2000 13:54:13 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA29012 for ; Thu, 13 Jan 2000 13:54:10 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA09651 for ; Thu, 13 Jan 2000 13:54:45 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA28458 for ; Thu, 13 Jan 2000 13:54:43 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id NAA07958 for ipng@sunroof.eng.sun.com; Thu, 13 Jan 2000 13:54:37 -0800 (PST) Date: Thu, 13 Jan 2000 13:54:37 -0800 (PST) From: Tim Hartrick Message-Id: <200001132154.NAA07958@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: Re: iruserok() with address-family independence X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, In looking at the manpages from several standards based UNIX systems I see no reference to iruserok. I also can't find prototypes for these functions in any header files on these standards based UNIX systems. I take this to mean that they are not part of any UNIX standard. My personal opinion is that 2292bis does not need to make any statement about these functions since they are not part of any standard or defacto standard API. As long as an implementation's ruserok works as expected for IPv4 and IPv6 I don't think anything more needs to be defined regarding what happens behinds the scenes. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 13 23:40:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0E7cTu01795 for ipng-dist; Thu, 13 Jan 2000 23:38:29 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0E7cIw01788 for ; Thu, 13 Jan 2000 23:38:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA21403 for ; Thu, 13 Jan 2000 23:38:18 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA24657 for ; Thu, 13 Jan 2000 23:38:17 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id QAA25103; Fri, 14 Jan 2000 16:38:02 +0900 (JST) To: Tim Hartrick cc: ipng@sunroof.eng.sun.com In-reply-to: tim's message of Thu, 13 Jan 2000 13:54:37 PST. <200001132154.NAA07958@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: iruserok() with address-family independence From: itojun@iijlab.net Date: Fri, 14 Jan 2000 16:38:02 +0900 Message-ID: <25101.947835482@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In looking at the manpages from several standards based UNIX >systems I see no reference to iruserok. I also can't find prototypes >for these functions in any header files on these standards based UNIX >systems. I take this to mean that they are not part of any UNIX standard. > My personal opinion is that 2292bis does not need to make any >statement about these functions since they are not part of any standard >or defacto standard API. As long as an implementation's ruserok works >as expected for IPv4 and IPv6 I don't think anything more needs to be defined >regarding what happens behinds the scenes. Hmm, I see. so all I'll need to do is to get some agreement about iruserok_sa or ruserok_sa (because they are publically available function and used in BSD/linux rshd/rlogind, we need to have certain agreement). I still vote for iruserok_sa, and not ruserok_sa, for minimum surprise in existing code. Another one we have on the table is bindresvport() (NOTE: old one, like int bindresvport(int sd, struct sockaddr_in *sin) I'm in favor of bindresvport_af(), with additional "af" argument. I don't want too many changes in behavior and would like to keep the change minimum. int bindresvport_af(int sd, struct sockaddr *sa, int af) (openbsd-current already has this) I vote against int bindresvport_sa(int sd, struct sockaddr *sa) (which takes "af" from sa->sa_family). bindresvport() allows "sin" to be NULL so we always need to pass address family even in this case. I do not want behavior change here. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 02:55:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0EArT301947 for ipng-dist; Fri, 14 Jan 2000 02:53:29 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0EArKw01940 for ; Fri, 14 Jan 2000 02:53:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA00493 for ; Fri, 14 Jan 2000 02:53:19 -0800 (PST) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA03069 for ; Fri, 14 Jan 2000 03:53:14 -0700 (MST) Received: (from richier@localhost) by horus.imag.fr (8.9.3/8.8.5) id LAA22078; Fri, 14 Jan 2000 11:52:52 +0100 (MET) Date: Fri, 14 Jan 2000 11:52:52 +0100 (MET) From: Jean-Luc Richier Message-Id: <200001141052.LAA22078@horus.imag.fr> In-Reply-To: itojun@iijlab.net's message as of Jan 14, 16:38. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: itojun@iijlab.net, Tim Hartrick Subject: Re: iruserok() with address-family independence Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dans votre courrier du 14 Jan 16:38 vous ecrivez : > >> In looking at the manpages from several standards based UNIX >>systems I see no reference to iruserok. I also can't find prototypes >>for these functions in any header files on these standards based UNIX >>systems. I take this to mean that they are not part of any UNIX standard. >> My personal opinion is that 2292bis does not need to make any >>statement about these functions since they are not part of any standard >>or defacto standard API. As long as an implementation's ruserok works >>as expected for IPv4 and IPv6 I don't think anything more needs to be defined >>regarding what happens behinds the scenes. > > Hmm, I see. so all I'll need to do is to get some agreement > about iruserok_sa or ruserok_sa (because they are publically available > function and used in BSD/linux rshd/rlogind, we need to have certain > agreement). I still vote for iruserok_sa, and not ruserok_sa, > for minimum surprise in existing code. > > > Another one we have on the table is bindresvport() (NOTE: old one, like > int bindresvport(int sd, struct sockaddr_in *sin) > > I'm in favor of bindresvport_af(), with additional "af" argument. > I don't want too many changes in behavior and would like to keep > the change minimum. > int bindresvport_af(int sd, struct sockaddr *sa, int af) > (openbsd-current already has this) > > I vote against > int bindresvport_sa(int sd, struct sockaddr *sa) > (which takes "af" from sa->sa_family). bindresvport() allows > "sin" to be NULL so we always need to pass address family even in > this case. I do not want behavior change here. I do not agree, bindresvport_sa does not take "af" from sa->sa_family, it already know the family from the socket argument sd. So even it sa is NULL, bindresvport - or bindresvport_sa still works. For exemple do a getsockname of sd to find the family. So I think an af argument is redundant. I fact in an early port of libc I tried it, and in some INET/INET6 independant code I had to add code to compute the af argument simply to pass it. Letting bindresvport* to compute it is simpler. I vote for bindresvport_sa, (or keeping bindresvport). According to my experience, the problems with bindresvport are: - the sa_family field of sa (everybody initializes it to AF_INET) In INRIA port I added the AF_UNSPEC value to signify : unknown, set it. - and over all the size of the returned value -with a PF_INET6 sd, the returned sockaddr_in6 will overflow a sockaddr_in buffer. That is why we may need a new function for forcing arg checks, with or without a len argument (len of sa argument). I do not think len is needed, if the new function use a generic type (sockaddr) for sa or a big type (sockaddr_storage). -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 03:02:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0EB0mk02001 for ipng-dist; Fri, 14 Jan 2000 03:00:48 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0EB0bw01994 for ; Fri, 14 Jan 2000 03:00:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA19583 for ; Fri, 14 Jan 2000 03:00:37 -0800 (PST) Received: from lychee.itojun.org (ny-ppp018.iij-us.net [216.98.99.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04982 for ; Fri, 14 Jan 2000 04:00:35 -0700 (MST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA00528; Fri, 14 Jan 2000 02:59:41 -0800 (PST) To: Jean-Luc Richier cc: Tim Hartrick , ipng@sunroof.eng.sun.com In-reply-to: Jean-Luc.Richier's message of Fri, 14 Jan 2000 11:52:52 +0100. <200001141052.LAA22078@horus.imag.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: iruserok() with address-family independence From: Jun-ichiro itojun Hagino Date: Fri, 14 Jan 2000 02:59:40 -0800 Message-ID: <526.947847580@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I vote against >> int bindresvport_sa(int sd, struct sockaddr *sa) >> (which takes "af" from sa->sa_family). bindresvport() allows >> "sin" to be NULL so we always need to pass address family even in >> this case. I do not want behavior change here. >I do not agree, bindresvport_sa does not take "af" from sa->sa_family, >it already know the family from the socket argument sd. So even it sa is >NULL, bindresvport - or bindresvport_sa still works. For exemple do a >getsockname of sd to find the family. Could you tell me more about your behavior in sa == NULL case? Also, please do not assume IPv4 mapped address for discussion, there are systems which does not (and will not) have it. AF_INET6 socket does not grab IPv4 connections, so you need to be explicit about address family, or use getaddrinfo to make a loop. >According to my experience, the problems with bindresvport are: >- the sa_family field of sa (everybody initializes it to AF_INET) > In INRIA port I added the AF_UNSPEC value to signify : unknown, set it. >- and over all the size of the returned value -with a PF_INET6 sd, the > returned sockaddr_in6 will overflow a sockaddr_in buffer. > That is why we may need a new function for forcing arg checks, with or > without a len argument (len of sa argument). I do not think len is needed, > if the new function use a generic type (sockaddr) for sa or a big type > (sockaddr_storage). How did you made sure that there's no buffer overrun? In your method third-party code would not notice the change and there will be buffer overrun if you regard AF_UNSPEC as AF_INET6 (or you will end up hardcode AF_UNSPEC behavior to AF_INET). itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 03:05:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0EB3mk02027 for ipng-dist; Fri, 14 Jan 2000 03:03:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0EB3Zw02012 for ; Fri, 14 Jan 2000 03:03:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA02262 for ; Fri, 14 Jan 2000 03:03:34 -0800 (PST) Received: from lychee.itojun.org (ny-ppp018.iij-us.net [216.98.99.18]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15714 for ; Fri, 14 Jan 2000 03:03:33 -0800 (PST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.9.3+3.2W/3.7W) with ESMTP id DAA00553; Fri, 14 Jan 2000 03:02:48 -0800 (PST) To: Jean-Luc Richier , ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Fri, 14 Jan 2000 02:59:40 PST. <526.947847580@lychee.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: iruserok() with address-family independence From: Jun-ichiro itojun Hagino Date: Fri, 14 Jan 2000 03:02:48 -0800 Message-ID: <551.947847768@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>- and over all the size of the returned value -with a PF_INET6 sd, the >> returned sockaddr_in6 will overflow a sockaddr_in buffer. >> That is why we may need a new function for forcing arg checks, with or >> without a len argument (len of sa argument). I do not think len is needed, >> if the new function use a generic type (sockaddr) for sa or a big type >> (sockaddr_storage). > How did you made sure that there's no buffer overrun? I may not be clear enough, I understand there are options in avoiding buffer overrun, I would like to know how you did it in your previous implementation, without having len, nor without changing function signature (to sockaddr_storage * - I don't really like passing around sockaddr_storage *). itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 03:31:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0EBSWZ02128 for ipng-dist; Fri, 14 Jan 2000 03:28:32 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0EBSNw02119 for ; Fri, 14 Jan 2000 03:28:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA03698 for ; Fri, 14 Jan 2000 03:28:23 -0800 (PST) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA12112 for ; Fri, 14 Jan 2000 04:28:17 -0700 (MST) Received: (from richier@localhost) by horus.imag.fr (8.9.3/8.8.5) id MAA24510; Fri, 14 Jan 2000 12:27:55 +0100 (MET) Date: Fri, 14 Jan 2000 12:27:55 +0100 (MET) From: Jean-Luc Richier Message-Id: <200001141127.MAA24510@horus.imag.fr> In-Reply-To: Jun-ichiro itojun Hagino's message as of Jan 14, 2:59. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Jun-ichiro itojun Hagino Subject: Re: iruserok() with address-family independence Cc: Tim Hartrick , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dans votre courrier du 14 Jan 2:59 vous ecrivez : > >>> I vote against >>> int bindresvport_sa(int sd, struct sockaddr *sa) >>> (which takes "af" from sa->sa_family). bindresvport() allows >>> "sin" to be NULL so we always need to pass address family even in >>> this case. I do not want behavior change here. >>I do not agree, bindresvport_sa does not take "af" from sa->sa_family, >>it already know the family from the socket argument sd. So even it sa is >>NULL, bindresvport - or bindresvport_sa still works. For exemple do a >>getsockname of sd to find the family. > > Could you tell me more about your behavior in sa == NULL case? if sa == NULL, the distrib bindresvport code do struct sockaddr_in myaddr; int sinlen = sizeof(struct sockaddr_in); if (sin == (struct sockaddr_in *)0) { sin = &myaddr; memset(sin, 0, sinlen); sin->sin_len = sinlen; sin->sin_family = AF_INET; } if (sin->sin_family != AF_INET) { errno = EPFNOSUPPORT; return (-1); } My code do (not the actual code, but the idea) RPC_SOCKADDR_IN myaddr; int sinaf, sinlen; if (sin == (RPC_SOCKADDR_IN *)0) { sinlen = sizeof (myaddr); if (getsockname(sd, (struct sockaddr *)&myaddr, &sinlen) != 0) return (-1); sinaf = S_FAMILY(&myaddr); sin = &myaddr; memset(sin, 0, sizeof (myaddr)); S_FAMILY(sin) = sinaf; S_LEN(sin) = sinlen; } also for the case sin != NULL but sin->sa_family = AF_UNSPEC (sa is only a buffer for returned value) else if (sin && S_FAMILY(sin) == AF_UNSPEC) { sinlen = sizeof (myaddr); if (getsockname(sd, (struct sockaddr *)&myaddr, &sinlen) != 0) return (-1); S_FAMILY(sin) = sinaf = S_FAMILY(&myaddr); S_LEN(sin) = sinlen; } > Also, please do not assume IPv4 mapped address for discussion, > there are systems which does not (and will not) have it. AF_INET6 > socket does not grab IPv4 connections, so you need to be explicit > about address family, or use getaddrinfo to make a loop. I know about this kame choice, but in bindresvport, only sa_family code are used. I do not try to accept bind between INET6 socket and INET sockaddr or between INET socket and INET6 sockaddr. I do not even suppose that a sa_len field exists (I can add #ifdef SIN6_LEN tests). I only suppose that getsockname works on all open sockets and returns correct sa->sa_family and length arguments. -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 04:32:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0ECUQ202230 for ipng-dist; Fri, 14 Jan 2000 04:30:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0ECUIw02223 for ; Fri, 14 Jan 2000 04:30:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA05754 for ; Fri, 14 Jan 2000 04:30:14 -0800 (PST) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06702 for ; Fri, 14 Jan 2000 04:30:10 -0800 (PST) Received: (from richier@localhost) by horus.imag.fr (8.9.3/8.8.5) id NAA28837 for ipng@sunroof.eng.sun.com; Fri, 14 Jan 2000 13:30:10 +0100 (MET) Date: Fri, 14 Jan 2000 13:30:10 +0100 (MET) From: Jean-Luc Richier Message-Id: <200001141230.NAA28837@horus.imag.fr> Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: rfc2292bis-01 rcmd comments Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-ietf-ipngwg-2292bis-01.txt suggest extension to replace r-functions with hostname argument, rexec and rcmd. The suggestion is to add an af argument to specify the INET/INET6 family. This solution is the same as the one of gethostbyname2. I do not think it is sufficient. Both getipnodebyname and getaddrinfo use a more powerful scheme: one can specify AF_INET, AF_INET6 or both. The both case is in fact often the default and seems the right value for rlogin, rsh: user do not care whether the remote host has an IPv4 or IPv6, any will do. And making two calls for IPv6 and then IPv4 is an unneeded complication. Therefore I suggest a modification to the proposition, based on the getaddrinfo solution: in addition to the AF_INET and AF_INET6 values, the af argument can take a special value which means AF_INET6 or AF_INET. I suggest AF_UNSPEC as in getaddrinfo, so this argument can be simply used as value of a ai_family field of an hint argument to a call to getaddrinfo. (Other value are possible, the arg is often an int, and af values are from 0 to 255) I think that this is a general concern with porting any function which use a hostname as argument: we need a new argument to tell the AF_ family, but AF_INET or AF_UNET6 is not enough, we need a AF_INET_ANY flag or value. Saying that INET6 contains INET (implicitely always add the case of V4mapped addresses) may be too strong. A returned family value is not needed: generally a socket is reated, and getsokckname/getpeername can be used to find the actual family. I have seen the same problem when porting the rpc library for functions clnt_create, callrpc and getrpcport, and in url manipulation library. An other concern is managing scopeid/flowinfo fields. There should be an universal notation in address literals for this information. Also for any function which take an ip addr as argument there should be a new one with a sockaddr argument to specify everything : family/scope/flow .... -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 09:29:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0EHNTG02636 for ipng-dist; Fri, 14 Jan 2000 09:23:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0EHNKw02629 for ; Fri, 14 Jan 2000 09:23:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA04176 for ; Fri, 14 Jan 2000 09:23:20 -0800 (PST) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26910 for ; Fri, 14 Jan 2000 10:23:12 -0700 (MST) Received: (from richier@localhost) by horus.imag.fr (8.9.3/8.8.5) id SAA19755; Fri, 14 Jan 2000 18:22:21 +0100 (MET) Date: Fri, 14 Jan 2000 18:22:21 +0100 (MET) From: Jean-Luc Richier Message-Id: <200001141722.SAA19755@horus.imag.fr> In-Reply-To: Jun-ichiro itojun Hagino's message as of Jan 14, 3:02. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: iruserok() with address-family independence Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dans votre courrier du 14 Jan 3:02 vous ecrivez : > >>>- and over all the size of the returned value -with a PF_INET6 sd, the >>> returned sockaddr_in6 will overflow a sockaddr_in buffer. >>> That is why we may need a new function for forcing arg checks, with or >>> without a len argument (len of sa argument). I do not think len is needed, >>> if the new function use a generic type (sockaddr) for sa or a big type >>> (sockaddr_storage). >> How did you made sure that there's no buffer overrun? > > I may not be clear enough, > I understand there are options in avoiding buffer overrun, > I would like to know how you did it in your previous implementation, > without having len, nor without changing function signature (to > sockaddr_storage * - I don't really like passing around > sockaddr_storage *). > >itojun I avoid overflow simply by using the fd family and the way old programs are coded: The only problem is when sa is not null. It should point to a buffer as least as long as a sockaddr_in. - With an old program and INET socket no overflow will occur. - With an old program incompletly ported, the risk is: a socket converted to PF_INET6 but a pointer to sockaddr_in. In that case old code asks for an explicit setting of sa_family to AF_INET. In that case bind will fail (family mismatch) and no value will be returned, so no overflow. - With an old program correctly ported, the mandatory changes are: changing the socket family to PF_INET6, and setting new value in sa_family to a value different that the old one AF_INET. If somebody make this change, I do hope that he will also check the type and size of the variable. If somebody write `sin.sin_family = AF_INET6;' he should know that he is looking for trouble. The only thing I added to this is saying that there is a unspecfied family, AF_INET or AF_INET6. In that case I can say that such an argument should always be a sockaddr_in6 or sockaddr_storage. Richier -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 09:53:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0EHoq602698 for ipng-dist; Fri, 14 Jan 2000 09:50:52 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0EHohw02691 for ; Fri, 14 Jan 2000 09:50:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA05521; Fri, 14 Jan 2000 09:50:42 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12300; Fri, 14 Jan 2000 10:50:36 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA22370; Sat, 15 Jan 2000 02:39:17 +0900 (JST) Date: Sat, 15 Jan 2000 02:49:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: a question about TCP Implications of rfc2292bis User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've implemented Section 4.1 of rfc2292bis-01 (TCP Implications) and have a question about receiving options. The draft has the following text: For efficiency reasons it is recommended that a TCP implementation not send ancillary data items with every received segment but instead try to detect the points in the data stream when the requested IPv6 and extension header content changes and only send a single ancillary data item at the time of the change. (in the second paragraph) My question is "if an extension header disappears in receiving packets, how can an application know the fact?" For example, suppose that an application set the IPV6_RECVRTHDR option and the peer of the application starts sending packet with a routing header. Then the application will see the routing header as ancillary data when receiving the 1st packet with the routing header. If the kernel follows the above text, the application won't see any routing headers unless the content of the routing header changes. It seems OK, but what if the peer stops sending a routing header? What should the kernel do in such a case? Should it send an ancillary data object with the data length being zero? Note that such a case is not problematic for UDP or raw socket applications, since they can detect the lack of routing header by the fact that no IPV6_RTHDR ancillary data object is contained in the received cmsg list. I'm not sure if this has already discussed in the list, but I'd appreciate any clarification. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 10:52:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0EInQC02966 for ipng-dist; Fri, 14 Jan 2000 10:49:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0EInDw02955 for ; Fri, 14 Jan 2000 10:49:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA23803; Fri, 14 Jan 2000 10:49:12 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13741; Fri, 14 Jan 2000 11:49:12 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA13587; Fri, 14 Jan 2000 10:49:48 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA26005; Fri, 14 Jan 2000 10:49:48 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id KAA08376; Fri, 14 Jan 2000 10:49:47 -0800 (PST) Date: Fri, 14 Jan 2000 10:49:47 -0800 (PST) From: Tim Hartrick Message-Id: <200001141849.KAA08376@feller.mentat.com> To: Erik.Nordmark@eng.sun.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: a question about TCP Implications of rfc2292bis Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > I've implemented Section 4.1 of rfc2292bis-01 (TCP Implications) and > have a question about receiving options. > > The draft has the following text: > > For efficiency reasons it is recommended that a > TCP implementation not send ancillary data items with every received > segment but instead try to detect the points in the data stream when > the requested IPv6 and extension header content changes and only send > a single ancillary data item at the time of the change. > (in the second paragraph) > > My question is "if an extension header disappears in receiving packets, > how can an application know the fact?" For example, suppose that an > application set the IPV6_RECVRTHDR option and the peer of the > application starts sending packet with a routing header. Then the > application will see the routing header as ancillary data when > receiving the 1st packet with the routing header. If the kernel follows > the above text, the application won't see any routing headers unless > the content of the routing header changes. It seems OK, but what if > the peer stops sending a routing header? What should the kernel do in > such a case? Should it send an ancillary data object with the data > length being zero? > > Note that such a case is not problematic for UDP or raw socket > applications, since they can detect the lack of routing header by the > fact that no IPV6_RTHDR ancillary data object is contained in the > received cmsg list. > > I'm not sure if this has already discussed in the list, but I'd > appreciate any clarification. Thanks, > These types of situations are the reason I am not enamored of the text you reference from the draft. In general I would prefer that we simply say that all ancillary data will be passed out to user space and leave it to the application to deal with noting changes, omissions and additions. The complexity involved is saving all the extensions from each datagram in the kernel and then comparing them to detect changes doesn't seem worth it to me. Depending on how the ancillary data is mananged at the user/kernel boundary I don't see that there would be that much difference in the efficiency between the two approaches but simply passing the entire mess out the the application is simpler on the kernel and guarantees more uniform behavior on which the application can depend. The way the text reads today the application can't really depend on the kernel removing duplicates so the application will need to watch for them anyway. Thus, for a portable application you end up with code in user space and in the kernel doing exactly the same work. In this case I would vote for the "keep it simple stupid" approach. tim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 11:07:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0EJ5HO03018 for ipng-dist; Fri, 14 Jan 2000 11:05:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0EJ58w03011 for ; Fri, 14 Jan 2000 11:05:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA28063 for ; Fri, 14 Jan 2000 11:05:08 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA22778 for ; Fri, 14 Jan 2000 12:05:07 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Jan 2000 11:05:06 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 11:05:05 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA219B0@RED-MSG-50> From: Richard Draves To: "'IPng List'" Cc: "'6bone'" <6bone@isi.edu> Subject: MSR IPv6 Release 1.4 Date: Fri, 14 Jan 2000 11:05:00 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Microsoft Research is please to announce Release 1.4 of our MSR IPv6 stack for Windows NT 4.0 and Windows 2000. See http://www.research.microsoft.com/msripv6 for more details and download information. The release includes freely-available source code as well as precompiled binaries. Major new functionality for this release includes scoped address support in the API and the stack, Plug'n'Play and Power Management on Windows 2000, and automated 6to4 configuration. The scoped address support includes sin6_scope_id, getaddrinfo/getnameinfo, and related changes and APIs. We support site-local addressing with site prefixes (Nordmark's draft) and multi-sited nodes. For literal addresses with scope ids, we use the format "scope-id/address". On Windows 2000, USB and PCMCIA network interfaces can now be added to or removed from the system on the fly and the stack will reconfigure itself accordingly. Similarly, one can disconnect and reconnect network links or hibernate and resume a system and the MSR IPv6 stack will do the right thing. It is possible to dynamically unload and reload the stack without rebooting. The new 6to4cfg program automates 6to4 configuration. The 6to4 transition technique lets IPv6 sites communicate transparently over the IPv4 internet backbone. 6to4cfg makes it very easy to setup a 6to4 gateway router and connect sites to the 6bone via 6to4. See our 6to4 documentation: http://www.research.microsoft.com/msripv6/docs/6to4.htm. And of course, there are many miscellaneous enhancements and fixes. Thanks, Rich -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 19:41:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0F3ccJ03423 for ipng-dist; Fri, 14 Jan 2000 19:38:38 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0F3cQw03416 for ; Fri, 14 Jan 2000 19:38:27 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA09316; Fri, 14 Jan 2000 19:38:26 -0800 (PST) Date: Fri, 14 Jan 2000 19:38:26 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a question about TCP Implications of rfc2292bis To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The draft has the following text: > > For efficiency reasons it is recommended that a > TCP implementation not send ancillary data items with every received > segment but instead try to detect the points in the data stream when > the requested IPv6 and extension header content changes and only send > a single ancillary data item at the time of the change. > (in the second paragraph) > > My question is "if an extension header disappears in receiving packets, > how can an application know the fact?" Looks like the text isn't clear on that point. A possibility is to return a zero length ancillary data item of the right type. > Note that such a case is not problematic for UDP or raw socket > applications, since they can detect the lack of routing header by the > fact that no IPV6_RTHDR ancillary data object is contained in the > received cmsg list. Ack. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 14 19:43:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0F3glK03441 for ipng-dist; Fri, 14 Jan 2000 19:42:47 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0F3gZw03434 for ; Fri, 14 Jan 2000 19:42:35 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA09472; Fri, 14 Jan 2000 19:42:35 -0800 (PST) Date: Fri, 14 Jan 2000 19:42:35 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a question about TCP Implications of rfc2292bis To: Tim Hartrick Cc: Erik.Nordmark@eng.sun.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200001141849.KAA08376@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > These types of situations are the reason I am not enamored of the text > you reference from the draft. In general I would prefer that we simply > say that all ancillary data will be passed out to user space and leave > it to the application to deal with noting changes, omissions and additions. I think the text in the draft allows such behavior. But if the TCP receives N segments with extension headers it can't "compress" them together when passing them up unless it knows that the extension headers are the same. Thus if you want reasonable performance you have to compare extension headers in TCP in any case. Also, if the messages with ancillary data appear in the socket receive buffer (or stream head read queue) they can't get received with a single recvmsg since the ancillary data items might be different. > Depending on how the ancillary data is mananged at the user/kernel boundary > I don't see that there would be that much difference in the efficiency > between the two approaches but simply passing the entire mess out the the > application is simpler on the kernel and guarantees more uniform behavior on > which the application can depend. The issue is how often you have to pass out the mess. If you are forcing there to be one recvmsg call for every TCP segment performance will suffer in many cases. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 06:41:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HEcZk04576 for ipng-dist; Mon, 17 Jan 2000 06:38:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HEcQw04569 for ; Mon, 17 Jan 2000 06:38:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA23619 for ; Mon, 17 Jan 2000 06:38:27 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA28847 for ; Mon, 17 Jan 2000 06:38:26 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jan 2000 06:37:51 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 06:37:51 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101EBEF639@RED-MSG-50> From: Richard Draves To: itojun@iijlab.net Cc: "'IPng List'" Subject: RE: API suggestion Date: Mon, 17 Jan 2000 06:37:44 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reviving this old thread... I was suggesting exactly the kind of union that itojun gives below. The idea was that it would be useful to have it in standard header files instead of having different applications inventing different versions of it. The struct/union would be not used by any of the APIs. It would be used by applications instead of sockaddr_storage, when those apps only care about supporting IPv4 and IPv6. And for these apps, it would similarly be useful to have a flag for getaddrinfo to say that only IPv4 and IPv6 addresses are requested, if there are none then the call should fail. I don't like the suggestion of calling getaddrinfo twice, it's a lot more cumbersome and less efficient (probably initiating two DNS lookups on the wire). Asking for all addresses and then scanning through them to throw out non-IP addresses is also more cumbersome for the app. This suggested addition to the API is certainly not critical, but I do think it would make porting a class of apps easier. Rich > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Tuesday, December 21, 1999 5:06 PM > To: Richard Draves > Cc: 'IPng List' > Subject: Re: API suggestion > > > > >I was using sockaddr_storage variables that were holding > either AF_INET or > >AF_INET6 addresses and I wanted to fetch/store the port > field. So my choices > >were > >a) look at the family and cast to the right structure -> > unnecessary code > >b) just cast to sockaddr_in without looking at family -> unpleasant > >assumptions > > first of all you sholud not assume AF_INET or AF_INET6 > in the above.... > you should check family every time you make use of the > sockaddr_storage. > > You can always define a union like: > > union sockaddr_union { > struct sockaddr sa; > struct sockaddr_in sin; > struct sockaddr_in6 sin6; > }; > > or, if port field is known to be on the same offset on > your system: > > union sockaddr_union { > struct { > u_int8_t _len; > u_int8_t _family; > u_int16_t _port; > } _su; > #define su_port _su._port > struct sockaddr sa; > struct sockaddr_in sin; > struct sockaddr_in6 sin6; > }; > > to avoid casting. > > >I would have been happier using sockaddr_ip variables where > I could directly > >access the port field without casting. > > which API should return this structure, or which > structure will convert > normal sockaddr_{in,in6} to sockaddr_ip? > > itojun > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 06:43:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HEgJd04594 for ipng-dist; Mon, 17 Jan 2000 06:42:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HEg7w04587 for ; Mon, 17 Jan 2000 06:42:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA29214 for ; Mon, 17 Jan 2000 06:42:02 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11879 for ; Mon, 17 Jan 2000 07:42:00 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA20240; Mon, 17 Jan 2000 23:41:56 +0900 (JST) To: Richard Draves cc: "'IPng List'" In-reply-to: richdr's message of Mon, 17 Jan 2000 06:37:44 PST. <4D0A23B3F74DD111ACCD00805F31D8101EBEF639@RED-MSG-50> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion From: itojun@iijlab.net Date: Mon, 17 Jan 2000 23:41:56 +0900 Message-ID: <20238.948120116@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >And for these apps, it would similarly be useful to have a flag for >getaddrinfo to say that only IPv4 and IPv6 addresses are requested, if there >are none then the call should fail. I don't like the suggestion of calling >getaddrinfo twice, it's a lot more cumbersome and less efficient (probably >initiating two DNS lookups on the wire). Asking for all addresses and then >scanning through them to throw out non-IP addresses is also more cumbersome >for the app. I still believe this is enough... you just need to filter out things you don't want to look at. /* lookup by PF_UNSPEC */ for (res = res0; res; res = res->ai_next) { if (res->ai_family != AF_INET && res->ai_family != AF_INET6) continue; s = socket(res->ai_family, res->ai_socktype, res->ai_protocol); connect(s, res->ai_addr, res->ai_addrlen); close(s); } itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 06:48:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HEkbh04636 for ipng-dist; Mon, 17 Jan 2000 06:46:37 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HEkQw04625 for ; Mon, 17 Jan 2000 06:46:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA26735 for ; Mon, 17 Jan 2000 06:46:26 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13167 for ; Mon, 17 Jan 2000 07:46:25 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA20343 for ; Mon, 17 Jan 2000 23:46:24 +0900 (JST) To: "'IPng List'" In-reply-to: itojun's message of Mon, 17 Jan 2000 23:41:56 JST. <20238.948120116@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion From: itojun@iijlab.net Date: Mon, 17 Jan 2000 23:46:24 +0900 Message-ID: <20341.948120384@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>And for these apps, it would similarly be useful to have a flag for >>getaddrinfo to say that only IPv4 and IPv6 addresses are requested, if there >>are none then the call should fail. I don't like the suggestion of calling >>getaddrinfo twice, it's a lot more cumbersome and less efficient (probably >>initiating two DNS lookups on the wire). Asking for all addresses and then >>scanning through them to throw out non-IP addresses is also more cumbersome >>for the app. > I still believe this is enough... you just need to filter out > things you don't want to look at. I wasn't clear enough. I actually read the last line. at this moment, on most of the platforms PF_UNSPEC returns AF_INET6 and AF_INET only :-) so this is not a big issue even if we filter them out manually. what I fear is, by introducing "v4 and v6 only" option to getaddrinfo, we may decrease getaddrinfo's address family independency. by using getaddrinfo careful enough, your application can become very future proven, by hardcoding "v4 and v6 only" option argument to getaddrinfo, now you are not future-proven (you apps will not work for other AFs). itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 06:48:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HElcO04661 for ipng-dist; Mon, 17 Jan 2000 06:47:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HElJw04642 for ; Mon, 17 Jan 2000 06:47:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA07845 for ; Mon, 17 Jan 2000 06:47:20 -0800 (PST) Received: from banzai.ericsson.co.jp ([202.239.179.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13360 for ; Mon, 17 Jan 2000 07:47:11 -0700 (MST) Received: from toa002 (intmail [202.239.179.6]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with SMTP id XAA09500; Mon, 17 Jan 2000 23:46:14 +0900 (JST) Received: from toa003.nrj.ericsson.se by toa002 (SMI-8.6/LME-DOM-2.2.6) id XAA09436; Mon, 17 Jan 2000 23:46:13 +0900 Received: by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id XAA03679; Mon, 17 Jan 2000 23:46:13 +0900 Received: from banzai.ericsson.co.jp by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id XAA03665; Mon, 17 Jan 2000 23:46:12 +0900 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with ESMTP id XAA09496 for ; Mon, 17 Jan 2000 23:46:11 +0900 (JST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21953; Mon, 17 Jan 2000 06:43:55 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA07617; Mon, 17 Jan 2000 06:42:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HEcZk04576 for ipng-dist; Mon, 17 Jan 2000 06:38:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HEcQw04569 for ; Mon, 17 Jan 2000 06:38:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA23619 for ; Mon, 17 Jan 2000 06:38:27 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA28847 for ; Mon, 17 Jan 2000 06:38:26 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jan 2000 06:37:51 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 06:37:51 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101EBEF639@RED-MSG-50> From: Richard Draves To: itojun@iijlab.net Cc: "'IPng List'" Date: Mon, 17 Jan 2000 06:37:44 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) X-Loop: your@own.mail.address Subject: E-mail address information Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This mail is automatically sent to you from the NRJ E-mail system. The contents of this mail refers to the mail sent to you from Richard Draves with the subject "RE: API suggestion ". Information regarding NRJ e-mail addresses. Since installation of the new e-mail system, last summer. The old e-mail address and the new have been configured to route received mails to same mailbox. This is a temporary solution to make it possible for all NRJ employees to inform business contacts about the new @nrj.ericsson.se e-mail address. Please be aware of that receiving service of old NRJ e-mail addresses ending @ericsson.co.jp will be stopped from February 15th. Only the addresses ending @nrj.ericsson.se will be valid and accepted in our e-mail system from February 16th and old address will bounce back to the sender. >From January 17th to February 15th you will get this e-mail notification if an e-mail is sent to you, using the old address. In that case, you have to inform the sender of your new address. Your business card shall have the new address .....@nrj.ericsson.se printed. Best Regards IS/IT HelpDesk -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 07:00:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HEvvG05358 for ipng-dist; Mon, 17 Jan 2000 06:57:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HEq2w05086 for ; Mon, 17 Jan 2000 06:53:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA08210 for ; Mon, 17 Jan 2000 06:52:01 -0800 (PST) Received: from banzai.ericsson.co.jp ([202.239.179.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15167 for ; Mon, 17 Jan 2000 07:52:00 -0700 (MST) Received: from toa002 (intmail [202.239.179.6]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with SMTP id XAA09532 for ; Mon, 17 Jan 2000 23:51:58 +0900 (JST) Received: from toa003.nrj.ericsson.se by toa002 (SMI-8.6/LME-DOM-2.2.6) id XAA09658; Mon, 17 Jan 2000 23:51:58 +0900 Received: by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id XAA03763; Mon, 17 Jan 2000 23:51:57 +0900 Received: from banzai.ericsson.co.jp by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id XAA03749; Mon, 17 Jan 2000 23:51:56 +0900 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with ESMTP id XAA09528 for ; Mon, 17 Jan 2000 23:51:04 +0900 (JST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23957; Mon, 17 Jan 2000 06:49:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA07880; Mon, 17 Jan 2000 06:48:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HEkbh04636 for ipng-dist; Mon, 17 Jan 2000 06:46:37 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HEkQw04625 for ; Mon, 17 Jan 2000 06:46:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA26735 for ; Mon, 17 Jan 2000 06:46:26 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13167 for ; Mon, 17 Jan 2000 07:46:25 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA20343 for ; Mon, 17 Jan 2000 23:46:24 +0900 (JST) To: "'IPng List'" In-reply-to: itojun's message of Mon, 17 Jan 2000 23:41:56 JST. <20238.948120116@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Mon, 17 Jan 2000 23:46:24 +0900 Message-ID: <20341.948120384@coconut.itojun.org> X-Loop: your@own.mail.address Subject: E-mail address information Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This mail is automatically sent to you from the NRJ E-mail system. The contents of this mail refers to the mail sent to you from itojun@iijlab.net with the subject "Re: API suggestion ". Information regarding NRJ e-mail addresses. Since installation of the new e-mail system, last summer. The old e-mail address and the new have been configured to route received mails to same mailbox. This is a temporary solution to make it possible for all NRJ employees to inform business contacts about the new @nrj.ericsson.se e-mail address. Please be aware of that receiving service of old NRJ e-mail addresses ending @ericsson.co.jp will be stopped from February 15th. Only the addresses ending @nrj.ericsson.se will be valid and accepted in our e-mail system from February 16th and old address will bounce back to the sender. >From January 17th to February 15th you will get this e-mail notification if an e-mail is sent to you, using the old address. In that case, you have to inform the sender of your new address. Your business card shall have the new address .....@nrj.ericsson.se printed. Best Regards IS/IT HelpDesk -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 07:00:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HEvd705357 for ipng-dist; Mon, 17 Jan 2000 06:57:40 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HEp9w04991 for ; Mon, 17 Jan 2000 06:51:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA27082 for ; Mon, 17 Jan 2000 06:51:08 -0800 (PST) Received: from banzai.ericsson.co.jp ([202.239.179.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14757 for ; Mon, 17 Jan 2000 07:51:07 -0700 (MST) Received: from toa002 (intmail [202.239.179.6]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with SMTP id XAA09516; Mon, 17 Jan 2000 23:49:58 +0900 (JST) Received: from toa003.nrj.ericsson.se by toa002 (SMI-8.6/LME-DOM-2.2.6) id XAA09514; Mon, 17 Jan 2000 23:49:57 +0900 Received: by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id XAA03721; Mon, 17 Jan 2000 23:49:57 +0900 Received: from banzai.ericsson.co.jp by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id XAA03707; Mon, 17 Jan 2000 23:49:55 +0900 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with ESMTP id XAA09512 for ; Mon, 17 Jan 2000 23:49:54 +0900 (JST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22754; Mon, 17 Jan 2000 06:45:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA29275; Mon, 17 Jan 2000 06:43:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HEgJd04594 for ipng-dist; Mon, 17 Jan 2000 06:42:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HEg7w04587 for ; Mon, 17 Jan 2000 06:42:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA29214 for ; Mon, 17 Jan 2000 06:42:02 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11879 for ; Mon, 17 Jan 2000 07:42:00 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA20240; Mon, 17 Jan 2000 23:41:56 +0900 (JST) To: Richard Draves cc: "'IPng List'" In-reply-to: richdr's message of Mon, 17 Jan 2000 06:37:44 PST. <4D0A23B3F74DD111ACCD00805F31D8101EBEF639@RED-MSG-50> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Mon, 17 Jan 2000 23:41:56 +0900 Message-ID: <20238.948120116@coconut.itojun.org> X-Loop: your@own.mail.address Subject: E-mail address information Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This mail is automatically sent to you from the NRJ E-mail system. The contents of this mail refers to the mail sent to you from itojun@iijlab.net with the subject "Re: API suggestion ". Information regarding NRJ e-mail addresses. Since installation of the new e-mail system, last summer. The old e-mail address and the new have been configured to route received mails to same mailbox. This is a temporary solution to make it possible for all NRJ employees to inform business contacts about the new @nrj.ericsson.se e-mail address. Please be aware of that receiving service of old NRJ e-mail addresses ending @ericsson.co.jp will be stopped from February 15th. Only the addresses ending @nrj.ericsson.se will be valid and accepted in our e-mail system from February 16th and old address will bounce back to the sender. >From January 17th to February 15th you will get this e-mail notification if an e-mail is sent to you, using the old address. In that case, you have to inform the sender of your new address. Your business card shall have the new address .....@nrj.ericsson.se printed. Best Regards IS/IT HelpDesk -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 07:18:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HFGfQ06620 for ipng-dist; Mon, 17 Jan 2000 07:16:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HFFiw06530 for ; Mon, 17 Jan 2000 07:15:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA01499 for ; Mon, 17 Jan 2000 07:15:45 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA12996 for ; Mon, 17 Jan 2000 07:15:44 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jan 2000 07:12:15 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 07:12:15 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101EBEF665@RED-MSG-50> From: Richard Draves To: itojun@iijlab.net Cc: "'IPng List'" Subject: RE: API suggestion Date: Mon, 17 Jan 2000 07:12:12 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > what I fear is, by introducing "v4 and v6 only" option > to getaddrinfo, > we may decrease getaddrinfo's address family independency. > by using getaddrinfo careful enough, your application can become > very future proven, by hardcoding "v4 and v6 only" > option argument > to getaddrinfo, now you are not future-proven (you apps > will not work > for other AFs). Yes, in the ideal world apps would be ported to use getaddrinfo in such a way that they become completely protocol independent. In the real world for real apps, this can be difficult and the path of least resistance is to retain a dependence on IP, eg port numbers & other more subtle assumptions. Rich -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 07:26:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HFOSj06916 for ipng-dist; Mon, 17 Jan 2000 07:24:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HFOIw06909 for ; Mon, 17 Jan 2000 07:24:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29127 for ; Mon, 17 Jan 2000 07:24:18 -0800 (PST) Received: from banzai.ericsson.co.jp ([202.239.179.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27787 for ; Mon, 17 Jan 2000 08:24:13 -0700 (MST) Received: from toa002 (intmail [202.239.179.6]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with SMTP id AAA09632; Tue, 18 Jan 2000 00:22:01 +0900 (JST) Received: from toa003.nrj.ericsson.se by toa002 (SMI-8.6/LME-DOM-2.2.6) id AAA10140; Tue, 18 Jan 2000 00:22:01 +0900 Received: by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id AAA04157; Tue, 18 Jan 2000 00:22:00 +0900 Received: from banzai.ericsson.co.jp by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id AAA04143; Tue, 18 Jan 2000 00:21:59 +0900 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with ESMTP id AAA09628 for ; Tue, 18 Jan 2000 00:21:58 +0900 (JST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02929; Mon, 17 Jan 2000 07:20:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28911; Mon, 17 Jan 2000 07:19:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HFGfQ06620 for ipng-dist; Mon, 17 Jan 2000 07:16:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HFFiw06530 for ; Mon, 17 Jan 2000 07:15:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA01499 for ; Mon, 17 Jan 2000 07:15:45 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA12996 for ; Mon, 17 Jan 2000 07:15:44 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jan 2000 07:12:15 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 07:12:15 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101EBEF665@RED-MSG-50> From: Richard Draves To: itojun@iijlab.net Cc: "'IPng List'" Date: Mon, 17 Jan 2000 07:12:12 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) X-Loop: your@own.mail.address Subject: E-mail address information Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This mail is automatically sent to you from the NRJ E-mail system. The contents of this mail refers to the mail sent to you from Richard Draves with the subject "RE: API suggestion ". Information regarding NRJ e-mail addresses. Since installation of the new e-mail system, last summer. The old e-mail address and the new have been configured to route received mails to same mailbox. This is a temporary solution to make it possible for all NRJ employees to inform business contacts about the new @nrj.ericsson.se e-mail address. Please be aware of that receiving service of old NRJ e-mail addresses ending @ericsson.co.jp will be stopped from February 15th. Only the addresses ending @nrj.ericsson.se will be valid and accepted in our e-mail system from February 16th and old address will bounce back to the sender. >From January 17th to February 15th you will get this e-mail notification if an e-mail is sent to you, using the old address. In that case, you have to inform the sender of your new address. Your business card shall have the new address .....@nrj.ericsson.se printed. Best Regards IS/IT HelpDesk -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 10:28:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HIQhk07799 for ipng-dist; Mon, 17 Jan 2000 10:26:43 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HIQZw07792 for ; Mon, 17 Jan 2000 10:26:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA17996 for ; Mon, 17 Jan 2000 10:26:34 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA00656 for ; Mon, 17 Jan 2000 10:26:34 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jan 2000 10:03:05 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 10:03:03 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA219E0@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-site-prefixes Date: Mon, 17 Jan 2000 10:03:00 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reviving another old thread... > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Tuesday, December 14, 1999 9:35 AM > To: Richard Draves > Cc: Erik Nordmark; ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipngwg-site-prefixes > > > > If for some reason the site-local address is not working > but the global > > address does, won't it almost always be better to use the > global address? > > Using the global address will only be a problem if there is > a renumbering or > > some other event that effects the global prefix. So it > seems best to risk a > > small chance of a future failure to prevent otherwise > certain failure in the > > present. > > I don't know. > It has to do with the users' perception of the viability of > site renumbering. > If we can make a statement that says "if you configure things this way > then all site-internal communication will be unaffected by > site renumbering > since it will always of site-local addresses" would that be helpful in > convincing users that the risks associated with planned > renumbering (with > overlap when both prefixes are valid) are acceptable? I think with site-local addressing, site renumbering is VERY feasible. Besides not breaking connections, if all the config files, databases, etc within the site use site-local addresses, then they do not need to be updated when the site renumbers. So my view is, site-local addressing plus router renumbering gets us practical site renumbering. I still think it's good to keep the global addresses when returning site-local addresses (putting site-local before global) - that's how I implemented it. I think it makes the network more robust. For example, it ameliorates a denial-of-service attack to keep the global addresses. If somebody puts bad site prefixes on a link, you'll probably timeout trying to connect to a bad site-local address. Instead of failing, the app can succeed by trying the global address. This is sort of like the question of when/if deprecated source addresses should be used when initiating communication. Rich -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 17 10:36:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HIZIj07841 for ipng-dist; Mon, 17 Jan 2000 10:35:18 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HIZ9w07834 for ; Mon, 17 Jan 2000 10:35:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA22907; Mon, 17 Jan 2000 10:35:08 -0800 (PST) Received: from banzai.ericsson.co.jp ([202.239.179.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03830; Mon, 17 Jan 2000 10:35:03 -0800 (PST) Received: from toa002 (intmail [202.239.179.6]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with SMTP id DAA10303; Tue, 18 Jan 2000 03:35:01 +0900 (JST) Received: from toa003.nrj.ericsson.se by toa002 (SMI-8.6/LME-DOM-2.2.6) id DAA12936; Tue, 18 Jan 2000 03:35:01 +0900 Received: by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id DAA06436; Tue, 18 Jan 2000 03:35:00 +0900 Received: from banzai.ericsson.co.jp by toa003.nrj.ericsson.se (SMI-8.6/client-1.6/jp1.0) id DAA06422; Tue, 18 Jan 2000 03:34:59 +0900 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by banzai.ericsson.co.jp (8.8.7/8.8.7) with ESMTP id DAA10299 for ; Tue, 18 Jan 2000 03:34:58 +0900 (JST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22425; Mon, 17 Jan 2000 10:29:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA15635; Mon, 17 Jan 2000 10:29:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0HIQhk07799 for ipng-dist; Mon, 17 Jan 2000 10:26:43 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0HIQZw07792 for ; Mon, 17 Jan 2000 10:26:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA17996 for ; Mon, 17 Jan 2000 10:26:34 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA00656 for ; Mon, 17 Jan 2000 10:26:34 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jan 2000 10:03:05 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 10:03:03 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA219E0@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: ipng@sunroof.eng.sun.com Date: Mon, 17 Jan 2000 10:03:00 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) X-Loop: your@own.mail.address Subject: E-mail address information Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This mail is automatically sent to you from the NRJ E-mail system. The contents of this mail refers to the mail sent to you from Richard Draves with the subject "RE: draft-ietf-ipngwg-site-prefixes ". Information regarding NRJ e-mail addresses. Since installation of the new e-mail system, last summer. The old e-mail address and the new have been configured to route received mails to same mailbox. This is a temporary solution to make it possible for all NRJ employees to inform business contacts about the new @nrj.ericsson.se e-mail address. Please be aware of that receiving service of old NRJ e-mail addresses ending @ericsson.co.jp will be stopped from February 15th. Only the addresses ending @nrj.ericsson.se will be valid and accepted in our e-mail system from February 16th and old address will bounce back to the sender. >From January 17th to February 15th you will get this e-mail notification if an e-mail is sent to you, using the old address. In that case, you have to inform the sender of your new address. Your business card shall have the new address .....@nrj.ericsson.se printed. Best Regards IS/IT HelpDesk -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 18 07:58:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0IFtaD09367 for ipng-dist; Tue, 18 Jan 2000 07:55:36 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0IFtPw09360 for ; Tue, 18 Jan 2000 07:55:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA12946 for ; Tue, 18 Jan 2000 07:55:26 -0800 (PST) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07389 for ; Tue, 18 Jan 2000 07:55:24 -0800 (PST) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id AAA01821; Wed, 19 Jan 2000 00:55:23 +0900 To: ipng@sunroof.eng.sun.com CC: drepper@cygnus.com Subject: getnameinfo() with NI_NUMERIC**** X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000119005523T.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 19 Jan 2000 00:55:23 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 82 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. About getnameinfo(), RFC2553 says: | The POSIX 1003.1g specification includes no function to perform the | reverse conversion from getaddrinfo(): to look up a nodename and | service name, given the binary address and port. Therefore, we | define the following function: | int getnameinfo(const struct sockaddr *sa, socklen_t salen, | char *host, size_t hostlen, | char *serv, size_t servlen, | int flags); | The first argument, sa, points to either a sockaddr_in structure (for | IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP | address and port number. The salen argument gives the length of the | sockaddr_in or sockaddr_in6 structure. The GNU C Library, used as Linux C library, extends getnameindo() to accept a pointer to sockaddr_un structure for PF_LOCAL sockets. I think this extension is natural because getnamefinfo() is a reverse-function of protocol-independent getaddrinfo() function. But, at this time, there are some issues, and I'd like to discuss them on this list. [1] NI_NUMERICHOST If we call getnameinfo() with NI_NUMERICHOST, it should returns in the numeric form of the host's address if sockaddr_in{,6} structure is given. On the other hand, getnameinfo() of the current glibc always returns "localhost" string as a host with sockaddr_un even if getnameinfo() is called with NI_NUMERICHOST. Since "localhost" doen't seem numeric (36-based number??), applications should be cofused. Which is the most appropriate? 1) return in an error 2) return INADDR_LOOPBACK ("127.0.0.1") ? 3) return IN6ADDR_LOOPBACK ("::1") ? 4) "-1" 5) "" 6) "localhost" 7) ? [2] NI_NUMERICSERV If we call getnemeinfo() with NI_NUMERICSERV, it returns in the numeric form of the service address (port number). The getnameinfo() of the current glibc always returns pathname like "/tmp/22", "/tmp/fileasdfgh", or "/whatever/path/to/file". 1st one is from getaddrinfo("localhost", "22") with PF_LOCAL (or PF_UNSPEC) hints. Next one is from getaddrinfo("localhost", NULL) (path is automatically selected), and the last one can be obttained if you call getaddrinfo("localhost", "/whatever/path/to/file"). Which is the most appropriate? 1) return in an error 2) return number if pathname matches ^/tmp/([0-9][0-9]*)$. (I mean, if "/tmp/22", it returns "22") otherwise, return in an error. 3) current behavior (pathname) 4) ? [3] When I complained about above issues, Ulrich Drepper at gnu.org / cygnus.com said, |I've looked a bit closer at the specification and found that it only |mentions AF_INET and AF_INET6. So whoever calls getnameinfo for |AF_LOCAL must expect everything since the behaviour is unspecified. How do you think about this opinion? Thanks in advance. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 19 03:07:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0JB5Ih10497 for ipng-dist; Wed, 19 Jan 2000 03:05:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0JB59p10490; Wed, 19 Jan 2000 03:05:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA11120; Wed, 19 Jan 2000 03:05:08 -0800 (PST) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26465; Wed, 19 Jan 2000 04:05:07 -0700 (MST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA13720; Wed, 19 Jan 2000 20:05:06 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA00634; Wed, 19 Jan 2000 20:05:06 +0900 (JST) Received: from iijlab.net (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id UAA19238; Wed, 19 Jan 2000 20:05:05 +0900 (JST) Date: Wed, 19 Jan 2000 20:04:56 +0900 (JST) Message-Id: <20000119.200456.23033996.kazu@iijlab.net> To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: filtering against IPv6 in IPv4 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b17 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Some ISPs configure IP filters NOT to forward "IPv6 in IPv4" packets. This is obstacles for transition from IPv4 to IPv6. Are there any activities in IETF to recommend ISPs not to filter "IPv6 in IPv4" packets? (e.g. IAB recommendation) --Kazu -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 19 03:59:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0JBvk910557 for ipng-dist; Wed, 19 Jan 2000 03:57:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0JBvap10550 for ; Wed, 19 Jan 2000 03:57:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA13244 for ; Wed, 19 Jan 2000 03:57:36 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23492 for ; Wed, 19 Jan 2000 03:57:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26043; Wed, 19 Jan 2000 06:57:32 -0500 (EST) Message-Id: <200001191157.GAA26043@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-iana-tla-03.txt Date: Wed, 19 Jan 2000 06:57:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Initial IPv6 Sub-TLA ID Assignments Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain Filename : draft-ietf-ipngwg-iana-tla-03.txt Pages : 5 Date : 14-Jan-00 This document defines initial assignments of IPv6 Sub-TLA Aggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the IANA from the IETF IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses. The IAB and IESG have authorized the Internet Assigned Numbers Authority (IANA) as the appropriate entity to have the responsibility for the management of the IPv6 address space as defined in [ALLOC].T The proposed initial assignment described in the document is consistent with: - RFC 2373,'IP Version 6 Addressing Architecture' [ARCH] - RFC 2374 'An Aggregatable Global Unicast Address Format' [AGGR] - RFC 2450 'Proposed TLA and NLA Assignment Rules' [TLA-RULES] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-iana-tla-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000114083941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iana-tla-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000114083941.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 19 06:52:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0JEoPw10678 for ipng-dist; Wed, 19 Jan 2000 06:50:25 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0JEoGp10671; Wed, 19 Jan 2000 06:50:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA02737; Wed, 19 Jan 2000 06:50:17 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21580; Wed, 19 Jan 2000 06:50:16 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id F02D715212C; Wed, 19 Jan 2000 08:50:15 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id E6172148506; Wed, 19 Jan 2000 08:50:15 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 49A07BC4D2; Wed, 19 Jan 2000 08:50:08 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id D30A1B2A42; Wed, 19 Jan 2000 08:50:07 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000031970; Wed, 19 Jan 2000 09:50:14 -0500 (EST) From: Jim Bound Message-Id: <200001191450.JAA0000031970@quarry.zk3.dec.com> To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) filtering against IPv6 in IPv4 In-reply-to: Your message of "Wed, 19 Jan 2000 20:04:56 +0900." <20000119.200456.23033996.kazu@iijlab.net> Date: Wed, 19 Jan 2000 09:50:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we should take this to the IPv6 Forum too. Many of the ISPs are members of the Forum. I will send a note to the Forum. But I agree this would be a good statement from the IAB. /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 20 18:13:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0L2B3P12980 for ipng-dist; Thu, 20 Jan 2000 18:11:03 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0L29np12958; Thu, 20 Jan 2000 18:09:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA00819; Thu, 20 Jan 2000 18:09:49 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA21322; Thu, 20 Jan 2000 18:09:47 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id CAA81004; Fri, 21 Jan 2000 02:09:46 GMT Received: from hursley.ibm.com (lig32-225-4-86.us.lig-dial.ibm.com [32.225.4.86]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id CAA21854; Fri, 21 Jan 2000 02:09:42 GMT Message-ID: <3887015C.36EA0323@hursley.ibm.com> Date: Thu, 20 Jan 2000 06:36:44 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Kazu@hursley.ibm.com, Yamamoto@hursley.ibm.com CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: filtering against IPv6 in IPv4 References: <20000119.200456.23033996.kazu@iijlab.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is not the sort of thing that the IAB can meaningfully recommend. It needs customer demand. I suspect that this is not anti-IPv6 discrimination; more likely they are filtering all protocol types except a few. Brian "Kazu Yamamoto ($B;3K\OBI'(B)" wrote: > > Hi all, > > Some ISPs configure IP filters NOT to forward "IPv6 in IPv4" packets. > This is obstacles for transition from IPv4 to IPv6. > > Are there any activities in IETF to recommend ISPs not to filter "IPv6 > in IPv4" packets? (e.g. IAB recommendation) > > --Kazu > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 20 18:32:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0L2T6u13128 for ipng-dist; Thu, 20 Jan 2000 18:29:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0L2Swp13121 for ; Thu, 20 Jan 2000 18:28:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA03630 for ; Thu, 20 Jan 2000 18:28:57 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA06319 for ; Thu, 20 Jan 2000 19:28:57 -0700 (MST) Received: from ix.netcom.com (user-33qscqe.dialup.mindspring.com [199.174.51.78]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id VAA00101 for ; Thu, 20 Jan 2000 21:28:55 -0500 (EST) Message-ID: <3887DE0B.2C653595@ix.netcom.com> Date: Thu, 20 Jan 2000 20:18:20 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: Re: filtering against IPv6 in IPv4 References: <20000119.200456.23033996.kazu@iijlab.net> <3887015C.36EA0323@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, I believe that filtering of any kind on IP versions, IPv6, IPv4 or IPv8 is just a bunch of silly nonsense. Brian E Carpenter wrote: > This is not the sort of thing that the IAB can meaningfully recommend. > It needs customer demand. > > I suspect that this is not anti-IPv6 discrimination; more likely they > are filtering all protocol types except a few. > > Brian > > "Kazu Yamamoto ($B;3K\OBI'(B)" wrote: > > > > Hi all, > > > > Some ISPs configure IP filters NOT to forward "IPv6 in IPv4" packets. > > This is obstacles for transition from IPv4 to IPv6. > > > > Are there any activities in IETF to recommend ISPs not to filter "IPv6 > > in IPv4" packets? (e.g. IAB recommendation) > > > > --Kazu > > -------------------------------------------------------------------- > > 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 majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 20 18:57:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0L2t1m13181 for ipng-dist; Thu, 20 Jan 2000 18:55:01 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0L2sqp13174; Thu, 20 Jan 2000 18:54:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA21554; Thu, 20 Jan 2000 18:54:53 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13259; Thu, 20 Jan 2000 19:54:52 -0700 (MST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 5E7BA18C; Thu, 20 Jan 2000 21:54:51 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 3A84C208; Thu, 20 Jan 2000 21:54:51 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000028789; Thu, 20 Jan 2000 21:54:50 -0500 (EST) From: Jim Bound Message-Id: <200001210254.VAA0000028789@quarry.zk3.dec.com> To: Brian E Carpenter Cc: Kazu@hursley.ibm.com, Yamamoto@hursley.ibm.com, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: (ngtrans) Re: filtering against IPv6 in IPv4 In-reply-to: Your message of "Thu, 20 Jan 2000 06:36:44 CST." <3887015C.36EA0323@hursley.ibm.com> Date: Thu, 20 Jan 2000 21:54:50 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is not the sort of thing that the IAB can meaningfully recommend. >It needs customer demand. I can see that good point. In fact the IETF really can't do anything about it nor should they. Now that I think about it. The IPv6 Forum can help resolve this. >I suspect that this is not anti-IPv6 discrimination; more likely they >are filtering all protocol types except a few. thats what I think too. /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 21 02:39:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0LAXom13403 for ipng-dist; Fri, 21 Jan 2000 02:33:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0LAXfp13396 for ; Fri, 21 Jan 2000 02:33:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA01075 for ; Fri, 21 Jan 2000 02:33:40 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04585 for ; Fri, 21 Jan 2000 03:33:40 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA16320; Fri, 21 Jan 2000 11:33:34 +0100 (MET) Date: Fri, 21 Jan 2000 11:33:33 +0100 From: Ignatios Souvatzis To: Jeff Williams Cc: "ipng@sunroof.eng.sun.com" Subject: Re: filtering against IPv6 in IPv4 Message-ID: <20000121113333.A16209@theory.cs.uni-bonn.de> References: <20000119.200456.23033996.kazu@iijlab.net> <3887015C.36EA0323@hursley.ibm.com> <3887DE0B.2C653595@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3887DE0B.2C653595@ix.netcom.com>; from jwkckid1@ix.netcom.com on Thu, Jan 20, 2000 at 08:18:20PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Jan 20, 2000 at 08:18:20PM -0800, Jeff Williams wrote: > Brian and all, > > I believe that filtering of any kind on IP versions, IPv6, IPv4 or IPv8 > is just a bunch of silly nonsense. The probably filter any protocol carried inside IP with the exception of ICMP, TCP and maybe UDP. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 21 02:42:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0LAg0013427 for ipng-dist; Fri, 21 Jan 2000 02:42:00 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0LAfpp13420 for ; Fri, 21 Jan 2000 02:41:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA09316 for ; Fri, 21 Jan 2000 02:41:50 -0800 (PST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06487 for ; Fri, 21 Jan 2000 03:41:50 -0700 (MST) Received: from ix.netcom.com (user-33qsdo1.dialup.mindspring.com [199.174.55.1]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id FAA15867; Fri, 21 Jan 2000 05:41:47 -0500 (EST) Message-ID: <3888518F.A7D99947@ix.netcom.com> Date: Fri, 21 Jan 2000 04:31:11 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Ignatios Souvatzis CC: "ipng@sunroof.eng.sun.com" Subject: Re: filtering against IPv6 in IPv4 References: <20000119.200456.23033996.kazu@iijlab.net> <3887015C.36EA0323@hursley.ibm.com> <3887DE0B.2C653595@ix.netcom.com> <20000121113333.A16209@theory.cs.uni-bonn.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios and all, Ignatios Souvatzis wrote: > On Thu, Jan 20, 2000 at 08:18:20PM -0800, Jeff Williams wrote: > > Brian and all, > > > > I believe that filtering of any kind on IP versions, IPv6, IPv4 or IPv8 > > is just a bunch of silly nonsense. > > The probably filter any protocol carried inside IP with the exception of > ICMP, TCP and maybe UDP. Your probably right here. And again, just as silly. I would luv to hear their reasons/excuses for doing this sort of filtering. I am sure it would be amusing and disgusting at the same time.... > > > -is > > -- > * Progress (n.): The process through which Usenet has evolved from > smart people in front of dumb terminals to dumb people in front of > smart terminals. -- obs@burnout.demon.co.uk (obscurity) -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 21 02:52:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0LAnrR13449 for ipng-dist; Fri, 21 Jan 2000 02:49:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0LAnjp13442 for ; Fri, 21 Jan 2000 02:49:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA18432 for ; Fri, 21 Jan 2000 02:49:45 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08285 for ; Fri, 21 Jan 2000 03:49:43 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA16433; Fri, 21 Jan 2000 11:49:41 +0100 (MET) Date: Fri, 21 Jan 2000 11:49:41 +0100 From: Ignatios Souvatzis To: Jeff Williams Cc: Ignatios Souvatzis , "ipng@sunroof.eng.sun.com" Subject: Re: filtering against IPv6 in IPv4 Message-ID: <20000121114941.C16209@theory.cs.uni-bonn.de> References: <20000119.200456.23033996.kazu@iijlab.net> <3887015C.36EA0323@hursley.ibm.com> <3887DE0B.2C653595@ix.netcom.com> <20000121113333.A16209@theory.cs.uni-bonn.de> <3888518F.A7D99947@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3888518F.A7D99947@ix.netcom.com>; from jwkckid1@ix.netcom.com on Fri, Jan 21, 2000 at 04:31:11AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Jan 21, 2000 at 04:31:11AM -0800, Jeff Williams wrote: > Ignatios and all, > > Ignatios Souvatzis wrote: > > > On Thu, Jan 20, 2000 at 08:18:20PM -0800, Jeff Williams wrote: > > > Brian and all, > > > > > > I believe that filtering of any kind on IP versions, IPv6, IPv4 or IPv8 > > > is just a bunch of silly nonsense. > > > > The probably filter any protocol carried inside IP with the exception of > > ICMP, TCP and maybe UDP. > > Your probably right here. And again, just as silly. I would luv to hear > their reasons/excuses for doing this sort of filtering. I am sure it would > be amusing and disgusting at the same time.... They are not Internet providers. They are WWW access providers. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 21 09:55:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) id e0LHr1113728 for ipng-dist; Fri, 21 Jan 2000 09:53:01 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0LHqup13721 for ; Fri, 21 Jan 2000 09:52:57 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA10828 for ipng@sunroof.eng.sun.com; Fri, 21 Jan 2000 09:51:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta11+Sun/8.10.0.Beta11) with ESMTP id e0LDAEp13507 for ; Fri, 21 Jan 2000 05:10:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA17192 for ; Fri, 21 Jan 2000 05:10:13 -0800 (PST) Received: from speedcom3.speedlan ([204.251.128.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10186 for ; Fri, 21 Jan 2000 06:10:12 -0700 (MST) Received: by SPEEDCOM3 with Internet Mail Service (5.5.2448.0) id ; Fri, 21 Jan 2000 08:08:25 -0500 Message-ID: From: Scot McPherson To: "'ipng@sunroof.eng.sun.com'" Subject: RE: filtering against IPv6 in IPv4 Date: Fri, 21 Jan 2000 08:08:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6410.993AD500" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6410.993AD500 Content-Type: text/plain; charset="iso-8859-1" I think primarily the reason is so that VPNs and IPX/IP tunnels and such are not created. Remember that ISP over subscribe their bandwidth quite a bit. I think its wrong, but that is the practice I believe. Scot -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Ignatios Souvatzis Sent: Friday, January 21, 2000 5:50 AM To: Jeff Williams Cc: Ignatios Souvatzis; ipng@sunroof.eng.sun.com Subject: Re: filtering against IPv6 in IPv4 On Fri, Jan 21, 2000 at 04:31:11AM -0800, Jeff Williams wrote: > Ignatios and all, > > Ignatios Souvatzis wrote: > > > On Thu, Jan 20, 2000 at 08:18:20PM -0800, Jeff Williams wrote: > > > Brian and all, > > > > > > I believe that filtering of any kind on IP versions, IPv6, IPv4 or IPv8 > > > is just a bunch of silly nonsense. > > > > The probably filter any protocol carried inside IP with the exception of > > ICMP, TCP and maybe UDP. > > Your probably right here. And again, just as silly. I would luv to hear > their reasons/excuses for doing this sort of filtering. I am sure it would > be amusing and disgusting at the same time.... They are not Internet providers. They are WWW access providers. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01BF6410.993AD500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: filtering against IPv6 in IPv4

I think primarily the reason is so that VPNs and = IPX/IP tunnels and such are not created. Remember that ISP over = subscribe their bandwidth quite a bit. I think its wrong, but that is = the practice I believe.

Scot

-----Original Message-----

[mailto:owner-ipng@sunroof= .eng.sun.com]On Behalf Of Ignatios Souvatzis
Sent: Friday, January 21, 2000 5:50 AM
To: Jeff Williams
Cc: Ignatios Souvatzis; = ipng@sunroof.eng.sun.com
Subject: Re: filtering against IPv6 in IPv4


On Fri, Jan 21, 2000 at 04:31:11AM -0800, Jeff = Williams wrote:
> Ignatios and all,
>
> Ignatios Souvatzis wrote:
>
> > On Thu, Jan 20, 2000 at 08:18:20PM -0800, = Jeff Williams wrote:
> > > Brian and all,
> > >
> > >   I believe that filtering = of any kind on IP versions, IPv6, IPv4 or IPv8
> > > is just a bunch of silly = nonsense.
> >
> > The probably filter any protocol carried = inside IP with the exception of
> > ICMP, TCP and maybe UDP.
>
>   Your probably right here.  And = again, just as silly.  I would luv to hear
> their reasons/excuses for doing this sort of = filtering.  I am sure it would
> be amusing and disgusting at the same = time....

They are not Internet providers. They are WWW access = providers.

        -is

--
 * Progress (n.): The process through which = Usenet has evolved from
   smart people in front of dumb terminals = to dumb people in front of
   smart terminals.  -- = obs@burnout.demon.co.uk (obscurity)
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01BF6410.993AD500-- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 24 10:07:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0OI4dq15260 for ipng-dist; Mon, 24 Jan 2000 10:04:39 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0OI4Zj15253 for ; Mon, 24 Jan 2000 10:04:35 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA11661 for ipng@sunroof.eng.sun.com; Mon, 24 Jan 2000 10:03:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0N1TKj14522 for ; Sat, 22 Jan 2000 17:29:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA08978 for ; Sat, 22 Jan 2000 17:29:19 -0800 (PST) Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA26755 for ; Sat, 22 Jan 2000 17:29:19 -0800 (PST) Received: from delius.kettenis.local ([213.46.27.170]) by relay01.chello.nl (InterMail vK.4.02.00.00 201-232-116 license a4501b83b68dc3e36f6046e1d8586abe) with ESMTP id <20000123013658.BUSW12616.relay01@delius.kettenis.local> for ; Sun, 23 Jan 2000 02:36:58 +0100 Received: (from kettenis@localhost) by delius.kettenis.local (8.9.1/8.9.1) id CAA12075; Sun, 23 Jan 2000 02:29:17 +0100 (CET) Date: Sun, 23 Jan 2000 02:29:17 +0100 (CET) From: Mark Kettenis Message-Id: <200001230129.CAA12075@delius.kettenis.local> To: ipng@sunroof.eng.sun.com Subject: rexec_af Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The current draft of the `Advanced Sockets API for IPv6' (draft-ietf-ipngwg-2292bis-01.txt) includes a specification for rexec_af(). The draft indicates that this specification is included to ease the porting of legacy applications to IPv6. However, IMHO this is not a wise thing to do, since the rexec() interface is VERY problematic: The FreeBSD manual page says in the DESCRIPTION: This interface is obsoleted by rcmd(3). It is available from the compat- ibility library, libcompat. and further on in the BUGS section: The rexec() function sends the unencrypted password across the network. The underlying service is considered a big security hole and therefore not enabled on many sites, see rexecd(8) for explanations. Another problem is the fact that there are some differences in behaviour between the various rexec() implementations on different platforms. The draft says: This function behaves the same as the existing rexec() function, but The FreeBSD man page says about the behaviour of rexec(): If a username and password are both speci- fied, then these are used to authenticate to the foreign host; otherwise the environment and then the user's .netrc file in his home directory are searched for appropriate information. If all this fails, the user is prompted for the information. However, this is not implemented, and AFAICT none of the publically available BSD's implement this (I also verified 4.4BSD-lite, NetBSD and OpenBSD), and the rexec() implementation in the GNU C Library (Linux, the Hurd) is based on the 4.4 BSD implementation and doesn't implement it either. Mark PS I'm not on the list, so please CC me on reply. -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 25 01:33:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0P9U2315997 for ipng-dist; Tue, 25 Jan 2000 01:30:02 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0P9Toj15990 for ; Tue, 25 Jan 2000 01:29:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA10041 for ; Tue, 25 Jan 2000 01:29:49 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29398 for ; Tue, 25 Jan 2000 02:29:47 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA28463 for ; Tue, 25 Jan 2000 18:29:42 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: rcmd_af (in 2292bis) From: itojun@iijlab.net Date: Tue, 25 Jan 2000 18:29:42 +0900 Message-ID: <28461.948792582@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, sorry if it was already mentioned. 2292bis currently defines rcmd_af() behavior for cases where af == AF_INET and af == AF_INET6 case. What should I do if I don't really care about which AF I'd like to connect to? (assuming that I'll use sockaddr_storage for getsockname()) Is it okay to allow PF_UNSPEC to be passed as last arg to rcmd_af()? itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 25 09:33:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0PHTTa16210 for ipng-dist; Tue, 25 Jan 2000 09:29:29 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0PHTKj16203 for ; Tue, 25 Jan 2000 09:29:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA13519 for ; Tue, 25 Jan 2000 09:29:15 -0800 (PST) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04408 for ; Tue, 25 Jan 2000 09:28:57 -0800 (PST) Received: (from richier@localhost) by horus.imag.fr (8.9.3/8.8.5) id SAA14064; Tue, 25 Jan 2000 18:28:53 +0100 (MET) Date: Tue, 25 Jan 2000 18:28:53 +0100 (MET) From: Jean-Luc Richier Message-Id: <200001251728.SAA14064@horus.imag.fr> In-Reply-To: itojun@iijlab.net's message as of Jan 25, 18:29. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: rcmd_af (in 2292bis) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dans votre courrier du 25 Jan 18:29 vous ecrivez : > > Hello, sorry if it was already mentioned. > > 2292bis currently defines rcmd_af() behavior for cases where > af == AF_INET and af == AF_INET6 case. What should I do if > I don't really care about which AF I'd like to connect to? > (assuming that I'll use sockaddr_storage for getsockname()) > Is it okay to allow PF_UNSPEC to be passed as last arg to rcmd_af()? > >itojun I asked the list one week ago, no answer. It seems the right thing to do, as in getaddrinfo. Most on the command/library functions should work the same with INET or INET6 correspondants, and leave to choice to dns functions. -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 25 15:05:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0PN3aN16559 for ipng-dist; Tue, 25 Jan 2000 15:03:36 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0PN2Mj16537; Tue, 25 Jan 2000 15:02:23 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA13527; Tue, 25 Jan 2000 15:02:23 -0800 (PST) Date: Tue, 25 Jan 2000 15:02:23 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Use of IP6.INT To: ipng@sunroof.eng.sun.com Cc: ngtrans@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Retransmitted with correct email for the ipng list.] Please followup on the ipng list only. There has been some discussion for a while in the IAB and IESG about the use of .INT. Since this is assigned to ITU to do assignments for international (treaty?) organizations it is clear that the IETF should not use .INT for any future use. The question on the table is whether or not we should switch IP6.INT to be somewhere else. I'd like to understand the implications of doing such a switch and in particular it it can be piggy-backed on the transition from AAAA to A6, DNAME, and binary labels. There seems to be consensus that .arpa would be a good place to put things like the IPv6 reverse tree since it already contains the IPv4 reverse tree. If we go this path we should presumably invent a new meaning for .arpa. So far I've seen two good suggestions: Address Reversing Pointer Access Address and Routing Parameters Area Thus ip6.arpa (or in6-addr.arpa if you want it to be closer to in-addr.arpa) could be a reasonable domain to use. Transition: Looking at the draft-ietf-ipngwg-dns-lookups draft and the binary labels RFC (RFC 2673) there already seems to be a transition for reverse lookups, althought it isn't explicitly mentioned in dns-lookups draft. The old AAAA spec says to look in IP6.INT by making a (text) label out of each nibble and reversing the order. In the new dns-lookups spec says to look in IP6.INT for a binary label consisting of the whole IPv6 address. This can be viewed as 128 one bit labels in reverse order. Note that RFC 2673 clearly says that a binary label never matches an ASCII label "0" and "1". Thus for transition purposes it seems like the reverse lookup, just like the forward lookup trying A6 and AAAA in some order, need to try two different lookups in some order. Thus it might be realatively painless to make the new way also look in a different place; such as ip6.arpa instead of ip6.int. Comments? 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 25 15:21:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0PNIcl16593 for ipng-dist; Tue, 25 Jan 2000 15:18:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0PNIRj16586 for ; Tue, 25 Jan 2000 15:18:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA23537; Tue, 25 Jan 2000 15:18:27 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24027; Tue, 25 Jan 2000 15:18:25 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id RAA18845; Tue, 25 Jan 2000 17:18:21 -0600 (CST) Message-Id: <200001252318.RAA18845@gungnir.fnal.gov> To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: (ngtrans) Use of IP6.INT In-reply-to: Your message of Tue, 25 Jan 2000 15:02:23 PST. Date: Tue, 25 Jan 2000 17:18:21 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, It looks perfectly fine to me. Matt -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 25 15:37:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0PNZC616618 for ipng-dist; Tue, 25 Jan 2000 15:35:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0PNZ4j16611 for ; Tue, 25 Jan 2000 15:35:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA15561 for ; Tue, 25 Jan 2000 15:35:04 -0800 (PST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03250 for ; Tue, 25 Jan 2000 15:35:02 -0800 (PST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA01197 for ipng@sunroof.eng.sun.com; Tue, 25 Jan 2000 15:34:42 -0800 (PST) From: Bill Manning Message-Id: <200001252334.PAA01197@zephyr.isi.edu> Subject: use of ip6.int To: ipng@sunroof.eng.sun.com Date: Tue, 25 Jan 2000 15:34:42 -0800 (PST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Resent. % >>> RCPT To: % <<< 550 5.1.1 ... User unknown % 550 ... User unknown % % Subject: Re: (ngtrans) Use of IP6.INT % To: Erik.Nordmark@eng.sun.com % Date: Tue, 25 Jan 2000 15:32:14 -0800 (PST) % Cc: ipngwg@sunroof.eng.sun.com, iana@iana.org % In-Reply-To: from "Erik Nordmark" at Jan 25, 2000 02:56:42 PM % X-Mailer: ELM [version 2.5 PL2] % MIME-Version: 1.0 % Content-Type: text/plain; charset=us-ascii % Content-Transfer-Encoding: 7bit % % % Please followup on the ipngwg list only. % % % % There has been some discussion for a while in the IAB and IESG about the % % use of .INT. Since this is assigned to ITU to do assignments for % % international (treaty?) organizations it is clear that the IETF should % % not use .INT for any future use. % % As someone who was intimately involved with that zone, % its transfer from Dr. Mockapetris back to the IANA and % the early discussions w/ ITU on the use of this domain, % I'd like to provide one point of view that was prevelant % during the 1995-1998 period. The .INT. zone was for % Internet Infrastructure as well as a home for International % treaty organizations that did not feel comfortable elsewhere. % The ITU would -like- to run this zone, but it is not clear % to me that they have to. This feeling was apparently shared by % Dr. Postel, since the zone did not transfer. ICANN is in % control of that zone now. I would hope that they soon are able % to take the root zone and the in-addr.arpa zone. These things % are arguably within their charter. % % % The question on the table is whether or not we should switch IP6.INT % % to be somewhere else. I'd like to understand the implications of % % doing such a switch and in particular it it can be piggy-backed on % % the transition from AAAA to A6, DNAME, and binary labels. % % See the discussions in from the namedroppers list in that time % period wrt the installed resolver base and the placement % of the inverse tree pointers. It was deemed to much of a % "flag-day" to migrate the in-addr.arpa. label to the ip4.int. % portion of the tree. I beleive that there is enough installed % base of BIND code in play now that migrating to somewhere else % (and where that might be would be a long debate) would be % very disruptive. % % % There seems to be consensus that .arpa would be a good place to put % % things like the IPv6 reverse tree since it already contains % % the IPv4 reverse tree. If we go this path we should presumably invent a new % % meaning for .arpa. So far I've seen two good suggestions: % % Address Reversing Pointer Access % % Address and Routing Parameters Area % % % % Thus ip6.arpa (or in6-addr.arpa if you want it to be closer to in-addr.arpa) % % could be a reasonable domain to use. % % Ick. I'm not comfortable with either although they could work. % Would it be prudent to move all the other infrastructure zones % under the .arpa. zone as well? This would reverse a long standing % effort to "kill" off the .arpa. zone. % % % Thus it might be realatively painless to make the new way also look in % % a different place; such as ip6.arpa instead of ip6.int. % % Again, the issue is with the deployed resolver code. Its % currently tweeked for an either/or lookup. % % % Comments? % % Erik % % Tell ICANN that the ITU does not need to manage infrastructure % zones and don't push the other bits of the infrastructure tree % back into .arpa. Let ICANN do its job. % % -- % --bill % % --PAA15067.948843156/engmail3.Eng.Sun.COM-- % % -- --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 25 16:31:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0Q0SQO16702 for ipng-dist; Tue, 25 Jan 2000 16:28:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0Q0R6j16680; Tue, 25 Jan 2000 16:27:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA10415; Tue, 25 Jan 2000 16:27:05 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA08031; Tue, 25 Jan 2000 17:27:04 -0700 (MST) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA20322; Tue, 25 Jan 2000 16:26:26 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: Date: Tue, 25 Jan 2000 16:26:24 -0800 To: Anne Lord , ipv6-registry@apnic.net From: Steve Deering Subject: Re: IPv6 Policy Document Review - Call for comments Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anne et al, Here are some comments on the Provisional IPv6 Assignment and Allocation Policy Document from the co-chairs of the IPng and NGTrans Working Groups. We very much appreciate your invitation for us to review the document. Let us first note that we are delighted that the IPv6 address allocation and assignment process has begun and seems to be functioning smoothly. The establishment of such a process was a critical requirement for production deployment of IPv6, and we would like to say thanks to you and your colleagues in the RIRs for all the work you have done to get the process up and running. Let us also point out that these comments are not based on us being customers of the allocation process -- we hope that those ISPs who have been allocated IPv6 address space under the existing process will separately comment on any difficulties they may have encountered or any suggestions for improvement they might have. Rather, these comments are based on our knowledge of the design goals and technical requirements of IPv6 addressing and our concerns about some potential negative consequences of the current allocation policy. Our primary concern with the current document is that it stresses unnecessary address conservation in a number of places, and in ways that are contrary to the intent of the protocol design. Specifically: (1) The third paragraph of section 4.3.1, regarding dial-up lines, is apparently motivated by a desire to conserve address space. Unfortunately, it is ambiguous and contradictory, and depending on how it is interpreted, it could impose an unnecessary and potentially harmful constraint on IPv6 address allocation to customer sites. o It is ambiguous because it seems to equate dial-up access with single-user access, while clearly those properties are distinct: a single dial-up line may well serve multiple users. And why is the number of users relevant to IP address allocation? A single user with multiple IP devices requires more IP addresses than multiple users sharing a single device. o It is contradictory because a dial-up customer (e.g., a residential or small-office customer) who has a need to create subnets is intended to receive a /48, according to the first paragraph of that section, and a longer prefix than /48, according to the third paragraph. o It is unnecessary because the size of the public topology part of the IPv6 address was explicitly chosen to be far more than enough to hierarchically assign a unique TLA+NLA (i.e., a unique /48) to every enterprise and every household in the world, for the foreseeable future and beyond, regardless of their type of access technology. We took into consideration the possibility that all dial-up users would one day migrate to always- on access, and we sized the public topology part of the IPv6 address accordingly. Thus there is no need to share a /48 among multiple customers, whether they use dial-up access or not. o It is potentially harmful because if ISPs interpret the policy to mean they should assign only a single /64 to each dial-up customer, given that at least some and possibly many dial-up customers will have a need to create subnets, we will almost certainly see one or both of the following harmful developments: - subdivision of the customer's 64-bit interface ID field into a subnet ID field and a smaller interface ID field, which would defeat the IPv6 goals of stateless address autoconfiguration and topologically-independent, globally-unique node identification that are achieved through the use of EUI-64-based interface IDs. - deployment of IPv6 NAT devices to allow the customer to have multiple /64 subnets behind a single /64 allocation, which would defeat the IPv6 goal of having a single, global address space for all IPv6 devices. Therefore, we recommend that the third paragraph of section 4.3.1 be deleted from the document, and that it be made clear to the RIRs and ISPs that it is perfectly legitimate and desirable that every end-user customer, including dial-up and residential customers, be assigned a static, unique /48 IPv6 address prefix. (2) The last paragraph of section 3.2, regarding address assignment to point-to-point links, also seems to be motivated by the desire to conserve address space. The recommendation against ISPs assigning global, public addresses to routers' point-to-point interfaces is both unnecessary and inappropriate. o It is unnecessary because it would have negligible impact on address space consumption if each ISP were to set aside one of its allocated NLA values (i.e., one /48), from which to assign global /64 prefixes to each of its point- to-point links. The IPv6 address space is, by design, big enough to allow all Internet device interfaces, including those of ISPs' routers, to have globally-unique, publicly visible addresses. o It is inappropriate because it is beyond the RIRs' mandate to determine that ISPs' router interfaces "do not require public address space". An ISP might well choose to assign global addresses to its point-to-point interfaces, for example to permit inter-ISP traceroute to work properly, and the RIRs have no business interfering in that operational decision. Therefore, we recommend that the last paragraph of section 3.2 be deleted. (However, the parenthetical comment at the end of that paragraph, concerning the validity of all 1s and all 0s field values, should be retained somewhere, or be promoted to being a paragraph of its own). (3) Though the document does not explicitly say so, a number of readers have interpreted the description of the slow-start mechanism in section 4.2.4 to mean that an ISP will normally start with a /35 allocation and then, as its IPv6 customer base grows, be required to come back to its RIR for each additional bit of address space, i.e., first for the enclosing /34, then for the enclosing /33, and so on, up to the sub-TLA allocation of /29. While that might be a reasonable approach if we were trying to force the ISPs to achieve maximal density of address usage, such aggressive address conservation is explicitly not a goal of the IPv6 allocation policy, and if it were in fact to be implemented that way, it would impose an unnecessary and undesirable burden on ISPs. For example, while an ISP might reasonably do flat routing for its first 6500 NLAs (80% of the NLAs in the initial /35), if it expected to enjoy any significant further growth, the next sensible step would be for it to establish an internal hierarchy for its subsequent NLA assignments. However, obtaining only a single bit of additional address space would not allow for any sort of long-term hierarchy to be established. Instead, we suggest that a reasonable expectation for any ISP that appears at all likely to grow into a full sub-TLA, and eventually a TLA, should be that they go from a /35 initial allocation to a /29 full sub-TLA allocation in one step. We do not believe this would be inconsistent with the purposes of slow start for IPv6 address allocation, which we understand to be: o prevention of flagrant wastage or stockpiling of IPv6 address space, o arranging that ISPs with significantly fewer customers have longer prefixes than others, and o forcing occasions for ISPs to receive guidance from their RIRs on acceptable address usage practices. Now perhaps our suggested approach is in fact what you have in mind -- we note that the document gives considerable (and sensible) flexibility for the RIRs to exercise their best judgement regarding how much additional space to grant. If that is the intent (and we hope it is), we would prefer that that be made much more explicit in the policy document, so that any legitimate ISP with serious plans for a large IPv6 deployment can know that it will not be subjected to many small "baby-step" allocations that would complicate its planning and possibly force it to impose otherwise unnecessary renumbering events on its earlier customers. We also suggest that you consider changing the criteria so that existing top-level IPv4 ISPs who already have a large installed infrastructure and IPv4 customer base, and who presumably require less guidance on prudent address allocation practices, be able to obtain a full /29 sub-TLA to start, rather than being required to slow start from a /35. Yes, that creates the risk of such an ISP obtaining a lot of IPv6 space and then never using it, but (a) the requirement that ISPs report their NLA allocations in a public database provides a separate mechanism for monitoring usage, and that could be used as input to a reclamation decision, should that become necessary, and (b) if existing large IPv4 ISPs fail to eventually acquire a significant number of IPv6 customers, that will almost certainly indicate an overall lack of demand for IPv6 service, in which case the issue of IPv6 address stockpiling will have become moot. (4) The very few words in the document regarding allocation of TLAs ("If no further growth is possible within that sub-TLA range, the Regional IR may allocate a full TLA.", in section 4.2.5.1), when read in the context of the other, unnecessary address conservation requirements above, give the impression that the RIRs will be very reluctant to allocate actual TLAs. In particular: o Why does it say "...*may* allocate a full TLA", rather than "...*will* allocate a full TLA" (or "...*will normally* allocate a full TLA", to allow for exceptions)? o What is the criterion for determining that "no further growth is possible" with a sub-TLA? The only reference to determining when a piece of address space is "full" is in the section on sub-TLA allocation, section 4.2.5, in which there is an "at least 80% used" requirement. That is a reasonable threshold for determining when a flat address space, or a single field of a hierarchical address (such as the 13-bit NLA field in an initial /35 allocation, handled as a flat space), is near capacity, but it is unreasonable and unachievable in practice in a hierarchically-structured address space (such as the 19-bit NLA space in a full sub-TLA). We recommend that the criteria for obtaining a TLA be made more explicit, and we suggest that you consider a metric such as the "H ratio" defined in RFC 1715, which takes into account the significantly reduced density achievable in a hierarchical address space. For example, specifying an H ratio of 0.26, which that RFC describes as "optimistic" based on past experience with other, similar address spaces, would yield a recommendation that an ISP be granted a TLA at the point that it has allocated about 87,000 NLA values to end-user customers and/or downstream ISPs. Perhaps you could round that number down to 75,000 or up to 100,000 to come up with a simple rule for when an ISP could expect to acquire a TLA. Our remaining comments, both substantive and editorial, are given below, following quotations of the relevant text: > ABSTRACT > > This document describes the registry system for distributing > globally unique unicast IPv6 address space. Append to the end of that sentence: "under format prefix 001, as defined in RFC 2374", to make it clear that this policy does not necessarily apply to any future global unicast space that might be created under other format prefixes. > IPv6 address > space is distributed in a hierarchical manner (as is IPv4 > address space), managed by the IANA and further delegated by > the Regional Internet Registries (Regional IRs) as described > in RFC 1881. In the case of IPv6, the Regional IRs allocate > Top-Level Aggregation Identifiers (TLAs) to organizations, > which, as TLA Registries, in turn allocate or assign address > space to other Internet Service Providers (ISPs) and end > users. ISPs then serve as Next Level Aggregation (NLA) > Registries for their customers. The use of the terms "TLA Registry" and "NLA Registry" above, and throughout the document, are inconsistent and often counter-intuitive. For example, the above paragraph uses: - "TLA Registry" to refer to an organization to whom a TLA value has been assigned, but - "NLA Registry" to refer to an organization that assigns NLA values to others. We suggest that you consistently use: - TLA Registry only to refer to those organization that assign TLA and sub-TLA values, i.e., IANA, the RIRs, and subordinate registries (like JPNIC), if any. - NLA Registry only to refer to those organizations that assign NLA values, i.e., ISPs and Exchanges, and their subordinate ISPs, if any. - SLA Registry only to refer to those organizations that assign SLA values, i.e., end-user customers (and ISPs, for their own infrastructure). > 2 IPv6 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM > > IPv6 unicast addresses are aggregatable with contiguous > bit-wise masks used to define routable prefixes,... The reference to "contiguous bit-wise masks" is obsolete and inapplicable to IPv6. In IPv6, prefixes are always specified by length (number of bits), never by mask. >...using a method similar to that used for IPv4 addresses under CIDR. The method of aggregation is not just "similar" to that used for IPv4 under CIDR, it is the same. > Internet. The Internet Registry system exists to ensure that > IPv6 address space is managed in a globally consistent, > fair, and responsible manner that minimizes wastage, and > maximizes aggregation within the routing structure. The goal is not to *minimize* wastage, nor is it to *maximize* aggregation. Rather, the goal is to *limit* wastage, and to achieve *adequate* aggregation to meet the demands of stable, global routing. > 2.1 The Internet Registry System Hierarchy > > The hierarchical Internet Registry system exists to enable > the goals described in this document to be met. In the case > of IPv6, this hierarchy consists of the following levels, as > seen from the top down: IANA, Regional Internet Registries, > TLA, NLA Registries, and end-sites. Following our suggestion above for consistent usage of terms, remove "TLA," from the last sentence above. (IANA and the RIRs are the TLA registries.) And if you disagree with that, then at least add the word "Registries" after "TLA", for grammatical consistency. > 2.1.3 TLA Registries > > TLA Registries are established under the authority of the > appropriate Regional IR to enable "custodianship" of a TLA > or sub-TLA block of IPv6 addresses. Following our terminology suggestion, this section would refer to NLA registries having custodianship over blocks of NLAs (that fall under specific TLA or sub-TLA values assigned by the RIRs), and the subsequent (currently empty) section 2.1.4 would be deleted. We would also like to see this same language about custodianship applied to the RIRs themselves, so that it is made clear the RIRs are also custodians, not owners, of the address space (blocks of TLAs and sub-TLAs) allocated to them by IANA. > 2.1.5 End-sites > > [to be written] We assume the points to be made here are that: - end-site customers are not granted "ownership" of the address space they are assigned. - end-site customers are responsible for assigning SLA IDs (subnet numbers) and interface IDs to their own links and nodes. > 2.2.1 Uniqueness > > Each IPv6 unicast address must be globally unique. After "unicast address", add the phrase "under format prefix 001", because the statement above is not true of *all* IPv6 unicast addresses (particularly site-local, link-local, and loopback unicast addresses). > This is an absolute requirement for guaranteeing that every host >on the Internet can be uniquely identified. Change "host" to "node". (In IPv6, the term "host" does not include routers, whereas "node" includes all IPv6 devices, both hosts and routers.) > 2.2.2 Aggregation > > IPv6 addresses must be distributed in a hierarchical manner, In several places in the document, the term "distribution" is used, rather than "allocation" or "assignment". If "distribution" has a distinct meaning, or is meant to refer to the union of allocation and assignment, please include it in the glossary at the end, with an explanation of its meaning. > permitting the aggregation of routing information and > limiting the number of routing entries advertised into the > Internet. This is necessary to ensure proper operation of > Internet routing and to maximize the routing system's > ability to meet the demands of both likely and unforeseeable > future increases in both size and topological complexity. In > IPv6, aggregation of external routes is the primary goal. In that last sentence, change "the primary goal" to "a primary goal". IPv6 has other primary goals, such as increasing the available address space. > This goal is motivated by the problems which arose in IPv4 > network addressing. IPv4 address allocations have not been > sufficiently hierarchical to ensure efficient routing across > the Internet. Inefficient use of classful allocations led to > an excess of routing entries appearing in the default-free > routing table. Change "Inefficient use of classful allocations" to "Allocations of non-hierarchical (classful) prefixes". It was not the inefficiency of classful allocation that led to large routing tables, but rather their lack of sufficient hierarchy. > Furthermore, increased complexity of network > topologies led to IPv4 prefixes being announced many times > via different routes. The presence of this sentence, in the context of the paragraph in which it appears, would seem to imply that a goal is to reduce the complexity of network topologies, which is certainly not a goal of IPv6 addressing or the allocation policy. > 2.2.4 Registration > > Every assignment and allocation of IPv6 Internet address > space must be registered in a publicly accessible database. > This is necessary to ensure uniqueness and to provide > information for Internet trouble shooting at all levels. Add a hyphen to "trouble shooting". > 3.2 Initial IPv6 Addressing Hierarchy > > ... > > All router interfaces are required to have at least one > link-local unicast address or site-local address. As we explained in our earlier comments, we recommend that the paragraph containing this sentence be deleted. However, in case you decline to accept that recommendation, you should know that the above sentence is not exactly right. All router (and host) interfaces are required to have at least one link-local unicast address. *In addition*, they may be assigned site-local and/or global unicast addresses. > 4.1 IPv6 Addresses not to be considered property > > All allocations and assignments of IPv6 address space are > made on the basis that the holder of the address space is > not to be considered the "owner" of the address space, and > that all such allocations and assignments always remain > subject to the current policies and guidelines described in > this document. Change "all such allocations and assignments" to "all allocations and assignments of addresses under format prefix 001". Perhaps change "in this document" to "in the most recent version of this document". > Holders of address space may potentially be > required, at some time in the future, to return their > address space and renumber their networks in accordance with > the consensus of the Internet community in ensuring that the > goals of aggregation and efficiency continue to be met. Perhaps change "that the goals of aggregation and efficiency be met" to "that the technically and operationally necessary levels of aggregation and efficiency be met". > 4.2.1 General Criteria for Initial Sub-TLA Allocation > > Subject to sections 4.2.2, and 4.2.3, Regional IRs will only > make an initial allocation of sub-TLA address space to > organizations that meet criterion (a) AND at least one part > of criterion (b), as follows: > > a. The requesting organization's IPv6 network must > have exterior routing protocol peering > relationships with the IPv6 networks of at least > three other organizations that have a sub-TLA > allocated to them. In criterion (a), change "sub-TLA" to "sub-TLA or TLA". > > AND either > > b(i). The requesting organization must have > reassigned IPv6 addresses received from its > upstream provider or providers to 40 SLA customer > sites with routed networks connected by permanent > or semi-permanent links. What's a semi-permanent link? > > OR > > b(ii). The requesting organization must > demonstrate a clear intent to provide IPv6 service > within 12 months after receiving allocated address > space. This must be substantiated by such > documents as an engineering plan or deployment > plan. So, what sort of organization would satisfy (a) AND b(ii)? Any ISP who could satisfy (a) would presumably already be providing IPv6 service, not just planning to do it. > > 4.2.2 Criteria for sub-TLA Allocations in Transitional > "Bootstrap" Phase > > ... > > a. The requesting organization's network must have > exterior routing protocol peering relationships > with at least three other public Autonomous > Systems in the default-free zone. Make it clearer that you are talking about *IPv4* peering arrangements, in this case. > > AND > > b. The requesting organization must show that it > plans to provide production IPv6 service within 12 > months after receiving allocated address space. > This must be substantiated by such documents as an > engineering plan or a deployment plan. > > AND either > > c. The requesting organization must be an IPv4 > transit provider and must show that it already has > issued IPv4 address space to 40 customer sites > that can meet the criteria for a /48 IPv6 > assignment. In this case, the organization must > have an up-to-date routing policy registered in > one of the databases of the Internet Routing > Registry, which the Regional IR may verify by > checking the routing table information on one of > the public looking glass sites). > > OR > > d. The requesting organization must demonstrate > that it has experience with IPv6 through active > participation in the 6bone project for at least > six months, during which time it operated a > pseudo-TLA (pTLA) for at least three months. The > Regional IRs may require documentation of > acceptable 6Bone routing policies and practice > from the requesting organization. We understood that the 6bone pre-qualification process was to be independent of the other bootstrap criteria, i.e. sufficient on it own. It seems unlikely that many ISPs meeting criteria (a) would need to rely on criterion (d), rather than (c). The 6bone pre-qual was supposed to allow bootstrapping of IPv6 providers who are *not* established IPv4 providers, i.e., do not satisfy (a). > 4.2.3.2 Multihomed Sites > > [to be written] What needs to be said here is that end-user sites connected to multiple ISPs are expected to receive an NLA assignment (i.e., a /48) from each of those ISPs, and therefore, each of such an end-user's nodes may have multiple, globally-unique addresses. However, it should also be explicitly said that nothing in this policy is intended to prevent or discourage a multi-homed end-user site from negotiating with any number of ISPs for the service of advertising and routing a /48 prefix obtained from another ISP. > 4.2.4 Size for Initial Allocation: "Slow-Start" Mechanism > > Regional IRs will adopt a "slow start" mechanism when making > initial allocations of sub-TLA space to eligible > organizations. By this mechanism, the initial allocation > will allow 13 bits worth of NLA IDs to be used by the > organization unless the requesting organization submits > documentation to the Regional IR to justify an exception > based on topological grounds. This initial allocation allows > the organization to create a hierarchy within the allocation > depending on their customer type (ISP or end-site) and the > topology of their own network. For example, an organization > may receive 8,192 SLAs (a /48 each). In that last sentence, change "8,192 SLAs" to "8,192 NLAs". > 4.2.6 Registering and Verifying Usage > > Each TLA Registry is responsible for the usage of the > sub-TLA address space it receives... Change "sub-TLA" to "sub-TLA or TLA". (And we would prefer that these be called NLA registries, because they register NLAs, not TLAs, as discussed above.) > Registered end-sites must be connected and reachable. This is inconsistent with our recommendation that dial-up customers be able to obtain a /48, just like any other customers, so if our recommendation is accepted, this section will have to be reconsidered. > ...Filtering holes should be negotiated > by the Regional IR and the organization holding the > addresses in question. Explain what is meant by a "filtering hole". >...If an end-site requests an additional SLA, the TLA Registry must >send the request to the Regional IR for a second opinion. That should be "If an end-site requests an additional *NLA*, the *NLA* Registry must...". > 4.2.7 Renumbering > > It is possible that circumstances could arise whereby > sub-TLA address space becomes scarce. This could occur, for > example, due to inefficient use of assigned address space, > or to an increase in the number of organizations holding > both TLA and sub-TLA space. Change "inefficient" to "very inefficient". > Regional IRs requiring a TLA Registry to renumber will allow > that Registry at least 12 months to return the sub-TLA > space. [Note that the granted renumbering time may depend on > the prefix length returned. The draft document > http://search.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-08.txt > describes the issues involved in and methods used for > renumbering IPv6 networks.] Just for your information, the IPng working group has an effort underway to produce a new document describing the renumbering process for a site, which will be more appropriate to cite here, once it has been published. > 4.4 Reclamation Methods/Conditions > > ... > > However, if the limit is reached and routing technology at > that time is not able to support additional routing entries, > Regional IRs will review all allocations made up to that > point. In the course of this review, the Regional IRs may > seek consensus of the Internet registry and engineering > communities to set minimum acceptable usage rates or new > criteria determining eligibility to hold sub-TLA space. > Dependent upon such a consensus, the Regional IRs may revoke > the sub-TLA allocations of any Registry not complying with > those rates or criteria. We wonder if you want to say "sub-TLA or TLA" in the two places above where you refer only to "sub-TLA". > During the period that routing technology is being > investigated, the Regional IRs will continue allocating > address space even if the number of "possible" routes are > reached. Change "are reached" to "is reached". > 6.1 Allocation and Reverse Address Mapping > > ... > > For each IPv6 address block allocated by a Regional IR to a > member or customer, the Regional IR must set up NS records > in the appropriate sub-domain within the "ip6.int" domain. Just for your information, it is very likely that the "ip6.int" domain will be moved out of ".int" and into ".arpa". We expect this to be decided fairly soon, probably by Adelaide. > 7. GLOSSARY > > Allocation - The provision of IP address space to ISPs that > reassign their address space to customers. Change "ISPs" to "ISPs or exchanges". > End-user - An organization receiving reassignments of IPv6 > addresses exclusively for use in operational networks. Why "reassignments" instead of "assignments"? What is the point of using the phrase "operational networks"? Is this in contrast to experimental networks or non-operational networks? If this is actually intended to mean "not for offering public transit service to other organizations" or something like that, please say that. > Public Topology - The collection of providers and exchanges > who provide public Internet transit service. Change "who" to "that". > Site - A location, physical or virtual, with a network > backbone connecting various network equipment and systems > together. There is no limit to the physical size or scope of > a site. Insert the word "geographic" before "scope"? > Unicast - An identifier for a single interface. A packet > sent to a unicast address is delivered to the interface > identified by that address. Note that the definition of an > IPv4 host is different from an IPv6 identifier. One physical > host may have many interfaces, and therefore many IPv6 > identifiers. IPv4 and IPv6 are *not* different in the way that this confusing text seems to suggest. In both protocols, addresses identify interfaces, not hosts, and in both kinds of addresses, the lowest-order field identifies an interface within a net or subnet (even though it is less precisely called the "host field" in IPv4). Finally, in the Call for Comments for the policy document, you said: >* Definition of 'transit provider' > >A definition for the above term was not included in the current document. >Comments and suggestions for an appropriate definition are encouraged. We suggest that you *not* try to define that term, knowing what a slippery slope that is. We believe the criteria for allocation specified by the policy document (however it turns out after this review cycle) is, or ought to be, sufficient to indicate who is eligible to be assigned a sub-TLA or TLA value and who is not. Thanks again for requesting our feedback, and we apologize for the lateness and lengthiness of our response. We would be happy to set up a meeting to discuss any of these issues with you in person, if that would be helpful. Steve Deering & Bob Hinden, Co-Chairs, IPng Working Group Alain Durand, Bob Fink & Tony Hain, Co-Chairs, NGTrans Working Group -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 25 17:26:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0Q1NgM16759 for ipng-dist; Tue, 25 Jan 2000 17:23:42 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0Q1Ncj16752 for ; Tue, 25 Jan 2000 17:23:38 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id RAA13349 for ipng@sunroof.eng.sun.com; Tue, 25 Jan 2000 17:22:25 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0Q09Nj16661 for ; Tue, 25 Jan 2000 16:09:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA04299; Tue, 25 Jan 2000 16:09:23 -0800 (PST) Received: from ib.rc.vix.com (ib.rc.vix.com [204.152.187.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29167; Tue, 25 Jan 2000 17:09:22 -0700 (MST) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by ib.rc.vix.com (8.9.1/8.9.1) via ESMTP id QAA14838; Tue, 25 Jan 2000 16:09:21 -0800 (PST) env-from (Bob.Halley@iengines.com) Received: (from halley@localhost) by bb.rc.vix.com (8.9.1/8.9.1) id QAA05765; Tue, 25 Jan 2000 16:09:21 -0800 (PST) env-from (Bob.Halley@iengines.com) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: From: Bob Halley Date: 25 Jan 2000 16:09:21 -0800 In-Reply-To: Erik Nordmark's message of "Tue, 25 Jan 2000 15:02:23 -0800 (PST)" Message-ID: Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > Thus for transition purposes it seems like the reverse lookup, just like > the forward lookup trying A6 and AAAA in some order, need to try two > different lookups in some order. Yes. At least in the first beta, BIND 9 will try the bitstring label scheme first, and then it will try the nibble scheme. (A future release may allow the search order to be changed). > Thus it might be realatively painless to make the new way also look in > a different place; such as ip6.arpa instead of ip6.int. Are you suggesting looking in a third place? We can do this, but I'd rather not have to. /Bob -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 07:12:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0QF9SM17717 for ipng-dist; Wed, 26 Jan 2000 07:09:28 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0QF9Hj17710 for ; Wed, 26 Jan 2000 07:09:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA13432; Wed, 26 Jan 2000 07:09:16 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25743; Wed, 26 Jan 2000 07:09:13 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA20499; Wed, 26 Jan 2000 09:09:11 -0600 (CST) Message-Id: <200001261509.JAA20499@gungnir.fnal.gov> To: Bob Halley Cc: Erik Nordmark , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Use of IP6.INT In-reply-to: Your message of 25 Jan 2000 16:09:21 PST. Date: Wed, 26 Jan 2000 09:09:11 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Are you suggesting looking in a third place? We can do this, but I'd > rather not have to. $ORIGIN IP6.INT. \[b0] 9999999 IN DNAME \[b0].IN6-ADDR.ARPA. \[b1] 9999999 IN DNAME \[b1].IN6-ADDR.ARPA. Would that help the transition, or just slow it down? Matt -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 11:23:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0QJKl117909 for ipng-dist; Wed, 26 Jan 2000 11:20:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0QJKdj17902 for ; Wed, 26 Jan 2000 11:20:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA01549 for ; Wed, 26 Jan 2000 11:20:38 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA21854 for ; Wed, 26 Jan 2000 12:20:35 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Jan 2000 11:20:32 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jan 2000 11:19:05 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101F17C259@RED-MSG-50> From: Richard Draves To: IPng List Subject: scope-exceeded and routing headers Date: Wed, 26 Jan 2000 11:19:02 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The ICMPv6 draft defines a new destination unreachable code point for scope-exceeded errors, when forwarding a packet would cause it to leave the scope of the source address. Does this same error situation apply to routing header processing? It seems like allowing a routing header to carry a packet beyond the source's scope might be useful in some situations, and if the sender is going to the trouble of specifying a routing header then presumably they know what they are doing. On the other hand, this could easily violate assumptions that receivers make about the source address in packets they receive. (Like being able to reply without using a reversed routing header, or pseudo-security assumptions.) Thanks, Rich -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 12:04:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0QK0Zi18024 for ipng-dist; Wed, 26 Jan 2000 12:00:35 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0QK0Oj18017 for ; Wed, 26 Jan 2000 12:00:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA27269 for ; Wed, 26 Jan 2000 12:00:22 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA23365 for ; Wed, 26 Jan 2000 13:00:19 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Jan 2000 12:00:15 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jan 2000 12:00:14 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712FDE@RED-MSG-02> From: Brian Zill To: Richard Draves , IPng List Subject: RE: scope-exceeded and routing headers Date: Wed, 26 Jan 2000 12:00:14 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This was actually discussed (somewhere) not too long ago when I asked more or less the same question. The consensus seemed to be: 1) Scoped addresses in routing headers are allowed to leave their scope. Routers are not expected to run through all the hops in a router header to perform scope verification. Senders are assumed to know what they are doing. 2) Believing that scoped addresses provide some sort of quasi-security guarantees about where a given packet comes from is a bad idea. People should use real security if they want real security. And while I don't recall whether it was discussed at the same time or not, I believe that it has never been the case that receivers of packets arriving via routing headers could/should assume that they could reply without using a reversed routing header of some sort. But I could be wrong about that. --Brian > -----Original Message----- > From: Richard Draves [mailto:richdr@microsoft.com] > Sent: Wednesday, January 26, 2000 11:19 > To: IPng List > Subject: scope-exceeded and routing headers > > > The ICMPv6 draft defines a new destination unreachable code point for > scope-exceeded errors, when forwarding a packet would cause > it to leave the > scope of the source address. > > Does this same error situation apply to routing header processing? > > It seems like allowing a routing header to carry a packet beyond the > source's scope might be useful in some situations, and if the > sender is > going to the trouble of specifying a routing header then > presumably they > know what they are doing. On the other hand, this could easily violate > assumptions that receivers make about the source address in > packets they > receive. (Like being able to reply without using a reversed > routing header, > or pseudo-security assumptions.) > > Thanks, > Rich > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 12:57:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0QKsn818083 for ipng-dist; Wed, 26 Jan 2000 12:54:49 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0QKsfj18076 for ; Wed, 26 Jan 2000 12:54:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA29057 for ; Wed, 26 Jan 2000 12:54:40 -0800 (PST) From: Alex_Conta@ne.3com.com Received: from rsvp.NE.3Com.COM (rsvp.ne.3com.com [151.104.25.98]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00729 for ; Wed, 26 Jan 2000 13:54:39 -0700 (MST) Received: from usboxmta.ne.3com.com (usboxmta.NE.3Com.COM [151.104.25.34]) by rsvp.NE.3Com.COM (Pro-8.9.3/Pro-8.9.3) with SMTP id PAA16000; Wed, 26 Jan 2000 15:54:35 -0500 (EST) Received: by usboxmta.ne.3com.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 85256872.00754AF8 ; Wed, 26 Jan 2000 16:21:09 -0500 X-Lotus-FromDomain: 3COM To: Richard Draves cc: IPng List Message-ID: <85256872.0071D888.00@usboxmta.ne.3com.com> Date: Wed, 26 Jan 2000 15:58:29 -0500 Subject: Re: scope-exceeded and routing headers Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My take on this, without consulting with Steve is: the /destination uncreachable/scope-exceded/ error condiftion si detected on the packet forwarding path, i.e. main header source/destination address processing. This implies that there is no difference between a packet that has a routing header and one that does not. Regards, Alex Richard Draves on 01/26/2000 02:19:02 PM Sent by: Richard Draves To: IPng List cc: (Alex Conta/US/3Com) Subject: scope-exceeded and routing headers The ICMPv6 draft defines a new destination unreachable code point for scope-exceeded errors, when forwarding a packet would cause it to leave the scope of the source address. Does this same error situation apply to routing header processing? It seems like allowing a routing header to carry a packet beyond the source's scope might be useful in some situations, and if the sender is going to the trouble of specifying a routing header then presumably they know what they are doing. On the other hand, this could easily violate assumptions that receivers make about the source address in packets they receive. (Like being able to reply without using a reversed routing header, or pseudo-security assumptions.) Thanks, Rich -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 14:23:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0QMKWw18241 for ipng-dist; Wed, 26 Jan 2000 14:20:32 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0QMKLj18234 for ; Wed, 26 Jan 2000 14:20:21 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA01244; Wed, 26 Jan 2000 14:20:12 -0800 (PST) Date: Wed, 26 Jan 2000 14:19:39 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Use of IP6.INT To: Bob Halley Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Are you suggesting looking in a third place? We can do this, but I'd > rather not have to. No. I'm assuming that, if we decide to do this change, we can do it quickly enough that there will be no (or close to zero) bit string labels in the ip6.int tree so we can just swap that part to instead look in ip6.arpa. Thus BIND would (in some order) look for reversed nibbles in ip6.int and bit string labels in ip6.arpa. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 17:32:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R1U1s18386 for ipng-dist; Wed, 26 Jan 2000 17:30:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R1Toj18379 for ; Wed, 26 Jan 2000 17:29:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA26952 for ; Wed, 26 Jan 2000 17:29:50 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA17356 for ; Wed, 26 Jan 2000 18:29:48 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA25112; Thu, 27 Jan 2000 10:29:43 +0900 (JST) To: Brian Zill to: Richard Draves cc: IPng List In-reply-to: bzill's message of Wed, 26 Jan 2000 12:00:14 PST. <3D2036E25376D31197A100805FEAD892712FDE@RED-MSG-02> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: scope-exceeded and routing headers From: itojun@iijlab.net Date: Thu, 27 Jan 2000 10:29:43 +0900 Message-ID: <25110.948936583@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This was actually discussed (somewhere) not too long ago when I asked more >or less the same question. The consensus seemed to be: >1) Scoped addresses in routing headers are allowed to leave their scope. >Routers are not expected to run through all the hops in a router header to >perform scope verification. Senders are assumed to know what they are >doing. >2) Believing that scoped addresses provide some sort of quasi-security >guarantees about where a given packet comes from is a bad idea. People >should use real security if they want real security. That depends on what is meant by "leave the scope". Could you give me more concrete example? My take was that, you can't leave scope boundary because routes cannot forward them. This is because there's no indication of "zones" (or scope-id) in the routing header. When router interprets routing header, it needs to find the outgoing interface (or zone), and the only hint it has is the incoming interface. For example, to forward this packet: src = link-local dst = link-local (= router) rthdr = link-local (to where fourter forwards it) router needs to guess which interface it should be forwarded. possible solutions I can think of is - forbidden - forward to the node on the incoming interface, hence you are not leaving the scope This goes the same with: src = link-local dst = link-local (= router) rthdr = site-local (to where fourter forwards it) since if the router is on site boundary, it can't be forwarded. We may be able to set an exception when we set global address in the routing header. src = link-local dst = link-local (= router) rthdr = global (where router forwards it) In this case, it can reach the final destination (because there's only single global address space), however, reverse path is not available. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 18:44:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R2flB18487 for ipng-dist; Wed, 26 Jan 2000 18:41:47 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R2fcj18480 for ; Wed, 26 Jan 2000 18:41:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA16132 for ; Wed, 26 Jan 2000 18:41:37 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12877 for ; Wed, 26 Jan 2000 19:41:35 -0700 (MST) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA12045; Thu, 27 Jan 2000 11:28:05 +0900 (JST) Date: Thu, 27 Jan 2000 11:38:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: kre@munnari.OZ.AU Cc: ipng@sunroof.eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 In-Reply-To: In your message of "Sat, 08 Jan 2000 20:23:03 +1100" <5352.947323383@munnari.OZ.AU> References: <5352.947323383@munnari.OZ.AU> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, I missed your reply. >>>>> On Sat, 08 Jan 2000 20:23:03 +1100, >>>>> Robert Elz said: > Date: Fri, 07 Jan 2000 00:50:50 +0900 > From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > > Message-ID: > | > I am not sure how useful this really is given the fact that there is no > | > requirement that all extension headers be structured in this way. It is > | > fine for hop-by-hop options, destination options and routing headers but > | > it is not generally useful. > | > | That's right, but (currently) the only exception is the fragment > | header and I think if we defined a new (variable length) extension > | header it would probably be formatted as above. > Only if the length fits in a byte, which is by no means certain. Of course yes in theory, but I'd think that an IPv6 extension header rarely needs a length field in more than one byte. > | Anyway, we are using the structure in chasing a header chain like > | this: > As I recall, the intent was always very explicitly, that as soon as an > unknown header is detected, packet parsing must cease. You are explicitly > not supposed to be able to step over an unknown header. Sorry, the sample code was too simple. In our actual code we of course reject an unknown header. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 19:16:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R3Bah18518 for ipng-dist; Wed, 26 Jan 2000 19:11:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R3B9j18511 for ; Wed, 26 Jan 2000 19:11:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA05517 for ; Wed, 26 Jan 2000 19:11:09 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA03497 for ; Wed, 26 Jan 2000 19:11:08 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 69F4F578E2; Wed, 26 Jan 2000 21:11:08 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 6783F54603 for ; Wed, 26 Jan 2000 21:11:08 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 2CD264FB02; Wed, 26 Jan 2000 21:11:01 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id C91274C901; Wed, 26 Jan 2000 21:11:00 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000003502; Wed, 26 Jan 2000 22:11:07 -0500 (EST) From: Jim Bound Message-Id: <200001270311.WAA0000003502@quarry.zk3.dec.com> To: Richard Draves Cc: IPng List Subject: Re: scope-exceeded and routing headers In-reply-to: Your message of "Wed, 26 Jan 2000 11:19:02 PST." <4D0A23B3F74DD111ACCD00805F31D8101F17C259@RED-MSG-50> Date: Wed, 26 Jan 2000 22:11:07 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The ICMPv6 draft defines a new destination unreachable code point for >scope-exceeded errors, when forwarding a packet would cause it to leave the >scope of the source address. This is a prudent dst unreach principle architecturally with the IPv6 addressing model. >Does this same error situation apply to routing header processing? Absolutely. >It seems like allowing a routing header to carry a packet beyond the >source's scope might be useful in some situations, and if the sender is >going to the trouble of specifying a routing header then presumably they >know what they are doing. On the other hand, this could easily violate >assumptions that receivers make about the source address in packets they >receive. (Like being able to reply without using a reversed routing header, >or pseudo-security assumptions.) If a packet is to exceed the source's scope thru forward operation that is simple illegal to me in IPv6. Its black and white and not gray. /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 19:16:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R3FKR18527 for ipng-dist; Wed, 26 Jan 2000 19:15:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R3FAj18520 for ; Wed, 26 Jan 2000 19:15:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA06416 for ; Wed, 26 Jan 2000 19:15:10 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA04502 for ; Wed, 26 Jan 2000 19:15:09 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 85CFC104BAF; Wed, 26 Jan 2000 21:15:08 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 7E30FFB101; Wed, 26 Jan 2000 21:15:08 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 3E6FBBC4D1; Wed, 26 Jan 2000 21:15:01 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id C96D0B2A43; Wed, 26 Jan 2000 21:15:00 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000000672; Wed, 26 Jan 2000 22:15:07 -0500 (EST) From: Jim Bound Message-Id: <200001270315.WAA0000000672@quarry.zk3.dec.com> To: Alex_Conta@ne.3com.com Cc: Richard Draves , IPng List Subject: Re: scope-exceeded and routing headers In-reply-to: Your message of "Wed, 26 Jan 2000 15:58:29 EST." <85256872.0071D888.00@usboxmta.ne.3com.com> Date: Wed, 26 Jan 2000 22:15:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >the /destination uncreachable/scope-exceded/ error condiftion si detected >on the packet forwarding path, i.e. main header source/destination address >processing. This implies that there is no difference between a packet >that has a routing header and one that does not. Exactly. This is why it is black and white decision. Not gray. The condition test to forward has nothing to do with why or how the packet got there, but that the packet if forwarded will exceed its scope. I can't see reading it any other way as an implementor. /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 19:33:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R3UlM18630 for ipng-dist; Wed, 26 Jan 2000 19:30:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R3Uaj18623 for ; Wed, 26 Jan 2000 19:30:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA17849 for ; Wed, 26 Jan 2000 19:30:34 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA26681 for ; Wed, 26 Jan 2000 20:30:19 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Jan 2000 19:02:36 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jan 2000 19:02:36 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712FE0@RED-MSG-02> From: Brian Zill To: "'itojun@iijlab.net'" , Richard Draves Cc: IPng List Subject: RE: scope-exceeded and routing headers Date: Wed, 26 Jan 2000 19:02:32 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry I wasn't clear. Allow me to clarify: In regular packet forwarding cases (i.e. non routing header), a scoped address in either the source or destination fields of the IP header cannot "leave the scope" (maybe I should have said "zone" here) since routers will refuse to forward such a packet outside of its zone. However, a scoped address contained in a routing header (i.e. it's not yet cycled up to the destination field) can pass through a non-destination router unnoticed since such routers do not look at routing headers (they only look at hop-by-hop options, of which the router header is not one). This is what I meant when I said addresses can "leave their scope". (Note: some of the IP mobility headers also contain embedded IPv6 addresses, similar issues apply there) At an intermediate destination router, the next address in the routing header is cycled up to the destination field in the IP header and is used to send the packet onward. If this address is a scoped address, there is no way of knowing what zone it originated in. The "best guess" in this case is to use the zone which applies to the receiving interface (or possibly the the zone which applies to the interface which has the intermediate destination address -- these could be different in "weak host" model nodes, which is one of many reasons I prefer the "strong host" model). The assumption is that senders have enough topology information about the network to know what zone the intermediate destination address is in, and only use scoped addresses that apply to that zone. At an intermediate destination router, regardless of whether or not the next intermediate destination is a scoped address, the router shouldn't run through the other addresses in the routing header to see whether or not they are scoped addresses. One could imagine a router attempting this in a misguided attempt at preventing scoped addresses from leaving their zone. However, since such addresses can "leave their zone" by passing through routers that aren't intermediate destinations, there is no point to this idea. Anyhow, the last three paragraphs explain what I meant by the 1st, 3rd, and 2nd sentences of point (1) in my original mail :-) For your first example, the thing to do is to forward the packet to the link-local destination ("rthdr") on the interface with address "dst". For your second example, you'd forward the packet to the site-local address ("rthdr") in the site to which the interface that has the link-local address "dst" belongs (if there is no route to that site-local prefix out of an interface in that site, you'd drop the packet). For your third example, you'd forward the packet to the global address ("rthdr") -- but only if the route you'd use to reach that global address goes out the interface with the link-local address "dst", otherwise you'd drop the packet. Yes, I know. Steve D. and I are supposed to be writing an ID that clarifies all this. --Brian > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, January 26, 2000 17:30 > To: Brian Zill; Richard Draves > Cc: IPng List > Subject: Re: scope-exceeded and routing headers > > > > >This was actually discussed (somewhere) not too long ago > when I asked more > >or less the same question. The consensus seemed to be: > >1) Scoped addresses in routing headers are allowed to leave > their scope. > >Routers are not expected to run through all the hops in a > router header to > >perform scope verification. Senders are assumed to know > what they are > >doing. > >2) Believing that scoped addresses provide some sort of > quasi-security > >guarantees about where a given packet comes from is a bad > idea. People > >should use real security if they want real security. > > That depends on what is meant by "leave the scope". > Could you give > me more concrete example? > > My take was that, you can't leave scope boundary > because routes cannot > forward them. This is because there's no indication of "zones" > (or scope-id) in the routing header. When router > interprets routing > header, it needs to find the outgoing interface (or > zone), and the > only hint it has is the incoming interface. > > For example, to forward this packet: > src = link-local > dst = link-local (= router) > rthdr = link-local (to where fourter forwards it) > router needs to guess which interface it should be forwarded. > possible solutions I can think of is > - forbidden > - forward to the node on the incoming interface, hence > you are not > leaving the scope > > This goes the same with: > src = link-local > dst = link-local (= router) > rthdr = site-local (to where fourter forwards it) > since if the router is on site boundary, it can't be forwarded. > > We may be able to set an exception when we set global address > in the routing header. > src = link-local > dst = link-local (= router) > rthdr = global (where router forwards it) > In this case, it can reach the final destination > (because there's only > single global address space), however, reverse path is > not available. > > itojun > -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 20:17:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R4EgZ18667 for ipng-dist; Wed, 26 Jan 2000 20:14:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R4EXj18660 for ; Wed, 26 Jan 2000 20:14:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA10144 for ; Wed, 26 Jan 2000 20:14:33 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19888 for ; Wed, 26 Jan 2000 20:14:32 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 370635789E; Wed, 26 Jan 2000 22:14:32 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 2FB3454601; Wed, 26 Jan 2000 22:14:32 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id E72CCBC4D3; Wed, 26 Jan 2000 22:14:24 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 6B062B2A42; Wed, 26 Jan 2000 22:14:24 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000013906; Wed, 26 Jan 2000 23:14:31 -0500 (EST) From: Jim Bound Message-Id: <200001270414.XAA0000013906@quarry.zk3.dec.com> To: Brian Zill Cc: "'itojun@iijlab.net'" , Richard Draves , IPng List Subject: Re: scope-exceeded and routing headers In-reply-to: Your message of "Wed, 26 Jan 2000 19:02:32 PST." <3D2036E25376D31197A100805FEAD892712FE0@RED-MSG-02> Date: Wed, 26 Jan 2000 23:14:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >At an intermediate destination router, the next address in the routing >header is cycled up to the destination field in the IP header and is used to >send the packet onward. If this address is a scoped address, there is no >way of knowing what zone it originated in. The "best guess" in this case is >to use the zone which applies to the receiving interface (or possibly the >the zone which applies to the interface which has the intermediate >destination address -- these could be different in "weak host" model nodes, >which is one of many reasons I prefer the "strong host" model). The >assumption is that senders have enough topology information about the >network to know what zone the intermediate destination address is in, and >only use scoped addresses that apply to that zone. I have no issue if the sender has enough topology information by specifying a source route that the scope of a particular address (as scope is discussed in RFC 2373) when it is cycled to the destination address is in fact routable to a like scope interface by the router or switched as some say today .--)... This is one smart sender. But if the packet src is FEC0/8 and the DST cycles to >site (i.e. 3ffe) then I do not think the packet should be forwarded at all. The concept of scope_id (zone) for a scoped address is not intellgible to our IPv6 routing protocols, so I don't see how that can even be used? >At an intermediate destination router, regardless of whether or not the next >intermediate destination is a scoped address, the router shouldn't run >through the other addresses in the routing header to see whether or not they >are scoped addresses. One could imagine a router attempting this in a >misguided attempt at preventing scoped addresses from leaving their zone. >However, since such addresses can "leave their zone" by passing through >routers that aren't intermediate destinations, there is no point to this >idea. All addresses are scoped: Global, Site, Link-Local, et al? I would think they can leave their zone by the fiat above or on purpose by a smart sender but at the point they enter the forwarding code the ICMPv6 scope exceeded test applies. Be good to use examples with real addresses for me anyway else I can't get into the examples. thanks /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 22:10:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R66GJ18786 for ipng-dist; Wed, 26 Jan 2000 22:06:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R661j18779 for ; Wed, 26 Jan 2000 22:06:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA02252 for ; Wed, 26 Jan 2000 22:05:58 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA05130 for ; Wed, 26 Jan 2000 23:05:52 -0700 (MST) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA13020; Thu, 27 Jan 2000 14:54:52 +0900 (JST) Date: Thu, 27 Jan 2000 15:05:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bzill@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: scope-exceeded and routing headers In-Reply-To: In your message of "Wed, 26 Jan 2000 19:02:32 -0800" <3D2036E25376D31197A100805FEAD892712FE0@RED-MSG-02> References: <3D2036E25376D31197A100805FEAD892712FE0@RED-MSG-02> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 46 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 26 Jan 2000 19:02:32 -0800, >>>>> Brian Zill said: > For your third example, > you'd forward the packet to the global address ("rthdr") -- but only if the > route you'd use to reach that global address goes out the interface with the > link-local address "dst", otherwise you'd drop the packet. >> We may be able to set an exception when we set global address >> in the routing header. >> src = link-local >> dst = link-local (= router) >> rthdr = global (where router forwards it) >> In this case, it can reach the final destination >> (because there's only >> single global address space), however, reverse path is >> not available. Then how do you think about the following case? src = global1 dst = link-local (router) rthdr = global2 (where router forwards it) In this case, even if the outgoing interface to global2 for the router is in the same link to which "dst" belongs, the forwarded packet could be leave the link scope of "dst" (see the following figure). src router |g1 |link-local | | |-+---+---+---| | another_router | +---------.......---g2 (final destination) I'd personally think we should not put addresses of different type of scopes into the source filed, destination filed, and all intermediate destination field of a routing header. i.e. All the addresses should belong to a same kind of scope. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 22:15:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R6E5K18817 for ipng-dist; Wed, 26 Jan 2000 22:14:05 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R6Dqj18810 for ; Wed, 26 Jan 2000 22:13:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA02876 for ; Wed, 26 Jan 2000 22:13:51 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA07124 for ; Wed, 26 Jan 2000 23:13:50 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA29432; Thu, 27 Jan 2000 15:13:38 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: bzill@microsoft.com, ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Thu, 27 Jan 2000 15:05:40 JST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: scope-exceeded and routing headers From: itojun@iijlab.net Date: Thu, 27 Jan 2000 15:13:37 +0900 Message-ID: <29430.948953617@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'd personally think we should not put addresses of different type of >scopes into the source filed, destination filed, and all intermediate >destination field of a routing header. i.e. All the addresses should >belong to a same kind of scope. I agree with jinmei on this point. I wasn't clear enough. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 23:05:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R71b218841 for ipng-dist; Wed, 26 Jan 2000 23:01:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R71Qj18834 for ; Wed, 26 Jan 2000 23:01:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA04001 for ; Wed, 26 Jan 2000 23:01:20 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA17166 for ; Thu, 27 Jan 2000 00:01:20 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Jan 2000 23:01:19 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jan 2000 23:01:19 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712FE1@RED-MSG-02> From: Brian Zill To: "'JINMEI Tatuya / ????'" Cc: ipng@sunroof.eng.sun.com, "'itojun@iijlab.net'" Subject: RE: scope-exceeded and routing headers Date: Wed, 26 Jan 2000 23:01:09 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First let me say that what I said in my previous message was my interpretation of the outcome of an earlier discussion of this issue, not what my personal inclination was. My original thought was that we'd need to disallow scoped addresses in routing headers (i.e. global only). The opposing argument was that we shouldn't prevent people from doing something unnecessarily, and if senders want to play with fire this way, let them. I ended up agreeing with that argument. > Then how do you think about the following case? > > src = global1 > dst = link-local (router) > rthdr = global2 (where router forwards it) > > In this case, even if the outgoing interface to > global2 for the router is in the same link to which > "dst" belongs, the forwarded packet could be leave > the link scope of "dst" (see the following figure). > > src router > |g1 |link-local > | | > |-+---+---+---| > | > another_router > | > +---------.......---g2 (final destination) I don't see anything wrong with this. If the source (g1) wants to send to (g2) and insist that the packet passes through "router" on the way, this seems like a perfectly good way to do it. Why is this a problem? > I'd personally think we should not put addresses > of different type of scopes into the source filed, > destination filed, and all intermediate destination > field of a routing header. i.e. All the addresses should > belong to a same kind of scope. I see in another message that itojun agrees with you on this. I don't think I do. Unless there is a very good reason for such a draconian policy, I don't think we should set one. We're way beyond discussing just routing headers here, but are getting into the realm of scoped address routing and source and destination address selection. Both the scoped-routing draft and the default-addr-select draft allow for, and explain how to work with, situations where the source and destination addresses are of different scopes. --Brian -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 26 23:50:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R7lmB18878 for ipng-dist; Wed, 26 Jan 2000 23:47:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R7ldj18871 for ; Wed, 26 Jan 2000 23:47:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA06740 for ; Wed, 26 Jan 2000 23:47:39 -0800 (PST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA27662 for ; Thu, 27 Jan 2000 00:47:39 -0700 (MST) Received: from ix.netcom.com (user-33qsdo1.dialup.mindspring.com [199.174.55.1]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id CAA18953; Thu, 27 Jan 2000 02:46:41 -0500 (EST) Message-ID: <38901178.B7EA5808@ix.netcom.com> Date: Thu, 27 Jan 2000 01:35:53 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian Zill CC: "'JINMEI Tatuya / ????'" , ipng@sunroof.eng.sun.com, "'itojun@iijlab.net'" Subject: Re: scope-exceeded and routing headers References: <3D2036E25376D31197A100805FEAD892712FE1@RED-MSG-02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and all, I agree with Brian that scoped addressesin routing headers is a mistake for obvious reasons. Brian Zill wrote: > First let me say that what I said in my previous message was my > interpretation of the outcome of an earlier discussion of this issue, not > what my personal inclination was. My original thought was that we'd need to > disallow scoped addresses in routing headers (i.e. global only). The > opposing argument was that we shouldn't prevent people from doing something > unnecessarily, and if senders want to play with fire this way, let them. I > ended up agreeing with that argument. > > > Then how do you think about the following case? > > > > src = global1 > > dst = link-local (router) > > rthdr = global2 (where router forwards it) > > > > In this case, even if the outgoing interface to > > global2 for the router is in the same link to which > > "dst" belongs, the forwarded packet could be leave > > the link scope of "dst" (see the following figure). > > > > src router > > |g1 |link-local > > | | > > |-+---+---+---| > > | > > another_router > > | > > +---------.......---g2 (final destination) > > I don't see anything wrong with this. If the source (g1) wants to send to > (g2) and insist that the packet passes through "router" on the way, this > seems like a perfectly good way to do it. Why is this a problem? > > > I'd personally think we should not put addresses > > of different type of scopes into the source filed, > > destination filed, and all intermediate destination > > field of a routing header. i.e. All the addresses should > > belong to a same kind of scope. > > I see in another message that itojun agrees with you on this. I don't think > I do. Unless there is a very good reason for such a draconian policy, I > don't think we should set one. We're way beyond discussing just routing > headers here, but are getting into the realm of scoped address routing and > source and destination address selection. Both the scoped-routing draft and > the default-addr-select draft allow for, and explain how to work with, > situations where the source and destination addresses are of different > scopes. > > --Brian > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 00:34:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R8S4I18899 for ipng-dist; Thu, 27 Jan 2000 00:28:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R8Rrj18892 for ; Thu, 27 Jan 2000 00:27:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA10063 for ; Thu, 27 Jan 2000 00:27:53 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA27091 for ; Thu, 27 Jan 2000 00:27:53 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Jan 2000 00:25:38 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jan 2000 00:25:38 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712FE2@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: "'itojun@iijlab.net'" , Richard Draves , IPng List Subject: RE: scope-exceeded and routing headers Date: Thu, 27 Jan 2000 00:25:31 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi'ya Jim, > I have no issue if the sender has enough topology > information by specifying a source route that the > scope of a particular address (as scope is discussed > in RFC 2373) when it is cycled to the destination > address is in fact routable to a like scope interface > by the router or switched as some say today .--)... > This is one smart sender. Yes, it really takes a knowledgeable sender for this to work. Thus I expect we won't see much use of scoped addresses in routing headers in practice. > But if the packet src is FEC0/8 and the DST cycles > to >site (i.e. 3ffe) then I do not think the packet > should be forwarded at all. Uh, why not? We allow mixed scope source/destination addresses in other cases today. I'd think it'd be ok to forward the packet in this example, but only on the link the packet came in on. Looks like I may have opened another can of worms here :-) Let me try a different approach. In the normal (no routing header) case, you can only forward packets to places inside their zone. This requires checking both the source and destination fields in the IP header. Packets with a link-level source and/or destination address can only be forwarded out via the same interface they came in on. Packets with a site-local source and/or destination address can only be forwarded out via an interface that shares a scope_id value with the interface that the packet came in on (i.e. it must go out the same interface it came in on, or another interface within the same "site" as the one it came in on). Any packets that don't pass these checks get dropped and an ICMPv6 scope-exceeded message gets sent back to the source. Haberman's scoped-routing draft covers most of this. The problem with the routing header is that it allows scoped addresses to cross zone boundaries without being subject to these checks because the checks are only performed against the source and destination fields of the IP header proper. Telling routers that they must make these checks against every address present in a routing header when forwarding would add tremendous overhead (it'd have to be done at each hop, not just at every intermediate destination) and also run against the base IPv6 Specification which says that only hop-by-hop options are done at each hop. So that's out. The only options are to disallow scoped addresses in routing headers completely (which was actually my original idea until I got talked out of it), or allow them and come up with some way of assigning them a zone when they cycle up out of a routing header. So what zone should they be assigned? There is no way to tell with certainty what zone the packet originated in, so that's out. The current router that the packet is at might not have an interface in the original zone in any case. So the proposed rule is to use the zone of the interface that the packet came in on ("weak host" model nodes might want to use the zone of the interface with the IP address corresponding to the destination field in the packet). In other words, if the packet came in on interface "5", and the next address in the routing header is link-local, treat that link-local address as having a scope_id of "5". If the next address in the routing header is site-local, then treat it as having a scope_id equal to whatever interface 5's site identifier is. Then route as normal and the normal routing rules for scoped addresses will prevent the packet from leaving its newly assigned zone. The end result of this is that putting scoped addresses in routing headers is only useful if the sender knows the "zone" of the intermediate destination just prior to the scoped address. Because that is the "zone" the scoped address will be interpreted in. So yeah, this is one smart sender. One contrived example: say I have a dumb device on my local wire that only has a link-local address, and I normally talk to it via my workstation on the same local wire. I could still send to this dumb device when I'm far away by using a routing header with my workstation's global address as the intermediate destination and the dumb device's link-local address as the final destination. It couldn't respond, but oh well. Is this capability really useful? I dunno. Is there any reason to forbid it? I can't think of one. So I think it would be better to take the more permissive approach. The behavior outlined in this message is how the latest release of our stack (msripv6 1.4) behaves. > Be good to use examples with real addresses for me > anyway else I can't get into the examples. Okay, I'll do that in the draft. Thanks, --Brian -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 00:48:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R8jl418934 for ipng-dist; Thu, 27 Jan 2000 00:45:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R8jaj18927 for ; Thu, 27 Jan 2000 00:45:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA01670 for ; Thu, 27 Jan 2000 00:45:37 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA12298 for ; Thu, 27 Jan 2000 01:45:24 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id RAA01945 for ; Thu, 27 Jan 2000 17:45:23 +0900 (JST) To: IPng List X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: freeaddrinfo(NUL) From: itojun@iijlab.net Date: Thu, 27 Jan 2000 17:45:23 +0900 Message-ID: <1943.948962723@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A question was raised about freeaddrinfo(NULL). Is it permitted, or should we just SEGV? NRL freeaddrinfo (in linux glibc, and BIND8): permits it RFC2553: silent about it X/Open: www.xopen.org is unreachable from me KAME freeaddrinfo (in freebsd, netbsd, openbsd): last Monday snapshot does not permit it, wondering My personal preference is to SEGV. I can find no reason to allow it except NRL compatibilty. due to freebsd code freeze, we need to get the answer VERY soon. please respond if you have any hints. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 01:34:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R9W4D19007 for ipng-dist; Thu, 27 Jan 2000 01:32:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R9Vsj19000 for ; Thu, 27 Jan 2000 01:31:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA13266 for ; Thu, 27 Jan 2000 01:31:52 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA19113 for ; Thu, 27 Jan 2000 01:31:50 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA32217; Thu, 27 Jan 2000 20:31:38 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: comments on ipngwg-rfc2292bis-01 In-Reply-To: Your message of "Thu, 27 Jan 2000 11:38:51 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Jan 2000 20:31:37 +1100 Message-Id: <450.948965497@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 27 Jan 2000 11:38:51 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | Of course yes in theory, but I'd think that an IPv6 extension header | rarely needs a length field in more than one byte. That depends what they end up being used for - I wouldn't like to define something now which would constrain choices in the future. The (not accepted but for this purpose that doesn't matter) payload header intended to allow a UCP or TCP (or anything else) packet to appear in its data field - clearly a one byte length would never have worked. | Sorry, the sample code was too simple. In our actual code we of course | reject an unknown header. That's good. Then, when you stop parsing the packet when you reach the unknown header, there's no need to know its length - because there's no need to skip over it (or do anthing else at all to it). Packet processing simply stops (and an ICMPv6 can be returned - that also doesn't need to be able to parse the insides of the unknown header, or anything beyond it). kre -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 01:40:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R9dfZ19026 for ipng-dist; Thu, 27 Jan 2000 01:39:41 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R9dVj19019 for ; Thu, 27 Jan 2000 01:39:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA03570 for ; Thu, 27 Jan 2000 01:39:30 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27577 for ; Thu, 27 Jan 2000 02:39:28 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA02814 for ; Thu, 27 Jan 2000 18:39:27 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Fri, 14 Jan 2000 02:41:04 JST. <15325.947785264@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: iruserok() with address-family independence From: itojun@iijlab.net Date: Thu, 27 Jan 2000 18:39:27 +0900 Message-ID: <2812.948965967@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I need more insight from someone familier with un*x API standards > (and this is why I posted it here). To summarize the question: > - are ruserok() and iruserok() in any of standards? > NetBSD manpage says they were from 4.2BSD, nothing more. > - if we supply address-family neutral version of iruserok (takes > sockaddr but I doubt this would be used with non-IP protocol), > which is preferable? > iruserok_sa > ruserok_sa > and question to ipngwg: there was no voice raised so far. just to report that *bsd (well, openbsd and netbsd - and freebsd i believe), picked iruserok_sa() with the following arguments. function prototype is in unistd.h. the reason for first arg being void * (not struct sockaddr *) and next being int (not socklen_t) is to avoid dependency between sys/socket.h and unistd.h, nothing more. since we specify salen separately, linux/solaris should be happy as well. > - do we need iruserok_sa (or ruserok_sa) in 2292bis? no need for inclusion. itojun int iruserok_sa(const void *sa, int salen, int superuser, const char *ruser); -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 01:46:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0R9hXt19044 for ipng-dist; Thu, 27 Jan 2000 01:43:33 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0R9hMj19037 for ; Thu, 27 Jan 2000 01:43:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA03708 for ; Thu, 27 Jan 2000 01:43:22 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA22750 for ; Thu, 27 Jan 2000 01:43:20 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA02906; Thu, 27 Jan 2000 18:43:03 +0900 (JST) To: Jean-Luc Richier cc: Tim Hartrick , ipng@sunroof.eng.sun.com In-reply-to: Jean-Luc.Richier's message of Fri, 14 Jan 2000 12:27:55 +0100. <200001141127.MAA24510@horus.imag.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: bindresvport() From: itojun@iijlab.net Date: Thu, 27 Jan 2000 18:43:03 +0900 Message-ID: <2904.948966183@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk just for the record. for netbsd/freebsd/openbsd, after long iscussion we've picked the following: int bindresvport(int sd, sockaddr_in *sin); int bindresvport_sa(int sd, sockaddr *sa); they both support AF_INET6. the only difference between them is function prototype. - when 2nd arg is NULL, it obeys address family of "sd" - when 2nd arg is not NULL, "family" field must properly be initialized, and it must match address family of "sd". this does not add additional requirements to old applications. see openbsd/netbsd/freebsd manpage for more details. thanks for all those participated in the discussion, including Jean-Luc, Inoue-san of KAME, and Theo de Raadt. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 07:19:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RFGoE19696 for ipng-dist; Thu, 27 Jan 2000 07:16:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RFGfj19689 for ; Thu, 27 Jan 2000 07:16:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA02770 for ; Thu, 27 Jan 2000 07:16:24 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14610 for ; Thu, 27 Jan 2000 07:16:22 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id ECFED32C; Thu, 27 Jan 2000 10:16:21 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 6BE7A319; Thu, 27 Jan 2000 10:16:21 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000014926; Thu, 27 Jan 2000 10:16:19 -0500 (EST) From: Jim Bound Message-Id: <200001271516.KAA0000014926@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , bzill@microsoft.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: scope-exceeded and routing headers In-reply-to: Your message of "Thu, 27 Jan 2000 15:13:37 +0900." <29430.948953617@coconut.itojun.org> Date: Thu, 27 Jan 2000 10:16:19 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I'd personally think we should not put addresses of different type of >>scopes into the source filed, destination filed, and all intermediate >>destination field of a routing header. i.e. All the addresses should >>belong to a same kind of scope. > > I agree with jinmei on this point. I wasn't clear enough. I believe this is a prudent ruleset too. Avoids the issue completely. /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 07:38:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RFZRZ19723 for ipng-dist; Thu, 27 Jan 2000 07:35:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RFZIj19716 for ; Thu, 27 Jan 2000 07:35:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA01561 for ; Thu, 27 Jan 2000 07:35:18 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23469 for ; Thu, 27 Jan 2000 07:35:16 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id E2F5E15204C; Thu, 27 Jan 2000 09:35:14 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id DA535148506; Thu, 27 Jan 2000 09:35:14 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 7A085BC4D2; Thu, 27 Jan 2000 09:35:07 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 0010EB2A42; Thu, 27 Jan 2000 09:35:06 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000017164; Thu, 27 Jan 2000 10:35:13 -0500 (EST) From: Jim Bound Message-Id: <200001271535.KAA0000017164@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , "'itojun@iijlab.net'" , Richard Draves , IPng List Subject: Re: scope-exceeded and routing headers In-reply-to: Your message of "Thu, 27 Jan 2000 00:25:31 PST." <3D2036E25376D31197A100805FEAD892712FE2@RED-MSG-02> Date: Thu, 27 Jan 2000 10:35:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >> But if the packet src is FEC0/8 and the DST cycles >> to >site (i.e. 3ffe) then I do not think the packet >> should be forwarded at all. > >Uh, why not? We allow mixed scope source/destination addresses in other >cases today. I'd think it'd be ok to forward the packet in this example, >but only on the link the packet came in on. Good point on the same link. In my above words I was thinking different link, sorry. For the same link that is fine. I just assumed this is OK in my reading of the ICMPv6 dst unreachable exceeding scope...uh oh.. Do we need to clarify that for that icmp type? >Looks like I may have opened another can of worms here :-) Alot of worms as we learn more. When I started working on IPv6 I accepted we would have warts :---).... Wait till I open the discussion of rfc2553bis (soon) ---).. >Let me try a different approach. In the normal (no routing header) case, >you can only forward packets to places inside their zone. This requires >checking both the source and destination fields in the IP header. Packets >with a link-level source and/or destination address can only be forwarded >out via the same interface they came in on. Packets with a site-local >source and/or destination address can only be forwarded out via an interface >that shares a scope_id value with the interface that the packet came in on >(i.e. it must go out the same interface it came in on, or another interface >within the same "site" as the one it came in on). Any packets that don't >pass these checks get dropped and an ICMPv6 scope-exceeded message gets sent >back to the source. Haberman's scoped-routing draft covers most of this. Yep. >The problem with the routing header is that it allows scoped addresses to >cross zone boundaries without being subject to these checks because the >checks are only performed against the source and destination fields of the >IP header proper. Telling routers that they must make these checks against >every address present in a routing header when forwarding would add >tremendous overhead (it'd have to be done at each hop, not just at every >intermediate destination) and also run against the base IPv6 Specification >which says that only hop-by-hop options are done at each hop. So that's >out. The only options are to disallow scoped addresses in routing headers >completely (which was actually my original idea until I got talked out of >it), or allow them and come up with some way of assigning them a zone when >they cycle up out of a routing header. A point. There is no bits in the address to define a scope_id so your sentence: >The only options are to disallow scoped addresses in routing headers I am having trouble parsing? All addresses are scoped but the scope_id is not part of the address? >So what zone should they be assigned? There is no way to tell with >certainty what zone the packet originated in, so that's out. The current >router that the packet is at might not have an interface in the original >zone in any case. So the proposed rule is to use the zone of the interface >that the packet came in on ("weak host" model nodes might want to use the >zone of the interface with the IP address corresponding to the destination >field in the packet). In other words, if the packet came in on interface >"5", and the next address in the routing header is link-local, treat that >link-local address as having a scope_id of "5". If the next address in the >routing header is site-local, then treat it as having a scope_id equal to >whatever interface 5's site identifier is. Then route as normal and the >normal routing rules for scoped addresses will prevent the packet from >leaving its newly assigned zone. Think we should stop saying scoped addresses here? And maybe refer to addresses which have an associated scope_id? I think it will get confusing for discussions? This could be done as you suggest but put a lot of overhead in the forwarding path which already may be an issue for VoIP packets, Cell-HTTP packets from a mobile node, etc... So I am wondering if we can just make this much more simple. I need to go reread Brian's draft and think about this some more. But right now we need to answer the simple question of the scope exceeded issue Richard raised. I'll be back later. >The end result of this is that putting scoped addresses in routing headers >is only useful if the sender knows the "zone" of the intermediate >destination just prior to the scoped address. Because that is the "zone" >the scoped address will be interpreted in. So yeah, this is one smart >sender. One contrived example: say I have a dumb device on my local wire >that only has a link-local address, and I normally talk to it via my >workstation on the same local wire. I could still send to this dumb device >when I'm far away by using a routing header with my workstation's global >address as the intermediate destination and the dumb device's link-local >address as the final destination. It couldn't respond, but oh well. Again all addresses are scoped? Your last sentence is my issue with even permitting normal communications that have src=link-local and dst=global. I am a pragmatist. The dst simply cannot respond. I hated calculus until I took diffyQ then I understood why calculus was useful to me as an engineer. Likewise whats the win here? I don't see it? >Is this capability really useful? I dunno. Is there any reason to forbid >it? I can't think of one. So I think it would be better to take the more >permissive approach. The behavior outlined in this message is how the >latest release of our stack (msripv6 1.4) behaves. OK. I kind said above the same thing, is it useful? I dunno? But we should not change the ICMPv6 spec till we are sure. >> Be good to use examples with real addresses for me >> anyway else I can't get into the examples. > >Okay, I'll do that in the draft. Great... My input to you is we need you to work with Steve on the site stuff first :----).... thanks /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 10:08:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RI4fK20049 for ipng-dist; Thu, 27 Jan 2000 10:04:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RI4Wj20042 for ; Thu, 27 Jan 2000 10:04:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA25488 for ; Thu, 27 Jan 2000 10:04:32 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13454 for ; Thu, 27 Jan 2000 10:04:31 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 7CD6321A; Thu, 27 Jan 2000 13:04:30 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 3222A37C for ; Thu, 27 Jan 2000 13:04:30 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000001845; Thu, 27 Jan 2000 13:04:29 -0500 (EST) From: Jim Bound Message-Id: <200001271804.NAA0000001845@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: rfc2553bis Update overview of assumptions, goals, etc. Date: Thu, 27 Jan 2000 13:04:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear WG, It is time to update because of the scope_id issues RFC 2553, the work will be rfc2553bis. Before I start changing text, editing etc. I would like to be clear on the input and issues we need to resolve in the spec. First I present some assumptions, then the changes in general that must be made per all the input. Once we get that level of understanding I can then start changing the spec. All of this needs some discussion. Lastly I present the reviewers of this update that are needed to achieve consensus on this spec. IMPORTANT: The reason we are updating the spec is because of the scope_id issue. This is not a free-for-all to put everything people want in the API, we have shipping products now, existing users, and binary compatibility is imperative for this API and I would also add source portability. Assumptions: Not being done in rfc2553bis at this time I assume these will be info rfcs?: A: A paper will be written for scope_ids (carl williams) B: A paper on concatenating scope_ids and addresses (JINMEI Tatuya) C: A paper on literal IPv6 addresses with port numbers (TBD) D: A paper on multihoming API issues (TBD) E: Others ????????????????? XNS Work. We will update text to be consistent with XNS version of the API you can view this work at: http://www.opengroup.org/publications/catalog/c808.htm Changes to rfc2553bis: 1. Edits to the Document we may have missed. 2. Update wording of rfc2553bis to be in synch with XNS version. For example section 3.10 will be updated to reflect what has been done XNS for struct sockaddr_storage and the additional error vals will be added to getaddrinfo/getnameinfo. 3. getipnodebyname/getipnodebyaddr will be removed from the main document and moved to an appendix. 4. getaddrinfo/getnameinfo need to be updated so all behavior supported by getipnodebyname/getipnodebyaddr is supported. 5. Header Files that should be added to the spec. Some sin6_scope_id discussions: 1. Need more text further describing its use or take the relevent papers above and add as an appendix. 2. The sections under section 4.0 Interface Identification should not be altered to accept / send scope_id, these are useful functions and this is not needed. 3. Likewise for the Multicast functions in section 5.0 as stated in #2 above. 4. inet_pton and inet_ntop should not be changed as they are useful functions to work on addresses. We need to add text to getaddrinfo regarding implementation of strings containing address+scope_ids. 5. Essentially the reason to moving to getaddrinfo/getnameinfo should hide this API from dealing directly with scope_ids. Reviewers for consensus of rfc2553bis update: - IPng WG - XNS WG - Internet Software Consortia and BIND Workers All discussion must take place on the IPng mailing list. Comments and Input? regards, /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 10:48:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RIjuX20117 for ipng-dist; Thu, 27 Jan 2000 10:45:56 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RIjkj20110 for ; Thu, 27 Jan 2000 10:45:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA01197 for ; Thu, 27 Jan 2000 10:45:45 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09540 for ; Thu, 27 Jan 2000 11:45:42 -0700 (MST) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA16112; Fri, 28 Jan 2000 03:34:36 +0900 (JST) Date: Fri, 28 Jan 2000 03:45:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bzill@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: scope-exceeded and routing headers In-Reply-To: In your message of "Wed, 26 Jan 2000 23:01:09 -0800" <3D2036E25376D31197A100805FEAD892712FE1@RED-MSG-02> References: <3D2036E25376D31197A100805FEAD892712FE1@RED-MSG-02> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 131 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 26 Jan 2000 23:01:09 -0800, >>>>> Brian Zill said: > First let me say that what I said in my previous message was my > interpretation of the outcome of an earlier discussion of this issue, not > what my personal inclination was. My original thought was that we'd need to > disallow scoped addresses in routing headers (i.e. global only). The > opposing argument was that we shouldn't prevent people from doing something > unnecessarily, and if senders want to play with fire this way, let them. I > ended up agreeing with that argument. Okay, and I agree that we should allow a die-hard user to play with anything (even if it could be dangerous) unless there is a strong and reasonable reason to oppose it. >> Then how do you think about the following case? >> >> src = global1 >> dst = link-local (router) >> rthdr = global2 (where router forwards it) >> >> In this case, even if the outgoing interface to >> global2 for the router is in the same link to which >> "dst" belongs, the forwarded packet could be leave >> the link scope of "dst" (see the following figure). >> src router |g1 |link-local | | |-+---+---+---| | another_router | +---------.......---g2 (final destination) > I don't see anything wrong with this. If the source (g1) wants to send to > (g2) and insist that the packet passes through "router" on the way, this > seems like a perfectly good way to do it. Why is this a problem? Because the "router" essentially forwards the packet to another link of "dst" in this case (if g2 belongs to a different link from the link of "dst"). You said in your previous mail as follows: > For your third example, > you'd forward the packet to the global address ("rthdr") -- but only if the > route you'd use to reach that global address goes out the interface with the > link-local address "dst", otherwise you'd drop the packet. When the "router" forwards to the packet toward "global2", it won't be able to detect the (new) destination is in the same link of "dst". Why is this case allowed while the previous case is prohibited? Also, please note that once the "router" cycles the destination address to "global2", the "another_router" won't be able to detect that the packet is leaving the link scope of "dst" unless it checks the content of the embedded routing header, which will cause a tremendous overhead on the router as you said in another mail. However...we could take an approach that once an address contained in a routing header is validly processed, the packet containing the header can even leave the scope zone of the address (like the above example). If this is a wg consensus, I'll follow it. But please let me confirm one more point. Consider the following packet containing a routing header: src = global1 dst = global2 1st element of the rthdr: link-local Also suppose that global1 and global2 are offlink and there are several paths to global2 like the following figure: global1 ........---+ | / |(interface1) +-------....(Internet clould) global2 \ |(interface2) +......----+ If the router of global2 adopt the weak host(node) model, it will accept packets destined to global2 regardless of the incoming interface (interface1 or interface2). The incoming interface depends on the routing in the intermediate cloud and could be dynamically changed. When global2 tries to forward the packet to "linklocal", which link (interface) should it send the packet? To the incoming interface, or the interface that has "global2" (those two are not necessarily same), or even another interface? According to your mail as a response to Jim, you seem to take the former (i.e. forward to the incoming interface). But as I said above, the incoming interface could dynamically change according to the routing. Your proposal assumes a "clever" sending node that knows all the network topology. (Though I'm not sure if it is practically feasible) the assumption itself is OK for me. However, isn't it a too strong assumption that the sending node can know or control the routing in the intermediate cloud? Or do you propose the latter approach? Or should all routers that handle a routing header adopt the strong host (node) model? I need a clarification on these points before accepting your proposal. >> I'd personally think we should not put addresses >> of different type of scopes into the source filed, >> destination filed, and all intermediate destination >> field of a routing header. i.e. All the addresses should >> belong to a same kind of scope. > I see in another message that itojun agrees with you on this. I don't think > I do. Unless there is a very good reason for such a draconian policy, I > don't think we should set one. We're way beyond discussing just routing > headers here, but are getting into the realm of scoped address routing and > source and destination address selection. Both the scoped-routing draft and > the default-addr-select draft allow for, and explain how to work with, > situations where the source and destination addresses are of different > scopes. Oops, sorry. I made a mistake in the above text (of mine). My intention was "we should not put addresses of different type of scopes into the destination filed and all intermediate destination fields of a routing header (i.e. the source can belong to any type of scope)". The source and destination (including one in a routing header) addresses can have different kind of scopes. If the packet with such src and dst addresses is leaving a scope, the forwarding router will be able to detect it and drop the packet. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 11:05:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RJ1at20159 for ipng-dist; Thu, 27 Jan 2000 11:01:36 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RJ1Rj20152 for ; Thu, 27 Jan 2000 11:01:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA04670 for ; Thu, 27 Jan 2000 11:01:27 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13813 for ; Thu, 27 Jan 2000 11:01:24 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 830A2104BDE; Thu, 27 Jan 2000 13:01:23 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 7E328FB101 for ; Thu, 27 Jan 2000 13:01:23 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id EAB47BC4C7; Thu, 27 Jan 2000 13:01:15 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 95C18B2A43 for ; Thu, 27 Jan 2000 13:01:15 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000016537; Thu, 27 Jan 2000 14:01:21 -0500 (EST) From: Jim Bound Message-Id: <200001271901.OAA0000016537@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: RESEND: DNS IPv6.INT issue Date: Thu, 27 Jan 2000 14:01:21 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- The following addresses had permanent fatal errors ----- From: Jim Bound Message-Id: <200001271833.NAA0000007780@quarry.zk3.dec.com> To: Erik Nordmark Cc: ipngwg@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: (ngtrans) Use of IP6.INT In-reply-to: Your message of "Tue, 25 Jan 2000 14:56:42 PST." Date: Thu, 27 Jan 2000 13:33:39 -0500 X-Mts: smtp MIME-Version: 1.0 Hi Erik, >Please followup on the ipngwg list only. ACK. >There has been some discussion for a while in the IAB and IESG about the >use of .INT. Since this is assigned to ITU to do assignments for >international (treaty?) organizations it is clear that the IETF should >not use .INT for any future use. Why is the suffix an issue if the prefix is different? This sounds like a political issue but has technical ramifications. Also who actually owns the Reverse Tree now? I did not think it was the IETF, and best they could do is make recommendation? What would ITU use a .INT for? Clarity on the above three points would be useful (thanks). >The question on the table is whether or not we should switch IP6.INT >to be somewhere else. I'd like to understand the implications of >doing such a switch and in particular it it can be piggy-backed on >the transition from AAAA to A6, DNAME, and binary labels. Well we all have shipping products that use IPv6.INT. As you know most of us have it hardcoded in our C runtime libraries (e.g. getnameinfo). Also users have configs using IPv6.INT. But if we leave "nibble" queries under IPv6.INT and binary label queries under ip6.arpa (as one mail recently suggested), that feels OK. I would like to hear Bill Mannings view of this too to the list? regards, /jim - --KAA28383.948998041/engmail2.Eng.Sun.COM-- ------- End of Forwarded Message -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 11:12:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RJBPG20236 for ipng-dist; Thu, 27 Jan 2000 11:11:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RJBGj20229 for ; Thu, 27 Jan 2000 11:11:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA11188 for ; Thu, 27 Jan 2000 11:11:15 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24434 for ; Thu, 27 Jan 2000 12:11:10 -0700 (MST) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA16210; Fri, 28 Jan 2000 03:48:04 +0900 (JST) Date: Fri, 28 Jan 2000 03:58:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: haberman@nortelnetworks.com Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: updated PIM for IPv6 draft In-Reply-To: In your message of "Tue, 21 Dec 1999 12:44:53 -0500" <385FBC94.F5B27045@nortelnetworks.com> References: <3835BBF9.1CCC1D9F@nortelnetworks.com> <385FBC94.F5B27045@nortelnetworks.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 21 Dec 1999 12:44:53 -0500, >>>>> "Brian Haberman" said: > Your approach would be consistent with what OSPF for IPv6 does. > The draft could be changed to require that change, but I would like > some input from the working groups. >> i.e. the checksum is calculated without a pseudo-IP header. However, I >> believe it should be calculated *with* a pseudo-IP header for IPv6 PIM >> packets, because IPv6 does not have an IP layer checksum and because >> PIM depends on some fileds of received IP packets (e.g. the source >> address field). >> >> If it's reasonable, I hope it will be described in a future version of >> the pim-ipv6 draft and/or the pim-v2 draft. I've been watching the list, but I've not seen any opinions on this issue (sorry if I missed something). Does this mean that everyone agrees on the change? Or do I miss something fundamental? Thanks again. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 11:44:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RJgxv20311 for ipng-dist; Thu, 27 Jan 2000 11:42:59 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RJgnj20304 for ; Thu, 27 Jan 2000 11:42:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA01233 for ; Thu, 27 Jan 2000 11:42:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06079 for ; Thu, 27 Jan 2000 11:42:47 -0800 (PST) Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id LAA03391; Thu, 27 Jan 2000 11:42:46 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.8.7/8.8.6) id LAA09286; Thu, 27 Jan 2000 11:42:40 -0800 (PST) Message-Id: <200001271942.LAA09286@zed.isi.edu> Subject: Re: RESEND: DNS IPv6.INT issue To: bound@zk3.dec.com (Jim Bound) Date: Thu, 27 Jan 2000 11:42:40 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200001271901.OAA0000016537@quarry.zk3.dec.com> from "Jim Bound" at Jan 27, 2000 02:01:21 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % >There has been some discussion for a while in the IAB and IESG about the % >use of .INT. Since this is assigned to ITU to do assignments for % >international (treaty?) organizations it is clear that the IETF should % >not use .INT for any future use. It is -NOT- true that the .INT. zone is assigned to the ITU. It is not clear that the IETF should recommend any given entry point in the DNS heirarchy as long as it works. % Why is the suffix an issue if the prefix is different? This sounds % like a political issue but has technical ramifications. This is true. % Also who actually owns the Reverse Tree now? I did not think it was % the IETF, and best they could do is make recommendation? ICANN has operational control of .INT and is unlikely to transition it elsewhere, at least in the forseeable future. % What would ITU use a .INT for? .INT has two functions, INTernet infrastructure and INTernational treaty organizations. This last reason is the argument ITU makes for taking on the zone. % Clarity on the above three points would be useful (thanks). % % I would like to hear Bill Mannings view of this too to the list? Again? :) I'm not in favor of re-activating and new efforts in the .ARPA domain, there has been a long, sometimes painful effort to clear out this zone. I'd like to hear a technical reason to migrate. (and I'd really like to see more flexability in the resolver code but that is another issue.) % regards, % /jim % % % - --KAA28383.948998041/engmail2.Eng.Sun.COM-- % % % ------- End of Forwarded Message % % -------------------------------------------------------------------- % 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 majordomo@sunroof.eng.sun.com % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 11:44:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RJfam20296 for ipng-dist; Thu, 27 Jan 2000 11:41:36 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RJfPj20289 for ; Thu, 27 Jan 2000 11:41:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA17929 for ; Thu, 27 Jan 2000 11:41:24 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05441 for ; Thu, 27 Jan 2000 11:41:23 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA26711; Thu, 27 Jan 2000 11:23:26 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA05806; Thu, 27 Jan 2000 11:23:26 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.1) id LAA05775; Thu, 27 Jan 2000 11:24:54 -0800 (PST) Date: Thu, 27 Jan 2000 11:24:54 -0800 (PST) From: Tim Hartrick Message-Id: <200001271924.LAA05775@feller.mentat.com> To: haberman@nortelnetworks.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: updated PIM for IPv6 draft Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > > Your approach would be consistent with what OSPF for IPv6 does. > > The draft could be changed to require that change, but I would like > > some input from the working groups. > > >> i.e. the checksum is calculated without a pseudo-IP header. However, I > >> believe it should be calculated *with* a pseudo-IP header for IPv6 PIM > >> packets, because IPv6 does not have an IP layer checksum and because > >> PIM depends on some fileds of received IP packets (e.g. the source > >> address field). > >> > >> If it's reasonable, I hope it will be described in a future version of > >> the pim-ipv6 draft and/or the pim-v2 draft. > > I've been watching the list, but I've not seen any opinions on this > issue (sorry if I missed something). Does this mean that everyone > agrees on the change? Or do I miss something fundamental? > For what it is worth I agree with you. Any upper level protocol that depends on the fields of the IPv6 header which are covered by the standard TCP/UDP pseudo header checksum calculation should specify the same pseudo header checksum calculation. Without this integrity check, misdelivered or intentially forged datagrams could cause serious problems absent some other form of integrity check. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 13:27:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RLP3920454 for ipng-dist; Thu, 27 Jan 2000 13:25:03 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RLOqj20447 for ; Thu, 27 Jan 2000 13:24:52 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA18364; Thu, 27 Jan 2000 13:24:50 -0800 (PST) Date: Thu, 27 Jan 2000 13:24:22 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: scope-exceeded and routing headers To: Richard Draves Cc: IPng List In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8101F17C259@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does this same error situation apply to routing header processing? The site-prefixes draft makes the assumption that it is ok to send a packet with a global source, global destination, and a 1 element source route which contains the site-local address of the destination node. This is to handle Mobile IPv6 nodes that leave their site but are communicating using site-local addresses. (There is also a Home Address option in the packets containing the site-local address of the sender.) Assuming we want to support this we don't want to check all elements of the source route when leaving a site. But when forwarding a packet (with or without a routing header) we should always check the source IP address. Exactly what case where you asking about? The source address being out of scope or the addresses in the routing header being out of scope? 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 13:34:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RLX9s20479 for ipng-dist; Thu, 27 Jan 2000 13:33:09 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RLWuj20472 for ; Thu, 27 Jan 2000 13:32:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA09840 for ; Thu, 27 Jan 2000 13:32:54 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11768 for ; Thu, 27 Jan 2000 14:32:53 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA29536; Thu, 27 Jan 2000 22:32:51 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA06748; Thu, 27 Jan 2000 22:32:51 +0100 (MET) Message-Id: <200001272132.WAA06748@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: Richard Draves , IPng List Subject: Re: scope-exceeded and routing headers In-reply-to: Your message of Wed, 26 Jan 2000 22:11:07 EST. <200001270311.WAA0000003502@quarry.zk3.dec.com> Date: Thu, 27 Jan 2000 22:32:37 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => I share Jim's position about this issue. >The ICMPv6 draft defines a new destination unreachable code point for >scope-exceeded errors, when forwarding a packet would cause it to leave the >scope of the source address. This is a prudent dst unreach principle architecturally with the IPv6 addressing model. => there is no rationate for scope-exceeded errors but for me the idea is to avoid the forwarding of packets which can't be returned to the source if something is going wrong down on the path. For source routed packets this is weaker than the "no reverse path" condition, I think in such cases a "SHOULD NOT" is enough (for scope-exceeded errors, I believe the statement is "MUST NOT be forwarded"). >Does this same error situation apply to routing header processing? Absolutely. => I agree! I'll refuse any proposal to look at inside routing headers for any routers (only intermediate routers, ie. routers in the source route, should deal with routing headers). >It seems like allowing a routing header to carry a packet beyond the >source's scope might be useful in some situations, and if the sender is >going to the trouble of specifying a routing header then presumably they >know what they are doing. On the other hand, this could easily violate >assumptions that receivers make about the source address in packets they >receive. (Like being able to reply without using a reversed routing header, >or pseudo-security assumptions.) If a packet is to exceed the source's scope thru forward operation that is simple illegal to me in IPv6. Its black and white and not gray. => I agree, scope-exceeded errors just add a (useful) check in the forwarding code. Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 13:36:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RLYwS20490 for ipng-dist; Thu, 27 Jan 2000 13:34:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RLYjj20481 for ; Thu, 27 Jan 2000 13:34:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA10172 for ; Thu, 27 Jan 2000 13:34:43 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12712 for ; Thu, 27 Jan 2000 14:34:42 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA29589; Thu, 27 Jan 2000 22:34:39 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA04063; Thu, 27 Jan 2000 22:34:38 +0100 (MET) Message-Id: <200001272134.WAA04063@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: Alex_Conta@ne.3com.com, Richard Draves , IPng List Subject: Re: scope-exceeded and routing headers In-reply-to: Your message of Wed, 26 Jan 2000 22:15:06 EST. <200001270315.WAA0000000672@quarry.zk3.dec.com> Date: Thu, 27 Jan 2000 22:34:37 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >the /destination uncreachable/scope-exceded/ error condiftion si detected >on the packet forwarding path, i.e. main header source/destination address >processing. This implies that there is no difference between a packet >that has a routing header and one that does not. Exactly. This is why it is black and white decision. Not gray. The condition test to forward has nothing to do with why or how the packet got there, but that the packet if forwarded will exceed its scope. I can't see reading it any other way as an implementor. => I agree as an implementor too! Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 13:41:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RLd3B20565 for ipng-dist; Thu, 27 Jan 2000 13:39:03 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RLchj20548 for ; Thu, 27 Jan 2000 13:38:43 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA20508; Thu, 27 Jan 2000 13:38:40 -0800 (PST) Date: Thu, 27 Jan 2000 13:38:13 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: scope-exceeded and routing headers To: Brian Zill Cc: "'JINMEI Tatuya / ????'" , ipng@sunroof.eng.sun.com, "'itojun@iijlab.net'" In-Reply-To: "Your message with ID" <3D2036E25376D31197A100805FEAD892712FE1@RED-MSG-02> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > src router > > |g1 |link-local > > | | > > |-+---+---+---| > > | > > another_router > > | > > +---------.......---g2 (final destination) > > I don't see anything wrong with this. If the source (g1) wants to send to > (g2) and insist that the packet passes through "router" on the way, this > seems like a perfectly good way to do it. Why is this a problem? Shouldn't g2 be able to reverse the routing header and use it for packets in the reverse direction? If it did it would try to send to the link-local address of "router" which is in a different zone. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 13:47:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RLk3d20652 for ipng-dist; Thu, 27 Jan 2000 13:46:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RLjsj20645 for ; Thu, 27 Jan 2000 13:45:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA23599 for ; Thu, 27 Jan 2000 13:45:52 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18279 for ; Thu, 27 Jan 2000 14:45:51 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA29821; Thu, 27 Jan 2000 22:45:48 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA03422; Thu, 27 Jan 2000 22:45:46 +0100 (MET) Message-Id: <200001272145.WAA03422@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: itojun@iijlab.net, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , bzill@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: scope-exceeded and routing headers In-reply-to: Your message of Thu, 27 Jan 2000 10:16:19 EST. <200001271516.KAA0000014926@quarry.zk3.dec.com> Date: Thu, 27 Jan 2000 22:45:45 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>I'd personally think we should not put addresses of different type of >>scopes into the source filed, destination filed, and all intermediate >>destination field of a routing header. i.e. All the addresses should >>belong to a same kind of scope. > > I agree with jinmei on this point. I wasn't clear enough. I believe this is a prudent ruleset too. Avoids the issue completely. => I agree for a SHOULD (this doesn't completely avoid the issue but make more discussions nearly useless :-). Regards Francis.Dupont@inria.fr PS: there is an other very old issue related to this one discovered by Jean-Luc Richier (who doesn't want to use such routing header hack). If you are doing a topology discovery using SNMP and routing tables, you should get as "next hop" only link-local addresses (with scope IDs) and you can go further than the first round because this kind of information is not enough for sending SNMP requests to routers. A link-local address to global address (or name) proxy service should be a good solution but none is really available even on paper (I haven't search in draft-ietf-ipngwg-icmp-name-lookups-05.txt then I apologize if this is in the I-D). -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 14:24:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RMLTH20859 for ipng-dist; Thu, 27 Jan 2000 14:21:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RMLJj20848 for ; Thu, 27 Jan 2000 14:21:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA00347 for ; Thu, 27 Jan 2000 14:21:20 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07172 for ; Thu, 27 Jan 2000 15:21:18 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id XAA00803; Thu, 27 Jan 2000 23:21:17 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id XAA02816; Thu, 27 Jan 2000 23:21:16 +0100 (MET) Message-Id: <200001272221.XAA02816@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: haberman@nortelnetworks.com, pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: updated PIM for IPv6 draft In-reply-to: Your message of Fri, 28 Jan 2000 03:58:48 +0900. Date: Thu, 27 Jan 2000 23:21:15 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Does this mean that everyone agrees on the change? => I agree (ie. the rationate for ICMPv6 checksum applies to PIMv6 one). Regards Francis.Dupont@inria.fr PS: we need a way (flag day?) to solve the interopability issue introduced by this change. -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 15:17:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RNFwt20931 for ipng-dist; Thu, 27 Jan 2000 15:15:58 -0800 (PST) Received: from sappey.eng.sun.com (sappey [129.146.85.69]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RNFmj20924 for ; Thu, 27 Jan 2000 15:15:48 -0800 (PST) Received: from eng.sun.com (localhost [127.0.0.1]) by sappey.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00959; Thu, 27 Jan 2000 15:15:47 -0800 (PST) Message-ID: <3890D1A3.3E7660C0@eng.sun.com> Date: Thu, 27 Jan 2000 15:15:47 -0800 From: Alain Durand X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Jim Bound , itojun@iijlab.net, jinmei@isl.rdc.toshiba.co.jp, bzill@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: scope-exceeded and routing headers References: <200001272145.WAA03422@givry.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > > PS: there is an other very old issue related to this one discovered > by Jean-Luc Richier (who doesn't want to use such routing header hack). > If you are doing a topology discovery using SNMP and routing tables, > you should get as "next hop" only link-local addresses (with scope IDs) > and you can go further than the first round because this kind of > information is not enough for sending SNMP requests to routers. > A link-local address to global address (or name) proxy service > should be a good solution but none is really available even on paper > (I haven't search in draft-ietf-ipngwg-icmp-name-lookups-05.txt > then I apologize if this is in the I-D). Francis, It is in this ID, section 5.4 - Alain. 5.4. Node Addresses The NI Node Addresses Query requests some set of the Responder's IPv6 unicast addresses. The Reply Data is a sequence of 128-bit IPv6 addresses, each address preceded by separate a 32-bit TTL value, with Preferred addresses listed before Deprecated addresses [2461], but otherwise in no special order. Five flag bits are defined in the Query, and six in the Reply. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype=3 | unused |G|S|L|C|A|T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G If set to 1, Global-scope addresses [2374] are requested. S If set to 1, Site-local addresses [2374] are requested. L If set to 1, Link-local addresses [2374] are requested. C If set to 1, IPv4-compatible and IPv4-mapped addresses [2373] are requested. A If set to 1, all the Responder's unicast addresses (of the specified scope(s)) are requested. If 0, only those addresses are requested which belong to the interface (or any one interface) which has the Subject Address, or which are associated with the Subject Name. T Defined in a Reply only, indicates that the set of addresses is incomplete for space reasons. Flags G, S, L, C and A are copied from a Query to the corresponding Reply. The TTL associated with each address are to be determined by the rules in section 5.3, applied to the returned address rather than the Subject. If no meaningful caching time can be given for an address, the corresponding TTL field MUST be zero. Each address with non-zero TTL in a NI Node Address Reply may be cached and used for the period indicated by that TTL. If the TTL is zero, the corresponding address must not be used more than once. If the Query was sent by a DNS server on behalf of a DNS client, the result may be returned to that client as a DNS response with TTL zero. IPv4-mapped addresses can only be returned by a Node Information proxy, since they represent addresses of IPv4-only nodes, which perforce do not implement this protocol. -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 15:17:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0RNEti20922 for ipng-dist; Thu, 27 Jan 2000 15:14:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0RNEkj20915 for ; Thu, 27 Jan 2000 15:14:46 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA01205 for ; Thu, 27 Jan 2000 15:14:46 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22141 for ; Thu, 27 Jan 2000 15:14:45 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 04AED20B; Thu, 27 Jan 2000 18:14:43 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id C045C39D; Thu, 27 Jan 2000 18:14:43 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id SAA0000013737; Thu, 27 Jan 2000 18:14:43 -0500 (EST) From: Jim Bound Message-Id: <200001272314.SAA0000013737@quarry.zk3.dec.com> To: Erik.Nordmark@eng.sun.com Cc: bound@zk3.dec.com, bmanning@ISI.EDU, ipng@sunroof.eng.sun.com Subject: Re: RESEND: DNS IPv6.INT issue In-reply-to: Your message of "Thu, 27 Jan 2000 11:42:40 PST." <200001271942.LAA09286@zed.isi.edu> Date: Thu, 27 Jan 2000 18:14:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, Hmm. From Bill's response below I have to say that I do NOT support the IETF processes altering the present ipv6.INT zone. It also does not sound like the IETF gets to make this decision anyway. Sounds like an ICANN decision? If your coming to this list to see if implementors support this change I can understand that, as I assume the IETF wants to use that as part of its input gathering to ICANN. Well this implementor don't support the change and I recommend to other implementors that they not support this change, until the questions from the attached from Bill Manning are in fact resolved. But with the change it appears we also may want to keep ipv6.INT for installed type processing of nibbles (as I state nested in Bills attached mail). I will also forward this mail to the IPv6 Forum as this has direct ramifications to the deployment of IPv6 at this time, to see what comes back from that set of folks. regards, /jim % >There has been some discussion for a while in the IAB and IESG about the % >use of .INT. Since this is assigned to ITU to do assignments for % >international (treaty?) organizations it is clear that the IETF should % >not use .INT for any future use. It is -NOT- true that the .INT. zone is assigned to the ITU. It is not clear that the IETF should recommend any given entry point in the DNS heirarchy as long as it works. % Why is the suffix an issue if the prefix is different? This sounds % like a political issue but has technical ramifications. This is true. % Also who actually owns the Reverse Tree now? I did not think it was % the IETF, and best they could do is make recommendation? ICANN has operational control of .INT and is unlikely to transition it elsewhere, at least in the forseeable future. % What would ITU use a .INT for? .INT has two functions, INTernet infrastructure and INTernational treaty organizations. This last reason is the argument ITU makes for taking on the zone. % Clarity on the above three points would be useful (thanks). % % I would like to hear Bill Mannings view of this too to the list? Again? :) I'm not in favor of re-activating and new efforts in the .ARPA domain, there has been a long, sometimes painful effort to clear out this zone. I'd like to hear a technical reason to migrate. (and I'd really like to see more flexability in the resolver code but that is another issue.) % regards, % /jim % % % - --KAA28383.948998041/engmail2.Eng.Sun.COM-- % % % ------- End of Forwarded Message % % -------------------------------------------------------------------- % 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 majordomo@sunroof.eng.sun.com % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 17:03:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0S0xec21181 for ipng-dist; Thu, 27 Jan 2000 16:59:40 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0S0xUj21174 for ; Thu, 27 Jan 2000 16:59:30 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA28099; Thu, 27 Jan 2000 16:59:21 -0800 (PST) Date: Thu, 27 Jan 2000 16:58:53 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RESEND: DNS IPv6.INT issue To: Jim Bound Cc: Erik.Nordmark@eng.sun.com, bmanning@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200001272314.SAA0000013737@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > If your coming to this list to see if implementors support this change I > can understand that, as I assume the IETF wants to use that as part of > its input gathering to ICANN. It is actually the IAB that has discussed things and decided not to use .INT for future infrastructure sort of things. I suspect that part of their concern is that the future ownership of .INT is not clear and that we do not want to make infrastructure type of things depend on that unclear future. Thus I just wanted to check if there are any technical issues with switching. Jim, do you have any technical issues? (given that A6 and binary labels are not yet deployed as far as I know) It sounds like both you and Bill do not feel that the change is necessary (even if it has no or very small technical implications.) I'll try to get some more data on why the IAB feels that it is a good thing to not use .INT for future infrastructure things. > Well this implementor don't support the change and I recommend to other > implementors that they not support this change, until the questions from > the attached from Bill Manning are in fact resolved. But with the change > it appears we also may want to keep ipv6.INT for installed type > processing of nibbles (as I state nested in Bills attached mail). Of course. I'm not suggesting that the current RFC 1886 (AAAA records and nibble reverse lookups) be touched at all. The question is about the technical implications of changing the binary labels lookup specified in draft-ietf-ipngwg-dns-lookups could use something else that ip6.int. If we do this switch before there is any deployment of A6/binary labels it seems like there wouldn't be any impact. (A few lines of code would have to be changed in BINDv9 and other implementations of A6 but that is it.) > I will also forward this mail to the IPv6 Forum as this has direct > ramifications to the deployment of IPv6 at this time, to see what comes > back from that set of folks. What impact does it have on deployment given that nobody is advocating changing the currently used RFC 1886 behavior? 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 18:26:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0S2No321275 for ipng-dist; Thu, 27 Jan 2000 18:23:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0S2Nej21268 for ; Thu, 27 Jan 2000 18:23:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA27332 for ; Thu, 27 Jan 2000 18:23:40 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA11542 for ; Thu, 27 Jan 2000 18:23:39 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 42F95104C1B; Thu, 27 Jan 2000 20:23:39 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 3B24CFB101; Thu, 27 Jan 2000 20:23:39 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id E0C894FB02; Thu, 27 Jan 2000 20:23:31 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 4E4C94C902; Thu, 27 Jan 2000 20:23:28 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000015375; Thu, 27 Jan 2000 21:23:34 -0500 (EST) From: Jim Bound Message-Id: <200001280223.VAA0000015375@quarry.zk3.dec.com> To: Erik Nordmark Cc: Jim Bound , bmanning@ISI.EDU, ipng@sunroof.eng.sun.com Subject: Re: RESEND: DNS IPv6.INT issue In-reply-to: Your message of "Thu, 27 Jan 2000 16:58:53 PST." Date: Thu, 27 Jan 2000 21:23:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, I think the IAB is out of there place here. Not there business other than writing a recommendation. If we can keep ipv6.INT for awhile for nibbles this will work. I don't see A6 getting deployed and this should not affect it. So I don't think there is an issue dowm the road. As I said ipv6.INT is hard coded on our implementation in the resolver and I would think others. I just don't want to send out a patch fix for IPv6 for this reason. But I am also responding to the political issue and why do this in the first place. Not trying to shoot the messenger guy... I hope you know that... thanks /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 20:35:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0S4XKw21372 for ipng-dist; Thu, 27 Jan 2000 20:33:20 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0S4XAj21365 for ; Thu, 27 Jan 2000 20:33:10 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA24814; Thu, 27 Jan 2000 20:33:08 -0800 (PST) Date: Thu, 27 Jan 2000 20:32:40 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RESEND: DNS IPv6.INT issue To: Jim Bound Cc: Erik Nordmark , bmanning@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200001280223.VAA0000015375@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I said ipv6.INT is hard coded on our implementation in the resolver > and I would think others. I just don't want to send out a patch fix for > IPv6 for this reason. Does your resolver implement A6 and binary labels? If not you have no reason for any concern. We are only discussion what would make sense when A6 and binary labels are deployed. 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 27 20:49:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0S4kr321427 for ipng-dist; Thu, 27 Jan 2000 20:46:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0S4kgj21420 for ; Thu, 27 Jan 2000 20:46:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA13851; Thu, 27 Jan 2000 20:46:40 -0800 (PST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA24633; Thu, 27 Jan 2000 21:46:40 -0700 (MST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA21828; Thu, 27 Jan 2000 20:46:20 -0800 (PST) From: Bill Manning Message-Id: <200001280446.UAA21828@zephyr.isi.edu> Subject: Re: RESEND: DNS IPv6.INT issue To: Erik.Nordmark@eng.sun.com Date: Thu, 27 Jan 2000 20:46:19 -0800 (PST) Cc: bound@zk3.dec.com (Jim Bound), bmanning@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: from "Erik Nordmark" at Jan 27, 2000 04:58:53 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % It is actually the IAB that has discussed things and decided not to use % .INT for future infrastructure sort of things. I suspect that part of % their concern is that the future ownership of .INT is not clear and that we % do not want to make infrastructure type of things depend on that unclear % future. Man, can I have a crack at that crystal ball. I think that if the IAB chooses to abandon .INT. that the community will be left with yet another legacy, grandfathered system that will have to be supported for a very long time. % It sounds like both you and Bill do not feel that the change is necessary % (even if it has no or very small technical implications.) I don;t see the perceived value. % The question is about the technical implications of changing the binary % labels lookup specified in draft-ietf-ipngwg-dns-lookups % could use something else that ip6.int. % If we do this switch before there is any deployment of A6/binary labels % it seems like there wouldn't be any impact. % (A few lines of code would have to be changed in BINDv9 and other % implementations of A6 but that is it.) Well, according to Matts note, it ought to be fairly trivial to make the change, into any part of the tree. I still don't see a technical reason for it and I see several social reasons to not make the switch (since we already had this discussion when ip6.int was selected.) % Erik --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 05:41:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SDcWO21708 for ipng-dist; Fri, 28 Jan 2000 05:38:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SDcMj21701 for ; Fri, 28 Jan 2000 05:38:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA08450 for ; Fri, 28 Jan 2000 05:38:22 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08374 for ; Fri, 28 Jan 2000 06:38:22 -0700 (MST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id IAA03890 for ; Fri, 28 Jan 2000 08:38:52 -0500 Message-Id: <200001281338.IAA03890@hygro.adsl.duke.edu> To: ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-Reply-To: Message from Erik Nordmark of "Wed, 26 Jan 2000 14:19:39 PST." Date: Fri, 28 Jan 2000 08:38:52 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's a bit more background on the desire to move away from ip6.int (or rather for moving away from .int period). It has been pointed out that that we may not want to use .INT for basic infrastructure. The concern is that mingling infrastructure domains with the "treaty organization" primary function of .INT will sooner or later cause problems, even though ITU is being very careful and cooperative about our views today. Note that the overall plan for .int is that ITU is the organization that will manage it. Even if no problems ever arise, the combination exposes the IETF to more complaints about selling the Internet to the ITU. Thus, it seems prudent to consider using some other domain instead of .int, if the cost of switching is acceptable. Indeed, the IAB has requested that the IESG review all uses of .int to see if it is feasible to switch them to some other domain. Obviously, it won't make sense to switch every use, and the cost/benefit needs to be considered on a case-by-case basis. That is where the current question comes up. We are at a point with IPv6 where we have an opportunity to make such a switch. If we don't do so now, we never will. Thus, we should consider the ramifications of such a switch and whether the cost of switching justifies the benefits. There is a bit of an operational issue here. ip6.int (or whatever the top part of the domain name) needs to be reliable and stable operationally. It will be part of the basic infrastructure and there should be no question about its working in practice. Why .arpa? Ideally, picking a new TLD just for basic infrastrucuture would seem the way to go. But dealing with the political and social issues that go along with creating new TLDs at this time makes this choice unattractive. We also want something short (i.e., as few components removed from the root as possible), so subdomains off of (say) ietf.org would not be ideal. Plus, it's not clear that CNRI wants to take on such a responsibility. That leads to .arpa. We have running code that it is stable and works (the in-addr.arpa part of the namespace, not necessarily the registration of individual addresses). I view this as a chance to buy a bit of insurance. The cost upfront seems quite small (based on discussion so far), but the potential payoff could be large. Thomas -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 06:39:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SEYGI21796 for ipng-dist; Fri, 28 Jan 2000 06:34:16 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SEY5j21789 for ; Fri, 28 Jan 2000 06:34:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA12218 for ; Fri, 28 Jan 2000 06:33:45 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA04803 for ; Fri, 28 Jan 2000 06:33:44 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 1B37A4F4; Fri, 28 Jan 2000 09:33:44 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id F2C6F5D3; Fri, 28 Jan 2000 09:33:43 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000006143; Fri, 28 Jan 2000 09:33:43 -0500 (EST) From: Jim Bound Message-Id: <200001281433.JAA0000006143@quarry.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Use of IP6.INT In-reply-to: Your message of "Fri, 28 Jan 2000 08:38:52 EST." <200001281338.IAA03890@hygro.adsl.duke.edu> Date: Fri, 28 Jan 2000 09:33:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, You did not address the need in the interim to support IPv6.INT until next generation products can use .arpa or whatever. You say its minimal. Its not. We do not want to send out patches with our first releases of Ipv6. You ignored all that mail in your response. Also continually in IPv6 trade-offs as an AD you keep saying we can make the change the pain is minimal. Lets get this straight we are deploying IPv6 and any change that affects shipping software is NOT MINIMAL ANYMORE. Besides it sounds like its really not the IETFs decision to blow ipv6.INT away. I am already speaking offline with others and there is a political issue here too. If I do not see the IETF support the issues raised by Bill Manning and several implementors on this list we will use our own implementors lobby with the ITU or ICANN to protect our investment. Is that what you want? The IETF has to sometimes do what the implementors want. And don't bullshit us. The IETF and ITU don't get along and the IETF is very nervous about the new power of the ITU via ICANN. Lets not appease any needs the IETF has by throwing a sacrifical lamb being IPv6. Also I think its time the vendors started lobbying their interests wherever to make sure the Internet infrastructure is not routed with phone numbers etc. via ITU thought processes. The IETF is a great STANDARDS BODY. But quite frankly the vendors and consumers have a great interest in the Internet staying the way it is and moving forwared into the next millenium. I don't the IETF is the org to influence and put pressure on the political processes to cover our butts. I think we need more powerful and connected leadership to keep our interests in tact. Fine to make a recommendation. But you should stay out of the business of keeping the Internet running or start working with the vendor community. Maybe this is an Internet Society issue. The IETF is simply not qualified to WIN the political battle. There are folks on the IESG and IAB who are qualified but the fact that they are having to play the social and consensus game of the IETF is probably holding them back from fixing the root issues of stewardship of the Internet. regards, /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 07:44:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SFfON21834 for ipng-dist; Fri, 28 Jan 2000 07:41:24 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SFfFj21827 for ; Fri, 28 Jan 2000 07:41:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA26240 for ; Fri, 28 Jan 2000 07:41:15 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00206 for ; Fri, 28 Jan 2000 08:41:14 -0700 (MST) Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id HAA08173; Fri, 28 Jan 2000 07:41:08 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.8.7/8.8.6) id HAA24366; Fri, 28 Jan 2000 07:41:02 -0800 (PST) Message-Id: <200001281541.HAA24366@zed.isi.edu> Subject: Re: Use of IP6.INT To: narten@raleigh.ibm.com (Thomas Narten) Date: Fri, 28 Jan 2000 07:41:02 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200001281338.IAA03890@hygro.adsl.duke.edu> from "Thomas Narten" at Jan 28, 2000 08:38:52 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % Here's a bit more background on the desire to move away from ip6.int % (or rather for moving away from .int period). % % It has been pointed out that that we may not want to use .INT for % basic infrastructure. The concern is that mingling infrastructure % domains with the "treaty organization" primary function of .INT will % sooner or later cause problems, even though ITU is being very careful % and cooperative about our views today. Note that the overall plan for % .int is that ITU is the organization that will manage it. Even if no % problems ever arise, the combination exposes the IETF to more % complaints about selling the Internet to the ITU. Thus, it seems % prudent to consider using some other domain instead of .int, if the % cost of switching is acceptable. Thanks for the background data. Is this from you or from someone else? Some of the precepts and assumptions in this background material seem questionable, e.g. the existance of an "overall plan", and the ability of the IETF to "sell" the Internet to the ITU, (or anyone else for that matter). Migrations are lengthy and have many costs. This material argues that we should abandon the attempts to migrate away from the .arpa zone, which has been in process for ~15 years and now abandon the infrastructure zone which was earmarked by the IANA as the place to migrate to. It almost seems that the IETF is attempting to co-op culpability for potential political ramifications that rightfully are ICANNs turf. IANA/ICANN gave us the .INT zone for infrastructure. Should we turn it down because we think it might be politically sensitive? I think this is a bit beyond IETF perview. --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 08:37:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SGYpU21882 for ipng-dist; Fri, 28 Jan 2000 08:34:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SGYgj21875 for ; Fri, 28 Jan 2000 08:34:43 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29605 for ; Fri, 28 Jan 2000 08:34:43 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03188 for ; Fri, 28 Jan 2000 08:34:41 -0800 (PST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id LAA04641; Fri, 28 Jan 2000 11:35:11 -0500 Message-Id: <200001281635.LAA04641@hygro.adsl.duke.edu> To: Bill Manning cc: ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-Reply-To: Message from Bill Manning of "Fri, 28 Jan 2000 07:41:02 PST." <200001281541.HAA24366@zed.isi.edu> Date: Fri, 28 Jan 2000 11:35:10 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Thanks for the background data. Is this from you or from > someone else? Some of the precepts and assumptions in this > background material seem questionable, e.g. the existance > of an "overall plan", and the ability of the IETF to "sell" > the Internet to the ITU, (or anyone else for that matter). This comes from folks other than me that know more about this space. I.e., the IAB discussed this and felt sure enough about their facts to make a recommendation. I will try and get someone else to comment directly. > Migrations are lengthy and have many costs. This material > argues that we should abandon the attempts to migrate away > from the .arpa zone, which has been in process for ~15 years > and now abandon the infrastructure zone which was earmarked > by the IANA as the place to migrate to. There is actually a plan to migrate away from in-addr.arpa? > It almost seems that the IETF is attempting to co-op culpability > for potential political ramifications that rightfully are ICANNs > turf. No. The IETF is trying to avoid a potential problem that may impact the Internet. Why is it ICANN's decision what domain names we use? We choose, based on what we think our our interests. > IANA/ICANN gave us the .INT zone for infrastructure. I think what is at issue is who is "us". My understanding is that .int will go (if it is not officially so now) to ITU. IETF is not ITU. :-) > Should we turn it down because we think it might be politically > sensitive? I think this is a bit beyond IETF perview. The issue isn't whether this is politically sensitive. The issue is whether the IETF feels that there are technical or operational ramifications with continuing to use ip6.int. There would appear to be a potential issue here, so why not just remove that potential, assuming the cost is low enough? Thomas -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 08:50:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SGlfZ21905 for ipng-dist; Fri, 28 Jan 2000 08:47:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SGlXj21898 for ; Fri, 28 Jan 2000 08:47:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA21036 for ; Fri, 28 Jan 2000 08:47:32 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05070 for ; Fri, 28 Jan 2000 09:47:31 -0700 (MST) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id LAA04676; Fri, 28 Jan 2000 11:47:55 -0500 Message-Id: <200001281647.LAA04676@hygro.adsl.duke.edu> To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-Reply-To: Message from Jim Bound of "Fri, 28 Jan 2000 09:33:43 EST." <200001281433.JAA0000006143@quarry.zk3.dec.com> Date: Fri, 28 Jan 2000 11:47:55 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > You did not address the need in the interim to support IPv6.INT until > next generation products can use .arpa or whatever. The proposal on the table is to continue to use ipv6.int for the existing AAAA records. No change to shipping code in that regard. Indeed, I would expect that ip6.int wouldn't ever go away. It would just at some point stop being used, as everyone moves to A6. .arpa (or whatever it is) would be used for the NEW A6 records, or rather, for implementations that understand A6, bit string labels and the like. These have not been deployed, and the code for implementing A6 is still being finalized. (At least that is my understanding of the state of A6 implementations.) So it does seem to me that it is relatively painless to have all the A6 based stuff use .arpa while we continue to use ip6.int for the existing standards (and products). No need for a flag day. The goal of A6 is to eventually phase out AAAA once it is widely deployed. Once that happens, everyone presumably will be able to just use .arpa. > You say its minimal. Its not. We do not want to send out patches with > our first releases of Ipv6. I'm very concerned about not making changes to IPv6 at this point that impact products and deployment. That's the purpose of the thread -- evaluate whether this is feasible. My understanding of the messages that have been posted is that the change is fairly minimal. I don't understand why you think you need to send out patches in your first release, but didn't mention that in my previous note as Erik (I think) raised that exact question in a separate note. > Also continually in IPv6 trade-offs as an AD you keep saying we can > make the change the pain is minimal. Lets get this straight we are > deploying IPv6 and any change that affects shipping software is NOT > MINIMAL ANYMORE. I don't understand how this impacts shipping code. As Erik pointed out, this does not change RFC 1886 at all, which is what I presume everyone is shipping. > Besides it sounds like its really not the IETFs decision to blow > ipv6.INT away. Sure, not our decision to "blow away" ip6.int. But it IS our decision whether we choose to use the domain name. Our specs are the ones saying use "ip6.int". We can change our specs to use some other domain name. > I am already speaking offline with others and there is a political issue > here too. Sure, there is a bit of a political issue here. Please note that the concern is that political issues might someday have a real (negative) operational impact. That wouldn't be good for IPv6 deployment. If the possibility can just be removed, why not do so? > If I do not see the IETF support the issues raised by Bill Manning > and several implementors on this list we will use our own > implementors lobby with the ITU or ICANN to protect our investment. The purpose of this mail thread is to decide whether the WG wants to make this change or not. If the IETF does not support the change, of course it won't be done. > The IETF has to sometimes do what the implementors want. Of course! > And don't bullshit us. The IETF and ITU don't get along and the > IETF is very nervous about the new power of the ITU via ICANN. My take is that the IETF isn't nervous about the "new power" of the ITU. Rather, our concern is that various standards organizations (including the ITU) have discovered the internet and want to assert influence over that space precisely because that is where the action is. The IETF's view is "we are doing just fine thank you, we don't need help in areas where we have demonstrated core competency". I.e., if you want to help, just come to the IETF and go directly to our WGs. Looking at a concrete example, the IETF is now having to do a certain amount of damage control where other standards bodies are attempting to do work in areas that are clearly IETF turf. Do you want the ITU to start doing standards work on IPv6? Well, they just happen to be trying to do some work that conflicts directly with PPP over Sonet, and that we think is totally unnecessary (actually, we believe it will be harmful to the community because it sends confusing signals to the marketplace and would likely cause vendors to have to implement two different standards where one suffices). > Lets not appease any needs the IETF has by throwing a sacrifical > lamb being IPv6. IPv6 is not a "sacrificial lamb" here. If this change can be done without much pain, let's do it. If it can't, let's not. The whole point of this excercise is to eliminate a potential negative issue to IPv6 deployment. > Also I think its time the vendors started lobbying their interests > wherever to make sure the Internet infrastructure is not routed with > phone numbers etc. via ITU thought processes. The IETF is a great > STANDARDS BODY. But quite frankly the vendors and consumers have a > great interest in the Internet staying the way it is and moving forwared > into the next millenium. I don't the IETF is the org to influence and > put pressure on the political processes to cover our butts. I think we > need more powerful and connected leadership to keep our interests in > tact. Again, the entire point of the proposed change of ip6.int -> .arpa is to remove a potential political aspect from the picture. That way we won't ever have to fight a battle on this particular issue. Thomas -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 08:54:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SGrAX21924 for ipng-dist; Fri, 28 Jan 2000 08:53:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SGr1j21917 for ; Fri, 28 Jan 2000 08:53:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA02302 for ; Fri, 28 Jan 2000 08:53:01 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13096 for ; Fri, 28 Jan 2000 08:52:58 -0800 (PST) Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14998; Fri, 28 Jan 2000 08:52:51 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.8.7/8.8.6) id IAA25288; Fri, 28 Jan 2000 08:52:45 -0800 (PST) Message-Id: <200001281652.IAA25288@zed.isi.edu> Subject: Re: Use of IP6.INT To: narten@raleigh.ibm.com (Thomas Narten) Date: Fri, 28 Jan 2000 08:52:44 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200001281635.LAA04641@hygro.adsl.duke.edu> from "Thomas Narten" at Jan 28, 2000 11:35:10 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % > Migrations are lengthy and have many costs. This material % > argues that we should abandon the attempts to migrate away % > from the .arpa zone, which has been in process for ~15 years % > and now abandon the infrastructure zone which was earmarked % > by the IANA as the place to migrate to. % % There is actually a plan to migrate away from in-addr.arpa? Sure. There used to be hosts & second-level zones under the .arpa space. Most of it was emptyed out by the early/mid 90's. % > IANA/ICANN gave us the .INT zone for infrastructure. % % I think what is at issue is who is "us". My understanding is that .int % will go (if it is not officially so now) to ITU. IETF is not ITU. :-) Back in the mists of time, My memory is the 1996 IETF held w/ ISOC in Montreal, there was a discussion on where to home the inverse data for the IPv6 protocol. The IANA (Postel) thought that moving things into the INT heirarchy made the most sense and both the ip6.int and an ip4.int zones were created. There was some kickback from ISC on the difficulties in changing the installed resolver base to look in the int zone for ipv4 resolution, so in-addr.arpa is still around. Hope that clarifies the "us" part, e.g. the code developers and operators that were concerned about the issue. I think this was mentioned in at least one of the IPv6 working groups at the time, but may have been overlooked as there were still many protocol issues outstanding and this was considered too operationally mundane. You are hearing more about this very issue now from both Bob Halley and Jim Bound. As to the future of the .INT zone, your understanding and mine appear to differ. The existant reality is that .INT is under ICANN control. The future of any zone is open for debate. % > Should we turn it down because we think it might be politically % > sensitive? I think this is a bit beyond IETF perview. % % The issue isn't whether this is politically sensitive. The issue is % whether the IETF feels that there are technical or operational % ramifications with continuing to use ip6.int. There would appear to be % a potential issue here, so why not just remove that potential, assuming the % cost is low enough? There are technical, operational, and political ramifications for the use of -ANY- zone. % % Thomas % -- --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 09:12:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SHC8b22005 for ipng-dist; Fri, 28 Jan 2000 09:12:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SHBqj21994 for ; Fri, 28 Jan 2000 09:11:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA25401 for ; Fri, 28 Jan 2000 09:11:51 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23339 for ; Fri, 28 Jan 2000 09:11:41 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA18421; Fri, 28 Jan 2000 09:02:02 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200001281433.JAA0000006143@quarry.zk3.dec.com> References: <200001281433.JAA0000006143@quarry.zk3.dec.com> Date: Fri, 28 Jan 2000 09:03:01 -0800 To: Jim Bound From: Steve Deering Subject: Re: Use of IP6.INT Cc: Thomas Narten , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:33 AM -0500 1/28/00, Jim Bound wrote: >You did not address the need in the interim to support IPv6.INT until >next generation products can use .arpa or whatever. > >You say its minimal. Its not. We do not want to send out patches with >our first releases of Ipv6. Jim, I thought the proposal on the table was to move only the bitstring labels to .arpa, and that no one had shipped any code to do bitstrings yet, and that it really *would* be a trivial change to make before shipping any code to support bitstring-based reverse lookups. In which case, no post-shipping patches would be needed to make this change. Is any of that incorrect? >Lets get this straight we are deploying IPv6 and any change that >affects shipping software is NOT MINIMAL ANYMORE. Sure, but who has shipped bitstring-based software at this point? >And don't bullshit us. The IETF and ITU don't get along and the IETF is >very nervous about the new power of the ITU via ICANN. Lets not appease >any needs the IETF has by throwing a sacrifical lamb being IPv6. > >Also I think its time the vendors started lobbying their interests >wherever to make sure the Internet infrastructure is not routed with >phone numbers etc. via ITU thought processes... The purpose of this suggestion is precisely to keep this aspect of IPv6 *out* of the hands of the ITU, and to *avoid* throwing IPv6 as a sacrificial lamb to anyone. And I don't know if you noticed, but the IAB has put a lot of effort into blocking apparent attempts by others to put phone numbers into IPv6 addresses. For example, see . By the way, a couple months ago, I got a call from someone who was very concerned that the IETF was making a big mistake by deciding to base IPv6 addressing on phone numbers. When I asked him where he got that mistaken impression, he said from an Internet Draft written by Jim Bound, on how to embed NSAP addresses (or was it E.164 addresses?) into IPv6 addresses. (!) Steve -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 12:10:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SK7jQ22150 for ipng-dist; Fri, 28 Jan 2000 12:07:45 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SK7aj22143 for ; Fri, 28 Jan 2000 12:07:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA13678 for ; Fri, 28 Jan 2000 12:07:35 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27135 for ; Fri, 28 Jan 2000 12:07:34 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 0B0F8151FD6; Fri, 28 Jan 2000 14:07:33 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id E84B2148508; Fri, 28 Jan 2000 14:07:32 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id B9DB44FB02; Fri, 28 Jan 2000 14:07:25 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 4BFE34C901; Fri, 28 Jan 2000 14:07:25 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000022311; Fri, 28 Jan 2000 15:07:31 -0500 (EST) From: Jim Bound Message-Id: <200001282007.PAA0000022311@quarry.zk3.dec.com> To: Erik Nordmark Cc: bmanning@ISI.EDU, ipng@sunroof.eng.sun.com Subject: Re: RESEND: DNS IPv6.INT issue In-reply-to: Your message of "Thu, 27 Jan 2000 20:32:40 PST." Date: Fri, 28 Jan 2000 15:07:31 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, >> As I said ipv6.INT is hard coded on our implementation in the resolver >> and I would think others. I just don't want to send out a patch fix for >> IPv6 for this reason. >Does your resolver implement A6 and binary labels? Not until we release BINDv9 as you. >If not you have no reason for any concern. >We are only discussion what would make sense when A6 and binary labels >are deployed. Reverse queries will look for ipv6.int zone for AAAA records. /jim /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 13:22:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SLIsg22195 for ipng-dist; Fri, 28 Jan 2000 13:18:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SLIij22188 for ; Fri, 28 Jan 2000 13:18:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA25758 for ; Fri, 28 Jan 2000 13:18:42 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01254 for ; Fri, 28 Jan 2000 14:18:41 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA02769; Fri, 28 Jan 2000 12:58:32 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: Date: Fri, 28 Jan 2000 12:59:32 -0800 To: Jim Bound From: Steve Deering Subject: Re: Use of IP6.INT Cc: Thomas Narten , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [retransmission, since I haven't seen the first copy appear on the list since sent, 4 hours ago. -sd] At 9:33 AM -0500 1/28/00, Jim Bound wrote: >You did not address the need in the interim to support IPv6.INT until >next generation products can use .arpa or whatever. > >You say its minimal. Its not. We do not want to send out patches with >our first releases of Ipv6. Jim, I thought the proposal on the table was to move only the bitstring labels to .arpa, and that no one had shipped any code to do bitstrings yet, and that it really *would* be a trivial change to make before shipping any code to support bitstring-based reverse lookups. In which case, no post-shipping patches would be needed to make this change. Is any of that incorrect? >Lets get this straight we are deploying IPv6 and any change that >affects shipping software is NOT MINIMAL ANYMORE. Sure, but who has shipped bitstring-based software at this point? >And don't bullshit us. The IETF and ITU don't get along and the IETF is >very nervous about the new power of the ITU via ICANN. Lets not appease >any needs the IETF has by throwing a sacrifical lamb being IPv6. > >Also I think its time the vendors started lobbying their interests >wherever to make sure the Internet infrastructure is not routed with >phone numbers etc. via ITU thought processes... The purpose of this suggestion is precisely to keep this aspect of IPv6 *out* of the hands of the ITU, and to *avoid* throwing IPv6 as a sacrificial lamb to anyone. And I don't know if you noticed, but the IAB has put a lot of effort into blocking apparent attempts by others to put phone numbers into IPv6 addresses. For example, see . By the way, a couple months ago, I got a call from someone who was very concerned that the IETF was making a big mistake by deciding to base IPv6 addressing on phone numbers. When I asked him where he got that mistaken impression, he said from an Internet Draft written by Jim Bound, on how to embed NSAP addresses (or was it E.164 addresses?) into IPv6 addresses. (!) Steve -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 13:53:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SLohW22239 for ipng-dist; Fri, 28 Jan 2000 13:50:43 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SLocj22232 for ; Fri, 28 Jan 2000 13:50:38 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA15962 for ipng@sunroof.eng.sun.com; Fri, 28 Jan 2000 13:49:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SLnQj22220 for ; Fri, 28 Jan 2000 13:49:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA05002 for ; Fri, 28 Jan 2000 13:49:24 -0800 (PST) Received: from isrv3.isc.org (isrv3.isc.org [204.152.184.87]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14615 for ; Fri, 28 Jan 2000 14:49:24 -0700 (MST) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.isc.org (8.9.1/8.9.1) via ESMTP id NAA17644; Fri, 28 Jan 2000 13:49:20 -0800 (PST) env-from (Bob.Halley@iengines.com) Received: (from halley@localhost) by bb.rc.vix.com (8.9.1/8.9.1) id NAA22216; Fri, 28 Jan 2000 13:49:19 -0800 (PST) env-from (Bob.Halley@iengines.com) To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: From: Bob Halley Date: 28 Jan 2000 13:49:19 -0800 In-Reply-To: Steve Deering's message of "Fri, 28 Jan 2000 12:59:32 -0800" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > I thought the proposal on the table was to move only the bitstring > labels to .arpa, and that no one had shipped any code to do bitstrings > yet, and that it really *would* be a trivial change to make before > shipping any code to support bitstring-based reverse lookups. No one is yet, but the first beta of BIND 9 is scheduled to be out next week. BIND 9 currently looks for both the bitstring and nibble forms of the reverse address in IP6.INT. It's easy to switch to something else for bitstring labels in a future beta. I doubt there'll be so many users with bitstring label reverse domains that this would be a problem. In order to continue interoperating with sites which do not have bitstring-aware nameservers I expect that people will maintain both the nibble and bitstring forms of reverse address for some time. Because BIND 9 will search for the nibble form if it doesn't find the bitstring form, a change in the bitstring suffix shouldn't disrupt reverse lookups for sites which continue to maintain the nibble form. I don't have a position on what domain should be used for bitstrings, but I'd like the choice to be made before May, when BIND 9 is scheduled to leave beta. /Bob -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 13:57:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SLumf22279 for ipng-dist; Fri, 28 Jan 2000 13:56:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SLubj22272 for ; Fri, 28 Jan 2000 13:56:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA03467 for ; Fri, 28 Jan 2000 13:56:36 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17806 for ; Fri, 28 Jan 2000 13:56:32 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id QAA13223; Fri, 28 Jan 2000 16:56:18 -0500 (EST) Date: Fri, 28 Jan 2000 16:56:18 -0500 (EST) From: Scott Bradner Message-Id: <200001282156.QAA13223@newdev.harvard.edu> To: Bob.Halley@nominum.com, deering@cisco.com Subject: Re: Use of IP6.INT Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't have a position on what domain should be used for bitstrings, > but I'd like the choice to be made before May, when BIND 9 is > scheduled to leave beta. any way to have this something that gets pulled from a configuration file? Scott -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 14:04:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SM19p22301 for ipng-dist; Fri, 28 Jan 2000 14:01:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SM11j22294 for ; Fri, 28 Jan 2000 14:01:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA23047 for ; Fri, 28 Jan 2000 14:00:59 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19694 for ; Fri, 28 Jan 2000 15:00:58 -0700 (MST) Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id OAA26097; Fri, 28 Jan 2000 14:00:57 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.8.7/8.8.6) id OAA29376; Fri, 28 Jan 2000 14:00:51 -0800 (PST) Message-Id: <200001282200.OAA29376@zed.isi.edu> Subject: Re: Use of IP6.INT To: sob@harvard.edu (Scott Bradner) Date: Fri, 28 Jan 2000 14:00:50 -0800 (PST) Cc: Bob.Halley@nominum.com, deering@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: <200001282156.QAA13223@newdev.harvard.edu> from "Scott Bradner" at Jan 28, 2000 04:56:18 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % > I don't have a position on what domain should be used for bitstrings, % > but I'd like the choice to be made before May, when BIND 9 is % > scheduled to leave beta. % % any way to have this something that gets pulled from a configuration file? % and while your at it, can we get RR types pulled in from a config file as well? -- --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 14:04:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SM37g22310 for ipng-dist; Fri, 28 Jan 2000 14:03:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SM2tj22303 for ; Fri, 28 Jan 2000 14:02:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA23378 for ; Fri, 28 Jan 2000 14:02:53 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20604 for ; Fri, 28 Jan 2000 15:02:52 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA03962; Fri, 28 Jan 2000 16:02:43 -0600 (CST) Message-Id: <200001282202.QAA03962@gungnir.fnal.gov> To: Scott Bradner Cc: Bob.Halley@nominum.com, deering@cisco.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Use of IP6.INT In-reply-to: Your message of Fri, 28 Jan 2000 16:56:18 EST. <200001282156.QAA13223@newdev.harvard.edu> Date: Fri, 28 Jan 2000 16:02:43 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't have a position on what domain should be used for bitstrings, > > but I'd like the choice to be made before May, when BIND 9 is > > scheduled to leave beta. > > any way to have this something that gets pulled from a configuration file? That would make only a very small difference. -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 14:55:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SMqfV22371 for ipng-dist; Fri, 28 Jan 2000 14:52:41 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SMqaj22364 for ; Fri, 28 Jan 2000 14:52:36 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id OAA16005 for ipng@sunroof.eng.sun.com; Fri, 28 Jan 2000 14:51:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SMNjj22335 for ; Fri, 28 Jan 2000 14:23:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA07950 for ; Fri, 28 Jan 2000 14:23:46 -0800 (PST) Received: from ib.rc.vix.com (ib.rc.vix.com [204.152.187.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01304 for ; Fri, 28 Jan 2000 14:23:44 -0800 (PST) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by ib.rc.vix.com (8.9.1/8.9.1) via ESMTP id OAA06308; Fri, 28 Jan 2000 14:23:43 -0800 (PST) env-from (Bob.Halley@iengines.com) Received: (from halley@localhost) by bb.rc.vix.com (8.9.1/8.9.1) id OAA27871; Fri, 28 Jan 2000 14:23:43 -0800 (PST) env-from (Bob.Halley@iengines.com) To: Scott Bradner Cc: ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: <200001282156.QAA13223@newdev.harvard.edu> From: Bob Halley Date: 28 Jan 2000 14:23:43 -0800 In-Reply-To: Scott Bradner's message of "Fri, 28 Jan 2000 16:56:18 -0500 (EST)" Message-ID: Lines: 5 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott Bradner writes: > any way to have this something that gets pulled from a configuration file? It could be done, but I don't think it should be. -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 14:55:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SMr9Q22380 for ipng-dist; Fri, 28 Jan 2000 14:53:09 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SMr4j22373 for ; Fri, 28 Jan 2000 14:53:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id OAA16035 for ipng@sunroof.eng.sun.com; Fri, 28 Jan 2000 14:51:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SMU5j22347 for ; Fri, 28 Jan 2000 14:30:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA09233 for ; Fri, 28 Jan 2000 14:30:06 -0800 (PST) Received: from isrv3.isc.org (isrv3.isc.org [204.152.184.87]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04350 for ; Fri, 28 Jan 2000 14:30:04 -0800 (PST) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.isc.org (8.9.1/8.9.1) via ESMTP id OAA18523; Fri, 28 Jan 2000 14:29:37 -0800 (PST) env-from (Bob.Halley@iengines.com) Received: (from halley@localhost) by bb.rc.vix.com (8.9.1/8.9.1) id OAA27937; Fri, 28 Jan 2000 14:29:37 -0800 (PST) env-from (Bob.Halley@iengines.com) To: Bill Manning Cc: ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT References: <200001282200.OAA29376@zed.isi.edu> From: Bob Halley Date: 28 Jan 2000 14:29:37 -0800 In-Reply-To: Bill Manning's message of "Fri, 28 Jan 2000 14:00:50 -0800 (PST)" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Manning writes: > and while your at it, can we get RR types pulled in from a config > file as well? I'm not sure what you mean. Are you talking about something specific to reverse lookups, or some kind of general RR type definition grammar? If the latter, the answer is "Not in BIND 9.0.0." /Bob -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 15:35:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0SNWv422412 for ipng-dist; Fri, 28 Jan 2000 15:32:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0SNWmj22405 for ; Fri, 28 Jan 2000 15:32:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA26256 for ; Fri, 28 Jan 2000 15:32:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02399 for ; Fri, 28 Jan 2000 15:32:48 -0800 (PST) Received: from zed.isi.edu (zed-e.isi.edu [128.9.160.57]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id OAA01663; Fri, 28 Jan 2000 14:50:42 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.8.7/8.8.6) id OAA00140; Fri, 28 Jan 2000 14:50:36 -0800 (PST) Message-Id: <200001282250.OAA00140@zed.isi.edu> Subject: Re: Use of IP6.INT To: Bob.Halley@nominum.com (Bob Halley) Date: Fri, 28 Jan 2000 14:50:36 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), ipng@sunroof.eng.sun.com In-Reply-To: from "Bob Halley" at Jan 28, 2000 02:29:37 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % Bill Manning writes: % % > and while your at it, can we get RR types pulled in from a config % > file as well? % % I'm not sure what you mean. Are you talking about something specific % to reverse lookups, or some kind of general RR type definition % grammar? If the latter, the answer is "Not in BIND 9.0.0." % % /Bob % Sorry for this brief followup. I've stated my peace about the folly of abandoning the INT zone and now we have just wandered far afield from the ipng WG charter and into what was the old namedroppers turf. Its not clear where this type of thing should be discussed these days, possibly the gab list. A general RR type definition grammar as was proposed & coded by Hotz in '96/97 & independently coded by Vixie in '97. (don't know who gave him the idea, possibly pvm?) A bit easier to implement than configurable inverse lookups eh? example code is available in the perl implementation of dig. --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 17:31:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0T1Swd22492 for ipng-dist; Fri, 28 Jan 2000 17:28:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0T1Snj22485 for ; Fri, 28 Jan 2000 17:28:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA16009 for ; Fri, 28 Jan 2000 17:28:49 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22566 for ; Fri, 28 Jan 2000 17:28:43 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id 3A99D9A832; Fri, 28 Jan 2000 19:28:42 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 2F74090D82; Fri, 28 Jan 2000 19:28:42 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id F0038BC4C4; Fri, 28 Jan 2000 19:28:34 -0600 (CST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id F007BB2A42; Fri, 28 Jan 2000 19:28:32 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000016304; Fri, 28 Jan 2000 20:28:36 -0500 (EST) From: Jim Bound Message-Id: <200001290128.UAA0000016304@quarry.zk3.dec.com> To: Thomas Narten Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-reply-to: Your message of "Fri, 28 Jan 2000 11:47:55 EST." <200001281647.LAA04676@hygro.adsl.duke.edu> Date: Fri, 28 Jan 2000 20:28:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, >> You did not address the need in the interim to support IPv6.INT until >> next generation products can use .arpa or whatever. > >The proposal on the table is to continue to use ipv6.int for the >existing AAAA records. No change to shipping code in that >regard. Indeed, I would expect that ip6.int wouldn't ever go away. It >would just at some point stop being used, as everyone moves to A6. Well we can move to the new "literal" if it is to be we just need time to synch up with a release of BIND that will be using the new one. We probably should stop hardcoding this but that will take some software analysis I can't say its simplistic. >.arpa (or whatever it is) would be used for the NEW A6 records, or >rather, for implementations that understand A6, bit string labels and >the like. These have not been deployed, and the code for implementing >A6 is still being finalized. (At least that is my understanding of the >state of A6 implementations.) So it does seem to me that it is >relatively painless to have all the A6 based stuff use .arpa while we >continue to use ip6.int for the existing standards (and products). For A6 yes. >No need for a flag day. The goal of A6 is to eventually phase out AAAA >once it is widely deployed. Once that happens, everyone presumably >will be able to just use .arpa. Does that mean the Internet would host an ip6.int zone for some time? >I'm very concerned about not making changes to IPv6 at this point that >impact products and deployment. That's the purpose of the thread -- >evaluate whether this is feasible. My understanding of the messages >that have been posted is that the change is fairly minimal. I don't >understand why you think you need to send out patches in your first >release, but didn't mention that in my previous note as Erik (I think) >raised that exact question in a separate note. When an app does getnameinfo(3ffe::9) it results in a query for the nibble value of the address ip6.int. This is all hard coded in the APIs usually at the resolver. If ip6.int went away as a zone and became ip6.arpa the software would break. To fix it we would go in and change all ip6.int's to ip6.arpa and send out a patch to all users of a certain release. I don't want us or other vendors to have to do that. We need a grace period to move to ip6.arpa. But if ip6.int will not go away then that is not a problem and I agree it will just phase out. But I took the mail to say ip6.int will disappear off the Internet not just in the specs. >> Also continually in IPv6 trade-offs as an AD you keep saying we can >> make the change the pain is minimal. Lets get this straight we are >> deploying IPv6 and any change that affects shipping software is NOT >> MINIMAL ANYMORE. >I don't understand how this impacts shipping code. As Erik pointed >out, this does not change RFC 1886 at all, which is what I presume >everyone is shipping. I think I explained that above. Also I should not shoot the messenger here but your wearing the IESG hat as is Erik. It just seems around here that I don't think folks realize for some of IPv6 it cannot be a free for all change if we have deployed and built/shipped it. But I could be over-reacting I will admit. Rather do that than risk that IPv6 is ill-affected. Sorry. >> Besides it sounds like its really not the IETFs decision to blow >> ipv6.INT away. >Sure, not our decision to "blow away" ip6.int. But it IS our decision >whether we choose to use the domain name. Our specs are the ones >saying use "ip6.int". We can change our specs to use some other domain >name. Agreed. Been good if that was in the first mail. >> I am already speaking offline with others and there is a political issue >> here too. >Sure, there is a bit of a political issue here. Please note that the >concern is that political issues might someday have a real (negative) >operational impact. That wouldn't be good for IPv6 deployment. >If the possibility can just be removed, why not do so? But there is a systemic problem with the ITU and ICANN. But I agree if fixing this one is just blow it away then do it. In this case. >> And don't bullshit us. The IETF and ITU don't get along and the >> IETF is very nervous about the new power of the ITU via ICANN. >My take is that the IETF isn't nervous about the "new power" of the >ITU. Rather, our concern is that various standards organizations >(including the ITU) have discovered the internet and want to assert >influence over that space precisely because that is where the action >is. The IETF's view is "we are doing just fine thank you, we don't >need help in areas where we have demonstrated core competency". I.e., >if you want to help, just come to the IETF and go directly to our >WGs. Looking at a concrete example, the IETF is now having to do a >certain amount of damage control where other standards bodies are >attempting to do work in areas that are clearly IETF turf. Do you want >the ITU to start doing standards work on IPv6? Well, they just happen >to be trying to do some work that conflicts directly with PPP over >Sonet, and that we think is totally unnecessary (actually, we believe >it will be harmful to the community because it sends confusing signals >to the marketplace and would likely cause vendors to have to implement >two different standards where one suffices). The ITU can be dealt with but you need to use a large political hammer and right now the IETF don't have one, except the technical argument. I say you cannot win these various skirmishes with technical arguments. You have to apply extreme pressure to places that cause pain sometimes to get entities to listen. A big hammer is really good because you just have to swing it once and land it as it covers a lot of area and has a large mass. The recipient will be stunned so that the next time they do battle with you they will have respect, then your negotiating position is much better. As a user of the Internet I don't want to happen the kind of things you describe above. I think on the IAB and IESG there are some very good politicians in the ranks and can apply the tactics to win a battle with entities like the ITU or ETSI. But overall I don't believe the IESG or IAB have that skill-set as a "group". What we need maybe is a group of pitt-bull dogs under the ISOC or maybe under some supportive Govt Agency that will let the pitt-bull dogs out of their cage when an entity cannot see or won't listen to the technical arguments which are in the best interest of the Internet (that I do believe the IESG and IAB are good at if they work with the implementors when it gets to the details). regards, /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 17:51:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0T1mpU22511 for ipng-dist; Fri, 28 Jan 2000 17:48:51 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0T1mgj22504 for ; Fri, 28 Jan 2000 17:48:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA22160 for ; Fri, 28 Jan 2000 17:48:41 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA28788 for ; Fri, 28 Jan 2000 17:48:41 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id A4F061BA; Fri, 28 Jan 2000 20:48:40 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 67BA72C6; Fri, 28 Jan 2000 20:48:40 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000019317; Fri, 28 Jan 2000 20:48:39 -0500 (EST) From: Jim Bound Message-Id: <200001290148.UAA0000019317@quarry.zk3.dec.com> To: Steve Deering Cc: Jim Bound , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-reply-to: Your message of "Fri, 28 Jan 2000 09:03:01 PST." Date: Fri, 28 Jan 2000 20:48:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >I thought the proposal on the table was to move only the bitstring >labels to .arpa, and that no one had shipped any code to do bitstrings >yet, and that it really *would* be a trivial change to make before >shipping any code to support bitstring-based reverse lookups. In which >case, no post-shipping patches would be needed to make this change. >Is any of that incorrect? No. But. If ip6.int was not available as a zone to lookup nibbles it would be. I just sent more expounded mail to Thomas. You should see before this response. >And I don't know if you noticed, but the IAB has put a lot of effort into >blocking apparent attempts by others to put phone numbers into IPv6 >addresses. For example, see . Only by fiat as someone told me about it. If it was sent out as a URL for information to the community I missed that? Was it? But the letter says the "IETF community" this and "IETF community" that. I don't want to get into our old battle but when did the community agree to all this the IAB claims they do? I happen to agree with the letter. I will just stop there as I have very strong feelings that are not related to this debate on the whole IAB perception on what the "community" agreed to, and how the IAB defines community. >By the way, a couple months ago, I got a call from someone who was very >concerned that the IETF was making a big mistake by deciding to base IPv6 >addressing on phone numbers. When I asked him where he got that mistaken >impression, he said from an Internet Draft written by Jim Bound, on how >to embed NSAP addresses (or was it E.164 addresses?) into IPv6 addresses. >(!) It was E.164 (unless they were concerned about the draft to support the NSAP space slotted in RFC 2373 which should be canceled now as no one is using it) and that draft is a use of IPv6 for old Tel systems in Europe that could have used IPv6 initially for "profit" (oh yea I forgot you don't like that word :--) ) immediately. But don't worry we cannot possibly develop the necessary security infrastructure needed to pull it off and with other developments for IPv6 in Europe the window for opportunity is over IMO. Also it was brought to the IETF not to the ITU or ETSI. Also bringing this up in this context is like blaming me for bad things the white man did because I am a white alpha male. My coauthors may disagree with me above too. regards, /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 18:36:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0T2Vlo22561 for ipng-dist; Fri, 28 Jan 2000 18:31:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0T2Vcj22554 for ; Fri, 28 Jan 2000 18:31:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA07962 for ; Fri, 28 Jan 2000 18:31:31 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA02204 for ; Fri, 28 Jan 2000 19:31:31 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA25892; Fri, 28 Jan 2000 18:24:54 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200001290148.UAA0000019317@quarry.zk3.dec.com> References: <200001290148.UAA0000019317@quarry.zk3.dec.com> Date: Fri, 28 Jan 2000 18:25:53 -0800 To: Jim Bound From: Steve Deering Subject: Re: Use of IP6.INT Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:48 PM -0500 1/28/00, Jim Bound wrote: > >I thought the proposal on the table was to move only the bitstring > >labels to .arpa, and that no one had shipped any code to do bitstrings > >yet, and that it really *would* be a trivial change to make before > >shipping any code to support bitstring-based reverse lookups. In which > >case, no post-shipping patches would be needed to make this change. > >Is any of that incorrect? > >No. But. If ip6.int was not available as a zone to lookup nibbles it >would be. Yes, no one proposed moving the the nibbles out of ip6.int, or suddenly making it unavailable. Sorry that wasn't clearer. > >And I don't know if you noticed, but the IAB has put a lot of effort into > >blocking apparent attempts by others to put phone numbers into IPv6 > >addresses. For example, see . > >Only by fiat as someone told me about it. If it was sent out as a URL >for information to the community I missed that? Was it? I don't remember exactly, but I think the full text was posted to the general IETF list, as well as being installed on the IAB web pages. I'm sure Brian will correct me if I'm wrong. >But the letter says the "IETF community" this and "IETF community" that. >I don't want to get into our old battle but when did the community agree to >all this the IAB claims they do? The nomcom appoints IAB members and gives them the job of handling IETF interactions with other standards bodies (among other responsibilities). If you disagree with the way that works, it would be best to take it to the POISED list. > >By the way, a couple months ago, I got a call from someone who was very > >concerned that the IETF was making a big mistake by deciding to base IPv6 > >addressing on phone numbers. When I asked him where he got that mistaken > >impression, he said from an Internet Draft written by Jim Bound, on how > >to embed NSAP addresses (or was it E.164 addresses?) into IPv6 addresses. > >(!) > >It was E.164 (unless they were concerned about the draft to support the >NSAP space slotted in RFC 2373 which should be canceled now as no one is >using it) and that draft is a use of IPv6 for old Tel systems in Europe >that could have used IPv6 initially for "profit" (oh yea I forgot you >don't like that word :--) ) immediately. But don't worry we cannot possibly >develop the necessary security infrastructure needed to pull it off and >with other developments for IPv6 in Europe the window for opportunity is >over IMO. Also it was brought to the IETF not to the ITU or ETSI. Yes, it was precisely the fact that the proposal arose in the IETF that so alarmed the guy who called me. > Also bringing this up in this context is like blaming me for bad things >the white man did because I am a white alpha male. I wasn't trying to blame you for anything. I thought you'd be amused to know, and would enjoy the irony, that someone out there thinks *you* are the one putting phone numbers into IPv6 addresses. Steve -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 18:55:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0T2qeR22581 for ipng-dist; Fri, 28 Jan 2000 18:52:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0T2qWj22574 for ; Fri, 28 Jan 2000 18:52:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA28613 for ; Fri, 28 Jan 2000 18:52:31 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA16330 for ; Fri, 28 Jan 2000 18:52:31 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id A5F1760A; Fri, 28 Jan 2000 21:52:30 -0500 (EST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 17DB652D; Fri, 28 Jan 2000 21:52:30 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000029159; Fri, 28 Jan 2000 21:52:27 -0500 (EST) From: Jim Bound Message-Id: <200001290252.VAA0000029159@quarry.zk3.dec.com> To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-reply-to: Your message of "Fri, 28 Jan 2000 18:25:53 PST." Date: Fri, 28 Jan 2000 21:52:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >Yes, no one proposed moving the the nibbles out of ip6.int, or suddenly >making it unavailable. Sorry that wasn't clearer. It was clear to two implementors I know and it was not clear to me and another implementor offline. No problem. >The nomcom appoints IAB members and gives them the job of handling IETF >interactions with other standards bodies (among other responsibilities). >If you disagree with the way that works, it would be best to take it to >the POISED list. I think I need to explain. I support the IAB doing this. Also you can't go to the community everytime you folks got to do your job. The letters you write should say the IAB this and the IAB that not the "community" this or the "community" that. Raise the IAB to the level of the EXPERTS in the letter, as you say above you have the authority to tell them the story or whatever. Don't use the community. If you act strong you will be percieved strong. So I support your job and role and trust you. I just think you need to be more direct with them. Also I thought the letter to the RIRs on being to conservative was really good example of how all the letter in your IAB job should look like. It was direct, correct, and polite. Now kick the ITU and ETSI's butt :----) [If you want a pit bull dog call me ;---)] >Yes, it was precisely the fact that the proposal arose in the IETF that >so alarmed the guy who called me. Geeez you can't win with these folks :----) >> Also bringing this up in this context is like blaming me for bad things >>the white man did because I am a white alpha male. > >I wasn't trying to blame you for anything. I thought you'd be amused to >know, and would enjoy the irony, that someone out there thinks *you* are >the one putting phone numbers into IPv6 addresses. Sorry I am having hard time lightening up these days I am taking this Ipv6 stuff way to serious maybe.... But in hindsight it is amusing. Oh well have a good weekend, /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 19:28:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0T3Pnv22604 for ipng-dist; Fri, 28 Jan 2000 19:25:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0T3Pcj22597 for ; Fri, 28 Jan 2000 19:25:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA22074 for ; Fri, 28 Jan 2000 19:25:38 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA12977 for ; Fri, 28 Jan 2000 20:25:37 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 28 Jan 2000 19:25:36 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jan 2000 19:25:36 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712FEE@RED-MSG-02> From: Brian Zill To: ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" Cc: Dave Thaler Subject: Clarifications wanted on Basic API (RFC 2553) Date: Fri, 28 Jan 2000 19:25:34 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When implementing the basic API functions for our 1.4 release, there were a number of places where I had to guess as to what the proper behavior should be. So I'm soliciting clarifications from anyone with an opinion, especially the RFC authors, and would also like to hear what other existing implementations do. I'm primarily interested in answers to the getaddrinfo and getnameinfo questions, but I'll do this in the order they're presented in the RFC. If this whole thing is too long to wade through, please at least look at those. Section 3.10, sockaddr_storage: I believe the consensus now is to use ss_family and not __ss_family. Correct me if I'm wrong. Section 6.1, getipnodebyname: What is the namespace for error_num? Regular system error number space, or a private one? Four errors are explicitly listed (HOST_NOT_FOUND, NO_ADDRESS, NO_RECOVERY, and TRY_AGAIN). The spec doesn't say that we're supposed to define these in an include file somewhere, so I assumed that you're supposed to use the system error codes that are the closest in meaning. Is this correct? Also, the text says "error_num will be set to one of the following values" and then lists only the above four errors. Is the intent really that no other errors are acceptable? I could see returning errors for invalid arguments, things that would fault, etc. We currently return an invalid argument error if the combination of the "af" and "flags" arguments yield a name resolution lookup type we don't support. Likewise we return a fault error code if the name argument is NULL, and an out of memory error code if the system can't allocate space to hold the returned hostent structure. Is this o.k.? And is returning a fault error better than just letting the user's code fault? For this API, I think it is. The AI_ADDRCONFIG flag is supposed to indicate that a AAAA query "should occur only if the node has at least one IPv6 source address configured". I assume this definition excludes the loopback address. Does it also exclude link-local? If our stack is present on a machine with interfaces, then people will have link-local addresses even if they don't have any native IPv6 connectivity to anywhere off of their local link. But maybe the machine they issued the query for is a node on the local link... How about automatic tunneling addresses? We automatically assign one of those for every IPv4 address, so if you have an IPv4 address, you have an IPv6 address that can reach any other IPv6 enabled machine on the IPv4 Internet. And if you don't have an IPv4 address, then you're probably not issuing a getaddrinfo call with this flag set. Section 6.2 getipnodebyaddr: The same error code issue that I asked about for getipnodebyname applies here as well. Again, we return errors that aren't explicitly listed: a fault error instead of faulting if "src" is a NULL pointer, an invalid arguments error if "len" isn't the right size for the given "af", and an address family not supported error if "af" isn't one of the address families we support. Section 6.3 freehostent: I have the same question that Itojun just asked about freeaddrinfo - what to do if "ptr" is NULL? You can't return an error, so the options are to take a fault, or just ignore the call. I agree with itojun that you should take the fault -- this is a good way to get the programmer's attention that there is something wrong with their code. Changing the call to return an error code doesn't strike me as any better than just silently ignoring a NULL ptr since far too many programmers don't bother to check return values from calls like this. Section 6.4 freeaddrinfo: Exact same issue as for freehostent. Section 6.4 getaddrinfo: The spec is explicit about getaddrinfo having its own error code namespace and what the various EAI_* error codes are. It's not always clear about which one to use in certain situations, however. For example, EAI_SERVICE means "servname not supported for ai_socktype". But there's also EAI_NONAME for "nodename nor servname provided, or not known". So what to return if someone gives you a service name that isn't valid for the requested socket type? Am I actually expected to look up the service name for all other socket types just so I can return EAI_SERVICE if it exists and EAI_NONAME if it doesn't? Also, the spec says that in the "hints" structure, "all members other than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL pointer". Okay, but what error code do I return if they aren't? None really seem to apply, so currently I'm returning EAI_FAIL. The existence of the EAI_BADFLAGS error implies that there is a combination of input parameters that would warrant such a return value. Am I really supposed to return this if I see a flag I don't recognize? That would make it hard to introduce new flags in the future as new programs requesting the new flag would fail on old systems. So I don't do that. The precise meaning of the AI_CANONNAME flag is unclear to me. It says that if this flag is set, then upon return, the first addrinfo struct's ai_canonname field will point to "a null terminated string containing the canonical name of the specified nodename". Someone define canonical name for me please. Is this supposed to be the fully qualified domain name for the host that, in DNS parlance, you get if you follow all the alias pointers? But what if someone passes in an IPv6 address literal into getaddrinfo when this flag is set? Am I supposed to do a reverse address lookup just to fill in the ai_canonname field? I'm thinking yes, although I currently don't do that. But what if AI_NUMERICHOST is also set? The text describing AI_NUMERICHOST states "this flag prevents any type of name resolution service from being called", so I'd think I couldn't perform a reverse address lookup in that case. Or maybe I can -- does "any type of name resolution service" include looking in /etc/hosts or a local cache of previous DNS lookups? If the only reason to avoid a "name resolution service" is to prevent the delay of hitting the DNS or equivalent, then that might be o.k. If it really means that one is forbidden from finding some sort of "canonical name" (I assume an address literal doesn't qualify) by any means, does this make it illegal to set both the AI_CANONNAME and AI_NUMERICHOST flags? Currently I return EAI_BADFLAGS in this case -- hey, a use for that error code after all! What am I supposed to do if in the "hints" structure, someone passes in a value for ai_socktype that is at odds with ai_protocol? (e.g. SOCK_STREAM with UDP). Is getaddrinfo supposed to check if the particular triple of address family, socket type, and protocol is supported on the system? The existence of the EAI_ADDRFAMILY error implies that just checking that the address family is supported is enough (which is all I currently do). Likewise, the spec isn't clear about whether one should use the value in ai_socktype or ai_protocol when performing protocol specific service lookups. The actual port number to name mappings appear to be assigned via protocol (specifically, UDP and TCP). But the EAI_SERVICE error code says "servname not supported for ai_socktype", it doesn't say "for ai_protocol". The spec appears to assume that SOCK_STREAM means TCP and vice-versa, and SOCK_DGRAM means UDP and vice-versa. Consider this line "if the caller handles only TCP and not UDP, then the ai_socktype member of the hints structure should be set to SOCK_STREAM" -- instead of saying that ai_protocol should be set to IP_PROTOCOL_TCP. Currently, I use ai_socktype with hardwired mappings from SOCK_STREAM to TCP and SOCK_DGRAM to UDP to perform the service lookup, and only use ai_protocol to know what to set the ai_protocol field in the returned addrinfo structures to. I do it this way, because in my experience, programmers typically leave the protocol value unspecified in socket() calls, instead choosing to specify the socket type. In the returned addrinfo structures, the spec is silent on what the ai_flags field should be. I can think of two possibilities: zero, or whatever was passed into getaddrinfo in the ai_flags field of the hints structure. Currently, I always return zero in this field. Section 6.5 getnameinfo: The spec says "the salen argument gives the length of the sockaddr_in or sockaddr_in6 structure". An overly pedantic member of our team (ok, it was Rich :-) thinks this means that salen must exactly equal the length of a sockaddr_in if sa->sa_family == AF_INET or it must exactly equal the length of a sockaddr_in6 if sa->sa_family == AF_INET6 (i.e. just insisting salen is large enough to hold a sockaddr of the appropriate type isn't good enough, it must be exactly the right size). The rest of us disagree, because that would mean that you can't call getnameinfo with a pointer to a struct sockaddr_storage and salen set to sizeof(struct sockaddr_storage). Losing that capability loses a lot of the address independence feature that makes getnameinfo so nice in the first place. We'd really like to be able to perform a getpeername call, with the result going into a sockaddr_storage, and then be able to just pass that to getnameinfo to find out who we're talking to without having to add any address family specific code. The spec doesn't say anything about the error code namespace, so I used the regular system one. Section 6.6 inet_pton: Should we check if "src" and/or "dst" is a NULL pointer and return an error (0?) if so? Or just let it fault? For "dst", the spec says that the buffer it points to must be large enough to hold the expected result, so if we treat a NULL pointer like any other too-small buffer, faulting would seem appropriate. For "src" though, it would seem returning 0 (for an invalid input string) would be appropriate. Section 6.6 inet_ntop: Here the spec says that "dst" must be non-NULL, but doesn't say what error to set if it isn't. However, ENOSPC is what is supposed to be set if the size of the buffer "dst" points to is inadequate. So would that apply, should it be EFAULT, or should we just let it fault? The spec doesn't say anything about what to do if "src" is NULL. Options appear to be to set EFAULT and return NULL, or just let it fault. The spec doesn't say anything about the error code namespace, although the names appear to be Unix system error codes (strangely different approach than the generic names used in Section 6.1 and 6.2 -- presumably different authors), so I used the regular system one. Well, that's about it, --Brian -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 21:44:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0T5fq122725 for ipng-dist; Fri, 28 Jan 2000 21:41:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0T5fgj22718 for ; Fri, 28 Jan 2000 21:41:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA07659 for ; Fri, 28 Jan 2000 21:41:40 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA06033 for ; Fri, 28 Jan 2000 22:41:38 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.02) with ESMTP id OAA05961; Sat, 29 Jan 2000 14:41:32 +0900 (JST) To: Brian Zill cc: ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler In-reply-to: bzill's message of Fri, 28 Jan 2000 19:25:34 PST. <3D2036E25376D31197A100805FEAD892712FEE@RED-MSG-02> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Clarifications wanted on Basic API (RFC 2553) From: itojun@iijlab.net Date: Sat, 29 Jan 2000 14:41:32 +0900 Message-ID: <5959.949124492@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are couple of additions to brian (zill)'s. I agree with brian's comment where I don't quote/comment in the following. >Section 3.10, sockaddr_storage: >I believe the consensus now is to use ss_family and not __ss_family. >Correct me if I'm wrong. This is correct, ss_family was the consensus of the most recent discussion. X/Open spec uses ss_family already. >Section 6.4 getaddrinfo: (addition) When host == NULL, loopback addresses and/or wildcard addresses will be returned. At this moment KAME getaddrinfo returns all the loopback/wildcard address in address family supported by the kernel. For example, if you are on top of IPv6-only kernel, getaddrinfo will return :: or ::1. If you are on dual-stack, getaddrinfo will return :: and 0.0.0.0, or ::1 and 127.0.0.1. Is the behavior okay? (addition) interaction of NI_NUMERICxxx with AF_LOCAL (AF_UNIX), or other address families where hostname/servname cannot become decimal/hexadecimal digits. (Hideaki YOSHIFUJI pointed this out around Jan 19, 2000) >The precise meaning of the AI_CANONNAME flag is unclear to me. It says >that if this flag is set, then upon return, the first addrinfo struct's >ai_canonname field will point to "a null terminated string containing the >canonical name of the specified nodename". Someone define canonical name >for me please. (just additional datapoint) KAME code copies hp->h_name returned from getipnodebyname(), or gethostbyname(). Not sure if this is the right answer to "canonical name". Things gets tricky as - KAME getaddrinfo calls name resolution twice, once for IPv4 and once for IPv6 - and hp->h_name can be different each time. so KAME code puts ai_canonname for every addrinfo entries, if AI_CANONNAME is given. >What am I supposed to do if in the "hints" structure, someone passes in a >value for ai_socktype that is at odds with ai_protocol? (e.g. SOCK_STREAM >with UDP). Is getaddrinfo supposed to check if the particular triple of >address family, socket type, and protocol is supported on the system? The >existence of the EAI_ADDRFAMILY error implies that just checking that the >address family is supported is enough (which is all I currently do). (similar to the above) The spec does not say how far we need to "glob" the input. When KAME getaddrinfo is called with the following parameter: host = "foo.internet.host" serv = "daytime" hints.ai_family = PF_UNSPEC hints.ai_socktype = hints.ai_protocol = 0 the code would return the following four entries: AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP AF_INET, port 13, SOCK_DGRAM, IPPROTO_UDP AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP AF_INET6, port 13, SOCK_DGRAM, IPPROTO_UDP Past KAME code returned SOCK_STREAM only (2 entries), like: AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP Which behavior the spec prefer? (addition) is SOCK_RAW allowed in hints.ai_socktype? this is very useful when we write "ping" which is less-dependent to AF (hints.ai_protocol is opaque in this case). >Section 6.5 getnameinfo: (addition) It is not 100% clear how the code should behave when a short buffer is passed. RFC2553 seems to me to raise error. X/Open says to truncate the result and success. The most recent ipngwg discussion preferred RFC2553 (error), if I remember correctly. >Section 6.5 getnameinfo: >it must be exactly the right size). The rest of us disagree, because that >would mean that you can't call getnameinfo with a pointer to a struct >sockaddr_storage and salen set to sizeof(struct sockaddr_storage). Losing >that capability loses a lot of the address independence feature that makes >getnameinfo so nice in the first place. We'd really like to be able to >perform a getpeername call, with the result going into a sockaddr_storage, >and then be able to just pass that to getnameinfo to find out who we're >talking to without having to add any address family specific code. (comment to brian's) by the time you call getnameinfo(), you should have done something like getpeername(sock, &ss, &sslen); and you have the exact length (like sizeof(sockaddr_in)) in sslen. you are not passing sizeof(sockaddr_storage) in 2nd arg in this case. getnameinfo(&ss, sslen, ...) or, if you have sa_len field, this should be okay: getnameinfo(&ss, ss.ss_len, ...) >The spec doesn't say anything about the error code namespace, so I used the >regular system one. KAME code defined NI_xxx and uses them. itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 28 23:49:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0T7ksJ22761 for ipng-dist; Fri, 28 Jan 2000 23:46:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0T7kij22754 for ; Fri, 28 Jan 2000 23:46:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA12967 for ; Fri, 28 Jan 2000 23:46:44 -0800 (PST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA24302 for ; Sat, 29 Jan 2000 00:46:44 -0700 (MST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id XAA14332; Fri, 28 Jan 2000 23:43:50 -0800 (PST) From: Bill Manning Message-Id: <200001290743.XAA14332@zephyr.isi.edu> Subject: Re: Use of IP6.INT To: bound@zk3.dec.com (Jim Bound) Date: Fri, 28 Jan 2000 23:43:50 -0800 (PST) Cc: narten@raleigh.ibm.com (Thomas Narten), bound@zk3.dec.com (Jim Bound), ipng@sunroof.eng.sun.com In-Reply-To: <200001290128.UAA0000016304@quarry.zk3.dec.com> from "Jim Bound" at Jan 28, 2000 08:28:36 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % Hi Thomas, % % >> You did not address the need in the interim to support IPv6.INT until % >> next generation products can use .arpa or whatever. % > % >The proposal on the table is to continue to use ipv6.int for the % >existing AAAA records. No change to shipping code in that % >regard. Indeed, I would expect that ip6.int wouldn't ever go away. It % >would just at some point stop being used, as everyone moves to A6. % % Well we can move to the new "literal" if it is to be we just need time to % synch up with a release of BIND that will be using the new one. We % probably should stop hardcoding this but that will take some software % analysis I can't say its simplistic. So technically it can be done, if there is coordination between all parties. I still don't have a good feeling as to -why- the IAB thinks this is worth the effort unless ICANN has announced it will transition the .INT zone to ITU. Doing this simply because it -might- look better does not argue that .arpa. is better. Will the IAB state with assurity that DARPA will never want its zone back? I'd really like a reading on this from the ICANN staff before we get too far down the path of, 'ah, I guess that the IAB thinks this is the best place to home the zones... this year.' We (operations and developers) were pointed into the .INT zone by the IANA as a way to vacate the .ARPA zone. I think we should get some direct comment from them. % Does that mean the Internet would host an ip6.int zone for some time? Yes. One more legacy point for inverse lookup. Jumping to a third w/o an active plan to migrate away is asking for a decade plus of using the ip6.int zone anyway, regardless of where it sits. % I don't want us or other vendors to have to do that. We need a % grace period to move to ip6.arpa. % But if ip6.int will not go away then that is not a problem and I agree % it will just phase out. % But I took the mail to say ip6.int will disappear off the Internet not % just in the specs. Thats the perceived threat. The ITU will get the .INT zone and not respect grandfathered delegations. I really want the IAB to back this assertion with a statement by the IANA that they are going to hand the .INT zone to ITU and a statement that DARPA will quit-claim on the .arpa. zone for the IABs use before we wander too far down the path of fabricating alternate solutions. Just "phasing out" will take a very long time. % >Sure, not our decision to "blow away" ip6.int. But it IS our decision % >whether we choose to use the domain name. Our specs are the ones % >saying use "ip6.int". We can change our specs to use some other domain % >name. But why should we? % The ITU can be dealt with but you need to use a large political hammer % and right now the IETF don't have one, except the technical argument. I % say you cannot win these various skirmishes with technical arguments. Since we were told by the IANA that ip6.int is/was ok, I wonder why the IAB has decided that its not OK and we as operators and developers should start second guessing IANA and believe them on a potential political debate? % regards, % /jim -- --bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 29 04:10:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0TC5hl22928 for ipng-dist; Sat, 29 Jan 2000 04:05:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0TC5Wj22921 for ; Sat, 29 Jan 2000 04:05:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA14123 for ; Sat, 29 Jan 2000 04:05:30 -0800 (PST) Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04275 for ; Sat, 29 Jan 2000 04:05:29 -0800 (PST) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id MAA00567; Sat, 29 Jan 2000 12:04:57 GMT Message-Id: <200001291204.MAA00567@orchard.arlington.ma.us> To: Bob Halley cc: Scott Bradner , ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-Reply-To: Message from Bob Halley of "28 Jan 2000 14:23:43 PST." Date: Sat, 29 Jan 2000 07:04:56 -0500 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It could be done, but I don't think it should be. Actually, given the interactions between dnssec, the inverse lookup tree, and v6 site-local addresses, it might be cleaner if it was configurable if you want the inverse tree secured in a meaningful way.. (but that's another can of worms..) - Bill -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 29 05:16:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0TD6YT22968 for ipng-dist; Sat, 29 Jan 2000 05:06:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0TD6Lj22961 for ; Sat, 29 Jan 2000 05:06:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA21574 for ; Sat, 29 Jan 2000 05:06:19 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28419 for ; Sat, 29 Jan 2000 06:06:18 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id NAA23274; Sat, 29 Jan 2000 13:56:02 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id NAA12242; Sat, 29 Jan 2000 13:55:58 +0100 (MET) Message-Id: <200001291255.NAA12242@givry.inria.fr> From: Francis Dupont To: Brian Zill cc: ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-reply-to: Your message of Fri, 28 Jan 2000 19:25:34 PST. <3D2036E25376D31197A100805FEAD892712FEE@RED-MSG-02> Date: Sat, 29 Jan 2000 13:55:43 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: When implementing the basic API functions for our 1.4 release, there were a number of places where I had to guess as to what the proper behavior should be. => some of your questions have answer in any Unix socket support (RFC 2553 is for this kind of systems then assume you have one, of course Winsocks are different). Section 6.1, getipnodebyname: What is the namespace for error_num? => same than for old gethostbyname, a private one defined in /usr/include/netdb.h as below: /* * Error return codes from gethostbyname() and gethostbyaddr() * (left in extern int h_errno). */ #define NETDB_INTERNAL -1 /* see errno */ #define NETDB_SUCCESS 0 /* no problem */ #define HOST_NOT_FOUND 1 /* Authoritative Answer Host not found */ #define TRY_AGAIN 2 /* Non-Authoritative Host not found, or SERVERFAIL */ #define NO_RECOVERY 3 /* Non recoverable errors, FORMERR, REFUSED, NOTIMP */ #define NO_DATA 4 /* Valid name, no data record of requested type */ #define NO_ADDRESS NO_DATA /* no address, look for MX record */ The AI_ADDRCONFIG flag is supposed to indicate that a AAAA query "should occur only if the node has at least one IPv6 source address configured". I assume this definition excludes the loopback address. => this has been discussed in the mailing list (we'd like to have more precisions in the future RFC). Section 6.4 getaddrinfo: For example, EAI_SERVICE means "servname not supported for ai_socktype". => I believe this error code is for service name is valid but not for this socket type, for instance if you ask for "tftp" with SOCK_STREAM/tcp socket type. Someone define canonical name for me please. => this is a standard DNS notion. A not canonical name can only appear as the left part of a CNAME RR, other names are canonical and MUST NOT appear as the left part of a CNAME RR. Many softwares pick a name as the canonical one when there are more than one PTR RR for an address but this is not a standardized extension. Is this supposed to be the fully qualified domain name for the host that, in DNS parlance, you get if you follow all the alias pointers? => names are FQDN (others are garbage :-). You are supposed to support a (short) alias (aka CNAME RR) chain but they are forbiden. But what if someone passes in an IPv6 address literal into getaddrinfo when this flag is set? Am I supposed to do a reverse address lookup just to fill in the ai_canonname field? I'm thinking yes, although I currently don't do that. => I agree (same reasoning and same implementation, ie. literals go into the canonical name field :-). If it really means that one is forbidden from finding some sort of "canonical name" (I assume an address literal doesn't qualify) by any means, does this make it illegal to set both the AI_CANONNAME and AI_NUMERICHOST flags? => I agree, both flags should be exclusive. Likewise, the spec isn't clear about whether one should use the value in ai_socktype or ai_protocol when performing protocol specific service lookups. => I agree but without a common counter-example is this a real issue? As you said programmers usually set only the socket type then the current spec is doing just we expect... Section 6.5 getnameinfo: The spec says "the salen argument gives the length of the sockaddr_in or sockaddr_in6 structure". An overly pedantic member of our team (ok, it was Rich :-) thinks this means that salen must exactly equal the length of a sockaddr_in if sa->sa_family == AF_INET or it must exactly equal the length of a sockaddr_in6 if sa->sa_family == AF_INET6 (i.e. just insisting salen is large enough to hold a sockaddr of the appropriate type isn't good enough, it must be exactly the right size). => I have no trouble with this because 4.4BSDs just copy sa->sa_len into salen (sa is the main argument)... (another reason to have socket structure length! :-) My proposal is "do what you want and leave the spec as it is". The spec doesn't say anything about the error code namespace, so I used the regular system one. => me and KAME use a ENI_ private space (cloned from EAI_ one). The spec doesn't say anything about the error code namespace, although the names appear to be Unix system error codes (strangely different approach than the generic names used in Section 6.1 and 6.2 -- presumably different authors), => yes, inet_pton/ntop are inherited by an old attempt by Paul Vixie to get family independent functions which deal with literals. Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 29 10:03:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0TI0Y023045 for ipng-dist; Sat, 29 Jan 2000 10:00:34 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0TI0Pj23038 for ; Sat, 29 Jan 2000 10:00:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA21406 for ; Sat, 29 Jan 2000 10:00:24 -0800 (PST) Received: from [207.160.210.253] (mail.nwmissouri.edu [198.209.246.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA06287 for ; Sat, 29 Jan 2000 11:00:23 -0700 (MST) Received: from mail.nwmissouri.edu by [207.160.210.253] via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 29 Jan 2000 15:01:05 UT Received: by mail.nwmissouri.edu with Internet Mail Service (5.5.2650.21) id ; Sat, 29 Jan 2000 11:59:31 -0600 Message-ID: <153B8DF8770CD211AB0A0000F8257DD801C2CDA9@mail.nwmissouri.edu> From: "Elliott,Daniel" To: "'Francis Dupont '" , "'Brian Zill '" Cc: "'ipng@sunroof.eng.sun.com '" , "''gilligan@freegate.com' '" , "''set@thumper.bellcore.com' '" , "''Jim Bound' '" , "'Dave Thaler '" Subject: RE: Clarifications wanted on Basic API (RFC 2553) Date: Sat, 29 Jan 2000 11:59:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Sir or Madam: I made the terrible mistake of getting on the mailing list, that you all are on. I NEED OFF! All i wanted was a good source for less in-depth information on IPv6. If this doesn't take care of it, as i am sure that i won't then please direct me to where i need to go. Thanks and sorry for the annoyance. Dan Elliott -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jan 29 19:37:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0U3ZIb23304 for ipng-dist; Sat, 29 Jan 2000 19:35:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0U3Z9j23297 for ; Sat, 29 Jan 2000 19:35:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA15708 for ; Sat, 29 Jan 2000 19:35:09 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA16353 for ; Sat, 29 Jan 2000 19:35:08 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id E51A057832; Sat, 29 Jan 2000 21:34:58 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id BB98F54601; Sat, 29 Jan 2000 21:34:58 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 9A0EE4FB04; Sat, 29 Jan 2000 21:34:51 -0600 (CST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 35F5E4C901; Sat, 29 Jan 2000 21:34:51 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000023592; Sat, 29 Jan 2000 22:34:57 -0500 (EST) From: Jim Bound Message-Id: <200001300334.WAA0000023592@quarry.zk3.dec.com> To: Bill Manning Cc: narten@raleigh.ibm.com (Thomas Narten), ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-reply-to: Your message of "Fri, 28 Jan 2000 23:43:50 PST." <200001290743.XAA14332@zephyr.isi.edu> Date: Sat, 29 Jan 2000 22:34:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All good points bill. /jim -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 30 19:23:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0V3KCl23956 for ipng-dist; Sun, 30 Jan 2000 19:20:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0V3K1j23949 for ; Sun, 30 Jan 2000 19:20:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA29307 for ; Sun, 30 Jan 2000 19:20:00 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA03265 for ; Sun, 30 Jan 2000 20:20:00 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 30 Jan 2000 19:19:25 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Sun, 30 Jan 2000 19:19:24 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712FF0@RED-MSG-02> From: Brian Zill To: "'itojun@iijlab.net'" Cc: ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler Subject: RE: Clarifications wanted on Basic API (RFC 2553) Date: Sun, 30 Jan 2000 19:19:23 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Itojun, for the detailed reply! Comments below... > >Section 6.4 getaddrinfo: > > addition) > When host == NULL, loopback addresses and/or > wildcard addresses will be returned. At this > moment KAME getaddrinfo returns all the > loopback/wildcard address in address family > supported by the kernel. For example, if you > are on top of IPv6-only kernel, getaddrinfo will > return :: or ::1. If you are on dual-stack, > getaddrinfo will return :: and 0.0.0.0, or ::1 > and 127.0.0.1. Is the behavior okay? If there are no hints, or ai_family == PF_UNSPEC, then we do the exact same thing (v6 address in first record, v4 address in the second). Although we currently assume you're on a dual-stack and always return both instead of checking which stacks are available, we need to fix that. > (just additional datapoint) > KAME code copies hp->h_name returned from > getipnodebyname(), or gethostbyname(). Not sure > if this is the right answer to "canonical > name". Things gets tricky as > - KAME getaddrinfo calls name resolution twice, once > for IPv4 and once for IPv6 - and hp->h_name can be > different each time. Ohhh, good point. We currently return the name associated with the first successful query, and don't check to see if the name is different for later queries. Like you, we also issue separate A and AAAA queries since we were seeing broken DNS implementations out on the Internet -- some DNS servers would respond to queries for type ANY with just the cached result from an earlier A query, thus losing any other records (like AAAA) that a real ANY query would return. Has anyone else seen this? I think this is a potential problem for v4 to v6 transition since it slows down name lookup for v4 hosts on machines that are v6 enabled (since you have to wait for the v6 lookup to fail). > so KAME code puts ai_canonname for every addrinfo > entries, if AI_CANONNAME is given. We could do that, I suppose. Right now we only put it in the first one. > >Is getaddrinfo supposed to check if the particular > >triple of address family, socket type, and protocol > >is supported on the system? The existence of the > >EAI_ADDRFAMILY error implies that just checking that > >the address family is supported is enough (which is > >all I currently do). > > (similar to the above) > The spec does not say how far we need to "glob" the input. > When KAME getaddrinfo is called with the following parameter: > host = "foo.internet.host" > serv = "daytime" > hints.ai_family = PF_UNSPEC > hints.ai_socktype = hints.ai_protocol = 0 > the code would return the following four entries: > AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET, port 13, SOCK_DGRAM, IPPROTO_UDP > AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET6, port 13, SOCK_DGRAM, IPPROTO_UDP > Past KAME code returned SOCK_STREAM only (2 entries), like: > AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP > AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP > Which behavior the spec prefer? We don't do either of those. You're right, the spec isn't clear here at all and we're doing quite different things. For your example (assuming foo.internet.host resolves to both a v4 and a v6 address) we'll return two entries: AF_INET, port 13, socktype 0, protocol 0 AF_INET6, port 13, socktype 0, protocol 0 My feeling was that addrinfo isn't responsible for checking supported triples, so we should treat someone calling addrinfo with an unspecified socket type and/or protocol the same way as the socket call does (and if our caller passes the addrinfo output directly to socket(), then they will get whatever that behavior is). However, if ai_socktype is unspecified, and there is a service name lookup, then I will perform a service lookup using both types and if one fails, I will set ai_socktype to be the one that worked. If both succeed but yield different port numbers, I return the one for TCP and set ai_socktype to be SOCK_STREAM. Otherwise, I return the unspecified ai_socktype. As for ai_protocol, I always blindly pass out whatever I was given (or zero if it was left unspecified in the hints). > (addition) > is SOCK_RAW allowed in hints.ai_socktype? this > is very useful when we write "ping" which is > less-dependent to AF (hints.ai_protocol is > opaque in this case). Good point. We don't currently allow SOCK_RAW. > >Section 6.5 getnameinfo: > > (addition) > It is not 100% clear how the code should behave > when a short buffer is passed. RFC2553 seems to > me to raise error. X/Open says to truncate the > result and success. The most recent ipngwg > discussion preferred RFC2553 (error), > if I remember correctly. We return an error. The "truncate and return success" behavior seems very dangerous to me. > >Section 6.5 getnameinfo: > >We'd really like to be able to perform a getpeername > >call, with the result going into a sockaddr_storage, > >and then be able to just pass that to getnameinfo to > >find out who we're talking to without having to add > >any address family specific code. > > (comment to brian's) > by the time you call getnameinfo(), you should have > done something like > getpeername(sock, &ss, &sslen); > and you have the exact length (like sizeof(sockaddr_in)) > in sslen. you are not passing sizeof(sockaddr_storage) > in 2nd arg in this case. Good point. I should have thought of that. Just out of curiosity, do you require it to be the exact size, or just that it is big enough to hold a sockaddr of the appropriate type? And does KAME use 4.4 style sockaddrs with the socket length field, or the 4.3 style? > >The spec doesn't say anything about the error code > >namespace, so I used the regular system one. > > KAME code defined NI_xxx and uses them. Francis also mentioned in his reply that he uses this same ENI_xxx namespace. Is this something that other implementations do, or just you two? If there is consensus on this in the working group, it'd be nice to get it into the spec. > > itojun > Thanks again, --Brian -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 30 19:54:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0V3qOd23985 for ipng-dist; Sun, 30 Jan 2000 19:52:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0V3qDj23978 for ; Sun, 30 Jan 2000 19:52:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA15807 for ; Sun, 30 Jan 2000 19:52:12 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA08790 for ; Sun, 30 Jan 2000 20:52:12 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 30 Jan 2000 19:52:07 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Sun, 30 Jan 2000 19:52:06 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712FF1@RED-MSG-02> From: Brian Zill To: "'Francis Dupont'" Cc: ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler Subject: RE: Clarifications wanted on Basic API (RFC 2553) Date: Sun, 30 Jan 2000 19:51:56 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, > Section 6.1, getipnodebyname: > What is the namespace for error_num? > > => same than for old gethostbyname, a private one > defined in /usr/include/netdb.h as below: Ah yes, I forgot. The Winsock spec folds these into a systemish error space along with other unix errno style codes. > Section 6.4 getaddrinfo: > For example, EAI_SERVICE means "servname not > supported for ai_socktype". > > => I believe this error code is for service name is > valid but not for this socket type, for instance if > you ask for "tftp" with SOCK_STREAM/tcp socket type. Yes, but what if I ask for some service "foo" with SOCK_STREAM/tcp socktype/protocol and it fails? Do I then have to lookup "foo" for all other socktypes/protocols just so I know that it isn't supported for SOCK_STREAM/tcp in particular and not that it's simply an unknown service name? The existance of a separate EAI_SERVICE error code from the EAI_NONAME error code implies this, but that strikes me as somewhat bizarre. I don't do the extra lookup today, if you asked using a specific socktype I'll return EAI_SERVICE, otherwise I return EAI_NONAME. Thus I may return EAI_SERVICE for a service name that is not supported for _any_ socktype, is this o.k.? It looks like we mostly agree on the rest of it. > Regards > > Francis.Dupont@inria.fr Thanks, --Brian -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 30 20:20:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0V4IXN24016 for ipng-dist; Sun, 30 Jan 2000 20:18:33 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0V4ILj24009 for ; Sun, 30 Jan 2000 20:18:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA17000 for ; Sun, 30 Jan 2000 20:18:16 -0800 (PST) Received: from lychee.itojun.org (dhcp108.iijlab.net [202.232.15.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA13838 for ; Sun, 30 Jan 2000 21:18:13 -0700 (MST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA15889; Mon, 31 Jan 2000 13:17:55 +0900 (JST) To: Brian Zill cc: ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler In-reply-to: bzill's message of Sun, 30 Jan 2000 19:19:23 PST. <3D2036E25376D31197A100805FEAD892712FF0@RED-MSG-02> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Clarifications wanted on Basic API (RFC 2553) From: Jun-ichiro itojun Hagino Date: Mon, 31 Jan 2000 13:17:55 +0900 Message-ID: <15887.949292275@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> so KAME code puts ai_canonname for every addrinfo >> entries, if AI_CANONNAME is given. >We could do that, I suppose. Right now we only put it in the first one. We still need the definition of "canonical name", or some reference to genuine document. Francis ciarified it a bit, but I'm still not sure what should I put to ai_canonname against getaddrinfo("ftp.kame.net"), while having the following records on DNS. I agree this is not a good example (maybe incorrectly configured), but we somehow need to fill in ai_canonname field. ftp.kame.net. 1H IN A 203.178.141.212 ftp.kame.net. 1H IN AAAA 3ffe:501:4819:2000:5254:ff:fedc:50d2 kame212.kame.net. 1H IN AAAA 3ffe:501:4819:2000:5254:ff:fedc:50d2 kame212.kame.net. 1H IN A 203.178.141.212 212.141.178.203.in-addr.arpa. 1D IN PTR kame212.kame.net. pine.v6.kame.net. 1H IN AAAA 3ffe:501:4819:2000:5254:ff:fedc:50d2 2.d.0.5.c.d.e.f.f.f.0.0.4.5.2.5.0.0.0.2.9.1.8.4.1.0.5.0.e.f.f.3.ip6.int. 1H IN PTR pine.v6.kame.net. KAME getaddrinfo would return the following two records, because gethostbyname2 returns them in hp->h_name: ai_addr: 3ffe:501:4819:2000:5254:ff:fedc:50d2 ai_canonname: "pine.v6.kame.net" ai_addr: 203.178.141.212 ai_canonname: "kame212.kame.net" (getaddrinfo globbing) >We don't do either of those. You're right, the spec isn't clear here at all >and we're doing quite different things. For your example (assuming >foo.internet.host resolves to both a v4 and a v6 address) we'll return two >entries: > AF_INET, port 13, socktype 0, protocol 0 > AF_INET6, port 13, socktype 0, protocol 0 >My feeling was that addrinfo isn't responsible for checking supported >triples, so we should treat someone calling addrinfo with an unspecified >socket type and/or protocol the same way as the socket call does (and if our >caller passes the addrinfo output directly to socket(), then they will get >whatever that behavior is). However, if ai_socktype is unspecified, and >there is a service name lookup, then I will perform a service lookup using >both types and if one fails, I will set ai_socktype to be the one that >worked. If both succeed but yield different port numbers, I return the one >for TCP and set ai_socktype to be SOCK_STREAM. Otherwise, I return the >unspecified ai_socktype. As for ai_protocol, I always blindly pass out >whatever I was given (or zero if it was left unspecified in the hints). I see, I think it is fair to leave ai_protocol opaque. That will simplify the code a bit. >> (addition) >> is SOCK_RAW allowed in hints.ai_socktype? this >> is very useful when we write "ping" which is >> less-dependent to AF (hints.ai_protocol is >> opaque in this case). >Good point. We don't currently allow SOCK_RAW. 4.4BSD has more socktypes, SOCK_RDM and SOCK_SEQPACKET in sys/socket.h. I'm not sure what should I do against them. >> by the time you call getnameinfo(), you should have >> done something like >> getpeername(sock, &ss, &sslen); >> and you have the exact length (like sizeof(sockaddr_in)) >> in sslen. you are not passing sizeof(sockaddr_storage) >> in 2nd arg in this case. >Good point. I should have thought of that. Just out of curiosity, do you >require it to be the exact size, or just that it is big enough to hold a >sockaddr of the appropriate type? And does KAME use 4.4 style sockaddrs >with the socket length field, or the 4.3 style? *BSD uses 4.4 style sockaddr (with sa_len), so KAME obeys it. KAME getaddrinfo requires salen (2nd arg to getnameinfo) to be the same as sa_len. >> >The spec doesn't say anything about the error code >> >namespace, so I used the regular system one. >> KAME code defined NI_xxx and uses them. >Francis also mentioned in his reply that he uses this same ENI_xxx >namespace. Is this something that other implementations do, or just you >two? If there is consensus on this in the working group, it'd be nice to >get it into the spec. Attached is the current ENI_xxx definition on KAME. At this moment those #define are not exported to users (local decl in getnameinfo.c). We also don't support ENI_xxx by gai_strerror(). If we would like to take this route further, - we need to define which result should be returned in which situation (like EAI_xxx). - do we need support for ENI_xxx in gai_strerror(), just unify ENI_xxx into EAI_xxx and use gai_strerror(), or add gni_strerror()? itojun --- #define ENI_NOSOCKET 0 #define ENI_NOSERVNAME 1 #define ENI_NOHOSTNAME 2 #define ENI_MEMORY 3 #define ENI_SYSTEM 4 #define ENI_FAMILY 5 #define ENI_SALEN 6 -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 30 22:41:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0V6d1K24087 for ipng-dist; Sun, 30 Jan 2000 22:39:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0V6coj24080 for ; Sun, 30 Jan 2000 22:38:51 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA16813 for ; Sun, 30 Jan 2000 22:38:48 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA00549 for ; Sun, 30 Jan 2000 22:38:45 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA00371; Mon, 31 Jan 2000 17:36:42 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Jun-ichiro itojun Hagino Cc: Brian Zill , ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-Reply-To: Your message of "Mon, 31 Jan 2000 13:17:55 +0900." <15887.949292275@lychee.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Jan 2000 17:36:37 +1100 Message-Id: <21014.949300597@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 31 Jan 2000 13:17:55 +0900 From: Jun-ichiro itojun Hagino Message-ID: <15887.949292275@lychee.itojun.org> | | Francis ciarified it a bit, but I'm still not | sure what should I put to ai_canonname against | getaddrinfo("ftp.kame.net"), "ftp.kame.net" The only time you'd change what the application gives you is if it gives you an alias (something with a CNAME record as a value, or something in some locally defined aliases form - eg: a name with no dots that gets searched for, or something found in .hostaliases, or whatever...) Values of PTR records are irrelevant. kre -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 30 22:43:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0V6gbu24105 for ipng-dist; Sun, 30 Jan 2000 22:42:37 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0V6gPj24098 for ; Sun, 30 Jan 2000 22:42:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA04880 for ; Sun, 30 Jan 2000 22:42:24 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA15218 for ; Sun, 30 Jan 2000 23:42:23 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.04) with ESMTP id PAA10709; Mon, 31 Jan 2000 15:42:20 +0900 (JST) To: Brian Zill , ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler In-reply-to: itojun's message of Mon, 31 Jan 2000 13:17:55 JST. <15887.949292275@lychee.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Clarifications wanted on Basic API (RFC 2553) From: itojun@iijlab.net Date: Mon, 31 Jan 2000 15:42:20 +0900 Message-ID: <10707.949300940@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >ftp.kame.net. 1H IN A 203.178.141.212 >ftp.kame.net. 1H IN AAAA 3ffe:501:4819:2000:5254:ff:fedc:50d2 > >kame212.kame.net. 1H IN AAAA 3ffe:501:4819:2000:5254:ff:fedc:50d2 >kame212.kame.net. 1H IN A 203.178.141.212 >212.141.178.203.in-addr.arpa. 1D IN PTR kame212.kame.net. > >pine.v6.kame.net. 1H IN AAAA 3ffe:501:4819:2000:5254:ff:fedc:50d2 >2.d.0.5.c.d.e.f.f.f.0.0.4.5.2.5.0.0.0.2.9.1.8.4.1.0.5.0.e.f.f.3.ip6.int. 1H IN PTR pine.v6.kame.net. > > KAME getaddrinfo would return the following two records, because > gethostbyname2 returns them in hp->h_name: sorry I've tried it with our old library. The result KAME getaddrinfo will return is: ai_addr: 3ffe:501:4819:2000:5254:ff:fedc:50d2 ai_canonname: "ftp.kame.net" ai_addr: 203.178.141.212 ai_canonname: "ftp.kame.net" Are there more tricky examles? itojun -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 31 01:05:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0V91XA24237 for ipng-dist; Mon, 31 Jan 2000 01:01:33 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0V91Ej24230 for ; Mon, 31 Jan 2000 01:01:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA29589 for ; Mon, 31 Jan 2000 01:01:12 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA11461 for ; Mon, 31 Jan 2000 01:01:11 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id JAA15406; Mon, 31 Jan 2000 09:49:39 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id JAA30226; Mon, 31 Jan 2000 09:49:31 +0100 (MET) Message-Id: <200001310849.JAA30226@givry.inria.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: Brian Zill , ipng@sunroof.eng.sun.com, "'gilligan@freegate.com'" , "'set@thumper.bellcore.com'" , "'Jim Bound'" , Dave Thaler Subject: Re: Clarifications wanted on Basic API (RFC 2553) In-reply-to: Your message of Mon, 31 Jan 2000 13:17:55 +0900. <15887.949292275@lychee.itojun.org> Date: Mon, 31 Jan 2000 09:48:53 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 4.4BSD has more socktypes, SOCK_RDM and SOCK_SEQPACKET in sys/socket.h. I'm not sure what should I do against them. => We added SOCK_CONTROL which is the same thing than SOCK_RAW but with restrictions on what is allowed and available to ordinary users (useful for a node information service (using ICMPv6 info packets) in user mode). >> >The spec doesn't say anything about the error code >> >namespace, so I used the regular system one. >> KAME code defined NI_xxx and uses them. >Francis also mentioned in his reply that he uses this same ENI_xxx >namespace. Is this something that other implementations do, or just you >two? If there is consensus on this in the working group, it'd be nice to >get it into the spec. Attached is the current ENI_xxx definition on KAME. At this moment those #define are not exported to users (local decl in getnameinfo.c). We also don't support ENI_xxx by gai_strerror(). If we would like to take this route further, => I think we should take it! - we need to define which result should be returned in which situation (like EAI_xxx). - do we need support for ENI_xxx in gai_strerror(), just unify ENI_xxx into EAI_xxx and use gai_strerror(), or add gni_strerror()? => gni_strerror(). #define ENI_NOSOCKET 0 #define ENI_NOSERVNAME 1 #define ENI_NOHOSTNAME 2 #define ENI_MEMORY 3 #define ENI_SYSTEM 4 #define ENI_FAMILY 5 #define ENI_SALEN 6 Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 31 11:34:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) id e0VJVPg24757 for ipng-dist; Mon, 31 Jan 2000 11:31:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta12+Sun/8.10.0.Beta12) with ESMTP id e0VJVFj24750 for ; Mon, 31 Jan 2000 11:31:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08837 for ; Mon, 31 Jan 2000 11:31:14 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29241 for ; Mon, 31 Jan 2000 11:31:13 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA38882; Mon, 31 Jan 2000 14:31:08 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA33742; Mon, 31 Jan 2000 14:31:09 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA05926; Mon, 31 Jan 2000 14:25:55 -0500 Message-Id: <200001311925.OAA05926@rotala.raleigh.ibm.com> To: Bill Manning cc: ipng@sunroof.eng.sun.com Subject: Re: Use of IP6.INT In-Reply-To: Message from Bill Manning of "Fri, 28 Jan 2000 23:43:50 PST." <200001290743.XAA14332@zephyr.isi.edu> Date: Mon, 31 Jan 2000 14:25:55 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Manning writes: > So technically it can be done, if there is coordination between > all parties. I still don't have a good feeling as to -why- > the IAB thinks this is worth the effort unless ICANN has > announced it will transition the .INT zone to ITU. I've seen little from the ICANN story to date that gives me a warm cozy feeling. You have a crystal ball as to what ICANN really will or will not be doing with the .INT zone? Whether ICANN thinks they need to make such a transition or not misses the point. There is a real concern that they will be forced to transition .INT elsewhere under outside pressure from folks who think ICANN has no business hosting TLDs. I.e, there are forces at play here over which we have zero influence. > % >Sure, not our decision to "blow away" ip6.int. But it IS our decision > % >whether we choose to use the domain name. Our specs are the ones > % >saying use "ip6.int". We can change our specs to use some other domain > % >name. > But why should we? Cheap insurance to avoid the possibility of a far more major hassle later. > Since we were told by the IANA that ip6.int is/was ok, Really Bill. The world has changed quite a lot since those decisions where made. Not all for the better. > I wonder why the IAB has decided that its not OK and we > as operators and developers should start second guessing > IANA and believe them on a potential political debate? ICANN deals with TLDs these days, so the question is are we comfortable with the assumption that ICANN will work things out in favor of our best interests. Thomas -------------------------------------------------------------------- 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 majordomo@sunroof.eng.sun.com --------------------------------------------------------------------