From owner-ipng@sunroof.eng.sun.com Mon Jan 4 14:26:50 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id OAA26279 for ipng-dist; Mon, 4 Jan 1999 14:12:49 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id OAA26272 for ; Mon, 4 Jan 1999 14:11:46 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA03866 for ; Mon, 4 Jan 1999 14:11:44 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA04223 for ; Mon, 4 Jan 1999 14:11:43 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA08197; Mon, 4 Jan 1999 16:11:17 -0600 (CST) Message-Id: <199901042211.QAA08197@gungnir.fnal.gov> To: Marc Fiuczynski Cc: "'Thomas Narten'" , Richard Draves , "'IPng List'" From: "Matt Crawford" X-Mailer: Microsoft Outlook98 Subject: (IPng 6997) Re: route distribution via ND In-reply-to: Your message of Wed, 30 Dec 1998 10:33:51 PST. <055A195871E5D1119F8100A0C9499B5F4F9916@exchsrv1.cs.washington.edu> Date: Mon, 04 Jan 1999 16:11:17 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > following simple scenario: > > Clients sending packets with a prefix P > *must* be sent via a stub-router S. > > This stub-router may not have the capability to act as a default router. > The question is how do clients learn about the route for prefix P to > stub-router S? > > One approach is to have a default-router send redirects. What if there > is no default router in this particular environment? I think this whole thing is a tempest in a teapot. (A non-issue, for those unacquainted with the expression.) If there is a default router, it should know how to redirect to all other routers. Unless you want to say "redirects are bad", this case is closed. If there is no default router, fall through to RFC 2461, section 6.3.6, case (3): 3) If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2. Presumably, the "right" router will respond to your NS with an NA, and there you go. 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 Mon Jan 4 21:48:39 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id VAA26599 for ipng-dist; Mon, 4 Jan 1999 21:45:00 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id VAA26592 for ; Mon, 4 Jan 1999 21:44:49 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA01278 for ; Mon, 4 Jan 1999 21:44:49 -0800 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA03406 for ; Mon, 4 Jan 1999 21:44:49 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Mon, 4 Jan 1999 21:44:49 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF819F5@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 6998) Re: route distribution via ND Date: Mon, 4 Jan 1999 21:44:43 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Back from vacation and I find I've missed a good discussion! I want to thank everyone for their input, and my apologies for this long message. Let me summarize where I think the discussion stands, in two parts - first, why would one want to distribute routes to hosts, and second, (assuming it's desirable), should it be done via ND or some other mechanism? 1. Why would one want to distribute routes to hosts? The counter-argument is redirects will always do the job acceptably. Let me break this down into three cases (a, b, c). a. Performance. I agree, in most situations the overhead of redirects will not be significant and so this is not a compelling argument on its own. My concern is that there may be some scenarios where it will be important, and for the poor souls stuck with some "feature" it's no comfort to know that most everyone else is not similarly afflicted. I think trying to calculate some metric like the percentage of network bandwidth consumed by redirects is not very interesting, because it completely dependent on the application traffic patterns and the implementations involved (eg destination cache size & management, rate-limiting of redirects). Another important performance issue, to my mind, is the increased latency incurred for the first packet of a flow. Between DNS & ND & who knows what else, it already takes enough packets to start talking to a new destination. b. Is there always a default router to send the redirect? Marc's scenario is a node (happens to be a translator, but that's not important) that knows how to forward packets sent to a certain range of destination addresses, but that has no particular ability to handle other packets. One line of thought seems to be that a router is a router and if you are going to forward any packets, then you must advertise yourself as a router and forward all packets appropriately. So the translator should advertise itself as a router, and if there's also a "real" router on link then it must be configured to forward/redirect to the real router & vice-versa. Another line of thought is that if there is no advertising router then hosts will fall back on treating all destinations as on-link, and the translator can "proxy-ND" for the range of addresses that it is handling. I don't much like this solution, not least because the fall-back doesn't work for multi-homed hosts (on which link should the multi-homed hosts attempt ND?). Btw, I think multi-homed hosts are a very important case - a host with a single physical interface can also have virtual interfaces, and this will be very common with some transition mechanisms/scenarios. Some day I would like to compare notes with some other implementor on this topic, since I like to think that we've done a good job in MSR IPv6 with support for multi-homed hosts. c. Redirects are not always a solution. For example, a redirect can not tell a multi-homed host that it should be using a different interface. For another example, consider a host H on a relatively slow link with two routers A & B and talking to a destination D. The "best" router for host H to use to reach destination D is router A. When host H uses router B, there's no redirect because B forwards the packet on to D using a different route (either not through A, or through A but via a faster link to A). 2. So on balance I think it's reasonable to have a mechanism for routers to communicate routes to hosts. It can be an optional mechanism, but it would be nice to have agreement so those desiring it can interoperate. Then the question is what should this mechanism be? An option in Router Advertisements? RIPng (RFC 2080)? Perhaps something new? At this point, I think I would favor a new option in Router Advertisements, with a route prefix, lifetime, and metric, instead of trying to use the existing prefix-information option. The argument in favor of using Router Advertisements is Router Advertisements are already the architectural mechanism for communicating information from routers to hosts. If it's there, why have another mechanism? Another mechanism is just more code & more packets. The argument in favor of using RIPng is that it already exists and there's precedent for using RIP in this fashion. It has the drawback that it doesn't support lifetimes for routes. It would mean hosts & routers would need to implement two mechanisms (ND/RAs and RIPng) instead of just one (RAs). Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 4 21:55:42 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id VAA26621 for ipng-dist; Mon, 4 Jan 1999 21:53:42 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id VAA26614 for ; Mon, 4 Jan 1999 21:53:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA18428 for ; Mon, 4 Jan 1999 21:53:32 -0800 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA06314 for ; Mon, 4 Jan 1999 21:53:32 -0800 (PST) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Mon, 4 Jan 1999 21:53:31 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF819F6@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 6999) Re: route distribution via ND Date: Mon, 4 Jan 1999 21:53:29 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Btw, I came across a minor thing while looking at the ND spec: It says A router MUST limit the rate at which Redirect messages are sent, in order to limit the bandwidth and processing costs incurred by the Redirect messages when the source does not correctly respond to the Redirects, or the source chooses to ignore unauthenticated Redirect messages. More details on the rate-limiting of ICMP error messages can be found in [ICMPv6]. But Redirect messages are Type 137, which makes them ICMP informational messages. In any case I interpret it to say Redirects should be subject to rate-limiting as if they were error messages. It's too late now, but it would have saved an extra check in some implementations if Redirects had a Type < 128. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 5 08:40:14 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA26945 for ipng-dist; Tue, 5 Jan 1999 08:30:47 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA26938 for ; Tue, 5 Jan 1999 08:30:33 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA18595 for ; Tue, 5 Jan 1999 08:30:31 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA13188 for ; Tue, 5 Jan 1999 08:30:31 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id KAA11402 for ; Tue, 5 Jan 1999 10:30:29 -0600 (CST) Message-Id: <199901051630.KAA11402@gungnir.fnal.gov> To: "'IPng List'" From: "Matt Crawford" X-Mailer: Microsoft Outlook98 Subject: (IPng 7001) Re: route distribution via ND X-MS-Blackeye: Visualize a valid Message-id! In-reply-to: Your message of Mon, 04 Jan 1999 21:44:43 PST. <4D0A23B3F74DD111ACCD00805F31D8100AF819F5@RED-MSG-50> Date: Tue, 05 Jan 1999 10:30:29 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Suppose you have your canonical dual-homed host H on two links L1 and L2. Each link has other, single-homed hosts, or hosts dual-homed to L3, and one or more routers. There may be no router in common on L1 and L2. There may be a myriad of destinations for which one link is preferred over the other, and not always the same link. Now, what information do you want the routers to convey to the hosts? How much routing state should the hosts have to cache in advance of any traffic to send? Any solution to the perceived problem (and yes, I do agree that it MAY be worth doing something about this) should be fully general and be lightweight to the uninterested hosts. I suggest a new option on neghbor advertisements which would include an AS identifier and a metric. Then a multihomed host which does not participate in a routing protocol but which wants to choose the best first-hop interface can do an NS (which might also include a new option, perhaps containing traffic class information?) on each interface and, when the NA replies have the metric option with equal AS identifiers, choose the better metric. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 5 11:04:29 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id KAA27097 for ipng-dist; Tue, 5 Jan 1999 10:54:03 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id KAA27090 for ; Tue, 5 Jan 1999 10:53:48 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id KAA24646; Tue, 5 Jan 1999 10:54:05 -0800 (PST) Date: Tue, 5 Jan 1999 10:53:45 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7003) Re: redirects [Was: route distribution via ND ] To: Richard Draves Cc: "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF819F6@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But Redirect messages are Type 137, which makes them ICMP informational > messages. In any case I interpret it to say Redirects should be subject to > rate-limiting as if they were error messages. That is correct. > It's too late now, but it > would have saved an extra check in some implementations if Redirects had a > Type < 128. Redirects being informational also has the drawback that nodes can generate ICMP errors in response to redirects. As long as that error doesn't cause another redirect there won't be an infinite number of packets - and rate limiting is likely to cut of any redirect + ICMP error ping-pong. But in hindsight I would feel more confortable if ICMP errors weren't generated in response to redirects (which they are not in IPv4). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 5 11:58:16 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id LAA27162 for ipng-dist; Tue, 5 Jan 1999 11:42:47 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id LAA27155 for ; Tue, 5 Jan 1999 11:42:18 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id LAA02570; Tue, 5 Jan 1999 11:42:34 -0800 (PST) Date: Tue, 5 Jan 1999 11:42:14 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7004) Re: route distribution via ND To: Richard Draves Cc: "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF819F5@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > b. Is there always a default router to send the redirect? Marc's scenario is > a node (happens to be a translator, but that's not important) that knows how > to forward packets sent to a certain range of destination addresses, but > that has no particular ability to handle other packets. > > One line of thought seems to be that a router is a router and if you are > going to forward any packets, then you must advertise yourself as a router > and forward all packets appropriately. So the translator should advertise > itself as a router, and if there's also a "real" router on link then it must > be configured to forward/redirect to the real router & vice-versa. I think that is the only way to build a robust network. Having "half-routers" that forward some packets but drop other packets on the floor will, when something goes wrong, cause black holes that are very hard to find. For instance, the R bit in the neighbor advertisement is used to indicate that the sender will forward packets - all packets - not just the packets it cares to forward. Thus I don't see how NUD can possible work in in world with "half-routers" since those boxes will effectively have an R bit that is a function of the destination address. I guess that is why we have the definitions for router and host. But it seems like we need to modify the definition of router to say "attempts to forward all packets not explicitly addressed to itself" to make this more clear :-) > Btw, I think multi-homed hosts are a very important case - a host with a > single physical interface can also have virtual interfaces, The multihomed case where you need more information for optimal routing is when a host has multiple *physical* interfaces (so that the node can select the outgoing interface). Virtual interfaces doesn't add any new requirements here as far as I know. > > c. Redirects are not always a solution. For example, a redirect can not tell > a multi-homed host that it should be using a different interface. > > For another example, consider a host H on a relatively slow link with two > routers A & B and talking to a destination D. The "best" router for host H > to use to reach destination D is router A. When host H uses router B, > there's no redirect because B forwards the packet on to D using a different > route (either not through A, or through A but via a faster link to A). I think this is the fundamental tradeoff with moving information out from the hosts to the routers. Unless the routers maintain a routing table per interface they will not be able to generate redirects that provide optimal routing. But the worst case is just one hop more than the optimal path. > At this point, I think I would favor a new option in Router Advertisements, > with a route prefix, lifetime, and metric, instead of trying to use the > existing prefix-information option. If we go this path I fear we will soon be getting requests for being able to authenticate the content of this routing option (but not using AH for the whole packet) since RIPng has such support. Thus I fear we will end up with a discussion of what parts of RIP to move into ND and that we might end up with most of RIPng functionality in ND. What for? RIPng is done and works. I don't see a problem for using it where it is really needed e.g. on hosts with multiple physical interfaces. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 5 12:00:24 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id LAA27172 for ipng-dist; Tue, 5 Jan 1999 11:53:12 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id LAA27165 for ; Tue, 5 Jan 1999 11:52:59 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA11249 for ; Tue, 5 Jan 1999 11:52:57 -0800 Received: from isosun.ariadne-t.gr (isosun.ariadne-t.gr [143.233.1.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA26063 for ; Tue, 5 Jan 1999 11:52:57 -0800 (PST) Received: (qmail 7378 invoked by alias); 5 Jan 1999 19:42:52 -0000 X-NCC-RegID: gr.ariadnet Received: (qmail 7371 invoked from network); 5 Jan 1999 19:42:51 -0000 Received: from xainis.ariadne-t.gr (HELO ariadne-t.gr) (msifa@143.233.233.4) by isosun.ariadne-t.gr with SMTP; 5 Jan 1999 19:42:51 -0000 Message-ID: <36926D84.47C7931B@ariadne-t.gr> Date: Tue, 05 Jan 1999 21:52:36 +0200 From: Manolis Sifalakis Organization: NCSR Demokritos - ARIADNE Network X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.35 i586) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: msifa@ariadne-t.gr Subject: (IPng 7005) EGP routing in IPv6 ? References: <199812301239.HAA00770@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, i wish to everybody Happy New Year ! At first i 'd like to apologise if, for any reason, my question has not been sent to the appropriate list. Since i am new with IPv6, and i am currently reading every piece of information that gets into my hands (or in front of my eyes!), i have read in several "old" documents (considering how fast things evolve with the drafts and rfcs in IPv6), that IDRPv2 had been proposed as the newcoming EGP protocol for IPv6, that will replace BGP4. Nevertheless the only draft i could find at the ISI draft-db, had expired. On the other hand BGP4 with multiprotocol extentions seems to be widely used, to achieve EGP routing at the 6bone. My question is this.. "Has the idea of using IDRPv2, been abandoned, and BGP4+ is going to be used, instead ???" Thanks in advance for tolerating my ignorance :-) Regards Manolis -- +--------------------------------------------------------+ | Sifalakis Manolis (WILLY) | | | | e-mail: msifa@ariadne-t.gr | | nic-hdl: MS4469-RIPE ARIADNE ACADEMIC NETWORK | | tel: +3 01 6544279 NCSR DEMOKRITOS | | tel: +3 01 6543615 15310, Ag. Paraskevi | | fax: +3 01 6532910 Athens, GR | +--------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 5 12:03:50 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id LAA27181 for ipng-dist; Tue, 5 Jan 1999 11:56:20 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id LAA27174 for ; Tue, 5 Jan 1999 11:56:08 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA11780 for ; Tue, 5 Jan 1999 11:56:04 -0800 Received: from aketzali.super.unam.mx (aketzali.super.unam.mx [132.248.159.41]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA28116 for ; Tue, 5 Jan 1999 11:56:04 -0800 (PST) Received: from localhost (rafael@localhost) by aketzali.super.unam.mx (8.8.7/8.8.7) with SMTP id NAA23164 for ; Tue, 5 Jan 1999 13:57:25 -0600 Date: Tue, 5 Jan 1999 13:57:25 -0600 (CST) From: Rafael Quiroz Plata To: ipng@sunroof.eng.sun.com Subject: (IPng 7006) Options of the traffic class field In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF819F6@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I need to know what are the options of the traffic class field of header of Ipv6, where I can get a good references o resources about this ? Thanks a lot -- Rafael Quiroz University of Mexico -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 5 12:55:52 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id MAA27295 for ipng-dist; Tue, 5 Jan 1999 12:43:36 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id MAA27288 for ; Tue, 5 Jan 1999 12:43:24 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16431 for ; Tue, 5 Jan 1999 12:43:21 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA29524 for ; Tue, 5 Jan 1999 12:43:21 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id MAA22141; Tue, 5 Jan 1999 12:42:38 -0800 (PST) Message-Id: <3.0.5.32.19990105124158.00a0b6e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 05 Jan 1999 12:41:58 -0800 To: Manolis Sifalakis From: Bob Hinden Subject: (IPng 7008) Re: EGP routing in IPv6 ? Cc: ipng@sunroof.eng.sun.com In-Reply-To: <36926D84.47C7931B@ariadne-t.gr> References: <199812301239.HAA00770@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Manolis, >EGP routing at the 6bone. My question is this.. "Has the idea of using IDRPv2, been >abandoned, and BGP4+ is going to be used, instead ???" Yes, that is my conclusion as well. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 01:07:28 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id AAA27722 for ipng-dist; Wed, 6 Jan 1999 00:59:13 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id AAA27715 for ; Wed, 6 Jan 1999 00:59:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA28695 for ; Wed, 6 Jan 1999 00:58:59 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA29590 for ; Wed, 6 Jan 1999 00:59:00 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id JAA19721; Wed, 6 Jan 1999 09:58:57 +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 JAA28280; Wed, 6 Jan 1999 09:58:57 +0100 (MET) Message-Id: <199901060858.JAA28280@givry.inria.fr> From: Francis Dupont To: Manolis Sifalakis cc: ipng@sunroof.eng.sun.com Subject: (IPng 7009) Re: EGP routing in IPv6 ? In-reply-to: Your message of Tue, 05 Jan 1999 21:52:36 +0200. <36926D84.47C7931B@ariadne-t.gr> Date: Wed, 06 Jan 1999 09:58:56 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: At first i 'd like to apologise if, for any reason, my question has not been sent to the appropriate list. Nevertheless the only draft i could find at the ISI draft-db, had expired. On the other hand BGP4 with multiprotocol extentions seems to be widely used, to achieve EGP routing at the 6bone. My question is this.. "Has the idea of using IDRPv2, been abandoned, and BGP4+ is going to be used, instead ???" => it is the case, near only BGP4+ is used as an EGP for IPv6 today and there are many implementations of it... BGP4+ is described in RFC 2283 and the IPv6 part is still in an I-D (draft-ietf-idr-bgp4-ipv6-01.txt) which has been approved by the IESG as a Proposed Standard (18 Feb 1998) but not yet published as a RFC (it seems to be in the queue of the RFC editor with many other RFCs). 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 Jan 6 02:56:00 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id CAA27796 for ipng-dist; Wed, 6 Jan 1999 02:49:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id CAA27789 for ; Wed, 6 Jan 1999 02:49:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA03227 for ; Wed, 6 Jan 1999 02:49:25 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA04538 for ; Wed, 6 Jan 1999 02:49:25 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id KAA130426; Wed, 6 Jan 1999 10:49:23 GMT Received: from hursley.ibm.com (9-20-31-131.dhcp.hursley.ibm.com [9.20.31.131]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id KAA15718; Wed, 6 Jan 1999 10:49:23 GMT Message-ID: <36933F88.DE37F322@hursley.ibm.com> Date: Wed, 06 Jan 1999 10:48:40 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Rafael Quiroz Plata CC: ipng@sunroof.eng.sun.com Subject: (IPng 7010) Re: Options of the traffic class field References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 2474 and RFC 2475 Brian Rafael Quiroz Plata wrote: > > I need to know what are the options of the traffic class field > of header of Ipv6, where I can get a good references o resources about > this ? > > Thanks a lot > -- Rafael Quiroz > University of Mexico > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 06:39:14 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id GAA27882 for ipng-dist; Wed, 6 Jan 1999 06:28:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id GAA27875 for ; Wed, 6 Jan 1999 06:28:37 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA12394 for ; Wed, 6 Jan 1999 06:28:33 -0800 Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA14565 for ; Wed, 6 Jan 1999 06:28:31 -0800 (PST) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP-external (PP); Wed, 6 Jan 1999 14:28:00 +0000 Date: Wed, 6 Jan 1999 14:28:15 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Brian E Carpenter cc: Rafael Quiroz Plata , ipng@sunroof.eng.sun.com Subject: (IPng 7011) Re: Options of the traffic class field In-Reply-To: <36933F88.DE37F322@hursley.ibm.com> Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 6 Jan 1999, Brian E Carpenter wrote: > RFC 2474 and RFC 2475 Hmmm, as of today http://src.doc.ic.ac.uk/rfc/rfc-index.txt ftp://ftp.isi.edu/in-notes/rfc-index.txt claim: 2474 . .. (Not online) although the diff-serv RFCs of Dec '98 that Brian mentions _are_ in the directories. Odd. I wish that the rfc-index was in reverse-chronological order with new stuff at the top, that it had a last-revised date inside it, and that it was always current. L. if you can't even rely on grepping through the current rfc-index... > Rafael Quiroz Plata wrote: > > > > I need to know what are the options of the traffic class field > > of header of Ipv6, where I can get a good references o resources about > > this ? PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 06:53:55 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id GAA27942 for ipng-dist; Wed, 6 Jan 1999 06:42:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id GAA27935 for ; Wed, 6 Jan 1999 06:41:50 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA13299 for ; Wed, 6 Jan 1999 06:41:47 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA20328 for ; Wed, 6 Jan 1999 06:41:49 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA26328; Wed, 6 Jan 1999 09:41:45 -0500 (EST) Message-Id: <199901061441.JAA26328@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7012) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-05.txt Date: Wed, 06 Jan 1999 09:41:45 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-new-05.txt Pages : 33 Date : 05-Jan-99 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-bsd-api-new-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-bsd-api-new-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990105155849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-new-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990105155849.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 07:47:38 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA28096 for ipng-dist; Wed, 6 Jan 1999 07:39:43 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA28089 for ; Wed, 6 Jan 1999 07:39:32 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA28004 for ; Wed, 6 Jan 1999 07:39:30 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA19950 for ; Wed, 6 Jan 1999 07:39:30 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA22684; Wed, 6 Jan 1999 15:39:27 GMT Received: from hursley.ibm.com (9-20-31-131.dhcp.hursley.ibm.com [9.20.31.131]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA13964; Wed, 6 Jan 1999 15:39:26 GMT Message-ID: <36938383.B5F76F9E@hursley.ibm.com> Date: Wed, 06 Jan 1999 15:38:43 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Lloyd Wood CC: Rafael Quiroz Plata , ipng@sunroof.eng.sun.com Subject: (IPng 7013) Re: Options of the traffic class field References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have informed the appropriate people that the index is broken. Brian Lloyd Wood wrote: > > On Wed, 6 Jan 1999, Brian E Carpenter wrote: > > > RFC 2474 and RFC 2475 > > Hmmm, as of today > http://src.doc.ic.ac.uk/rfc/rfc-index.txt > ftp://ftp.isi.edu/in-notes/rfc-index.txt > claim: > > 2474 . .. (Not online) > > although the diff-serv RFCs of Dec '98 that Brian mentions _are_ > in the directories. > > Odd. I wish that the rfc-index was in reverse-chronological order with > new stuff at the top, that it had a last-revised date inside it, and > that it was always current. > > L. > > if you can't even rely on grepping through the current rfc-index... > > > Rafael Quiroz Plata wrote: > > > > > > I need to know what are the options of the traffic class field > > > of header of Ipv6, where I can get a good references o resources about > > > this ? > > PGP > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 08:21:02 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA28135 for ipng-dist; Wed, 6 Jan 1999 08:11:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA28128 for ; Wed, 6 Jan 1999 08:11:13 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA20232 for ; Wed, 6 Jan 1999 08:11:11 -0800 Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA08394 for ; Wed, 6 Jan 1999 08:11:11 -0800 (PST) Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.1/8.9.1) with SMTP id LAA07339 for ; Wed, 6 Jan 1999 11:11:58 -0500 (EST) Date: Wed, 6 Jan 1999 11:11:57 -0500 (EST) From: "John F. Leser" To: ipng@sunroof.eng.sun.com Subject: (IPng 7014) Question about redirect function Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have a quick question about redirects: According to the neighbor discovery specification, in order for a redirect to be valid, the source address must be the same as the current first-hop router for the ICMP destination. Does this mean that a host must have a destination cache entry before it will accept a redirect for that destination? If not, what happens when a host has more than one router on its default router list - will it accept redirects from any of them for a destination it has not communicated with previously? ***************************************************************** John Leser InterOperability Lab IP/Routing Consortium Engineer University of New Hampshire 7 Leavitt Lane, Room 106 Tel: (603) 862-0090 Durham, NH 03824-3525 Fax: (603) 862-4181 Email: jfl@iol.unh.edu Web: http://www.iol.unh.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 13:34:05 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id NAA28422 for ipng-dist; Wed, 6 Jan 1999 13:21:14 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id NAA28415 for ; Wed, 6 Jan 1999 13:20:59 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA26070 for ; Wed, 6 Jan 1999 13:20:55 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA03986 for ; Wed, 6 Jan 1999 13:20:55 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 6 Jan 1999 13:20:52 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81A1B@RED-MSG-50> From: Richard Draves To: "'John F. Leser'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7016) RE: Question about redirect function Date: Wed, 6 Jan 1999 13:20:49 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > According to the neighbor discovery specification, in order > for a redirect > to be valid, the source address must be the same as the > current first-hop > router for the ICMP destination. Does this mean that a host > must have a > destination cache entry before it will accept a redirect for that > destination? If not, what happens when a host has more than > one router on > its default router list - will it accept redirects from any > of them for a > destination it has not communicated with previously? This is what I implemented after reading the spec: - if the host receiving the Redirect has a destination cache entry for the ICMP Destination address, then check that the source of the Redirect is the next-hop neighbor specified in the destination cache entry. Ignore the redirect if this check fails. - if the host receiving the Redirect does not have a destination cache entry, then create one (the spec says SHOULD). No sanity check on the source of the Redirect. In the latter case, I suppose it would be a good thing to sanity-check the source address, although it's not possible to do it perfectly. Eg valid Redirects would sometimes be rejected. For example, suppose H is a host sending to a destination D. A is a default router. A sends a redirect telling H to send that traffic to router B. B is not advertising itself as a default router. Later, B sends a redirect telling H to send the traffic to router C. Just before receiving the second redirect, H frees its destination cache entry for D. If H tries to sanity-check the source address of this second redirect, it will look bogus because H doesn't know about B anymore. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 14:14:00 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id NAA28466 for ipng-dist; Wed, 6 Jan 1999 13:58:34 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id NAA28459 for ; Wed, 6 Jan 1999 13:58:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA02723 for ; Wed, 6 Jan 1999 13:58:15 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA28685 for ; Wed, 6 Jan 1999 13:58:17 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 6 Jan 1999 13:58:17 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81A27@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: "'IPng List'" Subject: (IPng 7017) Re: route distribution via ND Date: Wed, 6 Jan 1999 13:58:15 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that is the only way to build a robust network. > Having "half-routers" that forward some packets but drop other packets > on the floor will, when something goes wrong, cause black > holes that are > very hard to find. Yes, I agree with this. > > Btw, I think multi-homed hosts are a very important case - > a host with a > > single physical interface can also have virtual interfaces, > > The multihomed case where you need more information for > optimal routing > is when a host has multiple *physical* interfaces (so that > the node can > select the outgoing interface). Virtual interfaces doesn't > add any new requirements here as far as I know. I don't see the difference between physical interfaces & virtual interfaces. (By definition :-). For example a multi-homed host with a physical ethernet interface and a virtual 6-over-4 interface is faced with the same problems as a multi-homed hosts with two physical ethernet interfaces. > If we go this path I fear we will soon be getting requests > for being able > to authenticate the content of this routing option (but not > using AH for > the whole packet) since RIPng has such support. Thus I fear > we will end up > with a discussion of what parts of RIP to move into ND and > that we might > end up with most of RIPng functionality in ND. What for? I think pretty much all the other information in RAs would want the same security/authentication as routes. RAs are already used to communicate information about default routes and "on-link" routes. This information should be authenticated. Information used for address auto-configuration should be authenticated. Etc. So in fact it would seem simpler to me to have a single system to authenticate RAs, then to authenticate RAs and RIPng separately. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 14:24:43 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id OAA28483 for ipng-dist; Wed, 6 Jan 1999 14:12:41 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id OAA28476 for ; Wed, 6 Jan 1999 14:12:12 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA09553 for ; Wed, 6 Jan 1999 14:12:11 -0800 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA07979 for ; Wed, 6 Jan 1999 14:12:10 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 6 Jan 1999 14:12:09 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81A28@RED-MSG-50> From: Richard Draves To: "'Matt Crawford'" Cc: "'IPng List'" Subject: (IPng 7018) Re: route distribution via ND Date: Wed, 6 Jan 1999 14:12:09 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Suppose you have your canonical dual-homed host H on two links L1 and > L2. Each link has other, single-homed hosts, or hosts dual-homed to > L3, and one or more routers. There may be no router in common on L1 > and L2. There may be a myriad of destinations for which one link is > preferred over the other, and not always the same link. Yes, in a very complex topology the multi-homed host needs a very large routing table to achieve perfect routing. I think this is inevitable, and the responsible network administrator can either choose not to build such a complex topology or to summarize the routing information provided to the hosts and accept imperfect routing. > I suggest a new option on neghbor advertisements which would include > an AS identifier and a metric. Then a multihomed host which does not > participate in a routing protocol but which wants to choose the best > first-hop interface can do an NS (which might also include a new > option, perhaps containing traffic class information?) on each > interface and, when the NA replies have the metric option with equal > AS identifiers, choose the better metric. I guess I don't understand this. Won't there only be an NA reply if the destination in question is on-link? The on-link prefix information in RAs already let a multi-homed host select the correct interface to use to reach on-link neighbors. Or are you suggesting that routers will respond with NAs on behalf of destinations to which they know how to route? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 15:03:53 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id OAA28553 for ipng-dist; Wed, 6 Jan 1999 14:48:51 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id OAA28546 for ; Wed, 6 Jan 1999 14:48:24 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA13224 for ; Wed, 6 Jan 1999 14:48:21 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA01154 for ; Wed, 6 Jan 1999 14:48:22 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA03790 for ; Wed, 6 Jan 1999 16:48:20 -0600 (CST) Message-Id: <199901062248.QAA03790@gungnir.fnal.gov> To: "'IPng List'" From: "Matt Crawford" X-Mailer: Microsoft Outlook98 Subject: (IPng 7019) Re: route distribution via ND In-reply-to: Your message of Wed, 06 Jan 1999 14:12:09 PST. <4D0A23B3F74DD111ACCD00805F31D8100AF81A28@RED-MSG-50> Date: Wed, 06 Jan 1999 16:48:20 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > .. are you suggesting that routers will respond with NAs > on behalf of destinations to which they know how to route? Yes, this would fit in under the term "proxy" as used in 2461. It may be a burden to be a member of so many multicast groups (all the solicited-node addresses, in practice) but many routers will typically be receiving all multicasts anyway. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 15:43:57 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id PAA28634 for ipng-dist; Wed, 6 Jan 1999 15:28:17 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id PAA28627 for ; Wed, 6 Jan 1999 15:27:57 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id PAA15227; Wed, 6 Jan 1999 15:28:14 -0800 (PST) Date: Wed, 6 Jan 1999 15:26:44 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7020) Re: route distribution via ND To: Richard Draves Cc: "'Erik Nordmark'" , "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF81A27@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't see the difference between physical interfaces & virtual interfaces. > (By definition :-). For example a multi-homed host with a physical ethernet > interface and a virtual 6-over-4 interface is faced with the same problems > as a multi-homed hosts with two physical ethernet interfaces. Correct (at least in principle). I didn't understand what you meant by "virtual". What I was trying to point out that that while the definition for multihomed is >1 IPv6 address it is really the number of interfaces that creates an issue. But in your specific case (an ethernet and a 6-over-4 interface) it would make most sense to only use one of those at a time. One way of implementing this would be: When the host finds a default router on the ethernet it would effectively turn off (or at least stop transmitting on) the 6-over-4 interface. When there are no default routers on the ethernet (or no non-link-local addresses assigned to the ethernet interface) it would switch back to transmitting on the 6-over-4 interface. [I personally think preferring the ethernet over 6-over-4 since it avoids encapsulating overhead as well as reduces IPv4 multicast traffic.] > So in fact it would seem simpler to me to have a single system to > authenticate RAs, then to authenticate RAs and RIPng separately. I spoke without checking RIPng. RIPng uses IPsec for authentication thus there won't be any pressure to add any RIPng specific authentication to your proposed new ND option. (But key distribution and authorization checks will be hard problems for anybody building ND/RIPng security.) But that doesn't change my basic argument: there will be pressure to ensure that your new ND option has all the features and capabilities of RIPng. Why invent a new packet/option format when RIPng can be used for this today? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 18:22:49 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id SAA28875 for ipng-dist; Wed, 6 Jan 1999 18:13:39 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id SAA28859; Wed, 6 Jan 1999 18:09:26 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA17337; Wed, 6 Jan 1999 18:09:24 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA27872; Wed, 6 Jan 1999 18:09:25 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id SAA19769; Wed, 6 Jan 1999 18:09:24 -0800 (PST) Message-Id: <3.0.5.32.19990106180842.009fc310@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 06 Jan 1999 18:08:42 -0800 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7021) Draft Agenda for IPng/NGTRANS Interim Meeting Cc: Bob Fink , Steve Deering , Tony Hain , Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Attached is the draft agenda for the interim IPng and NGTRANS working group meetings, February 2-4, in Grenoble, France. If you plan to attend, PLEASE register by emailing your name to , so we know how many people to plan for. See http://www.ipv6.imag.fr/ietf1999.html for travel and hotel information, as well as the list of currently registered attendees. The general structure of the three days will be: Day 1: IPng w.g. meeting Day 2: NGTRANS w.g. meeting Day 3: Non-IETF related discussions about IPv6 deployment and promotion Depending on interest and number of topics to be covered, either of the two WG meetings may be allowed to overflow its one-day slot, e.g., by reallocating time from one of the other meetings or adding an evening session on Wednesday. This is a *draft* agenda; please send suggested additions/changes to the WG chairs (listed in the Cc: line of this message). Bob, Steve, Bob, Tony IPng and NGTRANS Chairs ---------------------------------------------------------------- IPng / NGTRANS INTERIM MEETING AGENDA ---------------------------------------------------------------- Tuesday, February 2 -- IPng w.g. meeting ---------------------------------------- Purpose: The IPng w.g. has mostly completed its original charter, except for shepherding the many w.g. specs through the final stages of Internet Standardization. The purposes of this meeting are: (a) to review the state of our many documents to identify any holes or loose ends that must be finished up to complete our charter, and (b) to identify and discuss new IPv6-related topics that the attendees think should be taken on by the IETF or the IRTF (Internet Research Task Force), either in the current working group or in other working groups / research groups. Requirements for Attendees: **NOTE** All attendees are required to bring a short list (one to five items, on a single sheet of paper) of topics that they consider the most important IPv6-related topics for the IETF or IRTF to work on. Also, some attendees will be asked to lead discussions of specific topics (volunteers gratefully accepted). Agenda: (1) Review state/completeness of current IPv6-related protocols - IPv6 Protocols o Base Protocol o Addressing o ICMP, Neighbor discovery, auto config, MLD o IPover, Header compression o DNS o MIB's o Path MTU o Router Alert o Jumbograms - API's - Routing Protocols (Unicast and Multicast) - DHCP - IP Mobility (2) Identify important new IPv6 protocol/standards work - State of Plug-and-Play (Hinden) o "Dentist's office" o Secure "Dentist's office" - Securing ICMP/ND/MLD (who?) - Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (who?) - Better Support for Multihomed Hosts (who?) - Better Support for Multihomed Sites (who?) - Flow Label usage (who?) - ... (3) Formulate recommendations to the IESG/IAB, re future IPv6 work - Disposition of IPng w.g. (extend charter? go on hiatus?) - Distribution of work to other existing WGs? - Evaluation of all IETF protocols for "IPv6-readiness"? - Recommendations for establishing new WG(s) or RG(s)? Wednesday, February 3 -- NGTRANS w.g. meeting ---------------------------------------- Purpose: The NGTRANS w.g. has developed a large set of transition tools including the original transition mechanisms (i.e., dual stack w/ IPv6 over IPv4 tunneling), 6over4 without explicit tunnels, translation, and other tunneling techniques. The purpose of the meeting is for the w.g. to converge on a smaller set of tools and mechanisms. The meeting will include discussing specific transition scenarios and evaluating how the current transition tools and mechanism work in these environments. Agenda: (1) Review NGTRANS mission and charter (2) Develop a taxonomy for transition tools (who?) (3) Review current transition tools and mechanisms - Dual stack (who?) - Translation (who?) - 6over4 (who?) - Automatic tunneling (who?) - ... (4) Discuss specific transition scenarios (who?) - Private network case: (who?) - Public network case: (who?) - Issues to address in each scenario: (who?) (5) Review analysis and converge on set of tools and mechanisms. Thursday, February 4 -- IPv6 Deployment and Promotion ----------------------------------------------------- The purpose of this day will be to review current deployment activities, potential additional efforts, and opportunities for educating and influencing developers, ISPs, network managers, and users. This will include answering the following questions: - Why would anyone run IPv6 now? - Why would anyone ever run IPv6? - Who will deploy IPv6 first? - Will the Internet lead Corporate networks or follow as IPv6 is deployed? - How to get ISPs to deploy IPv6? Agenda: (1) Existing deployment efforts: - 6BONE (who?) - 6REN (who?) (2) Potential efforts: - IPv6 Exchanges (who?) - Corporate Plans (who?) - ISP Plans (who?) - ... (3) Promotion - IPv6.org (who?) - Influencing developers, vendors, etc. (who?) ---------------------------------------------------------------- ---------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 6 20:37:32 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id UAA29022 for ipng-dist; Wed, 6 Jan 1999 20:29:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id UAA29001; Wed, 6 Jan 1999 20:26:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA11228; Wed, 6 Jan 1999 20:26:03 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA21389; Wed, 6 Jan 1999 20:26:04 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id XAA26947; Wed, 6 Jan 1999 23:26:58 -0500 (EST) Received: from bywasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA05077; Wed, 6 Jan 1999 23:26:00 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id XAA0000015025; Wed, 6 Jan 1999 23:26:00 -0500 (EST) From: Jim Bound Message-Id: <199901070426.XAA0000015025@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, Bob Fink , Steve Deering , Tony Hain , bound@zk3.dec.com Subject: (IPng 7022) Re: Draft Agenda for IPng/NGTRANS Interim Meeting In-Reply-To: Your message of "Wed, 06 Jan 1999 18:08:42 PST." <3.0.5.32.19990106180842.009fc310@mailhost.iprg.nokia.com> Date: Wed, 06 Jan 1999 23:25:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Looks real good and worthwhile... even more than I was hoping for. Please add time on the third day to give all an update on our new IPv6 Deployment Mail lists and other things we are doing with WEB Servers, Mail Lists, and Pub Domain software. Perry Metzger and I are leading this and one or both of us will present what the status is (Perry if you are not going I am and we can talk offline). This is not an IETF function so I will stop talking about this here. I will send a short update and what we are doing for those interested real soon !!!! Also this work is different to the work I hear you, Bob and others are doing, for the benefit of the WG (e.g. 6REN, Registries). We all should probably have an agenda item to discuss what each of us are doing so we don't step on each other. When I sent the mail about the Gathering in Orlando all of a sudden I got tons of updates from folks on offline work others are doing and happenings. I highly suggest we communicate better about such acitivities that are not an official role/mission of the IETF where the Chairs, Internet ADs, etc have more control. In this arena that is not the case and we are dealing with a different beast. Coordination is key to making IPv6 get deployed. We should at least all be pushing the vectors in the same direction, but not necessarily with the same acceleration. I say this to set my feelings about the tone for the 3rd day. Especially regarding IETF politics regarding the deployment of IPv6, which really does not have a place for this meeting or should hinder it in "any way". On the third day there really are no kings. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 7 07:13:32 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA29268 for ipng-dist; Thu, 7 Jan 1999 07:03:38 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id GAA29243; Thu, 7 Jan 1999 06:59:23 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA29865; Thu, 7 Jan 1999 06:59:19 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA24865; Thu, 7 Jan 1999 06:59:19 -0800 (PST) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id KAA28003; Thu, 7 Jan 1999 10:00:14 -0500 (EST) Received: from bywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA19675; Thu, 7 Jan 1999 09:59:16 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id JAA0000001303; Thu, 7 Jan 1999 09:59:15 -0500 (EST) From: Jim Bound Message-Id: <199901071459.JAA0000001303@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu Cc: scoya@cnri.reston.va.us, iab@isi.edu, v6-deployment-cabal@alpha.zk3.dec.com Subject: (IPng 7023) ACTION: IETF 44 March Meeting 6bone connect in the terminal room Date: Thu, 07 Jan 1999 09:59:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 Folks, It has come to my attention that Matt Holderidge from Ascend has relayed to one of my folks that IPv6 for the 6bone in the IETF 44 Meeting Terminal room is not getting requested. Can you all please begin to send mail to Matt (matt@ascend.com) that we want IPv6 in the terminal room at Minneapolis. I don't think all IETF meeting terminal rooms should have access to the IPv6 6bone and new IPv6 backbone networks we may see by March 99. Please let Matt hear from you. Compaq is reviewing now if we can support IPv6 capable UNIX servers in the terminal room now to support IPv6 and why I heard this news. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 7 08:02:49 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA29365 for ipng-dist; Thu, 7 Jan 1999 07:57:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA29344; Thu, 7 Jan 1999 07:53:08 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA19062; Thu, 7 Jan 1999 07:53:04 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA24549; Thu, 7 Jan 1999 07:53:04 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id KAA02994; Thu, 7 Jan 1999 10:54:00 -0500 (EST) Received: from bywasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA07680; Thu, 7 Jan 1999 10:53:01 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id KAA0000010720; Thu, 7 Jan 1999 10:52:58 -0500 (EST) From: Jim Bound Message-Id: <199901071552.KAA0000010720@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Jim Bound Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu, scoya@cnri.reston.va.us, iab@isi.edu, v6-deployment-cabal@alpha.zk3.dec.com, bound@zk3.dec.com Subject: (IPng 7025) Re: ACTION: IETF 44 March Meeting 6bone connect in the terminal room In-Reply-To: Your message of "Thu, 07 Jan 1999 09:59:15 EST." <199901071459.JAA0000001303@wasted.zk3.dec.com> Date: Thu, 07 Jan 1999 10:52:58 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I don't think all IETF meeting terminal rooms should have access to >the IPv6 6bone and new IPv6 backbone networks we may see by March 99. Typo: Should be: I think all IETF meeting terminal rooms should have access to the IPv6 6bone and new IPv6 backbone networks we may see by March 99. Too early in the a.m. --------) /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 7 08:03:11 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA29342 for ipng-dist; Thu, 7 Jan 1999 07:52:29 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA29335; Thu, 7 Jan 1999 07:52:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA08825; Thu, 7 Jan 1999 07:52:15 -0800 Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA24077; Thu, 7 Jan 1999 07:52:14 -0800 (PST) Received: from classic (riq-129-120.riq.qc.ca [199.84.129.120]) by jazz.viagenie.qc.ca (Viagenie/8.8.8) with SMTP id KAA22269; Thu, 7 Jan 1999 10:43:57 -0500 (EST) Prefer-Language: fr, en Message-Id: <4.1.19990107102955.01395730@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 07 Jan 1999 10:48:29 -0500 To: bound@wasted.zk3.dec.com From: Marc Blanchet Subject: (IPng 7024) Re: (ngtrans) ACTION: IETF 44 March Meeting 6bone connect in the terminal room Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu, scoya@cnri.reston.va.us, iab@isi.edu, v6-deployment-cabal@alpha.zk3.dec.com, matt@ascend.com, 6pop@viagenie.qc.ca In-Reply-To: <199901071459.JAA0000001303@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by earth.sun.com id HAA24077 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id HAB29336 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:59 99-01-07 -0500, Jim Bound wrote: >IPv6 Folks, Jim, since we provided the ipv6 connectivity to the ietf terminal room since the last 2 ietfs, I will take care of this offline with Matt. We have some stats on the use of v6 at the next ietf. >I don't think all IETF meeting terminal rooms should have access to >the IPv6 6bone and new IPv6 backbone networks we may see by March 99. I surely think that we must provide ipv6 connectivity to all ietf terminal rooms. I'm really surprised to see this comment from you. I think the first place where ipv6 should be demonstrated fully is at the ietf. I would like to challenge people that for the next ietf, we will be able to do all our work during ietf in ipv6-only: i.e. email,web,ftp,... (yes, our company will put soon our production mail server on v6 with pop, sendmail,..., we already have the normos site on v6 (try it with a AAAA record http://www.normos.org) so all rfcs,internet-drafts,... are accessible on v6),... We also arranged to mirror the 6bone web site on v6 (try: http://www.6bone.net with a AAAA record). At least, the guys from our company will use v6-only during the next ietf. Any other takers? At 09:59 99-01-07 -0500, Jim Bound wrote: >IPv6 Folks, > >It has come to my attention that Matt Holderidge from Ascend has relayed >to one of my folks that IPv6 for the 6bone in the IETF 44 Meeting >Terminal room is not getting requested. > >Can you all please begin to send mail to Matt (matt@ascend.com) that we >want IPv6 in the terminal room at Minneapolis. > >I don't think all IETF meeting terminal rooms should have access to >the IPv6 6bone and new IPv6 backbone networks we may see by March 99. > >Please let Matt hear from you. Compaq is reviewing now if we can >support IPv6 capable UNIX servers in the terminal room now to support >IPv6 and why I heard this news. At the last ietf, Compaq already supported the unix servers in v6. Mary did that. > >thanks >/jim Regards, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.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 Thu Jan 7 08:03:31 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA29374 for ipng-dist; Thu, 7 Jan 1999 07:59:14 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA29367; Thu, 7 Jan 1999 07:59:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09459; Thu, 7 Jan 1999 07:58:59 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA27859; Thu, 7 Jan 1999 07:58:59 -0800 (PST) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id KAA10575; Thu, 7 Jan 1999 10:59:54 -0500 (EST) Received: from bywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA29507; Thu, 7 Jan 1999 10:58:55 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id KAA0000015911; Thu, 7 Jan 1999 10:58:54 -0500 (EST) From: Jim Bound Message-Id: <199901071558.KAA0000015911@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Marc Blanchet Cc: bound@wasted.zk3.dec.com, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu, scoya@cnri.reston.va.us, iab@isi.edu, v6-deployment-cabal@alpha.zk3.dec.com, matt@ascend.com, 6pop@viagenie.qc.ca, bound@zk3.dec.com Subject: (IPng 7026) Re: (ngtrans) ACTION: IETF 44 March Meeting 6bone connect in the terminal room In-Reply-To: Your message of "Thu, 07 Jan 1999 10:48:29 EST." <4.1.19990107102955.01395730@mail.viagenie.qc.ca> Date: Thu, 07 Jan 1999 10:58:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marc, Sorry it was a typo I sent correction. I had initially written it with NOT clause and "don't" would have been applicable in the sentence. I removed all but the "don't" and it was a typo. I agree with you. ALso I think IPv6 should be on the link in the terminal room too. Also any routers shoulid be supporting the dual-stack at this time. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 7 08:34:17 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA29533 for ipng-dist; Thu, 7 Jan 1999 08:25:09 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA29526; Thu, 7 Jan 1999 08:24:55 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA23686; Thu, 7 Jan 1999 08:24:48 -0800 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA14070; Thu, 7 Jan 1999 08:24:48 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W/smtpfeed 0.89) with ESMTP id BAA03404; Fri, 8 Jan 1999 01:24:40 +0900 (JST) To: Marc Blanchet cc: bound@wasted.zk3.dec.com, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu, scoya@cnri.reston.va.us, iab@isi.edu, v6-deployment-cabal@alpha.zk3.dec.com, matt@ascend.com, 6pop@viagenie.qc.ca In-reply-to: Marc.Blanchet's message of Thu, 07 Jan 1999 10:48:29 EST. <4.1.19990107102955.01395730@mail.viagenie.qc.ca> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 7027) Re: (ngtrans) ACTION: IETF 44 March Meeting 6bone connect in the terminal room From: Jun-ichiro itojun Hagino Date: Fri, 08 Jan 1999 01:24:40 +0900 Message-ID: <3400.915726280@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I surely think that we must provide ipv6 connectivity to all ietf terminal >rooms. I'm really surprised to see this comment from you. I think the >first place where ipv6 should be demonstrated fully is at the ietf. > I would like to challenge people that for the next ietf, we will be able >to do all our work during ietf in ipv6-only: i.e. email,web,ftp,... (yes, >our company will put soon our production mail server on v6 with pop, >sendmail,..., we already have the normos site on v6 (try it with a AAAA >record http://www.normos.org) so all rfcs,internet-drafts,... are >accessible on v6),... > We also arranged to mirror the 6bone web site on v6 (try: >http://www.6bone.net with a AAAA record). > > At least, the guys from our company will use v6-only during the next ietf. >Any other takers? Of course we will! Actually, in Japan's case it is much confortable to cross the ocean by IPv6 than by IPv4. We used IPv6 to reach hosts in Japan during IETF43. We got a translator box in our NOC, as a last resort (so that we can cross the ocean by IPv6 and then contact IPv4 host in Japan). This approach worked quite well for IETF42 and 43, and we hope to continue and expand "IPv6 from terminal room" approach. itojun@kame -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 7 10:15:50 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id KAA29665 for ipng-dist; Thu, 7 Jan 1999 10:04:04 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id KAA29658; Thu, 7 Jan 1999 10:03:39 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA01064; Thu, 7 Jan 1999 10:03:37 -0800 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA22412; Thu, 7 Jan 1999 10:03:32 -0800 (PST) Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA20433; Thu, 7 Jan 1999 18:55:41 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id SAA10714; Thu, 7 Jan 1999 18:55:39 +0100 Date: Thu, 7 Jan 1999 18:55:39 +0100 Message-Id: <199901071755.SAA10714@dumbo.fokus.gmd.de > To: hinden@iprg.nokia.com, bound@wasted.zk3.dec.com Subject: (IPng 7028) Re: Draft Agenda for IPng/NGTRANS Interim Meeting Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, rlfink@lbl.gov, deering@cisco.com, tonyhain@microsoft.com, bound@zk3.dec.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu Jan 7 05:41:47 1999 Jim Bound wrote: > Coordination is key to making IPv6 get deployed. Maybe this should become an item for the 3rd day's agenda: existing and needed coordination efforts? Regards Michael -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 7 10:34:42 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id KAA29757 for ipng-dist; Thu, 7 Jan 1999 10:24:18 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id KAA29718; Thu, 7 Jan 1999 10:20:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA03755; Thu, 7 Jan 1999 10:20:29 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA04133; Thu, 7 Jan 1999 10:20:28 -0800 (PST) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id TAA24615; Thu, 7 Jan 1999 19:20:24 +0100 (MET) Message-Id: <199901071820.TAA24615@imag.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 07 Jan 1999 19:19:19 +0100 To: 6bone@isi.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Alain Durand Subject: (IPng 7029) Grenoble interim IETF social event Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi alll. The agenda is now online on http://www.ipv6.imag.fr/ietf1999.html. Also, I'm pleased to announce that we will have a social event on tuesday evening. Places are limited to 50 only... sorry about that, so they'll go to the first 50 who will register. Be quick! More on this social event on the web server. To register to the social, send e-mail to ietf@imag.fr - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 7 13:52:38 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id NAA29986 for ipng-dist; Thu, 7 Jan 1999 13:40:28 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id NAA29979 for ; Thu, 7 Jan 1999 13:39:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA07900 for ; Thu, 7 Jan 1999 13:39:02 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA19005 for ; Thu, 7 Jan 1999 13:39:01 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id NAA24208; Thu, 7 Jan 1999 13:37:25 -0800 (PST) Message-Id: <3.0.5.32.19990107133519.00ae2100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 07 Jan 1999 13:35:19 -0800 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: (IPng 7031) Request to Advance "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6" Cc: 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@sunroof.eng.sun.com Precedence: bulk Jeff, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 Author(s) : M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang Filename : draft-ietf-ipngwg-esd-analysis-03.txt Pages : 50 Date : 20-Nov-98 A working group last call for this document was completed on January 4, 1999. No comments were received. 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 Thu Jan 7 14:11:40 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id NAA00008 for ipng-dist; Thu, 7 Jan 1999 13:54:50 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id NAA29997 for ; Thu, 7 Jan 1999 13:54:24 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA11038 for ; Thu, 7 Jan 1999 13:54:22 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA29493 for ; Thu, 7 Jan 1999 13:54:22 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id NAA24771; Thu, 7 Jan 1999 13:52:40 -0800 (PST) Message-Id: <3.0.5.32.19990107135156.0092b770@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 07 Jan 1999 13:51:56 -0800 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: (IPng 7032) Request to Advance RFC2373 and RFC2374 to Draft Standard Cc: 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@sunroof.eng.sun.com Precedence: bulk Jeff, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following documents be published as Draft Standards: RFC2373 IP Version 6 Addressing Architecture RFC2374 An Aggregatable Global Unicast Address Format An implementation report for these RFC's is available at: ftp://playground.sun.com/pub/ipng/implementation-reports as: add-arch-aggregat.txt A working group last call for this document was completed on January 4, 1999. No comments were received. Advancing these documents to draft standard was also discussed at the Orlando IETF meeting. 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 Thu Jan 7 14:11:37 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id OAA00017 for ipng-dist; Thu, 7 Jan 1999 14:02:02 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id OAA00010 for ; Thu, 7 Jan 1999 14:01:49 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA02724 for ; Thu, 7 Jan 1999 14:01:46 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA04749 for ; Thu, 7 Jan 1999 14:01:46 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id OAA25045; Thu, 7 Jan 1999 14:00:12 -0800 (PST) Message-Id: <3.0.5.32.19990107135928.00ac2620@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 07 Jan 1999 13:59:28 -0800 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: (IPng 7033) Request to Advance "Basic Socket Interface Extensions for IPv6" Cc: 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@sunroof.eng.sun.com Precedence: bulk Jeff, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-new-05.txt Pages : 33 Date : 05-Jan-99 This document replaces RFC2133. RFC2133 should become Historical. A working group last call for this document was completed on November 3, 1998 and this document was discussed at the IPng session at the Orlando IETF. The current draft (-05) incorporates comments received during the 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 Fri Jan 8 09:39:01 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA00881 for ipng-dist; Fri, 8 Jan 1999 09:28:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id JAA00874; Fri, 8 Jan 1999 09:27:58 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA12096; Fri, 8 Jan 1999 09:27:55 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA06879; Fri, 8 Jan 1999 09:27:56 -0800 (PST) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id MAA31019; Fri, 8 Jan 1999 12:28:51 -0500 (EST) Received: from bywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA08752; Fri, 8 Jan 1999 12:27:51 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000023386; Fri, 8 Jan 1999 12:27:46 -0500 (EST) From: Jim Bound Message-Id: <199901081727.MAA0000023386@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Matt Holdrege Cc: Marc Blanchet , bound@wasted.zk3.dec.com, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu, scoya@cnri.reston.va.us, iab@isi.edu, v6-deployment-cabal@alpha.zk3.dec.com, 6pop@viagenie.qc.ca Subject: (IPng 7034) Re: (ngtrans) ACTION: IETF 44 March Meeting 6bone connect in the terminal room In-Reply-To: Your message of "Thu, 07 Jan 1999 11:03:31 PST." <3.0.5.32.19990107110331.00bd16f0@porky> Date: Fri, 08 Jan 1999 12:27:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK Matt 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 Fri Jan 8 18:26:14 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id SAA02376 for ipng-dist; Fri, 8 Jan 1999 18:15:07 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id SAA02369 for ; Fri, 8 Jan 1999 18:14:54 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA15630 for ; Fri, 8 Jan 1999 18:14:55 -0800 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA20117 for ; Fri, 8 Jan 1999 18:14:55 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Fri, 8 Jan 1999 18:14:55 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81A6E@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: "'IPng List'" Subject: (IPng 7036) Re: route distribution via ND Date: Fri, 8 Jan 1999 18:14:54 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Correct (at least in principle). > I didn't understand what you meant by "virtual". > What I was trying to point out that that while the definition for > multihomed is >1 IPv6 address it is really the number of interfaces > that creates an issue. The definition of multihomed in Appendix A of the ND spec is >1 interface. > But in your specific case (an ethernet and a 6-over-4 > interface) it would make > most sense to only use one of those at a time. > One way of implementing this would be: > When the host finds a default router on the ethernet it would > effectively turn off (or at least stop transmitting on) > the 6-over-4 > interface. > When there are no default routers on the ethernet (or > no non-link-local > addresses assigned to the ethernet interface) it would > switch back > to transmitting on the 6-over-4 interface. > [I personally think preferring the ethernet over > 6-over-4 since it > avoids encapsulating overhead as well as reduces IPv4 multicast > traffic.] I think there are scenarios (not too contrived I hope) where that heuristic would fail. For example: A site first starts experimenting with v6. It installs a router R1 on an ethernet that speaks both v4 and v6. The router R1 has a tunnel to the 6bone. Inside the site, the router R1 advertises on its ethernet interface and on a 6-over-4 interface. Over time dual-stack hosts H are installed in the site. The hosts H hear R1's router advertisements via their 6-over-4 interface. If a host H is on the same ethernet as R1, then it also hears R1's router advertisements on its ethernet interface. So far everything works with your heuristic. Now the site tries experimenting with v6-only machines. It installs a router R2 that only speaks v6. Routers R1 and R2 are not directly connected via a link. Router R2 connects some hosts H1 that only speak v6 and some hosts H2 that are dual-stack. Consider a host H2 that is directly connected via ethernet to router R2, but not directly connected to router R1. On its ethernet interface H2 hears advertisements from R2. On its 6-over-4 interface H2 hears advertisements from R1. Now host H2 wants to send a packet to host H1, a v6-only node that is reachable via R2. How does H2 know to send the packet to R2 instead of R1? Note that R1 can not forward the packet to R2 - there is no v4 or v6 connectivity between R1 and R2. > But that doesn't change my basic argument: there will be pressure to > ensure that your new ND option has all the features and capabilities > of RIPng. Why invent a new packet/option format when RIPng can be used > for this today? 1. Architectural simplicity. Why have two mechanisms for communicating information from routers to hosts, with the resulting increases in code complexity & packet overhead? 2. RIPng is missing lifetimes on routes. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 11 06:35:16 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id GAA03544 for ipng-dist; Mon, 11 Jan 1999 06:19:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id GAA03534; Mon, 11 Jan 1999 06:18:57 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA03803; Mon, 11 Jan 1999 06:18:53 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA27096; Mon, 11 Jan 1999 06:18:55 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id JAA20707; Mon, 11 Jan 1999 09:18:52 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA22433; Mon, 11 Jan 1999 09:18:50 -0500 Message-Id: <199901111418.AA22433@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu Subject: (IPng 7038) V6-Deployment Gathering Minutes Date: Mon, 11 Jan 1999 09:18:50 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, If you want to get involved with this list you can join by sending mail to majrodomo@alpha.zk3.dec.com by subscribing to v6-deployment-cabal list. This should not replace the purpose of the v6imp list. /jim ---------------------- Return-Path: bound@alpha.zk3.dec.com Received: from bryalpha.zk3.dec.com by mailhub2.zk3.dec.com (5.65v4.0/1.1.10.5/24Sep96-0323PM) id AA05631; Mon, 11 Jan 1999 09:11:29 -0500 Received: by alpha.zk3.dec.com (8.8.8/1.1.8.2/18Feb95-1123AM) id JAA0000025487; Mon, 11 Jan 1999 09:10:35 -0500 (EST) Received: from quarry.zk3.dec.com by alpha.zk3.dec.com (8.8.8/1.1.8.2/18Feb95-1123AM) id JAA0000020829; Mon, 11 Jan 1999 09:10:34 -0500 (EST) From: Jim Bound Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA20816; Mon, 11 Jan 1999 09:10:34 -0500 Message-Id: <199901111410.AA20816@quarry.zk3.dec.com> To: v6-deployment-cabal@alpha.zk3.dec.com Subject: High-Level Minutes from the Gathering Date: Mon, 11 Jan 1999 09:10:34 -0500 X-Mts: smtp Sender: owner-v6-deployment-cabal@alpha.zk3.dec.com Precedence: bulk Reply-To: Jim Bound Folks, Here is my recollection of the high-points of the gathering. Please send me bullets and additions OK. Critical reqs for IPv6 deployment: Vendors must deploy IPv6 in base products: Required First Stage deployment needs: 1) IPv6 stack supporting core specs 2) Transition Mechanisms (1933-update) and V6overV4 Tunnels 3) RIPng and BGP4+ (for forwarding) 4) AAAA Records for now 5) WEB Server and Browser 6) Basic API 7) Basic Network Utilities (ping, ifconfig, netstact, tcpdump) 8) FTP and TELNET 9) Email via Sendmail We need to discuss this list more in depth on the mail list and sub-bullet requirements. We need to define additional stages of deployment and transition scenarios. What time-frames can Host and Routers vendors commit to now? Need to discuss the business reasons for IPv6 and killer apps that will benefit. What key features do ISPs need? What key features do commercial end users need? What key features do highly-technical end users need? What applicatons are critical path to be ported supported by VENDORS? ISVs? FREE-WARE APPS? We need to set up an intense technical grass roots movement? Perry Metzger suggested this and will try to set up mail lists and coordinate IPv6 servers within the technical community. We will have another mail list called v6-lovers which will be for the entire world to discuss the needs of IPv6 for deployment. This will be our first priority and this list will feed future requirements and bugs, etc... Comment was we need real customers on this list too. We need to coordinate efforts in the IPv6 community to get IPv6 deployed by sharing information across the board. We will need "how to" for transition mechanisms. /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 Jan 11 07:51:07 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA03709 for ipng-dist; Mon, 11 Jan 1999 07:41:50 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA03688; Mon, 11 Jan 1999 07:38:06 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA22259; Mon, 11 Jan 1999 07:38:04 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA18758; Mon, 11 Jan 1999 07:38:04 -0800 (PST) Received: from pinnacle (131.243.212.204) by cnrmail.lbl.gov with SMTP (Eudora Internet Mail Server 2.1); Mon, 11 Jan 1999 07:38:00 -0800 Message-Id: <4.1.19990111071751.00a326c0@cnrmail.lbl.gov> X-Sender: rlfink@cnrmail.lbl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 11 Jan 1999 07:37:39 -0800 To: ngtrans@sunroof.eng.sun.com, IPng List From: Bob Fink Subject: (IPng 7039) IPng Interim meeting 3rd day Cc: Tony Hain , Steve Deering , Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We (the IPng and NGtrans chairs) have asked Jim Bound to organize and chair the 3rd day of the interim meetings in Grenoble (the portion on IPv6 Deployment and Promotion). This should help spread the work load out and get other points of view included as well. Please give Jim your help in making this day a success! Thanks, Bob Fink NGtrans co-chair === Thursday, February 4 -- IPv6 Deployment and Promotion ----------------------------------------------------- The purpose of this day will be to review current deployment activities, potential additional efforts, and opportunities for educating and influencing developers, ISPs, network managers, and users. This will include answering the following questions: - Why would anyone run IPv6 now? - Why would anyone ever run IPv6? - Who will deploy IPv6 first? - Will the Internet lead Corporate networks or follow as IPv6 is deployed? - How to get ISPs to deploy IPv6? Agenda: (1) Existing deployment efforts: - 6BONE (who?) - 6REN (who?) (2) Potential efforts: - IPv6 Exchanges (who?) - Corporate Plans (who?) - ISP Plans (who?) - ... (3) Promotion - IPv6.org (who?) - Influencing developers, vendors, etc. (who?) ---------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 11 10:12:07 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA03895 for ipng-dist; Mon, 11 Jan 1999 09:51:28 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id JAA03888 for ; Mon, 11 Jan 1999 09:51:22 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id JAA24731 for ; Mon, 11 Jan 1999 09:51:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA21980 for ipng@sunroof.eng.sun.com; Mon, 11 Jan 1999 09:50:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id BAA03019 for ; Sun, 10 Jan 1999 01:55:21 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA20875 for ; Sun, 10 Jan 1999 01:55:20 -0800 Received: from idsc1.gov.eg (IDSC1.GOV.EG [163.121.2.224]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA07741 for ; Sun, 10 Jan 1999 01:55:19 -0800 (PST) Received: from hossam (subnet15.idsc.gov.eg [163.121.15.7] (may be forged)) by idsc1.gov.eg (8.8.8/8.8.8) with SMTP id LAA02520 for ; Sun, 10 Jan 1999 11:52:52 +0200 (EET) Message-ID: <000301bd1dad$dd841310$070f79a3@hossam> From: "Hossam El-Ashkar" To: "IPv6 Sun" Subject: (IPng 7040) ipv6 inetd Date: Sat, 10 Jan 1998 11:55:20 +0200 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.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a question about the inetd in the IPv6 stack ver. 5.3 . I have noticed that it does not respond to a HUP message. In the ordinary stack, when any of the configuration changes we just send a HUP signal to the process to reread its conf. file. In the v6 version, we need to restart it all over. Is there any other limitations?? Hossam El-Ashkar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 11 19:23:14 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id TAA04334 for ipng-dist; Mon, 11 Jan 1999 19:05:45 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id TAA04310; Mon, 11 Jan 1999 19:00:09 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA17127; Mon, 11 Jan 1999 19:00:07 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA15056; Mon, 11 Jan 1999 19:00:07 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id WAA15449; Mon, 11 Jan 1999 22:00:02 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA12901; Mon, 11 Jan 1999 22:00:01 -0500 Message-Id: <199901120300.AA12901@quarry.zk3.dec.com> To: ngtrans@sunroof.eng.sun.com Cc: IPng List , Tony Hain , Steve Deering , Bob Hinden , bound@zk3.dec.com Subject: (IPng 7041) Re: (ngtrans) IPng Interim meeting 3rd day In-Reply-To: Your message of "Mon, 11 Jan 1999 07:37:39 PST." <4.1.19990111071751.00a326c0@cnrmail.lbl.gov> Date: Mon, 11 Jan 1999 22:00:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Could I ask for folks who would be willing to present ideas on the attached topics or do you want to leave this as an "open forum" for discussion? For some of the attached presenters would be very good I have put an asterik by the ones we really should have a presenter for especially if you have been doing work in this space. In addition I would like to ask if the vendors coming would provide an update regarding their plans for IPv6 (Sun, Cisco, Compaq, Microsoft, HP, Bay, etc...). I think a 10 minute 4 slide presentation would be really beneficial for the third day as shipping IPv6 is pretty key to IPv6 success. Other agenda items welcome as always.. One I can think if is the status of public domain code like Sendmail, Mozilla, Mobility, or Service Location for IPv6. Another is "Are there any IPv6 Killer Applications that will shine far better over IPv4"? === Thursday, February 4 -- IPv6 Deployment and Promotion ----------------------------------------------------- The purpose of this day will be to review current deployment activities, potential additional efforts, and opportunities for educating and influencing developers, ISPs, network managers, and users. This will include answering the following questions: - Why would anyone run IPv6 now? - Why would anyone ever run IPv6? - Who will deploy IPv6 first? - Will the Internet lead Corporate networks or follow as IPv6 is deployed? - How to get ISPs to deploy IPv6? Agenda: (1) Existing deployment efforts: *- 6BONE (who?) *- 6REN (who?) (2) Potential efforts: *- IPv6 Exchanges (who?) *- Corporate Plans (who?) *- ISP Plans (who?) - ... (3) Promotion *- IPv6.org (who?) *- Influencing developers, vendors, etc. (who?) ---------------------------------------------------------------- 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 Jan 11 20:40:07 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id UAA04437 for ipng-dist; Mon, 11 Jan 1999 20:27:39 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id UAA04416; Mon, 11 Jan 1999 20:23:41 -0800 (PST) From: bmanning@ISI.EDU Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA17523; Mon, 11 Jan 1999 20:23:41 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA17797; Mon, 11 Jan 1999 20:23:41 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id UAA23915; Mon, 11 Jan 1999 20:23:38 -0800 (PST) Posted-Date: Mon, 11 Jan 1999 20:16:21 -0800 (PST) Message-Id: <199901120416.AA15008@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Mon, 11 Jan 1999 20:16:21 -0800 Subject: (IPng 7042) Re: (ngtrans) IPng Interim meeting 3rd day To: bound@zk3.dec.com Date: Mon, 11 Jan 1999 20:16:21 -0800 (PST) Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, tonyhain@microsoft.com, deering@cisco.com, hinden@iprg.nokia.com In-Reply-To: <199901120300.AA12901@quarry.zk3.dec.com> from "bound@zk3.dec.com" at Jan 11, 99 10:00:01 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@sunroof.eng.sun.com Precedence: bulk > Agenda: > (1) Existing deployment efforts: > *- 6BONE (who?) > *- 6REN (who?) > (2) Potential efforts: > *- IPv6 Exchanges (who?) Both Comapq (PAIX) and ISI (LAP) have IPv6 capable exchanges and have had for some time. > *- Corporate Plans (who?) > *- ISP Plans (who?) > - ... > (3) Promotion > *- IPv6.org (who?) > *- Influencing developers, vendors, etc. (who?) > > ---------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > -- --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 Mon Jan 11 23:52:00 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id XAA04551 for ipng-dist; Mon, 11 Jan 1999 23:38:28 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id XAA04544; Mon, 11 Jan 1999 23:38:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA11517; Mon, 11 Jan 1999 23:38:14 -0800 Received: from nttslb.slab.ntt.co.jp (nttslb.slab.ntt.co.jp [129.60.144.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA23084; Mon, 11 Jan 1999 23:38:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nttslb.slab.ntt.co.jp (8.9.1a/3.7Wpl2-99010411) with ESMTP id QAA11724; Tue, 12 Jan 1999 16:38:36 +0900 (JST) To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: (IPng 7043) request for short slot in Grenoble interim meeting. X-Mailer: Mew version 1.92 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990112163836F.ota@nttslb> Date: Tue, 12 Jan 1999 16:38:36 +0900 From: Kenji OTA X-Dispatcher: imput version 971024 Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks, At Grenoble interim meeting, I would like to have a short (about 5 minutes) slot in agenda (maybe, for NGtrans W.G.). It will be a report of our trial at the IETF-43 terminal room. In IETF-43, we, NTT, provided a 6bone connectivity from IETF43 terminal room to Japan, with the cooperation of Viagenie, Microsoft, and WIDE project. NTT has a trans-paciffic IPv6 native link between Tokyo, Japan and Cupertino, CA. U.S.A. And we established a tunnel between the terminal room and Cupertino during IETF-43. It was very successful so that we could have a comfortable IPv6 connection. My presentation will be a report of its results. Is that OK ? Regards, ---------------------------------- Kenji OTA < ota@slab.ntt.co.jp > NTT Software Labs. in Tokyo, Japan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 12 03:23:57 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id DAA04679 for ipng-dist; Tue, 12 Jan 1999 03:11:31 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id DAA04672 for ; Tue, 12 Jan 1999 03:11:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA07756 for ; Tue, 12 Jan 1999 03:11:18 -0800 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA28436 for ; Tue, 12 Jan 1999 03:11:18 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Tue, 12 Jan 1999 03:11:18 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81A96@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 7044) NS & RS with unspecified source address Date: Tue, 12 Jan 1999 03:11:16 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A warning to other implementors - I just noticed that the validation rules for Neighbor and Router Solicitations call for solicits with an unspecified source address to be discarded if there is a source link-layer address option in the message. This is a new check, introduced post-RFC1970. Prior to my just fixing it, our stack was sending all solicitations with a source link-layer address option, whether or not the source address was unspecified, because it was easier to always put it in. So this change in the spec has introduced interoperability problems. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 12 06:34:21 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id GAA04838 for ipng-dist; Tue, 12 Jan 1999 06:18:58 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id GAA04831; Tue, 12 Jan 1999 06:18:42 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA00012; Tue, 12 Jan 1999 06:18:40 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA00063; Tue, 12 Jan 1999 06:18:41 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id JAA24806; Tue, 12 Jan 1999 09:19:45 -0500 (EST) Received: from bywasted.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA16205; Tue, 12 Jan 1999 09:18:38 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id JAA0000010104; Tue, 12 Jan 1999 09:18:37 -0500 (EST) From: Jim Bound Message-Id: <199901121418.JAA0000010104@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: bmanning@ISI.EDU Cc: bound@zk3.dec.com, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, tonyhain@microsoft.com, deering@cisco.com, hinden@iprg.nokia.com Subject: (IPng 7045) Re: (ngtrans) IPng Interim meeting 3rd day In-Reply-To: Your message of "Mon, 11 Jan 1999 20:16:21 PST." <199901120416.AA15008@zed.isi.edu> Date: Tue, 12 Jan 1999 09:18:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, > *- IPv6 Exchanges (who?) Both Comapq (PAIX) and ISI (LAP) have IPv6 capable exchanges and have had for some time. Just as a note the IPv6 at Compaq Palo Alto where the IPv6 exchange exists is the Palo Alto Gateway (PAGTW) not the PAIX. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 12 10:41:37 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id KAA05175 for ipng-dist; Tue, 12 Jan 1999 10:26:28 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id KAA05168 for ; Tue, 12 Jan 1999 10:26:13 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA03359 for ; Tue, 12 Jan 1999 10:26:10 -0800 Received: from santacruz.org (noc.santacruz.org [209.133.111.168]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA00932 for ; Tue, 12 Jan 1999 10:26:10 -0800 (PST) Received: from santacruz.org (santacruz.org [209.133.111.174]) by santacruz.org (Postfix) with ESMTP id 741528A45; Tue, 12 Jan 1999 10:32:06 -0800 (PST) Date: Tue, 12 Jan 1999 10:32:06 -0800 (PST) From: Gregory Taylor To: "Dr. William Lenharth" Cc: ipv6imp@munnari.OZ.AU, audrey@vanb.com, ipng@sunroof.eng.sun.com Subject: (IPng 7048) Re: [IPv6Imp] connectathon 99 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to attend the Connect-A-Thon 1999, please send me information on doing so. Thank You, Gregory Taylor Network Security Analyst Consultant and Contract Unix Administrator SantaCruz Networks jest@santacruz.org On Tue, 12 Jan 1999, Dr. William Lenharth wrote: > This is a reminder notice: UNH will again be testing IPv6 implementations at > CONNECTATHON99 in San Jose on March 7-11, 1999. This is the week before the > IETF meeting in sunny Minneapolis. We have added over 50 new tests to our > program and will include router protocol testing. To participate you may > contact the coordinator at Audrey Van Belleghem . Please also > update us by sending mail to whl@unh.edu ! Thanks ... > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 12 20:57:10 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id UAA05751 for ipng-dist; Tue, 12 Jan 1999 20:54:22 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id UAA05744 for ; Tue, 12 Jan 1999 20:54:14 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA12964 for ; Tue, 12 Jan 1999 20:54:14 -0800 Received: from mail.cgocable.net (mail.cgocable.net [24.226.1.11]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA26784 for ; Tue, 12 Jan 1999 20:54:12 -0800 (PST) Received: from cgocable.net (cgowave-62-128.cgocable.net [24.226.62.128]) by mail.cgocable.net (8.8.7/8.8.6) with ESMTP id XAA19160 for ; Tue, 12 Jan 1999 23:54:24 -0500 (EST) Message-ID: <369C26D8.7EAB73F4@cgocable.net> Date: Tue, 12 Jan 1999 23:53:44 -0500 From: ryan elson X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 7049) RE: Ip addresses---okay...It's nice to listen to.. References: <3.0.5.32.19990107135928.00ac2620@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's nice to see how IP is evolving. Although I have a little dillemma that needs fixing, and I'm sure that there's somebody (probably everybody) that knows the answer to this----A good reason for posting this message eh? Anyways, I'm setting up a small network, although my stupid ISP isn't being helpful, nor do they wish to return any of the emails requesting a static IP address. Well that means that I won't deal with my ISP. Next thought was to look and see how I might actually obtain the rights to a few compliant IP addresses myself---I looked in a tcp/ip book, and low and behold, I was instructed to send an email to Hostmaster@internic.net---The book said, "send message requesting further informatio" Well it turned out that internic is pretty deaf too. How do I get a few Static IP addresses, without making them up, or borrowing them off somebody---and the second part---If internic does do this, is there an address that I might contact, or a site to see, that would be faster at obtaining this goal? I'm from canada, so is there any particular agency (or agencies) that I should be dealing with? I've been emailing internic, everyday for the past two weeks, because I want my network to be online (While it may look like spam now, it wasn't for the first month and a half of waiting that I did). While internic may think that they can do this at their own convienience, my patience with them has already worn thin. Actually I'm downright furious with them---and I'm surprised that I haven't sent them any nasty emails. So can somebody please help me..... Bob Hinden wrote: > Jeff, Thomas, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as an > Informational RFC: > > Title : Basic Socket Interface Extensions for IPv6 > Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens > Filename : draft-ietf-ipngwg-bsd-api-new-05.txt > Pages : 33 > Date : 05-Jan-99 > > This document replaces RFC2133. RFC2133 should become Historical. > > A working group last call for this document was completed on November 3, > 1998 and this document was discussed at the IPng session at the Orlando > IETF. The current draft (-05) incorporates comments received during the > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 13 00:16:02 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id AAA05856 for ipng-dist; Wed, 13 Jan 1999 00:10:48 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id AAA05849 for ; Wed, 13 Jan 1999 00:10:39 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA27561 for ; Wed, 13 Jan 1999 00:10:40 -0800 Received: from mail.cgocable.net (mail.cgocable.net [24.226.1.11]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA06165 for ; Wed, 13 Jan 1999 00:10:39 -0800 (PST) Received: from cgocable.net (cgowave-62-128.cgocable.net [24.226.62.128]) by mail.cgocable.net (8.8.7/8.8.6) with ESMTP id DAA03065 for ; Wed, 13 Jan 1999 03:04:25 -0500 (EST) Message-ID: <369C52F9.BE2C3768@cgocable.net> Date: Wed, 13 Jan 1999 03:02:02 -0500 From: ryan elson X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "ipng@sunroof.Eng.Sun.COM" Subject: (IPng 7051) Re: Ip addresses---okay...It's nice to listen to.. References: <369C26D8.7EAB73F4@cgocable.net> <199901130708.CAA14572@mail.cgocable.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm using a cable modem---not a phone line. And I also plan on adding more connections via cable modems. The simple fact is, is that I can get the equivalent to a T1 line for only $280CDN /month this way----which is much more reasonable than having to install new lines and pay higher monthly fees.---the network I'm on uses DHCP for almost everything (except for their servers and supposedly (this is what they told me) people with mac's (as in apple, not media access control) get static addresses)---They also do not use a proxy or gateway to reduce the amount of IP addresses being used (why bother---the @home network has a class B network)---anyways...If I keep goin this email's gunna be too lengthy. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 13 01:37:38 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id BAA05914 for ipng-dist; Wed, 13 Jan 1999 01:34:50 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id BAA05907 for ; Wed, 13 Jan 1999 01:34:40 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA02317 for ; Wed, 13 Jan 1999 01:34:39 -0800 Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA03933 for ; Wed, 13 Jan 1999 01:34:39 -0800 (PST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id SAA27770 for ; Wed, 13 Jan 1999 18:34:38 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA16069 for ; Wed, 13 Jan 1999 18:34:38 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA23903 for ; Wed, 13 Jan 1999 18:34:37 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 7052) new multi-home technologies From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94b2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990113183424T.kazu@iijlab.net> Date: Wed, 13 Jan 1999 18:34:24 +0900 X-Dispatcher: imput version 981124(IM104) Lines: 293 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, As I personally promised to Bob Fink, I wrote up technical memo on muli-homed sites in the IPv6 environment. I hope that this will be a big advantage of IPv6 against IPv4. Due to work of Ph. D thesis, I won't fly to France. So, Junichiro (itojun) Hagino (whose previous family name was Itoh) will talk this topic in the next interim meeting. Please update the agendas. > Alain --Kazu Multi-homed Sites in the IPv6 Environment Kazu Yamamoto kazu@iijlab.net IIJ Research Laboratory / KAME Project January 1999 0. Introduction Multi-homing technologies are important to implement robust connectivities, load balancing, migration from one provider to another, etc. For multi-homed environment, the following goals should be achieved: - Maintaining the Internet architecture including bidirectional communication (no more NAT) - No expansion of routing tables in provider routers. - Robustness (multiple exits, no single point of failure) - Making an outgoing link and an incoming link equal for communication crossing site boundary. - Load balancing between connected providers This memo first explains the current multi-homing technologies in the IPv4 environment. Advantages and disadvantages are analyzed for two typical sites, with and without NAT. Both the cases cannot achieve all goals above. Then this memo proposes new multi-homing technologies for IPv6 , which achieve all goals above. The proposed technologies include site router extensions to maintain multiple default routes and site node extensions to select an IPv6 address pair. This memo doesn't talk about policy routing in the Internet. It's providers' problems and outside the scope. 1 Multi-homed Sites in the IPv4 Environment The following two sub-sections discuss advantages and disadvantages of multi-homing technologies in the IPv4 environment. To make discussion simple, the figures below assume that provider "P" and "Q" have aggregated CIDR blocks only. 1.1 Multi-homed Sites without NAT Figure 1 illustrates multi-homed sites without NAT in the IPv4 environment. "P" is a primary provider. "Q" is a secondary provider. "x" is a node outeside of Site A. "r1", "r2", and "r3" are site routers. "p" is a node in Site A whose address is assigned by "P". Note that typical IPv4 node has just one address per network interface. Figure 1 Site A #=============# P --#-- r1 # +--------+/ # \ # x --|Internet| # r3 -- p # +--------+\ # / # Q --#-- r2 # #=============# To implement multi-homing, it is necessary to announce the specific routing information for "p" to "Q". Advantages in this technologies are as follows: - Routing is robust thanks to multiple exits. - The Internet architecture including bidirectional communication is maintained. Disadvantages in this technologies are as follows: - Expansion of routing tables in provider routers. - Given a connection, the outgoing link from the site and the incoming link to the site are possibly different. For example, a packet (src=p, dst=x) may go through "P" but a responding packet (x, p) may go through "Q" according to the longest match. 1.2 Multi-homed Sites with NAT Figure 2 illustrates multi-homed sites with NAT in the IPv4 environment. "P" and "Q" are providers. "x" is a node outeside of Site B. "s" is a node in Site B whose address is private. "n" is a NAT router which has addresses "p" and "q" from "P" and "Q", respectively. Note that "n" itself has the links to the providers. Figure 2 Site B #===============# P --#-- # +--------+/ # \ # x --|Internet| # n -- s # +--------+\ # / # Q --#-- # #===============# In this topology, given an outgoing packet, NAT first selects an outgoing link. Then NAT translates the source address with the address allocated by the provider which provides the selected link. For example, if "n" forwards a packet to "P", the source address is converted to "p". Advantages in this technologies are as follows: - No expansion of routing tables in provider routers. - Given a connection, the outgoing link from the site and the incoming link to the site are the same. Disadvantages in this technologies are as follows: - NAT is a single point of failure. - All disadvantages of NAT including loss of bidirectional communication. 2. Multi-homed Sites in the IPv6 Environment This section proposes new multi-homing technologies for IPv6. Assumptions are as follows: (a) All site nodes have multiple IPv6 addresses from the providers for the site. (Aggregatable addresses are used.) (b) NAT is not used. Figure 3 illustrates a typical site with the assumptions. Figure 3 Site C #=================# P --#-- r1 # +--------+/ # \ # --|Internet| # r3 -- # +--------+\ # / # Q --#-- r2 # / #=================# q1 Our goals are: (1) No expansion of routing tables in provider routers. (2) For communication crossing the site boundary, the outgoing link from the site and the incoming link to the site should be the same. (3) If a site node communicates with another node in one of the connected providers, the outgoing link toward the provider should be used. Otherwise, either providers' link may be used. (4) Load balancing between the providers should be implemented. All site nodes have multiple IPv6 addresses according to Assumption (a). Any source address that the site nodes select can be reachable from the Internet through the provider which assigns the address. This means that specific routing information need not to be announced. So, Goal (1) is archived. 2.1 Proposed Extension to Site Routers The providers announces its default route with its prefix to the site. Note that other routing information, if any, is announced without prefix. (Of course, routing protocol should be modified so that it can inform prefixes.) Site routers maintain multiple default routes with the provider prefixes. For example, in Figure 3, "P" and "Q" announces {default, p/48} and {default, q/48}, respectively. "r1", "r2", and "r3" maintain both {default, p/48} and {default, q/48}. Given a packet (src, dst), if there are multiple default routes and "dst" matches the default routes, a site router find a prefix which matches "src" to choose one of the default routes. For example, a packet (p, x) matches {default, p/48} on "r3". This extension ensures that the outgoing link from the site and the incoming link to the site are the same. This achieves Goal (2). For example, a packet (p, x) goes out from Site C through "P" and a responding packet (x, p) goes back to Site C via "P". Note that this is not a general policy routing. A source address is evaluated only to choose a default route. In other words, an outgoing link is selected according to a source address. In this environment, a node outside also may have multiple addresses as a site node has multiple source addresses. So, it is a key to implement an algorithm to choose a pair of source and destination IPv6 address. To inform errors, a new ICMPv6 *type* called "source prohibited" is introduced. This ICMPv6 messages are used to an address pair on site nodes. Note that since destination unreachable code 1 (communication with destination administratively prohibited) is corresponding to a destination, this messages are not suitable. Source prohibited messages may be generated by site boundary routers in the case that a site boundary router receives a packet whose source address is not a part of the connected provider's address block. Also, destination unreachable messages may be generated by site boundary routers in the case that the link to the connected provider is down but a packet is received. 2.2 Proposed Extensions for Site Nodes Assume that a site node has multiple addresses. The number of the addresses is Nsrc and each address is represented by sources[i]. Assume also that a node outside has multiple addresses. The number of the addresses is Ndst and each address is represented by destinations[j]. When the target hostname is given, destinations[0..Ndst] are resolved with DNS. The site node selects a pair of IPv6 addresses (sources[src], destination[dst]) by the following algorithm: ipv6_address destination[Ndst], sources[Nsrc]; DST: for (int dst = 0; dst < Ndst; dst++) { SRC: for (int src = 0; src < Nsrc; src++) { try a packet (srouces[src], destination[dst]); } catch { whenever a source prohibited message is received in this for block, continue SRC; } } catch { whenever a destination unreachable message is received in this for block, continue DST; } If a source address is selected in the longest match order with destination (in the inner block of the algorithm), Goal (3) is achieved. For example, if a destination is "q1", "q" is always selected for a source address on the site node . (Another implementation is that a provider announces its address block route to sites.) The longest match algorithm gives randomness to the source selection. This implements preliminary load balancing. So, Goal (4) is achieved. For example, "p" may be selected as a source for a destination "x" then this packet is forwarded to "P". "q" may be selected for "y" then this packet is forwarded to "Q". Example 1: in Figure 3, assume that "x" matches "p" and "q" in the longest order. "y" matches "q" and "p" in the longest order. Only defaults are announced by both "P" and "Q". An address pair is selected as follows: (p, x) -> forwarded to "P" (q, x) -> forwarded to "Q" (q, y) -> forwarded to "Q" (p, y) -> forwarded to "P" Example 2: the same as Example 1 but "Q" announces a specific route for "x". (p, x) -> forwarded to "Q" a source prohibited message returns since soruce "p" is filtered out by "Q" (q, x) -> forwarded to "Q" (q, y) -> forwarded to "Q" (p, y) -> forwarded to "P" Todo - implement extended routing table and forwading - implement address selection - design extended routing protocol -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 13 11:55:45 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id LAA06548 for ipng-dist; Wed, 13 Jan 1999 11:51:10 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id LAA06540 for ; Wed, 13 Jan 1999 11:50:55 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA22583 for ; Wed, 13 Jan 1999 11:50:54 -0800 Received: from santacruz.org (noc.santacruz.org [209.133.111.168]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA02229 for ; Wed, 13 Jan 1999 11:50:52 -0800 (PST) Received: from santacruz.org (santacruz.org [209.133.111.174]) by santacruz.org (Postfix) with ESMTP id 1AE138A44; Wed, 13 Jan 1999 11:56:29 -0800 (PST) Date: Wed, 13 Jan 1999 11:56:29 -0800 (PST) From: Gregory Taylor To: Audrey Van Belleghem Cc: "Dr. William Lenharth" , ipv6imp@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: (IPng 7054) Re: [IPv6Imp] connectathon 99 In-Reply-To: <369C34D6.16E8A613@vanb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How much does it cost if you do not want a booth, but just to attend? Gregory Taylor Network Security Analyst Consultant and Contract Unix Administrator SantaCruz Networks jest@santacruz.org On Tue, 12 Jan 1999, Audrey Van Belleghem wrote: > For the companies which have requested information about Connectathon, > please see http://www.connectathon.org for a detailed calendar, location > information, and registration forms. > > If I can be of any further assistance, please feel free to contact me at > cthon@sun.com, or audrey@vanb.com. > > Thanks for your interest! > > Audrey Van Belleghem > Connectathon Manager > > Gregory Taylor wrote: > > > I would like to attend the Connect-A-Thon 1999, please send me > > information > > on doing so. > > > > Thank You, > > > > Gregory Taylor > > Network Security Analyst > > Consultant and Contract Unix Administrator > > SantaCruz Networks > > > > jest@santacruz.org > > > > On Tue, 12 Jan 1999, Dr. William Lenharth wrote: > > > > > This is a reminder notice: UNH will again be testing IPv6 > > implementations at > > > CONNECTATHON99 in San Jose on March 7-11, 1999. This is the week > > before the > > > IETF meeting in sunny Minneapolis. We have added over 50 new tests > > to our > > > program and will include router protocol testing. To participate > > you may > > > contact the coordinator at Audrey Van Belleghem . > > Please also > > > update us by sending mail to whl@unh.edu ! Thanks ... > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 13 13:25:54 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id NAA06611 for ipng-dist; Wed, 13 Jan 1999 13:12:28 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id NAA06604 for ; Wed, 13 Jan 1999 13:12:07 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA04670 for ; Wed, 13 Jan 1999 13:12:04 -0800 Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA03030 for ; Wed, 13 Jan 1999 13:12:03 -0800 (PST) Received: (qmail 2483 invoked from network); 13 Jan 1999 21:12:02 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 13 Jan 1999 21:12:02 -0000 Received: from orr.arin.net (orr.arin.net [192.149.252.201]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA00249; Wed, 13 Jan 1999 16:12:01 -0500 (EST) Received: from localhost by orr.arin.net (8.9.0/8.9.0) with SMTP id QAA14940; Wed, 13 Jan 1999 16:12:01 -0500 (EST) X-Authentication-Warning: orr.arin.net: raminr owned process doing -bs Date: Wed, 13 Jan 1999 16:12:00 -0500 (EST) From: Ramin Sepehr Rad To: ipng@sunroof.eng.sun.com Subject: (IPng 7056) Qeustion on initial IPv6 Sub-TLA ID Assignments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A collegue of mine brough to my attention that some notations used in the draft on "Initial IPv6 Sub-TLA ID Assignments" is a little bit confusing. We hope we can get a clarification on this. His question is followed. You may email him directly, kerr@arin.net, but please CC me as well. Thanks, -ramin ---------- Forwarded message ---------- Date: Wed, 13 Jan 1999 16:05:48 -0500 (EST) From: Shane Kerr To: Ramin Sepehr Rad Subject: Initial IPv6 Sub-TLA ID Assignments We were figuring out the actual IP ranges from the IPv6 draft, , and we thought the initial assignments of the sub-TLA ID's was a bit confusing. Here's an excerpt from section 3.0 in the draft: As specified in [TLA-RULES] assignments of Sub-TLA ID's will be done in blocks. The initial assignment of Sub-TLA ID's to registries will be in blocks of 64 Sub-TLA ID's. These assignments are as follows: Binary Range (Hex) Assignment ---------------- --------------- ------------------- 0 0000 00XX XXXX 0x0000 - 0x003F IANA 0 0000 01XX XXXX 0x0040 - 0x007F APNIC 0 0000 10XX XXXX 0x0080 - 0x00BF ARIN 0 0000 11XX XXXX 0x00C0 - 0x00FF RIPE NCC Where "X" indicates "0" or "1". This is all well and good, until you consider where these bits lie in an IPv6 address. Here's the anatomy, grouped by hex digit: FFFT TTTT TTTT TTTT : SSSS SSSS SSSS SNNN : NNNN NNNN NNNN NNNN : I've noted Format Prefix by "F", TLA ID by "T", Sub-TLA ID by "S", and NLA ID by "N". The Sub-TLA bits start on the left boundary of the fifth hex digit, immediately after the first colon. Given this reality, I would prefer if the assignments were listed as follows: Binary Range (Hex) Assignment ---------------- --------------- ------------------- 0000 000X XXXX X 0x0000 - 0x01FF IANA 0000 001X XXXX X 0x0200 - 0x03FF APNIC 0000 010X XXXX X 0x0400 - 0x05FF ARIN 0000 011X XXXX X 0x0600 - 0x07FF RIPE NCC Where "X" indicates "0" or "1". The actual prefixes of the initial assignment are: 2001:0000::/23 IANA 2001:0200::/23 APNIC 2001:0400::/23 ARIN 2001:0600::/23 RIPE NCC I understand that using this notation might cause some confusion, since the hex ranges don't parse normally, but I think it will be more helpful in the long run. In fact, I'd prefer to do away with the hex ranges altogether than go forward using bit values that don't map into the IPv6 numbers properly. Shane Kerr Software Engineer American Registry for Internet Numbers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 14 06:00:31 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id FAA07452 for ipng-dist; Thu, 14 Jan 1999 05:53:05 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id FAA07445 for ; Thu, 14 Jan 1999 05:52:56 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA13471 for ; Thu, 14 Jan 1999 05:52:55 -0800 Received: from ns1.digital.fr (ns1.digital.fr [193.56.15.3]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA12464 for ; Thu, 14 Jan 1999 05:52:55 -0800 (PST) Received: from batman.vbo.dec.com (batman.vbo.dec.com [16.36.208.15]) by ns1.digital.fr (8.8.8/8.8.8) with ESMTP id OAA31381 for ; Thu, 14 Jan 1999 14:52:54 +0100 (MET) Received: from vb2rmc.vbo.dec.com (vb2rmc.vbo.dec.com [16.36.208.80]) by batman.vbo.dec.com (8.8.8/8.8.8) with ESMTP id OAA02974 for ; Thu, 14 Jan 1999 14:52:24 +0100 (MET) Received: from taec.enet (daemon@localhost) by vb2rmc.vbo.dec.com (8.7.3/8.7) with SMTP id OAA08690 for ; Thu, 14 Jan 1999 14:27:09 +0100 Message-Id: <199901141327.OAA08690@vb2rmc.vbo.dec.com> Received: from taec.enet; by vbormc.enet; Thu, 14 Jan 99 14:27:19 MET Date: Thu, 14 Jan 99 14:27:19 MET From: Yanick To: "ipng@sunroof.eng.sun.com"@vb2rmc.vbo.dec.com Cc: pouffary@taec.enet.dec.com Apparently-To: ipng@sunroof.eng.sun.com Subject: (IPng 7058) who ipng Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 15 11:19:43 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id LAA09820 for ipng-dist; Fri, 15 Jan 1999 11:10:19 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id LAA09799; Fri, 15 Jan 1999 11:05:57 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA23817; Fri, 15 Jan 1999 11:05:54 -0800 Received: from om2.gto.net.om (om2.gto.net.om [206.49.101.40]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA25356; Fri, 15 Jan 1999 11:05:53 -0800 (PST) Received: from default(as12-107.gto.net.om[212.72.7.234]) (833 bytes) by om2.gto.net.om via sendmail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Fri, 15 Jan 1999 23:00:12 +0400 (OMAN) (Smail-3.2.0.102 1998-Aug-2 #21 built 1998-Aug-20) Message-ID: <369F9264.A822FB45@gto.net.om> Date: Fri, 15 Jan 1999 23:09:27 +0400 From: Peter Dawson X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: IPng CC: 6bone <6bone@ISI.EDU>, ngtrans Subject: (IPng 7059) tunnerl broker protocol X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi is there any ID for tunnel broker protocol ? if not where could I find some more details on this complementary ngtrans mechanism ...more specifically how will this work with tunnel endpoints on the dual stack ? thks /pete -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 15 11:57:20 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id LAA09900 for ipng-dist; Fri, 15 Jan 1999 11:47:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id LAA09879; Fri, 15 Jan 1999 11:44:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA10274; Fri, 15 Jan 1999 11:44:16 -0800 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA21336; Fri, 15 Jan 1999 11:44:17 -0800 (PST) Received: from pinnacle.wins.lbl.gov (pinnacle) [131.243.216.234] by mail1.es.net with smtp (Exim 1.81 #2) id 101FAG-0001dD-00; Fri, 15 Jan 1999 11:44:17 -0800 Message-Id: <4.1.19990115114309.009958e0@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Jan 1999 11:43:53 -0800 To: ngtrans@sunroof.eng.sun.com, IPng From: Bob Fink Subject: (IPng 7060) Re: (ngtrans) tunnerl broker protocol In-Reply-To: <369F9264.A822FB45@gto.net.om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:09 PM 1/15/99 +0400, Peter Dawson wrote: >hi >is there any ID for tunnel broker protocol ? if >not where could I find some more details on this >complementary ngtrans mechanism ...more specifically >how will this work with tunnel endpoints on the dual stack ? >thks There is no draft yet. Hopefully by the Interim Grenoble meetings Alain Durand will have some more details. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 15 14:39:04 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id OAA10101 for ipng-dist; Fri, 15 Jan 1999 14:30:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id OAA10094; Fri, 15 Jan 1999 14:30:37 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA07286; Fri, 15 Jan 1999 14:30:37 -0800 Received: from santacruz.org (noc.santacruz.org [209.133.111.168]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA02207; Fri, 15 Jan 1999 14:30:36 -0800 (PST) Received: from santacruz.org (santacruz.org [209.133.111.174]) by santacruz.org (Postfix) with ESMTP id 2F5FB8A44; Fri, 15 Jan 1999 14:36:29 -0800 (PST) Date: Fri, 15 Jan 1999 14:36:29 -0800 (PST) From: Gregory Taylor To: ngtrans@sunroof.eng.sun.com Cc: IPng Subject: (IPng 7061) Connectathon? In-Reply-To: <4.1.19990115114309.009958e0@imap2.es.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I wish connectathon was a little less expensive.. My business and I would like to attend so that I may discuss with fellow IPv6/NG developers and commentors about the implimentation of the protocol and ideas on how to achieve this. Unfortunately, the business I work for as well as myself, are unable to gather the funds to attend such a conference. Maybe perhaps in the future Sun microsystems and the connectathon staff will consider either allowing visitors who are on the mailing lists and committee to attend connectathon, or at least drop the price to a reasonable level. The majority of IPv6's potential success was not achieved by highly paid corporate junkies, but by average people who have great ideas and excellent reasoning and programming skills. Thank You Gregory Taylor Network Security Analyst Consultant and Contract Unix Administrator SantaCruz Networks jest@santacruz.org On Fri, 15 Jan 1999, Bob Fink wrote: > At 11:09 PM 1/15/99 +0400, Peter Dawson wrote: > >hi > >is there any ID for tunnel broker protocol ? if > >not where could I find some more details on this > >complementary ngtrans mechanism ...more specifically > >how will this work with tunnel endpoints on the dual stack ? > >thks > > There is no draft yet. Hopefully by the Interim Grenoble meetings Alain > Durand will have some more details. > > > 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 Sat Jan 16 09:51:26 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA10735 for ipng-dist; Sat, 16 Jan 1999 09:41:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id JAA10728 for ; Sat, 16 Jan 1999 09:41:30 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA24294 for ; Sat, 16 Jan 1999 09:41:28 -0800 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA11836 for ; Sat, 16 Jan 1999 09:41:29 -0800 (PST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with SMTP id SAA28159; Sat, 16 Jan 1999 18:34:46 +0100 (MET) Received: from rcur98nbn173w by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id SAA20947; Sat, 16 Jan 1999 18:34:46 +0100 Message-Id: <3.0.1.32.19990116183116.0078325c@era-t.ericsson.se> X-Sender: eratekd@era-t.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 16 Jan 1999 18:31:16 +0100 To: ipng@sunroof.eng.sun.com From: Thomas Eklund Subject: (IPng 7062) request for a slot Cc: bound@zk3.dec.com, rlfink@buster.lbl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, my name is Thomas Eklund and I work at Ericsson Research... I was hoping for a slot to talk a little bit about IPv6 in mobile systems like GPRS and UMTS, perhaps Bluetooth if there is time. - GPRS is the packet based network service in GSM systems (various radio coding channel schemes are specified to allow bitrates from 9 to more than 150 kbps per user) - UMTS which is the 3rd generation mobile systems with WCDMA as access which is Europes proposal for IMT2000 ( with bw uptil 2 mbps) - Bluetooth which is the future shoort link radio that was origannaly designed as a cable replacer but has evolved to be integrated in the hole network The slot will be something like "IPv6 in mobile systems" Try to schetch the advantages and where the problem lies for deployment... Cheers Thomas Eklund -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 18 10:07:57 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA12077 for ipng-dist; Mon, 18 Jan 1999 09:56:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id JAA12070 for ; Mon, 18 Jan 1999 09:56:46 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA12115 for ; Mon, 18 Jan 1999 09:56:45 -0800 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA22299 for ; Mon, 18 Jan 1999 09:56:45 -0800 (PST) Received: from rasp1-34.lbl.gov (pinnacle) [131.243.212.234] by mail1.es.net with smtp (Exim 1.81 #2) id 102Iul-0005yp-00; Mon, 18 Jan 1999 09:56:40 -0800 Message-Id: <4.1.19990118093518.00a5e4c0@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 18 Jan 1999 09:43:39 -0800 To: Thomas Eklund , ipng@sunroof.eng.sun.com From: Bob Fink Subject: (IPng 7064) Re: request for a slot Cc: bound@zk3.dec.com In-Reply-To: <3.0.1.32.19990116183116.0078325c@era-t.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, At 06:31 PM 1/16/99 +0100, Thomas Eklund wrote: >Hi, >my name is Thomas Eklund and I work at Ericsson Research... > >I was hoping for a slot to talk a little bit about IPv6 in mobile systems >like GPRS and UMTS, perhaps Bluetooth if there is time. >- GPRS is the packet based network service in GSM systems (various radio >coding channel schemes are specified to allow bitrates from 9 to more than >150 kbps per user) >- UMTS which is the 3rd generation mobile systems with WCDMA as access >which is Europes proposal for IMT2000 ( with bw uptil 2 mbps) >- Bluetooth which is the future shoort link radio that was origannaly >designed as a cable replacer but has evolved to be integrated in the hole >network > >The slot will be something like "IPv6 in mobile systems" > >Try to schetch the advantages and where the problem lies for deployment... Are you asking for time on the 1st day IPng, or 3rd day deployment agenda? 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 Mon Jan 18 10:54:07 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id KAA12190 for ipng-dist; Mon, 18 Jan 1999 10:49:42 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id KAA12168; Mon, 18 Jan 1999 10:47:20 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA00518; Mon, 18 Jan 1999 10:47:14 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA21369; Mon, 18 Jan 1999 10:47:13 -0800 (PST) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id TAA11729; Mon, 18 Jan 1999 19:47:11 +0100 (MET) Message-Id: <199901181847.TAA11729@imag.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 18 Jan 1999 19:46:00 +0100 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@ISI.EDU From: Alain Durand Subject: (IPng 7065) Grenoble meeting: maps Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks I've scanned some maps of Grenoble and the university campus. You'll find them on http://www.ipv6.imag.fr/ietf1999.html Also, there are 10 places left for the social... - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 19 03:02:54 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id CAA12668 for ipng-dist; Tue, 19 Jan 1999 02:59:39 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id CAA12661 for ; Tue, 19 Jan 1999 02:59:28 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA02337 for ; Tue, 19 Jan 1999 02:59:26 -0800 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA21269 for ; Tue, 19 Jan 1999 02:59:12 -0800 (PST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with SMTP id LAA08074 for ; Tue, 19 Jan 1999 11:58:59 +0100 (MET) Received: from rcur98nbn173w.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA02327; Tue, 19 Jan 1999 11:58:59 +0100 Message-Id: <3.0.1.32.19990119115531.006d7ff8@era-t.ericsson.se> X-Sender: eratekd@era-t.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 19 Jan 1999 11:55:31 +0100 To: Sascha Meyer , ipng@sunroof.eng.sun.com From: Thomas Eklund Subject: (IPng 7066) Re: request for a slot In-Reply-To: <36A37C4D.60AA8CEA@eed.ericsson.se> References: <3.0.1.32.19990116183116.0078325c@era-t.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, we have written a draft about it that will be submitted very soon to mobileip and ipng group... Cheers Thomas Eklund At 19:24 1999-01-18 +0100, Sascha Meyer wrote: >Hi Thomas! > >I am currently working on my diploma thesis at EED/RN. My work involves issues >on how to achieve mobility in IP. Recently I heard "rumors" about a concept >that suggests to encapsulate a mobile host's IMSI within the 128 bits of an >IPv6 address. Perhaps you have heard any details about this idea? > >Could you provide me with information on this approach? That would be very >helpful! > >Thanks in advance >/Sascha > >Thomas Eklund wrote: > >> Hi, >> my name is Thomas Eklund and I work at Ericsson Research... >> >> I was hoping for a slot to talk a little bit about IPv6 in mobile systems >> like GPRS and UMTS, perhaps Bluetooth if there is time. >> - GPRS is the packet based network service in GSM systems (various radio >> coding channel schemes are specified to allow bitrates from 9 to more than >> 150 kbps per user) >> - UMTS which is the 3rd generation mobile systems with WCDMA as access >> which is Europes proposal for IMT2000 ( with bw uptil 2 mbps) >> - Bluetooth which is the future shoort link radio that was origannaly >> designed as a cable replacer but has evolved to be integrated in the hole >> network >> >> The slot will be something like "IPv6 in mobile systems" >> >> Try to schetch the advantages and where the problem lies for deployment... >> >> Cheers Thomas Eklund >> >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- > > > >-- >Sascha Meyer Sascha.Meyer@eed.ericsson.se >Ericsson Eurolab GmbH >D-52134 Herzogenrath Tel: +49-2407-575-7814 >Ericsson-Allee 1 Fax: +49-2407-575-651 > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 19 17:33:37 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id RAA13426 for ipng-dist; Tue, 19 Jan 1999 17:16:44 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id RAA13419 for ; Tue, 19 Jan 1999 17:16:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA06306 for ; Tue, 19 Jan 1999 17:16:29 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA28968 for ; Tue, 19 Jan 1999 17:16:28 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id DCD6715C; Tue, 19 Jan 1999 20:16:26 -0500 (EST) To: ipng@sunroof.eng.sun.com Subject: (IPng 7067) France decontrols crypto Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 19 Jan 1999 20:16:26 -0500 Message-ID: <87sod6pwut.fsf@jekyll.piermont.com> Lines: 12 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk According to many reports sent to the cryptography@c2.net mailing list, France has decided to eliminate its domestic encryption controls. The reports claim that pending legislation entirely removing these controls, the permitted limit on conventional ciphers is being administratively raised from 40 bits to 128 bits. I hope this means the INRIA people are now going to be able to help work on IPSEC for the Unified BSD IPv6 stack. :) Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 20 01:30:51 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id BAA13716 for ipng-dist; Wed, 20 Jan 1999 01:27:23 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id BAA13709 for ; Wed, 20 Jan 1999 01:27:14 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA17094 for ; Wed, 20 Jan 1999 01:27:13 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA04388 for ; Wed, 20 Jan 1999 01:27:13 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA22702; Wed, 20 Jan 1999 10:27:10 +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 KAA28901; Wed, 20 Jan 1999 10:27:10 +0100 (MET) Message-Id: <199901200927.KAA28901@givry.inria.fr> From: Francis Dupont To: perry@piermont.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 7068) Re: France decontrols crypto In-reply-to: Your message of 19 Jan 1999 20:16:26 EST. <87sod6pwut.fsf@jekyll.piermont.com> Date: Wed, 20 Jan 1999 10:27:09 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: According to many reports sent to the cryptography@c2.net mailing list, France has decided to eliminate its domestic encryption controls. The reports claim that pending legislation entirely removing these controls, the permitted limit on conventional ciphers is being administratively raised from 40 bits to 128 bits. => it is only a political statement. The last time freedom has been promised and we got a restrictive law and it took near 20 months to get more restrictive application decrees... But now it seems there is a real political will (without an important election in some months :-). I hope this means the INRIA people are now going to be able to help work on IPSEC for the Unified BSD IPv6 stack. :) => it will be a good thing ! Thanks Francis.Dupont@inria.fr PS: references (LONG): the speech is at http://www.premier-ministre.gouv.fr/PM/D190199.HTM (premier-ministre = first-minister, gouv = gov, D is from discours = speech, the date is in European format (day-month-year)) Le Gouvernement a donc décidé de présenter progressivement au Parlement un ensemble de propositions relatives au document numérique et à la signature électronique (a), à la protection des données personnelles (b) et enfin la cryptologie (c). (so the Government has decided to present gradually to the Parlement a set of proposals relative to the digital document and to the electronic signature (a), to the protection of personnal data (b) and finally to the cryptology (c).) (c ) Le troisième chantier législatif concerne la cryptologie. Alors que se développent les moyens d'espionnage électronique, la cryptologie apparaît comme un moyen essentiel pour protéger la confidentialité des échanges et la protection de la vie privée. (c: The third legislative task is about the cryptology. When electronic spying abilities spread, the cryptology appears to be an essential tool for the protection of the confidentality of exchanges and of the privacy.) Nous avions, il y a un an, franchi un premier pas vers la libéralisation des moyens de cryptologie, c'est à dire la technique qui assure la sécurité des échanges de données sur les réseaux. J'avais annoncé alors que nous en franchirions un autre ultérieurement. Le Gouvernement a, depuis, entendu les acteurs, interrogé les experts et consulté ses partenaires internationaux. Nous avons aujourd'hui acquis la conviction que la législation de 1996 n'est plus adaptée. En effet, elle restreint fortement l'usage de la cryptologie en France, sans d'ailleurs permettre pour autant aux pouvoirs publics de lutter efficacement contre des agissements criminels dont le chiffrement pourrait faciliter la dissimulation. (One year ago we have done a first step towards the liberalization (?) of cryptology devices, ie the technical way to insure the security of data exchanges on networks. I announced at this time that we should do another step. Since the Government has consulted actors, experts and international partners. Today we have got the conviction that the 1996 law does no more fit. Indeed it greatly limits the use of cryptology in France, and anyway does not give to the authorities an efficient tool against criminal acts which should be conceal with the help of cryptology devices.) Pour changer l'orientation de notre législation, le Gouvernement a donc retenu les orientations suivantes dont je me suis entretenu avec le Président de la République : (In order to change the trend of the legislation, the Government has accepted the following ideas after an interview with the President:) - offrir une liberté complète dans l'utilisation de la cryptologie ; (- give a complete freedom for the use of cryptology (Note: use, not supply)) - supprimer le caractère obligatoire du recours au tiers de confiance pour le dépôt des clefs de chiffrement ; (- abolish the mandatory usage of trusted parties) - compléter le dispositif juridique actuel par l'instauration d'obligations, assorties de sanctions pénales, concernant la remise aux autorités judiciaires, lorsque celles-ci la demandent, de la transcription en clair des documents chiffrés. De même, les capacités techniques des pouvoirs publics seront significativement renforcées et les moyens correspondant dégagés. (- complement the current legal system with new enforced obligations about the delivery to legal authorities on demand of cleartext transcripts of enciphered documents. Likewise the technical facilities of the authorities will be strengthened.) Changer la loi prendra plusieurs mois. Le Gouvernement a voulu que les principales entraves qui pèsent sur les citoyens pour protéger la confidentialité de leurs échanges et sur le développement du commerce électronique soient levées sans attendre. Ainsi, dans l'attente des modifications législatives annoncées, le Gouvernement a décidé de relever le seuil de la cryptologie dont l'utilisation est libre, de 40 bits à 128 bits, niveau considéré par les experts comme assurant durablement une très grande sécurité. (To change the law will take some months. The Government has wanted that the main hindrances which put a lot of weight on the ability of citizens to protect the confidentiality of their exchanges and on the development of the electronic business are lifted without wait. Then, in wait of announced upgrade of the law, the Government has decided to raise the threshold for free use ciphers from 40 bit key length to 128 bits, a level which should give for a long time a very good security according to experts.) PPS: my comments: the French law separates: - authentication/integrity/digital signature, ... - low security ciphers (threshold on key length) or ciphers with trusted third party - high security ciphers and - usage, supply, export and import from a country outside the European Union. The speech is only on usage, not on supply then as usual it is not clear it is an effective progress. The value of threshold on key length is not in the law, only in a decree: the Government can change it tomorrow (which is a good point) and usually the proceedings for supply, export and import use the same threshold (ie the Government can abolish most of the current law only with a new application decree which takes only the time to publish it). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 20 06:14:25 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id GAA13917 for ipng-dist; Wed, 20 Jan 1999 06:04:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id GAA13910 for ; Wed, 20 Jan 1999 06:04:40 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA00282 for ; Wed, 20 Jan 1999 06:04:36 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA01711 for ; Wed, 20 Jan 1999 06:04:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA18298; Wed, 20 Jan 1999 09:04:33 -0500 (EST) Message-Id: <199901201404.JAA18298@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 7069) Last Call: IPv6 Addressing Architecture and Aggregatable Global Unicast Address Format to Draft Reply-to: iesg@ietf.org Date: Wed, 20 Jan 1999 09:04:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request to consider elevating the following two RFCs (current Proposed Standards) to Draft Standard. o RFC2373: IP Version 6 Addressing Architecture o RFC2374: An IPv6 Aggregatable Global Unicast Address Format These documents are a product of the IPNG Working Group of the IETF. 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@cnri.reston.va.us or ietf@ietf.org mailing lists by February 2,1999. Files can be obtained via http://www.ietf.org/rfc/rfc2273.txt http://www.ietf.org/rfc/rfc2274.txt All Implementation Reports can be found at: http://www.ietf.org/IESG/implementation.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 20 07:49:42 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA13967 for ipng-dist; Wed, 20 Jan 1999 07:41:24 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA13960 for ; Wed, 20 Jan 1999 07:41:13 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09576 for ; Wed, 20 Jan 1999 07:41:12 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA26795 for ; Wed, 20 Jan 1999 07:41:12 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20182; Wed, 20 Jan 1999 10:40:34 -0500 (EST) Message-Id: <199901201540.KAA20182@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 7070) Protocol Action: A Method for the Transmission of IPv6 Packets over ARCnet Networks. to Proposed Standard Date: Wed, 20 Jan 1999 10:40:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved A Method for the Transmission of IPv6 Packets over ARCnet Networks as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document defines how to run IPv6 over an ARCnet network. It defines the protocol ID, encapsulation format, method for forming interface identifiers, etc. Working Group Summary There was consensus within the WG for this document. Protocol Quality This document has been reviewed for the IESG by 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 Wed Jan 20 08:48:25 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA14085 for ipng-dist; Wed, 20 Jan 1999 08:38:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA14078 for ; Wed, 20 Jan 1999 08:38:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA16237 for ; Wed, 20 Jan 1999 08:38:03 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA06580 for ; Wed, 20 Jan 1999 08:38:01 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21455; Wed, 20 Jan 1999 11:37:55 -0500 (EST) Message-Id: <199901201637.LAA21455@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7071) I-D ACTION:draft-ietf-ipngwg-6over4-02.txt Date: Wed, 20 Jan 1999 11:37:55 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Transmission of IPv6 over IPv4 Domains without Explicit Tunnels Author(s) : B. Carpenter, C. Jung Filename : draft-ietf-ipngwg-6over4-02.txt Pages : 9 Date : 19-Jan-99 This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a 'virtual Ethernet.' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-6over4-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-6over4-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-6over4-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990119164440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-6over4-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-6over4-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990119164440.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 20 13:10:39 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id MAA14550 for ipng-dist; Wed, 20 Jan 1999 12:59:08 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id MAA14543 for ; Wed, 20 Jan 1999 12:59:00 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id MAA23716 for ; Wed, 20 Jan 1999 12:59:01 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id MAA05676 for ipng@sunroof.eng.sun.com; Wed, 20 Jan 1999 12:58:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id MAA14470 for ; Wed, 20 Jan 1999 12:34:44 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA28926 for ; Wed, 20 Jan 1999 12:34:41 -0800 Received: from sr.unh.edu (bluemoon.sr.unh.edu [132.177.241.26]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA01493 for ; Wed, 20 Jan 1999 12:34:40 -0800 (PST) Received: from [132.177.121.243] (macg3.iol.unh.edu [132.177.121.243]) by sr.unh.edu (8.9.1a/8.9.1) with ESMTP id PAA04566 for ; Wed, 20 Jan 1999 15:34:34 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: whl@bluemoon.sr.unh.edu (Unverified) Message-Id: Date: Wed, 20 Jan 1999 15:34:57 -0400 To: ipng@sunroof.eng.sun.com From: "Dr. William Lenharth" Subject: (IPng 7073) Connectathon99 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a reminder notice: UNH will again be testing IPv6 implementations at CONNECTATHON99 in San Jose on March 7-11, 1999. This is the week before the IETF meeting in sunny Minneapolis. We have added over 50 new tests to our program and will include RIPng. To participate you may contact the coordinator at Audrey Van Belleghem . Please also update us by sending mail to whl@unh.edu ! Thanks ... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 21 02:46:36 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id CAA15276 for ipng-dist; Thu, 21 Jan 1999 02:29:52 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id CAA15269 for ; Thu, 21 Jan 1999 02:29:43 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA16794 for ; Thu, 21 Jan 1999 02:29:43 -0800 Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA17016 for ; Thu, 21 Jan 1999 02:29:40 -0800 (PST) Received: from wega (wega [193.175.132.17]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with SMTP id LAA05804 for ; Thu, 21 Jan 1999 11:29:37 +0100 (MET) Date: Thu, 21 Jan 1999 11:29:36 +0100 (MET) From: "G. Goldacker" Reply-To: "G. Goldacker" Subject: (IPng 7074) geographic addressing To: ipng@sunroof.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 Can anybody point me to the why and when geographic addressing was removed from the IPng addressing architecture? Thanks Gabriele Goldacker (GMD FOKUS) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 21 06:08:54 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id FAA15500 for ipng-dist; Thu, 21 Jan 1999 05:52:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id FAA15462; Thu, 21 Jan 1999 05:43:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA16251; Thu, 21 Jan 1999 05:43:08 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA19970; Thu, 21 Jan 1999 05:43:08 -0800 (PST) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id OAA16648; Thu, 21 Jan 1999 14:43:06 +0100 (MET) Message-Id: <199901211343.OAA16648@imag.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 21 Jan 1999 14:41:50 +0100 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@ISI.EDU From: Alain Durand Subject: (IPng 7076) Interim Meeting registration fees. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. We came out with a solution to get you some lunch during the meeting. We will have a catering service with a buffet and we will have to charge some fees for that. The registration fees, covering the 3 lunches and 3 afternoom breaks, will be 100F per day. So, the total will be 300F (about $50) for the meeting and 450F (300+150) if you attend the social. We will open a registration desk on tuesday, Feb. 2nd, morning at 8:00 AM. ---------------------------------------------------------------------------- --------- ---- Please come with ***exact*** change in cash in french francs ---- ---------------------------------------------------------------------------- --------- We can take french checks from a french bank, but we can not take credit cards. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 21 08:55:19 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA15736 for ipng-dist; Thu, 21 Jan 1999 08:41:40 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA15729 for ; Thu, 21 Jan 1999 08:41:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA22305 for ; Thu, 21 Jan 1999 08:41:31 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA06571 for ; Thu, 21 Jan 1999 08:41:29 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA165594; Thu, 21 Jan 1999 16:41:25 GMT Received: from hursley.ibm.com (9-20-31-131.dhcp.hursley.ibm.com [9.20.31.131]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA18272; Thu, 21 Jan 1999 16:41:25 GMT Message-ID: <36A7587D.BFDD9DB6@hursley.ibm.com> Date: Thu, 21 Jan 1999 16:40:29 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "G. Goldacker" CC: ipng@sunroof.eng.sun.com Subject: (IPng 7079) Re: geographic addressing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There has never been a workable proposal for geog. addressing. For that reason, it doesn't have a format prefix assigned in RFC 2373 (there was one in the obsolete RFC 1884). Brian G. Goldacker wrote: > > Can anybody point me to the why and when geographic addressing was removed from > the IPng addressing architecture? > Thanks > Gabriele Goldacker (GMD FOKUS) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 21 09:23:00 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA15796 for ipng-dist; Thu, 21 Jan 1999 09:09:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id JAA15789 for ; Thu, 21 Jan 1999 09:09:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA16849 for ; Thu, 21 Jan 1999 09:08:59 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.192.13]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA26685 for ; Thu, 21 Jan 1999 09:08:57 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA11323; Thu, 21 Jan 1999 09:08:12 -0800 (PST) X-Sender: deering@postoffice Message-Id: In-Reply-To: <36A7587D.BFDD9DB6@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Jan 1999 09:09:44 -0800 To: Brian E Carpenter From: Steve Deering Subject: (IPng 7080) Re: geographic addressing Cc: "G. Goldacker" , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:40 AM -0800 1/21/99, Brian E Carpenter wrote: > There has never been a workable proposal for geog. addressing. ...where "workable" means politically acceptable. > For that reason, it doesn't have a format prefix assigned > in RFC 2373 (there was one in the obsolete RFC 1884). The newer "aggregatable" address format permits aggregates based on providers, geography, exchanges, or any other workable method of clustering the topology. Thus, there is no longer a need for separate "provider-based" and "geography-based" format prefixes. 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 Jan 21 10:00:59 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA15857 for ipng-dist; Thu, 21 Jan 1999 09:41:27 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id JAA15850 for ; Thu, 21 Jan 1999 09:41:12 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA22242 for ; Thu, 21 Jan 1999 09:41:08 -0800 Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA18879 for ; Thu, 21 Jan 1999 09:41:06 -0800 (PST) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Thu, 21 Jan 1999 12:41:04 -0500 Message-ID: <1180113EC576D011AADE0060975B88B341DBF2@neonet_server1.nexabit.com> From: Dimitry Haskin To: Brian E Carpenter , "G. Goldacker" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7081) Re: geographic addressing Date: Thu, 21 Jan 1999 12:41:03 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually I believe the adopted addressing proposal has a strong geographic component in it. It relates to the fact that address blocks can be given to exchanges located in particular geographical areas. ---------------------------------------------------------------------- Dimitry Haskin Nexabit Networks, Inc. http://www.nexabit.com > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, January 21, 1999 11:40 AM > To: G. Goldacker > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 7079) Re: geographic addressing > > > There has never been a workable proposal for geog. addressing. > > For that reason, it doesn't have a format prefix assigned > in RFC 2373 (there was one in the obsolete RFC 1884). > > Brian > > G. Goldacker wrote: > > > > Can anybody point me to the why and when geographic > addressing was removed from > > the IPng addressing architecture? > > Thanks > > Gabriele Goldacker (GMD FOKUS) > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 22 04:04:14 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id DAA17279 for ipng-dist; Fri, 22 Jan 1999 03:49:11 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id DAA17271 for ; Fri, 22 Jan 1999 03:48:59 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA21908 for ; Fri, 22 Jan 1999 03:48:59 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA15301 for ; Fri, 22 Jan 1999 03:48:58 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA111216; Fri, 22 Jan 1999 11:48:55 GMT Received: from hursley.ibm.com (9-20-31-131.dhcp.hursley.ibm.com [9.20.31.131]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA24614; Fri, 22 Jan 1999 11:48:54 GMT Message-ID: <36A8656C.30F8A4C2@hursley.ibm.com> Date: Fri, 22 Jan 1999 11:47:56 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Dimitry Haskin CC: "G. Goldacker" , ipng@sunroof.eng.sun.com Subject: (IPng 7083) Re: geographic addressing References: <1180113EC576D011AADE0060975B88B341DBF2@neonet_server1.nexabit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oh, I agree compeletely; there is no reason why TLA or subTLA prefixes couldn't be used as metropolitan prefixes. What I meant is that I have never seen a version of metro-based addressing that looked to me as if it had any chance of being deployed in practice. I disagree humbly with Steve that the issues are "political"; they seem to me to be practical business issues (such as we don't discuss in the IETF). Brian Dimitry Haskin wrote: > > Actually I believe the adopted addressing proposal has a strong > geographic component in it. It relates to the fact that address blocks > can be given to exchanges located in particular geographical areas. > > ---------------------------------------------------------------------- > Dimitry Haskin > Nexabit Networks, Inc. http://www.nexabit.com > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Thursday, January 21, 1999 11:40 AM > > To: G. Goldacker > > Cc: ipng@sunroof.Eng.Sun.COM > > Subject: (IPng 7079) Re: geographic addressing > > > > > > There has never been a workable proposal for geog. addressing. > > > > For that reason, it doesn't have a format prefix assigned > > in RFC 2373 (there was one in the obsolete RFC 1884). > > > > Brian > > > > G. Goldacker wrote: > > > > > > Can anybody point me to the why and when geographic > > addressing was removed from > > > the IPng addressing architecture? > > > Thanks > > > Gabriele Goldacker (GMD FOKUS) > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 22 09:26:07 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA17547 for ipng-dist; Fri, 22 Jan 1999 09:17:41 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id JAA17540 for ; Fri, 22 Jan 1999 09:17:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA00968 for ; Fri, 22 Jan 1999 09:17:03 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA22169 for ; Fri, 22 Jan 1999 09:17:03 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23292; Fri, 22 Jan 1999 12:16:28 -0500 (EST) Message-Id: <199901221716.MAA23292@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 7085) Protocol Action: A Method for the Transmission of IPv6 Packets over ARCnet Networks. to Proposed Standard Date: Fri, 22 Jan 1999 12:16:28 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved A Method for the Transmission of IPv6 Packets over ARCnet Networks as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document defines how to run IPv6 over an ARCnet network. It defines the protocol ID, encapsulation format, method for forming interface identifiers, etc. Working Group Summary There was consensus within the WG for this document. Protocol Quality This document has been reviewed for the IESG by 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 Mon Jan 25 06:22:18 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id GAA19662 for ipng-dist; Mon, 25 Jan 1999 06:08:30 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id GAA19653 for ; Mon, 25 Jan 1999 06:08:16 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA26188 for ; Mon, 25 Jan 1999 06:08:16 -0800 Received: from romeo.ic.ac.uk (romeo.ic.ac.uk [155.198.5.9]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA27004 for ; Mon, 25 Jan 1999 06:07:44 -0800 (PST) Received: from oban.cc.ic.ac.uk [155.198.5.28] by romeo.ic.ac.uk with smtp (Exim 1.62 #1) id 104mg3-0000g0-00; Mon, 25 Jan 1999 14:07:43 +0000 Received: from hide.ee.ic.ac.uk ([155.198.120.14] helo=eecfsag2.ee.ic.ac.uk) by oban.cc.ic.ac.uk with esmtp (Exim 1.90 #1) for ipng@sunroof.eng.sun.com id 104mg1-00014g-00; Mon, 25 Jan 1999 14:07:41 +0000 Received: from ally ([155.198.133.9] helo=ally.ee.ic.ac.uk) by eecfsag2.ee.ic.ac.uk with esmtp (Exim 1.90 #1) id 104mfz-00051n-00; Mon, 25 Jan 1999 14:07:39 +0000 From: "ya" To: Subject: (IPng 7088) Setting up the H/W for IPv6 implementation and test environments Date: Mon, 25 Jan 1999 14:11:39 -0000 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@sunroof.eng.sun.com Precedence: bulk Hi there, In our section we are looking at setting up the required H/W for IPv6 implementation and test environments. My question is what are the equipment needed to set up such a test bed? Do I only need a router on the backbone and a hub on each segment/subnet? Do I need anything else? Any suggestions to which vendor? I am looking at the 3com NetBuilder II for the router and SuperStack II Fast Ethenet Hub? Has anyone used these? Than you in advance, awaiting any replies. Regards. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 26 11:30:58 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id LAA00577 for ipng-dist; Tue, 26 Jan 1999 11:18:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id LAA00548; Tue, 26 Jan 1999 11:15:45 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA28104; Tue, 26 Jan 1999 11:15:41 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA19113; Tue, 26 Jan 1999 11:15:42 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id OAA29347; Tue, 26 Jan 1999 14:15:39 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000019871; Tue, 26 Jan 1999 14:15:39 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id OAA0000028045; Tue, 26 Jan 1999 14:15:38 -0500 (EST) From: Jim Bound Message-Id: <199901261915.OAA0000028045@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com, 6bone@isi.edu, ngtrans@sunroof.eng.sun.com cc: v6-deployment-cabal@alpha.zk3.dec.com Subject: (IPng 7090) V6 Deployment 3rd Day Final Agenda Date: Tue, 26 Jan 1999 14:15:38 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk === Thursday, February 4 -- IPv6 Deployment and Promotion ----------------------------------------------------- The purpose of this day will be to review current deployment activities, potential additional efforts, and opportunities for educating and influencing developers, ISPs, network managers, and users. This will include answering the following questions: - Why would anyone run IPv6 now? - Why would anyone ever run IPv6? - Who will deploy IPv6 first? - Will the Internet lead Corporate networks or follow as IPv6 is deployed? - How to get ISPs to deploy IPv6? We would like to request that each attendee come with answers to the above questions for discussion on this 3rd day. This is the Final Agenda before Grenbole. We will do Agenda Bashing at Grenoble and select order and times. Agenda: (1) Discussion of the questions above. (2) Existing deployment efforts: - 6BONE (who?) - 6REN (who?) (3) Potential efforts: - IPv6 Exchanges (who?) - Corporate Plans (who?) - ISP Plans (who?) - ... (4) Promotion - IPv6.org (who?) - Influencing developers, vendors, etc. (who?) (5) Presentations: - Bob Fink - 6REN and 6TAP - Jim Bound - The Palo Alto Gateway and IPv6 and sub-TLA Request Strategy - Marc Blanchet - IPv6 Deployment Issues - Henk Steenman - Amsterdam Internet Exchange (AMS-IX) native IPv6 environment - Jim Bound for Perry Metzger - Status of the V6 Deployment List Activities - Jun Murai - IPv6 Deployment in Japan - Paula Caslav - Proposed Guidelines RIPE NCC Regional Registries for IPv6 (6) Public Domain Code Needs for IPv6 Discussion - Appache Web Server - Sendmail - BIND - BSD Network Utilities thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 26 13:49:11 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id NAA00905 for ipng-dist; Tue, 26 Jan 1999 13:39:35 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id NAA00867; Tue, 26 Jan 1999 13:35:30 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA11522; Tue, 26 Jan 1999 13:35:30 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA22386; Tue, 26 Jan 1999 13:34:54 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id NAA27770; Tue, 26 Jan 1999 13:25:51 -0800 (PST) Message-Id: <3.0.5.32.19990126132452.00917530@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 26 Jan 1999 13:24:52 -0800 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7092) Current Agenda for First Day of IPng Interim Meeting Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Attached is the current agenda for the first day of the interim IPng and NGTRANS working group meetings, February 2-4, in Grenoble, France. Please send requests for changes to hinden@iprg.nokia.com and deering@cisco.com. *** Note 1 *** Several folks sent suggested agenda additions already, but in some cases, it was not clear which of the three days those topics best belonged to. If you sent a suggestion, and it has not appeared on any of the three agendas, please resend to the appropriate chair(s): Day 1: IPng working group (Deering & Hinden) Day 2: NGtrans working group (Fink & Hain) Day 3: Deployment & promotion (Bound) Also, there will be a chance to adjust the agendas further on the meeting days themselves, of course. *** Note 2 *** For the first day, we have written down some names of folks to lead discussions on particular topics. If one of those names is yours, and you don't want to lead those discussions, please let us know. Thanks, Bob Hinden Steve Deering Tuesday, February 2 -- IPng w.g. meeting ---------------------------------------- Purpose: The IPng w.g. has mostly completed its original charter, except for shepherding the many w.g. specs through the final stages of Internet Standardization. The purposes of this meeting are: (a) to review the state of our many documents to identify any holes or loose ends that must be finished up to complete our charter, and (b) to identify and discuss new IPv6-related topics that the attendees think should be taken on by the IETF or the IRTF (Internet Research Task Force), either in the current working group or in other working groups / research groups. Requirements for Attendees: **NOTE** All attendees are required to bring a short list (one to five items, on a single sheet of paper) of topics that they consider the most important IPv6-related topics for the IETF or IRTF to work on. Agenda: o Introduction (S. Deering) o Local arrangements (A. Durand) o Collect attendee required issue lists (S. Deering) o Review and update agenda (S. Deering) o Review state/completeness of current IPv6-related protocols (B. Hinden) - IPv6 Protocols o Base Protocol o Addressing o ICMP, Neighbor discovery, auto config, MLD o IPover, Header compression o DNS o MIB's o Path MTU o Router Alert o Jumbograms - API's - Routing Protocols (Unicast and Multicast) - DHCP - IP Mobility o Identify important new IPv6 protocol/standards work - State of Plug-and-Play (B. Hinden) o "Dentist's office" o Secure "Dentist's office" - Securing ICMP/ND/MLD (S. Deering) - Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) - Better Support for Multihomed Hosts (R. Draves) - Better Support for Multihomed Sites (E. Nordmark) - Privacy issues with use of EUI-64 IDs (T. Narten) - Source and Destination Address Selection (T. Narten) - Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) (3) Formulate recommendations to the IESG/IAB, re future IPv6 work (S. Deering, B. Hinden) - Disposition of IPng w.g. (extend charter? go on hiatus?) - Distribution of work to other existing WGs? - Evaluation of all IETF protocols for "IPv6-readiness"? - Recommendations for establishing new WG(s) or RG(s)? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 26 15:48:46 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id PAA01141 for ipng-dist; Tue, 26 Jan 1999 15:40:16 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id PAA01134 for ; Tue, 26 Jan 1999 15:40:06 -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 PAA20661 for ; Tue, 26 Jan 1999 15:40:06 -0800 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id PAA07098 for ; Tue, 26 Jan 1999 15:40:06 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Tue, 26 Jan 1999 15:35:01 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81BCF@RED-MSG-50> From: Richard Draves To: "'IPng List'" Cc: "'6bone'" <6bone@isi.edu>, "'MSR IPv6 Discussion'" Subject: (IPng 7093) MSR IPv6 Release 1.2 Date: Tue, 26 Jan 1999 15:34:58 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Microsoft Research and ISI East are pleased to announce Release 1.2 of our MSR IPv6 stack for Windows NT. See http://www.research.microsoft.com/msripv6 for more details and download information. Some highlights: - Source and binaries are freely available. - Full support for the core (draft standard) IPv6 specs. - Routing (with static routing tables) and sending Router Advertisements. You can use an MSR IPv6 machine to connect a local network to the 6bone. - Web support, with a port of Internet Explorer and a free web server called Fnord!. Check out http://ipv6.research.microsoft.com, a v6-only web site on the 6bone. - Ports of SDR and RAT (multicast multimedia applications), thanks to the help of UCL. - A v6/v4 address/protocol translator, in cooperation with UW. - Correspondence with mobile IPv6 nodes. To support developers, we're going to start daily source drops. Send email to msripv6-bugs@list.research.microsoft.com to request more information about the daily source drops. See http://list.research.microsoft.com/archives/msripv6-users.html to join our discussion list or search the archives. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 26 16:43:38 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id QAA01209 for ipng-dist; Tue, 26 Jan 1999 16:31:40 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id QAA01202 for ; Tue, 26 Jan 1999 16:31:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA16170 for ; Tue, 26 Jan 1999 16:31:28 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA10516 for ; Tue, 26 Jan 1999 16:31:25 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA25931; Tue, 26 Jan 1999 16:25:10 -0800 (PST) X-Sender: deering@postoffice Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Jan 1999 16:25:21 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 7094) the task of discussion leaders for Tuesday's meeting Cc: Bob Hinden Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you are one of the lucky folks named, or planning to volunteer, as a discussion leader for the "Identify important new IPv6 protocol/standards work" part of Tuesday's IPng WG meeting, and are wondering what a discussion leader is expected to do, here's an answer: Describe the issue/problem, and its significance. Identify known solutions, possible solutions, or possible directions in which solutions might be found. Express an opinion about whether or not the solution(s) require new research, new architecture, new protocol(s), or new operational methods. Solicit input on the above from the meeting attendees. And be prepared to do all of that in as little as 15 minutes (worst case), if necessary. The goal of the exercise is to decide on what action should be taken to address the issue/problem: do nothing? add as a work item to an existing WG? form a new WG? delegate to an IRTF research group? something else? Do not expect to reach agreement on the solution to the problem within the time allotted on the Grenoble agenda (though maybe agreement will be arrived at in the hallways/restaurants/bars sometime during the three days). Any questions, please let us know. Steve Deering Bob Hinden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 26 16:43:45 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id QAA01223 for ipng-dist; Tue, 26 Jan 1999 16:36:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id QAA01192; Tue, 26 Jan 1999 16:28:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA29460; Tue, 26 Jan 1999 16:28:17 -0800 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id QAA08316; Tue, 26 Jan 1999 16:28:18 -0800 (PST) Received: from rasp1-23.lbl.gov (pinnacle) [131.243.212.223] by mail1.es.net with smtp (Exim 1.81 #2) id 105Iq9-0007OT-00; Tue, 26 Jan 1999 16:28:17 -0800 Message-Id: <4.1.19990126162149.00942820@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 26 Jan 1999 16:26:59 -0800 To: ngtrans@sunroof.eng.sun.com, IPng List From: Bob Fink Subject: (IPng 7095) Current NGtrans agenda for 2nd day of Grenoble interim meetings Cc: Bob Fink , Tony Hain Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NGtrans Folk, Below is the current, and final pre-meeting, NGtrans agenda for the 2nd day of the Grenoble interim meetings. We can still alter the agenda at the meeting. As Bob and Steve are doing for the IPng interim meeting, we would like to assign an assignment for attendees, so please read below. Thanks, Tony and Bob ------------------------------------------------------ Wednesday, February 3 -- NGtrans working group meeting ------------------------------------------------------ Purpose: The NGtrans working group has developed a large set of transition tools including the original transition mechanisms (i.e., dual stack w/IPv6 over IPv4 tunneling), 6over4 without explicit tunnels, translation, and other tunneling techniques. The purpose of the meeting is for the working group to converge on a smaller set of tools and mechanisms. The meeting will include discussing specific transition scenarios and evaluating how the current transition tools and mechanism work in these environments. Requirements for Attendees: **NOTE** All attendees are required to bring two lists, hopefully each on a single sheet of paper, as follows: 1. how you would evaluate the various transition tools/mechanisms under agenda item (2). 2. your favorite (i.e., most important) transition scenario to provide for under agenda item (4). Agenda: (1) Review NGtrans mission and charter (brief) - Bob Fink (2) Review transition tools/mechanism and how to evaluate them - Jim Bound with help from various authors as needed (Cyndi Jung, Kazuaki Tsuchiya, etc.) (3) Discuss specific transition scenarios - Tony Hain with help from various folk (Jim Bound, etc.) (4) Evaluate tools/mechanisms against transition scenarios to establish which to converge on - Bob Fink/Tony Hain (5) NGtrans mission and charter reprise (wrapup) - Tony Hain -end -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 26 21:31:50 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id VAA01404 for ipng-dist; Tue, 26 Jan 1999 21:22:23 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id VAA01397 for ; Tue, 26 Jan 1999 21:22:14 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA00393 for ; Tue, 26 Jan 1999 21:22:14 -0800 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA26913 for ; Tue, 26 Jan 1999 21:22:14 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Tue, 26 Jan 1999 21:22:10 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81BE3@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 7096) RE: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt Date: Tue, 26 Jan 1999 21:22:07 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There's an interesting (to me at least) issue that arises when a node supports both 6over4 and configured tunnels. The problem is demultiplexing received encapsulated packets (v6 packet encapsulated in a v4 packet) to the proper interface in the v6 implementation. This is 95% an implementation issue, but I suspect it's common to many implementations and there's also an operational element involved. So I hope this note proves at least mildly interesting to some. A node that supports 6over4 will have a logical or virtual interface for the 6over4 link. (To simplify the discussion, let's just consider nodes with a single physical interface, eg, ethernet.) The virtual 6over4 interface will behave in the implementation exactly like a real physical interface. A node that expects to receive packets sent to it via configured tunnels will probably have an interface, call it the tunnel interface. The encapsulated packets will be "received by" the tunnel interface. The tunnel interface might be just an implementation convenience but it can have addresses assigned to it. Why does it matter what interface "receives" a packet? For example, it makes a difference if the receiving node needs to generate an ICMP error in response. The ICMP error will take a source address from the receiving interface. It makes a difference for IPsec - there's an inbound policy check in the Security Policy Database, which is per-interface. There may be other implementation-specific reasons why it's important to figure out which interface is receiving a packet. Now when this node receives an encapsulated packet, should the 6over4 interface or the tunnel interface be considered the receiving interface? The information available to make this decision is the v4 source & destination and the v6 source and destination. The v6 source and destination are no help, in general. For example the v6 destination might not be assigned to any of the node's interfaces if the node is a router, and similarly the v6 source might be anything if the sending node is a v6 router. The v4 destination is no help, in general. If it's a 6over4 link-layer multicast address, then the packet can be assigned to the 6over4 interface. But in general the v4 destination will just be the node's v4 unicast address. This leaves us with the v4 source address. Recall that configured tunnels are nominally unidirectional - if A has a configured tunnel to B then A knows B's v4 address but not vice-versa. The configured tunnel requires configuration of A but not of B. Suppose that configured tunnels were "biconfigured", so A & B both know each other's v4 address. Now B has a way of demultiplexing encapsulated packets - if they're from A, assign them to the tunnel interface, otherwise assign them to the 6over4 interface. So my conclusion is that one solution to making 6over4 and configured tunnels work together in an implementation, is to have configured tunnels be "biconfigured" so recipients know about sources. Another possibility is to have a single interface receiving all encapsulated traffic. But then this single interface will also be sending both 6over4 and configured tunnel traffic. This might be awkward for the implementation because the 6over4 traffic uses Neighbor Discovery and the configured tunnel traffic does not. It also means that the implementation can't have separate IPsec SPDs for 6over4 and configured tunnel traffic. >From this IPsec/administrative point of view, it might be useful to have multiple tunnel interfaces, one for each configured tunnel over which the implementation is sending or receiving. And use the v4 source/destination addresses to demultiplex received traffic to the appropriate tunnel interface. This would support configured tunnels as a bidirectional construct, instead of purely a unidirectional construct. Anyway, I'm curious what other implementations do. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 26 23:02:37 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id WAA01445 for ipng-dist; Tue, 26 Jan 1999 22:52:38 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id WAA01438 for ; Tue, 26 Jan 1999 22:52:22 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA10560 for ; Tue, 26 Jan 1999 22:52:22 -0800 Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA14152 for ; Tue, 26 Jan 1999 22:52:22 -0800 (PST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id WAA08924; Tue, 26 Jan 1999 22:51:43 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id WAA02338; Tue, 26 Jan 1999 22:51:42 -0800 (PST) Received: from tellurium (lan-isdn-cmj3.nsd.3com.com [129.213.207.235]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id WAA21582; Tue, 26 Jan 1999 22:51:42 -0800 (PST) Message-Id: <3.0.2.32.19990126224927.00b5e870@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Tue, 26 Jan 1999 22:49:27 -0800 To: Richard Draves From: Cyndi Jung Subject: (IPng 7098) Re: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81BE3@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:22 PM 1/26/99 -0800, you wrote: >There's an interesting (to me at least) issue that arises when a node >supports both 6over4 and configured tunnels. > [much good stuff deleted] >Another possibility is to have a single interface receiving all encapsulated >traffic. But then this single interface will also be sending both 6over4 and >configured tunnel traffic. This might be awkward for the implementation >because the 6over4 traffic uses Neighbor Discovery and the configured tunnel >traffic does not. It also means that the implementation can't have separate >IPsec SPDs for 6over4 and configured tunnel traffic. You wouldn't want to put these into the same tunnel interface. The 6over4 is a fairly "local area" IPv6 subnet, spanning several IPv4 subnets that are all within the same administrative scope for IPv4 multicast. The configured tunnels would be with IPv6 routers in other domains, beyond the scope of the Neighbor Discovery protocol. These could conceivably use the same source IPv4 address locally - the destination IPv4 address would be the distinguishing piece of information. > >>From this IPsec/administrative point of view, it might be useful to have >multiple tunnel interfaces, one for each configured tunnel over which the >implementation is sending or receiving. And use the v4 source/destination >addresses to demultiplex received traffic to the appropriate tunnel >interface. This would support configured tunnels as a bidirectional >construct, instead of purely a unidirectional construct. > I would expect that in usage, the configured tunnels end up being bidirectional, even if the routing isn't symmetric. >Anyway, I'm curious what other implementations do. > So am I, Cyndi >Thanks, >Rich >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 27 08:39:09 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA01752 for ipng-dist; Wed, 27 Jan 1999 08:30:15 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA01744 for ; Wed, 27 Jan 1999 08:30:05 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA27274 for ; Wed, 27 Jan 1999 08:30:03 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA22214 for ; Wed, 27 Jan 1999 08:30:03 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25356; Wed, 27 Jan 1999 11:29:59 -0500 (EST) Message-Id: <199901271629.LAA25356@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7100) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-06.txt Date: Wed, 27 Jan 1999 11:29:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-new-06.txt Pages : 33 Date : 26-Jan-99 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-bsd-api-new-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-bsd-api-new-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990126151100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-new-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990126151100.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 27 08:55:30 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA01783 for ipng-dist; Wed, 27 Jan 1999 08:46:36 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA01762; Wed, 27 Jan 1999 08:44:05 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA03944; Wed, 27 Jan 1999 08:44:03 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA03818; Wed, 27 Jan 1999 08:44:02 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA19496; Wed, 27 Jan 1999 08:43:57 -0800 (PST) X-Sender: deering@postoffice Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Jan 1999 08:44:08 -0800 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 7101) start time of Grenoble meetings Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The IPv6 meetings on Feb 2, 3, and 4 will start at 9:00 am each day. Steve (for the 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 Wed Jan 27 09:21:14 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA01808 for ipng-dist; Wed, 27 Jan 1999 09:11:41 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id JAA01801 for ; Wed, 27 Jan 1999 09:11:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA27911 for ; Wed, 27 Jan 1999 09:11:16 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA27926 for ; Wed, 27 Jan 1999 09:11:03 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA20235 for ; Wed, 27 Jan 1999 11:10:57 -0600 (CST) Message-Id: <199901271710.LAA20235@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 7102) New draft of router-renumbering Date: Wed, 27 Jan 1999 11:10:57 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted a new router renumbering draft (-07). Changes are as follows: A little tightening up of the "ignored on receipt" clauses for reserved fields and flags which have no meaning in context. Fixed the text about the flags field, which had gotten out of sync with the diagram and descriptions. Gave word-names to the flags for easier reference. Specified that the response delay timer should start running after processing, not before. (Although I presume this is obvious to the capable implementor.) Clarified that new auth. keys may already be available when old keys are invalidated. Added to the IANA considerations pointers to the sections defining allocatable fields. ** Added, at IESG request, a new, large section called "Implementation and Usage Advice" which spells out a method for deciding when a certain confidence level has been achieved that all managed routers have received & processed a command. If anyone wants to see how it works, I have a quick-and-dirty simulator code. ** (I imagine someone somewhere has invented this before. If not, it may be worth publishing separately as an informational document.) Updated all the references -- none are internet-drafts any more. 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 Jan 27 09:21:29 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA01817 for ipng-dist; Wed, 27 Jan 1999 09:14:50 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id JAA01810 for ; Wed, 27 Jan 1999 09:14:45 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id JAA19867 for ; Wed, 27 Jan 1999 09:14:48 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA14593 for ipng@sunroof.eng.sun.com; Wed, 27 Jan 1999 09:13:45 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id WAA01421 for ; Tue, 26 Jan 1999 22:06:22 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA03176 for ; Tue, 26 Jan 1999 22:06:03 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA20704 for ; Tue, 26 Jan 1999 22:06:04 -0800 (PST) Received: from brakescr.iprg.nokia.com (brakescr.iprg.nokia.com [205.226.1.186]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id WAA21146; Tue, 26 Jan 1999 22:06:03 -0800 (PST) Received: from brakescr.iprg.nokia.com (localhost.iprg.nokia.com [127.0.0.1]) by brakescr.iprg.nokia.com (8.8.8/8.6.12) with ESMTP id WAA11759; Tue, 26 Jan 1999 22:07:18 -0800 (PST) Message-Id: <199901270607.WAA11759@brakescr.iprg.nokia.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Richard Draves cc: "'IPng List'" Subject: (IPng 7103) Re: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt In-reply-to: Your message of "Tue, 26 Jan 1999 21:22:07 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF81BE3@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Jan 1999 22:07:18 -0800 From: Peter Grehan Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Anyway, I'm curious what other implementations do. This problem also applies to ipv4 DVMRP tunnels, and in that case, our implementation uses a configured v4 src/dst and is assumed bi-directional for the reasons you mentioned. Also, routing protocols assume that links are symmetrical, so if you want to run routing over a tunnel, it is required to be bidirectional. Another compelling reason is that at some stage, the tunnels usually go through a firewall, and f/w admins don't like to configure wildcard sources in their rulebases. later, Peter. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 27 10:27:01 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id KAA01913 for ipng-dist; Wed, 27 Jan 1999 10:19:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id KAA01906 for ; Wed, 27 Jan 1999 10:19:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA25793 for ; Wed, 27 Jan 1999 10:19:16 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA26865 for ; Wed, 27 Jan 1999 10:19:11 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA01734; Wed, 27 Jan 1999 10:19:01 -0800 (PST) X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81BE3@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Jan 1999 10:19:12 -0800 To: Richard Draves From: Steve Deering Subject: (IPng 7104) Re: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt Cc: "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:22 PM -0800 1/26/99, Richard Draves wrote: > This leaves us with the v4 source address. Recall that configured tunnels > are nominally unidirectional - if A has a configured tunnel to B then A > knows B's v4 address but not vice-versa. The configured tunnel requires > configuration of A but not of B. Suppose that configured tunnels were > "biconfigured", so A & B both know each other's v4 address. Rich, Whether or not both ends of a tunnel are configured to know about the other end is orthogonal to whether or not the tunnel is unidirectional. In other words, you might well configure the receive end of unidirectional tunnel to know the address of the sending end. For a tunneled packets that arrives on an "unknown" tunnel (i.e., from an encapsulating source address that has not been configured), it should probably be a local configuration choice whether to drop such a packet or to instantiate a new virtual interface for the newly-discovered tunnel. (The local configuration variable might be called something like "tunnel-promiscuous". It's not immediately clear to me what the default value of that variable should be. Perhaps promiscuous for routers and non-promiscuous for hosts?) I think it is architecturally cleanest if the endpoint of each tunnel is treated as a separate virtual interface, rather than having a single virtual interface for all tunnels originating or terminating at a node. You listed some of the problems with the later approach. Different tunnels can be distinguished from each other by the type of the encapsulating header (e.g., IPv4 vs. IPv6) and by the addresses in that encpasulating header: - point-to-point tunnels are identified by the encapsulating source and destination unicast addresses. - multi-access tunnels are identified by the encapsulating destination multicast address alone. A separate attribute of a tunnel virtual interface is whether it is unidirectional-incoming, unidirectional-outgoing, or bidirectional (anologous to unidirectional and bidirectional physical interfaces). That attribute is set at tunnel configuration time. (Inconsistent configuration of different ends of the same tunnel is analogous to having a broken physical interface.) For dynamically-established tunnel interfaces (through promiscuous tunnel acceptance), the attribute is set to unidirectional-incoming. How does that sound? 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 Wed Jan 27 14:30:48 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id OAA02238 for ipng-dist; Wed, 27 Jan 1999 14:25:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id OAA02231 for ; Wed, 27 Jan 1999 14:25:10 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id OAA05798; Wed, 27 Jan 1999 14:25:09 -0800 (PST) Date: Wed, 27 Jan 1999 14:23:50 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7105) Re: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt To: Richard Draves Cc: "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF81BE3@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't think this issue needs to be discussed in the draft. It is all implementation issues. > There's an interesting (to me at least) issue that arises when a node > supports both 6over4 and configured tunnels. > > The problem is demultiplexing received encapsulated packets (v6 packet > encapsulated in a v4 packet) to the proper interface in the v6 > implementation. This is 95% an implementation issue, but I suspect it's > common to many implementations and there's also an operational element > involved. So I hope this note proves at least mildly interesting to some. > Now when this node receives an encapsulated packet, should the 6over4 > interface or the tunnel interface be considered the receiving interface? Even though we haven't built 6over4 we have a similar issue with configured and automatic tunnels. Basically we assume that the configured tunnels, while not necessarily bidirectional, have a counterpart at the other end. For router-router tunnels you end with pairs of configured tunnels. (You need something like that in any case as pointed out in draft-ietf-ngtrans-mech-01.txt to not make tunneling be a tool to circumvent ingress filtering.) When a packet is received we first check for configured tunnels using the IPv4 source and destination. If they match a configured tunnel we pass the packet to that pseudo interface. If it doesn't match any configured tunnel we look for an automatic (and in the future 6over4) tunnel pseudo-interface where we just match on the local IPv4 address. This allows simple things like N different configured tunnels (perhaps with different security policy) together with 1 automatic tunnel OR 1 6over4 tunnel. But we can't do multiple 6over4 pseudo interfaces unless we node has multiple local IPv4 addresses. I think that's all that can be done unless you get something like VLAN support in 6over4 (some tag in the packet which identifies the virtual 6over4 LAN) which would be overkill. Except for configured tunnels I don't expect machines to have more than one "encapsulate in IPv4" tunnel per physical interface. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 27 18:09:33 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id SAA02433 for ipng-dist; Wed, 27 Jan 1999 18:04:24 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id SAA02426; Wed, 27 Jan 1999 18:04:15 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA18770; Wed, 27 Jan 1999 18:04:15 -0800 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id SAA01267; Wed, 27 Jan 1999 18:04:15 -0800 (PST) Received: from pinnacle.wins.lbl.gov (pinnacle) [128.3.9.220] by mail1.es.net with smtp (Exim 1.81 #2) id 105goX-0005g9-00; Wed, 27 Jan 1999 18:04:13 -0800 Message-Id: <4.1.19990127180116.0091d540@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 27 Jan 1999 18:04:07 -0800 To: IPng List , ngtrans@sunroof.eng.sun.com From: Bob Fink Subject: (IPng 7106) projection equipment at the IPv6 Interim meetings Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenoble Interim Meeting folk: There will be PC LCD projection equipment available to us in addition to the usual overhead transparency projector. Alain will have plenty of blank plastic and pens available as well. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 27 18:51:26 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id SAA02503 for ipng-dist; Wed, 27 Jan 1999 18:46:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id SAA02496; Wed, 27 Jan 1999 18:46:40 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA09844; Wed, 27 Jan 1999 18:46:35 -0800 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA00715; Wed, 27 Jan 1999 18:46:05 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id LAA00628; Thu, 28 Jan 1999 11:45:54 +0900 (JST) To: ngtrans@sunroof.eng.sun.com cc: IPng List In-reply-to: fink's message of Wed, 27 Jan 1999 18:04:07 PST. <4.1.19990127180116.0091d540@imap2.es.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 7107) Re: (ngtrans) projection equipment at the IPv6 Interim meetings From: Jun-ichiro itojun Hagino Date: Thu, 28 Jan 1999 11:45:54 +0900 Message-ID: <625.917491554@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Grenoble Interim Meeting folk: >There will be PC LCD projection equipment available to us in addition to >the usual overhead transparency projector. Could you please tell us the resolution? 640x480 or 800x600? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 27 22:17:52 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id WAA02673 for ipng-dist; Wed, 27 Jan 1999 22:07:29 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id WAA02666 for ; Wed, 27 Jan 1999 22:07:12 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA11410 for ; Wed, 27 Jan 1999 22:07:12 -0800 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA05058 for ; Wed, 27 Jan 1999 22:07:12 -0800 (PST) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Wed, 27 Jan 1999 22:07:13 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81C08@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 7109) Re: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt Date: Wed, 27 Jan 1999 22:07:11 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, I think in our next MSR IPv6 release I'll change the tunnel code so that each configured tunnel gets a separate pseudo-interface and the receiving end of a configured tunnel is configured to know about the sending end. This will solve the demultiplexing problem wrt 6over4 and make it possible for administrators to put separate IPsec policies on the different configured tunnels. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 27 23:10:57 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id XAA02712 for ipng-dist; Wed, 27 Jan 1999 23:07:15 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id XAA02705 for ; Wed, 27 Jan 1999 23:07:06 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA19586 for ; Wed, 27 Jan 1999 23:07:06 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA00134 for ; Wed, 27 Jan 1999 23:07:07 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 27 Jan 1999 23:07:06 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81C09@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 7111) host vs router Date: Wed, 27 Jan 1999 23:07:05 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was thinking recently about the terms "host" and "router", particularly as they are used in RFC 2461 (Neighbor Discovery). A router is defined as a node that forwards packets not addressed to itself. A host is defined as a node that's not a router. I think it's pretty clear that a multi-homed node might behave as a router on some interfaces and behave as a host on other interfaces. So host vs router is really a property of an interface. However for simplicity we normally say "host" instead of "interface acting as a host" and "router" instead of "interface acting as a router". In addition to forwarding packets, routers typically also send Router Advertisements ("advertise"). I think it's pretty clear that forwarding and advertising are separate and orthogonal properties of an interface. You can have an interface that forwards without advertising, or advertises without forwarding. See section 6.2.5. Because being a router is equated with forwarding, this means you can have a router that doesn't advertise or a host that does advertise. (When a host sends a Router Advertisement, the router lifetime in the RA will be zero.) Then in section 6.2.6, the spec says A host MUST silently discard any received Router Solicitation messages. But surely a node that is not forwarding but is advertising should be allowed to respond to Router Solicitations? It would seem very strange to be sending unsolicited Router Advertisements and be prohibited from sending solicited Router Advertisements. In section 6.2.2, the spec says The term "advertising interface" refers to any functioning and enabled multicast interface that has at least one unicast IP address assigned to it and whose corresponding AdvSendAdvertisements flag is TRUE. A router MUST NOT send Router Advertisements out any interface that is not an advertising interface. Since advertising is orthogonal to forwarding (being a host or a router), shouldn't the last prohibition apply to hosts as well as routers? In section 6.2.2, the spec says A router MUST join the all-routers multicast address on an advertising interface. Routers respond to Router Solicitations sent to the all-routers address and verify the consistency of Router Advertisements sent by neighboring routers. In section 6.2.5, talking about an interface ceasing to advertise, the spec says In such cases the router SHOULD transmit one or more (but not more than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router Advertisements on the interface with a Router Lifetime field of zero. In the case of a router becoming a host, the system SHOULD also depart from the all-routers IP multicast group on all interfaces on which the router supports IP multicast (whether or not they had been advertising interfaces). In addition, the host MUST insure that subsequent Neighbor Advertisement messages sent from the interface have the Router flag set to zero. I find the description of the all-routers multicast address to be confusing. Wouldn't it be simpler to say that an advertising interface (whether or not it is forwarding, ie, is a host or a router) MUST join the all-routers multicast address, and an interface that ceases to advertise SHOULD depart from it (whether or not it is forwarding)? That seems to be the right definition, given how the all-routers multicast address is used, although it makes the name "all-routers" a little strange :-). Now whenever I look at the spec and see something about what a router or a host should or should not do, I wonder if it means forwarding interfaces or advertising interfaces or what. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 27 23:54:23 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id XAA02743 for ipng-dist; Wed, 27 Jan 1999 23:48:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id XAA02736 for ; Wed, 27 Jan 1999 23:48:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA02066 for ; Wed, 27 Jan 1999 23:48:16 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA20378 for ; Wed, 27 Jan 1999 23:48:18 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA20691; Wed, 27 Jan 1999 23:48:13 -0800 (PST) X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81C09@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Jan 1999 23:48:25 -0800 To: Richard Draves From: Steve Deering Subject: (IPng 7112) Re: host vs router Cc: "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:07 PM -0800 1/27/99, Richard Draves wrote: > I think it's pretty clear that a multi-homed node might behave as a router > on some interfaces and behave as a host on other interfaces. So host vs > router is really a property of an interface. However for simplicity we > normally say "host" instead of "interface acting as a host" and "router" > instead of "interface acting as a router". Rich, This nuance is mentioned in the base IPv6 spec, as a footnote in Section 2 (Terminology): Note: it is possible, though unusual, for a device with multiple interfaces to be configured to forward non-self-destined packets arriving from some set (fewer than all) of its interfaces, and to discard non-self-destined packets arriving from its other interfaces. Such a device must obey the protocol requirements for routers when receiving packets from, and interacting with neighbors over, the former (forwarding) interfaces. It must obey the protocol requirements for hosts when receiving packets from, and interacting with neighbors over, the latter (non-forwarding) interfaces. > I think it's pretty clear that forwarding and advertising are separate and > orthogonal properties of an interface. I disagree that those properties are orthogonal. Only router (forwarding) interfaces are (or ought to be) allowed to send Router Advertisements. I thought that was explicitly stated somewhere (it's been a loooong time since I've read the ND spec). As I recall, the Neighbor Advertisement has a router/host flag specifically for the purpose of allowing a former routing interface (i.e., an interface that was recently in forwarding mode) to be able to indicate that it is no longer a forwarding interface, something it cannot do via Router Advertisments because sending a router advertisement implies that the sender is a router (forwarder). > You can have an interface that forwards without advertising, or advertises > without forwarding. See section 6.2.5. Then that's a bug. Forwarding without advertising is OK, but advertising when not enabled for forwarding is not OK. > Because being a router is equated with forwarding, this means you can have a > router that doesn't advertise or a host that does advertise. (When a host > sends a Router Advertisement, the router lifetime in the RA will be zero.) That lifetime field is the remaining time that the sender may be considered a *default* router. A Router Advertisement carrying a zero lifetime means the sender is able to forward packets, but must not be used as anyone's default router, i.e., it is only to be used as a result of Redirects or manual configuration. > Then in section 6.2.6, the spec says > A host MUST silently discard any received Router Solicitation messages. > > But surely a node that is not forwarding but is advertising should be > allowed to respond to Router Solicitations? It would seem very strange to be > sending unsolicited Router Advertisements and be prohibited from sending > solicited Router Advertisements. I contend that hosts (non-forwarding interfaces) should never send Router Advertisements, in which case, the above strangeness does not occur. > In section 6.2.2, the spec says > The term "advertising interface" refers to any functioning and > enabled multicast interface that has at least one unicast IP address > assigned to it and whose corresponding AdvSendAdvertisements flag is > TRUE. A router MUST NOT send Router Advertisements out any interface > that is not an advertising interface. > > Since advertising is orthogonal to forwarding (being a host or a router), > shouldn't the last prohibition apply to hosts as well as routers? Since the predicate of that sentence is false, no. > I find the description of the all-routers multicast address to be confusing. > Wouldn't it be simpler to say that an advertising interface (whether or not > it is forwarding, ie, is a host or a router) MUST join the all-routers > multicast address, and an interface that ceases to advertise SHOULD depart > from it (whether or not it is forwarding)? That seems to be the right > definition, given how the all-routers multicast address is used, although it > makes the name "all-routers" a little strange :-). All becomes un-strange if you retrict Router Advertisements to routers only. > Now whenever I look at the spec and see something about what a router or a > host should or should not do, I wonder if it means forwarding interfaces or > advertising interfaces or what. Forwarding interfaces. 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 Jan 28 04:19:13 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id EAA02886 for ipng-dist; Thu, 28 Jan 1999 04:16:15 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id EAA02879 for ; Thu, 28 Jan 1999 04:16:06 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA17400 for ; Thu, 28 Jan 1999 04:16:05 -0800 Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA27228 for ; Thu, 28 Jan 1999 04:16:05 -0800 (PST) Received: from hygro.raleigh.ibm.com (hygro.adsl.duke.edu [152.16.67.44]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id HAA10003; Thu, 28 Jan 1999 07:16:01 -0500 (EST) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.8.7/8.7.3) with ESMTP id HAA00822; Thu, 28 Jan 1999 07:18:14 -0500 Message-Id: <199901281218.HAA00822@hygro.raleigh.ibm.com> To: Steve Deering cc: Richard Draves , "'IPng List'" Subject: (IPng 7114) Re: host vs router In-Reply-To: Message from Steve Deering of "Wed, 27 Jan 1999 23:48:25 PST." Date: Thu, 28 Jan 1999 07:18:13 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Couple of small clarifications. > > You can have an interface that forwards without advertising, or advertises > > without forwarding. See section 6.2.5. > Then that's a bug. Forwarding without advertising is OK, but advertising > when not enabled for forwarding is not OK. It is possible to send out RAs with a Lifetime of zero. In such cases, the router has an "advertising interface". However, the router is not forwarding packets or being a default router. This allows a router to send RA Options (e.g., prefix information) without having be a default router. > > Because being a router is equated with forwarding, this means you can have a > > router that doesn't advertise or a host that does advertise. (When a host > > sends a Router Advertisement, the router lifetime in the RA will be zero.) > That lifetime field is the remaining time that the sender may be > considered a *default* router. A Router Advertisement carrying a > zero lifetime means the sender is able to forward packets, but must > not be used as anyone's default router, i.e., it is only to be used as > a result of Redirects or manual configuration. Actually, the wording in the spec says that if you receive a RA with a lifetime of zero, two things happen: 1) remove the router from the default list 2) update the neighbor cache so that all entries using that router perform next-hop resolution over again. In this case of a router being removed from the default list, another router will be selected. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 28 07:37:53 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA03085 for ipng-dist; Thu, 28 Jan 1999 07:35:20 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA03074 for ; Thu, 28 Jan 1999 07:35:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA18722 for ; Thu, 28 Jan 1999 07:34:58 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA10808 for ; Thu, 28 Jan 1999 07:34:59 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA26762; Thu, 28 Jan 1999 10:34:54 -0500 (EST) Message-Id: <199901281534.KAA26762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7117) I-D ACTION:draft-ietf-ipngwg-router-renum-07.txt Date: Thu, 28 Jan 1999 10:34:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-07.txt Pages : 26 Date : 27-Jan-99 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ('RR') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-router-renum-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990127171406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990127171406.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 Thu Jan 28 07:37:54 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA03086 for ipng-dist; Thu, 28 Jan 1999 07:35:26 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA03070 for ; Thu, 28 Jan 1999 07:34:52 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA18710 for ; Thu, 28 Jan 1999 07:34:50 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA10742 for ; Thu, 28 Jan 1999 07:34:51 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA26730; Thu, 28 Jan 1999 10:34:47 -0500 (EST) Message-Id: <199901281534.KAA26730@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7118) I-D ACTION:draft-ietf-ipngwg-resv-anycast-02.txt Date: Thu, 28 Jan 1999 10:34:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Reserved IPv6 Subnet Anycast Addresses Author(s) : D. Johnson, S. Deering Filename : draft-ietf-ipngwg-resv-anycast-02.txt Pages : 6 Date : 27-Jan-99 The IP Version 6 addressing architecture defines an 'anycast' address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-resv-anycast-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-resv-anycast-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-resv-anycast-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990127160149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-resv-anycast-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-resv-anycast-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990127160149.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 Thu Jan 28 07:38:06 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA03068 for ipng-dist; Thu, 28 Jan 1999 07:32:08 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA03061 for ; Thu, 28 Jan 1999 07:31:58 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA24206 for ; Thu, 28 Jan 1999 07:31:57 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA08692 for ; Thu, 28 Jan 1999 07:31:57 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA15561; Thu, 28 Jan 1999 07:31:16 -0800 (PST) X-Sender: deering@postoffice Message-Id: In-Reply-To: <199901281218.HAA00822@hygro.raleigh.ibm.com> References: Message from Steve Deering of "Wed, 27 Jan 1999 23:48:25 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Jan 1999 07:31:28 -0800 To: Thomas Narten From: Steve Deering Subject: (IPng 7116) Re: host vs router Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:18 AM -0800 1/28/99, Thomas Narten wrote: > It is possible to send out RAs with a Lifetime of zero. In such cases, > the router has an "advertising interface". However, the router is not > forwarding packets or being a default router. Forwarding packets and being a default router are two different things. An RA Lifetime of zero is supposed to mean that the sender is not a candidate to be a default router, but it may still be used as a non- default router for nodes that have been redirected or configured to use it for specific destinations (and thus it must have forwarding enabled). An interface that is configured to drop all non-self- addressed packets is a host interface, and must not send any RAs. The ability to set the RA Lifetime to zero was *not* intended to allow hosts to send "proxy router advertisements". > This allows a router to send RA Options (e.g., prefix information) > without having be a default router. Yes, but it must be serving as a *non*-default router, i.e., it must have forwarding enabled. > Actually, the wording in the spec says that if you receive a RA with a > lifetime of zero, two things happen: > > 1) remove the router from the default list > > 2) update the neighbor cache so that all entries using that router > perform next-hop resolution over again. In this case of a router > being removed from the default list, another router will be > selected. Step (2) needs to be conditional on step (1) happening. That is, if you receive an RA with a lifetime of zero from a router whose address is present in your default list, then you do steps (1) and (2). If you receive an RA with a lifetime of zero from a router whose address is *not* present in your default list, you should not perform step (1) [because you can't] or (2) [because any entries using that router at that point in time will necessarily be ones created by a Redirect or manual config, and need not and should not be disturbed]. The case of a router becoming a non-router (i.e., forwarding being turned off) is detected when an NA is received from an address believed to be a router address (default or non-default), in which the host/router flag set to "host". That NA may be either unsolicited or a consequence of the NUD process. Do you agree? 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 Jan 28 07:55:47 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id HAA03140 for ipng-dist; Thu, 28 Jan 1999 07:53:13 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id HAA03133 for ; Thu, 28 Jan 1999 07:53:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA21853 for ; Thu, 28 Jan 1999 07:53:02 -0800 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA23762 for ; Thu, 28 Jan 1999 07:53:02 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA22658; Thu, 28 Jan 1999 10:52:56 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA25076; Thu, 28 Jan 1999 10:52:58 -0500 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id KAA20158; Thu, 28 Jan 1999 10:52:56 -0500 (EST) Message-Id: <199901281552.KAA20158@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: (IPng 7119) Re: host vs router In-reply-to: Your message of "Thu, 28 Jan 1999 07:31:28 PST." Date: Thu, 28 Jan 1999 10:52:56 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > At 4:18 AM -0800 1/28/99, Thomas Narten wrote: > > It is possible to send out RAs with a Lifetime of zero. In such cases, > > the router has an "advertising interface". However, the router is not > > forwarding packets or being a default router. > Forwarding packets and being a default router are two different > things. Agreed. > An RA Lifetime of zero is supposed to mean that the sender is not a > candidate to be a default router, but it may still be used as a non- > default router for nodes that have been redirected or configured to > use it for specific destinations (and thus it must have forwarding > enabled). An interface that is configured to drop all non-self- > addressed packets is a host interface, and must not send any RAs. > The ability to set the RA Lifetime to zero was *not* intended to > allow hosts to send "proxy router advertisements". I'm not sure I agree entirely with the last part of this. I suspect that everyone agrees that a router that is not a default router MUST NOT send RAs with a non-zero lifetime. But should a host be allowed to send proxy advertisements with a Lifetime of 0? Well, the document pretty clearly says a host MUST NOT send RAs, so one could say the answer is no. But I don't see an interoperability problem with proxy advertisements, and there doesn't appear to be a way for a host receiving RAs to distinguish proxy advertisements from non-proxy advertisements. > > This allows a router to send RA Options (e.g., prefix information) > > without having be a default router. > Yes, but it must be serving as a *non*-default router, i.e., it must > have forwarding enabled. Why? It only needs to have forwarding enabled if a host forwards traffic to it. And the only way a host should be sending traffic to it (that needs further forwarding) is if it has been redirected to that router. The set of routers to which hosts should be redirected is a problem for the routers to sort out. I would assume that the way routers sort this out is via routing protocols. I don't believe that routers can make the assumption that anyone sending out RAs with a Lifetime of zero is a forwarding router. I.e., the mechanism routers use to figure out what other forwarding routers there are is not based just on who is sending RAs. Indeed, knowing that some router X is a forwarding router is not very useful by itself. One needs to also know which destinations it is willing to forward. So I don't think RAs with 0 lifetimes provide sufficient information to other routers to justify a requirement that all routers sending 0 lifetime RAs must forward packets. > > Actually, the wording in the spec says that if you receive a RA with a > > lifetime of zero, two things happen: > > > > 1) remove the router from the default list > > > > 2) update the neighbor cache so that all entries using that router > > perform next-hop resolution over again. In this case of a router > > being removed from the default list, another router will be > > selected. > Step (2) needs to be conditional on step (1) happening. The current text supports your interpretation. > The case of a router becoming a non-router (i.e., forwarding being > turned off) is detected when an NA is received from an address > believed to be a router address (default or non-default), in which > the host/router flag set to "host". That NA may be either unsolicited > or a consequence of the NUD process. Agreed. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 28 08:14:27 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA03188 for ipng-dist; Thu, 28 Jan 1999 08:11:16 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA03181 for ; Thu, 28 Jan 1999 08:11:07 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA24566; Thu, 28 Jan 1999 08:11:06 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA05949; Thu, 28 Jan 1999 08:11:05 -0800 (PST) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id LAA16008; Thu, 28 Jan 1999 11:11:07 -0500 (EST) Received: from wasted.zk3.dec.com by flume.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000000982; Thu, 28 Jan 1999 11:11:03 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id LAA0000031242; Thu, 28 Jan 1999 11:11:03 -0500 (EST) From: Jim Bound Message-Id: <199901281611.LAA0000031242@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Erik Nordmark cc: Richard Draves , "'IPng List'" Subject: (IPng 7120) Re: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt In-reply-to: Your message of "Wed, 27 Jan 1999 14:23:50 PST." Date: Thu, 28 Jan 1999 11:11:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Erik it is an implementation issue. Having did psuedo tunnels, then only configured tunnels, we went back to psuedo tunnels. Its the only way to make all this work and for other parts of IPv6 too (e.g. routing). Psuedo tunnels are harder but better. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 28 08:21:41 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA03229 for ipng-dist; Thu, 28 Jan 1999 08:19:54 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA03222; Thu, 28 Jan 1999 08:19:46 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26158; Thu, 28 Jan 1999 08:19:45 -0800 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA11892; Thu, 28 Jan 1999 08:19:43 -0800 (PST) Received: from pinnacle.wins.lbl.gov (pinnacle) [128.3.9.220] by mail1.es.net with smtp (Exim 1.81 #2) id 105uAN-00020Q-00; Thu, 28 Jan 1999 08:19:39 -0800 Message-Id: <4.1.19990128081858.009a57e0@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 28 Jan 1999 08:19:38 -0800 To: Alain Durand From: Bob Fink Subject: (IPng 7122) Re: (ngtrans) projection equipment at the IPv6 Interim meetings Cc: IPng List , ngtrans@sunroof.eng.sun.com In-Reply-To: <625.917491554@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, At 11:45 AM 1/28/99 +0900, Jun-ichiro itojun Hagino wrote: > >>Grenoble Interim Meeting folk: >>There will be PC LCD projection equipment available to us in addition to >>the usual overhead transparency projector. > > Could you please tell us the resolution? 640x480 or 800x600? Do you know yet what the resolution will be? 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 Thu Jan 28 08:25:43 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA03260 for ipng-dist; Thu, 28 Jan 1999 08:22:47 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA03253 for ; Thu, 28 Jan 1999 08:22:36 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA11367 for ; Thu, 28 Jan 1999 08:22:35 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA14078 for ; Thu, 28 Jan 1999 08:22:34 -0800 (PST) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id LAA18244; Thu, 28 Jan 1999 11:22:31 -0500 (EST) Received: from wasted.zk3.dec.com by flume.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000002408; Thu, 28 Jan 1999 11:22:30 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id LAA0000000408; Thu, 28 Jan 1999 11:22:30 -0500 (EST) From: Jim Bound Message-Id: <199901281622.LAA0000000408@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Richard Draves cc: "'IPng List'" Subject: (IPng 7123) Re: host vs router In-reply-to: Your message of "Wed, 27 Jan 1999 23:07:05 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF81C09@RED-MSG-50> Date: Thu, 28 Jan 1999 11:22:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, We had many of these discussions. The defined lines btw a host and router are very clear. If one starts doing router functions on a host it gets unclear real fast. All Host vendors who do routing today have this problem and I too saw many of your issues with ND when it was first architected when Bill Simpson was the only author. So the issues are inherent in the architecture of ND and its philosophy. The only real fix to realize that a Host tomorrow with IPv6 will really have code to be a Router on one interface and a Host on another interface. This is why I have basically given up on the need to justify anycast addresses on large MP machines and clusters for Hosts. Just make the interfaces for that router interfaces and many of the issues you bring up in the spec I don't think are issues anymore. But this does add cost to engineering IPv6 Hosts if a Server is to be more than robust desktop. I will bring you mail to grenoble though and the ND spec. p.s This will be a big issue for the diff serve work in process too IMO!!! /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 28 08:29:38 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA03310 for ipng-dist; Thu, 28 Jan 1999 08:28:18 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA03303; Thu, 28 Jan 1999 08:28:09 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA11914; Thu, 28 Jan 1999 08:28:09 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA17715; Thu, 28 Jan 1999 08:28:08 -0800 (PST) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id RAA09552; Thu, 28 Jan 1999 17:28:06 +0100 (MET) Message-Id: <199901281628.RAA09552@imag.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 28 Jan 1999 17:26:49 +0100 To: ngtrans@sunroof.eng.sun.com From: Alain Durand Subject: (IPng 7124) Re: (ngtrans) projection equipment at the IPv6 Interim meetings Cc: IPng List , ngtrans@sunroof.eng.sun.com References: <625.917491554@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>Grenoble Interim Meeting folk: >>>There will be PC LCD projection equipment available to us in addition to >>>the usual overhead transparency projector. >> >> Could you please tell us the resolution? 640x480 or 800x600? We will use a Barco projector. It goes up to 1600x1200 and can be adjusted for lower resolution. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 28 08:45:35 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id IAA03367 for ipng-dist; Thu, 28 Jan 1999 08:41:26 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id IAA03351; Thu, 28 Jan 1999 08:37:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA00963; Thu, 28 Jan 1999 08:37:26 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA24948; Thu, 28 Jan 1999 08:37:24 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id LAA25441; Thu, 28 Jan 1999 11:37:11 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000019975; Thu, 28 Jan 1999 11:36:59 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id LAA0000003320; Thu, 28 Jan 1999 11:36:58 -0500 (EST) From: Jim Bound Message-Id: <199901281636.LAA0000003320@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu, v6-deployment-cabal@alpha.zk3.dec.com Subject: (IPng 7125) UPDATED AGENDA - V6 Deploy 3rd Day Date: Thu, 28 Jan 1999 11:36:58 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, OK I added the last three requests including the one Bob F got on ngtrans just now. Any more changes will have to be done on the fly folks. A saying for IPv6'ers: Poor or late Planning on your part does not constitute an emergency on the WG, Authors, IESG, or Chairs part -----).... /jim === Thursday, February 4 -- IPv6 Deployment and Promotion ----------------------------------------------------- The purpose of this day will be to review current deployment activities, potential additional efforts, and opportunities for educating and influencing developers, ISPs, network managers, and users. This will include answering the following questions: - Why would anyone run IPv6 now? - Why would anyone ever run IPv6? - Who will deploy IPv6 first? - Will the Internet lead Corporate networks or follow as IPv6 is deployed? - How to get ISPs to deploy IPv6? We would like to request that each attendee come with answers to the above questions for discussion on this 3rd day. This is the Final Agenda before Grenbole. We will do Agenda Bashing at Grenoble and select order and times. Agenda: (1) Discussion of the questions above. (2) Existing deployment efforts: - 6BONE (who?) - 6REN (who?) (3) Potential efforts: - IPv6 Exchanges (who?) - Corporate Plans (who?) - ISP Plans (who?) - ... (4) Promotion - IPv6.org (who?) - Influencing developers, vendors, etc. (who?) (5) Presentations: - Bob Fink - 6REN and 6TAP - Jim Bound - The Palo Alto Gateway and IPv6 and sub-TLA Request Strategy - Marc Blanchet - IPv6 Deployment Issues - Henk Steenman - Amsterdam Internet Exchange (AMS-IX) native IPv6 environment - Jim Bound for Perry Metzger - Status of the V6 Deployment List Activities - Jun Murai - IPv6 Deployment in Japan - Paula Caslav - Proposed Guidelines RIPE NCC Regional Registries for IPv6 - Jun-ichiro itojun Hagino - IPv6 verification technologies and open result by FREE see: http://www.tahil.org/ - Latif LADID - Influencing IPv6 Developers and Promotion - Kenji OTA - IETF Terminal Room Experiences with IPv6 (6) Public Domain Code Needs for IPv6 Discussion - Appache Web Server - Sendmail - BIND - BSD Network Utilities thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 28 09:54:00 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id JAA03547 for ipng-dist; Thu, 28 Jan 1999 09:49:13 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with ESMTP id JAA03539 for ; Thu, 28 Jan 1999 09:48:57 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id JAA13893; Thu, 28 Jan 1999 09:48:59 -0800 (PST) Date: Thu, 28 Jan 1999 09:47:38 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7126) Re: host vs router To: Thomas Narten Cc: Steve Deering , Richard Draves , "'IPng List'" In-Reply-To: "Your message with ID" <199901281218.HAA00822@hygro.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is possible to send out RAs with a Lifetime of zero. In such cases, > the router has an "advertising interface". However, the router is not > forwarding packets or being a default router. This allows a router to > send RA Options (e.g., prefix information) without having be a default > router. I just realized that this doesn't work in practise since the spec states that when a host receives an RA that it should treat the sender as being a router from the NUD perspective. (Section 6.3.4 setting of IsRouter to TRUE.) If a non-forwarding node sends Router Advertisements it would be inconsistent since the NAs sent by the node would have the Router flag cleared but the RAs it sends implicitly mean that the Router flag is set. So I think the note at the end of section 6.2.5 is incorrect since we haven't worked out the details for non-forwarding advertising interfaces. And I'd argue that adding more complexity to make this work isn't worth the effort. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 28 10:46:32 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id KAA03599 for ipng-dist; Thu, 28 Jan 1999 10:38:30 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id KAA03592 for ; Thu, 28 Jan 1999 10:38:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA21121 for ; Thu, 28 Jan 1999 10:38:18 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA27857 for ; Thu, 28 Jan 1999 10:38:16 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA96628; Thu, 28 Jan 1999 18:38:01 GMT Received: from hursley.ibm.com (lig32-225-78-206.us.lig-dial.ibm.com [32.225.78.206]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA18770; Thu, 28 Jan 1999 18:37:55 GMT Message-ID: <36B097FE.59D956BF@hursley.ibm.com> Date: Thu, 28 Jan 1999 17:01:50 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Richard Draves CC: "'IPng List'" Subject: (IPng 7127) Re: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt References: <4D0A23B3F74DD111ACCD00805F31D8100AF81C08@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that is the cleanest solution. Brian Richard Draves wrote: > > OK, I think in our next MSR IPv6 release I'll change the tunnel code so that > each configured tunnel gets a separate pseudo-interface and the receiving > end of a configured tunnel is configured to know about the sending end. This > will solve the demultiplexing problem wrt 6over4 and make it possible for > administrators to put separate IPsec policies on the different configured > tunnels. > > Thanks, > Rich > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 28 10:53:45 1999 Received: by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) id KAA03634 for ipng-dist; Thu, 28 Jan 1999 10:49:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2+Sun/8.9.2) with SMTP id KAA03626 for ; Thu, 28 Jan 1999 10:48:54 -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 KAA09211 for ; Thu, 28 Jan 1999 10:48:51 -0800 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id KAA01281 for ; Thu, 28 Jan 1999 10:48:53 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 28 Jan 1999 10:48:03 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81C0D@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" , Thomas Narten Cc: Steve Deering , "'IPng List'" Subject: (IPng 7128) Re: host vs router Date: Thu, 28 Jan 1999 10:48:01 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I just realized that this doesn't work in practise since the spec > states that when a host receives an RA that it should treat the > sender as being a router from the NUD perspective. (Section > 6.3.4 setting of > IsRouter to TRUE.) This is a good point... the IsRouter rules say senders of Router Advertisements are implicitly assumed to be routers ie forwarding interfaces, and senders of Router Solicitations are implicitly assumed to be hosts ie non-forwarding interfaces. (I've never liked that part of the IsRouter rules. :-) I think it would be fairly simple to revise the spec to allow for non-forwarding advertising interfaces. But it would be more complicated than revising the spec to explicitly prohibit non-forwarding interfaces from advertising. So unless there's some good case for allowing non-forwarding interfaces to advertise, it seems the spec should be clarified to disallow them and section 6.2.5 should be revised. A counter-argument would be that if an implementation did decide to allow non-forwarding advertising interfaces, it would not introduce any real interoperability problems. At least, I haven't noticed any yet with MSR IPv6 release 1.2, which does support such interfaces. :-) Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 07:18:30 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id HAA04999 for ipng-dist; Fri, 29 Jan 1999 07:13:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id HAA04970; Fri, 29 Jan 1999 07:11:52 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09823; Fri, 29 Jan 1999 07:11:51 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA14139; Fri, 29 Jan 1999 07:11:49 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA01409; Fri, 29 Jan 1999 07:11:44 -0800 (PST) X-Sender: deering@postoffice Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Jan 1999 07:11:59 -0800 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 7132) Grenoble meeting schedule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are more details of the meeting and break schedule for next week. Tuesday: 8:00 registration 9:00 meeting starts, welcome speech by IMAG's director 9:10 morning session 11:30 lunch break & registration 13:00 afternoon session 1 15:00 afternoon break 15:30 afternoon session 2 18:00 end 20:00 rendezvous at Bus station (next to the train station) to take a bus to go to the social. 23:00 return from the social Wednesday: 8:30 registration 9:00 morning session 11:30 lunch 13:00 afternoon session 1 15:00 break 15:30 afternoon session 2 18:00 end Thursday: 8:30 registration 9:00 morning session 11:30 lunch 13:00 afternoon session 1 15:00 break 15:30 afternoon session 2 18:00 end -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 07:36:14 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id HAA05060 for ipng-dist; Fri, 29 Jan 1999 07:32:56 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id HAA05053 for ; Fri, 29 Jan 1999 07:32:47 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA04203 for ; Fri, 29 Jan 1999 07:32:45 -0800 Received: from theoryx.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA27129 for ; Fri, 29 Jan 1999 07:32:39 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theoryx.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id QAA15741 for ; Fri, 29 Jan 1999 16:32:28 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id QAA13591; Fri, 29 Jan 1999 16:32:27 +0100 (MET) Message-ID: <19990129163227.B13568@cs.uni-bonn.de> Date: Fri, 29 Jan 1999 16:32:27 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 7133) Link layers we dont have yet... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, there are two protocols that come into my mind, with no IPv6 specification I am aware of: AX25 layer 2 (amateur packet radio) and Appletalk. Is there any work in progress? -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 08:36:27 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id IAA05141 for ipng-dist; Fri, 29 Jan 1999 08:31:01 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id IAA05134 for ; Fri, 29 Jan 1999 08:30:52 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA27488 for ; Fri, 29 Jan 1999 08:30:52 -0800 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA05995 for ; Fri, 29 Jan 1999 08:30:50 -0800 (PST) Received: from pinnacle.wins.lbl.gov (pinnacle) [128.3.9.220] by mail1.es.net with smtp (Exim 1.81 #2) id 106Gof-0005RL-00; Fri, 29 Jan 1999 08:30:45 -0800 Message-Id: <4.1.19990129082406.0094dee0@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jan 1999 08:30:33 -0800 To: Ignatios Souvatzis , ipng@sunroof.eng.sun.com From: Bob Fink Subject: (IPng 7134) Re: Link layers we dont have yet... In-Reply-To: <19990129163227.B13568@cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:32 PM 1/29/99 +0100, Ignatios Souvatzis wrote: >Hello, > >there are two protocols that come into my mind, with no IPv6 specification >I am aware of: AX25 layer 2 (amateur packet radio) and Appletalk. > >Is there any work in progress? I believe these two are in distinctly different categories. The first might indeed be a candidate for a "v6-over" spec. AppleTalk is a full protocol suite that can have its network layer replaced by IPv4 (and in one early test demo, IPv6 as well). Though one could, in theory, attempt to push AppleTalk's network level down to a media level for IPv6, I can't see why it would be useful (just my opinion). Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 08:49:47 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id IAA05169 for ipng-dist; Fri, 29 Jan 1999 08:43:29 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id IAA05162 for ; Fri, 29 Jan 1999 08:43:20 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA19599 for ; Fri, 29 Jan 1999 08:43:19 -0800 Received: from theoryx.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA14840 for ; Fri, 29 Jan 1999 08:43:09 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theoryx.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id RAA16123; Fri, 29 Jan 1999 17:42:53 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id RAA13758; Fri, 29 Jan 1999 17:42:52 +0100 (MET) Message-ID: <19990129174251.E13568@cs.uni-bonn.de> Date: Fri, 29 Jan 1999 17:42:51 +0100 From: Ignatios Souvatzis To: Bob Fink , ipng@sunroof.eng.sun.com Subject: (IPng 7135) Re: Link layers we dont have yet... References: <19990129163227.B13568@cs.uni-bonn.de> <4.1.19990129082406.0094dee0@imap2.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <4.1.19990129082406.0094dee0@imap2.es.net>; from Bob Fink on Fri, Jan 29, 1999 at 08:30:33AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Jan 29, 1999 at 08:30:33AM -0800, Bob Fink wrote: > At 04:32 PM 1/29/99 +0100, Ignatios Souvatzis wrote: > >Hello, > > > >there are two protocols that come into my mind, with no IPv6 specification > >I am aware of: AX25 layer 2 (amateur packet radio) and Appletalk. > > > >Is there any work in progress? > > I believe these two are in distinctly different categories. The first might > indeed be a candidate for a "v6-over" spec. > > AppleTalk is a full protocol suite that can have its network layer replaced > by IPv4 (and in one early test demo, IPv6 as well). Though one could, in > theory, attempt to push AppleTalk's network level down to a media level for > IPv6, I can't see why it would be useful (just my opinion). Uhm, yes, but there's AppleTalks original link level protocol (how is it called officially?), that 220 kbit HDLC over RS422.... I thought (but might be wrong) that IPv4 was defined over that. -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 09:27:13 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id JAA05215 for ipng-dist; Fri, 29 Jan 1999 09:23:22 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id JAA05208 for ; Fri, 29 Jan 1999 09:23:13 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA17781 for ; Fri, 29 Jan 1999 09:23:12 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA14238 for ; Fri, 29 Jan 1999 09:23:12 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA13729; Fri, 29 Jan 1999 09:21:35 -0800 (PST) Message-Id: <3.0.5.32.19990129092030.038c9100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 29 Jan 1999 09:20:30 -0800 To: Ignatios Souvatzis From: Bob Hinden Subject: (IPng 7136) Re: Link layers we dont have yet... Cc: Bob Fink , ipng@sunroof.eng.sun.com In-Reply-To: <19990129174251.E13568@cs.uni-bonn.de> References: <4.1.19990129082406.0094dee0@imap2.es.net> <19990129163227.B13568@cs.uni-bonn.de> <4.1.19990129082406.0094dee0@imap2.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios, >Uhm, yes, but there's AppleTalks original link level protocol (how is it >called officially?), that 220 kbit HDLC over RS422.... > >I thought (but might be wrong) that IPv4 was defined over that. I think we usually call this "localtalk". Bob is correct, Appletalk is a complete protocol suite (e.g., appletalk over ethernet, appletalk over localtalk, etc.). There is a IPv4 over Localtalk specification. We should consider doing an IPv6 version. The question I would ask is there any need for IPv6 over Localtalk? My guess is that any Apple machines that will be capable of running a new version of MacOS that includes IPv6 will have Ethernet and will not have LocalTalk (e.g., the iMac). Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 09:57:29 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id JAA05534 for ipng-dist; Fri, 29 Jan 1999 09:50:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id JAA05527 for ; Fri, 29 Jan 1999 09:50:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA02214 for ; Fri, 29 Jan 1999 09:50:16 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA03399 for ; Fri, 29 Jan 1999 09:50:14 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA10000; Fri, 29 Jan 1999 09:49:01 -0800 (PST) X-Sender: deering@postoffice Message-Id: In-Reply-To: <3.0.5.32.19990129092030.038c9100@mailhost.iprg.nokia.com> References: <19990129174251.E13568@cs.uni-bonn.de> <4.1.19990129082406.0094dee0@imap2.es.net> <19990129163227.B13568@cs.uni-bonn.de> <4.1.19990129082406.0094dee0@imap2.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Jan 1999 09:49:16 -0800 To: Bob Hinden From: Steve Deering Subject: (IPng 7137) Re: Link layers we dont have yet... Cc: Ignatios Souvatzis , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:20 AM -0800 1/29/99, Bob Hinden wrote: > I think we usually call this "localtalk". Bob is correct, Appletalk is a > complete protocol suite (e.g., appletalk over ethernet, appletalk over > localtalk, etc.). There is a IPv4 over Localtalk specification. It is my understanding that the common practice is IP-over-AppleTalk, *not* IP-over-LocalTalk. I.e., IP is "tunneled" through the AppleTalk internet protocol to reach LocalTalk-attached devices. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 10:22:35 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id KAA05640 for ipng-dist; Fri, 29 Jan 1999 10:15:44 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id KAA05633 for ; Fri, 29 Jan 1999 10:15:07 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA07441 for ; Fri, 29 Jan 1999 10:15:05 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA20603 for ; Fri, 29 Jan 1999 10:15:04 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA23107; Fri, 29 Jan 1999 10:14:17 -0800 (PST) X-Sender: deering@postoffice Message-Id: In-Reply-To: References: <3.0.5.32.19990129092030.038c9100@mailhost.iprg.nokia.com> <19990129174251.E13568@cs.uni-bonn.de> <4.1.19990129082406.0094dee0@imap2.es.net> <19990129163227.B13568@cs.uni-bonn.de> <4.1.19990129082406.0094dee0@imap2.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Jan 1999 10:14:25 -0800 To: Ignatios Souvatzis , ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 7138) Re: Link layers we dont have yet... Cc: Bob Hinden Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:49 AM -0800 1/29/99, I wrote: > It is my understanding that the common practice is IP-over-AppleTalk, > *not* IP-over-LocalTalk. I.e., IP is "tunneled" through the AppleTalk > internet protocol to reach LocalTalk-attached devices. One more thing: the maximum payload size of AppleTalk is less than the 1280-byte minumum IPv6 link MTU, so any IPv6-over-AppleTalk spec will need to include a mechanism for fragmenting and reassembling IPv6 packets across the AppleTalk "hop". One possible solution is to use IPv4 as the local fragmentation protocol, since that's already implemented in the devices of interest. However, that would impose a greater header cost than a new fragmenting protocol defined specifically for this purpose. By the way, I agree with Bob that the importance of specifying a means of transmitting IPv6 over LocalTalk is debatable. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 10:53:02 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id KAA05720 for ipng-dist; Fri, 29 Jan 1999 10:45:54 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id KAA05713 for ; Fri, 29 Jan 1999 10:45:45 -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 KAA23630 for ; Fri, 29 Jan 1999 10:45:45 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id KAA11866 for ; Fri, 29 Jan 1999 10:45:44 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id KAA17334; Fri, 29 Jan 1999 10:35:36 -0800 (PST) Message-Id: <3.0.5.32.19990129103432.008a5100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 29 Jan 1999 10:34:32 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7140) New IPng Internet Draft Procedure Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please note that all new IPng Internet drafts submitted on or after February 1, 1999 need to follow the procedure described in the attached email. This procedure includes the following: "All Internet-Drafts must begin with ONE of the following three statements: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except for the right to produce derivative works. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and will only exist as an Internet-Draft. Any submission which does not include one (and only one) of the above three statements will be returned to the submitter. The IETF Secretariat will NOT add this text." The IPng w.g. chairs require anyone considering the submission an IPng Internet Draft (i.e. draft-ietf-ipngwg-xxxx) that does not include the first statement obtain permission from the chairs prior to publication. Without the first statement is not possible to consider the draft for entry into the standards process. Bob Hinden / Steve Deering IPng w.g. Chairs >To: IETF-Announce:; >Subject: Revised Internet-Draft boilerplate >From: The IESG >Date: Fri, 29 Jan 1999 11:23:40 -0500 >Sender: scoya@ns.cnri.reston.va.us > > >Following up on the discussion in the plenary session at the IETF meeting in >Orlando and the discussion on the poised mailing list, the IESG on Thursday, >January 28th approved the new boilerplate text that must be included with >all Internet-Draft submissions. > >Beginning Monday, February 1, all Internet-Draft submissions must include >the new boilerplate. Any submissions that do not use the new text will >be returned to the author/submitter. > >The new template can be accessed with this URL: > > http://www.ietf.org/ietf/1id-guidelines.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 Fri Jan 29 10:53:10 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id KAA05735 for ipng-dist; Fri, 29 Jan 1999 10:47:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with ESMTP id KAA05728 for ; Fri, 29 Jan 1999 10:47:47 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with ESMTP id KAA15450 for ; Fri, 29 Jan 1999 10:47:52 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA17788 for ipng@sunroof.eng.sun.com; Fri, 29 Jan 1999 10:47:05 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with ESMTP id KAA05646 for ; Fri, 29 Jan 1999 10:20:45 -0800 (PST) Received: from gargleblaster.eng.sun.com (gargleblaster [129.146.86.249]) by jurassic.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with ESMTP id KAA10652; Fri, 29 Jan 1999 10:20:45 -0800 (PST) Received: from gargleblaster (gargleblaster [129.146.86.249]) by gargleblaster.eng.sun.com (8.9.0+Sun/8.9.0) with SMTP id KAA26425; Fri, 29 Jan 1999 10:21:06 -0800 (PST) Message-Id: <199901291821.KAA26425@gargleblaster.eng.sun.com> Date: Fri, 29 Jan 1999 10:21:06 -0800 (PST) From: Don Coolidge Reply-To: Don Coolidge Subject: (IPng 7141) Re: Link layers we dont have yet... To: hinden@iprg.nokia.com, deering@cisco.com Cc: ignatios@cs.uni-bonn.de, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: w8hK4gJTgUfW6+S142g4Og== X-Mailer: dtmail 1.3.0 CDE Version 1.3_14 SunOS 5.7 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >At 9:20 AM -0800 1/29/99, Bob Hinden wrote: >> I think we usually call this "localtalk". Bob is correct, Appletalk is a >> complete protocol suite (e.g., appletalk over ethernet, appletalk over >> localtalk, etc.). There is a IPv4 over Localtalk specification. > >It is my understanding that the common practice is IP-over-AppleTalk, >*not* IP-over-LocalTalk. I.e., IP is "tunneled" through the AppleTalk >internet protocol to reach LocalTalk-attached devices. > >Steve Steve's right about this; the AppleTalk then runs over whatever link layer protocol it happens to be above. And Ethernet's among them, so the lack of a native LocalTalk connection on an iMac doesn't say anything meaningful about IPV6 over AppleTalk. (I wonder how/if/what my former colleagues are doing about that?) -- Don Coolidge -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 11:03:58 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id KAA05782 for ipng-dist; Fri, 29 Jan 1999 10:56:29 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id KAA05775 for ; Fri, 29 Jan 1999 10:56:21 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA09574; Fri, 29 Jan 1999 10:56:14 -0800 Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA19641; Fri, 29 Jan 1999 10:56:07 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA02342; Fri, 29 Jan 1999 10:55:45 -0800 (PST) X-Sender: deering@postoffice Message-Id: In-Reply-To: <199901291821.KAA26425@gargleblaster.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Jan 1999 10:56:00 -0800 To: Don Coolidge From: Steve Deering Subject: (IPng 7142) Re: Link layers we dont have yet... Cc: ignatios@cs.uni-bonn.de, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Steve's right about this; the AppleTalk then runs over whatever link > layer protocol it happens to be above. And Ethernet's among them, so > the lack of a native LocalTalk connection on an iMac doesn't say > anything meaningful about IPV6 over AppleTalk. Right, but you don't need to use AppleTalk encapsulation to get IP packets in and out of Ethernet-attached Macs (so-called "EtherTalk"); you can use standard IP-over-Ethernet for that. It is only when you want to reach LocalTalk-attached devices that you have to resort to AppleTalk encapsulation. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 29 17:04:42 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id QAA06307 for ipng-dist; Fri, 29 Jan 1999 16:59:52 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id QAA06300 for ; Fri, 29 Jan 1999 16:59:43 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA23468 for ; Fri, 29 Jan 1999 16:59:41 -0800 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id QAA10617 for ; Fri, 29 Jan 1999 16:59:42 -0800 (PST) Received: from pinnacle.wins.lbl.gov (pinnacle) [128.3.9.220] by mail1.es.net with smtp (Exim 1.81 #2) id 106OlA-0001en-00; Fri, 29 Jan 1999 16:59:40 -0800 Message-Id: <4.1.19990115111101.00944100@imap2.es.net> Message-Id: <4.1.19990115111101.00944100@imap2.es.net> Message-Id: <4.1.19990115111101.00944100@imap2.es.net> Message-Id: <4.1.19990115111101.00944100@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jan 1999 16:59:37 -0800 To: IPng List From: Bob Fink Subject: (IPng 7143) 6REN Overview Information Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To all parties interested in IPv6: I've been talking about the formation of the 6REN for several months now, and have established a domain and web site at . Many of you have been asking me for more information so this is a kickoff message. Please address any messages to me at . Thanks, Bob Fink ESnet ========================================= 6REN - IPv6 Research & Education Networks Overview and Introduction In October of 1998, the Energy Sciences Network (ESnet) established a "6REN" initiative for promoting the introduction of IPv6 services into the production Internet. As ESnet is a US national-level "Research & Education Network", the focus was set on encouraging and helping Research & Education Networks worldwide to start providing IPv6 services. Thus the 6ren is a voluntary coordination initiative of Research and Education Networks that provide production IPv6 transit service to facilitiate high quality, high performance, and operationally robust IPv6 networks. Participation is free and open to all Research and Education Networks that provide IPv6 service. Other for-profit and not-for-profit IPv6 networks are also encouraged to participate. Primary Goals The primary goals of the 6REN are: 1. provide production quality IPv6 packet delivery services 2. developing operational procedures for IPv6 networks 3. promoting the deployment of IPv6 networks 4. enabling early IPv6-ready application testing and deployment Who May Participate Any network providing, or planning to provide, IPv6 production services can participate. This includes service providers (i.e., those carrying IPv6 for other networks) as well as end user (leaf) sites (i.e., those carrying IPv6 for their own site's use). The only condition is that the network/site is using production IPv6 addresses (as soon as they are available) and provides production quality IPv6 service. There are no fees or costs to participation other than the time, equipment and good will that the participant contributes for the provision of the production IPv6 service. How to Participate The 6REN has a mail list at <6ren@es.net> that requires you to join the list to submit mail to it. Just send "subscribe" in the body of the message to 6ren-request@es.net. First Step for the 6REN Starting in October, 1998, production native IPv6 over ATM interconnections were established between ESnet, Internet2/vBNS, Canarie, Cairn and WIDE. Though these connections were done using testing (6bone) IPv6 addresses, the participants will convert to their production IPv6 addresses as soon as they are issued by the address registries, hopefully by the end of the 1st quarter of 1999 (currently promised by ARIN, APNIC and RIPE-NCC). Also, ESnet will provide transit for all 6bone connected networks to all 6REN networks to guarantee early continuity for early application and operational testing. A Next Step for the 6REN - the 6TAP In order to facilitate the easy interconnection of 6REN participants in the US, Canarie and ESnet are jointly sponsoring an IPv6 Exchange "6TAP" project to provide routing and route serving services at the StarTAP in Chicago. The 6TAP will provide an IPv6 capable router and route server colocated at StarTAP to experiment with early route administration and peering services to assist in the development of IPv6 operational procedures. What's Next Getting the word about the 6REN to the 6bone networks able to run production IPv6 networks is a first order of business. In addition, ESnet is helping carry the message to those networks not yet IPv6 experienced to help them understand the value of 6REN participation. Another important effort is to promote production Internet traffic to be moved over 6REN networks in native IPv6 wherever and whenever possible. Anyone with questions are encouraged to contact Bob Fink of ESnet (fink@es.net). -end -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------