From owner-ipng@sunroof.eng.sun.com Wed Oct 1 04:25:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA27988; Wed, 1 Oct 1997 04:16:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA27981; Wed, 1 Oct 1997 04:16:25 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA23634; Wed, 1 Oct 1997 04:16:23 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA11839 for ; Wed, 1 Oct 1997 04:16:23 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id EAA10567; Wed, 1 Oct 1997 04:15:53 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id EAA21295; Wed, 1 Oct 1997 04:15:50 -0700 (MST) Message-Id: <199710011115.EAA21295@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 1 Oct 1997 04:15:50 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 4605) Re: Update to RFC 2133 Cc: bound@zk3.dec.com, thartric@mentat.com (Tim Hartrick) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2309 [In your message of Sep 30, 10:24pm you write:] > > Not. There are two issues at hand: > > 1. Vendor - Each of us have to merge our threads strategy into each > new resolver BIND release. This can be avoided if the underlying > APIs are by definiition MT Safe via the IPv6 APIs. It saves > cost for each vendor. And if anyone who is not a vendor doing > this tells me it doesn't I will say you don't know what > your talking about and speaking from a perceived opinion > not a real one. And why is the threads safety of the underlying DNS resolver API an IPng mailing list issue? I don't disagree with this point of yours at all, I just don't think it's relevant to IPng. If some group of vendors want to get together and require the resolver be MT-safe, then they should do that. That sounds like an OpenGroup issue to me, and indeed they could have done this with Unix 98 but they chose to explicitly state that all the name translation function need *not* be MT-safe. > 2. ISVs have an actual gurantee that the API is thread safe in a > uniform manner across all platforms. I would rather use the > same MT safe API on each platform for IPv6, than have to assume > the same behavior on each platform. Then use getaddrinfo(). It was designed from day one to be thread safe. > getaddrinfo() is a red herring. Ah, this seems to be the real issue, and something I doubt we'll agree on. > So far (except for Tim ??) I have > not seen one major vendor on this list say they don't think we need this > feature. I think that says something too. I also have not seen one ISV > say they don't need this either, or say they will use getaddrinfo(). No, I think this means that there are not too many ISVs on this list, and that lots of people are just ignoring this thread. This is mainly a protocols group, not a sockets API group. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 1 04:42:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA28013; Wed, 1 Oct 1997 04:32:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA27996; Wed, 1 Oct 1997 04:32:07 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA24788; Wed, 1 Oct 1997 04:32:00 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA15350 for ; Wed, 1 Oct 1997 04:31:56 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id EAA10929; Wed, 1 Oct 1997 04:31:54 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id EAA21371; Wed, 1 Oct 1997 04:31:53 -0700 (MST) Message-Id: <199710011131.EAA21371@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 1 Oct 1997 04:31:51 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: thartric@mentat.com (Tim Hartrick), bound@zk3.dec.com Subject: (IPng 4606) Re: Update to RFC 2133 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1824 [In your message of Sep 30, 10:36pm you write:] > > I guess the problem that I see is that everyone of the proposals for > an MT safe replacement of gethostbyname that I have seen have not been > particularly simple. They have all required a matching free function > to deal with the freeing of the storage. The exception is the gethostby- > name_r variants of the traditional functions which require that the user > pass in the storage. > > Once you have reconciled yourself to the need for the free function then > the difference between using getaddrinfo/getnameinfo and one of the MT safe > gethostbyname variants which have been proposed on this list is pretty slim. > Approximately the same amount of code needs to be moved around in the > application to deal with the free'ing of the storage. The rest seems like > window dressing to me. Tim, you are 100% correct. A related point is that if you're going to invent yet another structure of information to return (a dynhostent{} or whatever), then you've complicated the changes required. The existing hostent{} structure only allows one size of address to be returned (one h_length return value). You get a list of addresses, but they must all be the same length. This prevents returning something like native IPv6 addresses and native IPv4 addresses, something that getaddrinfo() does easily, since in the addrinfo{} structure each list entry has its own length. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 1 06:11:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA28066; Wed, 1 Oct 1997 06:02:03 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA28059; Wed, 1 Oct 1997 06:01:54 -0700 Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id GAA07427; Wed, 1 Oct 1997 06:01:53 -0700 (PDT) Received: by lucknow.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA12296; Wed, 1 Oct 1997 05:59:40 -0700 Date: Wed, 1 Oct 1997 05:59:40 -0700 From: Mukesh.Kacker@eng.sun.com (Mukesh Kacker) Message-Id: <199710011259.FAA12296@lucknow.eng.sun.com> To: ipng@sunroof.eng.sun.com, rstevens@kohala.com Subject: (IPng 4607) Re: Update to RFC 2133 Cc: bound@zk3.dec.com, thartric@mentat.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2656 > > And why is the threads safety of the underlying DNS resolver API an > IPng mailing list issue? I don't disagree with this point of yours > at all, I just don't think it's relevant to IPng. If some group of > vendors want to get together and require the resolver be MT-safe, > then they should do that. That sounds like an OpenGroup issue to me, > and indeed they could have done this with Unix 98 but they chose to > explicitly state that all the name translation function need *not* be > MT-safe. > ... > This is mainly > a protocols group, not a sockets API group. > "Opinion time" here...though nothing direcly related to the technical arguemnts here. :-) I think development of the right kind of APIs that vendors can ship should be an issue "relevant to IPng" since it would affect how/when /how-widely protocols get deployment and use (and maybe find issues that feed into the protocol development cycle). Most vendors (for right or wrong reasons :-)) do have "MT-safe" as a requirement for any new API work they ship since "MT" is part of the base environments they ship. Ofcourse the can get together in any forum, but IETF is one that has a culture of "implement before you mandate a specification" and brings the right set of people together in the most open manner without any "members only" sign at its door. [ Why other forums do not maybe an interesting question that I will not attempt to address :-) ]. Let us not raise the issue of whether it is a "socket API group" or not. API issues are also hard to fix once the bugs makes it into a "standard" the protocol issues. Other forums fulfill different requirements/cultures/needs (e.g they may believe in kings, presidents or voting :-)). Also what makes it into specific "brands" like Unix98 is the minimal set of things that people can agree on before they can no longer call themselves "Unix" which are issues separte from leading edge development work that community at IETF does. [e.g. The multicast API options are probably not required in what can be called "Unix" probably because not all vendors had it. Would that be an appropriate choice for a community such as IETF ? ] My $0.02 opinion...solve this issue here and not leave it to be solved later in another forum. -Mukesh Kacker -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 1 08:46:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA28122; Wed, 1 Oct 1997 08:34:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA28115; Wed, 1 Oct 1997 08:34:03 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA14576; Wed, 1 Oct 1997 08:34:02 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA21275 for ; Wed, 1 Oct 1997 08:33:52 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA21879; Wed, 1 Oct 1997 11:00:15 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA12528; Wed, 1 Oct 1997 11:00:14 -0400 Message-Id: <9710011500.AA12528@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com, thartric@mentat.com (Tim Hartrick) Subject: (IPng 4608) Re: Update to RFC 2133 In-Reply-To: Your message of "Wed, 01 Oct 1997 04:15:50 PDT." <199710011115.EAA21295@kohala.kohala.com> Date: Wed, 01 Oct 1997 11:00:13 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1972 Richard, We are going no where here. getaddrinfo sucks. I will revisit all this later. You have completly missed the point of Eric's first mail that started this and continue to do so. The resolver input is not and should not make the decision it was just added discussion. You are politically turning this discussion around on the list and not addressing Eric's orginal issue. I don't think I will respond to you or Tim on what can be done to fix MT safeness if its not done here. OK. I think that will just start another rat-hole. But I don't think we (vendors) should bother with standards group to get this done if its not done here. We will just pay someone to fix it in BIND, as none of us want to roll our own here. I am going to seriously look for a compromise this p.m. But I am very disappointed in you not getting the orginal point and hugging getaddrinfo as a tree and not seeing the forest around you. You like getaddrinfo go use it. Don't tell the rest of us to use it. You stated clearly all the extra baggage with getaddrinfo in one of your messages. Thats why I think it sucks and always did. Your right maybe why ISVs are not on this list. But I think your hard definition who is on this list is completely bogus for IPv6. There are folks on this list who are watching it to track it so your making a personal observation again I don't agree with. The only one who has stated real use of getadddrinfo() here is you and Craig Metz. And Craig is building an IPv6 implementation. Anyway my point was I don't see anyone saying "here" go use it. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 1 11:02:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA28459; Wed, 1 Oct 1997 10:47:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA28452; Wed, 1 Oct 1997 10:47:06 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA19966; Wed, 1 Oct 1997 10:47:03 -0700 Received: from frantic.BSDI.COM (frantic.BSDI.COM [205.230.227.254]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA04241 for ; Wed, 1 Oct 1997 10:46:56 -0700 Received: (from dab@localhost) by frantic.BSDI.COM (8.8.5/8.8.5) id MAA03733; Wed, 1 Oct 1997 12:46:19 -0500 (CDT) Date: Wed, 1 Oct 1997 12:46:19 -0500 (CDT) From: David Borman Message-Id: <199710011746.MAA03733@frantic.BSDI.COM> To: bound@zk3.dec.com, thartric@mentat.com Subject: (IPng 4609) Re: Update to RFC 2133 Cc: ipng@sunroof.eng.sun.com, rstevens@kohala.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3046 Jim Bound writes: > I hope none of this push back is because folks don't want to change RFC > 2133 because its an info RFC, or because they have some implementations > developed or some other absurd reason. That right now is not a good > reason to not fix the core issue which is we need a simple replacement > for gethostbyname() for IPv6 that is MT safe. I don't take to well to > folks pushing getaddrinfo() down ours or the ISVs throat, who are > not vendors shipping products. So far (except for Tim ??) I have > not seen one major vendor on this list say they don't think we need this > feature. I think that says something too. I also have not seen one ISV > say they don't need this either, or say they will use getaddrinfo(). Ok, I'll speak up. Back at Cray Research gethostbyname() and friends were made thread-safe by using task-common data (provided you use the thread-safe version of libc (-lcm)). So, under that model, a simple replacement for gethostbyname() for IPv6 would also be MT safe, and adding getaddrinfo(), using gethostbyname2() would also be MT safe. So, if I was still at Cray Research, I wouldn't be worrying about it. (But I'm not at Cray Research anymore, so I can't speak for them.) Here at BSDI, the simple gethostbyname2() replacement for gethostbyname() (ignoring any MT issues!) is not sufficient. We will be shipping a system with IPv6 support, but we will not require that people build IPv6 into their kernels. Adding "#ifdef INET6" to applications is not feasable, because we ship a binary version of the system, so, the binary needs to be able to run with kernels both with and without IPv6 support. At this point in time, getaddrinfo() and getnameinfo() seem to provide what is needed, in a manner that is protocol version independent. For a trivial client that wants to do socket()/connect() or a trivial server that is just doing socket()/bind()/accept(), once they are converted to use getaddrinfo() and getnameinfo() they are both IPv4 and IPv6 capable and they don't really need to know whether they are connecting to an IPv6 or an IPv4 address. (I will say that it is advantageous that the port number is in the same location for both sockaddr_in and sockaddr_in6.) So, I guess I'd more interested in making getadddrinfo() MT safe than providing a simple MT safe replacement for gethostbyname(). If I was strictly an application writer and I wanted to add IPv6 support, I'd probably convert to getaddrinfo(), and then write a trivial version of getaddrinfo() that calls gethostbyname() and getservbyname() for those platforms that don't yet offer getaddrinfo(). -David Borman, dab@bsdi.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 Oct 1 12:10:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28578; Wed, 1 Oct 1997 11:57:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28571; Wed, 1 Oct 1997 11:56:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA11795; Wed, 1 Oct 1997 11:56:51 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA27136; Wed, 1 Oct 1997 11:56:43 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA18107; Wed, 1 Oct 1997 14:33:42 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA28601; Wed, 1 Oct 1997 14:33:37 -0400 Message-Id: <9710011833.AA28601@wasted.zk3.dec.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, Mukesh.Kacker@Eng, thartric@mentat.com (Tim Hartrick), masha@zk3.dec.com Subject: (IPng 4610) Re: Update to RFC 2133 In-Reply-To: Your message of "Wed, 01 Oct 1997 04:15:50 PDT." <199710011115.EAA21295@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Oct 1997 14:33:37 -0400 From: Maria Stanley X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3507 >And why is the threads safety of the underlying DNS resolver API an >IPng mailing list issue? I don't disagree with this point of yours >at all, I just don't think it's relevant to IPng. If some group of >vendors want to get together and require the resolver be MT-safe, >then they should do that. That sounds like an OpenGroup issue to me, >and indeed they could have done this with Unix 98 but they chose to >explicitly state that all the name translation function need *not* be >MT-safe. Treadsafeness of a library routine needs to be addressed at the time it is designed. Mukesh made some very good points about relevancy of the designing the right kind of API here, in this forum. I would like to add to this that gethostbyname() is a very good example of a design done without threadsafeness in mind - with the consequence of no standards group in the world being able to fix this after the fact. It is *impossible* to implement gethostbyname() as a thread-safe function. The best you can do is to make it return a pointer to a thread-specific area, at a performance cost. Not all implementors can deal with thread-specific data, and this makes it a questionable subject for standartization. Invention of gethostbyname_r() came out of necessity, to complement the deficiency. When you have all of the control over how you design your API, you do not want to build in any deficiencies of this sort, spawning various *_r() as a result. Regarding the current UNIX X/Open's specs, they define what everybody who claims UNIX complience should provide, as a MINIMUM subset. Currently threadsafeness of the address resolution routines is one of the proposed work items at XNET and it will be discussed at the meeting next week. But what can we do with gethostbyname? I can think of only three things: 1. Make it a standard returning of the pointer to the thread specific data? - questionable. 2. Standardize gethostbyname_r()? May be, but it may be difficult to find the consensus on the parameters etc. between the vendors. 3. Next release of the XNS will contain IPv6 extentions to sockets AND will contain a new threadsafe API for addres resolution, designed at IETF? By the way, if getaddrinfo() is not in the X/Open specs, it does not mean that the Open Group is *against* it (I wrote about this before). It caught our attention as a POSIX alignment item at one time, but there was no real interest from any of the participating vendors to include it into the XNS, and it was accidently overlooked at the time. If this routine becomes part of the iping's solution to all these issues, then, I predict, XNET will consider it. Regards, Maria Stanley. ____________________________________________________________________________ Maria Stanley Digital Equipment Corporation IPv6 Development 110 Spit Brook Road Memeber of XNET at The Open Group Nashua, NH 03062, USA masha@zk3.dec.com +1 (603) 884-0382 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 1 12:37:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA28602; Wed, 1 Oct 1997 12:20:54 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA28595; Wed, 1 Oct 1997 12:20:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA18125; Wed, 1 Oct 1997 12:20:42 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA04954 for ; Wed, 1 Oct 1997 12:20:41 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id MAA11909; Wed, 1 Oct 1997 12:20:36 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id MAA22579; Wed, 1 Oct 1997 12:20:35 -0700 (MST) Message-Id: <199710011920.MAA22579@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 1 Oct 1997 12:20:35 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Maria Stanley Subject: (IPng 4611) Re: Update to RFC 2133 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1811 [In your message of Oct 1, 2:33pm you write:] > > It is *impossible* to implement gethostbyname() as a thread-safe function. > The best you can do is to make it return a pointer to a thread-specific > area, at a performance cost. Not all implementors can deal with > thread-specific data, and this makes it a questionable subject for > standartization. > ... > But what can we do with gethostbyname? I can think of only three things: > 1. Make it a standard returning of the pointer to the thread specific data? > - questionable. Thread-specific data is part of Posix.1 (Section 17, 1996 edition). If we are designing something to be MT-safe, we have to assume something, and I believe implementation of Posix threads should be a minimal assumption. It's also mandated by Unix 98, so it must be part of the minimal set that all (most?) Unix vendors have agreed to. I'm also not sure what you're referring to as the performance cost of thread-specific data. The function has to do an malloc() for each thread that calls the function, but don't you have to do that anyway, if you have a freeXXX() function to go along with the getXXX() function? Lastly, I think that the designers of a hostname lookup function, something normally done once per application, need not worry about small performance implications (small in terms of the overall application, that is). Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 1 16:57:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA29044; Wed, 1 Oct 1997 16:47:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA29037; Wed, 1 Oct 1997 16:47:49 -0700 From: Cipolli_Stephen@corp.timeplex.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA28467; Wed, 1 Oct 1997 16:47:45 -0700 Received: from sys30 (corp.timeplex.com [134.196.236.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA01175 for ; Wed, 1 Oct 1997 16:47:36 -0700 Received: from conversion.sys30 by sys30.timeplex.com (PMDF V4.3-13 #7256) id <01IOAYVGSFBK8Y5BIS@sys30.timeplex.com>; Wed, 01 Oct 1997 19:49:08 -0500 (EST) Received: from CCMAIL.TIMEPLEX.COM by sys30.timeplex.com (PMDF V4.3-13 #7256) id <01IOAYVELXBK8Y5HIE@sys30.timeplex.com>; Wed, 01 Oct 1997 19:49:05 -0500 (EST) Date: Wed, 01 Oct 1997 15:20 -0500 (EST) Subject: (IPng 4612) Re: Update to RFC 2133 To: ipng@sunroof.eng.sun.com Message-id: <01IOAYVEO2HE8Y5HIE@sys30.timeplex.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2926 >> But if the underlying gethostbyname() is MT-safe, then so is getaddrinfo(), >> which is why all of the memory returned by getaddrinfo() is dynamically >> allocated. RFC 2133 does not spell this out explicitly, but if all that's >> needed is to say this, that's easy to fix. > Possibly. I think my problem in this case is that I have been operating > under some false assumptions with respect to how MT safety needs to be > implemented. >> I know that both Digital Unix 4.0 and HP-UX 10.30 state that gethostbyname() >> is MT-safe and both say they do this using thread-specific data. Solaris 2.6 >> explicitly says its gethostbyname() is not MT-safe. But you can still write >> an MT-safe getaddrinfo() for Solaris using gethostbyname_r(), and I have >> done this. > Specifically, I was assuming that thread-specifc data was not something that > was broadly available and that the existing resolver API's (gethostbyname, etc) > would need to be extended ala gethostbyname_r to become MT safe. Clearly that > is not the case on all platforms. Using Thread-specific (Thread-local) data implies a performance penalty. Thread-local data must be swapped in and out on each thread switch. If enough of these data items are used (from this and other libraries), the performance in time critical (real-time) applications will degrade. Thread-local data is typically used to preserve legacy libraries (such as the standard C library), which were designed before threading was widely available. Real-time systems, running preemptive multitasking (multithreading) kernels would find this solution unacceptable for modern APIs. > Given that some platforms already support MT safe implementations of the get- > hostbyname API's I see even less reason to event another wheel to deal with > MT safety. The existing getaddrinfo/getnameinfo entry points should be > sufficient. I think it is unwise to develop a library interface today which does not suport MT safety and then depend on the OS to make the library work in a thread safe manner. >> So I think it's trivial to specify that getaddrinfo() and getnameinfo() >> be MT-safe, and leave it up to the implementation as to how that's done. >> You could even just have getaddrinfo() allocate its own mutex to protect >> itself, if nothing better is provided by the underlying system. > Agreed. If the options are whether IPv6 should have a MT safe API or should it specify that OS vendor should make it behave in a MT safe manner. My vote is for a MT safe API. --Stephen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 1 17:55:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA29200; Wed, 1 Oct 1997 17:42:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA29193; Wed, 1 Oct 1997 17:42:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA11433; Wed, 1 Oct 1997 17:42:47 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA16084 for ; Wed, 1 Oct 1997 17:42:45 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04749; Wed, 1 Oct 97 17:41:08 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA03315; Wed, 1 Oct 1997 17:43:19 -0700 Date: Wed, 1 Oct 1997 17:43:19 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199710020043.RAA03315@feller.mentat.com> To: Cipolli_Stephen@corp.timeplex.com Subject: (IPng 4613) Re: Update to RFC 2133 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1358 Stephen, > > If the options are whether IPv6 should have a MT safe API or should it > specify that OS vendor should make it behave in a MT safe manner. My vote > is for a MT safe API. > I am not arguing for not specifying an MT safe resolver API. What I am arguing for is a single MT safe resolver API. There is one specified in the document today (getaddrinfo/getnameinfo). If that facility is unacceptable to folks then I don't see the point in adding another slightly different version which does exactly the same thing with slightly different structures, function names and calling conventions. If the getaddrinfo/get- nameinfo are unacceptable they should be junked and replaced with one of the proposals which has been made on this list during this discussion. I am 100% agnostic on which API is chosen (getaddrinfo/getnameinfo, getdyn- hostent, gethostbynameopt) but having both (or worse all three) makes us look like a camel construction company. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 06:36:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA29527; Thu, 2 Oct 1997 06:25:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA29519; Thu, 2 Oct 1997 06:21:11 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA10287; Thu, 2 Oct 1997 06:21:03 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA16294 for ; Thu, 2 Oct 1997 06:21:04 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA32417; Thu, 2 Oct 1997 09:13:51 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09279; Thu, 2 Oct 1997 09:13:44 -0400 Message-Id: <9710021313.AA09279@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: thartric@mentat.com (Tim Hartrick), bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4615) Re: Update to RFC 2133 In-Reply-To: Your message of "Wed, 01 Oct 1997 04:31:51 PDT." <199710011131.EAA21371@kohala.kohala.com> Date: Thu, 02 Oct 1997 09:13:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2170 >> Once you have reconciled yourself to the need for the free function then >> the difference between using getaddrinfo/getnameinfo and one of the MT safe >> gethostbyname variants which have been proposed on this list is pretty slim. >> Approximately the same amount of code needs to be moved around in the >> application to deal with the free'ing of the storage. The rest seems like >> window dressing to me. >Tim, you are 100% correct. Well getaddrinfo has window dressing too if you don't want to change all the way your existing app gets ports etc and other parts it does. I view window dressing as the look and feel of the API to a programmer. Many of us are fine with the look and feel of our applications today just like we are fine with our mail interface, window system, or shell script (I still use csh for example even though there is ksh). I claim getaddrinfo leaves what many are used to and many will not use it for that reason. You have to think about your inline code to change to getaddrinfo more than if you just replace lines and variables to support IPv6. >A related point is that if you're going to invent yet another structure >of information to return (a dynhostent{} or whatever), then you've >complicated the changes required. The existing hostent{} structure only >allows one size of address to be returned (one h_length return value). >You get a list of addresses, but they must all be the same length. This >prevents returning something like native IPv6 addresses and native IPv4 >addresses, something that getaddrinfo() does easily, since in the >addrinfo{} structure each list entry has its own length. You would just return h_length based on AF parameter just like gethostbyname2 does in rfc 2133 today. So I don't see this as huge hurdle. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 07:41:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA29585; Thu, 2 Oct 1997 07:29:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA29578; Thu, 2 Oct 1997 07:29:41 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA29947; Thu, 2 Oct 1997 07:29:40 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA04887 for ; Thu, 2 Oct 1997 07:29:40 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA16278; Thu, 2 Oct 1997 09:25:19 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09816; Thu, 2 Oct 1997 09:25:03 -0400 Message-Id: <9710021325.AA09816@wasted.zk3.dec.com> To: David Borman Cc: bound@zk3.dec.com, thartric@mentat.com, ipng@sunroof.eng.sun.com, rstevens@kohala.com Subject: (IPng 4616) Re: Update to RFC 2133 In-Reply-To: Your message of "Wed, 01 Oct 1997 12:46:19 CDT." <199710011746.MAA03733@frantic.BSDI.COM> Date: Thu, 02 Oct 1997 09:25:03 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3709 >Ok, I'll speak up. Back at Cray Research gethostbyname() and friends >were made thread-safe by using task-common data (provided you use the >thread-safe version of libc (-lcm)). So, under that model, a simple >replacement for gethostbyname() for IPv6 would also be MT safe, and >adding getaddrinfo(), using gethostbyname2() would also be MT safe. >So, if I was still at Cray Research, I wouldn't be worrying about it. >(But I'm not at Cray Research anymore, so I can't speak for them.) I could just ignore it at Digital too. But I am also here as an individual. If I leave Digital and go try to build a small business writing applications I want the APIs to be there. This is how I try to view my standards work since a long time ago. Also as Mukesh pointed out in his mail places like XNET are "members only" and this list provides a place for all to input into the API discussion, and I believe relying on Cray, Digital, Sun, or anyone is not a good idea for gethostbyname etc if we can make the API MT safe via some API below getaddrinfo (if you want to use that mechanism). I think with gethostbyname that is an IPv4 issue and not my concern anyway in this discusssion. >Here at BSDI, the simple gethostbyname2() replacement for gethostbyname() >(ignoring any MT issues!) is not sufficient. We will be shipping a >system with IPv6 support, but we will not require that people build IPv6 >into their kernels. Adding "#ifdef INET6" to applications is not feasable, >because we ship a binary version of the system, so, the binary needs to be >able to run with kernels both with and without IPv6 support. At this point >in time, getaddrinfo() and getnameinfo() seem to provide what is needed, in >a manner that is protocol version independent. For a trivial client that >wants to do socket()/connect() or a trivial server that is just doing >socket()/bind()/accept(), once they are converted to use getaddrinfo() and >getnameinfo() they are both IPv4 and IPv6 capable and they don't really >need to know whether they are connecting to an IPv6 or an IPv4 address. >(I will say that it is advantageous that the port number is in the same >location for both sockaddr_in and sockaddr_in6.) I think you have come up with one good reason for using getaddrinfo(). I am not clear it is a good idea to send out kernels that don't support IPv6 or why one would do that unless you really are building a pure dual stack and I guess that is one way to approach IPv6. But I am not in that situation. In fact putting APIs to support IPv6 now is doable and it enables users to start using the APIs for IPv6 without using the IPv6 stack until they are ready. We all will not deploy IPv6 the same way, but we all should be able to have an agreed upon set of APIs for our customers. >So, I guess I'd more interested in making getadddrinfo() MT safe than >providing a simple MT safe replacement for gethostbyname(). If I was >strictly an application writer and I wanted to add IPv6 support, I'd >probably convert to getaddrinfo(), and then write a trivial version of >getaddrinfo() that calls gethostbyname() and getservbyname() for those >platforms that don't yet offer getaddrinfo(). I agree with getting getaddrinfo MT safe and I will propose an API to do that, but first I would like to get rid of RES_USE_INET6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 08:21:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29626; Thu, 2 Oct 1997 08:08:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29619; Thu, 2 Oct 1997 08:07:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA10992; Thu, 2 Oct 1997 08:07:47 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA17123 for ; Thu, 2 Oct 1997 08:07:41 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id IAA15233; Thu, 2 Oct 1997 08:07:02 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id IAA24249; Thu, 2 Oct 1997 08:07:01 -0700 (MST) Message-Id: <199710021507.IAA24249@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 2 Oct 1997 08:07:01 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 4617) Re: Update to RFC 2133 Cc: Cipolli_Stephen@corp.timeplex.com, Maria Stanley Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2322 Two postings yesterday to the list said that thread-specific data (TSD) should not be considered for the API issues that we are talking about, due to performance penalties. For example: > Using Thread-specific (Thread-local) data implies a performance penalty. > Thread-local data must be swapped in and out on each thread switch. I'm no threads expert, but my gut feel (having used TSD and knowing how it's normally implemented) was that these concerns are insignificant. So I asked a friend who *is* a threads expert (intimately involved with the pthreads standard, and responsible for one major vendor's pthreads implementation) and his response was: > Concerns about the overhead of "swapping TSD context in and out" are > absurd. It's not POSSIBLE to do it that way in a threading system that > supports multiprocessors. It doesn't even make sense for a strictly > user-mode threading implementation, because there are simpler (and > faster) methods. > ... > You wouldn't want to casually use TSD "all over the place" instead of > global data. That's why I favor _r variants rather than making the > existing interfaces use TSD. On the other hand, TSD isn't > prohibitively expensive except in critical sections of code. So I don't think we should write off TSD, especially for a function that is normally called only once per application. In general there are three methods for making a function MT-safe: 1. Use TSD. (DUnix and HP-UX do this with gethostbyname().) 2. Force the caller to allocate the storage (look at the existing DUnix, HP-UX, Solaris gethostbyname_r() functions for an example). 3. Allocate the memory dynamically within the function and provide another function to free the memory (getaddrinfo()/freeaddrinfo()). So if we invent a new function, I would avoid (2) at all costs. I have used the _r versions of the resolver functions, and they are a pain, with so many arguments. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 2 08:25:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29639; Thu, 2 Oct 1997 08:12:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29632; Thu, 2 Oct 1997 08:12:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12040; Thu, 2 Oct 1997 08:12:22 -0700 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA18564 for ; Thu, 2 Oct 1997 08:12:20 -0700 Received: from fleck.iol.unh.edu by iol.unh.edu (4.1/SMI-4.1) id AA28785; Thu, 2 Oct 97 11:01:50 EDT Received: by fleck.iol.unh.edu (SMI-8.6/SMI-SVR4) id LAA02488; Thu, 2 Oct 1997 11:16:21 -0400 Date: Thu, 2 Oct 1997 11:16:21 -0400 Message-Id: <199710021516.LAA02488@fleck.iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andreas Kleen Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4618) Re: Extension header processing in ICMPv6 packets. In-Reply-To: <97Oct2.125403met_dst.86020-1@colin.muc.de> References: <97Oct2.125403met_dst.86020-1@colin.muc.de> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremy McCooey Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1820 Andreas Kleen writes: > > > > I think that the nicest solution would be some usage restriction on > > extension headers in ICMP error messages, like: only those extension > > headers required of a "full" implementation may be used in ICMP > > errors, and extension headers may only be used in an ICMP error if the > > sending node supports all extension headers required of a "full" > > implementation. Likewise, perhaps a "discard with error" flavor > > option should not be allowed in an ICMP error packet. > Hmm, that still has the same problem: the implementation doesn't know > yet if it's an ICMP packet or not. That is true; however, these rules would prevent the recursive behavior. There would never be an error message that was in response to (an error message that was in response to an error message). At least, provided that both implementations are working properly. > When there is a good reason for the 'never send ICMP error to ICMP errors' > rule then this isn't a good idea (because it's really a ICMP error you're > processing). If not, the requirement should be at least changed to a MAY. A machine which should not be expected to know the contents of the payload of a packet (like an intermediate router) should not be expected to follow the rules which govern the payload. I don't think that this is a reason to change the requirements for those machines which _do_ process the payload. Jeremy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 2 08:39:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29653; Thu, 2 Oct 1997 08:22:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29646; Thu, 2 Oct 1997 08:21:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA14659; Thu, 2 Oct 1997 08:21:55 -0700 Received: from postoffice.cisco.com (postoffice-hme0.cisco.com [171.69.192.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA21849 for ; Thu, 2 Oct 1997 08:21:48 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA00515 for ; Thu, 2 Oct 1997 08:21:38 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <9710021325.AA09816@wasted.zk3.dec.com> References: Your message of "Wed, 01 Oct 1997 12:46:19 CDT." <199710011746.MAA03733@frantic.BSDI.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Oct 1997 08:21:10 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 4619) Re: Update to RFC 2133 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1080 A nit from the IPv6 terminology watchdog: if you folks *do* end up inventing some radically new, IPv6-only API functions, instead of embedding the term "host" in the function name (a la gethostbyname), please consider using the term "node" instead (e.g., getnodebyname). Unless, of course, your new function is intended to apply only to hosts, and not to routers. On the other hand, if you are making new functions that are simply "clones" of the existing IPv4 functions (e.g., by adding a "6" to the IPv4 function name, but otherwise keeping the same semantics, arguments, etc.), then it probably makes sense to stick with the "host" term for backwards compatibility with old programmers. 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 Thu Oct 2 08:55:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29695; Thu, 2 Oct 1997 08:44:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29687; Thu, 2 Oct 1997 08:44:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA20267; Thu, 2 Oct 1997 08:43:28 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA29562 for ; Thu, 2 Oct 1997 08:43:12 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id IAA15332; Thu, 2 Oct 1997 08:42:10 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id IAA24333; Thu, 2 Oct 1997 08:42:10 -0700 (MST) Message-Id: <199710021542.IAA24333@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 2 Oct 1997 08:42:10 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 4620) Re: Update to RFC 2133 Cc: thartric@mentat.com, bound@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2450 Let's step back. Erik's email that started this thread on July 23rd brought up three points: 1. Calling res_init() and turning on the RES_USE_INET6 bit in res_options is bad programming. 2. This interface is tied to the DNS and some vendors use other types of name resolution (NIS, etc.). 3. Setting res_options is not MT-safe. I think we all agree with all three points? Then how about the following: 1. We explicitly declare that getaddrinfo() be MT-safe. It was always *intended* to be, which is why it dynamically allocates the memory, and why it has a matching freeaddrinfo() function, it's just that Posix.1g and RFC 2133 never explicitly said it was MT-safe. 2. We define a new function struct hostent *gethostbyname3(const char *host, int family, int options); and specify that it *must* be MT-safe. One way is with thread-specific data, another way is with a matching freehostent() function. I don't care which. The "family" argument is AF_INET or AF_INET6, just like gethostbyname2(), and one "option" is RES_USE_INET6 (changing the name, perhaps, I don't care, as long as the functionality is the same as implemented today). We could easily define more options, if desired. The hostent{} structure remains the same. Existing code that calls gethostbyname() could easily be changed to call this new function instead. In the absolute worst case (resolver functions that are not MT-safe, such as the publicly available BIND releases today), all you have to to is lock a mutex, set res_options, and call gethostbyname2(). But it should also be simple to implement this function using a vendor-supplied MT-safe resolver (e.g., Sun's gethostbyname_r(), Digital and HP's gethostbyname()) when available. I am correct, I hope, in assuming that we do not specify how you have to implement it, only that it be MT-safe and that providing an MT-safe version using existing systems be feasible? Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 2 09:27:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29799; Thu, 2 Oct 1997 09:12:54 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29792; Thu, 2 Oct 1997 09:12:45 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA28162; Thu, 2 Oct 1997 09:12:33 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA09689 for ; Thu, 2 Oct 1997 09:12:28 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA00790 for ; Thu, 2 Oct 1997 12:04:44 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA08699; Thu, 2 Oct 1997 12:04:42 -0400 Message-Id: <9710021604.AA08699@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 4621) Deprecating RES_USE_INET6 and gethostbyname2() Idea Date: Thu, 02 Oct 1997 12:04:42 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5436 Below I propose a replacement for RES_USE_INET6 and gethostbyname2(). I will show a porting cheat sheet as it is now from IPv4 to IPv6 and then a porting cheat sheet using gethostbyname3(). ALso lets leave the MT safe issue for a moment I would just like to focus/discuss the issue of RES_USE_INET6. thanks... In addition I don't think changing a global variable to make a function behave correctly is an elegant thing to do which RES_USE_INET6 does. This is basic data structures 101 in any Computer Science curriculum. But anyway the idea is we should "deprecate" the use of RES_USE_INET6 and gethostbyname2(), which to me means that at some point it would not be supported, and one should move to gethostbyname3(). This permits applications that have been ported a grace period and those that have built IPv6 tutorials, presentations, white papers etc.. to also have a migration period. But we would update RFC 2133 to support the gethostbyname3(). gethostbyname3(name, AF, u_int flags) Where flags is an integer and the first definitions are: flags = 0; This is the default and it states the following: If AF_INET is specified IPv4 addresses are returned. If AF_INET6 is specified IPv6 addresses are returned, but if no AF_INET6 addresses are found look for IPv4 addresses and return v4-mapped addresses, but if neither are found return an error. flags = 1 This is a strict interpretation of AF parameter. You only return the address type specified by the AF paramter. Another fix we need is for gethostbyaddr() too as it now depends on RES_USE_INET6 to. The rule set for gethostbyaddr() would be updated as follows: In both cases h_length would return the proper value for the address as in gethosbyname2() today in RFC 2133. gethostbyaddr(addr, len, af) if af==AF_NET addr is IPv4 4 byte addr lookup under inaddr.arpa return v4-addr if af==AF_INET6 addr is 16 byte addr switch (addr-type) case v4-mapped: extract v4-addr lookup under inaddr.arpa return v4-mapped case v4-compat: extract v4-addr lookup under inaddr.arpa return v4-compat (rfc 2133 don't do this now) default: lookup under ip6.intl; return v6-addr Cheat sheet comparison. You will note in the second one we don't need RES_USE_INET6 and with the flags parameter getaddrinfo() can still use gethostbyname3() (not that I think that is a good idea as its not MT safe). And here is the IPv4 to IPv6 porting cheat sheet using RFC 2133 Change this IPv4 thingy... to this IPv6 thingy... - ------------------------------------- -------------------------------------- AF_INET AF_INET6 PF_INET PF_INET6 struct in_addr struct in6_addr s_addr s6_addr INADDR_ANY in6addr_any struct sockaddr (where it really struct sockaddr_in6 (a sockaddr_in6 should be struct sockaddr_in, is bigger than a sockaddr) e.g. sizeof(struct sockaddr)) sockaddr_in sockaddr_in6 sin_len sin6_len sin_family sin6_family sin_port sin6_port sin_addr sin6_addr gethostbyaddr(xx, 4, AF_INET) res_init(); _res.options |= RES_USE_INET6; : gethostbyaddr(xx ,16, AF_INET6) gethostbyname(name) res_init(); _res.options |= RES_USE_INET6; : gethostbyname(name) inet_ntoa() inet_ntop() inet_addr() inet_pton() (addr1->s_addr == addr2->s_addr) (memcmp(addr1, addr2, sizeof(struct in6_addr) == 0) (addr1->s_addr == addr2->s_addr) IN6_ARE_ADDR_EQUAL(addr1, addr2) (addr1->s_addr == INADDR_ANY) IN6_IS_ADDR_UNSPECIFIED(addr1) IPv4-specific IP-level socket option look for similar IPv6-specific option int (where used to hold IPv4 address) struct in6_addr --------------------------------------------- And here is the IPv4 to IPv6 porting cheat sheet using gethostbyname3() Change this IPv4 thingy... to this IPv6 thingy... - ------------------------------------- -------------------------------------- AF_INET AF_INET6 PF_INET PF_INET6 struct in_addr struct in6_addr s_addr s6_addr INADDR_ANY in6addr_any struct sockaddr (where it really struct sockaddr_in6 (a sockaddr_in6 should be struct sockaddr_in, is bigger than a sockaddr) e.g. sizeof(struct sockaddr)) sockaddr_in sockaddr_in6 sin_len sin6_len sin_family sin6_family sin_port sin6_port sin_addr sin6_addr gethostbyaddr(xx, 4, AF_INET) gethostbyaddr(xx ,16, AF_INET6) gethostbyname(name) gethostbyname3(name, AF, Flags) inet_ntoa() inet_ntop() inet_addr() inet_pton() (addr1->s_addr == addr2->s_addr) (memcmp(addr1, addr2, sizeof(struct in6_addr) == 0) (addr1->s_addr == addr2->s_addr) IN6_ARE_ADDR_EQUAL(addr1, addr2) (addr1->s_addr == INADDR_ANY) IN6_IS_ADDR_UNSPECIFIED(addr1) IPv4-specific IP-level socket option look for similar IPv6-specific option int (where used to hold IPv4 address) struct in6_addr --------------------------------------------- Comments ???? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 09:42:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29845; Thu, 2 Oct 1997 09:24:17 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29838; Thu, 2 Oct 1997 09:24:06 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA17194 for ; Thu, 2 Oct 1997 09:24:06 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20214; Thu, 2 Oct 1997 09:21:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA29463; Thu, 2 Oct 1997 03:54:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA24056; Thu, 2 Oct 1997 03:54:34 -0700 Received: from colin.muc.de (colin.muc.de [193.174.4.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA17621 for ; Thu, 2 Oct 1997 03:54:28 -0700 Received: by colin.muc.de id <86020-1>; Thu, 2 Oct 1997 12:54:03 +0200 Subject: (IPng 4622) Re: Extension header processing in ICMPv6 packets. From: Andreas Kleen To: jam@iol.unh.edu (Jeremy McCooey) Date: Thu, 2 Oct 1997 12:54:01 +0200 Cc: ak@muc.de, ipng@sunroof.eng.sun.com In-Reply-To: from "Jeremy McCooey" at Sep 30, 97 08:54:47 pm X-Mailer: ELM [version 2.4 PL13] Content-Type: text Message-Id: <97Oct2.125403met_dst.86020-1@colin.muc.de> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1783 > Also, the situation you describe with the ESP header can be > generalized to any "unknown next header" before the ICMP header, as > a node would not know how to proceed to the following header. Yes, I used the ESP header only as an example where I know that it breaks :) > > I think that the nicest solution would be some usage restriction on > extension headers in ICMP error messages, like: only those extension > headers required of a "full" implementation may be used in ICMP > errors, and extension headers may only be used in an ICMP error if the > sending node supports all extension headers required of a "full" > implementation. Likewise, perhaps a "discard with error" flavor > option should not be allowed in an ICMP error packet. Hmm, that still has the same problem: the implementation doesn't know yet if it's an ICMP packet or not. > > In any event, I personally understand the spec to mean "do not > generate an ICMP error as the result of processing the ICMP portion of > an ICMP error packet." For instance, I wouldn't expect a router to > process a packet in its entirety before sending a destination > unreachable or time exceeded message.. When there is a good reason for the 'never send ICMP error to ICMP errors' rule then this isn't a good idea (because it's really a ICMP error you're processing). If not, the requirement should be at least changed to a MAY. -Andi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 2 09:53:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29870; Thu, 2 Oct 1997 09:32:02 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29863; Thu, 2 Oct 1997 09:31:42 -0700 Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA17990; Thu, 2 Oct 1997 09:31:40 -0700 (PDT) Date: Thu, 2 Oct 1997 09:30:14 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4623) Re: Update to RFC 2133 To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, thartric@mentat.com, bound@zk3.dec.com In-Reply-To: "Your message with ID" <199710021542.IAA24333@kohala.kohala.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1701 > Then how about the following: > > 1. We explicitly declare that getaddrinfo() be MT-safe. It was always > *intended* to be, which is why it dynamically allocates the memory, > and why it has a matching freeaddrinfo() function, it's just that > Posix.1g and RFC 2133 never explicitly said it was MT-safe. Agreed. We think also need to define additional AI_* flags to cover the semantics of RES_USE_INET6 and any other options we decide we need. > 2. We define a new function > > struct hostent *gethostbyname3(const char *host, int family, > int options); > > and specify that it *must* be MT-safe. One way is with thread-specific > data, another way is with a matching freehostent() function. I don't > care which. I assume you imply that we have to decide whether or not there is a freehostent style function in order to get portability. I'd presonally prefer a freehostent (i.e. that gethostbyname3 return dynamically allocated storage) since it doesn't require an implementation to use thread specific/local data Presumably an implementation that would use TSD could just have an empty freehostent function. And for the $10,000 question: Should it be named gethostbyname3, getdynhostbyname or gethostbynameafopt? :-) :-) 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 Oct 2 10:08:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29891; Thu, 2 Oct 1997 09:43:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29884; Thu, 2 Oct 1997 09:42:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA06883; Thu, 2 Oct 1997 09:42:54 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA19686 for ; Thu, 2 Oct 1997 09:42:51 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA07175; Thu, 2 Oct 1997 12:25:48 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10007; Thu, 2 Oct 1997 12:25:43 -0400 Message-Id: <9710021625.AA10007@wasted.zk3.dec.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "W. Richard Stevens" Cc: Maria Stanley , ipng@sunroof.eng.sun.com, masha@zk3.dec.com Subject: (IPng 4624) Re: Update to RFC 2133 In-Reply-To: Your message of "Wed, 01 Oct 1997 12:20:35 PDT." <199710011920.MAA22579@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Oct 1997 12:25:42 -0400 From: Maria Stanley X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3049 I have to stress my original point: even if some solution for the threadsafeness of gethostbyname() is found (and I can't see how it can be a clean one...), it is important that IPV6 API is designed with threadsafeness in mind now, vs leaving the threadsafeness issues to whoever, to resolve them somehow after the fact. Now, regarding the thread-specific data (and with understanding that none of the opinions expressed are official opinions of XNET, unless clearly stated): > [In your message of Oct 1, 2:33pm you write:] > > > > It is *impossible* to implement gethostbyname() as a thread-safe function. > > The best you can do is to make it return a pointer to a thread-specific > > area, at a performance cost. Not all implementors can deal with > > thread-specific data, and this makes it a questionable subject for > > standartization. > > ... > > But what can we do with gethostbyname? I can think of only three things: > > 1. Make it a standard returning of the pointer to the thread specific data? > > - questionable. > > Thread-specific data is part of Posix.1 (Section 17, 1996 edition). If > we are designing something to be MT-safe, we have to assume something, and > I believe implementation of Posix threads should be a minimal assumption. > It's also mandated by Unix 98, so it must be part of the minimal set that > all (most?) Unix vendors have agreed to. Good point for arguing for this solution. Weakness that I see: pthreads and Xsockets (X/Open sockets), while both included in the UNIX definition, each of them are separate brandable entities, and companies may decide that they want to keep it this way. > > I'm also not sure what you're referring to as the performance cost of > thread-specific data. The function has to do an malloc() for each thread > that calls the function, but don't you have to do that anyway, if you > have a freeXXX() function to go along with the getXXX() function? The assumption that thread-specific data implementation "has to do an malloc()" is actually wrong. Penaly or no penalty is probably an implemetation-specific questiion. I did not mean this as a real show stopper for the solution, but mentioned it just for completeness of the discussion. Thanks, Maria Stanley ____________________________________________________________________________ Maria Stanley Digital Equipment Corporation IPv6 Development 110 Spit Brook Road Memeber of XNET at The Open Group Nashua, NH 03062, USA masha@zk3.dec.com +1 (603) 884-0382 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 2 11:28:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00251; Thu, 2 Oct 1997 11:13:07 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00242; Thu, 2 Oct 1997 11:12:55 -0700 Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id LAA07955; Thu, 2 Oct 1997 11:12:37 -0700 (PDT) Date: Thu, 2 Oct 1997 11:11:11 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4625) Re: Deprecating RES_USE_INET6 and gethostbyname2() Idea To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9710021604.AA08699@wasted.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 content-length: 5134 > In addition I don't think changing a global variable to make a function > behave correctly is an elegant thing to do which RES_USE_INET6 does. > This is basic data structures 101 in any Computer Science curriculum. > But anyway the idea is we should "deprecate" the use of RES_USE_INET6 > and gethostbyname2(), which to me means that at some point it would not > be supported, and one should move to gethostbyname3(). This permits > applications that have been ported a grace period and those that have > built IPv6 tutorials, presentations, white papers etc.. to also have a > migration period. But we would update RFC 2133 to support the > gethostbyname3(). I think that we should update RFC 2133 with an RFC that has no mention of RES_USE_INET6 but instead lists the behavior of gethostbyname, gethostbyname2, and gethostbyname3 (or whatever we want to call it). Vendors will know how to deal with compatibility for applications that have already been ported and use RES_USE_INET6 - no need to mention this in the RFC. > gethostbyname3(name, AF, u_int flags) > > Where flags is an integer and the first definitions are: > > flags = 0; > > This is the default and it states the following: > > If AF_INET is specified IPv4 addresses are returned. > > If AF_INET6 is specified IPv6 addresses are returned, but > if no AF_INET6 addresses are found look for IPv4 addresses > and return v4-mapped addresses, but if neither are found > return an error. > > flags = 1 > > This is a strict interpretation of AF parameter. You only > return the address type specified by the AF paramter. I agree in priciple but I think it is better to invert the 0/1 and introduce named constants for the options. The inverting means that gethostbyname3(name, af, 0) will behave the same way as gethostbyname2(name, af) i.e. a strict interpretation of the af parameter. For the flags we can start off with: GH_OPT_V4_FALLBACK 0x01 If no inet6 found look for AF_INET. GH_OPT_V4_MAPPED 0x02 Return v4 addr as v4 mapped AF_INET6. Combining the above two results in the same behavior that you proposed for flags = 0. I think applications might also want: GH_OPT_ALL_AF 0x04 Return all addresses from all families An alternative would be to use AF_UNSPEC to get this behavior. Finally (and this was mentioned in an email during the summer) GH_OPT_MATCH_SOURCE(?) 0x08 Only return IPv6 addresses if the IP stack has at least one IPv6 address assigned to an interface. This option is useful for applications that run on nodes with a v6 capable protocol stack but where the admin has chosen not to configure any IPv6 addresses. We could then also define AI_* flags corresponding to the above (except GH_OPT_ALL_AF which is handled using PF_UNSPEC) to give the same capabilities to the users of getaddrinfo(). > Another fix we need is for gethostbyaddr() too as it now depends on > RES_USE_INET6 to. The rule set for gethostbyaddr() would be updated as > follows: > > In both cases h_length would return the proper value for the address as > in gethosbyname2() today in RFC 2133. > > gethostbyaddr(addr, len, af) > > if af==AF_NET > addr is IPv4 4 byte addr > lookup under inaddr.arpa > return v4-addr > if af==AF_INET6 > addr is 16 byte addr > switch (addr-type) > case v4-mapped: > extract v4-addr > lookup under inaddr.arpa > return v4-mapped > case v4-compat: > extract v4-addr > lookup under inaddr.arpa > return v4-compat (rfc 2133 don't do this now) > default: lookup under ip6.intl; return v6-addr I agree with the clarification that the address in the hostent structure should always be identical to what was passed in. Thus if an AF_INET6 (native, mapped, or compatible) is passed in the same address should be returned. The text in RFC 2133 doesn't seem completely clear to me on that point. I think this can be done my modifying this section of RFC 2133: 4. If the function is returning success, and if af equals AF_INET, and if the RES_USE_INET6 option was set, then the single address that is returned in the hostent structure (a copy of the first argument to the function) is returned as an IPv4-mapped IPv6 address and the h_length member is set to 16. to instead say: 4. If the function is returning success, then the single address that is returned in the hostent structure is a copy of the first argument to the function with the same address family as when gethostbyname was called. Thus it seems like the only real open issue is whether or not gethostbyname3 should have an associated freehostent structure. 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 Oct 2 11:32:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00274; Thu, 2 Oct 1997 11:16:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00267; Thu, 2 Oct 1997 11:16:18 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA07910; Thu, 2 Oct 1997 11:16:14 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA19689 for ; Thu, 2 Oct 1997 11:15:38 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id NAA06592; Thu, 2 Oct 1997 13:44:42 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA08264; Thu, 2 Oct 1997 13:44:31 -0400 Message-Id: <9710021744.AA08264@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, thartric@mentat.com, bound@zk3.dec.com Subject: (IPng 4626) Re: Update to RFC 2133 In-Reply-To: Your message of "Thu, 02 Oct 1997 08:42:10 PDT." <199710021542.IAA24333@kohala.kohala.com> Date: Thu, 02 Oct 1997 13:44:31 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2842 Richard, This is a good idea. I just sent similar mail but lets go with your mail and void my last mail (except my input on gethostbyaddr() see my comment below). >1. We explicitly declare that getaddrinfo() be MT-safe. It was always > *intended* to be, which is why it dynamically allocates the memory, > and why it has a matching freeaddrinfo() function, it's just that > Posix.1g and RFC 2133 never explicitly said it was MT-safe. Good. >2. We define a new function > > struct hostent *gethostbyname3(const char *host, int family, > int options); > > and specify that it *must* be MT-safe. One way is with thread-specific > data, another way is with a matching freehostent() function. I don't > care which. The "family" argument is AF_INET or AF_INET6, just like > gethostbyname2(), and one "option" is RES_USE_INET6 (changing the name, > perhaps, I don't care, as long as the functionality is the same as > implemented today). We could easily define more options, if desired. > The hostent{} structure remains the same. > > Existing code that calls gethostbyname() could easily be changed to > call this new function instead. > > In the absolute worst case (resolver functions that are not MT-safe, > such as the publicly available BIND releases today), all you have to > to is lock a mutex, set res_options, and call gethostbyname2(). But > it should also be simple to implement this function using a > vendor-supplied MT-safe resolver (e.g., Sun's gethostbyname_r(), > Digital and HP's gethostbyname()) when available. I am correct, > I hope, in assuming that we do not specify how you have to implement > it, only that it be MT-safe and that providing an MT-safe version > using existing systems be feasible? ALso make one of the options to get back a dynamic ptr to addresses but have it be only an option so if folks don't want to call MT safe they can do that too. I think I agree with Eriks response he stated, and I would like to see it called gethostbyname3(...). Also per Steve's input I think we are mostly talking about "hosts" here, but the way routers are evolving I wonder if it should be "node" but then we would have to change the others too.... What do you think? Also in my mail I just sent we also have to fix gethostbyaddr() as that depends on RES_USE_INET6 now. I proposed a fix for that in my mail. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 11:54:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00306; Thu, 2 Oct 1997 11:34:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00299; Thu, 2 Oct 1997 11:33:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA00125; Thu, 2 Oct 1997 10:54:53 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA12850 for ; Thu, 2 Oct 1997 10:54:35 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA10094; Thu, 2 Oct 97 10:52:54 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA00562; Thu, 2 Oct 1997 10:55:05 -0700 Date: Thu, 2 Oct 1997 10:55:05 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199710021755.KAA00562@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4627) Re: Update to RFC 2133 X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1784 Richard, Erik, > > 1. Calling res_init() and turning on the RES_USE_INET6 bit in > res_options is bad programming. > > 2. This interface is tied to the DNS and some vendors use other types > of name resolution (NIS, etc.). > > 3. Setting res_options is not MT-safe. > > I think we all agree with all three points? > Agreed. > Then how about the following: > > 1. We explicitly declare that getaddrinfo() be MT-safe. It was always > *intended* to be, which is why it dynamically allocates the memory, > and why it has a matching freeaddrinfo() function, it's just that > Posix.1g and RFC 2133 never explicitly said it was MT-safe. > Agreed. > 2. We define a new function > > struct hostent *gethostbyname3(const char *host, int family, > int options); > > > I assume you imply that we have to decide whether or not there is a > freehostent style function in order to get portability. > > > And for the $10,000 question: Should it be named gethostbyname3, > getdynhostbyname or gethostbynameafopt? :-) :-) > If we must have a second hump, err... I mean MT-safe API then I vote for getdynhostbyname as its name with an explicit free function. Erik, where do I pick up my $10,000 dollars? :-) I want to pick it up soon before other people get a chance to answer the question and dilute the prize money. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 11:58:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00346; Thu, 2 Oct 1997 11:40:32 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00336; Thu, 2 Oct 1997 11:40:15 -0700 Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id LAA13264; Thu, 2 Oct 1997 11:40:13 -0700 (PDT) Date: Thu, 2 Oct 1997 11:38:47 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4628) RFC 2133 - remove IPV6_ADDRFORM? To: ipng@sunroof.eng.sun.com Cc: nordmark@jurassic.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2912 I think we should remove IPV6_ADDRFORM when we update RFC 2133 since it is not needed as far as I can tell and the detailed semantics are unclear and complex. The option was introduced back in the SIP days when we have a prototype that used PF_INET to create the socket and then the application would use AF_INET or AF_SIP in the bind/connect/sendto/sendmsg calls. In that prototype the protocol stack would look at the AF in the above calls from the user to determine what address family to use when passing up addresses with the accept/recvfrom/recvmsg/getsockname/getpeername calls. In that prototype there was a need to programs like inetd to make sure that the protocol stack would pass up the correct form of addresses once inetd had exec'ed an application (that might desire either AF_INET or AF_SIP). This option has stayed with us for a long time partly due to deficiencies in the Solaris IPv6 prototype where the protocol stack can't tell the different between e.g. these two sockets socket(AF_INET, SOCK_STREAM, 0) socket(AF_INET6, SOCK_STREAM, 0) thus the prototype code relies on the address family in the bind or connect calls. The semantics of IPV6_ADDRFORM might be clear when there is nothing queued on the socket. This is just a case of making sure that future datagrams and connect indications (for accept) queued on the socket have the correct address family. But here are a few examples where things are already queued: An AF_INET6 tcp socket has one or more connections queued for accept. IPV6_ADDRFORM changes the socket to AF_INET. For the queued connections that have IPv4-mapped addresses this *could* result in the addresses being rewritten to be AF_INET addresses. But for queued connections using "native" IPv6 address this is not possible. It seems like the correct result in such a case would be to make TCP send a reset just as if the socket had been AF_INET (hence unable to accept native IPv6 connections) when the first TCP SYN arrived for that connection. This is complex and in any case RFC 2133 doesn't state the behavior to this detail. The same issues show up with UDP and queued datagrams. The only difference is when the address doesn't "fit" in the new address form is that UDP would drop the packet and presumably send an ICMP port unreachable. I don't think we need this complexity. But if we keep IPV6_ADDRFORM and don't specify things to this level I can't see how a portable program could use IPV6_ADDRFORM. So we might as well drop the option. Comments? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 12:55:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA00434; Thu, 2 Oct 1997 12:41:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA00427; Thu, 2 Oct 1997 12:41:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA02650; Thu, 2 Oct 1997 12:41:09 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA15793; Thu, 2 Oct 1997 12:41:08 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id MAA15716; Thu, 2 Oct 1997 12:41:06 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id MAA27842; Thu, 2 Oct 1997 12:41:05 -0700 (MST) Message-Id: <199710021941.MAA27842@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 2 Oct 1997 12:41:05 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Erik Nordmark , bound@zk3.dec.com Subject: (IPng 4629) Re: Deprecating RES_USE_INET6 and gethostbyname2() Idea Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1224 [In your message of Oct 2, 11:11am you write:] > > I think applications might also want: > GH_OPT_ALL_AF 0x04 Return all addresses from all families > An alternative would be to use AF_UNSPEC to get this behavior. The problem here is that there is only one h_length member and one h_addrtype member in the hostent{} structure. Even though you get back a list of addresses, they must all have the same length and type. (You could, of course, return IPv4-mapped when IPv6 are asked for.) Instead of trying to define yet another structure to handle this, I think we should restrict gethostbyname3() to return addresses for only one family. The addrinfo{} structure used with getaddrinfo() allows each returned address of have a different family and length, so getaddrinfo() should be used when this functionality is required. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 2 13:39:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00539; Thu, 2 Oct 1997 13:26:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00532; Thu, 2 Oct 1997 13:26:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA14645; Thu, 2 Oct 1997 13:26:00 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA28589 for ; Thu, 2 Oct 1997 13:25:32 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA11084; Thu, 2 Oct 97 13:23:54 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA00654; Thu, 2 Oct 1997 13:26:06 -0700 Date: Thu, 2 Oct 1997 13:26:06 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199710022026.NAA00654@feller.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 4630) Re: RFC 2133 - remove IPV6_ADDRFORM? Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1157 Erik, > > I think we should remove IPV6_ADDRFORM when we update RFC 2133 > since it is not needed as far as I can tell and the detailed semantics > are unclear and complex. > I agree 100%. Your analysis is right on. It is almost identical to an note which Marc Hasson posted to this list order 2 years ago. We have never been comfortable that all the edge cases had been completely specified. In addition to the overall complexity of dealing with the edge cases of the option it has never been clear to me that an application would actually need to set the option at all. There are other ways of dealing with the fork()/exec() problem which are probably cleaner. There might be some utility in allowing the option to be read-only. It is questionable though. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 15:13:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00811; Thu, 2 Oct 1997 15:01:57 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00804; Thu, 2 Oct 1997 15:01:44 -0700 Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA23975; Thu, 2 Oct 1997 15:01:41 -0700 (PDT) Date: Thu, 2 Oct 1997 15:00:15 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4631) Re: Deprecating RES_USE_INET6 and gethostbyname2() Idea To: "W. Richard Stevens" Cc: Erik Nordmark , bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199710021941.MAA27842@kohala.kohala.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2242 > [In your message of Oct 2, 11:11am you write:] > > > > I think applications might also want: > > GH_OPT_ALL_AF 0x04 Return all addresses from all families > > An alternative would be to use AF_UNSPEC to get this behavior. > > The problem here is that there is only one h_length member and one > h_addrtype member in the hostent{} structure. Even though you get > back a list of addresses, they must all have the same length and type. > (You could, of course, return IPv4-mapped when IPv6 are asked for.) I know. Thus if there are both IPv4 and IPv6 addresses the IPv4 ones would have to be returned as mapped AF_INET6 addresses. It is not clear to me what we want to return if there are only IPv4 addresses. But we could also restrict things so that the above flag is only allowed with the V4_MAPPED flag. > Instead of trying to define yet another structure to handle this, I > think we should restrict gethostbyname3() to return addresses for only > one family. Agreed. But I think there are some applications which need all IPv4+IPv6 addresses and it would make sense providing that are part of the API. > The addrinfo{} structure used with getaddrinfo() allows each returned > address of have a different family and length, so getaddrinfo() should > be used when this functionality is required. I think we should try to keep the IPv4/IPv6 related functionality identical between gethostbyname* and getaddrinfo. Otherwise we risk a case where functionality X can only be access with gethostbyname* and functionality Y can only be accessed with getaddrinfo - and the application wants to use both X and Y. Or stated differently: getaddrinfo provides a different level of abstraction than gethostbyname* and is a very useful interface. However, we should not force the use of getaddrinfo when porting applications to the IPv6 socket API. 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 Oct 2 15:43:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00864; Thu, 2 Oct 1997 15:28:05 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00857; Thu, 2 Oct 1997 15:27:50 -0700 Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA29221; Thu, 2 Oct 1997 15:27:48 -0700 (PDT) Date: Thu, 2 Oct 1997 15:26:23 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4632) Re: RFC 2133 - remove IPV6_ADDRFORM? To: Tim Hartrick Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199710022026.NAA00654@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1209 > In addition to the overall complexity of dealing with the edge cases > of the option it has never been clear to me that an application would > actually need to set the option at all. There are other ways of dealing > with the fork()/exec() problem which are probably cleaner. Exactly. In the case of inetd it should just create an AF_INET or AF_INET6 socket based on what the application (which will be exec'ed) can handle. Having inetd create an AF_INET6 socket and then trying to "downshift" it to AF_INET before the exec makes no sense to me. > There might be some utility in allowing the option to be read-only. > It is questionable though. I think applications that want to find out can instead do e.g. a getsockname() and look at the address family in the returned address. That avoids the IPV6_ADDRFORM. 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 Oct 2 15:54:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00904; Thu, 2 Oct 1997 15:39:37 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00897; Thu, 2 Oct 1997 15:39:25 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA23636; Thu, 2 Oct 1997 15:39:17 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA08839; Thu, 2 Oct 1997 15:39:11 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id PAA15935; Thu, 2 Oct 1997 15:39:10 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id PAA01582; Thu, 2 Oct 1997 15:39:09 -0700 (MST) Message-Id: <199710022239.PAA01582@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 2 Oct 1997 15:39:09 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Erik Nordmark Subject: (IPng 4634) Re: Deprecating RES_USE_INET6 and gethostbyname2() Idea Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1971 > I think we should try to keep the IPv4/IPv6 related functionality identical > between gethostbyname* and getaddrinfo. Otherwise we risk a case where > functionality X can only be access with gethostbyname* and functionality Y > can only be accessed with getaddrinfo - and the application wants to > use both X and Y. Or stated differently: getaddrinfo provides a different > level of abstraction than gethostbyname* and is a very useful interface. > However, we should not force the use of getaddrinfo when porting > applications to the IPv6 socket API. I agree, but here is the scenario that worries me. I have an application that is IPv4/IPv6 independent, rewritten to use getaddrinfo(). I distribute it to lots of people who run it on different systems. Some have a dual stack kernel, some don't. By specifying AF_UNSPEC to getaddrinfo() I get back IPv6 sockaddrs and IPv4 sockaddrs (assuming the peer is dual stack). Assuming I am a client, as long as I code the call to socket()/connect() in a loop, trying all addresses until one works, even if the run-time host does not support IPv6, when I hit the IPv4 sockaddrs, it will work. (Craig Metz pointed this out to me months ago.) I don't see how to do this with gethostbyname3(). Perhaps I am missing something? But I think we do have to worry about IPv4/IPv6 applications running on hosts without IPv6. When do you think someone like Netscape, that distributes binaries, can assume a dual stack at run time? Or do we assume that once a vendor supports IPv6, everyone running that level of the OS has IPv6? Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 2 16:25:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01079; Thu, 2 Oct 1997 16:12:08 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01072; Thu, 2 Oct 1997 16:11:54 -0700 Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id QAA08966; Thu, 2 Oct 1997 16:11:50 -0700 (PDT) Date: Thu, 2 Oct 1997 16:10:25 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4635) Re: Deprecating RES_USE_INET6 and gethostbyname2() Idea To: "W. Richard Stevens" Cc: Erik Nordmark , bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199710022239.PAA01582@kohala.kohala.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3275 > I agree, but here is the scenario that worries me. I have an application > that is IPv4/IPv6 independent, rewritten to use getaddrinfo(). I distribute > it to lots of people who run it on different systems. Some have a dual > stack kernel, some don't. By specifying AF_UNSPEC to getaddrinfo() I get > back IPv6 sockaddrs and IPv4 sockaddrs (assuming the peer is dual stack). > Assuming I am a client, as long as I code the call to socket()/connect() > in a loop, trying all addresses until one works, even if the run-time host > does not support IPv6, when I hit the IPv4 sockaddrs, it will work. (Craig > Metz pointed this out to me months ago.) I agree that this will be a very common case since I don't expect e.g. every Sun customer to enable IPv6 on all the machines just because they receive an OS upgrade that includes IPv6. Thus the protocol stack will have no IPv6 addresses. However, in the case of a UDP application it is more complicated. I have seen TCP applications that do the loop over all IPv4 addresses but I don't know of any UDP apps that do this (perhaps the BIND resolver does it). And it would look odd when I try a telnet to a multihomed machine and get: Trying x:y:1:800:20ff:fe7d:3dd2 telnet: Unable to connect to remote host: No such address Trying x:y:17:800:20ff:fe7d:3dd2 telnet: Unable to connect to remote host: No such address Trying x:y:12:800:20ff:fe7d:3dd2 telnet: Unable to connect to remote host: No such address Trying x:y:cb:800:20ff:fe7d:3dd2 telnet: Unable to connect to remote host: No such address Trying 129.146.86.31... Connected to jurassic.eng.sun.com. Which is why I think one of the useful options for gethostbyname3 (which I'll can getdynhostbyname from now to look for consensus...) is to not include IPv6 addresses when the node has no IPv6 source addresses. > I don't see how to do this with gethostbyname3(). Perhaps I am missing > something? But I think we do have to worry about IPv4/IPv6 applications > running on hosts without IPv6. When do you think someone like Netscape, > that distributes binaries, can assume a dual stack at run time? Or do > we assume that once a vendor supports IPv6, everyone running that level > of the OS has IPv6? You can do this with getdynhostbyname ine one of two ways: For call it with AF_INET6. Then when the list to try is empty call it again with AF_INET inside the loop. Or, if we add the "get me all IPv6 + IPv4 address" option you can do it in one loop. But the "get me all IPv6 + IPv4 address" option, whether with getaddrinfo or getdynhostbyname, is expensive with DNS since it forces both a AAAA query and an A query even though the host might succeed connecting with an IPv6 address thus the A query was wasted. But for this I think we also want the "exclude IPv6 addresses when the node has no IPv6 source addresses" option for performance reasons. 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 Oct 2 16:34:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01101; Thu, 2 Oct 1997 16:18:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01094; Thu, 2 Oct 1997 16:18:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA05251; Thu, 2 Oct 1997 16:18:26 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA21099 for ; Thu, 2 Oct 1997 16:18:23 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA12355; Thu, 2 Oct 97 16:16:47 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA00797; Thu, 2 Oct 1997 16:18:58 -0700 Date: Thu, 2 Oct 1997 16:18:58 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199710022318.QAA00797@feller.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 4636) Re: RFC 2133 - remove IPV6_ADDRFORM? Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 693 Erik, > > > There might be some utility in allowing the option to be read-only. > > It is questionable though. > > I think applications that want to find out can instead do e.g. a > getsockname() and look at the address family in the returned address. > That avoids the IPV6_ADDRFORM. > Good point. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 2 22:38:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01475; Thu, 2 Oct 1997 22:27:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01468; Thu, 2 Oct 1997 22:27:49 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA18158; Thu, 2 Oct 1997 22:27:47 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA17697; Thu, 2 Oct 1997 22:27:48 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id BAA25427; Fri, 3 Oct 1997 01:23:07 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09229; Fri, 3 Oct 1997 01:23:06 -0400 Message-Id: <9710030523.AA09229@wasted.zk3.dec.com> To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4638) Re: RFC 2133 - remove IPV6_ADDRFORM? In-Reply-To: Your message of "Thu, 02 Oct 1997 11:38:47 PDT." Date: Fri, 03 Oct 1997 01:23:06 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 530 Erik, I think removing this is a good idea. It was mostly for our sip day implementatons I agree. We don't need it for anything at our end. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 3 00:06:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA01538; Thu, 2 Oct 1997 23:58:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA01531; Thu, 2 Oct 1997 23:57:52 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA18754; Thu, 2 Oct 1997 23:57:50 -0700 Received: from ganga.mnrec.ernet.in (ganga.mnrec.ernet.in [202.141.55.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA03104 for ; Thu, 2 Oct 1997 23:57:39 -0700 Received: from localhost (semwal@localhost) by ganga.mnrec.ernet.in (8.7.5/8.7.3) with SMTP id MAA04445; Fri, 3 Oct 1997 12:28:10 +0530 Date: Fri, 3 Oct 1997 12:28:10 +0530 (IST) From: "Rajesh K.Semwal" Reply-To: "Rajesh K.Semwal" To: ipng@sunroof.eng.sun.com cc: netdev@nuclecu.unam.mx Subject: (IPng 4639) Connection to IPv6 hosts through IPv4. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1032 Hi, I'm working on a project to implement IPv6 under Linux Operating System, but here in our comp. center we have only IPv4 router.So how can we connect ourselves with other machines on the internet running IPv6 so that we can check for the implemented part that is mainly processed by intermediate (IPv6 supported) routers. I've heard of the translaters that can make possible the communication between IPv4 machine and other remote IPv6 machine. Where can I get this translater from, so that we can check our IPv6 implementation by interacting with other machines that are supporting IPv6. Any other suggestions in this regard will favor me. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 3 04:15:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA01695; Fri, 3 Oct 1997 04:06:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA01688; Fri, 3 Oct 1997 04:06:33 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA06029; Fri, 3 Oct 1997 04:06:31 -0700 Received: from novi.net ([194.73.60.247]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA16797 for ; Fri, 3 Oct 1997 04:06:25 -0700 Received: by novi.net from localhost (router,SLMail V2.5); Fri, 03 Oct 1997 13:06:38 +0100 Received: by novi.net from werkplek2.novi.net (194.73.60.241::mail daemon; unverified,SLMail V2.5); Fri, 03 Oct 1997 13:06:37 +0100 Received: by werkplek2.novi.net with Microsoft Mail id <01BCCFFD.589EAA00@werkplek2.novi.net>; Fri, 3 Oct 1997 13:07:48 +0100 Message-ID: <01BCCFFD.589EAA00@werkplek2.novi.net> From: "V.vanbeuningen" To: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 4640) Firewalls and IPv6 Date: Fri, 3 Oct 1997 13:07:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 780 Hi IPng guys, This is Mark van Zuijlen and Veron van Beuningen mailing. We are two = students analysing the posibilities to connect a LAN to Internet in a = safe way. We already know that we have to use a firewall. Are there any modifications necessary for using a firewall together with = IPv6? Where can we find more info on this subject? Thanks in advance, Mark van Zuijlen Veron van Beuningen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 5 09:51:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA03346; Sun, 5 Oct 1997 09:40:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA03339; Sun, 5 Oct 1997 09:40:46 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA17957; Sun, 5 Oct 1997 09:40:44 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA17124 for ; Sun, 5 Oct 1997 09:40:44 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA03597 for ; Sun, 5 Oct 1997 12:39:56 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10213; Sun, 5 Oct 1997 12:39:55 -0400 Message-Id: <9710051639.AA10213@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4641) *IMORTANT* UPDATE Clarification to Specs Date: Sun, 05 Oct 1997 12:39:55 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1020 Steve/Bob, Are we all set to move specs to new PS or DS? Also can we assume 1500 bytes as min MTU for IPv6 now? I have seen no valid objections at Munich or on this list here. It will be very useful for ICMP msgs too. We also will find this beneficial to DHCPv6. Also I sent proposed fixes to the list for addrconf issues but have seen no response from Tom or Sue? Can we please put this one to bed? ALso I assume for IPv6 the prefix will never be greater than 8 bytes? Your reponse or responses on this is important to the development of IPv6 across many specs at this point and continued implementation progress. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 6 09:44:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA03929; Mon, 6 Oct 1997 09:28:13 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA03922; Mon, 6 Oct 1997 09:28:03 -0700 Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA09863; Mon, 6 Oct 1997 09:28:02 -0700 (PDT) Date: Mon, 6 Oct 1997 09:27:01 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4642) Re: Connection to IPv6 hosts through IPv4. To: "Rajesh K.Semwal" Cc: ipng@sunroof.eng.sun.com, netdev@nuclecu.unam.mx 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 content-length: 1637 The tunneling described in RFC 1933 allows two IPv6 hosts to communicate across one or more IPv4 routers. You don't need IPv6/v4 translators when both hosts are IPv6. Erik > Hi, > I'm working on a project to implement IPv6 under Linux Operating System, > but here in our comp. center we have only IPv4 router.So how can we > connect ourselves with other machines on the internet running IPv6 so > that we can check for the implemented part that is mainly processed by > intermediate (IPv6 supported) routers. > I've heard of the translaters that can make possible the > communication between IPv4 machine and other remote IPv6 machine. > Where can I get this translater from, so that we can check our IPv6 > implementation by interacting with other machines that are supporting > IPv6. > Any other suggestions in this regard will favor me. > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 6 14:45:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04569; Mon, 6 Oct 1997 14:34:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04562; Mon, 6 Oct 1997 14:34:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04019; Mon, 6 Oct 1997 14:34:29 -0700 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA11608 for ; Mon, 6 Oct 1997 14:33:57 -0700 Received: from newt.engr.sgi.com ([150.166.75.47]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id OAA20289 for <@sgi.engr.sgi.com:ipng@sunroof.Eng.Sun.COM>; Mon, 6 Oct 1997 14:33:32 -0700 env-from (ms@newt.engr.sgi.com) Received: by newt.engr.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for ipng@sunroof.Eng.Sun.COM id OAA29657; Mon, 6 Oct 1997 14:33:32 -0700 Date: Mon, 6 Oct 1997 14:33:32 -0700 From: ms@newt.engr.sgi.com (Mark Smith) Message-Id: <199710062133.OAA29657@newt.engr.sgi.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4643) Re: Clarifications needed for Adv. Socket API options Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3640 > > inet6_option_space > ------------------ > > . In the description it states "The argument is the size of > the structure defining the option, which must include > any pad bytes at the beginning (the Y value), the type > byte, the length byte, and the option data". I think this > might need more clarification. Take for example an > alignment requirement of 8n+1. After the 'hdr ext len' > byte, we will need an additional 7 bytes to get to > 8n+1 alignment. The Y value of 1 doesn't cut it. > > . There needs to be some discussion about padding in between > options when we have more than one. In the options > examples, ip6_X_opt and ip6_Y_opt each have a structure > member on the front end which is the padding. If this > is an absolute requirement for all options structures > then this should be stated. > > . The discussion of overestimating the amount of space > by N-1 cmsghdr structures is not clear. In the example > a call is made to option_space and the argument passed in > is sizeof(X)+sizeof(Y). Option_space has no idea we're > talking about 2 options here. "The argument is the size of > the structure defining the option" so one cmsghdr structure > is assumed. > I agree that padding issues should be made clearer. It seems that you shouldn't do something like: malloc(inet6_option_space(sizeof(optX) + sizeof(optY))); unless you know what you are doing. If optX doesn't end on the boundary optY wants, padding will be inserted which wasn't taken into account in the value returned by inet6_option_space(). > > inet6_option_append > ------------------- > > . In the examples, the wording "...function notices that the > appended data requires 4 bytes of padding at the end, to > make the size of the ancillary data object a multiple of > 8...". The implies that the function always does this > before returning as the function cannot know that it will > be called again. If this is the case, it should be > spelled out in the description of the function rather than > in the text of the example. I too have a problem with this. It seems like we are added unneed padding. Let's say an option ends at 8n+2 so we pad up to the next multiple of 8. If the next option wants an alignment other than 8n+0 or 8n+1 we have more padding than we really needed. Perhaps there is a better way but you could eliminate the padding by looking at what is at the end of the extension header before adding the new option. If it is a pad1 or padN you might be able to shrink it to get the correct alignment. This seems a bit cumbersome. > inet6_option_alloc > ------------------ > Do we really need inet6_option_alloc and inet6_option_append. They are so similar. They differ basically by a bcopy. > . Further on in the examples we have "Alternately, the > application could build two ancillary data objects, one > per option...The kernel must combine these into a single..." > What if we just disallow this and save work and complexity > in the kernel? What does everyone think ?? Sounds ok to me. I was hoping that these functions could eliminate all padding work from the kernel and the user by having library functions do it all. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 7 06:45:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA05454; Tue, 7 Oct 1997 06:36:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA05447; Tue, 7 Oct 1997 06:35:55 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25250; Tue, 7 Oct 1997 06:35:52 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA00024 for ; Tue, 7 Oct 1997 06:35:45 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA23889; Tue, 7 Oct 1997 09:35:03 -0400 (EDT) Message-Id: <199710071335.JAA23889@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4644) I-D ACTION:draft-ietf-ipngwg-discovery-v2-00.txt Date: Tue, 07 Oct 1997 09:35:02 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3146 --NextPart Note: This is a re-send with correction made on the version number. 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 : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : W. Simpson, T. Narten, E. Nordmark Filename : draft-ietf-ipngwg-discovery-v2-00.txt Pages : 90 Date : 06-Oct-97 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-discovery-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-v2-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971006153005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971006153005.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 7 07:08:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA05468; Tue, 7 Oct 1997 06:58:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA05461; Tue, 7 Oct 1997 06:58:27 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01730; Tue, 7 Oct 1997 06:58:24 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA06831 for ; Tue, 7 Oct 1997 06:58:19 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA06116; Tue, 7 Oct 1997 08:58:18 -0500 Message-Id: <199710071358.IAA06116@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4645) interface-id's for tunnels and other links w/o built-ins Date: Tue, 07 Oct 1997 08:58:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 795 Could we add a sentence to say that non-global identifiers, if automatically generated, SHOULD be generated in such a way that they do not change after a reboot of the node? I think the addr-arch-v2 is the right place for such a directive, as it would apply to many types of link. I just had a 6bone BGP peering go down because the other end of the tunnel came up with a new interface-id after a reboot. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 7 07:42:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05518; Tue, 7 Oct 1997 07:30:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05511; Tue, 7 Oct 1997 07:30:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA11195; Tue, 7 Oct 1997 07:30:12 -0700 Received: from surya.ntd.comsat.com (surya.ntd.comsat.com [134.133.80.147]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA08287 for ; Tue, 7 Oct 1997 07:29:47 -0700 Received: from laurel.ntd.comsat.com by surya.ntd.comsat.com (4.1/SMI-4.1) id AA05101; Tue, 7 Oct 97 10:30:01 EDT Received: by laurel.ntd.comsat.com (SMI-8.6/SMI-SVR4) id KAA14223; Tue, 7 Oct 1997 10:27:38 -0400 Date: Tue, 7 Oct 1997 14:27:38 +0000 (GMT) From: Ravi To: ipng@sunroof.eng.sun.com Subject: (IPng 4646) IPv6 congestion control mechanisms Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 734 Hi, Is their any specific work being done with regards to congestion control, windowing and buffering for IPv6. Are there any RFCs under development that addresses these issues or are they the same as one for IPv4? Thanks * * * * * * * * * * * * * Ravi Malghan MTS, Systems Engineering Group COMSAT Labs ravi@ntd.comsat.com ************************* -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 7 07:45:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05527; Tue, 7 Oct 1997 07:35:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05520; Tue, 7 Oct 1997 07:35:15 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA12510; Tue, 7 Oct 1997 07:35:12 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA10020 for ; Tue, 7 Oct 1997 07:34:49 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id KAA10469 for ; Tue, 7 Oct 1997 10:29:58 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA28823; Tue, 7 Oct 1997 10:29:52 -0400 Message-Id: <9710071429.AA28823@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4647) new ND spec just announced on ietf announce Date: Tue, 07 Oct 1997 10:29:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 607 Tom/Erik, draft-ietf-ipngwg-discovery-v2-00.txt just came across my mailer... It has date of July 30, 1997? this is before Munich meeting? is this bogus or should we read it cause its diff than -00.txt spec? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 7 10:31:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05936; Tue, 7 Oct 1997 10:11:38 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05929; Tue, 7 Oct 1997 10:11:22 -0700 Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA11633; Tue, 7 Oct 1997 10:11:10 -0700 (PDT) Date: Tue, 7 Oct 1997 10:10:07 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4648) Re: new ND spec just announced on ietf announce To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9710071429.AA28823@wasted.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 content-length: 870 > draft-ietf-ipngwg-discovery-v2-00.txt > > just came across my mailer... It has date of July 30, 1997? > > this is before Munich meeting? > > is this bogus or should we read it cause its diff than -00.txt spec? There is no new specification. The annoucement sent out before Munich listed the draft as -02.txt. (draft-ietf-ipngwg-discovery-v2-02.txt). This was recently discovered which caused the secreatariat to send out a new announcement with the above correct name. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 7 10:34:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05948; Tue, 7 Oct 1997 10:16:40 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05941; Tue, 7 Oct 1997 10:16:27 -0700 Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA12579; Tue, 7 Oct 1997 10:15:57 -0700 (PDT) Date: Tue, 7 Oct 1997 10:14:55 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4649) Re: interface-id's for tunnels and other links w/o built-ins To: Matt Crawford Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199710071358.IAA06116@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1268 Matt, > Could we add a sentence to say that non-global identifiers, if > automatically generated, SHOULD be generated in such a way that they > do not change after a reboot of the node? I think the addr-arch-v2 > is the right place for such a directive, as it would apply to many > types of link. The temporal stability of addresses that are derived from an IEEE (Ethernet) address is an interesting area. While we want them not to change we can't blindly keep them the same since there is the off chance that somebody moves an Ethernet card to a different device. If that device is on the same Ethernet and it uses IPv6 you have to prevent the old and the new device from thinking they can use the same global IPv6 address. So how can we provide stability should the Ethernet card be tossed away while avoiding problems when the Ethernet card is reused in some other box? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 7 11:12:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06003; Tue, 7 Oct 1997 11:00:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05996; Tue, 7 Oct 1997 10:59:49 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA06353; Tue, 7 Oct 1997 10:59:45 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA12743; Tue, 7 Oct 1997 10:59:39 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA06936; Tue, 7 Oct 1997 12:59:38 -0500 Message-Id: <199710071759.MAA06936@gungnir.fnal.gov> To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4650) Re: interface-id's for tunnels and other links w/o built-ins In-reply-to: Your message of Tue, 07 Oct 1997 10:14:55 PDT. Date: Tue, 07 Oct 1997 12:59:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 879 > > Could we add a sentence to say that non-global identifiers, if > > automatically generated, SHOULD be generated in such a way that they > > do not change after a reboot of the node? > > The temporal stability of addresses that are derived from an IEEE (Ethernet) > address is an interesting area. No, no! I'm talking about the *other* sort of addresses. The one with the universal/local bit set to "local", and used on an interface such as a tunnel which has no built-in identifier. 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 Oct 8 07:12:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06505; Wed, 8 Oct 1997 07:03:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06498; Wed, 8 Oct 1997 07:02:51 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA10321; Wed, 8 Oct 1997 07:02:48 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA05482 for ; Wed, 8 Oct 1997 07:02:39 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA08913; Wed, 8 Oct 1997 09:02:17 -0500 Message-Id: <199710081402.JAA08913@gungnir.fnal.gov> To: Yoshinobu Inoue Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4652) Re: interface-id's for tunnels and other links w/o built-ins In-reply-to: Your message of Wed, 08 Oct 1997 10:34:36 +0900. <199710080134.KAA15154@guitarman.nd.net.fujitsu.co.jp> Date: Wed, 08 Oct 1997 09:02:17 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1166 > If we can suppose that V4 address will be the most stable address in > tunnel case, how about just specifying opposite v4 compatible address > as gateway of opposite routing information? Or if some implementation > can specify v4 address as gateway of v6 routing information, just > specifying opposite v4 address as gateway? That may be a start, but there may be several tunnels that have the same IPv4 address as the local endpoint, and they can't be required to all have the same IPv6 address. I'm not looking for a full prescription of how the addresses are chosen; just a strong recommendation that if an address is assigned to "tunnel number 3", that address should not change due to the addition or removal of a "tunnel number 4" ... or a "tunnel number 2". Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 8 09:37:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06601; Wed, 8 Oct 1997 09:23:01 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06594; Wed, 8 Oct 1997 09:22:55 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA05126 for ; Wed, 8 Oct 1997 09:22:55 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00531; Wed, 8 Oct 1997 09:20:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA06311; Tue, 7 Oct 1997 18:44:26 -0700 Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA05210; Tue, 7 Oct 1997 18:44:25 -0700 Received: from ebayuucp.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id SAA04091; Tue, 7 Oct 1997 18:44:25 -0700 Received: by ebayuucp.Sun.COM (SMI-8.6/SMI-4.1) id SAA24592; Tue, 7 Oct 1997 18:43:54 -0700 >Return-Path: shin@guitarman.nd.net.fujitsu.co.jp Received: from fujitsuI by ebayuucp.Ebay.Sun.COM; Tue, 7 Oct 1997 18:43 PDT Received: from fdmmail.fujitsu.co.jp ([133.161.11.2]) by fujitsuI.fujitsu.com (8.8.5/8.7.3) with ESMTP id SAA18074 for ; Tue, 7 Oct 1997 18:34:41 -0700 (PDT) Received: from guitarman.nd.net.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.5Wpl3-971001-Fujitsu Domain Mail Master) id KAA05198; Wed, 8 Oct 1997 10:34:37 +0900 (JST) Received: from guitarman (localhost [127.0.0.1]) by guitarman.nd.net.fujitsu.co.jp (8.7.4/8.6.9) with ESMTP id KAA15154; Wed, 8 Oct 1997 10:34:36 +0900 (JST) Message-Id: <199710080134.KAA15154@guitarman.nd.net.fujitsu.co.jp> To: fujitsuI!fnal.gov!crawdad@Eng Cc: fujitsuI!Eng.Sun.COM!Erik.Nordmark@Eng, fujitsuI!sunroof.Eng.sun.com!ipng@Eng Subject: (IPng 4653) Re: interface-id's for tunnels and other links w/o built-ins From: Yoshinobu Inoue In-Reply-To: Your message of "Tue, 07 Oct 1997 12:59:38 -0500" References: <199710071759.MAA06936@gungnir.fnal.gov> X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.2 Mime-Version: 1.0 Date: Wed, 08 Oct 1997 10:34:36 +0900 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1217 > > The temporal stability of addresses that are derived from an IEEE (Ethernet) > > address is an interesting area. > > No, no! I'm talking about the *other* sort of addresses. The one > with the universal/local bit set to "local", and used on an interface > such as a tunnel which has no built-in identifier. In the case of tunnel, maybe change of underlying V4 address will be the real issue. And main problem will be the change of gateway address of routing information to the opposite side. If we can suppose that V4 address will be the most stable address in tunnel case, how about just specifying opposite v4 compatible address as gateway of opposite routing information? Or if some implementation can specify v4 address as gateway of v6 routing information, just specifying opposite v4 address as gateway? Yoshinobu Inoue -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 8 09:51:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06614; Wed, 8 Oct 1997 09:33:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06607; Wed, 8 Oct 1997 09:33:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20053; Wed, 8 Oct 1997 09:33:38 -0700 Received: from saluki.cisco.com (saluki.cisco.com [171.69.1.205]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA25671 for ; Wed, 8 Oct 1997 09:33:35 -0700 Received: from [171.69.54.253] (dhcp-f-54-253.cisco.com [171.69.54.253]) by saluki.cisco.com (8.6.12/8.6.5) with ESMTP id JAA22362; Wed, 8 Oct 1997 09:33:09 -0700 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 7 Oct 1997 23:16:05 -0700 To: Ravi From: Fred Baker Subject: (IPng 4654) Re: IPv6 congestion control mechanisms Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 850 At 2:27 PM +0000 10/7/97, Ravi wrote: >Is their any specific work being done with regards to congestion control, >windowing and buffering for IPv6. Are there any RFCs under development >that addresses these issues or are they the same as one for IPv4? as far as I know, congestion management is protocol-independent. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= No animals or trees were injured in the process of generating this email. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 9 06:23:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA07592; Thu, 9 Oct 1997 06:13:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA07585; Thu, 9 Oct 1997 06:11:40 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA28805; Thu, 9 Oct 1997 06:11:35 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA00152 for ; Thu, 9 Oct 1997 06:11:23 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA14835; Thu, 9 Oct 1997 08:58:28 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA16406; Thu, 9 Oct 1997 08:58:27 -0400 Message-Id: <9710091258.AA16406@wasted.zk3.dec.com> To: ms@newt.engr.sgi.com (Mark Smith) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4658) Re: Clarifications needed for Adv. Socket API options In-Reply-To: Your message of "Mon, 06 Oct 1997 14:33:32 PDT." <199710062133.OAA29657@newt.engr.sgi.com> Date: Thu, 09 Oct 1997 08:58:27 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 840 Richard Stevens/Matt Thomas, Can we please get a reply to Mark and Garys mail on the inet_xxx's for padding et al sent to this list. We are building the Advanced API now and need it for several system applications for IPv6. We want to move to the new advanced API. We will have to build work arounds if we don't fix it here soon and get some input from you guys if you too as some of us believe that some of this is broken in the Advanced API. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 9 09:19:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07768; Thu, 9 Oct 1997 09:10:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07761; Thu, 9 Oct 1997 09:09:59 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA14324; Thu, 9 Oct 1997 09:09:57 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA22482 for ; Thu, 9 Oct 1997 09:09:46 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id JAA02371; Thu, 9 Oct 1997 09:09:44 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id JAA05223; Thu, 9 Oct 1997 09:09:44 -0700 (MST) Message-Id: <199710091609.JAA05223@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 9 Oct 1997 09:09:44 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: bound@zk3.dec.com Subject: (IPng 4659) Re: Clarifications needed for Adv. Socket API options Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2519 [In your message of Oct 9, 8:58am you write:] > Richard Stevens/Matt Thomas, > > Can we please get a reply to Mark and Garys mail on the inet_xxx's for > padding et al sent to this list. We are building the Advanced API now > and need it for several system applications for IPv6. We want to move > to the new advanced API. We will have to build work arounds if we don't > fix it here soon and get some input from you guys if you too as some of > us believe that some of this is broken in the Advanced API. Jim: you do have a way with words, don't you. Reality check time for you. First, I got involved with the Advanced API at the Los Angeles IETF when you and Matt asked me to take it over and get it out. Fine. The same thing happened with the basic API (RFC 2133) when it stalled due to other's lack of time. Fine with me. I think both documents are a good start, but am the first to admit that neither is absolutely perfect. Time to implement and then update. Second, IETF is all volunteer work for me (I am self employed) and I do not have an employer who pays me to work on IETF stuff, or to send me to IETF meetings. That's fine with me too, as I've enjoyed the work and like working on things that are leading edge. BUT, this means my IETF work is not the top of my queue. Period. I do have other committments and obligations (that pay my bills). This seems to be a real problem for you. First you were demanding that an update to RFC 2133 be out by October 1. Now this email to the list. I am not producing an IPv6 product for anyone. This may be why the two API documents are not as high on my queue as they are on your's. Perhaps it is time for me to step aside from both documents and let someone who is producing APIs based on these two specs take them over. I have no emotional attachment to either API document. Anyone who has more time (yourself included) who wants to get them out by your schedule, the documents are yours. Or perhaps it is time to bring in the hired guns (XNET), who I believe are all paid by their employers to work on XNET stuff, and let them finish the specs. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 9 12:54:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07922; Thu, 9 Oct 1997 12:44:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07915; Thu, 9 Oct 1997 12:44:09 -0700 From: bound@zk3.dec.com Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA15150; Thu, 9 Oct 1997 12:44:05 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA01514 for ; Thu, 9 Oct 1997 12:43:57 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA24088; Thu, 9 Oct 1997 15:27:12 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19748; Thu, 9 Oct 1997 15:27:11 -0400 Message-Id: <9710091927.AA19748@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4660) Re: Clarifications needed for Adv. Socket API options In-Reply-To: Your message of "Thu, 09 Oct 1997 09:09:44 PDT." <199710091609.JAA05223@kohala.kohala.com> Date: Thu, 09 Oct 1997 15:27:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4417 Richard, >> Can we please get a reply to Mark and Garys mail on the inet_xxx's for >> padding et al sent to this list. We are building the Advanced API now >> and need it for several system applications for IPv6. We want to move >> to the new advanced API. We will have to build work arounds if we don't >> fix it here soon and get some input from you guys if you too as some of >> us believe that some of this is broken in the Advanced API. >Jim: you do have a way with words, don't you. Reality check time for you. OK thats fair. >First, I got involved with the Advanced API at the Los Angeles IETF >when you and Matt asked me to take it over and get it out. Fine. >The same thing happened with the basic API (RFC 2133) when it stalled >due to other's lack of time. Fine with me. I think both documents >are a good start, but am the first to admit that neither is absolutely >perfect. Time to implement and then update. Agreed. >Second, IETF is all volunteer work for me (I am self employed) and I >do not have an employer who pays me to work on IETF stuff, or to send >me to IETF meetings. That's fine with me too, as I've enjoyed the work >and like working on things that are leading edge. Glad you do this too its a big help. >BUT, this means my IETF work is not the top of my queue. Period. I do >have other committments and obligations (that pay my bills). This seems >to be a real problem for you. First you were demanding that an update >to RFC 2133 be out by October 1. Now this email to the list. Whoa slow down. I am really sick of people not being able to handle a direct piece of mail without adding context to what I said. This really gets me ticked off. First, I never said that anything your doing is a problem for me so do not put words in my mouth or take great liberties reading btw any lines I use with words I do not have any sublimal messages on this particular thread. Second I never "demanded" (using this word is really bogus) anything of anyone. Third I never said back in August (when I suggested a time frame) that we needed a new draft out by Oct 1st but that we needed a decision by Oct 1st. It appears we have that decision to me based on the last mail exchanges. >I am not producing an IPv6 product for anyone. This may be why the two >API documents are not as high on my queue as they are on your's. Perhaps >it is time for me to step aside from both documents and let someone who >is producing APIs based on these two specs take them over. Well I think we can take this offline and I am willing to help get this done. I think an updated RFC 2133+ by mid-Novemember and last call would be really good. I am assuming though we are only talking about updating the text for DNS interaction. I am hearing that XNET wants to suggest some internationalization parts that could be major edit headaches and I just don't know the scale of that right now. >I have no emotional attachment to either API document. Anyone who has >more time (yourself included) who wants to get them out by your schedule, >the documents are yours. Well not really as you do a good job. I will connect with you offline I can steal some cycles somewhere. >Or perhaps it is time to bring in the hired guns (XNET), who I believe >are all paid by their employers to work on XNET stuff, and let them >finish the specs. Well if they just build what we want for the update to RFC 2133 and get us to RFC 3124 which will obsolete RFC 2133 on the index that is great. But I think we need to do that. Also above all I was asking for was if you saw the problem that Mark and Gary stated to the list with the API not to rewrite it today. Your thoughts were more important at this point. Note the phrase "get some input from you guys" to me is a hip way of saying do you think the input was invalid or do you see this error too. How one would get I demanded anything from that is beyond my interpretation of the American language system (note I did not say English language system on purpose). /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 10 13:15:47 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id NAA09267 for ipng-dist; Fri, 10 Oct 1997 13:13:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id NAA09260 for ; Fri, 10 Oct 1997 13:12:51 -0700 (PDT) Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA09142; Fri, 10 Oct 1997 13:12:48 -0700 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA21955 for ; Fri, 10 Oct 1997 13:12:23 -0700 Received: from newt.engr.sgi.com ([192.26.75.28]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id NAA18853 for <@sgi.engr.sgi.com:ipng@sunroof.Eng.Sun.COM>; Fri, 10 Oct 1997 13:12:21 -0700 env-from (ms@newt.engr.sgi.com) Received: by newt.engr.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) for ipng@sunroof.Eng.Sun.COM id NAA11090; Fri, 10 Oct 1997 13:12:21 -0700 Date: Fri, 10 Oct 1997 13:12:21 -0700 From: ms@newt.engr.sgi.com (Mark Smith) Message-Id: <199710102012.NAA11090@newt.engr.sgi.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4661) advanced api Sender: owner-ipng@eng.sun.com Precedence: bulk The description of inet6_rthdr_segments seems overly restrictive to me. It states: "On success the return value is between 1 and 23, inclusive." This is true for a Type 0 Routing header but may not be for others. I would prefer the statement read as follows: For an IPv6 Type 0 Routing header, on success the return value is between 1 and 23, inclusive. This brings me to a related topic. It appears to me that the interface is tied rather closely to the current implementation of Type 0 Routing headers. For example Type 0 has a reserved byte which can not be accessed with this interface. There is no need now but it might be useful to conveniently get at it in the future. Also, the interface assumes pairs of (int, in6_addr) where the case of Type 0 the 'int' is a single bit. I have no idea what someone might do in the future with the Routing header. Maybe Type 1 will have 64 bits associated with each address. Would it be better to follow the style used with the hop-by-hop and destination headers? Basically we supply a structure, that the user fills in, and an init function which initializes the 'system' part (ie. the part that is the same for all options). The API would the consist of 3 things: struct rt_type_0 { int rt0_reserved:8; rt0_slflags:24; in6_addr rt0_addrs[1]; /* Could be longer */ } inet6_rthdr_space() in6_rthdr_init(); The user fills in the struct rt_type_0 just like they have to fill in the options that get passed to inet6_option_append(). That way the API handles the parts that are always the same (cmsg and the 4 byte routing header). The user handles the type-specific data. Basically, what I am suggesting is that the API should not initialize the type specific portions of the option. Leave that to the user. We do that now with hop-by-hop and destination options. Lets also do that with Routing options. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 12 17:55:22 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id RAA10184 for ipng-dist; Sun, 12 Oct 1997 17:52:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id RAA10177 for ; Sun, 12 Oct 1997 17:52:33 -0700 (PDT) Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA21073; Sun, 12 Oct 1997 17:52:03 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA11199 for ; Sun, 12 Oct 1997 17:51:50 -0700 Received: from spruce.ipsilon.com ([205.226.22.76]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA16278; Sun, 12 Oct 1997 17:50:43 -0700 Message-Id: <3.0.3.32.19971012174956.008e7780@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 12 Oct 1997 17:49:56 -0700 To: Jeffrey Burgan From: Bob Hinden Subject: (IPng 4663) Request to Advance IPv6 over Ethernet and FDDI Documents Cc: narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following documents be published as a Proposed Standard: Title : Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-ethernet-03.txt Pages : 6 Date : 1997-09-26 This document replaces RFC 1972, 'A Method for the Transmission of IPv6 Packets over Ethernet Networks', which will become historic. Title : Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-fddi-net-03.txt Pages : 7 Date : 1997-09-26 This document replaces RFC 2019, 'Transmission of IPv6 Packets Over FDDI', which will become historic. A working group last call for this document was completed on August 13, 1997. These draft incorporates changes based on comments received during the w.g. last call. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 12 21:25:27 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id VAA10286 for ipng-dist; Sun, 12 Oct 1997 21:22:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id VAA10279 for ; Sun, 12 Oct 1997 21:22:38 -0700 (PDT) Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA05094; Sun, 12 Oct 1997 21:22:37 -0700 Received: from santacruz.org (santacruz.org [207.86.120.165]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAB16048 for ; Sun, 12 Oct 1997 21:22:29 -0700 Received: from localhost (jest@localhost) by santacruz.org (8.8.7/8.8.5) with SMTP id VAA19967; Sun, 12 Oct 1997 21:30:18 -0700 Date: Sun, 12 Oct 1997 21:30:18 -0700 (PDT) From: Gregory Taylor To: Bob Hinden cc: Jeffrey Burgan , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 4664) Re: Request to Advance IPv6 over Ethernet and FDDI Documents In-Reply-To: <3.0.3.32.19971012174956.008e7780@mailhost.ipsilon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk On Sun, 12 Oct 1997, Bob Hinden wrote: Publish them and propose them. Any changes that may be needed should be written to the W.G. I have a question.. anyone have a prediction of when IPv6 would be integrated into all unix systems and internet/lan/intranet networks? I would like to know, email me jest@santacruz.org. Thank you. > Jeff, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following documents be published as a > Proposed Standard: > > Title : Transmission of IPv6 Packets over > Ethernet Networks > Author(s) : M. Crawford > Filename : draft-ietf-ipngwg-trans-ethernet-03.txt > Pages : 6 > Date : 1997-09-26 > > This document replaces RFC 1972, 'A Method for the Transmission of > IPv6 Packets over Ethernet Networks', which will become historic. > > > Title : Transmission of IPv6 Packets over FDDI Networks > Author(s) : M. Crawford > Filename : draft-ietf-ipngwg-trans-fddi-net-03.txt > Pages : 7 > Date : 1997-09-26 > > This document replaces RFC 2019, 'Transmission of IPv6 Packets Over > FDDI', which will become historic. > > A working group last call for this document was completed on August 13, > 1997. These draft incorporates changes based on comments received during > the w.g. > last call. > > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > Thank You, Gregory Taylor Owner Resourceful Network Solutions, Inc. (253) 475-1227 jest@santacruz.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 13 05:54:34 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id FAA10393 for ipng-dist; Mon, 13 Oct 1997 05:51:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id FAA10386 for ; Mon, 13 Oct 1997 05:51:45 -0700 (PDT) Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA11313; Mon, 13 Oct 1997 05:51:43 -0700 Received: from elrond.uc3m.es (elrond.uc3m.es [163.117.136.62]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA22162 for ; Mon, 13 Oct 1997 05:51:25 -0700 Received: from muza.uc3m.es (paraiso.uc3m.es) by elrond.uc3m.es (4.1/SM941027.01) id AA15545; Mon, 13 Oct 97 14:50:34 +0100 Message-Id: <34421832.91967F55@inf.uc3m.es> Date: Mon, 13 Oct 1997 13:46:42 +0200 From: Jose Maria Sierra Camara Organization: Universidad Carlos III de Madrid X-Mailer: Mozilla 4.01 [en] (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 4665) Ip ng security. X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@eng.sun.com Precedence: bulk "I would like to know if anybody knows a particular News group or Distribution List that might be dedicated to Next Generation IP Security System(Protocol)(on the Net)(for file transfer protocol/ftp)." Thanks. -- ————————————————————— José María Sierra Cámara Profesor ayudante Departamento de Informática Correo electrónico: sierra@inf.uc3m.es Universidad Carlos III de Madrid C/ Butarque, 15. 28911 Leganés (Madrid) ————————————————————— -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 13 07:31:46 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id HAA10475 for ipng-dist; Mon, 13 Oct 1997 07:29:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id HAA10468 for ; Mon, 13 Oct 1997 07:28:58 -0700 (PDT) From: bound@zk3.dec.com Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA01893; Mon, 13 Oct 1997 07:28:57 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA14575 for ; Mon, 13 Oct 1997 07:28:48 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA03002; Mon, 13 Oct 1997 09:40:32 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA02006; Mon, 13 Oct 1997 09:40:28 -0400 Message-Id: <9710131340.AA02006@wasted.zk3.dec.com> To: Gregory Taylor Cc: Bob Hinden , Jeffrey Burgan , narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4666) Re: Request to Advance IPv6 over Ethernet and FDDI Documents In-Reply-To: Your message of "Sun, 12 Oct 1997 21:30:18 PDT." Date: Mon, 13 Oct 1997 09:40:27 -0400 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk > I have a question.. anyone have a prediction of when IPv6 would be >integrated into all unix systems and internet/lan/intranet networks? I >would like to know, email me jest@santacruz.org. Thank you. If the addressing architecture can move to Draft Standard by Jan 1998, and then Full Standard by June 1998, major Intranets (private) companies will begin to deploy IPv6 in 1998-1999. This will drive requests to ISPs for IPv6 addresses and there will be a market for IPv6 at the provider level. Providers will not be used who cannot provide IPv6 addresses or some type of support for them and this will let the markeet begin for IPv6. Many are having some pain now with IPv4 and would take IPv6 today if they could get it right now. Not everyone wants NAT and Private addresses. The two parts missing for deployment right now are: 1. Is the TLA for addr arch big enough (13 bits)? This will permit aggressive providers to obtain an IPv6 TLA for their customers. Right now they can't get one from IANA, which is clearly a problem right now. 2. Need in transition group NO-NAT so Intranets can use IPv4 temporary assigned addresses after having moved to IPv6. The vendors may or may not wait on the IETF processes for this part is my reading. We don't have two years to discuss it. I also think several host vendors will and do provide in some cases today IPv6 enabled on their platforms today and in early 1998 so ISVs can start porting applications to be IPv4/IPv6 smart. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 13 11:29:58 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id LAA10718 for ipng-dist; Mon, 13 Oct 1997 11:26:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id LAA10711 for ; Mon, 13 Oct 1997 11:26:35 -0700 (PDT) Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA19736; Mon, 13 Oct 1997 11:25:46 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA21151 for ; Mon, 13 Oct 1997 11:25:30 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id MAA03082; Mon, 13 Oct 1997 12:51:05 -0400 (EDT) Message-Id: <199710131651.MAA03082@brookfield.ans.net> To: Dimitry Haskin cc: Pedro Marques , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4667) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Thu, 25 Sep 1997 18:20:32 EDT." <3.0.32.19970925182031.006dfec8@pobox> Date: Mon, 13 Oct 1997 12:51:04 -0400 From: Curtis Villamizar Sender: owner-ipng@eng.sun.com Precedence: bulk In message <3.0.32.19970925182031.006dfec8@pobox>, Dimitry Haskin writes: > At 02:14 PM 9/25/97 -0700, Pedro Marques wrote: > >The discussion so far as been on what to carry on a EBGP peering on a direct > >link and my proposal doesn't restrict anyone from doing anything they wish. > > I don't get why it so difficult to understand but you're forcing one to > assign a global address to the IX interface. That hardly qualifies as > "doesn't restrict anyone from doing anything they wish". > > Dimitry This is exactly as it should be. There must be a globally significant address for the IX interface and it cannot change with renumbering of any of the peers at the IX. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 13 12:29:19 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id MAA10889 for ipng-dist; Mon, 13 Oct 1997 12:25:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id MAA10882 for ; Mon, 13 Oct 1997 12:25:37 -0700 (PDT) Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA13251; Mon, 13 Oct 1997 12:25:25 -0700 Received: from mailhost1.BayNetworks.COM ([134.177.3.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA17645 for ; Mon, 13 Oct 1997 12:25:14 -0700 Received: from ns1.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id MAA07389 Posted-Date: Mon, 13 Oct 1997 12:12:09 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.61.6]) by ns1.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id MAA20843; Mon, 13 Oct 1997 12:24:36 -0700 (PDT) Received: from andover.engeast (andover [192.32.174.201]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA05493; Mon, 13 Oct 1997 15:24:35 -0400 for Date: Mon, 13 Oct 1997 15:24:35 -0400 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199710131924.PAA05493@pobox.engeast.BayNetworks.COM> To: curtis@ans.net Subject: (IPng 4669) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Sender: owner-ipng@eng.sun.com Precedence: bulk Curtis, > > In message <3.0.32.19970925182031.006dfec8@pobox>, Dimitry Haskin writes: > > At 02:14 PM 9/25/97 -0700, Pedro Marques wrote: > > >The discussion so far as been on what to carry on a EBGP peering on a direct > > >link and my proposal doesn't restrict anyone from doing anything they wish. > > > > I don't get why it so difficult to understand but you're forcing one to > > assign a global address to the IX interface. That hardly qualifies as > > "doesn't restrict anyone from doing anything they wish". > > > > Dimitry > > > This is exactly as it should be. There must be a globally significant > address for the IX interface and it cannot change with renumbering of > any of the peers at the IX. > > Curtis > I agree that as far as IPv4 is concerned it is the only option to make IX interfaces impervious to the renumbering of peer ASs. I'm not convinced that it is the only option in IPv6. I understand the remote monitoring issue but I hope it can be solved with proper tools that utilize the source routing. Note that I'm not proposing to elimibate the possibility of assigning global addresses to the IX interface -- it may turn out to be the preferred way to handle IX interfaces. I just think that eliminating other deployment options that are possible in IPv6 even before we get chance to experiment and learn is unwise. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 13 18:24:30 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id SAA11264 for ipng-dist; Mon, 13 Oct 1997 18:16:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id SAA11257 for ; Mon, 13 Oct 1997 18:16:10 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA15434 for ; Mon, 13 Oct 1997 18:16:06 -0700 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA17714 for ; Mon, 13 Oct 1997 18:16:06 -0700 Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Mon Oct 13 21:14:51 EDT 1997 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research; Mon Oct 13 21:14:55 EDT 1997 Received: from dnrc.bell-labs.com (gjapc [135.180.130.101]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA11509; Mon, 13 Oct 1997 21:12:16 -0400 (EDT) Message-ID: <3442C77F.B7B855CF@dnrc.bell-labs.com> Date: Mon, 13 Oct 1997 21:14:39 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ion@nexen.com CC: ipng@sunroof.eng.sun.com Subject: (IPng 4670) New IPv6/NBMA docs released Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk Hi all, As discussed in Munich, the existing IPv6/NBMA(ATM) doc was woefully unclear about how it could (a) be generalized beyond ATM, and (b) how the pt-pt case was to be handled. This has been addressed through a restructuring of the I-D into 2 docs - a core IPv6/NBMA architecture document, and an ATM-specific companion document. The core document is now quite general, and the expectation is that other NBMA-specific companion docs will be generated fairly simply under this architecture. The docs will be available from your favorite I-D archive this week, but for interested readers they're available now from: "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", http://nj5.injersey.com/~gja/internet-drafts/draft-ietf-ion-ipv6-00.txt "IPv6 over ATM Networks" http://nj5.injersey.com/~gja/internet-drafts/draft-ietf-ion-ipv6-atm-00.txt The companion doc provides ATM specific codepoints, including those for the PVC/pt-pt case. cheers, gja ________________________________________________________________________ Grenville Armitage High Speed Networks Research http://nj5.injersey.com/~gja Bell Labs, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 13 20:41:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id UAA11309 for ipng-dist; Mon, 13 Oct 1997 20:38:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id UAA11302 for ; Mon, 13 Oct 1997 20:38:38 -0700 (PDT) From: HDhil@aol.com Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA01768 for ; Mon, 13 Oct 1997 20:38:38 -0700 Received: from emout32.mail.aol.com (emout32.mx.aol.com [198.81.11.15]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA17708 for ; Mon, 13 Oct 1997 20:38:37 -0700 Received: (from root@localhost) by emout32.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id XAA00546; Mon, 13 Oct 1997 23:38:35 -0400 (EDT) Date: Mon, 13 Oct 1997 23:38:35 -0400 (EDT) Message-ID: <971013233426_1565754146@emout07.mail.aol.com> To: sierra@inf.uc3m.es, ipng@sunroof.eng.sun.com Subject: (IPng 4671) Re: Ip ng security. Sender: owner-ipng@eng.sun.com Precedence: bulk Jose: I presume you are referring to IPng security in general. The IPsec working group has specified a core set of authentication and encryption mechanisms for IPv6 as well as a key management/exchange protocol (ISAKMP/Oakley). For general discussion: ipsec@tis.com Or to subscribe to the IPsec list: ipsec-request@tis.com You can also check the IPsec page at the IETF web site for the latest standards track documents themselves. Harry Dhillon Lucent Technologies Phone: (732) 224-8013 Fax: (732) 224-3202 E-mail: hdhillon@lucent.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 14 08:14:52 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id IAA11634 for ipng-dist; Tue, 14 Oct 1997 08:12:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id IAA11627 for ; Tue, 14 Oct 1997 08:12:04 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA01259 for ; Tue, 14 Oct 1997 08:12:01 -0700 Received: from dxcnaf.cnaf.infn.it (dxcnaf.cnaf.infn.it [131.154.3.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA00575 for ; Tue, 14 Oct 1997 08:11:57 -0700 Received: from localhost (chierici@localhost) by dxcnaf.cnaf.infn.it (8.8.5/8.8.5) with SMTP id RAA22895 for ; Tue, 14 Oct 1997 17:11:38 +0200 (MET DST) Date: Tue, 14 Oct 1997 17:11:38 +0200 (MET DST) From: Andrea Chierici To: ipng@sunroof.eng.sun.com Subject: (IPng 4672) IPv4 compatibility Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Hi, I would like to know something more about the IP4v compatibility of ipng. When an IPv6 only machine whishes to comunicate with an IPv4 only machine for example... we have to use the IPv4-mapped address... well I think that the translation of the address into a pure ipv4 address will be done by the last hop router, the one next to the ipv4 only machine, am I right? And i think that the router will convert all the ipv6 packets into Ipv4 too... will this create a lack of performances?? Can anyone point me to a document that explains this issue in detail? Thanks, Andrea ----------------------------------------- Andrea Chierici, Computer Science Student INFN-CNAF Bologna ITALY ----------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 15 01:21:12 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id BAA12573 for ipng-dist; Wed, 15 Oct 1997 01:18:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id BAA12566 for ; Wed, 15 Oct 1997 01:18:16 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA24333 for ; Wed, 15 Oct 1997 01:18:15 -0700 Received: from att.com (kcgw1.att.com [192.128.133.151]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA14813 for ; Wed, 15 Oct 1997 01:18:14 -0700 Received: by kcgw1.att.com; Wed Oct 15 03:15 CDT 1997 Received: from eurdirsync.be.att.com (eurdirsync.be.att.com [135.76.165.12]) by kcig1.att.att.com (AT&T/GW-1.0) with SMTP id DAA15379 for ; Wed, 15 Oct 1997 03:07:53 -0500 (CDT) Received: by eurdirsync.be.att.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCD94B.861C56B0@eurdirsync.be.att.com>; Wed, 15 Oct 1997 09:20:05 +0100 Message-ID: From: "Buclin, Bertrand" To: "'Francis Dupont'" , "'Bob Hinden'" Cc: "'brian@hursley.ibm.com'" , "'deering@cisco.com'" , "'6bone@ISI.EDU'" <6bone@ISI.EDU>, "'ipng@sunroof.eng.sun.com'" Subject: (IPng 4675) RE: query re IPv6 URL format Date: Wed, 15 Oct 1997 10:16:39 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk On Tuesday, October 14, 1997 9:09 PM, Francis Dupont [SMTP:Francis.Dupont@inria.fr] wrote: > > > => it is very easy and as far as I know enough to support DNS names > (and the terrible RES_USE_INET6 stuff). Personally I think the right > thing to do is to kill literals (IPv4 literals too)! > Although user-friendliness calls for killing literals, as you suggest Francis, I believe it would be a serious mistake to do it: - When you are setting up a network, you don't necessarily have DNS in place from day one. - When troubleshooting a network problem, the least thing you want is to first debug DNS issues... and in general if you have network issues, chances are that DNS will be affected too. - We know that DNS can return erroneous results from time to time (becaues of stale data in caches, bogus nameservers, etc...). The only way to overcome those conditions is to use litterals. Literals are an essential feature that we must preserve, else it will become impossible to operate the networks. Cheers, Bertrand _____________________________________________________ Bertrand Buclin Service & Product Development Manager AT&T Labs Europe Phone: +41 22 929 37 40 Fax: +41 22 929 49 85 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 15 11:12:07 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id LAA12912 for ipng-dist; Wed, 15 Oct 1997 11:08:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id LAA12905 for ; Wed, 15 Oct 1997 11:08:33 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA11863 for ; Wed, 15 Oct 1997 11:08:28 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA23468 for ; Wed, 15 Oct 1997 11:08:22 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id UAA06369; Wed, 15 Oct 1997 20:08:16 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA05883; Wed, 15 Oct 1997 20:08:15 +0200 (MET DST) Message-Id: <199710151808.UAA05883@givry.inria.fr> From: Francis Dupont To: "Buclin, Bertrand" cc: "'Bob Hinden'" , "'brian@hursley.ibm.com'" , "'deering@cisco.com'" , "'6bone@ISI.EDU'" <6bone@isi.edu>, "'ipng@sunroof.eng.sun.com'" Subject: (IPng 4677) Re: query re IPv6 URL format In-reply-to: Your message of Wed, 15 Oct 1997 10:16:39 BST. Date: Wed, 15 Oct 1997 20:08:07 +0200 Sender: owner-ipng@eng.sun.com Precedence: bulk In your previous mail you wrote: > Personally I think the right thing to do is to kill literals > (IPv4 literals too)! Although user-friendliness calls for killing literals, as you suggest Francis, I believe it would be a serious mistake to do it: ... (some good arguments) Literals are an essential feature that we must preserve, else it will become impossible to operate the networks. => I have changed my mind. I'd still like to kill literals but without killing the functionality. The best proposal I saw is to use names in the ip6.int domain. They have strictly the same information than literals, but they are full standard DNS names and very easy to recognize, parse and use (ie reverse). I know only one drawback: one has to use a tool in order to get it (here I use "nslookup -debug -type=ptr" and cut & paste). For instance the address: 3ffe:306:1051:8300:220:feff:fe00:8781 becomes the name: 1.8.7.8.0.0.e.f.f.f.e.f.0.2.2.0.0.0.3.8.1.5.0.1.6.0.3.0.e.f.f.3.ip6.int Another advantage is this solution is general and can be used for all the cases (URL, X11, RFC 822, ...). Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 15 12:19:46 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id MAA13043 for ipng-dist; Wed, 15 Oct 1997 12:16:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id MAA13036 for ; Wed, 15 Oct 1997 12:16:47 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA01599 for ; Wed, 15 Oct 1997 12:16:42 -0700 Received: from merit.edu (merit.edu [198.108.1.42]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA15030 for ; Wed, 15 Oct 1997 12:16:40 -0700 Received: from merit.edu (masaki@osaka.merit.edu [198.108.60.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA12054; Wed, 15 Oct 1997 15:15:52 -0400 (EDT) Message-Id: <199710151915.PAA12054@merit.edu> To: Francis Dupont cc: "Buclin, Bertrand" , "'Bob Hinden'" , "'brian@hursley.ibm.com'" , "'deering@cisco.com'" , "'6bone@ISI.EDU'" <6bone@isi.edu>, "'ipng@sunroof.eng.sun.com'" Subject: (IPng 4678) Re: query re IPv6 URL format In-reply-to: Your message of "Wed, 15 Oct 1997 20:08:07 +0200." <199710151808.UAA05883@givry.inria.fr> Date: Wed, 15 Oct 1997 15:15:47 -0400 From: Masaki Hirabaru Sender: owner-ipng@eng.sun.com Precedence: bulk > 3ffe:306:1051:8300:220:feff:fe00:8781 3ffe%3a306%3a1051%3a8300%3a220%3afeff%3afe00%3a8781 I think that this should work in url. -- Masaki -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 15 15:34:36 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id PAA13309 for ipng-dist; Wed, 15 Oct 1997 15:31:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id PAA13302 for ; Wed, 15 Oct 1997 15:31:32 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA20512 for ; Wed, 15 Oct 1997 15:31:29 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA13681 for ; Wed, 15 Oct 1997 15:31:06 -0700 Received: (qmail 26407 invoked by uid 502); 15 Oct 1997 22:30:58 -0000 Message-ID: <19971015223058.26404.qmail@mail.ocs.com.au> Received: (qmail 26388 invoked from network); 15 Oct 1997 22:30:53 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Oct 1997 22:30:52 -0000 From: Keith Owens To: Francis Dupont Cc: 6bone@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 4679) Re: query re IPv6 URL format In-reply-to: Your message of "Wed, 15 Oct 1997 20:08:07 +0200." <199710151808.UAA05883@givry.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Oct 1997 08:30:56 +1000 Sender: owner-ipng@eng.sun.com Precedence: bulk On Wed, 15 Oct 1997 20:08:07 +0200, Francis Dupont wrote: >I know only one drawback: one has to use a tool >in order to get it (here I use "nslookup -debug -type=ptr" and cut & paste). Try this, I got fed up with typing as well :) #!/usr/bin/perl -w # # ip6_int # # Convert valid IPv6 address to ip6.int PTR value. Convert valid # IPv4 address to in-addr.arpa PTR value. Anything not valid is # simply printed as is. Handles :: notation and embedded IPv4 # addresses. If the address is followed by /n, the PTR is # truncated to n bits. # # Examples: # nslookup -type=any `ip6_int 3ffe::203.34.97.6` looks up # 6.0.1.6.2.2.b.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.f.f.3.ip6.int # nslookup -type=any `ip6_int fe80::b432:e6ff/10` looks up # 2.e.f.ip6.int # nslookup -type=any `ip6_int ::127.0.0.1` looks up # 1.0.0.0.0.0.f.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int # nslookup -type=any `ip6_int 127.0.0.1` looks up # 1.0.0.127.in-addr.arpa # nslookup -type=any `ip6_int 127.0.0.1/8` looks up # 127.in-addr.arpa # # Copyright 1997 Keith Owens . GPL. # require 5; use strict; use integer; my $v6; if ($#ARGV >= 0 && ($v6 = ($ARGV[0] =~ m;^([0-9a-fA-f:]+)(?::(\d+\.\d+\.\d+\.\d+))?(?:/(\d+))?$;)) || $ARGV[0] =~ m;^(\d+\.\d+\.\d+\.\d+)(?:/(\d+))?$;) { my $valid = 1; if ($v6) { my (@chunk) = split(/:/, $1, 99); my $mask = $3; if ($2) { my (@v4) = split(/\./, $2); $valid = ($v4[0] <= 255 && $v4[1] <= 255 && $v4[2] <= 255 && $v4[3] <= 255); if ($valid) { push(@chunk, sprintf("%x%02x", $v4[0], $v4[1])); push(@chunk, sprintf("%x%02x", $v4[2], $v4[3])); } } my $pattern = ""; if ($valid) { foreach (@chunk) { $pattern .= /^$/ ? 'b' : 'c'; } if ($pattern =~ /^bbc+$/) { @chunk = (0, 0, @chunk[2..$#chunk]); @chunk = (0, @chunk) while ($#chunk < 7); } elsif ($pattern =~ /^c+bb$/) { @chunk = (@chunk[0..$#chunk-2], 0, 0); push(@chunk, 0) while ($#chunk < 7); } elsif ($pattern =~ /^c+bc+$/) { my @left; push(@left, shift(@chunk)) while ($chunk[0] ne ""); shift(@chunk); push(@left, 0); push(@left, 0) while (($#left + $#chunk) < 6); @chunk = (@left, @chunk); } $valid = $#chunk == 7; } my $ip6int = "ip6.int"; my $i; if ($valid) { foreach (@chunk) { $i = hex($_); if ($i > 65535) { $valid = 0; } else { $ip6int = sprintf("%x.%x.%x.%x.", ($i) & 0xf, ($i >> 4) & 0xf, ($i >> 8) & 0xf, ($i >> 12) & 0xf) . $ip6int; } } } if ($valid && defined($mask)) { $valid = ($mask =~ /^\d+$/ && $mask <= 128); if ($valid) { $ip6int = substr($ip6int, int((128-$mask)/4)*2); if ($mask &= 3) { $i = hex(substr($ip6int, 0, 1)); $i >>= (4-$mask); substr($ip6int, 0, 1) = sprintf("%x", $i); } } } $ARGV[0] = $ip6int if ($valid); } else { # v4 my (@v4) = split(/\./, $1); my $mask = $2; $valid = ($v4[0] <= 255 && $v4[1] <= 255 && $v4[2] <= 255 && $v4[3] <= 255); my $v4 = hex(sprintf("%02X%02X%02X%02X", @v4)); if ($valid && defined($mask)) { $valid = ($mask =~ /^\d+$/ && $mask <= 32); if ($valid) { $v4 = $v4 & ((~0) << (32-$mask)); $v4[0] = ($v4 >> 24) & 255; $v4[1] = ($v4 >> 16) & 255; $v4[2] = ($v4 >> 8) & 255; $v4[3] = $v4 & 255; } } else { $mask = 32; } if ($valid) { my $i = 4 - int(($mask+7) / 8); pop(@v4) while ($i--); $ARGV[0] = join('.', reverse(@v4)); $ARGV[0] .= '.' if ($ARGV[0] ne ""); $ARGV[0] .= 'in-addr.arpa'; } } } print "@ARGV\n"; -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 15 16:33:08 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id QAA13372 for ipng-dist; Wed, 15 Oct 1997 16:30:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id QAA13365 for ; Wed, 15 Oct 1997 16:30:13 -0700 (PDT) From: bmanning@ISI.EDU Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA05971 for ; Wed, 15 Oct 1997 16:30:10 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA01409 for ; Wed, 15 Oct 1997 16:30:04 -0700 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29) id ; Wed, 15 Oct 1997 16:30:00 -0700 Posted-Date: Wed, 15 Oct 1997 16:29:41 -0700 (PDT) Message-Id: <199710152329.AA24317@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Wed, 15 Oct 1997 16:29:41 -0700 Subject: (IPng 4680) Re: query re IPv6 URL format To: Francis.Dupont@inria.fr (Francis Dupont) Date: Wed, 15 Oct 1997 16:29:41 -0700 (PDT) Cc: Bertrand.Buclin@ch.att.com, hinden@ipsilon.com, brian@hursley.ibm.com, deering@cisco.com, 6bone@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: <199710151808.UAA05883@givry.inria.fr> from "Francis Dupont" at Oct 15, 97 08:08:07 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk >From another list (dns related no less!) with the names "scrubbed" to protect the innocent. >> I've now updated the patches for allowing named to chroot to also support >> setting the user and group id's with another option: 'runas "user[.group]";'. >> Also, they didn't apply cleanly against 8.1.1. The patches below cover >> both chroot and runas. > >Minor nit: '.' is a valid character for a user name. Perhaps ':' would be >a better delimiter? (It is not a valid user name character...) -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 16 01:38:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id BAA13666 for ipng-dist; Thu, 16 Oct 1997 01:35:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id BAA13659 for ; Thu, 16 Oct 1997 01:35:27 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA17496 for ; Thu, 16 Oct 1997 01:35:26 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA05559 for ; Thu, 16 Oct 1997 01:35:21 -0700 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA105436; Thu, 16 Oct 1997 09:35:17 +0100 Date: Thu, 16 Oct 1997 09:35:17 +0100 Message-Id: <9710160835.AA105436@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 4682) Re: query re IPv6 URL format To: masaki@merit.edu (Masaki Hirabaru) Cc: Francis.Dupont@inria.fr, Bertrand.Buclin@ch.att.com, hinden@ipsilon.com, brian@hursley.ibm.com, deering@cisco.com, 6bone@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: <199710151915.PAA12054@merit.edu> from "Masaki Hirabaru" at Oct 15, 97 03:15:47 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk It doesn't in at least one well known browser - the "escaped" colons get turned into colons before being passed to the resolver. I tried it some time ago. Brian >- Masaki Hirabaru said: > > > 3ffe:306:1051:8300:220:feff:fe00:8781 > 3ffe%3a306%3a1051%3a8300%3a220%3afeff%3afe00%3a8781 > > I think that this should work in url. -- Masaki > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 16 06:02:43 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id FAA13780 for ipng-dist; Thu, 16 Oct 1997 05:56:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id FAA13773 for ; Thu, 16 Oct 1997 05:55:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA12013 for ; Thu, 16 Oct 1997 05:55:22 -0700 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA28597 for ; Thu, 16 Oct 1997 05:55:13 -0700 Received: from fleck.iol.unh.edu by iol.unh.edu (4.1/SMI-4.1) id AA24082; Thu, 16 Oct 97 08:54:45 EDT Received: by fleck.iol.unh.edu (SMI-8.6/SMI-SVR4) id IAA07784; Thu, 16 Oct 1997 08:59:04 -0400 Date: Thu, 16 Oct 1997 08:59:04 -0400 Message-Id: <199710161259.IAA07784@fleck.iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU Subject: (IPng 4683) December test period at IOL X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremy McCooey Sender: owner-ipng@eng.sun.com Precedence: bulk ************** NOTICE **************************** The IP group at the UNH Interoperability Lab will be hosting the 6th IPv6 Group test period in Durham, N.H., at the New England Center Convention Center (Champlain Room) on Dec 1 - 5, 1997. The cost for testing is FREE for members and $1250.00 for non-members. In addition, for the first time there is an additional required charge for food. All food will be catered by the NEC on site, to include meals plus breaks. The cost for the meals is $75.00/day and if you stay at the NEC it will be $175.00/day (this includes your room charges). There are limited rooms available , so book early !! Check our WEB site www.iol.unh.edu for details. We will shortly provide an agenda, however it will be similar to the summer event: interoperability testing. Please use the on-line web form to register. Questions: Mail: whl@unh.edu, jam@iol.unh.edu or for administrative/accomodation questions chc@bigred.sr.unh.edu. We look forward to seeing you all in sunny, but brisk NH !! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 16 09:39:46 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id JAA13915 for ipng-dist; Thu, 16 Oct 1997 09:36:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with ESMTP id JAA13908 for ; Thu, 16 Oct 1997 09:36:46 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA20329 for ; Thu, 16 Oct 1997 09:36:45 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA14063; Thu, 16 Oct 1997 09:34:07 -0700 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id JAA13884 for ; Thu, 16 Oct 1997 09:29:48 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA04099 for ; Thu, 16 Oct 1997 09:29:46 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA26827 for ; Thu, 16 Oct 1997 09:28:27 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA15889 for ; Thu, 16 Oct 1997 09:28:26 -0700 Message-Id: <3.0.3.32.19971016092744.007d4a00@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 16 Oct 1997 09:27:44 -0700 To: ipng@sunroof.eng.sun.com From: Steve Coya (by way of Bob Hinden ) Subject: (IPng 4685) WG Action: IPv6 MIB (ipv6mib) to conclude Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk The IPv6 MIB (ipv6mib) Working Group in the Internet Area of the IETF has concluded. The work of that group is now being handled by the IPNG Working Group. The IESG Contact Persons are Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 16 11:45:04 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id LAA14003 for ipng-dist; Thu, 16 Oct 1997 11:41:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id LAA13996 for ; Thu, 16 Oct 1997 11:40:51 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA11745 for ; Thu, 16 Oct 1997 11:40:27 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA10357 for ; Thu, 16 Oct 1997 11:40:17 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA23606; Thu, 16 Oct 1997 14:39:49 -0400 (EDT) Message-Id: <199710161839.OAA23606@ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 4686) Last Call: Transmission of IPv6 Packets over FDDI Networks to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 16 Oct 1997 14:39:49 -0400 Sender: owner-ipng@eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Transmission of IPv6 Packets over FDDI Networks as a Proposed Standard. This is a replacement for RFC2019, which will be reclassified as Historic. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 30, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-fddi-net-03.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 16 11:56:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id LAA14028 for ipng-dist; Thu, 16 Oct 1997 11:53:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id LAA14021 for ; Thu, 16 Oct 1997 11:53:37 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA15168 for ; Thu, 16 Oct 1997 11:53:33 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA13787 for ; Thu, 16 Oct 1997 11:53:19 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA23886; Thu, 16 Oct 1997 14:52:37 -0400 (EDT) Message-Id: <199710161852.OAA23886@ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 4687) Last Call: Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 16 Oct 1997 14:52:36 -0400 Sender: owner-ipng@eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Transmission of IPv6 Packets over Ethernet Networks as a Proposed Standard. This is a replacement for RFC1972, which will be reclassified as Historic. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 30, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-ethernet-03.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 16 12:22:00 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id MAA14085 for ipng-dist; Thu, 16 Oct 1997 12:19:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id MAA14078 for ; Thu, 16 Oct 1997 12:18:59 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA21844 for ; Thu, 16 Oct 1997 12:18:56 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA21818 for ; Thu, 16 Oct 1997 12:18:48 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA26308; Thu, 16 Oct 1997 14:18:35 -0500 Message-Id: <199710161918.OAA26308@gungnir.fnal.gov> To: iesg@ietf.org Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4688) Re: Last Call: Transmission of IPv6 Packets over FDDI Networks to Proposed Standard In-reply-to: Your message of Thu, 16 Oct 1997 14:39:49 EDT. <199710161839.OAA23606@ietf.org> Date: Thu, 16 Oct 1997 14:18:35 -0500 Sender: owner-ipng@eng.sun.com Precedence: bulk I just spotted one sentence which I forgot to remove between -02 and 03. In section 3, the sentence, "The Frame Code should be in the range 51 to 57 hexadecimal, inclusive, for reasons given in the next section." should be deleted. Whoops, sorry. 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 Fri Oct 17 12:20:44 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id MAA15190 for ipng-dist; Fri, 17 Oct 1997 12:15:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id MAA15183 for ; Fri, 17 Oct 1997 12:15:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA10063 for ; Fri, 17 Oct 1997 12:15:01 -0700 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA21718 for ; Fri, 17 Oct 1997 12:14:31 -0700 Received: from fleck.iol.unh.edu by iol.unh.edu (4.1/SMI-4.1) id AA13011; Fri, 17 Oct 97 15:05:10 EDT Received: by fleck.iol.unh.edu (SMI-8.6/SMI-SVR4) id PAA11003; Fri, 17 Oct 1997 15:09:31 -0400 Date: Fri, 17 Oct 1997 15:09:31 -0400 Message-Id: <199710171909.PAA11003@fleck.iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipv6imp@munnari.oz.au, ipng@sunroof.eng.sun.com Subject: (IPng 4690) UNH test period clarifications X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremy McCooey Sender: owner-ipng@eng.sun.com Precedence: bulk First, before I get flooded with messages, the group test period information/registration is *not* yet online. The basic information will be up by Monday. More detailed information will be online later. If you need particular information and can't wait, you can email me at jam@iol.unh.edu. Regarding the associated costs: The cost of the *testing* is $1250 per company for non-members and is free for members. However, since the testing will be taking place off-site, there is an additional *per-person* charge. This charge covers the expenses associated with the use of the New England Center. For those who are not staying at the NEC, the charge is $75/day and includes lunch, morning and afternoon breaks, and snacks. For those who stay at the NEC, a charge of $175/day covers the above as well as your room, breakfast, and dinner. Also, we moved the discussion of test period details to a private list last time. If you would like to be included on that list, please send me mail (or register). Jeremy -- +---------------------------------+-------------------+ | Jeremy McCooey | jam@iol.unh.edu | | UNH InterOperability Laboratory | 603-862-0090 | | IP/Routing Consortium | | +---------------------------------+-------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 21 23:02:26 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id WAA17912 for ipng-dist; Tue, 21 Oct 1997 22:58:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id WAA17905 for ; Tue, 21 Oct 1997 22:58:45 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA29585 for ; Tue, 21 Oct 1997 22:58:44 -0700 Received: from citytelprct8.citytel.net (citytelprct65.citytel.net [204.244.99.18]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id WAA00091 for ; Tue, 21 Oct 1997 22:58:42 -0700 Received: from localhost ([127.0.0.1]) by citytelprct8.citytel.net with smtp (ident jwalther using rfc1413) id m0xNnLt-000UmlC (Debian Smail-3.2 1996-Jul-4 #2); Tue, 21 Oct 1997 23:04:41 +0000 () Date: Tue, 21 Oct 1997 23:04:40 +0000 ( ) From: Manong Dibos To: ipng@sunroof.eng.sun.com Subject: (IPng 4696) ipng address allocation. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Who will be responsible for allocating the new IPv6 addresses? At the moment, I cant even get a single IPv4 address without paying an exhorbitant sum of money. When can I reserve a few for myself out of the new ones? And what are likely to be the costs? Jonathan Walther http://www.linuxos.org/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 22 07:12:32 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id HAA18088 for ipng-dist; Wed, 22 Oct 1997 07:09:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id HAA18081 for ; Wed, 22 Oct 1997 07:09:36 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA00229 for ; Wed, 22 Oct 1997 07:09:33 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA27807 for ; Wed, 22 Oct 1997 07:09:32 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA07631; Wed, 22 Oct 1997 09:09:13 -0500 Message-Id: <199710221409.JAA07631@gungnir.fnal.gov> To: Manong Dibos Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4697) Re: ipng address allocation. In-reply-to: Your message of Tue, 21 Oct 1997 23:04:40 -0000. Date: Wed, 22 Oct 1997 09:09:13 -0500 Sender: owner-ipng@eng.sun.com Precedence: bulk > Who will be responsible for allocating the new IPv6 addresses? > [...] When can I reserve a few for myself out of the new ones? Anyone who can even ask the question, "Can I get some IPv6 addresses now?" does not understand the goals of the address architecture. When you connect to an IPv6 network, you will get addresses. When you drop that connection and get a different one, you'll get different addresses. Your previous addresses will be valid for, at most, a transitional period. If you want to set up IPv6 now, without a connection to a global IPv6 network such as the 6bone, use link-local and/or site-local addresses. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 26 01:46:58 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id BAA20701 for ipng-dist; Sun, 26 Oct 1997 01:41:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id BAA20694 for ; Sun, 26 Oct 1997 01:41:22 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA19963 for ; Sun, 26 Oct 1997 01:41:21 -0800 Received: from wentzl.cdg.chalmers.se (wentzl.cdg.chalmers.se [129.16.12.9]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA24002 for ; Sun, 26 Oct 1997 01:41:21 -0800 Received: from rubner.cdg.chalmers.se (d1306.sth.pi.se [195.7.71.210]) by wentzl.cdg.chalmers.se (8.8.7/8.8.5) with SMTP id KAA27892; Sun, 26 Oct 1997 10:41:16 +0100 (MET) Date: Sun, 26 Oct 1997 10:41:16 +0100 (MET) From: Gunnar Lindberg Message-Id: <199710260941.KAA27892@wentzl.cdg.chalmers.se> Received: by rubner.cdg.chalmers.se (5.60+IDA/3.14+gl) id AA00283; Sun, 26 Oct 97 10:40:58 +0100 To: ipng@sunroof.eng.sun.com Subject: (IPng 4702) TLA, NLA & SLA in practice Cc: ipv6@chalmers.se X-Mailer: UCB Mail 5.3.5 95-03-10 (MIME) Sender: owner-ipng@eng.sun.com Precedence: bulk Could someone please help me put my university into the hierarchy assumed in draft-ietf-ipngwg* and perhpas fill in missing pieces. >====================================================================== >draft-ietf-ipngwg-addr-arch-v2-02.txt > >2.5.7 Aggregatable Global Unicast Addresses > ... > The IPv6 aggregatable global unicast address format is as follows: > > | 3 | 13 | 32 | 16 | 64 bits | > +---+-----+-----------+--------+--------------------------------+ > |FP | TLA | NLA ID | SLA ID | Interface ID | > | | ID | | | | > +---+-----+-----------+--------+--------------------------------+ >====================================================================== >====================================================================== >draft-ietf-ipngwg-tla-assignment-00.txt > >3.0 Rules for Assignment of Top-Level Aggregation ID's > ... > Registries are required to insure that organizations assigned TLA > ID's meet the following requirements: > > - Must have a plan to offer public native IPv6 service within 6 > months from assignment. The plan must include plan for NLA ID > allocation. >====================================================================== Our hierarchy, in organization and roughly in networks: NORDU.net SUNET.se Chalmers.se Chalmers' local subnets (~110 LANs) NORDU.net is our connection to the global Internet (though there are some optimizations); all Nordic countries' Universities reach Internet this way. NORDU.net uses its own Layer2 links to its 5 members (Nordic University Networks). My view is that NORDU.net is an ISP, small and with a non-public Policy. SUNET.se uses its own Layer2 links to interconnect Universities (and some strictly defined exceptions) and connects that group to other Swedish ISPs and Internet/NORDU.net. My view is that SUNET.se is an ISP, but it does have a policy that only Universities and some exceptions may connect; SUNET.se is not a Public ISP. All in all SUNET.se has 40-50 "customers" connected. So, could someone please help me find where Chalmers.se fits in and who seems the most reasonably party for an TLA, NLA and SLA in this hierarchy/model. Many thanks in advance, Gunnar Lindberg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 27 05:59:53 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id FAA21388 for ipng-dist; Mon, 27 Oct 1997 05:57:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id FAA21381 for ; Mon, 27 Oct 1997 05:57:00 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA17543 for ; Mon, 27 Oct 1997 05:56:58 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA04907 for ; Mon, 27 Oct 1997 05:57:02 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA35978; Mon, 27 Oct 1997 13:56:49 GMT Date: Mon, 27 Oct 1997 13:56:49 GMT Message-Id: <9710271356.AA35978@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 4705) draft-ietf-ipngwg-addr-arch-v2-03.txt To: ipng@sunroof.eng.sun.com Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk Just some minor points on draft-ietf-ipngwg-addr-arch-v2-03.txt 1. Given the difficulty we have in persuading the URL and SMTP folks to do the right thing with the textual representation, I suggest including a BNF syntax version as an annex. A rough cut is annexed to this email. 2. I know why we say > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. but is this really going to be tenable? It certainly isn't enforceable. 3. For the record: I know I lost this one, but I still think it is wrong to invert the universal/local bit in EUI-64. Brian Carpenter In the variant of BNF used for URL syntax: IPv6address = hexpart [ ":" IPv4address ] IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*hex hex = digit | "A" | "a" | "B" digit = "1" | "2" | "3" -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 27 09:01:31 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id IAA21546 for ipng-dist; Mon, 27 Oct 1997 08:58:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with ESMTP id IAA21539 for ; Mon, 27 Oct 1997 08:57:58 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id IAA08802 for ; Mon, 27 Oct 1997 08:57:58 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08890; Mon, 27 Oct 1997 08:55:14 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id LAA20053 for ; Fri, 24 Oct 1997 11:05:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA13577 for ; Fri, 24 Oct 1997 11:05:12 -0700 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA04156 for ; Fri, 24 Oct 1997 11:05:06 -0700 Received: from raisin-bran.ai.mit.edu (raisin-bran.ai.mit.edu [128.52.37.84]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id OAA10107 for ; Fri, 24 Oct 1997 14:04:58 -0400 (EDT) Received: (from dina@localhost) by raisin-bran.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id OAA03989; Fri, 24 Oct 1997 14:04:57 -0400 (EDT) Date: Fri, 24 Oct 1997 14:04:56 -0400 (EDT) From: dina katabi To: ipng@sunroof.eng.sun.com Subject: (IPng 4706) Anycast Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Hello, I am looking for detailed information about Anycast (Address allocation, routing, possible applications ..) I am also interested to know what was the final agreement regarding cluster addresses and what is exactly the problem with them and where can I find some info about the " Pack proposal". I will be very thankful if someone points out some papers, online discussions, or any related information. Thank you, Dina Katabi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 27 09:08:49 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id JAA21600 for ipng-dist; Mon, 27 Oct 1997 09:06:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with ESMTP id JAA21593 for ; Mon, 27 Oct 1997 09:05:57 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id JAA09866 for ; Mon, 27 Oct 1997 09:05:57 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08928; Mon, 27 Oct 1997 09:03:12 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) with SMTP id LAA20541 for ; Sat, 25 Oct 1997 11:35:02 -0700 (PDT) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA23058 for ; Sat, 25 Oct 1997 11:34:59 -0700 Received: from inforamp.net (InfoRamp.net [204.191.136.8]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA15612 for ; Sat, 25 Oct 1997 11:35:00 -0700 Received: from greg [204.191.150.178] by inforamp.net with esmtp (Exim 1.70 #1) id 0xPB3e-0002ow-00; Sat, 25 Oct 1997 14:35:34 -0400 From: "Greg Cooper" To: Subject: (IPng 4707) FTP protocol Date: Sat, 25 Oct 1997 14:31:31 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-ipng@eng.sun.com Precedence: bulk This probably isn't the correct place to send this request but it was the best place I could find in a quick search of the Internet. I would like to propose that one simple extension be made to the File Transfer Protocol. The objective is to allow users to resume FTP downloads which have been interrupted because their connection has been terminated for some reason. My proposal is to add two client commands to the current protocol. The first one, ftpver, would return information about the version of the FTP version. It could be used for other purposes but my reason for suggesting it is so that FTP clients can determine if an FTP server supports the following command. It is assumed that existing FTP server software will not "choke" on this command but will simpy return an error message, which will indicate to the client that it supports a version that precedes the introduction of this command. The second client command would be getfrom, which would include not only a file identifier but also a file position, returning the data in the file from that position to the end of the file. Together, these new commands would allow FTP server software developers and FTP client software developers to independently upgrade their products. Over time, most Internet users could use the FTP protocol without fear of losing the connection after 95% of the file is downloaded. Thank you, Greg Cooper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 27 09:23:03 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id JAA21691 for ipng-dist; Mon, 27 Oct 1997 09:19:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with ESMTP id JAA21680 for ; Mon, 27 Oct 1997 09:17:52 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id JAA11134 for ; Mon, 27 Oct 1997 09:17:12 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09037; Mon, 27 Oct 1997 09:14:07 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id AAA21248 for ; Mon, 27 Oct 1997 00:35:58 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA23744 for ; Mon, 27 Oct 1997 00:35:56 -0800 Received: from dxcnaf.cnaf.infn.it (dxcnaf.cnaf.infn.it [131.154.3.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA09422 for ; Mon, 27 Oct 1997 00:35:57 -0800 Received: from localhost (chierici@localhost) by dxcnaf.cnaf.infn.it (8.8.5/8.8.5) with SMTP id JAA11988 for ; Mon, 27 Oct 1997 09:35:49 +0100 (MET) Date: Mon, 27 Oct 1997 09:35:49 +0100 (MET) From: Andrea Chierici To: ipng@sunroof.eng.sun.com Subject: (IPng 4708) IPv4 compatibility (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Sorry to repost this, but for strange reason I was unsubscribed from the list and could not get the answers (if there were any) to this mail... Could someone repost them or send me privately? TIA, Andrea ----------------------------------------- Andrea Chierici, Computer Science Student INFN-CNAF Bologna ITALY ----------------------------------------- ---------- Forwarded message ---------- Date: Tue, 14 OCT 97 15:11:38 +0000 From: andrea.chierici@cnaf.infn.it To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 4672) IPv4 compatibility Hi, I would like to know something more about the IP4v compatibility of ipng. When an IPv6 only machine whishes to comunicate with an IPv4 only machine for example, we have to use the IPv4-mapped address... well I think that the translation of the address into a pure ipv4 address will be done by the last hop router, the one next to the ipv4 only machine, am I right? And i think that the router will convert all the ipv6 packets into Ipv4 too. Will this create a lack of performances?? Can anyone point me to a document that explains this issue in detail? Thanks, Andrea ----------------------------------------- Andrea Chierici, Computer Science Student INFN-CNAF Bologna ITALY ----------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 27 10:46:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id KAA21825 for ipng-dist; Mon, 27 Oct 1997 10:43:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id KAA21815 for ; Mon, 27 Oct 1997 10:43:10 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA04815 for ; Mon, 27 Oct 1997 10:43:08 -0800 Received: from frantic.BSDI.COM (frantic.BSDI.COM [205.230.227.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA29713 for ; Mon, 27 Oct 1997 10:43:05 -0800 Received: (from dab@localhost) by frantic.BSDI.COM (8.8.5/8.8.5) id MAA29289; Mon, 27 Oct 1997 12:43:12 -0600 (CST) Date: Mon, 27 Oct 1997 12:43:12 -0600 (CST) From: David Borman Message-Id: <199710271843.MAA29289@frantic.BSDI.COM> To: ipng@sunroof.eng.sun.com, pxl@inforamp.net Subject: (IPng 4709) Re: FTP protocol Sender: owner-ipng@eng.sun.com Precedence: bulk Greg, > I would like to propose that one simple extension be made to the File > Transfer Protocol. The objective is to allow users to resume FTP downloads > which have been interrupted because their connection has been terminated > for some reason. 1) FTP already supports this, via the RESTART (RST) command. Most BSD based implementation of FTP support this, with the reget/restart commands. 2) There is an ftp extensions working group, ftp-wg@hethmon.com -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 27 12:01:47 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id LAA21896 for ipng-dist; Mon, 27 Oct 1997 11:58:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with ESMTP id LAA21889 for ; Mon, 27 Oct 1997 11:58:48 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id LAA18740 for ; Mon, 27 Oct 1997 11:58:47 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09347; Mon, 27 Oct 1997 11:56:02 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id LAA21874 for ; Mon, 27 Oct 1997 11:54:56 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA25949 for ; Mon, 27 Oct 1997 11:54:54 -0800 Received: from mail1.eni.net (mail1.eni.net [205.214.51.15]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA05624 for ; Mon, 27 Oct 1997 11:54:49 -0800 Received: from housel-1234.nb.rockwell.com ([129.172.195.14]) by mail1.eni.net (8.8.5/8.8.5) with SMTP id LAA23962 for ; Mon, 27 Oct 1997 11:55:19 -0800 (PST) Reply-To: "Peter Housel" From: "Peter Housel" To: Subject: (IPng 4711) Re: IPv4 compatibility (fwd) Date: Mon, 27 Oct 1997 11:54:07 -0800 Message-ID: <01bce312$163accc0$0ec3ac81@housel-1234.nb.rockwell.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@eng.sun.com Precedence: bulk >When an IPv6 only machine whishes to comunicate with an IPv4 only machine >for example, we have to use the IPv4-mapped address... well I think that >the translation of the address into a pure ipv4 address will be done by >the last hop router, the one next to the ipv4 only machine, am I right? >And i think that the router will convert all the ipv6 packets into Ipv4 >too. Will this create a lack of performances?? >Can anyone point me to a document that explains this issue in detail? As I read the standards, IPv6-only devices can't communicate with IPv4-only machines at all. If a dual-stack device wants to communicate with an IPv4 device anywhere in the network, it has to use its IPv4 stack, and the transmitted packet uses IPv4 format and IPv4 routing from beginning to end. No format translation happens anywhere in the network. Given this, I can't figure out what IPv4-mapped addresses are for, other than for using IPv6 data structures to represent IPv4 addresses. Is this correct? -Peter S. Housel- housel@acm.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 27 13:00:07 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id MAA21983 for ipng-dist; Mon, 27 Oct 1997 12:57:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with ESMTP id MAA21976 for ; Mon, 27 Oct 1997 12:57:09 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id MAA25305 for ; Mon, 27 Oct 1997 12:57:08 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09396; Mon, 27 Oct 1997 12:54:24 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id MAA21964 for ; Mon, 27 Oct 1997 12:52:17 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA08460 for ; Mon, 27 Oct 1997 12:52:15 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA17334 for ; Mon, 27 Oct 1997 12:51:48 -0800 Received: (from peter@localhost) by gate.ticl.co.uk (8.8.5/8.8.5) id UAA20889; Mon, 27 Oct 1997 20:49:45 GMT From: Peter Curran Message-Id: <199710272049.UAA20889@gate.ticl.co.uk> Subject: (IPng 4713) Re: IPv4 compatibility (fwd) In-Reply-To: <01bce312$163accc0$0ec3ac81@housel-1234.nb.rockwell.com> from Peter Housel at "Oct 27, 97 11:54:07 am" To: housel@acm.org Date: Mon, 27 Oct 1997 20:49:45 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk > As I read the standards, IPv6-only devices can't communicate with IPv4-only > machines at all. If a dual-stack device wants to communicate with an IPv4 > device anywhere in the network, it has to use its IPv4 stack, and the > transmitted packet uses IPv4 format and IPv4 routing from beginning to end. > No format translation happens anywhere in the network. > > Given this, I can't figure out what IPv4-mapped addresses are for, other > than for using IPv6 data structures to represent IPv4 addresses. Is this > correct? > This is correct. It is also used to indicate to an application that is dual-stacked that it should use the IPv4 stack to communicate with a host. Arguably, the inherent strength of the dual-stack approach is that it is the applications that define which stack is used. For this reason, you need some way of hinting to the application what is appropriate. By default a dual-stacked application will always try and use IPv6. (If this is wrong then the default can be changed to IPv4 via the BIND mapIPv6 option). Peter Curran TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 27 15:20:13 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id PAA22148 for ipng-dist; Mon, 27 Oct 1997 15:17:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with ESMTP id PAA22141 for ; Mon, 27 Oct 1997 15:17:06 -0800 (PST) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id PAA22055; Mon, 27 Oct 1997 15:17:04 -0800 (PST) Date: Mon, 27 Oct 1997 15:15:45 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4715) Re: IPv4 compatibility (fwd) To: Peter Housel Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <01bce312$163accc0$0ec3ac81@housel-1234.nb.rockwell.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk > As I read the standards, IPv6-only devices can't communicate with IPv4-only > machines at all. If a dual-stack device wants to communicate with an IPv4 > device anywhere in the network, it has to use its IPv4 stack, and the > transmitted packet uses IPv4 format and IPv4 routing from beginning to end. > No format translation happens anywhere in the network. Correct. The killer constraint is that a device needs an address that can be represented as a unique IPv4 address in order to communicate with IPv4-only nodes. > Given this, I can't figure out what IPv4-mapped addresses are for, other > than for using IPv6 data structures to represent IPv4 addresses. Is this > correct? Yes. The only currently described use of IPv4-mapped addresses is for application programming convinience. An application can use the same data structure to represent IPv6 addresses and IPv4 addresses. However, the mapped address mechanism is general to allow future extensions to the set of transition mechanisms such as the mythical IPv4/IPv6 stateless header translators. But the key thing that is needed in my opinion is a mechanism for the dual host (which does not have a permanently assigned IPv4 address) to be able to allocate an IPv4 address when it needs to communicate with an IPv4-only peer. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 27 18:36:48 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id SAA22631 for ipng-dist; Mon, 27 Oct 1997 18:34:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id SAA22624 for ; Mon, 27 Oct 1997 18:33:56 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA29201 for ; Mon, 27 Oct 1997 18:33:53 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA03250 for ; Mon, 27 Oct 1997 13:37:50 -0800 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id QAA26575; Mon, 27 Oct 1997 16:30:20 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA05823; Mon, 27 Oct 1997 16:30:19 -0500 Message-Id: <9710272130.AA05823@wasted.zk3.dec.com> To: "Peter Housel" Cc: Subject: (IPng 4716) Re: IPv4 compatibility (fwd) In-Reply-To: Your message of "Mon, 27 Oct 1997 11:54:07 -0800." <01bce312$163accc0$0ec3ac81@housel-1234.nb.rockwell.com> Date: Mon, 27 Oct 1997 16:30:18 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk >Given this, I can't figure out what IPv4-mapped addresses are for, other >than for using IPv6 data structures to represent IPv4 addresses. Is this >correct? This is correct. It also permits building a "hybrid" stack instead of a dual stack per IPv4 addresses. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 27 22:16:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id WAA22894 for ipng-dist; Mon, 27 Oct 1997 22:13:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id WAA22887 for ; Mon, 27 Oct 1997 22:13:41 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA03765; Mon, 27 Oct 1997 22:13:40 -0800 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id WAA16313; Mon, 27 Oct 1997 22:13:34 -0800 Received: from sanam.india.hp.com (sanam.india.hp.com [15.10.43.113]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id WAA14092; Mon, 27 Oct 1997 22:13:15 -0800 (PST) Message-Id: <199710280613.WAA14092@palrel1.hp.com> Received: by sanam.india.hp.com (1.39.111.2/16.2) id AA240959857; Tue, 28 Oct 1997 11:54:17 +0530 From: Rajesh "Kumar." L Subject: (IPng 4718) Re: IPv4 compatibility (fwd) To: Erik.Nordmark@Eng Date: Tue, 28 Oct 1997 11:54:17 +0530 (IST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from Erik Nordmark at Oct "27," 1997 "03:15:45" pm X-Mailer: ELM [Revision: 213.1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk > > > As I read the standards, IPv6-only devices can't communicate with IPv4-only > > machines at all. If a dual-stack device wants to communicate with an IPv4 > > device anywhere in the network, it has to use its IPv4 stack, and the > > transmitted packet uses IPv4 format and IPv4 routing from beginning to end. > > No format translation happens anywhere in the network. But this is not what RFC2133 says. Here is a snippet from the RFC. ***** Applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect() or sendto() call. When applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way. Few applications will likely need to know which type of node they are interoperating with. However, for those applications that do need to know, the IN6_IS_ADDR_V4MAPPED() macro is provided. ***** I was thinking that IPv6 machines when communicating to IPv4 machines will use the IPv4-mapped IPv6 address and the destination will receive the IPv4 adress of the IPv6 source as its source address. The sockets API should map the IPv4 address of a source to its IPv6 style address, when the IPv6 server "accept()" from a IPv4 client. Similiarly, when an IPv4 server "accept" from an IPv6 client, it should get the IPv4 address of the IPv6 client. There are some doubts i have regarding binding to in6addr_any. Will it be able to "accept" from a IPv4 client as well as an IPv6 client? If it cannot handle IPv4 clents, there should be seperate IPv4 and IPv6 servers in all the machines for all applications (DNS,ftp,telnet etc). > > Correct. > The killer constraint is that a device needs an address that can be > represented as a unique IPv4 address in order to communicate with > IPv4-only nodes. > > > Given this, I can't figure out what IPv4-mapped addresses are for, other > > than for using IPv6 data structures to represent IPv4 addresses. Is this > > correct? > > Yes. The only currently described use of IPv4-mapped addresses > is for application programming convinience. An application can use the > same data structure to represent IPv6 addresses and IPv4 addresses. > > However, the mapped address mechanism is general to allow future extensions > to the set of transition mechanisms such as the mythical IPv4/IPv6 stateless > header translators. > > But the key thing that is needed in my opinion is a mechanism > for the dual host (which does not have a permanently assigned IPv4 > address) to be able to allocate an IPv4 address when it needs to > communicate with an IPv4-only peer. > > 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 > -------------------------------------------------------------------- > Rajesh. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 28 01:22:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id BAA23070 for ipng-dist; Tue, 28 Oct 1997 01:19:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id BAA23063 for ; Tue, 28 Oct 1997 01:19:47 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA22542 for ; Tue, 28 Oct 1997 01:19:46 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA20310 for ; Tue, 28 Oct 1997 01:19:45 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA39101; Tue, 28 Oct 1997 09:19:34 GMT Date: Tue, 28 Oct 1997 09:19:34 GMT Message-Id: <9710280919.AA39101@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 4719) Re: draft-ietf-ipngwg-addr-arch-v2-03.txt To: ipng@sunroof.eng.sun.com In-Reply-To: <9710280130.AA13800@hursley.ibm.com> from "Roger Fajman" at Oct 27, 97 08:28:00 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk I agree - I used the notation from the URL syntax draft but it would be better to use ABNF, if people like the basic idea. Thanks Brian >- Roger Fajman said: > > > In the variant of BNF used for URL syntax: > > I suggest using the ABNF definition that the Drums WG is almost done with. > There's an I-D by Dave Crocker under the Drums WG. > > > IPv6address = hexpart [ ":" IPv4address ] > > IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit > > Wouldn't 1*3digit be better? > > > hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] > > hexseq = hex4 *( ":" hex4) > > hex4 = 1*hex > > Wouldn't 1*4hex be better? > > > hex = digit | "A" | "a" | "B" > > digit = "1" | "2" | "3" > > These two are defined in the draft. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 28 04:29:53 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id EAA23173 for ipng-dist; Tue, 28 Oct 1997 04:27:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id EAA23166 for ; Tue, 28 Oct 1997 04:27:04 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA05347; Tue, 28 Oct 1997 04:27:01 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA27256; Tue, 28 Oct 1997 04:26:59 -0800 Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id HAA12446; Tue, 28 Oct 1997 07:21:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA20469; Tue, 28 Oct 1997 07:21:35 -0500 Message-Id: <9710281221.AA20469@wasted.zk3.dec.com> To: Erik Nordmark Cc: Peter Housel , ipng@sunroof.eng.sun.com Subject: (IPng 4720) Re: IPv4 compatibility (fwd) In-Reply-To: Your message of "Mon, 27 Oct 1997 15:15:45 -0800." Date: Tue, 28 Oct 1997 07:21:35 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk >But the key thing that is needed in my opinion is a mechanism >for the dual host (which does not have a permanently assigned IPv4 >address) to be able to allocate an IPv4 address when it needs to >communicate with an IPv4-only peer. I will have a draft for you and I to review by end of next week or early the following week given no gremilins steal my time then we can publish before IETF deadline and discuss at ngtrans at wash d.c. I have figured out the dns/dhcpv6 issues which was up in the air. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 28 06:04:52 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id GAA23218 for ipng-dist; Tue, 28 Oct 1997 06:02:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id GAA23211 for ; Tue, 28 Oct 1997 06:01:55 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA13968; Tue, 28 Oct 1997 06:01:51 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA19783; Tue, 28 Oct 1997 06:01:41 -0800 Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA29169; Tue, 28 Oct 1997 08:21:38 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22632; Tue, 28 Oct 1997 08:21:36 -0500 Message-Id: <9710281321.AA22632@wasted.zk3.dec.com> To: Rajesh "Kumar." L Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com Subject: (IPng 4721) Re: IPv4 compatibility (fwd) In-Reply-To: Your message of "Tue, 28 Oct 1997 11:54:17 +0530." <199710280613.WAA14092@palrel1.hp.com> Date: Tue, 28 Oct 1997 08:21:36 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk > I was thinking that IPv6 machines when communicating to IPv4 machines will > use the IPv4-mapped IPv6 address and the destination will receive the IPv4 > adress of the IPv6 source as its source address. The sockets API should > map the IPv4 address of a source to its IPv6 style address, when the IPv6 > server "accept()" from a IPv4 client. Similiarly, when an IPv4 server > "accept" from an IPv6 client, it should get the IPv4 address of the IPv6 > client. > There are some doubts i have regarding binding to in6addr_any. Will it be > able to "accept" from a IPv4 client as well as an IPv6 client? If it cannot > handle IPv4 clents, there should be seperate IPv4 and IPv6 servers in all > the machines for all applications (DNS,ftp,telnet etc). As long as an implementation treats all IPv4 addresses as IPv4-mapped above the network layer (e.g. inpcb struct) then it works fine and does not require different servers. The only reason for this is if the server app has not been ported to be v4/v6 aware. Once that is done you only need one server app. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 28 06:49:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id GAA23310 for ipng-dist; Tue, 28 Oct 1997 06:46:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id GAA23303 for ; Tue, 28 Oct 1997 06:46:07 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA22668 for ; Tue, 28 Oct 1997 06:46:00 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA02327 for ; Tue, 28 Oct 1997 06:45:52 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA24848; Tue, 28 Oct 1997 09:45:42 -0500 (EST) Message-Id: <199710281445.JAA24848@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4722) I-D ACTION:draft-ietf-ipngwg-icmp-v2-00.txt Date: Tue, 28 Oct 1997 09:45:42 -0500 Sender: owner-ipng@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 : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v2-00.txt Pages : 20 Date : 27-Oct-97 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-icmp-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-v2-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971027124357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971027124357.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 28 06:50:21 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id GAA23319 for ipng-dist; Tue, 28 Oct 1997 06:47:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id GAA23312 for ; Tue, 28 Oct 1997 06:46:58 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA23001 for ; Tue, 28 Oct 1997 06:46:54 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA02279 for ; Tue, 28 Oct 1997 06:45:44 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA24829; Tue, 28 Oct 1997 09:45:35 -0500 (EST) Message-Id: <199710281445.JAA24829@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4723) I-D ACTION:draft-ietf-ipngwg-trans-tokenring-03.txt Date: Tue, 28 Oct 1997 09:45:35 -0500 Sender: owner-ipng@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 : Transmission of IPv6 Packets over Token Ring Networks Author(s) : T. Narten, M. Crawford, S. Thomas Filename : draft-ietf-ipngwg-trans-tokenring-03.txt Pages : 10 Date : 27-Oct-97 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-trans-tokenring-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-tokenring-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-03.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971027123400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-tokenring-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971027123400.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 28 10:39:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id KAA23740 for ipng-dist; Tue, 28 Oct 1997 10:35:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id KAA23733 for ; Tue, 28 Oct 1997 10:35:18 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA00805 for ; Tue, 28 Oct 1997 10:35:12 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA25122 for ; Tue, 28 Oct 1997 10:35:08 -0800 Received: from [128.3.9.22] by cnrmail.lbl.gov with ESMTP (Eudora Internet Mail Server 1.2); Tue, 28 Oct 1997 10:35:01 -0800 X-Sender: rlfink@cnrmail.lbl.gov Message-Id: In-Reply-To: <199710260941.KAA27892@wentzl.cdg.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 28 Oct 1997 10:34:59 -0800 To: Gunnar Lindberg From: Bob Fink Subject: (IPng 4724) Re: TLA, NLA & SLA in practice Cc: ipng@sunroof.eng.sun.com, ipv6@chalmers.se Sender: owner-ipng@eng.sun.com Precedence: bulk Gunnar, At 1:41 AM -0800 10/26/97, Gunnar Lindberg wrote: >Could someone please help me put my university into the hierarchy >assumed in draft-ietf-ipngwg* and perhpas fill in missing pieces. I'll try :-) >>====================================================================== >>draft-ietf-ipngwg-addr-arch-v2-02.txt >> >>2.5.7 Aggregatable Global Unicast Addresses >> ... >> The IPv6 aggregatable global unicast address format is as follows: >> >> | 3 | 13 | 32 | 16 | 64 bits | >> +---+-----+-----------+--------+--------------------------------+ >> |FP | TLA | NLA ID | SLA ID | Interface ID | >> | | ID | | | | >> +---+-----+-----------+--------+--------------------------------+ >>====================================================================== > >>====================================================================== >>draft-ietf-ipngwg-tla-assignment-00.txt >> >>3.0 Rules for Assignment of Top-Level Aggregation ID's >> ... >> Registries are required to insure that organizations assigned TLA >> ID's meet the following requirements: >> >> - Must have a plan to offer public native IPv6 service within 6 >> months from assignment. The plan must include plan for NLA ID >> allocation. >>====================================================================== > >Our hierarchy, in organization and roughly in networks: > > NORDU.net > SUNET.se > Chalmers.se > Chalmers' local subnets (~110 LANs) > >NORDU.net is our connection to the global Internet (though there are >some optimizations); all Nordic countries' Universities reach Internet >this way. NORDU.net uses its own Layer2 links to its 5 members (Nordic >University Networks). My view is that NORDU.net is an ISP, small and >with a non-public Policy. > >SUNET.se uses its own Layer2 links to interconnect Universities (and >some strictly defined exceptions) and connects that group to other >Swedish ISPs and Internet/NORDU.net. > >My view is that SUNET.se is an ISP, but it does have a policy that >only Universities and some exceptions may connect; SUNET.se is not >a Public ISP. All in all SUNET.se has 40-50 "customers" connected. > >So, could someone please help me find where Chalmers.se fits in and >who seems the most reasonably party for an TLA, NLA and SLA in this >hierarchy/model. Many thanks in advance, If the IANA was actually handing out AGGR based IPv6 addresses for real (rather than just for the 6bone), and all the ISPs you use supported native IPv6 transport, then I would assume NORDU.NET was a big enough player to justify being assigned a TLA. [Some might argue that NORDU.NET isn't a "public native service" and that it should get it's IPv6 attachment and routing from some larger entity that is, but I will ignore that interpretation for now as TLA rules are being prepared for a larger discussion than this one.] So, NORDU.NET would get a TLA (say 01AB hex for discussion), thus its routing prefix is 21AB::/16. Then NORDU.NET might assign the first 16-bits of NLA space as the first level transit aggregation under NORDU.NET. So in this model SUNET.SE might get 0001 hex (0000 hex would be reserved for NORDU.NET to assign leaf sites directly attached to them). Thus SUNET.SE would have a routing prefix of 21AB:0001::/32. Then SUNET.SE might assign all remaining 16 bits of space in the NLA field for leaf sites, e.g., CHALMERS.SE might get 0017 hex (and as NORDU.NET did above them, SUNET.SE would reserve 0000 hex for SUNET.SE directly attached leaf sites). Thus CHALMERS.SE would have a routing prefix of 21AB:0001:0017::/48. Finally, your Chalmer's local subnet would be assigned out of the SLA space. If your own subnet was 5th out of your ~110 subnets it might be 0004 hex, thus giving your local subnet a routing prefix of 21AB:0001:0017:0004::/64. This would, in theory given the use of EUI-64 Interface IDs, be the longest routing prefix your on-site routers would have to cache and route on. Obviously if the definition of TLAs eventually defines a network like NORDU.NET as too far down the food chain to qualify for a TLA, then it would have to get an NLA assignment from a qualified TLA (or Exchange). However, all this is far from resolution as revised TLA specs haven't really been released for broader discussion yet...but expect it will be soon. Now, if you want a 6bone IPv6 address, then you have to either become a pTLA, convince NORDU.NET or SUNET.SE to become one, or find an existing one, e.g., ERA (Ericsson Radio Systems) to handle your tunnel. But the concepts are all the same re AGGR type addresses. Hope this helps, or at least opens a floodgate of useful discourse on this. Regards, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 28 19:04:02 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id TAA24571 for ipng-dist; Tue, 28 Oct 1997 19:01:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id TAA24564 for ; Tue, 28 Oct 1997 19:00:58 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA10971 for ; Tue, 28 Oct 1997 19:00:52 -0800 Received: from TYO39.gate.nec.co.jp (TYO39.gate.nec.co.jp [202.247.7.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA17614 for ; Tue, 28 Oct 1997 19:00:53 -0800 Received: from mailsv.nec.co.jp ([133.200.254.203]) by TYO39.gate.nec.co.jp (8.8.7+2.7Wbeta6/3.6Wbeta697090413) with ESMTP id MAA04047 for ; Wed, 29 Oct 1997 12:00:48 +0900 (JST) Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.2.2]) by mailsv.nec.co.jp (8.8.7+2.7Wbeta6/3.6Wbeta6-97092610) with ESMTP id LAA21831 for ; Wed, 29 Oct 1997 11:59:31 +0900 (JST) Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.8.5+2.7Wbeta4/3.3W9-GW_CCS) with ESMTP id LAA10052 for ; Wed, 29 Oct 1997 11:59:29 +0900 (JST) Received: from ccse4 by mail.ccs.mt.nec.co.jp (8.8.5+2.7Wbeta4/6.4J.6-ccs_mx) id LAA08169; Wed, 29 Oct 1997 11:59:29 +0900 (JST) Date: Wed, 29 Oct 1997 11:59:29 +0900 (JST) Message-Id: <199710290259.LAA08169@mail.ccs.mt.nec.co.jp> From: Takuya Murakami To: ipng@sunroof.eng.sun.com Subject: (IPng 4727) original packet? MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.23 Sender: owner-ipng@eng.sun.com Precedence: bulk I have some question about ICMP. Consider following situation. 1. Node A sends fragmented UDP packet to node B. 2. Node B reassemble the UDP packet. 3. Node B check the port number, and the check fails. 4. Node B returns a ICMP port unreach to node A. ICMP port unreach contains "invoking packet". My question is what is the precise definition of this. a. Reassembled UDP packet. b. Fragmented packet which fragment offset is 0. c. Recently received fragmented packet. Which is correct? ----- Takuya Murakami tmurakam@ccs.mt.nec.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 29 13:15:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id NAA25350 for ipng-dist; Wed, 29 Oct 1997 13:11:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id NAA25343 for ; Wed, 29 Oct 1997 13:11:22 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA22124 for ; Wed, 29 Oct 1997 13:11:18 -0800 Received: from snoopy.lucentmmit.com ([38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA29928 for ; Wed, 29 Oct 1997 13:11:08 -0800 Received: by smtp.Lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 29 Oct 1997 16:17:00 -0500 Message-ID: From: "Conta, Alex" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 4729) RE: original packet? Date: Wed, 29 Oct 1997 16:16:58 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@eng.sun.com Precedence: bulk "Unreachable Port" is an ICMP message from the receiving UDP to the sender UDP. So the answer is: a. reassembled UDP packet The ICMP message is generated at the request of the receiving UDP layer which fails to find the received packet's destination port among the local UDP ports - the ICMP error generator module is called with the UDP datagram as a parameter. The receiver of the ICMP message passes a message notification (and the message) up to the original packet's UDP sender. Alex ----------------- I have some question about ICMP. Consider following situation. 1. Node A sends fragmented UDP packet to node B. 2. Node B reassemble the UDP packet. 3. Node B check the port number, and the check fails. 4. Node B returns a ICMP port unreach to node A. ICMP port unreach contains "invoking packet". My question is what is the precise definition of this. a. Reassembled UDP packet. b. Fragmented packet which fragment offset is 0. c. Recently received fragmented packet. Which is correct? ----- Takuya Murakami tmurakam@ccs.mt.nec.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 29 18:43:10 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id SAA25861 for ipng-dist; Wed, 29 Oct 1997 18:40:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id SAA25854 for ; Wed, 29 Oct 1997 18:40:15 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA20360 for ; Wed, 29 Oct 1997 18:40:11 -0800 Received: from TYO9.gate.nec.co.jp (TYO9.gate.nec.co.jp [203.180.98.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA02054 for ; Wed, 29 Oct 1997 18:37:37 -0800 Received: from mailsv.nec.co.jp ([133.200.254.203]) by TYO9.gate.nec.co.jp (8.8.7+2.7Wbeta6/3.6Wbeta697082713) with ESMTP id LAA06029; Thu, 30 Oct 1997 11:37:07 +0900 (JST) Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.2.2]) by mailsv.nec.co.jp (8.8.7+2.7Wbeta6/3.6Wbeta6-97092610) with ESMTP id LAA12394; Thu, 30 Oct 1997 11:36:59 +0900 (JST) Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.8.5+2.7Wbeta4/3.3W9-GW_CCS) with ESMTP id LAA22056; Thu, 30 Oct 1997 11:36:58 +0900 (JST) Received: from ccse4 by mail.ccs.mt.nec.co.jp (8.8.5+2.7Wbeta4/6.4J.6-ccs_mx) id LAA22679; Thu, 30 Oct 1997 11:36:57 +0900 (JST) Date: Thu, 30 Oct 1997 11:36:57 +0900 (JST) Message-Id: <199710300236.LAA22679@mail.ccs.mt.nec.co.jp> From: Takuya Murakami To: AConta@Lucent.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4730) Re: original packet? In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.23 Sender: owner-ipng@eng.sun.com Precedence: bulk > "Unreachable Port" is an ICMP message from the receiving UDP to the > sender > UDP. > > So the answer is: > > a. reassembled UDP packet > > The ICMP message is generated at the request of the receiving UDP layer > which fails to find the received packet's destination port among the > local UDP ports - the ICMP error generator module is called with the > UDP datagram as a parameter. The receiver of the ICMP message passes > a message notification (and the message) up to the original packet's > UDP sender. Thank you for your answer. I understand, but I have another question. If the UDP packet was encrypted by ESP header, which invoking packet should be included in ICMP packet? Or, must not the node return ICMP? ----- Takuya Murakami tmurakam@ccs.mt.nec.co.jp http://www2.biglobe.ne.jp/~tmurakam -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 29 19:36:51 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id TAA25917 for ipng-dist; Wed, 29 Oct 1997 19:33:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id TAA25910 for ; Wed, 29 Oct 1997 19:33:22 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA00513 for ; Wed, 29 Oct 1997 19:33:21 -0800 Received: from snoopy.lucentmmit.com ([38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA15190 for ; Wed, 29 Oct 1997 19:33:25 -0800 Received: by smtp.Lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 29 Oct 1997 22:39:20 -0500 Message-ID: From: "Conta, Alex" To: "'tmurakam@ccs.mt.nec.co.jp'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4731) Re: original packet? Date: Wed, 29 Oct 1997 22:39:19 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@eng.sun.com Precedence: bulk I consider this, if I may, a good question: in case the UDP header is preceded by an ESP header, you're asking which of the possible scenarios is valid: 1. the ICMP message contains the IP datagram as it was received by the IP layer, i.e. IP headers (and part of ESP header) "in clear", (part of ESP and) UDP encrypted. 2. the ICMP message contains the IP datagram as it was processed by the UDP layer, i.e. the IP datagram, including the UDP part "in clear". If encryption (of ICMP messages) is enabled on the reverse path, the ICMP message gets encrypted. Otherwise, the ICMP message contains the original IP datagram "in clear". RFC 1827 is clear in terms of what is "passed up for processing" to the UDP layer: the "in clear" part of the IP header, to be used for PCB lookup, and the UDP header and data. The UDP layer invokes ICMP with the IP datagram content it was "passed up for processing". Hence, I consider scenario #2 the correct answer. If I am wrong, I am sure security experts will comment! Alex ------------------ > UDP datagram as a parameter. The receiver of the ICMP message passes > a message notification (and the message) up to the original packet's > UDP sender. Thank you for your answer. I understand, but I have another question. If the UDP packet was encrypted by ESP header, which invoking packet should be included in ICMP packet? Or, must not the node return ICMP? ----- Takuya Murakami tmurakam@ccs.mt.nec.co.jp http://www2.biglobe.ne.jp/~tmurakam -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 30 04:31:00 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id EAA26182 for ipng-dist; Thu, 30 Oct 1997 04:27:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id EAA26175 for ; Thu, 30 Oct 1997 04:27:01 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA25070 for ; Thu, 30 Oct 1997 04:26:56 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA02668 for ; Thu, 30 Oct 1997 04:27:00 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id NAA02370; Thu, 30 Oct 1997 13:26:44 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id NAA25796; Thu, 30 Oct 1997 13:26:39 +0100 (MET) Message-Id: <199710301226.NAA25796@givry.inria.fr> From: Francis Dupont To: Takuya Murakami cc: AConta@lucent.com, ipng@sunroof.eng.sun.com Subject: (IPng 4732) Re: original packet? In-reply-to: Your message of Thu, 30 Oct 1997 11:36:57 +0900. <199710300236.LAA22679@mail.ccs.mt.nec.co.jp> Date: Thu, 30 Oct 1997 13:26:28 +0100 Sender: owner-ipng@eng.sun.com Precedence: bulk In your previous mail you wrote: If the UDP packet was encrypted by ESP header, which invoking packet should be included in ICMP packet? Or, must not the node return ICMP? => a deciphered packet must not be returned by ICMP (and you don't keep the original packet then you can't signal the error). In fact I believe ICMP and ESP are incompatible and ICMP must never signal (or use a strict rate limitation) a problem with a packet with an ESP header. The argument is this kind of packets can be in fact ICMP errors and you must not trigger a ciphered ICMP error flood (for ICMPv4 I think the rule should be "it is forbidden to send an ICMP error for any ESP packets", for ICMPv6 there is a rate limitation (needed because extension headers can be decoded one by one) and the rule can be less strict). I've seen nothing about this in the current ESP draft (nor in the RFC), I think Ran Atkinson reads this mailing list and will modify if he believes it is a real problem the draft... Regards Francis.Dupont@inria.fr PS: in the README of my next distrib I added some weeks ago this node: - avoid ICMPv6 errors with clear text of ESP packets (ie I already paid attention to your question). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 30 08:48:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id IAA26339 for ipng-dist; Thu, 30 Oct 1997 08:45:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id IAA26332 for ; Thu, 30 Oct 1997 08:45:21 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA20489 for ; Thu, 30 Oct 1997 08:45:18 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA16659 for ; Thu, 30 Oct 1997 08:44:40 -0800 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA00938; Thu, 30 Oct 1997 10:44:10 -0600 Message-Id: <199710301644.KAA00938@gungnir.fnal.gov> To: "Conta, Alex" Cc: "'tmurakam@ccs.mt.nec.co.jp'" , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4734) Re: original packet? In-reply-to: Your message of Wed, 29 Oct 1997 22:39:19 EST. Date: Thu, 30 Oct 1997 10:44:10 -0600 Sender: owner-ipng@eng.sun.com Precedence: bulk > Hence, I consider scenario #2 the correct answer. If I am wrong, I am > sure security experts will comment! I can imagine an asymmetric encryption scheme in use, so that the original sender can't decrypt its own returned packet. So again, #2 looks right, but is there the right MAY/MUST/SHOULDage in place to prevent unintended disclosure of cleartext if the peer application exits or shuts its endpoint? 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 Thu Oct 30 09:09:41 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id JAA26406 for ipng-dist; Thu, 30 Oct 1997 09:06:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id JAA26399 for ; Thu, 30 Oct 1997 09:06:33 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA25928 for ; Thu, 30 Oct 1997 09:06:31 -0800 Received: from snoopy.lucentmmit.com (smtp.Lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA23754 for ; Thu, 30 Oct 1997 09:05:19 -0800 Received: by smtp.Lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Thu, 30 Oct 1997 12:11:17 -0500 Message-ID: From: "Conta, Alex" To: "'Francis.Dupont@inria.fr'" , Takuya Murakami Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4735) Re: original packet? Date: Thu, 30 Oct 1997 12:11:14 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@eng.sun.com Precedence: bulk In my previous message (IPng 4731), I missed scenario #3, which is #3 "do not return an ICMP message at all". Francis, In your message you seem to indicate that #3 may be the correct answer, and that strict rate limitation is required. While I agree with the latter, I question though whether the presence of an ESP header should be considered as a reason to turn off the return of ICMP errors, as much as I question whether the presence of an ESP header be considered always as a reason to encrypt an ICMP message returned to the source of the encrypted packet. The bidirectional path between two nodes A and B can be looked at as two unidirectional paths A->B, and B->A. The two may be: (a) completely identical, or (b) completely different not only as paths in the network, but also as properties/requirements relative to security. Therefore I consider that allowing flexibility in configuring security according to the circumstances of a particular environment which will accommodate both (a) and (b) is the answer. Alex ------------------ In fact I believe ICMP and ESP are incompatible and ICMP must never signal (or use a strict rate limitation) a problem with a packet with an ESP header. The argument is this kind of packets can be in fact ICMP errors and you must not trigger a ciphered ICMP error flood (for ICMPv4 I think the rule should be "it is forbidden to send an ICMP error for any ESP packets", for ICMPv6 there is a rate limitation (needed because extension headers can be decoded one by one) and the rule can be less strict). I've seen nothing about this in the current ESP draft (nor in the RFC), I think Ran Atkinson reads this mailing list and will modify if he believes it is a real problem the draft... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 30 09:21:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id JAA26432 for ipng-dist; Thu, 30 Oct 1997 09:17:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id JAA26425 for ; Thu, 30 Oct 1997 09:17:05 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA28862 for ; Thu, 30 Oct 1997 09:17:02 -0800 Received: from snoopy.lucentmmit.com (smtp.Lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA27400 for ; Thu, 30 Oct 1997 09:15:57 -0800 Received: by smtp.Lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Thu, 30 Oct 1997 12:21:57 -0500 Message-ID: From: "Conta, Alex" To: "'crawdad@gungnir.fnal.gov'" Cc: "'tmurakam@ccs.mt.nec.co.jp'" , ipng@sunroof.eng.sun.com Subject: (IPng 4736) Re: original packet? Date: Thu, 30 Oct 1997 12:21:55 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@eng.sun.com Precedence: bulk The security section will be added text to discuss this particular case. I think also that a mentioning that the rate of generating encrypted ICMP messages should be strictly enforced will be useful. Thanks for the input to all who contributed, Alex --------- > Hence, I consider scenario #2 the correct answer. If I am wrong, I am > sure security experts will comment! I can imagine an asymmetric encryption scheme in use, so that the original sender can't decrypt its own returned packet. So again, #2 looks right, but is there the right MAY/MUST/SHOULDage in place to prevent unintended disclosure of cleartext if the peer application exits or shuts its endpoint? 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 Thu Oct 30 13:27:56 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id NAA26944 for ipng-dist; Thu, 30 Oct 1997 13:25:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id NAA26937 for ; Thu, 30 Oct 1997 13:24:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA10187 for ; Thu, 30 Oct 1997 13:24:51 -0800 Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA01567 for ; Thu, 30 Oct 1997 13:24:47 -0800 Received: from soomro (slip139-92-120-241.kar.pk.ibm.net [139.92.120.241]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id VAA147242 for ; Thu, 30 Oct 1997 21:24:34 GMT Message-ID: <3458FB0D.5DCC@ibm.net> Date: Fri, 31 Oct 1997 02:24:29 +0500 From: Javaid Ahmed Soomro Reply-To: soomro@ibm.net X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: IPng Working Group Subject: (IPng 4737) (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk As a newcomer + inexperienced I had difficulty understanding following terms during the discussion about Mr.takuya Murakami's question about Original Packet. 1. Is the port number = the fragment number of that originated UDP packet at the source A? 2. what is an invoking packet? 3. whats an ESP header , what OSI layer it works? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 30 14:42:04 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id OAA27054 for ipng-dist; Thu, 30 Oct 1997 14:37:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id OAA27047 for ; Thu, 30 Oct 1997 14:37:47 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA29086 for ; Thu, 30 Oct 1997 14:37:44 -0800 Received: from lilly.ping.de (lilly.ping.de [193.100.14.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA18454 for ; Thu, 30 Oct 1997 14:37:23 -0800 Received: (qmail 3397 invoked by alias); 30 Oct 1997 22:37:06 -0000 Received: (qmail 3386 invoked from network); 30 Oct 1997 22:37:05 -0000 Received: from ostenberg.ping.de (194.173.10.97) by lilly.ping.de with SMTP; 30 Oct 1997 22:37:05 -0000 Received: from Bwana (unverified [192.168.1.10]) by ostenberg.ping.de (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 30 Oct 1997 22:39:17 +0100 Message-ID: Comments: Authenticated sender is From: "Andreas Roeschies" To: IPng Working Group , soomro@ibm.net Date: Thu, 30 Oct 1997 23:37:35 +0001 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: (IPng 4739) Re: (no subject) In-reply-to: <3458FB0D.5DCC@ibm.net> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipng@eng.sun.com Precedence: bulk On 31 Oct 97 at 2:24, Javaid Ahmed Soomro wrote: > 3. whats an > ESP header , what OSI layer it works? ESP is an additional/optional header field in ipv6, indicating the packet is encrypted. Andreas Roeschies and@ostenberg.ping.de --------------------------------------------------------------------- You drank beer, you played golf, you watched football - WE EVOLVED! (FZ) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 30 14:48:26 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id OAA27071 for ipng-dist; Thu, 30 Oct 1997 14:44:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with ESMTP id OAA27064 for ; Thu, 30 Oct 1997 14:44:44 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id OAA23955 for ; Thu, 30 Oct 1997 14:44:42 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00667; Thu, 30 Oct 1997 14:44:40 -0800 Received: from kebe.eng.sun.com (kebe [129.146.86.51]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with ESMTP id OAA27026 for ; Thu, 30 Oct 1997 14:27:30 -0800 (PST) Received: (from danmcd@localhost) by kebe.eng.sun.com (8.8.7+Sun.Alpha.9/8.8.7) id OAA12179; Thu, 30 Oct 1997 14:27:29 -0800 (PST) From: Dan McDonald Message-Id: <199710302227.OAA12179@kebe.eng.sun.com> Subject: (IPng 4740) Re: original packet? To: Francis.Dupont@inria.fr (Francis Dupont) Date: Thu, 30 Oct 1997 14:27:29 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199710301226.NAA25796@givry.inria.fr> from "Francis Dupont" at Oct 30, 97 01:26:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk > In fact I believe ICMP and ESP are incompatible and ICMP must never I wouldn't go _THAT_ far. But there are a lot of sticky issues with ESP and ICMP. And let's not forget AH as well! > signal (or use a strict rate limitation) a problem with a packet with an > ESP header. The argument is this kind of packets can be in fact ICMP errors > and you must not trigger a ciphered ICMP error flood (for ICMPv4 I think > the rule should be "it is forbidden to send an ICMP error for any ESP > packets", for ICMPv6 there is a rate limitation (needed because extension > headers can be decoded one by one) and the rule can be less strict). I've > seen nothing about this in the current ESP draft (nor in the RFC), I think > Ran Atkinson reads this mailing list and will modify if he believes it is a > real problem the draft... Steve Bellovin's paper from the 1996 USENIX Security Symposium talks about this too. The rule of thumb is that ICMP messages MUST be protected with the same level of security that sent them. So let's say you get... IP + ESP {UDP....} and it causes and ICMP error, it should return: IP + ESP {ICMP + IP + UDP....} and policy engines on both side should be aware of these cases. Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Oct 30 15:19:55 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id PAA27149 for ipng-dist; Thu, 30 Oct 1997 15:16:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id PAA27142 for ; Thu, 30 Oct 1997 15:16:43 -0800 (PST) Received: from saturn.Sun.COM (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA11309 for ; Thu, 30 Oct 1997 15:16:40 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA28323 for ; Thu, 30 Oct 1997 15:16:03 -0800 Received: from spruce.ipsilon.com (slip202-135-41-71.kw.jp.ibm.net [202.135.41.71]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA10556; Thu, 30 Oct 1997 15:15:50 -0800 Message-Id: <3.0.3.32.19971030151530.00931740@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 30 Oct 1997 15:15:30 -0800 To: brian@hursley.ibm.com From: Bob Hinden Subject: (IPng 4741) Re: draft-ietf-ipngwg-addr-arch-v2-03.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9710280919.AA39101@hursley.ibm.com> References: <9710280130.AA13800@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Brian, I was just about to send the current addressing architecture draft to the IESG for proposed standard. I could either delay that and issue a new draft with the appendix you suggest or we could publish the ABNF syntax in a separate document. I lean to the former, but am open to other suggestions. Is there a final ABNF syntax I could include? Other comments? Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 31 04:53:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) id EAA27563 for ipng-dist; Fri, 31 Oct 1997 04:50:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id EAA27556 for ; Fri, 31 Oct 1997 04:50:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA03710 for ; Fri, 31 Oct 1997 04:50:05 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA25811 for ; Fri, 31 Oct 1997 04:49:57 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id NAA11557; Fri, 31 Oct 1997 13:49:14 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id NAA30189; Fri, 31 Oct 1997 13:49:10 +0100 (MET) Message-Id: <199710311249.NAA30189@givry.inria.fr> From: Francis Dupont To: "Conta, Alex" cc: Takuya Murakami , ipng@sunroof.eng.sun.com Subject: (IPng 4742) Re: original packet? In-reply-to: Your message of Thu, 30 Oct 1997 12:11:14 EST. Date: Fri, 31 Oct 1997 13:48:48 +0100 Sender: owner-ipng@eng.sun.com Precedence: bulk In your previous mail you wrote: In my previous message (IPng 4731), I missed scenario #3, which is #3 "do not return an ICMP message at all". Francis, In your message you seem to indicate that #3 may be the correct answer, and that strict rate limitation is required. => I believe #3 is the simplest and safest answer. While I agree with the latter, I question though whether the presence of an ESP header should be considered as a reason to turn off the return of ICMP errors, as much as I question whether the presence of an ESP header be considered always as a reason to encrypt an ICMP message returned to the source of the encrypted packet. => the two questions are related because in many cases you should encrypt ICMP error messages then you must be protected against ICMP error flood because encryption hides the fact a packet is an ICMP error message. In IPv6 there are other reasons this information is not available or expensive to get then there is a rate limitation for ICMP errors. It is not the case for IPv4 then something must be done (rate limitation (which is a good idea in absolute terms) or #3). There are some inputs in the discussion about ICMP messages for IPsec errors too... Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------