From owner-ipng@sunroof.eng.sun.com Sun Apr 2 17:07:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e32Nxqu25164 for ipng-dist; Sun, 2 Apr 2000 16:59:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e32NxfN25157 for ; Sun, 2 Apr 2000 16:59:42 -0700 (PDT) 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 QAA11003 for ; Sun, 2 Apr 2000 16:59:33 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06741 for ; Sun, 2 Apr 2000 16:59:32 -0700 (PDT) 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 IAA02739; Mon, 3 Apr 2000 08:45:50 +0900 (JST) Date: Mon, 03 Apr 2000 08:47:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: muralia@future.futsoft.com Cc: users@ipv6.org, itojun@iijlab.net, 6bone@isi.edu, ipng@sunroof.eng.sun.com Subject: Re: Path MTU in IPv6 In-Reply-To: In your message of "Tue, 28 Mar 2000 10:46:36 +0530" <01BF98A2.E4C4F460.muralia@future.futsoft.com> References: <01BF98A2.E4C4F460.muralia@future.futsoft.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 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: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 28 Mar 2000 10:46:36 +0530, >>>>> Murali Krishna Ch said: > How does transport layers are innformed about ICMP "packet too big message" ? > and what is the best way? Since transport layers are usually implemented in kernel, it highly depends on kernel (i.e. OS) implementation. Or did you mean applications by "transport layers"? In any case, this type of question would be more meaningful with specific OSes. 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 Mon Apr 3 11:32:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e33IRi925654 for ipng-dist; Mon, 3 Apr 2000 11:27:44 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e33IReN25647 for ; Mon, 3 Apr 2000 11:27:40 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA02000 for ipng@sunroof.eng.sun.com; Mon, 3 Apr 2000 11:25:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e33HvCN25613 for ; Mon, 3 Apr 2000 10:57:12 -0700 (PDT) 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 KAA07587 for ; Mon, 3 Apr 2000 10:57:11 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20085 for ; Mon, 3 Apr 2000 10:57:10 -0700 (PDT) Received: from localhost (jludman@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id NAA13632 for ; Mon, 3 Apr 2000 13:57:22 -0400 (EDT) Date: Mon, 3 Apr 2000 13:57:22 -0400 From: "Jacques J. Ludman" To: ipng@sunroof.eng.sun.com Subject: MIPv6 questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I work in test development at UNHs InterOperability Lab and am currently working on our Mobile IPv6 test suite. I am having trouble discerning the exact method by which (in the presence of a home-address option) ICMP6 checksums are calculated, and similarly, how AH works in this light: - We have 2 running MIPv6 implementations in our lab, and they compute their ICMP6 checksum values differently in the presence of a home-address option. 1 creates its pseudo-header based on the original source address, the other implementation does it based on the address present in the home-address option. It is my understanding that the latter of these approaches is the correct one based on the following text in section 5.4 of the mobility draft (v. 11). " Upon receipt of a packet containing a Home Address option, the receiving node replaces the Source Address in the IPv6 header with the Home Address in the Home Address option. " - What order should/must the binding update, home-address option and authentication header be placed in a binding update packet? Strict destination option processing order as prescribed in rfc2460 _almost_ forces the home-address option to be before the binding update (you can't process options further in the packet, but you ?can? look ahead (both ahead in that destination option header and for later destination option headers) to see if they exist). o If the home-address option precedes the authentication header, does the AH calculate its ICV value based on a source address of the home-address or the original value? If it uses the orignial value, then the original source address (which is used in computing the new care-of address) is _not_ protected by the AH. Also this would cause the text of the AH document (RFC2402) to be out of date in a couple places (source address is no longer immutable, ... ). The alternative would seem to violate option processing order. Any insights would be greatly appreciated. thx, jj ps: if I had my druthers, I would mandate (MUST) that the order be AH, home-address, binding update and if they are not in this order the receiving node MUST discard the packet. ----------------------------------------- / Jacques J.Ludman \ | IP Consortium, UNH InterOperability Lab | | Morse Hall, Room 332 | | 32 College Rd, Durham NH 03824 | \ tel: 862-0090 fax: 862-1761 / ----------------------------------------- -------------------------------------------------------------------- IETF IPng Working 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 Apr 4 03:14:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e34AC9N26123 for ipng-dist; Tue, 4 Apr 2000 03:12:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e348p5N26103 for ; Tue, 4 Apr 2000 01:51:13 -0700 (PDT) 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 BAA23384 for ; Tue, 4 Apr 2000 01:50:55 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26808 for ; Tue, 4 Apr 2000 02:50:46 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA28951; Tue, 4 Apr 2000 10:49:36 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12095; Tue, 4 Apr 2000 10:49:35 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA03051; Tue, 4 Apr 2000 10:54:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200004040854.KAA03051@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jacques J. Ludman" cc: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 questions In-reply-to: Your message of Mon, 03 Apr 2000 13:57:22 EDT. Date: Tue, 04 Apr 2000 10:54:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I work in test development at UNHs InterOperability Lab and am currently working on our Mobile IPv6 test suite. I am having trouble discerning the exact method by which (in the presence of a home-address option) ICMP6 checksums are calculated, and similarly, how AH works in this light: => ICMPv6 checksums are computed with a pseudo-header which is independent of all kinds of optional headers as the packet is before applying them (RFC 2460 8.1). - We have 2 running MIPv6 implementations in our lab, and they compute their ICMP6 checksum values differently in the presence of a home-address option. 1 creates its pseudo-header based on the original source address, the other implementation does it based on the address present in the home-address option. It is my understanding that the latter of these approaches is the correct one based on the following text in section 5.4 of the mobility draft (v. 11). " Upon receipt of a packet containing a Home Address option, the receiving node replaces the Source Address in the IPv6 header with the Home Address in the Home Address option. " => I agree. RFC 2460 was written before the home address option but the text about routing header is clear. Next version of RFC 2460 should have a statement about home address options... The transparency argument of sections 10.[12] of last I-D applies too (ie. the upper-layer should do the same thing than no mobile IPv6 is here). - What order should/must the binding update, home-address option and authentication header be placed in a binding update packet? Strict destination option processing order as prescribed in rfc2460 _almost_ forces the home-address option to be before the binding update (you can't process options further in the packet, but you ?can? look ahead (both ahead in that destination option header and for later destination option headers) to see if they exist). => there are two questions: - the place of the destination option header which carries the home address option: it must be before the authentication header (I-D 11, section 10.2). - the place of the home address option into a destination option header: this doesn't matter, for instance if a binding update option and a home address option are both in the same header they can be in *any* order (but this should not happen because of the IPSec processing rule). o If the home-address option precedes the authentication header, does the AH calculate its ICV value based on a source address of the home-address or the original value? => the home-address because of the order of headers (I-D 11, section 10.2). The alternative would seem to violate option processing order. => the option processing order (which is only recommended by RFC 2460) is amended by the I-D 11. The rule against duplication of headers too (as I noted in a previous mail in this list). Any insights would be greatly appreciated. => just read the last I-D section 10.2 which is very clear about IPSec processing and header ordering. ps: if I had my druthers, I would mandate (MUST) that the order be AH, home-address, binding update and if they are not in this order the receiving node MUST discard the packet. => if headers are not in the right order then the packet will not be authenticated then will be discarded, ie. no extra statement is needed. Regards 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 Tue Apr 4 09:54:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e34GqVY26307 for ipng-dist; Tue, 4 Apr 2000 09:52:31 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e34GqKN26300 for ; Tue, 4 Apr 2000 09:52:21 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e34GqIG965756; Tue, 4 Apr 2000 09:52:19 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.9.3+Sun/8.9.3) id JAA16565; Tue, 4 Apr 2000 09:51:50 -0700 (PDT) Date: Tue, 4 Apr 2000 09:51:50 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200004041651.JAA16565@locked.eng.sun.com> To: jludman@iol.unh.edu, Francis.Dupont@enst-bretagne.fr Subject: Re: MIPv6 questions Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > o If the home-address option precedes the authentication > header, does the AH calculate its ICV value based on a source address of > the home-address or the original value? > > => the home-address because of the order of headers (I-D 11, section 10.2). > > > => just read the last I-D section 10.2 which is very clear about IPSec > processing and header ordering. > The latest draft on mobile ipv6 is not very clear on what exact bits are passed through for computing the AH ICV on inbound. One can only infer how it should be on inbound. The steps on outbound are (from section 10.2) 1) Insert the Dst options and put ip6_src = COA. 2) Compute the AH ICV. For the reciever to compute the same ICV, ip6_src should be still COA. But from section 5.4, it says that the receiving node replaces the source address in the IPv6 header with the Home Address in the Home Address option. Does this mean we replace the address and then compute the ICV ? This won't be correct as we computed the ICV with ip6_src = COA. In the case of Routing Header does'nt the sender compute the AH ICV after constructing a pseudo IP header as it would look like on the receiver i.e If "S" wants to send packet to "D", through hops I1, I2, the ICV is computed with ip6_src = S, ip6_dst = D, Routing header with I1 and I2 though the packet when it is actually sent, it is sent to I1 i.e packet from S looks like ip6_src = S, ip6_dst = I1, Routing header I2, D but the ICV on "S" is computed with ip6_src = S, ip6_dst = D, Routing header I1, I2. Similarly, for Home Address Option, the sender should construct the pseudo header as it would appear on the receiver when it computes the ICV. On outbound, 1) Insert the HOME address option before the AH header. 2) Compute the AH ICV. 3) Replace the ip6_src with the COA. And on Inbound, we can do the replacement first and then compute the AH ICV. The draft does not mention what is contained in the Home address option while computing the ICV. If instead of replacement, we "swap" the ip6_src with the Home address, we get exactly what we did on outbound. Nice to know what the existing implementations do. -mohan -------------------------------------------------------------------- IETF IPng Working 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 Apr 4 10:27:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e34HPVQ26426 for ipng-dist; Tue, 4 Apr 2000 10:25:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e34HPMN26419 for ; Tue, 4 Apr 2000 10:25:23 -0700 (PDT) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA03286; Tue, 4 Apr 2000 10:25:17 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05995; Tue, 4 Apr 2000 10:25:11 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.0/8.10.0) with ESMTP id e34HOc818753; Tue, 4 Apr 2000 19:24:39 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA19478; Tue, 4 Apr 2000 19:24:38 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA04256; Tue, 4 Apr 2000 19:29:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200004041729.TAA04256@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy cc: jludman@iol.unh.edu, ipng@sunroof.eng.sun.com Subject: Re: MIPv6 questions In-reply-to: Your message of Tue, 04 Apr 2000 09:51:50 PDT. <200004041651.JAA16565@locked.eng.sun.com> Date: Tue, 04 Apr 2000 19:29:36 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The latest draft on mobile ipv6 is not very clear on what exact bits are passed through for computing the AH ICV on inbound. => the last draft is very clear for me but if you have better way to explain IPSec processing then you can propose improvements to the authors (it is a case where nothing is too good :-). 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 Wed Apr 5 05:05:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35C3eg27044 for ipng-dist; Wed, 5 Apr 2000 05:03:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35C3UN27037 for ; Wed, 5 Apr 2000 05:03:31 -0700 (PDT) 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 FAA19438 for ; Wed, 5 Apr 2000 05:03:29 -0700 (PDT) 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 FAA02128 for ; Wed, 5 Apr 2000 05:03:26 -0700 (PDT) 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 MA15932; Wed, 5 Apr 2000 22:03:23 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: Advanced sockets API draft (rfc2292bis) query Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Apr 2000 22:03:21 +1000 Message-Id: <29996.954936201@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There has been a little off line discussion about DNS and IPv6, which led (due to a "I don't know of a way to ..." from me, and then a "see section ... in draft ..." response) to an examination of section 11.1 in draft-ietf-ipngwg-rfc2292bis-01.txt (this is new since 2292). After a brief explanation of what is being done, section 11.1 says ... This specification defines a mechanism to avoid fragmentation by sending at the minimum IPv6 MTU (1280 bytes). This can be enabled using the IPV6_USE_MIN_MTU socket option. Unfortunately, it doesn't say what that means (there's more text on how to call the option, and what values mean on & off, etc). The context is sending UDP packets ("A potential example is a DNS server"). The question now is what does "to avoid fragmentation" really mean here? The best interpretation (for the DNS anyway) would be if the actual meaning of this option was "to cause fragmentation" rather than "to avoid fragmentation". That is, when enabled, this option would cause packets larger than specified (1280 as it is now) to be fragmented from the source, so they should never fail with a packet to big error. If that is the intent, and I suspect it might be, then "to avoid fragmentation" seems like a very poor description, as what is being done is causing fragmentation, not avoiding it. Of course, that is what needs to be done to allow large UDP packets to traverse the net (without requiring the application to engage in PMTU discovery, which is a truly evil thing to require of a DNS server, which will typically be sending exactly one packet to the particular destination). If that isn't what the option is intended to achieve, then two things arise - first, something needs to be added to that section to say exactly what it is meant to achieve (actually, that probably needs to be done anyway) and second, an option that will cause fragmentation to occur needs to be added. Then, while on the topic, I feel this option would be better if instead of taking a boolean value, it actually took an int value, so the application could set the size above which fragments would be created. This one isn't for DNS servers, for which 1280 seems like a fine value to have set, but for other UDP applications for which use of PMTU discovery (and the IPV6_RECVPATHMTU setsockopt defined in section 11.2) is a reasonable thing to do - but which do need to be able to send single packet datagrams which might be bigger than the MTU discovered. There fragmentation is still required, but 1280 is not necessarily the best number to use (one possible example here is for DHCP servers, which when lots of data needs to be conveyed to the client might need to send a packet bigger than 1500 bytes - but which are sending it only to a few local ethernets, all of which have an MTU of 1500, which can easily be discovered). So, if a change is to be made to section 11.1, and I think one is eneded, can I suggest that it also be changed to use an int value, where 1280 would be a common case, and 0 would mean "don't fragment at all, send what I send" equivalent to the current "off" status ... assuming I am guessing correctly at what IPV6_USE_MIN_MTU actually means). Matt? Erik? Is one of you currently responsible for this draft? 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 Wed Apr 5 06:44:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35Dd7b27104 for ipng-dist; Wed, 5 Apr 2000 06:39:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35DcuN27097 for ; Wed, 5 Apr 2000 06:38:57 -0700 (PDT) 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 GAA23119 for ; Wed, 5 Apr 2000 06:38:56 -0700 (PDT) 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 HAA05407 for ; Wed, 5 Apr 2000 07:38:54 -0600 (MDT) 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 WAA22908; Wed, 5 Apr 2000 22:37:12 +0900 (JST) To: Robert Elz cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Wed, 05 Apr 2000 22:03:21 +1000. <29996.954936201@munnari.OZ.AU> 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: Advanced sockets API draft (rfc2292bis) query From: itojun@iijlab.net Date: Wed, 05 Apr 2000 22:37:12 +0900 Message-ID: <22906.954941832@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >After a brief explanation of what is being done, section 11.1 >says ... > This specification defines a mechanism to avoid fragmentation by > sending at the minimum IPv6 MTU (1280 bytes). This can be enabled > using the IPV6_USE_MIN_MTU socket option. I agree the "avoid fragmentation" is a little vague. >Then, while on the topic, I feel this option would be better if instead >of taking a boolean value, it actually took an int value, so the >application could set the size above which fragments would be created. >This one isn't for DNS servers, for which 1280 seems like a fine value >to have set, but for other UDP applications for which use of PMTU discovery >(and the IPV6_RECVPATHMTU setsockopt defined in section 11.2) is a >reasonable thing to do - but which do need to be able to send single >packet datagrams which might be bigger than the MTU discovered. There >fragmentation is still required, but 1280 is not necessarily the best >number to use (one possible example here is for DHCP servers, which when >lots of data needs to be conveyed to the client might need to send a packet >bigger than 1500 bytes - but which are sending it only to a few local >ethernets, all of which have an MTU of 1500, which can easily be discovered). I'm not sure if I understand the intent here. Why userland application needs to think about link MTU? >So, if a change is to be made to section 11.1, and I think one is eneded, >can I suggest that it also be changed to use an int value, where 1280 would >be a common case, and 0 would mean "don't fragment at all, send what I send" >equivalent to the current "off" status ... assuming I am guessing correctly >at what IPV6_USE_MIN_MTU actually means). I believe the default behavior is not just "don't fragment at all". Normally, without any setsockopt, the kernel behavior would be like: if (cached PMTU value is available for destination) x = cached PMTU value; else x = link MTU for outgoing interface; fragment packet to fit into x; so this is not "don't fragment at all". 2292bis-01 behavior would be (I'm guessing): /* if you would like to honor PMTU or link MTU */ if (cached PMTU value is available for destination) x = cached PMTU value; else x = link MTU for outgoing interface; if (x > 1280 && IPV6_USE_MIN_MTU is specified) x = 1280; fragment packet to fit into x; or: /* if you really want to enforce 1280 by setsockopt */ if (IPV6_USE_MIN_MTU is specified) x = 1280; else if (cached PMTU value is available for destination) x = cached PMTU value; else x = link MTU for outgoing interface; fragment packet to fit into x; Could you describe your suggestion in more detail? 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 Apr 5 07:16:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35ECkh27147 for ipng-dist; Wed, 5 Apr 2000 07:12:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35ECYN27140 for ; Wed, 5 Apr 2000 07:12:34 -0700 (PDT) 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 HAA28689 for ; Wed, 5 Apr 2000 07:12:30 -0700 (PDT) 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 HAA06883 for ; Wed, 5 Apr 2000 07:12:28 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA21475; Wed, 5 Apr 2000 09:05:34 -0500 (CDT) Message-Id: <200004051405.JAA21475@gungnir.fnal.gov> To: itojun@iijlab.net Cc: Robert Elz , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Advanced sockets API draft (rfc2292bis) query In-reply-to: Your message of Wed, 05 Apr 2000 22:37:12 +0900. <22906.954941832@coconut.itojun.org> Date: Wed, 05 Apr 2000 09:05:34 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It looks to me like the option is useful, but the description is, as kre says, entirely wrong. But I don't think he captured what I see as the full effect of setting the option. On a datagram (UDP) socket, this would force fragmentation on the initial transmission rather than after a possible ICMPv6 "Too Big" message comes back. On a stream (TCP) socket, this would set the packetization quantum of the stream and indeed avoid fragmentation. 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 Apr 5 07:38:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35EZuP27182 for ipng-dist; Wed, 5 Apr 2000 07:35:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35EZlN27175 for ; Wed, 5 Apr 2000 07:35:48 -0700 (PDT) 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 HAA04961 for ; Wed, 5 Apr 2000 07:35:48 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21925 for ; Wed, 5 Apr 2000 07:35:41 -0700 (PDT) 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 XAA27574 for ; Wed, 5 Apr 2000 23:35:36 +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 XAA20724 for ; Wed, 5 Apr 2000 23:35:36 +0900 (JST) Received: from Mew.org (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id XAA07727 for ; Wed, 5 Apr 2000 23:35:35 +0900 (JST) Date: Wed, 05 Apr 2000 23:36:15 +0900 (JST) Message-Id: <20000405.233615.74702777.kazu@Mew.org> To: ipng@sunroof.eng.sun.com Subject: Re: Advanced sockets API draft (rfc2292bis) query From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <200004051405.JAA21475@gungnir.fnal.gov> References: <22906.954941832@coconut.itojun.org> <200004051405.JAA21475@gungnir.fnal.gov> X-Mailer: Mew version 1.95b29 on Emacs 20.6 / 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 From: "Matt Crawford" Subject: Re: Advanced sockets API draft (rfc2292bis) query > On a datagram (UDP) socket, this would force fragmentation on the > initial transmission rather than after a possible ICMPv6 "Too Big" > message comes back. > > On a stream (TCP) socket, this would set the packetization quantum of > the stream and indeed avoid fragmentation. Or clarify that this sockopt is for UDP/IPv6 only. I think this option is not necessary for TCP/IPv6 if RFC 1981 Section 5.4 is implemented correctly. --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 Apr 5 07:55:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35Es4827221 for ipng-dist; Wed, 5 Apr 2000 07:54:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35EruN27214 for ; Wed, 5 Apr 2000 07:53:56 -0700 (PDT) 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 HAA20369 for ; Wed, 5 Apr 2000 07:53:56 -0700 (PDT) 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 HAA03157 for ; Wed, 5 Apr 2000 07:52:17 -0700 (PDT) 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 OA22353; Thu, 6 Apr 2000 00:47:14 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Advanced sockets API draft (rfc2292bis) query In-Reply-To: Your message of "Wed, 05 Apr 2000 22:37:12 +0900." <22906.954941832@coconut.itojun.org> Date: Thu, 06 Apr 2000 00:47:04 +1000 Message-Id: <857.954946024@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 05 Apr 2000 22:37:12 +0900 From: itojun@iijlab.net Message-ID: <22906.954941832@coconut.itojun.org> | I'm not sure if I understand the intent here. Why userland | application needs to think about link MTU? Because with UDP, there is no-ne else (the kernel is just a packet sender). | I believe the default behavior is not just "don't fragment at all". Hmm - perhaps. Is that stated somewhere? In IPv4 fragmentation happens unless explicitly disabled, but in IPv6 it needs to be explicitly enabled. I was kind of expecting the API to have made that adjustment as well. | Normally, without any setsockopt, the kernel behavior would be like: [...] | so this is not "don't fragment at all". And if I, as the application, want to get back the "packet too big" message so I can send something smaller? This would be rational for a TFTP server (which is, in a sense, just a userland implementation of a poor man's TCP). | 2292bis-01 behavior would be (I'm guessing): [...] | or: [...] perhaps one of those. An alternative might be ... len = lengthof(packet); x = 1280 (or value set by this setsoockopt if it gets an int value). if (len > x && x > 0) fragment into ((len + x - 1) / x) pieces; send the packet (or fragments). if any fragment (or the entire packet if not fragmented) is too big for the link MTU, return E2BIG (or something). | Could you describe your suggestion in more detail? Aside from improving the language, I'm not sure I have a specific suggestion (aside from not setting the 1280 number in stone, and instead allowing it to be set by the application - either of your algorithms would work with that modification). Perhaps all options can be achieved by making the default value for the section 11.1 setsockopt (whose name might perhaps change) be the cached path MTU for the destination (which will default to the link MTU of the first hop). That way, unless the application does something special, it gets the behaviour you described. If it never wants fragmentation, it can set the frag limit huge (2^32 - 1) though anything larger than 65536 would do (nothing bigger can be fragmented anyway). If it wants minimum MTU type fragments (as a DNS server might) it can set 1280. Then 0 would return to the default behaviour. kre ps: I meant to say what Matt Crawford said... -------------------------------------------------------------------- IETF IPng Working 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 Apr 5 08:26:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35FOWw27262 for ipng-dist; Wed, 5 Apr 2000 08:24:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35FOKN27251 for ; Wed, 5 Apr 2000 08:24:21 -0700 (PDT) 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 IAA16517 for ; Wed, 5 Apr 2000 08:24:21 -0700 (PDT) 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 JAA16760 for ; Wed, 5 Apr 2000 09:24:18 -0600 (MDT) 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 AAA23991; Thu, 6 Apr 2000 00:20:55 +0900 (JST) To: Robert Elz cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 06 Apr 2000 00:47:04 +1000. <857.954946024@munnari.OZ.AU> 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: Advanced sockets API draft (rfc2292bis) query From: itojun@iijlab.net Date: Thu, 06 Apr 2000 00:20:55 +0900 Message-ID: <23989.954948055@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | I'm not sure if I understand the intent here. Why userland > | application needs to think about link MTU? >Because with UDP, there is no-ne else (the kernel is just a packet >sender). > | I believe the default behavior is not just "don't fragment at all". >Hmm - perhaps. Is that stated somewhere? In IPv4 fragmentation happens >unless explicitly disabled, but in IPv6 it needs to be explicitly enabled. >I was kind of expecting the API to have made that adjustment as well. For raw socket, RFC2292 page 13 (5th paragraph) says that it would automatically fragment packet to fit into path MTU. I found no explicit descrptiion about UDP sockets, but I think it makes sense to have similar behavior with raw socket case. Since we have interpreted the text differently, we may need some clarification in some of the documents (RFC2553?). > | Normally, without any setsockopt, the kernel behavior would be like: >[...] > | so this is not "don't fragment at all". >And if I, as the application, want to get back the "packet too big" >message so I can send something smaller? This would be rational for >a TFTP server (which is, in a sense, just a userland implementation of >a poor man's TCP). RFC2348 (TFTP blocksize option)? The TFTP server should, in my guess, behave like this: 0. (get request from client) 1. query link MTU for directly attached link. The TFTP server needs to look at its interface status by itself, since there will be nobody who would send ICMPv6 TOOBIG to the server (NOTE: TOOBIG is sent by router only - see RFC2463 3.2). 2. send a packet that fits into link MTU. 3-a. if path MTU >= link MTU, the packet should reach the client okay. 3-b. if path MTU < link MTU, path MTU discovery would occur (TOOBIG reaches server from intermediate routers). The TFTP server would use to use IPV6_RECVPATHMTU (2292bis-01 11.2) to get the informed path MTU. Go back to 2 for resend, with the informed path MTU (smaller than before). 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 Apr 5 09:57:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35Gtjd27332 for ipng-dist; Wed, 5 Apr 2000 09:55:45 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35GtXN27325 for ; Wed, 5 Apr 2000 09:55:34 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35GtX7162212; Wed, 5 Apr 2000 09:55:33 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.9.3+Sun/8.9.3) id JAA17339; Wed, 5 Apr 2000 09:55:04 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200004051655.JAA17339@locked.eng.sun.com> Subject: Re: MIPv6 questions In-Reply-To: <200004041729.TAA04256@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Apr 4, 2000 07:29:36 pm" To: Francis Dupont Date: Wed, 5 Apr 2000 09:55:04 -0700 (PDT) CC: Mohan Parthasarathy , jludman@iol.unh.edu, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > The latest draft on mobile ipv6 is not very clear on what exact bits > are passed through for computing the AH ICV on inbound. > > => the last draft is very clear for me but if you have better way > to explain IPSec processing then you can propose improvements to > the authors (it is a case where nothing is too good :-). > In section 5.4 and other places, the draft says that when a packet with HOME address option is recieved it should be processed first before IPSEC is done. Thus while AH ICV is being computed ip6_src of the IPv6 header contains the HOME address. If you refer to 10.2 for outbound processing with Home address options, it states that HOME address option is inserted, ip6_src is replaced with Care of Address and then AH ICV is computed. ip6_src is not same in these two cases and hence ICV can't be the same. Am i reading anything wrong here ? -mohan -------------------------------------------------------------------- IETF IPng Working 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 Apr 5 10:14:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35HCCM27384 for ipng-dist; Wed, 5 Apr 2000 10:12:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35HC3N27377 for ; Wed, 5 Apr 2000 10:12:04 -0700 (PDT) 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 KAA07741 for ; Wed, 5 Apr 2000 10:11:58 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09244 for ; Wed, 5 Apr 2000 10:11:56 -0700 (PDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id E634B322; Wed, 5 Apr 2000 12:11:54 -0500 (CDT) Received: from yquarry.zk3.dec.com (byquarry.zk3.dec.com [16.140.96.30]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 8F552287 for ; Wed, 5 Apr 2000 12:11:54 -0500 (CDT) Received: from whitestar.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id NAA0000016338; Wed, 5 Apr 2000 13:11:53 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA08713; Wed, 5 Apr 2000 13:11:52 -0400 Message-Id: <38EB73D8.8D351EC1@zk3.dec.com> Date: Wed, 05 Apr 2000 13:11:52 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: Advanced sockets API draft (rfc2292bis) query References: <29996.954936201@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, how about the following behavior: If the user sets the IPV6_USE_MIN_MTU option with a 0 value, use the cached or default media mtu. If the user sets this option with a value of 1, use the minimum IPv6 mtu (1280). If the user sets this option with another value, use that value as the mtu. I also think that there should be a different option to completely disable fragmentation so that an application (ex: traceroute) can do path mtu discovery (starting with the first hop) itself. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working 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 Apr 5 11:59:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35IvSk27610 for ipng-dist; Wed, 5 Apr 2000 11:57:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35IvHN27603 for ; Wed, 5 Apr 2000 11:57:17 -0700 (PDT) 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 LAA06360; Wed, 5 Apr 2000 11:57:10 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19841; Wed, 5 Apr 2000 11:57:08 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.0/8.10.0) with ESMTP id e35Iv5818888; Wed, 5 Apr 2000 20:57:05 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA04868; Wed, 5 Apr 2000 20:57:04 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id VAA08595; Wed, 5 Apr 2000 21:02:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200004051902.VAA08595@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy cc: jludman@iol.unh.edu, ipng@sunroof.eng.sun.com Subject: Re: MIPv6 questions In-reply-to: Your message of Wed, 05 Apr 2000 09:55:04 PDT. <200004051655.JAA17339@locked.eng.sun.com> Date: Wed, 05 Apr 2000 21:02:08 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > In your previous mail you wrote: > > The latest draft on mobile ipv6 is not very clear on what exact bits > are passed through for computing the AH ICV on inbound. > > => the last draft is very clear for me but if you have better way > to explain IPSec processing then you can propose improvements to > the authors (it is a case where nothing is too good :-). > In section 5.4 and other places, the draft says that when a packet with HOME address option is recieved it should be processed first before IPSEC is done. => the idea is to use the home address for SA lookup. Thus while AH ICV is being computed ip6_src of the IPv6 header contains the HOME address. => it is a consequence of the previous point: inbound IPSec processing should be done after the home address option processing. The real problem is to know what is it exactly the home address option processing, texts say replace addresses in source by the one in the option, verbal explanations say to swap them which is better because the care-of address (the source address before processing) must be kept and protected. If you refer to 10.2 for outbound processing with Home address options, it states that HOME address option is inserted, ip6_src is replaced with Care of Address and then AH ICV is computed. ip6_src is not same in these two cases... => the piece you'd like is the AH processing rule for the home address option which depends a bit of the way you "fully assemble" the packet. 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 Wed Apr 5 12:46:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e35JfbD27732 for ipng-dist; Wed, 5 Apr 2000 12:41:37 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35JfMN27725 for ; Wed, 5 Apr 2000 12:41:22 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e35JfK7192532; Wed, 5 Apr 2000 12:41:20 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.9.3+Sun/8.9.3) id MAA17568; Wed, 5 Apr 2000 12:40:51 -0700 (PDT) Date: Wed, 5 Apr 2000 12:40:51 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200004051940.MAA17568@locked.eng.sun.com> To: Mohan.Parthasarathy@eng.sun.com, Francis.Dupont@enst-bretagne.fr Subject: Re: MIPv6 questions Cc: jludman@iol.unh.edu, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In section 5.4 and other places, the draft says that when a packet > with HOME address option is recieved it should be processed first > before IPSEC is done. > > => the idea is to use the home address for SA lookup. > Agreed. > Thus while AH ICV is being computed ip6_src of the IPv6 header contains > the HOME address. > > => it is a consequence of the previous point: inbound IPSec processing > should be done after the home address option processing. The real problem > is to know what is it exactly the home address option processing, texts > say replace addresses in source by the one in the option, verbal > explanations say to swap them which is better because the care-of address > (the source address before processing) must be kept and protected. > Depending on swap or replacement, the results will differ. So, my original question was to find out the intent of the text in the draft. I prefer swap and if swapping is done before IPSEC processing on inbound, a similar change should happen on outbound so that after the insertion of the home address option, ICV should be computed first and then swap the address. > If you refer to 10.2 for outbound processing with Home address > options, it states that HOME address option is inserted, ip6_src > is replaced with Care of Address and then AH ICV is computed. ip6_src > is not same in these two cases... > > => the piece you'd like is the AH processing rule for the home address > option which depends a bit of the way you "fully assemble" the packet. > So, are you saying that the text needs to be clarified with respect to this ? -mohan > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working 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 Apr 5 22:23:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e365LNO28157 for ipng-dist; Wed, 5 Apr 2000 22:21:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e365LAN28150 for ; Wed, 5 Apr 2000 22:21:10 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with SMTP id e365L67277991; Wed, 5 Apr 2000 22:21:06 -0700 (PDT) Date: Wed, 5 Apr 2000 22:15:25 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Advanced sockets API draft (rfc2292bis) query To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <29996.954936201@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Matt? Erik? Is one of you currently responsible for this draft? Yes, I pretend to be responsible. I agree the document is a bit terse :-) And incorrect. First of all I expect most existing implementations automatically fragment UDP packets that exceed the path MTU (and by path MTU I mean the outgoing link MTU if no pmtu has been cached yet). This is necessary to provide minimal porting for UDP applications that send around large packets - NFS/UDP being one prime example. To minimize the "suprise" with IPv6 I think we want to keep it that way, even though no document I know of states this. I take your point on being able to set a specific value for protocols on top of UDP that need to be PMTU aware. For such applications the behavior needs to be to get an error when the packet size exceeds the cached pmtu value in the kernel, since the pmtu value might have been established by some other communication hence this application might not have seen the current pmtu with IPV6_RECVPATHMTU. If we go this path it makes sense to have an IPV6_USEMTU option (instead of IPV6_USE_MIN_MTU) which takes a uint32_t as an argument (for those that want to control jumbogram sizes). Default value of option is zero, which has to above "fragment to the path mtu/link mtu bahevior". The option can not be set to the values 1 through 1279. If it is set to a non-zero value that value will be used to determine the size of the fragments. There are no other checks on the value of the option. When packets are sent and the option has been set to a non-zero value an attempt is made to fragment to the min of that value and the length of the packet sent. If this value exceeds the path MTU or link MTU an ETOOBIG error may be returned (or the packet silently dropped) and an IPV6_PATHMTU ancillary data item sent to the application (assuming it has enabled IPV6_RECVPATHMTU). [Note that some implementations, in particular those based on STREAMS, might not be able to return an error to a sendto/sendmsg call when the error is generated by the protocols in the stack. Hence the "may" above. In any case, ETOOBIG wouldn't indicate the correct max size to use.] A portable application which sets IPV6_USEMTU to a value other than 0 or 1280 must enable IPV6_RECVPATHMTU and use those notifications to modify either the size of the packets being sent or the value of the IPV6_USEMTU option. One question that remains is should we specify the use of this with TCP? Would it make sense for a busy DNS server (which some times fall back to sending using TCP) to be able to tell TCP to send 1280 byte packets even if the link MTU is larger? That would save time and resources when it is just sending back e.g. 2k of data. 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 Apr 5 22:24:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e365O3p28175 for ipng-dist; Wed, 5 Apr 2000 22:24:03 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e365NoN28168 for ; Wed, 5 Apr 2000 22:23:50 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with SMTP id e365Nk7278190; Wed, 5 Apr 2000 22:23:47 -0700 (PDT) Date: Wed, 5 Apr 2000 22:18:14 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Advanced sockets API draft (rfc2292bis) query To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <38EB73D8.8D351EC1@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 > Well, how about the following behavior: > > If the user sets the IPV6_USE_MIN_MTU option with a 0 value, use the > cached or default media mtu. > > If the user sets this option with a value of 1, use the minimum > IPv6 mtu (1280). Having the application just set it to 1280 in that case seems more logical - less special values to track. > If the user sets this option with another value, use that value as > the mtu. > > > I also think that there should be a different option to completely > disable fragmentation so that an application (ex: traceroute) can > do path mtu discovery (starting with the first hop) itself. Good point. Has anybody implemented this for IPv6? Or do we need to invent something new? (IPV6_DONTFRAGMENT option?) The IPv4 traceroutes I've seen do this depend on being able to set the DF flag with raw sockets (when IP_HDRINCL is set). We don't have anything similar in IPv6. 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 Apr 5 22:31:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e365TtZ28206 for ipng-dist; Wed, 5 Apr 2000 22:29:55 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e365TVN28199 for ; Wed, 5 Apr 2000 22:29:31 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with SMTP id e365TR7278644; Wed, 5 Apr 2000 22:29:27 -0700 (PDT) Date: Wed, 5 Apr 2000 22:23:53 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Advanced sockets API draft (rfc2292bis) query To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <38EB73D8.8D351EC1@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 > I also think that there should be a different option to completely > disable fragmentation so that an application (ex: traceroute) can > do path mtu discovery (starting with the first hop) itself. I just realized this can be done using the IPV6_USEMTU as I specified it in an earlier email. The application enables IPV6_RECVPATHMTU and sets IPV6_USEMTU to 65535 (or maxint). This means that it will receive an IPV6_PATHMTU ancillary data item (and maybe an ETOOBIG) as long as it it sending packets larger than the link MTU (or larger than a cached path MTU - is the path MTU interaction an issue here? Should the kernel just check the link MTU and ignore the path MTU for this type of traceroute?) 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 Apr 6 02:14:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e369CJA28333 for ipng-dist; Thu, 6 Apr 2000 02:12:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e368hTN28312 for ; Thu, 6 Apr 2000 01:43:30 -0700 (PDT) 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 BAA29970; Thu, 6 Apr 2000 01:43:20 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24680; Thu, 6 Apr 2000 02:42:44 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.0/8.10.0) with ESMTP id e368gH823996; Thu, 6 Apr 2000 10:42:17 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA09469; Thu, 6 Apr 2000 10:42:16 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA09903; Thu, 6 Apr 2000 10:47:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200004060847.KAA09903@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy cc: jludman@iol.unh.edu, ipng@sunroof.eng.sun.com Subject: Re: MIPv6 questions In-reply-to: Your message of Wed, 05 Apr 2000 12:40:51 PDT. <200004051940.MAA17568@locked.eng.sun.com> Date: Thu, 06 Apr 2000 10:47:24 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Thus while AH ICV is being computed ip6_src of the IPv6 header contains > the HOME address. > > => it is a consequence of the previous point: inbound IPSec processing > should be done after the home address option processing. The real problem > is to know what is it exactly the home address option processing, texts > say replace addresses in source by the one in the option, verbal > explanations say to swap them which is better because the care-of address > (the source address before processing) must be kept and protected. > Depending on swap or replacement, the results will differ. => with a simple replacement the care-of address is no more present and as I said the care-of is both needed and must be protected then in the reassembled packet used for AH ICV both the home address and the care-of address will appear in the source address and the home address option. The only question is which one will be in the source address... So, my original question was to find out the intent of the text in the draft. I prefer swap and if swapping is done before IPSEC processing on inbound, a similar change should happen on outbound so that after the insertion of the home address option, ICV should be computed first and then swap the address. => or the reassembly processing will swap again the address (two swaps are the identity function). > => the piece you'd like is the AH processing rule for the home address > option which depends a bit of the way you "fully assemble" the packet. So, are you saying that the text needs to be clarified with respect to this ? => first I believe the text will never become too clear, second if we have this discussion obviously the text is not clear enough! Regards 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 Thu Apr 6 02:24:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e369Mq428357 for ipng-dist; Thu, 6 Apr 2000 02:22:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e369MhN28350 for ; Thu, 6 Apr 2000 02:22:43 -0700 (PDT) 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 CAA29850; Thu, 6 Apr 2000 02:22:43 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10538; Thu, 6 Apr 2000 03:22:27 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.0/8.10.0) with ESMTP id e369L8826914; Thu, 6 Apr 2000 11:21:08 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA10094; Thu, 6 Apr 2000 11:21:02 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA10070; Thu, 6 Apr 2000 11:26:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200004060926.LAA10070@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Vladislav Yasevich , ipng@sunroof.eng.sun.com Subject: Re: Advanced sockets API draft (rfc2292bis) query In-reply-to: Your message of Wed, 05 Apr 2000 22:18:14 PDT. Date: Thu, 06 Apr 2000 11:26:10 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I also think that there should be a different option to completely > disable fragmentation so that an application (ex: traceroute) can > do path mtu discovery (starting with the first hop) itself. Good point. Has anybody implemented this for IPv6? => fragmentation is disabled in my code on one of these three conditions: - forwarding (both unicast and multicast) - internal don't-frag flag (used by IPv6 over IPv6 as an option and by TCP (in order to get path MTU discovery)) - raw output (ie. output on a SOCK_RAW socket) with the IP_HDRINCL option set (this is used by traceroute6). Or do we need to invent something new? (IPV6_DONTFRAGMENT option?) => my IP_HDRINCL is not standard (:-) then I am in favor of a don't fragment socket option. The IPv4 traceroutes I've seen do this depend on being able to set the DF flag with raw sockets (when IP_HDRINCL is set). We don't have anything similar in IPv6. => I agree Francis.Dupont@enst-bretagne.fr PS: an alternative is to make draft-ietf-ipngwg-bsd-frag-01.txt alive again. -------------------------------------------------------------------- IETF IPng Working 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 Apr 6 07:32:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e36ERfh28452 for ipng-dist; Thu, 6 Apr 2000 07:27:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e36ERWN28445 for ; Thu, 6 Apr 2000 07:27:32 -0700 (PDT) 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 HAA00980 for ; Thu, 6 Apr 2000 07:27:33 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12844 for ; Thu, 6 Apr 2000 07:27:27 -0700 (PDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 448E7F88; Thu, 6 Apr 2000 09:27:27 -0500 (CDT) Received: from yquarry.zk3.dec.com (byquarry.zk3.dec.com [16.140.96.30]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id B8DFBE5F; Thu, 6 Apr 2000 09:27:26 -0500 (CDT) Received: from whitestar.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id KAA0000023330; Thu, 6 Apr 2000 10:27:25 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA00986; Thu, 6 Apr 2000 10:27:25 -0400 Message-Id: <38EC9ECD.15F0884F@zk3.dec.com> Date: Thu, 06 Apr 2000 10:27:25 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: Advanced sockets API draft (rfc2292bis) query References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > > I also think that there should be a different option to completely > > disable fragmentation so that an application (ex: traceroute) can > > do path mtu discovery (starting with the first hop) itself. > > I just realized this can be done using the IPV6_USEMTU as I specified > it in an earlier email. I agree. > > The application enables IPV6_RECVPATHMTU and sets IPV6_USEMTU to 65535 > (or maxint). > > This means that it will receive an IPV6_PATHMTU ancillary data item > (and maybe an ETOOBIG) This is one point that I was uncertain about in handling IPV6_RECVPATHMTU. Assuming the application uses 2 sockets (one to send and one to receive) it would never know to adjust the size of the packets without something like ETOOBIG on the sendto/sendmsg (btw, this is a case with traceroute6 as it's using UDP instead of RAW sockets). So, it sounds like a sending error would be needed where possible (as you said, its not available in streams). > as long as it it sending packets larger > than the link MTU (or larger than a cached path MTU - is > the path MTU interaction an issue here? Should the kernel > just check the link MTU and ignore the path MTU for this type of > traceroute?) Path MTU interaction is not really an issue as any application that does this, would know the mtu from IPV6_PATHMTU ancillary data and would reset IPV6_USEMTU with that value. (in case of traceroute, it can process ICMP6_PACKET_TOO_BIG to get the value). -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working 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 Apr 10 04:36:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3ABZ8D00516 for ipng-dist; Mon, 10 Apr 2000 04:35:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3ABYm700505 for ; Mon, 10 Apr 2000 04:34:49 -0700 (PDT) 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 EAA11196 for ; Mon, 10 Apr 2000 04:34:46 -0700 (PDT) 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 EAA19686 for ; Mon, 10 Apr 2000 04:34:46 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05578; Mon, 10 Apr 2000 07:34:44 -0400 (EDT) Message-Id: <200004101134.HAA05578@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-site-prefixes-04.txt Date: Mon, 10 Apr 2000 07:34:44 -0400 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 : Site prefixes in Neighbor Discovery Author(s) : E. Nordmark Filename : draft-ietf-ipngwg-site-prefixes-04.txt Pages : 22 Date : 06-Apr-00 This document specifies extensions to IPv6 Neighbor Discovery to carry site prefixes. The site prefixes are used to reduce the effect of site renumbering by ensuring that the communication inside a site uses site-local addresses. This protocol requires that all IPv6 implementations, even those that do not implement this protocol, ignore all site-local addresses that they retrieve from the DNS when the AAAA or A6 RRset contain both global and site-local addresses. If the RRset contains only site- local addresses those addresses can be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-04.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-site-prefixes-04.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-site-prefixes-04.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: <20000407074929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-site-prefixes-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000407074929.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 Mon Apr 10 06:32:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3ADUSp00694 for ipng-dist; Mon, 10 Apr 2000 06:30:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3ADUE700687 for ; Mon, 10 Apr 2000 06:30:17 -0700 (PDT) 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 GAA25285 for ; Mon, 10 Apr 2000 06:29:46 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15409 for ; Mon, 10 Apr 2000 07:29:45 -0600 (MDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id QAA11140; Mon, 10 Apr 2000 16:29:40 +0300 (EET DST) Date: Mon, 10 Apr 2000 16:29:40 +0300 (EET DST) From: Markku Savela Message-Id: <200004101329.QAA11140@anise.tte.vtt.fi> To: ipng@sunroof.eng.sun.com Subject: Use of "IPv6" headers in IPv4? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I sent a message earlier to the list, but it appears to have lost] While implementin a dual IPv6/Ipv4 stack I observed that the code was happy to reply to ICMP6 Echo requests (protocol 58) that were directly under IPv4 header (and my PING program was happy too...). Similar feature seems to apply many other "IPv6" headers, I could have Destination options, IPv6 fragment headers, etc. in plain IPv4. Hmm.. Home address option? Routing headers? The question is how much extra effort should I put into disabling these things, or can I just call it a "feature"? :-) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -------------------------------------------------------------------- IETF IPng Working 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 Apr 10 07:23:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3AEKNL00762 for ipng-dist; Mon, 10 Apr 2000 07:20:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3AEKD700755 for ; Mon, 10 Apr 2000 07:20:14 -0700 (PDT) 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 HAA22713 for ; Mon, 10 Apr 2000 07:20:13 -0700 (PDT) Received: from audrey.enst-bretagne.fr (audrey.enst-bretagne.fr [192.108.115.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27940 for ; Mon, 10 Apr 2000 07:20:10 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by audrey.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA16761; Mon, 10 Apr 2000 16:19:55 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA11833; Mon, 10 Apr 2000 16:19:54 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA13923; Mon, 10 Apr 2000 16:25:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200004101425.QAA13923@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipng@sunroof.eng.sun.com Subject: Re: Use of "IPv6" headers in IPv4? In-reply-to: Your message of Mon, 10 Apr 2000 16:29:40 +0300. <200004101329.QAA11140@anise.tte.vtt.fi> Date: Mon, 10 Apr 2000 16:25:10 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: [I sent a message earlier to the list, but it appears to have lost] => I've never seen it... While implementin a dual IPv6/Ipv4 stack I observed that the code was happy to reply to ICMP6 Echo requests (protocol 58) that were directly under IPv4 header (and my PING program was happy too...). => and your ICMPv6 checksum check too? Similar feature seems to apply many other "IPv6" headers, I could have Destination options, IPv6 fragment headers, etc. in plain IPv4. Hmm.. Home address option? Routing headers? => I can't find a reasonable meaning when an address is involved (case of the home address option or not empty/useless routing headers). The question is how much extra effort should I put into disabling these things, or can I just call it a "feature"? :-) => you can get two problems: - an IPv6 header and an IPv4 protocol with the same number but nothing else in common (both spaces are 8 bit long, this is both large and narrow :) - pseudo-headers are very different for IPv4 and IPv6. IMHO the only reasonable way to mix directly IPv4 and IPv6 is by encapsulation (link-layer addresses for IPv6 over IPv4 tunnels, as in 6over4 (RFC 2529), are another case but addresses are not at the same layer). Regards 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 Apr 10 07:46:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3AEiQE00781 for ipng-dist; Mon, 10 Apr 2000 07:44:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3AEiE700774 for ; Mon, 10 Apr 2000 07:44:15 -0700 (PDT) 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 HAA02797 for ; Mon, 10 Apr 2000 07:44:14 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10900 for ; Mon, 10 Apr 2000 07:44:12 -0700 (PDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id RAA11579; Mon, 10 Apr 2000 17:43:58 +0300 (EET DST) Date: Mon, 10 Apr 2000 17:43:58 +0300 (EET DST) From: Markku Savela Message-Id: <200004101443.RAA11579@anise.tte.vtt.fi> To: Francis.Dupont@enst-bretagne.fr CC: ipng@sunroof.eng.sun.com In-reply-to: <200004101425.QAA13923@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Mon, 10 Apr 2000 16:25:10 +0200) Subject: Re: Use of "IPv6" headers in IPv4? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => and your ICMPv6 checksum check too? Yes, naturally. The ICMPv6 checksum does not care what the IP header was (of course, in ICMP6 in IPv4 case the pseudoheader is computed using IPv4 mapped addresses). > => you can get two problems: > - an IPv6 header and an IPv4 protocol with the same number but nothing > else in common (both spaces are 8 bit long, this is both large > and narrow :) I can see that a router advertisement ICMP will not work inside Ipv4 frame, because there is no equivalent of link local address in Ipv4, but this is required for router advertisement. But, unless no similar "second level rule" prevents fully processing IPv6 header inside IPv4, then why not let it go? That was my question about... > - pseudo-headers are very different for IPv4 and IPv6. As said, in case of IPv4, the IPv6 upper layer pseudoheaders are computed using IPv4 mapped addresses. Seems to work fine for TCP and UDP, same code works for both IPv4 and IPv6. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -------------------------------------------------------------------- IETF IPng Working 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 Apr 10 12:13:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3AJBZJ01131 for ipng-dist; Mon, 10 Apr 2000 12:11:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3AJBQ701124 for ; Mon, 10 Apr 2000 12:11:27 -0700 (PDT) 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 MAA00265 for ; Mon, 10 Apr 2000 12:11:26 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22342 for ; Mon, 10 Apr 2000 13:11:25 -0600 (MDT) Received: from localhost (rglr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id PAA04239; Mon, 10 Apr 2000 15:11:50 -0400 (EDT) Date: Mon, 10 Apr 2000 15:11:50 -0400 From: Ray LaRocca To: ipng@sunroof.eng.sun.com cc: Ray LaRocca Subject: UNH Cthon, Forum results Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello All, The following are the results of the UNH testing at Connectathon 2000 and the IPv6 Forum meeting in Telluride. Connectathon 2000: 1. 15 IPv6 implementations were present (5 times as many as last year) 2. We tested Mobile IPv6, RIPng and BGP4+ interoperability (as well as some conformance testing) IPv6 Forum, Telluride: 1. 7 IPv6 implementations were present 2 We tested RIPng, BGP4+, and tunneling interoperability (some conformance testing here also) --------------------------------------------------------------- Mobility testing at Connectathon: --------------------------------------------------------------- Participants: ENST Bretagne, Ericsson, Ericsson-Telebit, Microsoft Research, NEC, Nokia Implementations present: 5 home agents, 3 mobile nodes, 4 correspondent nodes Testing Highlights: Approximately 20 interoperability tests were run over the course of the 3 days of testing. We had a moderate level of interoperability even though the implementations were in various stages of development (version 8, 9, and 10 of the spec were present). The participants spent much of the time debugging and modifying their code. Testing Topology: 4 networks connected via a single mobile unaware v6 router. Testing Scenarios: (A) 1. A home agent, mobile node pair begin on the home network with a correspondent node residing on a foreign network. 2. The mobile node moves from the home network to a foreign network while pinging the correspondent node. 3. The mobile node then moves from a foreign network to another foreign network continuing to ping the correspondent node. 4. The mobile node then moves to the foreign network where the correspondent node resides (still pinging) 5. The mobile node returns home. (B) The same as above except with a telnet session open between the mobile node and the correspondent node. We were able to achieve success in both of the above scenarios. Issues/Questions: 1. Versions 8, 9, and 10 of the spec were present. 2. There were issues involving DAD when the mobile node returned home (this has been addressed in version 11 of the spec) 3. Issues with option ordering in the packet have also been addressed in version 11 of the spec 4. There was an implementation incorrectly detecting movement by detecting the different EUI-64 of the router. In our setup the router was using the same EUI-64 for each of its interfaces thus causing difficulty for that implementation to detect movement. This issue was presented to Dave Johnson and he has addressed this issue to the mobileip working group. What Next? 1. We need to have an interoperability test event within 6 months to include Mobile IPv4, DIAMETER, and Mobile IPv6, with IPsec interaction. (TBD) 2. UNH IOL has developed Mobile IPv6 conformance tests and is currently providing the testing service. --------------------------------------------------------------- Routing and conformance testing at both Connectathon and IPv6 Forum --------------------------------------------------------------- Participants: 3Com, Cisco, COMPAQ, Ericsson-Telebit, HP, Hitachi, KAME, Microsoft Research, NOKIA, Nortel, SCO, SGI, SUN RIPng: 1. 14 implementations with nearly 100% interoperability 2. Some minor issues that were implementation-specific 3. The basic setup was all routers on the same network with some configured routes being advertised. 4. 1 question regarding advertising a prefix for a network on the actual network was posted to the ipng mailing list. Implementations were doing one of 3 things: advertise the prefix with metric 1, metric 16, or not advertise it at all. BGP4+: 1. 9 implementations with nearly 100% interoperability 2. Some minor issues that were implementation-specific 3. The basic setup was all routers on the same network establishing both internal and external peer sessions with other routers. --------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working 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 Apr 14 03:05:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3EA3Ed04156 for ipng-dist; Fri, 14 Apr 2000 03:03:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3E9o6704140 for ; Fri, 14 Apr 2000 02:50:13 -0700 (PDT) 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 CAA13016 for ; Fri, 14 Apr 2000 02:49:47 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24359 for ; Fri, 14 Apr 2000 02:49:45 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fffe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA12197; Fri, 14 Apr 2000 18:37:37 +0900 (JST) Date: Fri, 14 Apr 2000 18:48:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcp-v6@bucknell.edu Cc: ipng@sunroof.eng.sun.com Subject: current status of DHCPv6 User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 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: 14 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'd like to know the current status of DHCPv6. As far as know, DHCPv6 has not been published as an RFC, but the latest draft draft-ietf-dhc-dhcpv6-15.txt has already expired. Which document should I refere to now? 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 Apr 14 16:53:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3ENpg004688 for ipng-dist; Fri, 14 Apr 2000 16:51:42 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3ENpb704681 for ; Fri, 14 Apr 2000 16:51:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id QAA04290 for ipng@sunroof.eng.sun.com; Fri, 14 Apr 2000 16:51:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3EMt1704637 for ; Fri, 14 Apr 2000 15:55:01 -0700 (PDT) Received: from dhcptest86-c (dhcptest86-c.Eng.Sun.COM [129.146.86.200]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3EMt0w578557; Fri, 14 Apr 2000 15:55:00 -0700 (PDT) Date: Fri, 14 Apr 2000 15:54:10 -0700 (PDT) From: "Michael W. Carney" Reply-To: "Michael W. Carney" Subject: Re: current status of DHCPv6 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com, dhcp-v6@bucknell.edu 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 Hi jinmei-san, Our plan (dhcpv6 authors) is to produce 3 drafts on the road to pittsburg. The roadmap is as follows: a) DHCPv6 protocol and extension drafts ready for review on May 5th. We'll collect input until May 19th. b) We'll release an updated set of drafts on June 2nd. We'll collect input on these drafts until June 16. c) We'll release another set of drafts on June 30th, collecting any input which we'll roll into what we hope would be the final draft by the July 14th pittsburg publishing deadline. Of course, if the initial drafts are so wonderful that we don't need b+c, that's fine too. ;^) I hope you'll participate in the review of the drafts! Thanks, Mike Carney SNT Internet Engineering Sun Microsystems, Inc. (650) 786-4171 Mailstop UMPK17-202 901 San Antonio Rd Palo Alto, CA 94303 -------------------------------------------------------------------- IETF IPng Working 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 Apr 17 00:14:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3H7D8A05450 for ipng-dist; Mon, 17 Apr 2000 00:13:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3H7Cv705443 for ; Mon, 17 Apr 2000 00:12:58 -0700 (PDT) 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 AAA16780; Mon, 17 Apr 2000 00:12:58 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA21311; Mon, 17 Apr 2000 00:12:54 -0700 (PDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA21478; Mon, 17 Apr 2000 16:00:56 +0900 (JST) Date: Mon, 17 Apr 2000 16:12:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: permission control for IPV6_REACHCONF User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 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: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, According to draft-ietf-ipngwg-rfc2292bis-01.txt, it seems to me that any users can set IPV6_REACHCONF cmsg type for an outgoing UDP/raw-IPv6 packet. However, this option might be dangerous in some situations. Consider the following scenario: - A node "A" resolves the link-layer address of another node "B", and then starts communicating with B. - After starting the communication, a malicious user opens a UDP socket to B, and continuously sends packets to B with the IPV6_REACHCONF option. - Then the neighbor cache entry for B will never be stale, and NUD will never occur even if B is down. I'm not sure if we should regard such a scenario as a threat, but it would be much safer to limit use of the option to privileged users. I'd like to know your (and other implementors') opinion this. Thanks. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. KAME's latest implementation has (experimentally) introduced the restriction. -------------------------------------------------------------------- IETF IPng Working 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 Apr 17 00:48:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3H7kKh05493 for ipng-dist; Mon, 17 Apr 2000 00:46:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3H7kB705486 for ; Mon, 17 Apr 2000 00:46:12 -0700 (PDT) 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 AAA26781; Mon, 17 Apr 2000 00:46:09 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05721; Mon, 17 Apr 2000 00:46:07 -0700 (PDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA21694; Mon, 17 Apr 2000 16:34:04 +0900 (JST) Date: Mon, 17 Apr 2000 16:45:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael.Carney@eng.sun.com Cc: ipng@sunroof.eng.sun.com, dhcp-v6@bucknell.edu Subject: Re: current status of DHCPv6 In-Reply-To: In your message of "Fri, 14 Apr 2000 15:54:10 -0700 (PDT)" References: User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 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: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 14 Apr 2000 15:54:10 -0700 (PDT), >>>>> "Michael W. Carney" said: > Our plan (dhcpv6 authors) is to produce 3 drafts on the road to pittsburg. The > roadmap is as follows: > a) DHCPv6 protocol and extension drafts ready for review on May 5th. We'll > collect input until May 19th. Thanks for the information. Then I'm looking forward to the next version. > b) We'll release an updated set of drafts on June 2nd. We'll collect input on > these drafts until June 16. > c) We'll release another set of drafts on June 30th, collecting any input > which we'll roll into what we hope would be the final draft by the July 14th > pittsburg publishing deadline. > Of course, if the initial drafts are so wonderful that we don't need b+c, > that's fine too. ;^) > I hope you'll participate in the review of the drafts! Sure. Actually, I have some comments on the dhcpv6-14 draft (this is the only version that I can get), but I won't send them since they might now be meaningless. I'd just wait for the next version. 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 Mon Apr 17 19:39:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3I2bap06132 for ipng-dist; Mon, 17 Apr 2000 19:37:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3I2bR706125 for ; Mon, 17 Apr 2000 19:37:27 -0700 (PDT) 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 TAA01588 for ; Mon, 17 Apr 2000 19:37:27 -0700 (PDT) Received: from mail.rdc1.wa.home.com (ha1.rdc1.wa.home.com [24.0.2.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA07161 for ; Mon, 17 Apr 2000 19:37:26 -0700 (PDT) Received: from c752132-d.sttln1.wa.home.com ([24.0.234.225]) by mail.rdc1.wa.home.com (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20000418023726.BTJB7733.mail.rdc1.wa.home.com@c752132-d.sttln1.wa.home.com> for ; Mon, 17 Apr 2000 19:37:26 -0700 Received: from c1037490-a.gocougs.wsu.edu (unverified [24.14.234.113]) by c752132-d.sttln1.wa.home.com (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 17 Apr 2000 19:39:59 -0700 Message-Id: <4.3.1.0.20000417193429.00b13578@c752132-d.sttln1.wa.home.com> X-Sender: furness@c752132-d.sttln1.wa.home.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 17 Apr 2000 19:36:38 -0700 To: ipng@sunroof.eng.sun.com From: Grant Furness Subject: FreeBSD 4.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I loaded FreeBSD 4.0 on my box to run IPv6. I am having trouble installing inet6d on the box, so it won't put an IPv6 address on the interface. I gotta be missing something really easy, here. If anybody could clue me in as to how to install inet6, I would be most grateful., Thanks; furness -------------------------------------------------------------------- IETF IPng Working 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 Apr 17 20:37:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3I3ZVO06185 for ipng-dist; Mon, 17 Apr 2000 20:35:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3I3ZL706178 for ; Mon, 17 Apr 2000 20:35:21 -0700 (PDT) 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 UAA14317 for ; Mon, 17 Apr 2000 20:35:19 -0700 (PDT) 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 UAA24052 for ; Mon, 17 Apr 2000 20:35:19 -0700 (PDT) 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 MAA28945; Tue, 18 Apr 2000 12:34:59 +0900 (JST) To: Grant Furness cc: ipng@sunroof.eng.sun.com In-reply-to: furness's message of Mon, 17 Apr 2000 19:36:38 MST. <4.3.1.0.20000417193429.00b13578@c752132-d.sttln1.wa.home.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: FreeBSD 4.0 From: itojun@iijlab.net Date: Tue, 18 Apr 2000 12:34:59 +0900 Message-ID: <28943.956028899@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I loaded FreeBSD 4.0 on my box to run IPv6. I am having trouble installing >inet6d on the box, so it won't put an IPv6 address on the interface. I >gotta be missing something really easy, here. If anybody could clue me in >as to how to install inet6, I would be most grateful., ipngwg is a place to discuss specification, not a place for particular implementation(s). in this case, users@ipv6.org, freebsd-net@freebsd.org or snap-users@kame.net would be more appropriate. anyway. you do not need inet6d, you only need inetd with "tcp6" in /etc/inetd.conf. also your description does not really describe your situation. you may want to paste output from "ifconfig -a", "netstat -in", "netstat -rn" and alike. (on place othr than ipngwg, of course) 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 Apr 19 10:13:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3JHBno07596 for ipng-dist; Wed, 19 Apr 2000 10:11:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3JHBe707589 for ; Wed, 19 Apr 2000 10:11:40 -0700 (PDT) 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 KAA00969 for ; Wed, 19 Apr 2000 10:11:39 -0700 (PDT) Received: from tweety.fe.up.pt (tweety.fe.up.pt [193.136.28.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13357 for ; Wed, 19 Apr 2000 11:11:29 -0600 (MDT) Received: from lorosae.fe.up.pt (lorosae.fe.up.pt [193.136.28.35]) by tweety.fe.up.pt (8.9.3/8.9.3) with ESMTP id SAA05623 for ; Wed, 19 Apr 2000 18:11:18 +0100 (WET DST) Received: from fe.up.pt (bean.fe.up.pt [193.136.28.69]) by lorosae.fe.up.pt (8.9.3/8.9.3) with ESMTP id SAA28050 for ; Wed, 19 Apr 2000 18:11:17 +0100 (WET DST) Message-ID: <38FDE8A9.8ACFCA96@fe.up.pt> Date: Wed, 19 Apr 2000 18:11:05 +0100 From: "Tito Carlos S. Vieira" X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: IP Next Generation Subject: Browser Ipv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Where i can find, to download, one Ipv6 Browser for Linux? Thanks Tito -------------------------------------------------------------------- IETF IPng Working 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 Apr 25 07:23:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3PELcq11379 for ipng-dist; Tue, 25 Apr 2000 07:21:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3PELR711372 for ; Tue, 25 Apr 2000 07:21:27 -0700 (PDT) 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 HAA13906 for ; Tue, 25 Apr 2000 07:21:27 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18705 for ; Tue, 25 Apr 2000 08:21:25 -0600 (MDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id RAA21186; Tue, 25 Apr 2000 17:21:23 +0300 (EET DST) Date: Tue, 25 Apr 2000 17:21:23 +0300 (EET DST) From: Markku Savela Message-Id: <200004251421.RAA21186@anise.tte.vtt.fi> To: ipng@sunroof.eng.sun.com Sent-via: ipng@sunroof.eng.sun.com Subject: IPv6 Source address selection.. Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just throwing some ideas and questions... the draft draft-ietf-ipngwg-default-addr-select-00.txt uses at one stage CommonPrefixLen(SA, D) as a comparison value to select between candidate source addresses (prefixes). This is simple common bits counted from left ("most significant end"), right? In our code we use following ComparisonValue(SA, D), returns prefixlength, if the common bits covers the prefix, and (common bits - prefixlength), when match is less (e.g. this value is always negative) This prefers the longest prefix that matches fully. If none matches, it prefers the prefix with least differing bits in the "routing part". "My version" differs only when none of the prefixes match fully. For example, if D=xxxyyy... (x = 4bit unit) SA= xxxzzzz/32 CommonPrefixLen=12 ComparisonValue= -20 SB= xxz/12 CommonPrefixlen=8 ComparisonValue= -4 CommonPrefix would select SA, ComparisonValue would select SB. Just food for thoughts ... :) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -------------------------------------------------------------------- IETF IPng Working 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 Apr 26 09:54:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3QGq7h12203 for ipng-dist; Wed, 26 Apr 2000 09:52:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3QGpx712196 for ; Wed, 26 Apr 2000 09:51:59 -0700 (PDT) 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 JAA22930 for ; Wed, 26 Apr 2000 09:51:58 -0700 (PDT) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11086 for ; Wed, 26 Apr 2000 10:51:55 -0600 (MDT) Received: from gateway (h004005a2eb98.ne.mediaone.net [24.147.209.173]) by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id MAA27608; Wed, 26 Apr 2000 12:51:52 -0400 (EDT) Message-Id: <4.1.20000426124126.043bd840@pop.ne.mediaone.net> X-Sender: loshin@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 26 Apr 2000 12:50:36 -0400 To: ipng@sunroof.eng.sun.com, 6bone@isi.edu, deployment@ipv6.org From: Pete Loshin Subject: Looking for panel members for ISPCON session Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, and please accept my apologies for the cross-posting. I'm chairing a one-hour session on IPv6 and commercial ISP deployment for the upcoming IPSCON event in Orlando Florida. Please let me know if you plan to be in town for that event and would be interested in participating (along with a thumbnail c.v.). Thanks! -pl +-------------------------------------------------------------+ | Pete Loshin http://Internet-Standard.com | | | | _IPv6 Clearly Explained_ Morgan Kaufmann January 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working 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 Apr 26 23:13:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3R6C8t12868 for ipng-dist; Wed, 26 Apr 2000 23:12:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3R6Bx712861 for ; Wed, 26 Apr 2000 23:11:59 -0700 (PDT) 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 XAA00339 for ; Wed, 26 Apr 2000 23:12:01 -0700 (PDT) Received: from un.cct.ydc.co.jp (ydcspingw.ydc.co.jp [202.33.211.252]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA29609 for ; Thu, 27 Apr 2000 00:11:58 -0600 (MDT) Received: from italy (Italy.cct.ydc.co.jp [10.21.0.135]) by un.cct.ydc.co.jp (8.9.1+3.1W/3.7W) with ESMTP id PAA02543; Thu, 27 Apr 2000 15:14:00 +0900 (JST) Message-Id: <4.2.0.58.J.20000427150107.028ce170@un.cct.ydc.co.jp> X-Sender: miyata@imap.cct.ydc.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 27 Apr 2000 15:10:04 +0900 To: ipng@sunroof.eng.sun.com From: Hiroshi Miyata Subject: 2nd TAHI IPv6 Interoperabiliyte Test Event Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! We at the TAHI Project plans to hold an interoperability test event with the following detail in July, 2000, just before the INET2000 JAPAN and at the same site with the INET2000 JAPAN. We are happy to invite you to participate in the event and look forward to meeting you at the event. ----------------------------------------------- 2nd TAHI IPv6 Interoperability Test Event <> Sunday, July 16 8:45 Registration 10:00 - 10:30 Opening & Briefing 10:30 - 18:00 Testing Session Monday, July 17 8:45 Registration 9:00 - 18:00 Testing Session Tuesday, July 18 8:45 Registration 9:00 - 15:00 Testing Session <> Pacifico Yokohama Conference Center (ROOM 511 and 512) 1-1-1, Minato Mirai, Nishi-ku, Yokohama, Japan TEL : 81-45-221-2155 <> Please register by Friday, June 16, 2000. You can get the registration form at http://www.tahi.org/inop/2ndinterop.html <> Conformance Test Interoperability Test <> The conformance test will be performed for your implementations suiting to your requirements. IPsec test suite is now available. You can select functions to test from the following menu. IPv6 Specification ICMPv6 for IPv6 Specification Neighbor Discovery for IP Version 6 IPv6 Stateless Address Autoconfiguration IPv6 Path MTU Discovery IPsec AH and ESP for IPv6 (New) IPsec AH and ESP for IPv4 (New) IPv6 over IPv4 Tunnel Robustness Please visit our site for more detail and example. http://www.tahi.org/report/KAME/ Interoperability test with other implementations. Our staff will coordinate the test about the following function. Routing Primarily, RIPng and BGP4+, but other protocols such as OSPF are welcome too. Transition (experimental) If you have a transition function you want to test, please inform us of a type of your transition function. You can find more detail information at the URL below. http://www.tahi.org/ Please visit and check it. If you have question please send email to contact@tahi.org. Thanks, ----------------------------- Hiroshi Miyata @ TAHI project -------------------------------------------------------------------- IETF IPng Working 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 Apr 27 11:51:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3RIoIb13198 for ipng-dist; Thu, 27 Apr 2000 11:50:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3RIoA713191 for ; Thu, 27 Apr 2000 11:50:10 -0700 (PDT) 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 LAA05214 for ; Thu, 27 Apr 2000 11:50:08 -0700 (PDT) Received: from maredsous.monarch.cs.cmu.edu (MAREDSOUS.MONARCH.CS.CMU.EDU [128.2.250.149]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18638 for ; Thu, 27 Apr 2000 11:50:07 -0700 (PDT) Received: from maredsous.monarch.cs.cmu.edu (localhost [127.0.0.1]) by maredsous.monarch.cs.cmu.edu id OAA26786; Thu, 27 Apr 2000 14:57:18 -0400 (EDT) To: mobile-ip@standards.nortelnetworks.com, ipng@sunroof.eng.sun.com From: Dave Johnson Reply-To: Dave Johnson Subject: New version of "Mobility Support in IPv6" draft Date: Thu, 27 Apr 2000 14:57:18 -0400 Message-ID: <26784.956861838@maredsous.monarch.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted a revised version of the Internet-Draft "Mobility Support in IPv6", which corrects a number of minor problems and adds several clarifications over the previous version of the draft. Here is a list of some of the changes since the previous version: - Moved the definition of IPsec requirements for Binding Updates and Binding Acknowledgements to Section 4.4), giving this important information its own specific section with a section title (IPsec Requirements for Mobile IPv6 Destination Options) that will be identifiable in the table of contents for this document. This makes these requirements harder to miss than where they were defined in Sections 5.1 and 5.2, mixed in with the definition of the format of these destination options. - In Section 4.6, added a precise definition of Sequence Number value comparison modulo 2**16. Also added a reference to this definition in each other place where Sequence Number comparison is discussed. - Added a statement in Section 9.5 to clarify the sending of a Neighbor Advertisement message by the home agent on behalf of the mobile node in order to intercept packets addressed to the mobile node. Except for the specific fields defined there, all fields in each such Neighbor Advertisement SHOULD be set in the same way they would be set by the mobile node itself if sending this Neighbor Advertisement while at home [17]. - In Section 10.6, specified that the Lifetime in the Binding Update sent by a mobile node to its home agent SHOULD be less than or equal to the remaining lifetime of the home address and the care-of address specified for the binding. - In Section 10.8, modified the specification that was there about the correct setting of the Lifetime in the Binding Update sent by a mobile node to a correspondent node. The original specification stated that the Lifetime value MUST be no greater than the remaining lifetime of the mobile node's home registration of its primary care-of address at its home agent. However, there should be no necessary relationship between the remaining lifetime of a home registration and the lifetime of a binding at a correspondent node. Instead, as with the home registration Binding Update, the Lifetime in the Binding Update sent by a mobile node to a correspondent node SHOULD be less than or equal to the remaining lifetime of the home address and the care-of address specified for the binding. - In Section 5.4, added a statement that a packet MUST NOT contain more than one Home Address option, except that an encapsulated packet [4] MAY contain a separate Home Address option associated with each encapsulating IP header. - In Section 4.6, added a new field in the Binding Update List entry format to record the initial value of the Lifetime field sent in that Binding Update. - In Section 10.12, defined a new step in processing a received Binding Acknowledgement: if the value specified in the Lifetime field in the Binding Acknowledgement is less than the Lifetime value sent in the Binding Update being acknowledged, then the mobile node MUST subtract the difference between these two Lifetime values from the remaining lifetime for the binding as maintained in the corresponding Binding Update List entry. The effect of this step is to correctly manage the mobile node's view of the binding's remaining lifetime (as maintained in the corresponding Binding Update List entry) so that it correctly counts down from the Lifetime value given in the Binding Acknowledgement, but with the timer countdown beginning at the time that the Binding Update was sent. This change also affected Section 10.8 in sending Binding Updates, to record both the original lifetime and the remaining lifetime in the Binding Update List. - In Sections 5.1 and 9.3, clarified that the Duplicate Address Detection performed by the home agent if the Duplicate Address Detection (D) bit is set in the Binding Update, is performed before returning the Binding Acknowledgement for that Binding Update. - In Section 5.1, clarified that the mobile node SHOULD set the Duplicate Address Detection (D) bit in its home registration Binding Updates based on any requirements for Duplicate Address Detection that would apply to the mobile node if it were at home [17, 27]. - In Section 9.3, specified that a home agent, when performing Duplicate Address Detection for a mobile node when the Duplicate Address Detection (D) bit is set in a received Binding Update, SHOULD NOT delay sending the initial Neighbor Solicitation message of Duplicate Address Detection by the random delay specified for normal processing of Duplicate Address Detection [17, 27]. - In Section 10.5, defined special considerations for a mobile node's use of Duplicate Address Detection upon forming a new care-of address. In particular, the mobile node MAY begin using the new care-of address without performing Duplicate Address Detection, and MAY optionally bypass Duplicate Address Detection or begin Duplicate Address Detection asynchronously when it begins use of the address, allowing the Duplicate Address Detection procedure to complete in parallel with normal communication using the address. In addition, the mobile node SHOULD NOT delay sending the initial Neighbor Solicitation message of Duplicate Address Detection by the random delay specified for normal processing of Duplicate Address Detection [17, 27], unless the mobile node is initializing after rebooting. - In Section 4.6, added a clarification to the definition of the Binding Update List, that for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. This was already noted in previous versions of the draft in the sending of Binding Updates, as defined in Section update-corresp, but was not previously stated explicitly in the definition of the Binding Update List conceptual data structure. - In Section 9.3, added a specification that the lifetime for the Binding Cache entry (and thus the Lifetime value returned in the Binding Acknowledgement) MUST NOT be greater than the Lifetime value specified in the Binding Update. Also added a similar specification (and clarification) in Section 8.3 for the Binding Cache entry in a correspondent node. - In Section 10.6, added a clarification that, when sending a Binding Update to its home agent, the mobile node MUST also create or update the corresponding Binding Update List entry, as specified in Section 10.8. The official announcement of the draft should appear on the mailing lists shortly, but you can get a copy of the new draft now from http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-12.txt We expect to go to Last Call on this version of the draft shortly. Please send any comments on the draft to the Mobile IP mailing list at mobile-ip@standards.nortelnetworks.com. Thanks. Dave -- David B. Johnson dbj@cs.cmu.edu Associate Professor http://www.cs.cmu.edu/~dbj/ Computer Science Department http://www.monarch.cs.cmu.edu/ Carnegie Mellon University Phone: (412) 268-7399 5000 Forbes Avenue Fax: (412) 268-5576 Pittsburgh, PA 15213-3891 -------------------------------------------------------------------- IETF IPng Working 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 Apr 27 18:33:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3S1VS713519 for ipng-dist; Thu, 27 Apr 2000 18:31:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3S1VJ713512 for ; Thu, 27 Apr 2000 18:31:19 -0700 (PDT) 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 SAA19726 for ; Thu, 27 Apr 2000 18:31:18 -0700 (PDT) Received: from gate.alliedtelesyn.co.nz ([202.49.72.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA27301 for ; Thu, 27 Apr 2000 18:31:17 -0700 (PDT) Received: (qmail 20821 invoked from network); 28 Apr 2000 01:30:39 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.72.92) by gate-int.alliedtelesyn.co.nz with SMTP; 28 Apr 2000 01:30:39 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 28 Apr 00 13:36:08 +1300 Received: from SpoolDir by ASLAN (Mercury 1.47); 28 Apr 00 13:36:03 +1300 From: "Sean Lin" Organization: Allied Telesyn Intl Ltd., Chch, NZ To: ipng@sunroof.eng.sun.com Date: Fri, 28 Apr 2000 13:35:58 +1200 (NZT) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: icmpv6 group messages Reply-to: sean.lin@alliedtelesyn.co.nz Message-ID: <3909937B.28845.BF556A@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I must have missed it out somewhere but can anyone tell me where in the RFCs do they specify the format of the ICMPv6 Group Membership messages? Cheers, Sean -------------------------------------------------------------------- IETF IPng Working 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 Apr 27 23:32:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3S6UfN13686 for ipng-dist; Thu, 27 Apr 2000 23:30:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3S6UV713679 for ; Thu, 27 Apr 2000 23:30:31 -0700 (PDT) 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 XAA03421 for ; Thu, 27 Apr 2000 23:30:32 -0700 (PDT) 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 AAA15246 for ; Fri, 28 Apr 2000 00:30:31 -0600 (MDT) 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 XAA19077; Thu, 27 Apr 2000 23:29:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <3909937B.28845.BF556A@localhost> References: <3909937B.28845.BF556A@localhost> Date: Thu, 27 Apr 2000 23:30:10 -0700 To: sean.lin@alliedtelesyn.co.nz From: Steve Deering Subject: Re: icmpv6 group messages Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:35 PM +1200 4/28/00, Sean Lin wrote: >I must have missed it out somewhere but can anyone tell me where in the >RFCs do they specify the format of the ICMPv6 Group Membership messages? Sean, They're in RFC 2710, "Multicast Listener Discovery (MLD) for IPv6". 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 Sun Apr 30 07:53:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e3UEpeI14678 for ipng-dist; Sun, 30 Apr 2000 07:51:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3UEpP714671 for ; Sun, 30 Apr 2000 07:51:25 -0700 (PDT) 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 HAA26863 for ; Sun, 30 Apr 2000 07:51:24 -0700 (PDT) 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 HAA23139 for ; Sun, 30 Apr 2000 07:51:23 -0700 (PDT) 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 XAA14523; Sun, 30 Apr 2000 23:51:19 +0900 (JST) To: snap-users@kame.net cc: ipng@sunroof.eng.sun.com, linux-ipv6@inner.net In-reply-to: yoshfuji's message of Sun, 30 Apr 2000 23:36:13 JST. <20000430233613H.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: socklen_t vs size_t From: itojun@iijlab.net Date: Sun, 30 Apr 2000 23:51:19 +0900 Message-ID: <14521.957106279@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Glibc people has recently changed prototypes of getnameinfo() and >inet_ntop etc. (size_t -> socklen_t) like this: I believed socklen_t is only for measuring length of sockaddr, not others. 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 --------------------------------------------------------------------