From hansolofalcon@worldnet.att.net Sat Jan 1 02:10:13 2000 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Fri, 31 Dec 1999 21:10:13 -0500 Subject: Two questions Message-ID: <01BF53D3.71929560.hansolofalcon@worldnet.att.net> Hello from Gregg C Levine usually at Jedi Knight Computers I have two questions for the crowd on this mailing list: The first one is: Is anyone who is US based aware of access for the 6Bone project through a dial-up account from a non-participating ISP? This service provider AT&T Worldnet, so far has not moved in the direction that this list is moving into. The second question is:Is anyone working with the RSVP protocol, either on Linux/UNIX/Solaris, or on Windows? Also included on the non-Microsoft side is the operating systems for SGI workstations. Please realize that these are serious questions, as my group and I, are looking for new, and noteworthy questions to answer, and solutions to provide. Gregg C Levine mailto:hansolofalcon@worldnet.att.net "They were in the wrong place, at the wrong time, naturally they became heroes." Princess Leia Organna of Alderann, Senator "Remember, the Force will be with you." Obi-Wan(Ben) Kenobi, Jedi Knight and, General, (Retired) "May the Force be with you." Anonymous From snaraya2@Bayou.UH.EDU Tue Jan 4 01:00:42 2000 From: snaraya2@Bayou.UH.EDU (Shiva Narayanaswamy) Date: Mon, 03 Jan 2000 19:00:42 -0600 Subject: References: <270C142DA02CD211B99C00104B8FDBC4431675@IBTMAIL> <20000101212143.A52232@metal.intt.org> Message-ID: <00e601bf564f$1fb899a0$a8030781@phys.uh.edu> Thanks a lot for the reply. I am aware of the fact that automatic tunnelling is not very prevalent in current designs. But I am trying to concentrate on "The Flag Day" , when we go in for a global transition to IPv6. But I have not yet been able to arrive upon a single problem statement on which to work. I do have a couple of more questions. I was wondering as to how the priority field of a IPv6 packet gets translated while being encapsulated into an IPv4 packet, so that the same QoS is maintained even within the tunnel. Also how do we ensure that all the IP packets of the same flow label follow the same path and pass through the same tunnel? Thanks again for the response, Shiva > > > > Hi all, > > I am a graduate student in Houston, about to begin work on some aspect > > of IPv6. I am currently involved in Literary Survey, and am yet to narrow > > down mu problem statement. I have narrowed it down to doing some work on > > routing aspects of 4 to 6 transition, especially concerned with Automatic > > Tunneling. I would be obliged if someone on the list could guide me furthur > > with some current problems in this area which are yet to be solved. > > Please add a cc to my address snaraya2@bayou.uh.edu > > while replying to the mail. Thanks a lot in > > advance. > > > >From a backbone aspect, there probably won't be much automatic tunneling. The > current designs are for native backbones and ipv6-in-ipv4 tunnels. Currently > there are no plans for a transition to ipv6 globally. IPv6 is mostly used for > experimentation. I don't know of any commercial backbones that are supporting > ipv6 as a service. Just recently the various regional registries have begun > to allocate TLAs to qualified backbones. I would check our www.arin.net. > > On the enterprise side, most sides simply run a dual stack. I havn't heard of > anyone doing automatic tunneling. > > > I hope this gives you some pointers. > > > Scott > From bound@zk3.dec.com Tue Jan 4 04:21:06 2000 From: bound@zk3.dec.com (Jim Bound) Date: Mon, 03 Jan 2000 23:21:06 -0500 Subject: In-Reply-To: Your message of "Mon, 03 Jan 2000 19:00:42 CST." <00e601bf564f$1fb899a0$a8030781@phys.uh.edu> Message-ID: <200001040421.XAA0000010445@quarry.zk3.dec.com> Shiva, > Thanks a lot for the reply. I am aware of the fact that automatic >tunnelling is not very prevalent in current designs. But I am trying to >concentrate on "The Flag Day" , when we go in for a global transition to >IPv6. But I have not yet been able to arrive upon a single problem statement >on which to work. I do have a couple of more questions. I don't think a flag day will ever work no matter how minimal the nodes are for the transition except for a home user and the ISP is now doing IPv6 and even then assuming all the apps have been ported to IPv6 would have to be an a priori. I believe all transition mechanisms defined in the IETF and out of the IETF all assume no flag day. Even if lets say cell devices moved to IPv6 (which seems logical to many of us) they would still have to interoperate with IPv4 for some parts assuming all infrastructure was able to utilize Ipv6 for Wireless and Mobile paradigms in a specific geo-market segment (e.g. Sprint, Deutch Telecom, Singapore Telecom, etc). > I was wondering as to how the priority field of a IPv6 packet gets >translated while being encapsulated into an IPv4 packet, so that the same >QoS is maintained even within the tunnel. Also how do we ensure that all the >IP packets of the same flow label follow the same path and pass through the >same tunnel? If you mean the traffic class field diff serve group has done a good job keeping them the same. So that IP header field should mean the same thing for most cases. Though I have to read the latest specs on aggregation of diff serve with RSVP. If you mean the flow label this is still not officially defined except for RSVP via the Flow Spec. And this will only work with IPv6 capable nodes. If we do define a means to pass thru as you say the Ipv6 flowlabel plus the dst address, it will not be possible today if the packet is encapsulated within IPv4 packet to maintain the same state defined by the address+flowlabel in IPv6. I say today because I guess it would be possible to define some IPv4 "option" to carry the IPv6 flowlabel in the Ipv4 packet or possible in a route proto-id TBD. But getting that kind of idea done in IPv4 I think has zero chance for success in the market unless Ipv6 gets much more deployed and then maybe something like that may happen as a defined assistance transition mechanism. But if you have ideas to help this along I think all of us are all ears. /jim From dlitz@cheerful.com Sun Jan 9 21:16:45 2000 From: dlitz@cheerful.com (Dwayne C . Litzenberger) Date: Sun, 9 Jan 2000 15:16:45 -0600 Subject: IPv6 address/port format Message-ID: <20000109151645.A5340@dlitz.dyn.dhs.org> --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'm not really knowledgeable about this, but what is a good, standard way to show address/port shown in IPv4, IPv6, IPX, etc? I would think address.:port (dot-colon) would be good (and it already works with domain names), but I haven't seen this done yet.=20 Any thoughts?=20 Please always Cc to me when replying to me on the lists. --=20 "If you continue running Windows, your system may become unstable." -- Windows 95 BSOD Dwayne C. Litzenberger - dlitz@cheerful.com Please always Cc to me when replying to me on the lists. Advertising Policy: http://www.redrival.com/dlitz/spamoff.html GnuPG Public Key: http://www.redrival.com/dlitz/gpgkey.asc Fingerprint: 0535 F7CF FF5F 8547 E5A5 695E 4456 FB6C BC39 A4B0 --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEAREBAAYFAjh4+rwACgkQRFb7bLw5pLBexwCfQ/TxIq5HHseyVTUzm2/oZWAz keQAoI96yquA19a50LhH7ZLbLolwQYI8 =2iKQ -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From cross@eng.us.uu.net Mon Jan 10 07:06:52 2000 From: cross@eng.us.uu.net (Chris P. Ross) Date: Mon, 10 Jan 2000 02:06:52 -0500 (EST) Subject: IPv6 address/port format In-Reply-To: Dwayne C . Litzenberger's message of Sun, 9 January 2000 15:16:45 -0600 <20000109151645.A5340@dlitz.dyn.dhs.org> References: <20000109151645.A5340@dlitz.dyn.dhs.org> Message-ID: <14457.34060.339364.62768@ballista.eng.us.uu.net> "Dwayne C . Litzenberger" said: > I'm not really knowledgeable about this, but what is a good, standard way > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > address.:port (dot-colon) would be good (and it already works with domain > names), but I haven't seen this done yet. > Any thoughts? I've seen people use both "IPv6-addr port" (space sep.) and "IPv6-addr/port". I think I really like using '/', and haven't yet found a place where that will cause problems except for in URIs. Using spaces is just universally compliated. I guess we could use something like '%', but then again, me randomly proposing things here is probabaly not the best place to make suggestions usefully. ;-) - Chris -- Chris P. Ross UUNET Technologies, Inc. cross@eng.us.uu.net R & D / Engineering cross@uu.net From logix@foobar.franken.de Mon Jan 10 11:07:39 2000 From: logix@foobar.franken.de (Harold Gutch) Date: Mon, 10 Jan 2000 12:07:39 +0100 Subject: IPv6 address/port format In-Reply-To: <14457.34060.339364.62768@ballista.eng.us.uu.net>; from Chris P. Ross on Mon, Jan 10, 2000 at 02:06:52AM -0500 References: <20000109151645.A5340@dlitz.dyn.dhs.org> <14457.34060.339364.62768@ballista.eng.us.uu.net> Message-ID: <20000110120739.A27826@foobar.franken.de> On Mon, Jan 10, 2000 at 02:06:52AM -0500, Chris P. Ross wrote: > > "Dwayne C . Litzenberger" said: > > I'm not really knowledgeable about this, but what is a good, standard way > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > address.:port (dot-colon) would be good (and it already works with domain > > names), but I haven't seen this done yet. > > > Any thoughts? > > I've seen people use both "IPv6-addr port" (space sep.) and > "IPv6-addr/port". I think I really like using '/', and haven't yet I don't like the slash ('/'), since it's used to to seperate the base network address and the relevant number of bits in IPv4 (e.g. 192.168.10.0/24 isn't the same as 192.168.10.0:24). That dot-colon idea looks much better to me. bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc From kaos@ocs.com.au Mon Jan 10 12:24:44 2000 From: kaos@ocs.com.au (Keith Owens) Date: Mon, 10 Jan 2000 23:24:44 +1100 Subject: IPv6 address/port format In-Reply-To: Your message of "Mon, 10 Jan 2000 12:07:39 BST." <20000110120739.A27826@foobar.franken.de> Message-ID: <1438.947507084@ocs3.ocs-net> "Dwayne C . Litzenberger" said: > I'm not really knowledgeable about this, but what is a good, standard way > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > address.:port (dot-colon) would be good (and it already works with domain > names), but I haven't seen this done yet. See RFC 2732, Format for Literal IPv6 Addresses in URL's. Sample with address and port. http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html From woeber@cc.univie.ac.at Mon Jan 10 15:08:13 2000 From: woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 10 Jan 2000 15:08:13 MET Subject: IPv6 address/port format Message-ID: <009E3F04.FAB256C4.6@cc.univie.ac.at> > I've seen people use both "IPv6-addr port" (space sep.) and >"IPv6-addr/port". I think I really like using '/', and haven't yet >found a place where that will cause problems except for in URIs. >Using spaces is just universally compliated. I guess we could use >something like '%', but then again, me randomly proposing things here >is probabaly not the best place to make suggestions usefully. ;-) > > - Chris I suppose we're suffering from a severe case of character overload: In the IPv4 world the convention is a.b.c.d:port, with a,b,c and d an external encoding base 10 of the 4-bytes of the 32bit address. Talking in routing terms the convention is a.b.c.d/prefix, with a.b.c.d being the network part of the address and a prefix length [1..32] in bits, again given as a number base 10. In the IPv6 world, both the ".", as well as the ":" as well as the "/" are being used to specify the address and/or the length of the routing prefix. The external erpresentation uses base 16, with the 128 bits grouped into 8 fields of 16 bits each, separated by colons (see RFC 2373): FE80::02A0:24FF:FE9D:5094 (e.g. for a MAC Address of 00a0.249d.5094) 3FFE:8034:80::0/48 (e.g. for a routing prefix) ::FFFF:10.2.3.4 (e.g. for a mixed v4/v6 environment) We already ran into the port specification problem for IPv6, last resort was to use white-space. Hmmm.... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ From sommerfeld@orchard.arlington.ma.us Mon Jan 10 15:30:24 2000 From: sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld) Date: Mon, 10 Jan 2000 10:30:24 -0500 Subject: IPv6 address/port format In-Reply-To: Message from "Chris P. Ross" of "Mon, 10 Jan 2000 02:06:52 EST." <14457.34060.339364.62768@ballista.eng.us.uu.net> Message-ID: <200001101530.PAA12945@orchard.arlington.ma.us> > "Dwayne C . Litzenberger" said: > > I'm not really knowledgeable about this, but what is a good, standard way > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > address.:port (dot-colon) would be good (and it already works with domain > > names), but I haven't seen this done yet. > > > Any thoughts? > > I've seen people use both "IPv6-addr port" (space sep.) and > "IPv6-addr/port". I think I really like using '/', and haven't yet > found a place where that will cause problems except for in URIs. It's too easily confused with network prefixes.. (IPv6-addr/prefixlen). How am I supposed to know whether 3ffe:1ce1:0:b5::1/64 should be parsed as an pair or as a network prefix? - Bill From 6bone@chrisbrown.org Mon Jan 10 15:31:29 2000 From: 6bone@chrisbrown.org (Chris Brown) Date: Mon, 10 Jan 2000 10:31:29 -0500 (EST) Subject: IPv6 address/port format In-Reply-To: <20000110120739.A27826@foobar.franken.de> from Harold Gutch at "Jan 10, 2000 12: 7:39 pm" Message-ID: <20000110153129.21422.qmail@ritchie.wnycp.com> I would tend twords using dot-colon for host:port combinations, and dot-slash for network/bits for two reasons. This first is that this is already common practice in IPv4. The second reason is that using the same notation for two different but related purposes would eventually lead to confusion. Chris > On Mon, Jan 10, 2000 at 02:06:52AM -0500, Chris P. Ross wrote: > > > > "Dwayne C . Litzenberger" said: > > > I'm not really knowledgeable about this, but what is a good, standard way > > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > > address.:port (dot-colon) would be good (and it already works with domain > > > names), but I haven't seen this done yet. > > > > > Any thoughts? > > > > I've seen people use both "IPv6-addr port" (space sep.) and > > "IPv6-addr/port". I think I really like using '/', and haven't yet > > I don't like the slash ('/'), since it's used to to seperate the > base network address and the relevant number of bits in IPv4 > (e.g. 192.168.10.0/24 isn't the same as 192.168.10.0:24). > That dot-colon idea looks much better to me. > > bye, > Harold > > -- > Someone should do a study to find out how many human life spans have > been lost waiting for NT to reboot. > Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc > From dancer@zeor.simegen.com Mon Jan 10 20:20:08 2000 From: dancer@zeor.simegen.com (dancer@zeor.simegen.com) Date: Mon, 10 Jan 2000 20:20:08 +0000 Subject: IPv6 address/port format References: Message-ID: <387A3EF8.AD2241C9@zeor.simegen.com> Jason Gunthorpe wrote: > On Mon, 10 Jan 2000, Chris P. Ross wrote: > > > I've seen people use both "IPv6-addr port" (space sep.) and > > "IPv6-addr/port". I think I really like using '/', and haven't yet > > found a place where that will cause problems except for in URIs. > > Using spaces is just universally compliated. I guess we could use > > something like '%', but then again, me randomly proposing things here > > is probabaly not the best place to make suggestions usefully. ;-) > > The various RFCs for URIS basically mandate a format like this: > > http://user:password@host:port/ > > Trouble is that IPv6 numberic addresses are incompatible with that form.. > Using % (uri escape char) and / (uri path seperator) are both no > goes. > > We may just find that you cannot use IPv6 numeric addresses at all with > alot of things... > > It seems to me that using : for the seperator was a very bad idea :< Perhaps. However, file:/// URL's for DOS boxen encode ':' in the path as a pipe. No reason why the same thing wouldn't work for v6 addresses in URLs. D From cross@eng.us.uu.net Mon Jan 10 07:06:52 2000 From: cross@eng.us.uu.net (Chris P. Ross) Date: Mon, 10 Jan 2000 02:06:52 -0500 (EST) Subject: IPv6 address/port format In-Reply-To: Dwayne C . Litzenberger's message of Sun, 9 January 2000 15:16:45 -0600 <20000109151645.A5340@dlitz.dyn.dhs.org> References: <20000109151645.A5340@dlitz.dyn.dhs.org> Message-ID: <14457.34060.339364.62768@ballista.eng.us.uu.net> "Dwayne C . Litzenberger" said: > I'm not really knowledgeable about this, but what is a good, standard way > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > address.:port (dot-colon) would be good (and it already works with domain > names), but I haven't seen this done yet. > Any thoughts? I've seen people use both "IPv6-addr port" (space sep.) and "IPv6-addr/port". I think I really like using '/', and haven't yet found a place where that will cause problems except for in URIs. Using spaces is just universally compliated. I guess we could use something like '%', but then again, me randomly proposing things here is probabaly not the best place to make suggestions usefully. ;-) - Chris -- Chris P. Ross UUNET Technologies, Inc. cross@eng.us.uu.net R & D / Engineering cross@uu.net From kaos@ocs.com.au Mon Jan 10 12:24:44 2000 From: kaos@ocs.com.au (Keith Owens) Date: Mon, 10 Jan 2000 23:24:44 +1100 Subject: IPv6 address/port format In-Reply-To: Your message of "Mon, 10 Jan 2000 12:07:39 BST." <20000110120739.A27826@foobar.franken.de> Message-ID: <1438.947507084@ocs3.ocs-net> "Dwayne C . Litzenberger" said: > I'm not really knowledgeable about this, but what is a good, standard way > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > address.:port (dot-colon) would be good (and it already works with domain > names), but I haven't seen this done yet. See RFC 2732, Format for Literal IPv6 Addresses in URL's. Sample with address and port. http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html From logix@foobar.franken.de Mon Jan 10 11:07:39 2000 From: logix@foobar.franken.de (Harold Gutch) Date: Mon, 10 Jan 2000 12:07:39 +0100 Subject: IPv6 address/port format In-Reply-To: <14457.34060.339364.62768@ballista.eng.us.uu.net>; from Chris P. Ross on Mon, Jan 10, 2000 at 02:06:52AM -0500 References: <20000109151645.A5340@dlitz.dyn.dhs.org> <14457.34060.339364.62768@ballista.eng.us.uu.net> Message-ID: <20000110120739.A27826@foobar.franken.de> On Mon, Jan 10, 2000 at 02:06:52AM -0500, Chris P. Ross wrote: > > "Dwayne C . Litzenberger" said: > > I'm not really knowledgeable about this, but what is a good, standard way > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > address.:port (dot-colon) would be good (and it already works with domain > > names), but I haven't seen this done yet. > > > Any thoughts? > > I've seen people use both "IPv6-addr port" (space sep.) and > "IPv6-addr/port". I think I really like using '/', and haven't yet I don't like the slash ('/'), since it's used to to seperate the base network address and the relevant number of bits in IPv4 (e.g. 192.168.10.0/24 isn't the same as 192.168.10.0:24). That dot-colon idea looks much better to me. bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc From woeber@cc.univie.ac.at Mon Jan 10 15:08:13 2000 From: woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 10 Jan 2000 15:08:13 MET Subject: IPv6 address/port format Message-ID: <009E3F04.FAB256C4.6@cc.univie.ac.at> > I've seen people use both "IPv6-addr port" (space sep.) and >"IPv6-addr/port". I think I really like using '/', and haven't yet >found a place where that will cause problems except for in URIs. >Using spaces is just universally compliated. I guess we could use >something like '%', but then again, me randomly proposing things here >is probabaly not the best place to make suggestions usefully. ;-) > > - Chris I suppose we're suffering from a severe case of character overload: In the IPv4 world the convention is a.b.c.d:port, with a,b,c and d an external encoding base 10 of the 4-bytes of the 32bit address. Talking in routing terms the convention is a.b.c.d/prefix, with a.b.c.d being the network part of the address and a prefix length [1..32] in bits, again given as a number base 10. In the IPv6 world, both the ".", as well as the ":" as well as the "/" are being used to specify the address and/or the length of the routing prefix. The external erpresentation uses base 16, with the 128 bits grouped into 8 fields of 16 bits each, separated by colons (see RFC 2373): FE80::02A0:24FF:FE9D:5094 (e.g. for a MAC Address of 00a0.249d.5094) 3FFE:8034:80::0/48 (e.g. for a routing prefix) ::FFFF:10.2.3.4 (e.g. for a mixed v4/v6 environment) We already ran into the port specification problem for IPv6, last resort was to use white-space. Hmmm.... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ From sommerfeld@orchard.arlington.ma.us Mon Jan 10 15:30:24 2000 From: sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld) Date: Mon, 10 Jan 2000 10:30:24 -0500 Subject: IPv6 address/port format In-Reply-To: Message from "Chris P. Ross" of "Mon, 10 Jan 2000 02:06:52 EST." <14457.34060.339364.62768@ballista.eng.us.uu.net> Message-ID: <200001101530.PAA12945@orchard.arlington.ma.us> > "Dwayne C . Litzenberger" said: > > I'm not really knowledgeable about this, but what is a good, standard way > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > address.:port (dot-colon) would be good (and it already works with domain > > names), but I haven't seen this done yet. > > > Any thoughts? > > I've seen people use both "IPv6-addr port" (space sep.) and > "IPv6-addr/port". I think I really like using '/', and haven't yet > found a place where that will cause problems except for in URIs. It's too easily confused with network prefixes.. (IPv6-addr/prefixlen). How am I supposed to know whether 3ffe:1ce1:0:b5::1/64 should be parsed as an pair or as a network prefix? - Bill From 6bone@chrisbrown.org Mon Jan 10 15:31:29 2000 From: 6bone@chrisbrown.org (Chris Brown) Date: Mon, 10 Jan 2000 10:31:29 -0500 (EST) Subject: IPv6 address/port format In-Reply-To: <20000110120739.A27826@foobar.franken.de> from Harold Gutch at "Jan 10, 2000 12: 7:39 pm" Message-ID: <20000110153129.21422.qmail@ritchie.wnycp.com> I would tend twords using dot-colon for host:port combinations, and dot-slash for network/bits for two reasons. This first is that this is already common practice in IPv4. The second reason is that using the same notation for two different but related purposes would eventually lead to confusion. Chris > On Mon, Jan 10, 2000 at 02:06:52AM -0500, Chris P. Ross wrote: > > > > "Dwayne C . Litzenberger" said: > > > I'm not really knowledgeable about this, but what is a good, standard way > > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > > address.:port (dot-colon) would be good (and it already works with domain > > > names), but I haven't seen this done yet. > > > > > Any thoughts? > > > > I've seen people use both "IPv6-addr port" (space sep.) and > > "IPv6-addr/port". I think I really like using '/', and haven't yet > > I don't like the slash ('/'), since it's used to to seperate the > base network address and the relevant number of bits in IPv4 > (e.g. 192.168.10.0/24 isn't the same as 192.168.10.0:24). > That dot-colon idea looks much better to me. > > bye, > Harold > > -- > Someone should do a study to find out how many human life spans have > been lost waiting for NT to reboot. > Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc > From boozy@rabelo.eti.br Tue Jan 11 01:04:16 2000 From: boozy@rabelo.eti.br (Boozy) Date: Mon, 10 Jan 2000 23:04:16 -0200 Subject: Problemas na instalacao do KAME Message-ID: <200001110111.XAA12896@svn.com.br> --=====================_947559856==_ Content-Type: text/plain; charset="us-ascii" Ola, Fiz o download da ultima versao stable do KAME para FreeBSD (23/12/1999), mas obtive sucesso na sua instalacao. Descompactei o arquivo tgz em /usr/kame e copiei o arquivo GENERIC.v6 para saturno.v6 sem fazer nehuma alteracao. Executei /usr/sbin/config saturno.v6 sem problemas. Entretanto aconteceram alguns erros quando tentei executar make depend. Sera que alguem pode me dar uma luz? Estou usando FreeBSD 3.3 e estou enviando o arquivo gerado atraves do script. [] Luciano Rabelo --=====================_947559856==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="step_2b" Script started on Mon Jan 10 17:52:51 2000 saturno# pwd /usr/kame/freebsd3 saturno# cd sys/i386/conf saturno# cp GENERIC.v6 saturno.v6 saturno# /usr/sbin/config saturno.v6 Don't forget to do a ``make depend'' Kernel build directory is ../../compile/saturno.v6 saturno# cd ../../compile/saturno.v6/ saturno# make depend cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi = -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include= opt_global.h -D_KERNEL ../../i386/i386/genassym.c cc -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs= -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline= -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I-= -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h= -D_KERNEL genassym.o -o genassym ./genassym >assym.s rm -f param.c cp ../../conf/param.c . sh ../../kern/vnode_if.sh ../../kern/vnode_if.src make -f ../../dev/aic7xxx/Makefile MAKESRCPATH=3D../../dev/aic7xxx Warning: Object directory not changed from original= /usr/kame/freebsd3/sys/compile/saturno.v6 yacc -d ../../dev/aic7xxx/aicasm_gram.y mv y.tab.c aicasm_gram.c cc -O -pipe -I/usr/include -I. -c aicasm_gram.c lex -t ../../dev/aic7xxx/aicasm_scan.l > aicasm_scan.c cc -O -pipe -I/usr/include -I. -c aicasm_scan.c cc -O -pipe -I/usr/include -I. -c ../../dev/aic7xxx/aicasm.c cc -O -pipe -I/usr/include -I. -c ../../dev/aic7xxx/aicasm_symbol.c cc -O -pipe -I/usr/include -I. -o aicasm aicasm_gram.o aicasm_scan.o= aicasm.o aicasm_symbol.o -ll ./aicasm -nostdinc -I- -I. -I../.. -I../../../include -o aic7xxx_seq.h -r= aic7xxx_reg.h ../../dev/aic7xxx/aic7xxx.seq ./aicasm: 709 instructions used perl5 ../../kern/makedevops.pl -c ../../kern/device_if.m perl5 ../../kern/makedevops.pl -h ../../kern/device_if.m perl5 ../../kern/makedevops.pl -c ../../kern/bus_if.m perl5 ../../kern/makedevops.pl -h ../../kern/bus_if.m rm -f .newdep mkdep -a -f .newdep -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi = -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include= opt_global.h -D_KERNEL -elf device_if.c bus_if.c ../../cam/cam.c= ../../cam/cam_xpt.c ../../cam/cam_extend.c ../../cam/cam_queue.c= ../../cam/cam_periph.c ../../cam/cam_sim.c ../../cam/scsi/scsi_all.c= ../../cam/scsi/scsi_da.c ../../cam/scsi/scsi_sa.c ../../cam/scsi/scsi_cd.c= ../../cam/scsi/scsi_pass.c ../../dev/advansys/advansys.c = ../../dev/advansys/advlib.c ../../dev/advansys/advmcode.c = ../../dev/advansys/adwcam.c ../../dev/advansys/adwlib.c = ../../dev/advansys/adwmcode.c ../../dev/aha/aha.c = ../../dev/aic7xxx/aic7xxx.c ../../dev/aic7xxx/93cx6.c = ../../dev/buslogic/bt.c ../../dev/isp/isp_freebsd.c ../../dev/isp/isp.c = ../../dev/dpt/dpt_scsi.c ../../dev/ppbus/lpt.c ../../dev/ppbus/ppb_base.c = ../../dev/ppbus/ppb_1284.c ../../dev/ppbus/ppb_msq.c = ../../dev/ppbus/ppbconf.c ../../dev/ppbus/ppi.c ../../dev/ppbus/if_plip.c = ../../dev/vx/if_vx.c ../../isofs/cd9660/cd9660_bmap.c = ../../isofs/cd9660/cd9660_lookup.c ../../isofs/cd9660/cd9660_node.c = ../../isofs/cd9660/cd9660_rrip.c ../../isofs/cd9660/cd9660_util.c = ../../isofs/cd9660/cd9660_vfsops.c ../../isofs/cd9660/cd9660_vnops.c = ../../kern/imgact_aout.c ../../kern/imgact_elf.c ../../kern/imgact_gzip.c = ../../kern/imgact_shell.c ../../kern/inflate.c ../../kern/init_main.c = ../../kern/init_sysent.c ../../kern/kern_intr.c ../../kern/kern_module.c = ../../kern/kern_linker.c ../../kern/link_aout.c ../../kern/link_elf.c = ../../kern/kern_acct.c ../../kern/kern_clock.c ../../kern/kern_conf.c = ../../kern/kern_descrip.c ../../kern/kern_environment.c = ../../kern/kern_exec.c ../../kern/kern_exit.c ../../kern/kern_fork.c = ../../kern/kern_ktrace.c ../../kern/kern_lock.c ../../kern/kern_lockf.c = ../../kern/kern_malloc.c ../../kern/kern_mib.c ../../kern/kern_ntptime.c = ../../kern/kern_physio.c ../../kern/kern_proc.c ../../kern/kern_prot.c = ../../kern/kern_resource.c ../../kern/kern_shutdown.c = ../../kern/kern_sig.c ../../kern/kern_subr.c ../../kern/kern_synch.c = ../../kern/kern_syscalls.c ../../kern/kern_sysctl.c ../../kern/kern_time.c= ../../kern/kern_timeout.c ../../kern/kern_xxx.c ../../kern/md5c.c= ../../kern/subr_autoconf.c ../../kern/subr_bus.c ../../kern/subr_devstat.c= ../../kern/subr_diskslice.c ../../kern/subr_dkbad.c ../../kern/subr_log.c= ../../kern/subr_module.c ../../kern/subr_prf.c ../../kern/subr_prof.c= ../../kern/subr_rlist.c ../../kern/subr_scanf.c ../../kern/subr_xxx.c= ../../kern/sys_generic.c ../../kern/sys_pipe.c ../../kern/sys_process.c= ../../kern/subr_rman.c ../../kern/sys_socket.c ../../kern/sysv_ipc.c= ../../kern/sysv_msg.c ../../kern/sysv_sem.c ../../kern/sysv_shm.c= ../../kern/tty.c ../../kern/tty_compat.c ../../kern/tty_conf.c= ../../kern/tty_pty.c ../../kern/tty_subr.c ../../kern/tty_tty.c= ../../kern/uipc_domain.c ../../kern/uipc_mbuf.c ../../kern/uipc_proto.c= ../../kern/uipc_socket.c ../../kern/uipc_socket2.c= ../../kern/uipc_syscalls.c ../../kern/uipc_usrreq.c ../../kern/vfs_bio.c= ../../kern/vfs_cache.c ../../kern/vfs_cluster.c ../../kern/vfs_conf.c= ../../kern/vfs_default.c ../../kern/vfs_init.c ../../kern/vfs_lookup.c= ../../kern/vfs_subr.c ../../kern/vfs_syscalls.c ../../kern/vfs_vnops.c = ../../kern/kern_threads.c ../../kern/vfs_aio.c = ../../miscfs/deadfs/dead_vnops.c ../../miscfs/fifofs/fifo_vnops.c = ../../miscfs/procfs/procfs_ctl.c ../../miscfs/procfs/procfs_fpregs.c = ../../miscfs/procfs/procfs_map.c ../../miscfs/procfs/procfs_mem.c = ../../miscfs/procfs/procfs_note.c ../../miscfs/procfs/procfs_regs.c = ../../miscfs/procfs/procfs_status.c ../../miscfs/procfs/procfs_subr.c = ../../miscfs/procfs/procfs_type.c ../../miscfs/procfs/procfs_vfsops.c = ../../miscfs/procfs/procfs_vnops.c ../../miscfs/specfs/spec_vnops.c = ../../msdosfs/msdosfs_conv.c ../../msdosfs/msdosfs_denode.c = ../../msdosfs/msdosfs_fat.c ../../msdosfs/msdosfs_lookup.c = ../../msdosfs/msdosfs_vfsops.c ../../msdosfs/msdosfs_vnops.c = ../../net/bpf.c ../../net/bpf_filter.c ../../net/altq_conf.c ../../net/if.c= ../../net/if_ethersubr.c ../../net/if_loop.c ../../net/if_media.c = ../../net/if_mib.c ../../net/if_ppp.c ../../net/if_sl.c ../../net/if_tun.c = ../../net/ppp_tty.c ../../net/radix.c ../../net/raw_cb.c = ../../net/raw_usrreq.c ../../net/route.c ../../net/rtsock.c = ../../net/slcompress.c ../../net/zlib.c ../../netinet/altq_afmap.c = ../../netinet/altq_blue.c ../../netinet/altq_cbq.c = ../../netinet/altq_cdnr.c ../../netinet/altq_fifoq.c = ../../netinet/altq_hfsc.c ../../netinet/altq_localq.c = ../../netinet/altq_red.c ../../netinet/altq_rio.c = ../../netinet/altq_rmclass.c ../../netinet/altq_subr.c = ../../netinet/altq_wfq.c ../../netinet/if_ether.c ../../netinet/igmp.c = ../../netinet/in.c ../../netinet/in_pcb.c ../../netinet/in_proto.c = ../../netinet/in_rmx.c ../../netinet/ip_flow.c ../../netinet/ip_icmp.c = ../../netinet/ip_input.c ../../netinet/ip_mroute.c = ../../netinet/ip_output.c ../../netinet/raw_ip.c ../../netinet/tcp_input.c= ../../netinet/tcp_output.c ../../netinet/tcp_subr.c= ../../netinet/tcp_timer.c ../../netinet/tcp_usrreq.c= ../../netinet/udp_usrreq.c ../../netkey/key.c ../../netkey/key_debug.c= ../../netkey/keysock.c ../../nfs/nfs_bio.c ../../nfs/nfs_node.c= ../../nfs/nfs_nqlease.c ../../nfs/nfs_serv.c ../../nfs/nfs_socket.c= ../../nfs/nfs_srvcache.c ../../nfs/nfs_subs.c ../../nfs/nfs_syscalls.c= ../../nfs/nfs_vfsops.c ../../nfs/nfs_vnops.c ../../pci/amd.c= ../../pci/adv_pci.c ../../pci/adw_pci.c ../../pci/ahc_pci.c = ../../pci/bt_pci.c ../../pci/dpt_pci.c ../../pci/if_al.c ../../pci/if_ax.c = ../../pci/if_de.c ../../pci/if_ed_p.c ../../pci/if_fxp.c = ../../pci/if_lnc_p.c ../../pci/if_mx.c ../../pci/if_pn.c ../../pci/if_rl.c = ../../pci/if_sf.c ../../pci/if_tl.c ../../pci/if_tx.c ../../pci/if_vr.c = ../../pci/if_vx_pci.c ../../pci/if_wb.c ../../pci/if_xl.c = ../../pci/isp_pci.c ../../pci/ncr.c ../../pci/pci.c ../../pci/pci_compat.c = ../../pci/pcisupport.c ../../pci/wdc_p.c ../../posix4/posix4_mib.c = ../../posix4/p1003_1b.c ../../net/if_dummy.c ../../net/if_gif.c = ../../net/net_osdep.c ../../netinet/in_gif.c ../../netinet6/in6_gif.c = ../../netinet/ip_ecn.c ../../netinet6/in6.c ../../netinet6/in6_ifattach.c = ../../netinet6/in6_cksum.c ../../netinet6/in6_pcb.c = ../../netinet6/in6_proto.c ../../netinet6/in6_rmx.c = ../../netinet6/in6_prefix.c ../../netinet6/dest6.c ../../netinet6/frag6.c = ../../netinet6/icmp6.c ../../netinet6/ip6_input.c = ../../netinet6/ip6_forward.c ../../netinet6/ip6_mroute.c = ../../netinet6/ip6_output.c ../../netinet6/route6.c ../../netinet6/mld6.c = ../../netinet6/nd6.c ../../netinet6/nd6_nbr.c ../../netinet6/nd6_rtr.c = ../../netinet6/raw_ip6.c ../../netinet6/udp6_usrreq.c = ../../netinet6/ah_core.c ../../netinet6/esp_core.c ../../netinet6/ipsec.c = ../../netinet6/ah_output.c ../../netinet6/ah_input.c = ../../netinet6/esp_output.c ../../netinet6/esp_input.c = ../../netinet6/ipcomp_core.c ../../netinet6/ipcomp_input.c = ../../netinet6/ipcomp_output.c ../../crypto/sha1.c = ../../crypto/des/des_cbc.c ../../crypto/des/des_ecb.c = ../../crypto/des/des_setkey.c ../../crypto/des/des_3cbc.c = ../../crypto/blowfish/bf_cbc.c ../../crypto/blowfish/bf_cbc_m.c = ../../crypto/blowfish/bf_enc.c ../../crypto/blowfish/bf_skey.c = ../../crypto/cast128/cast128.c ../../crypto/cast128/cast128_cbc.c = ../../crypto/rc5/rc5.c ../../crypto/rc5/rc5_cbc.c = ../../ufs/ffs/ffs_alloc.c ../../ufs/ffs/ffs_balloc.c = ../../ufs/ffs/ffs_inode.c ../../ufs/ffs/ffs_softdep_stub.c = ../../ufs/ffs/ffs_subr.c ../../ufs/ffs/ffs_tables.c = ../../ufs/ffs/ffs_vfsops.c ../../ufs/ffs/ffs_vnops.c = ../../ufs/mfs/mfs_vfsops.c ../../ufs/mfs/mfs_vnops.c = ../../ufs/ufs/ufs_bmap.c ../../ufs/ufs/ufs_disksubr.c = ../../ufs/ufs/ufs_ihash.c ../../ufs/ufs/ufs_inode.c = ../../ufs/ufs/ufs_lookup.c ../../ufs/ufs/ufs_quota.c = ../../ufs/ufs/ufs_vfsops.c ../../ufs/ufs/ufs_vnops.c = ../../vm/default_pager.c ../../vm/device_pager.c ../../vm/swap_pager.c = ../../vm/vm_fault.c ../../vm/vm_glue.c ../../vm/vm_init.c= ../../vm/vm_kern.c ../../vm/vm_map.c ../../vm/vm_meter.c= ../../vm/vm_mmap.c ../../vm/vm_object.c ../../vm/vm_page.c= ../../vm/vm_pageout.c ../../vm/vm_pager.c ../../vm/vm_swap.c= ../../vm/vm_unix.c ../../vm/vnode_pager.c ../../vm/vm_zone.c= ../../dev/fb/fb.c ../../dev/fb/splash.c ../../dev/kbd/atkbd.c= ../../dev/kbd/atkbdc.c ../../dev/kbd/kbd.c ../../dev/syscons/syscons.c = ../../dev/syscons/scvidctl.c ../../dev/syscons/scvesactl.c = ../../i386/apm/apm.c ../../i386/eisa/dpt_eisa.c ../../i386/eisa/3c5x9.c = ../../i386/eisa/adv_eisa.c ../../i386/eisa/ahc_eisa.c = ../../i386/eisa/ahb.c ../../i386/eisa/bt_eisa.c ../../i386/eisa/eisaconf.c= ../../i386/eisa/if_vx_eisa.c ../../i386/i386/atomic.c= ../../i386/i386/autoconf.c ../../i386/i386/bios.c= ../../i386/i386/busdma_machdep.c ../../i386/i386/cons.c= ../../i386/i386/elf_machdep.c ../../i386/i386/i686_mem.c= ../../i386/i386/identcpu.c ../../i386/i386/in_cksum.c= ../../i386/i386/initcpu.c ../../i386/i386/machdep.c= ../../i386/i386/math_emulate.c ../../i386/i386/mem.c= ../../i386/i386/pmap.c ../../i386/i386/procfs_machdep.c= ../../i386/i386/sys_machdep.c ../../i386/i386/trap.c= ../../i386/i386/userconfig.c ../../i386/i386/vm_machdep.c= ../../i386/isa/adv_isa.c ../../i386/isa/aha_isa.c= ../../i386/isa/atkbd_isa.c ../../i386/isa/atkbdc_isa.c= ../../i386/isa/bt_isa.c ../../i386/isa/clock.c= ../../i386/isa/diskslice_machdep.c ../../i386/isa/elink.c= ../../i386/isa/fd.c ../../i386/isa/if_cs.c ../../i386/isa/if_ed.c= ../../i386/isa/if_ep.c ../../i386/isa/if_ex.c ../../i386/isa/if_fe.c= ../../i386/isa/if_ie.c ../../i386/isa/if_le.c ../../i386/isa/if_lnc.c= ../../i386/isa/if_ze.c ../../i386/isa/if_zp.c ../../i386/isa/ipl_funcs.c= ../../i386/isa/intr_machdep.c ../../i386/isa/isa.c ../../i386/isa/mcd.c= ../../i386/isa/npx.c ../../i386/isa/matcd/matcd.c ../../i386/isa/pcibus.c = ../../i386/isa/pcicx.c ../../i386/isa/pnp.c ../../i386/isa/ppc.c = ../../i386/isa/psm.c ../../i386/isa/random_machdep.c ../../i386/isa/scd.c = ../../i386/isa/sio.c ../../i386/isa/syscons_isa.c ../../i386/isa/vesa.c = ../../i386/isa/vga_isa.c ../../i386/isa/wd.c ../../i386/isa/atapi.c = ../../i386/isa/atapi-cd.c ../../i386/isa/wfd.c ../../i386/isa/wt.c = ../../libkern/bcd.c ../../libkern/divdi3.c ../../libkern/inet_ntoa.c = ../../libkern/index.c ../../libkern/moddi3.c ../../libkern/qdivrem.c = ../../libkern/qsort.c ../../libkern/random.c ../../libkern/rindex.c = ../../libkern/scanc.c ../../libkern/skpc.c ../../libkern/strcat.c = ../../libkern/strcmp.c ../../libkern/strcpy.c ../../libkern/strlen.c = ../../libkern/strncmp.c ../../libkern/strncpy.c ../../libkern/udivdi3.c = ../../libkern/umoddi3.c ../../pci/ide_pci.c swapkernel.c ioconf.c param.c= vnode_if.c config.c mkdep -a -f .newdep -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi = -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include= opt_global.h -D_KERNEL ../../i386/i386/genassym.c env MKDEP_CPP=3D"cc -E" mkdep -a -f .newdep -x assembler-with-cpp -DLOCORE= -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs= -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline= -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I-= -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h= -D_KERNEL -elf ../../i386/apm/apm_setup.s ../../i386/i386/bioscall.s = ../../i386/i386/exception.s ../../i386/i386/globals.s = ../../i386/i386/support.s ../../i386/i386/swtch.s ../../i386/i386/locore.s rm -f .depend mv -f .newdep .depend saturno# exit exit Script done on Mon Jan 10 17:57:57 2000 --=====================_947559856==_ Content-Type: text/plain; charset="us-ascii" ******************************** * Luciano Rabelo * * Analista de Sistemas * * Salvador - Bahia - Brasil * * http://www.rabelo.eti.br/ * * lrcp@rabelo.eti.br * * UIN - 8642704 * ******************************** /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ --=====================_947559856==_-- From boozy@rabelo.eti.br Tue Jan 11 01:17:51 2000 From: boozy@rabelo.eti.br (Boozy) Date: Mon, 10 Jan 2000 23:17:51 -0200 Subject: Problemas na instalacao do KAME Message-ID: <200001110125.XAA16003@svn.com.br> --=====================_947560671==_ Content-Type: text/plain; charset="us-ascii" Hello, I have downloaded the last stable version of KAME for FreeBSD (19991213), but I didn't get sucess. I extracted the tgx file into /usr/kame and copied the file GENERIC.v6 to saturno.v6 without any changes. I ran /usr/sbin/config saturno.v6 without any problems. However some erros occurred when I tried to execute make depend. Can anybody help me? I'm using FreeBSD 3.3 and I'm sending the file created by the script command. [] Luciano Rabelo --=====================_947560671==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="step_2b" Script started on Mon Jan 10 17:52:51 2000 saturno# pwd /usr/kame/freebsd3 saturno# cd sys/i386/conf saturno# cp GENERIC.v6 saturno.v6 saturno# /usr/sbin/config saturno.v6 Don't forget to do a ``make depend'' Kernel build directory is ../../compile/saturno.v6 saturno# cd ../../compile/saturno.v6/ saturno# make depend cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi = -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include= opt_global.h -D_KERNEL ../../i386/i386/genassym.c cc -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs= -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline= -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I-= -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h= -D_KERNEL genassym.o -o genassym ./genassym >assym.s rm -f param.c cp ../../conf/param.c . sh ../../kern/vnode_if.sh ../../kern/vnode_if.src make -f ../../dev/aic7xxx/Makefile MAKESRCPATH=3D../../dev/aic7xxx Warning: Object directory not changed from original= /usr/kame/freebsd3/sys/compile/saturno.v6 yacc -d ../../dev/aic7xxx/aicasm_gram.y mv y.tab.c aicasm_gram.c cc -O -pipe -I/usr/include -I. -c aicasm_gram.c lex -t ../../dev/aic7xxx/aicasm_scan.l > aicasm_scan.c cc -O -pipe -I/usr/include -I. -c aicasm_scan.c cc -O -pipe -I/usr/include -I. -c ../../dev/aic7xxx/aicasm.c cc -O -pipe -I/usr/include -I. -c ../../dev/aic7xxx/aicasm_symbol.c cc -O -pipe -I/usr/include -I. -o aicasm aicasm_gram.o aicasm_scan.o= aicasm.o aicasm_symbol.o -ll ./aicasm -nostdinc -I- -I. -I../.. -I../../../include -o aic7xxx_seq.h -r= aic7xxx_reg.h ../../dev/aic7xxx/aic7xxx.seq ./aicasm: 709 instructions used perl5 ../../kern/makedevops.pl -c ../../kern/device_if.m perl5 ../../kern/makedevops.pl -h ../../kern/device_if.m perl5 ../../kern/makedevops.pl -c ../../kern/bus_if.m perl5 ../../kern/makedevops.pl -h ../../kern/bus_if.m rm -f .newdep mkdep -a -f .newdep -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi = -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include= opt_global.h -D_KERNEL -elf device_if.c bus_if.c ../../cam/cam.c= ../../cam/cam_xpt.c ../../cam/cam_extend.c ../../cam/cam_queue.c= ../../cam/cam_periph.c ../../cam/cam_sim.c ../../cam/scsi/scsi_all.c= ../../cam/scsi/scsi_da.c ../../cam/scsi/scsi_sa.c ../../cam/scsi/scsi_cd.c= ../../cam/scsi/scsi_pass.c ../../dev/advansys/advansys.c = ../../dev/advansys/advlib.c ../../dev/advansys/advmcode.c = ../../dev/advansys/adwcam.c ../../dev/advansys/adwlib.c = ../../dev/advansys/adwmcode.c ../../dev/aha/aha.c = ../../dev/aic7xxx/aic7xxx.c ../../dev/aic7xxx/93cx6.c = ../../dev/buslogic/bt.c ../../dev/isp/isp_freebsd.c ../../dev/isp/isp.c = ../../dev/dpt/dpt_scsi.c ../../dev/ppbus/lpt.c ../../dev/ppbus/ppb_base.c = ../../dev/ppbus/ppb_1284.c ../../dev/ppbus/ppb_msq.c = ../../dev/ppbus/ppbconf.c ../../dev/ppbus/ppi.c ../../dev/ppbus/if_plip.c = ../../dev/vx/if_vx.c ../../isofs/cd9660/cd9660_bmap.c = ../../isofs/cd9660/cd9660_lookup.c ../../isofs/cd9660/cd9660_node.c = ../../isofs/cd9660/cd9660_rrip.c ../../isofs/cd9660/cd9660_util.c = ../../isofs/cd9660/cd9660_vfsops.c ../../isofs/cd9660/cd9660_vnops.c = ../../kern/imgact_aout.c ../../kern/imgact_elf.c ../../kern/imgact_gzip.c = ../../kern/imgact_shell.c ../../kern/inflate.c ../../kern/init_main.c = ../../kern/init_sysent.c ../../kern/kern_intr.c ../../kern/kern_module.c = ../../kern/kern_linker.c ../../kern/link_aout.c ../../kern/link_elf.c = ../../kern/kern_acct.c ../../kern/kern_clock.c ../../kern/kern_conf.c = ../../kern/kern_descrip.c ../../kern/kern_environment.c = ../../kern/kern_exec.c ../../kern/kern_exit.c ../../kern/kern_fork.c = ../../kern/kern_ktrace.c ../../kern/kern_lock.c ../../kern/kern_lockf.c = ../../kern/kern_malloc.c ../../kern/kern_mib.c ../../kern/kern_ntptime.c = ../../kern/kern_physio.c ../../kern/kern_proc.c ../../kern/kern_prot.c = ../../kern/kern_resource.c ../../kern/kern_shutdown.c = ../../kern/kern_sig.c ../../kern/kern_subr.c ../../kern/kern_synch.c = ../../kern/kern_syscalls.c ../../kern/kern_sysctl.c ../../kern/kern_time.c= ../../kern/kern_timeout.c ../../kern/kern_xxx.c ../../kern/md5c.c= ../../kern/subr_autoconf.c ../../kern/subr_bus.c ../../kern/subr_devstat.c= ../../kern/subr_diskslice.c ../../kern/subr_dkbad.c ../../kern/subr_log.c= ../../kern/subr_module.c ../../kern/subr_prf.c ../../kern/subr_prof.c= ../../kern/subr_rlist.c ../../kern/subr_scanf.c ../../kern/subr_xxx.c= ../../kern/sys_generic.c ../../kern/sys_pipe.c ../../kern/sys_process.c= ../../kern/subr_rman.c ../../kern/sys_socket.c ../../kern/sysv_ipc.c= ../../kern/sysv_msg.c ../../kern/sysv_sem.c ../../kern/sysv_shm.c= ../../kern/tty.c ../../kern/tty_compat.c ../../kern/tty_conf.c= ../../kern/tty_pty.c ../../kern/tty_subr.c ../../kern/tty_tty.c= ../../kern/uipc_domain.c ../../kern/uipc_mbuf.c ../../kern/uipc_proto.c= ../../kern/uipc_socket.c ../../kern/uipc_socket2.c= ../../kern/uipc_syscalls.c ../../kern/uipc_usrreq.c ../../kern/vfs_bio.c= ../../kern/vfs_cache.c ../../kern/vfs_cluster.c ../../kern/vfs_conf.c= ../../kern/vfs_default.c ../../kern/vfs_init.c ../../kern/vfs_lookup.c= ../../kern/vfs_subr.c ../../kern/vfs_syscalls.c ../../kern/vfs_vnops.c = ../../kern/kern_threads.c ../../kern/vfs_aio.c = ../../miscfs/deadfs/dead_vnops.c ../../miscfs/fifofs/fifo_vnops.c = ../../miscfs/procfs/procfs_ctl.c ../../miscfs/procfs/procfs_fpregs.c = ../../miscfs/procfs/procfs_map.c ../../miscfs/procfs/procfs_mem.c = ../../miscfs/procfs/procfs_note.c ../../miscfs/procfs/procfs_regs.c = ../../miscfs/procfs/procfs_status.c ../../miscfs/procfs/procfs_subr.c = ../../miscfs/procfs/procfs_type.c ../../miscfs/procfs/procfs_vfsops.c = ../../miscfs/procfs/procfs_vnops.c ../../miscfs/specfs/spec_vnops.c = ../../msdosfs/msdosfs_conv.c ../../msdosfs/msdosfs_denode.c = ../../msdosfs/msdosfs_fat.c ../../msdosfs/msdosfs_lookup.c = ../../msdosfs/msdosfs_vfsops.c ../../msdosfs/msdosfs_vnops.c = ../../net/bpf.c ../../net/bpf_filter.c ../../net/altq_conf.c ../../net/if.c= ../../net/if_ethersubr.c ../../net/if_loop.c ../../net/if_media.c = ../../net/if_mib.c ../../net/if_ppp.c ../../net/if_sl.c ../../net/if_tun.c = ../../net/ppp_tty.c ../../net/radix.c ../../net/raw_cb.c = ../../net/raw_usrreq.c ../../net/route.c ../../net/rtsock.c = ../../net/slcompress.c ../../net/zlib.c ../../netinet/altq_afmap.c = ../../netinet/altq_blue.c ../../netinet/altq_cbq.c = ../../netinet/altq_cdnr.c ../../netinet/altq_fifoq.c = ../../netinet/altq_hfsc.c ../../netinet/altq_localq.c = ../../netinet/altq_red.c ../../netinet/altq_rio.c = ../../netinet/altq_rmclass.c ../../netinet/altq_subr.c = ../../netinet/altq_wfq.c ../../netinet/if_ether.c ../../netinet/igmp.c = ../../netinet/in.c ../../netinet/in_pcb.c ../../netinet/in_proto.c = ../../netinet/in_rmx.c ../../netinet/ip_flow.c ../../netinet/ip_icmp.c = ../../netinet/ip_input.c ../../netinet/ip_mroute.c = ../../netinet/ip_output.c ../../netinet/raw_ip.c ../../netinet/tcp_input.c= ../../netinet/tcp_output.c ../../netinet/tcp_subr.c= ../../netinet/tcp_timer.c ../../netinet/tcp_usrreq.c= ../../netinet/udp_usrreq.c ../../netkey/key.c ../../netkey/key_debug.c= ../../netkey/keysock.c ../../nfs/nfs_bio.c ../../nfs/nfs_node.c= ../../nfs/nfs_nqlease.c ../../nfs/nfs_serv.c ../../nfs/nfs_socket.c= ../../nfs/nfs_srvcache.c ../../nfs/nfs_subs.c ../../nfs/nfs_syscalls.c= ../../nfs/nfs_vfsops.c ../../nfs/nfs_vnops.c ../../pci/amd.c= ../../pci/adv_pci.c ../../pci/adw_pci.c ../../pci/ahc_pci.c = ../../pci/bt_pci.c ../../pci/dpt_pci.c ../../pci/if_al.c ../../pci/if_ax.c = ../../pci/if_de.c ../../pci/if_ed_p.c ../../pci/if_fxp.c = ../../pci/if_lnc_p.c ../../pci/if_mx.c ../../pci/if_pn.c ../../pci/if_rl.c = ../../pci/if_sf.c ../../pci/if_tl.c ../../pci/if_tx.c ../../pci/if_vr.c = ../../pci/if_vx_pci.c ../../pci/if_wb.c ../../pci/if_xl.c = ../../pci/isp_pci.c ../../pci/ncr.c ../../pci/pci.c ../../pci/pci_compat.c = ../../pci/pcisupport.c ../../pci/wdc_p.c ../../posix4/posix4_mib.c = ../../posix4/p1003_1b.c ../../net/if_dummy.c ../../net/if_gif.c = ../../net/net_osdep.c ../../netinet/in_gif.c ../../netinet6/in6_gif.c = ../../netinet/ip_ecn.c ../../netinet6/in6.c ../../netinet6/in6_ifattach.c = ../../netinet6/in6_cksum.c ../../netinet6/in6_pcb.c = ../../netinet6/in6_proto.c ../../netinet6/in6_rmx.c = ../../netinet6/in6_prefix.c ../../netinet6/dest6.c ../../netinet6/frag6.c = ../../netinet6/icmp6.c ../../netinet6/ip6_input.c = ../../netinet6/ip6_forward.c ../../netinet6/ip6_mroute.c = ../../netinet6/ip6_output.c ../../netinet6/route6.c ../../netinet6/mld6.c = ../../netinet6/nd6.c ../../netinet6/nd6_nbr.c ../../netinet6/nd6_rtr.c = ../../netinet6/raw_ip6.c ../../netinet6/udp6_usrreq.c = ../../netinet6/ah_core.c ../../netinet6/esp_core.c ../../netinet6/ipsec.c = ../../netinet6/ah_output.c ../../netinet6/ah_input.c = ../../netinet6/esp_output.c ../../netinet6/esp_input.c = ../../netinet6/ipcomp_core.c ../../netinet6/ipcomp_input.c = ../../netinet6/ipcomp_output.c ../../crypto/sha1.c = ../../crypto/des/des_cbc.c ../../crypto/des/des_ecb.c = ../../crypto/des/des_setkey.c ../../crypto/des/des_3cbc.c = ../../crypto/blowfish/bf_cbc.c ../../crypto/blowfish/bf_cbc_m.c = ../../crypto/blowfish/bf_enc.c ../../crypto/blowfish/bf_skey.c = ../../crypto/cast128/cast128.c ../../crypto/cast128/cast128_cbc.c = ../../crypto/rc5/rc5.c ../../crypto/rc5/rc5_cbc.c = ../../ufs/ffs/ffs_alloc.c ../../ufs/ffs/ffs_balloc.c = ../../ufs/ffs/ffs_inode.c ../../ufs/ffs/ffs_softdep_stub.c = ../../ufs/ffs/ffs_subr.c ../../ufs/ffs/ffs_tables.c = ../../ufs/ffs/ffs_vfsops.c ../../ufs/ffs/ffs_vnops.c = ../../ufs/mfs/mfs_vfsops.c ../../ufs/mfs/mfs_vnops.c = ../../ufs/ufs/ufs_bmap.c ../../ufs/ufs/ufs_disksubr.c = ../../ufs/ufs/ufs_ihash.c ../../ufs/ufs/ufs_inode.c = ../../ufs/ufs/ufs_lookup.c ../../ufs/ufs/ufs_quota.c = ../../ufs/ufs/ufs_vfsops.c ../../ufs/ufs/ufs_vnops.c = ../../vm/default_pager.c ../../vm/device_pager.c ../../vm/swap_pager.c = ../../vm/vm_fault.c ../../vm/vm_glue.c ../../vm/vm_init.c= ../../vm/vm_kern.c ../../vm/vm_map.c ../../vm/vm_meter.c= ../../vm/vm_mmap.c ../../vm/vm_object.c ../../vm/vm_page.c= ../../vm/vm_pageout.c ../../vm/vm_pager.c ../../vm/vm_swap.c= ../../vm/vm_unix.c ../../vm/vnode_pager.c ../../vm/vm_zone.c= ../../dev/fb/fb.c ../../dev/fb/splash.c ../../dev/kbd/atkbd.c= ../../dev/kbd/atkbdc.c ../../dev/kbd/kbd.c ../../dev/syscons/syscons.c = ../../dev/syscons/scvidctl.c ../../dev/syscons/scvesactl.c = ../../i386/apm/apm.c ../../i386/eisa/dpt_eisa.c ../../i386/eisa/3c5x9.c = ../../i386/eisa/adv_eisa.c ../../i386/eisa/ahc_eisa.c = ../../i386/eisa/ahb.c ../../i386/eisa/bt_eisa.c ../../i386/eisa/eisaconf.c= ../../i386/eisa/if_vx_eisa.c ../../i386/i386/atomic.c= ../../i386/i386/autoconf.c ../../i386/i386/bios.c= ../../i386/i386/busdma_machdep.c ../../i386/i386/cons.c= ../../i386/i386/elf_machdep.c ../../i386/i386/i686_mem.c= ../../i386/i386/identcpu.c ../../i386/i386/in_cksum.c= ../../i386/i386/initcpu.c ../../i386/i386/machdep.c= ../../i386/i386/math_emulate.c ../../i386/i386/mem.c= ../../i386/i386/pmap.c ../../i386/i386/procfs_machdep.c= ../../i386/i386/sys_machdep.c ../../i386/i386/trap.c= ../../i386/i386/userconfig.c ../../i386/i386/vm_machdep.c= ../../i386/isa/adv_isa.c ../../i386/isa/aha_isa.c= ../../i386/isa/atkbd_isa.c ../../i386/isa/atkbdc_isa.c= ../../i386/isa/bt_isa.c ../../i386/isa/clock.c= ../../i386/isa/diskslice_machdep.c ../../i386/isa/elink.c= ../../i386/isa/fd.c ../../i386/isa/if_cs.c ../../i386/isa/if_ed.c= ../../i386/isa/if_ep.c ../../i386/isa/if_ex.c ../../i386/isa/if_fe.c= ../../i386/isa/if_ie.c ../../i386/isa/if_le.c ../../i386/isa/if_lnc.c= ../../i386/isa/if_ze.c ../../i386/isa/if_zp.c ../../i386/isa/ipl_funcs.c= ../../i386/isa/intr_machdep.c ../../i386/isa/isa.c ../../i386/isa/mcd.c= ../../i386/isa/npx.c ../../i386/isa/matcd/matcd.c ../../i386/isa/pcibus.c = ../../i386/isa/pcicx.c ../../i386/isa/pnp.c ../../i386/isa/ppc.c = ../../i386/isa/psm.c ../../i386/isa/random_machdep.c ../../i386/isa/scd.c = ../../i386/isa/sio.c ../../i386/isa/syscons_isa.c ../../i386/isa/vesa.c = ../../i386/isa/vga_isa.c ../../i386/isa/wd.c ../../i386/isa/atapi.c = ../../i386/isa/atapi-cd.c ../../i386/isa/wfd.c ../../i386/isa/wt.c = ../../libkern/bcd.c ../../libkern/divdi3.c ../../libkern/inet_ntoa.c = ../../libkern/index.c ../../libkern/moddi3.c ../../libkern/qdivrem.c = ../../libkern/qsort.c ../../libkern/random.c ../../libkern/rindex.c = ../../libkern/scanc.c ../../libkern/skpc.c ../../libkern/strcat.c = ../../libkern/strcmp.c ../../libkern/strcpy.c ../../libkern/strlen.c = ../../libkern/strncmp.c ../../libkern/strncpy.c ../../libkern/udivdi3.c = ../../libkern/umoddi3.c ../../pci/ide_pci.c swapkernel.c ioconf.c param.c= vnode_if.c config.c mkdep -a -f .newdep -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith= -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi = -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include= opt_global.h -D_KERNEL ../../i386/i386/genassym.c env MKDEP_CPP=3D"cc -E" mkdep -a -f .newdep -x assembler-with-cpp -DLOCORE= -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs= -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline= -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I-= -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h= -D_KERNEL -elf ../../i386/apm/apm_setup.s ../../i386/i386/bioscall.s = ../../i386/i386/exception.s ../../i386/i386/globals.s = ../../i386/i386/support.s ../../i386/i386/swtch.s ../../i386/i386/locore.s rm -f .depend mv -f .newdep .depend saturno# exit exit Script done on Mon Jan 10 17:57:57 2000 --=====================_947560671==_ Content-Type: text/plain; charset="us-ascii" ******************************** * Luciano Rabelo * * Analista de Sistemas * * Salvador - Bahia - Brasil * * http://www.rabelo.eti.br/ * * lrcp@rabelo.eti.br * * UIN - 8642704 * ******************************** /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ --=====================_947560671==_-- From dlitz@cheerful.com Tue Jan 11 02:12:43 2000 From: dlitz@cheerful.com (Dwayne C . Litzenberger) Date: Mon, 10 Jan 2000 20:12:43 -0600 Subject: IPv6 address/port format In-Reply-To: ; from hwang@371.net on Tue, Jan 11, 2000 at 09:22:53AM +0800 References: <009E3F04.FAB256C4.6@cc.univie.ac.at> Message-ID: <20000110201243.A4658@dlitz.dyn.dhs.org> --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2000 at 09:22:53AM +0800, Wang Hui wrote: > I suggest that we use the symbol of `#' to seperate the IP address and= =20 > the port *number*. Since `#' is mostly pronounced as `number'. :)) why > not 3ffe:3216:2101::1#8080? > =20 > -Wang Hui. >=20 Let's not use a widely-used comment character to introduce bugs in our scri= pts. =20 --=20 "If you continue running Windows, your system may become unstable." -- Windows 95 BSOD Dwayne C. Litzenberger - dlitz@cheerful.com Please always Cc to me when replying to me on the lists. Advertising Policy: http://www.redrival.com/dlitz/spamoff.html GnuPG Public Key: http://www.redrival.com/dlitz/gpgkey.asc Fingerprint: 0535 F7CF FF5F 8547 E5A5 695E 4456 FB6C BC39 A4B0 --azLHFNyN32YCQGCU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEAREBAAYFAjh6kZsACgkQRFb7bLw5pLDeTQCfVpYPPDunxJsZ152GfCMv7vY6 lLwAn0sCot3KtPx3or9rcpsQjq3xrdx3 =FrNX -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From hansolofalcon@worldnet.att.net Tue Jan 11 03:59:41 2000 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Mon, 10 Jan 2000 22:59:41 -0500 Subject: Resend:Two questions Message-ID: <01BF5BBE.6277DE80.hansolofalcon@worldnet.att.net> Hello from Gregg C Levine usually at Jedi Knight Computers I am resending this message following because since sending it out, I have received nothing in response to it. I believe it happened because of the time it was sent, on 12/31/99, what with the usual things, following the coming of the millennium, and a strange work week following it. I have basically received little or no mail on the questions that I asked. Please everyone, do not dismiss them, at least remind me that I am off the topic. Hello from Gregg C Levine usually at Jedi Knight Computers I have two questions for the crowd on this mailing list: The first one is: Is anyone who is US based aware of access for the 6Bone project through a dial-up account from a non-participating ISP? This service provider AT&T Worldnet, so far has not moved in the direction that this list is moving into. (Nor or they even aware of the 6Bone, as of today 1/10/2000) The second question is:Is anyone working with the RSVP protocol, either on Linux/UNIX/Solaris, or on Windows? Also included on the non-Microsoft side is the operating systems for SGI workstations. Please realize that these are serious questions, as my group and I, are looking for new, and noteworthy questions to answer, and solutions to provide. Gregg C Levine mailto:hansolofalcon@worldnet.att.net "They were in the wrong place, at the wrong time, naturally they became heroes." Princess Leia Organna of Alderann, Senator "Remember, the Force will be with you." Obi-Wan(Ben) Kenobi, Jedi Knight and, General, (Retired) "May the Force be with you." Anonymous From lewis@tislabs.com Tue Jan 11 14:14:12 2000 From: lewis@tislabs.com (Edward Lewis) Date: Tue, 11 Jan 2000 09:14:12 -0500 Subject: Resend:Two questions In-Reply-To: <01BF5BBE.6277DE80.hansolofalcon@worldnet.att.net> Message-ID: At 10:59 PM -0500 1/10/00, Gregg C Levine wrote: >The first one is: Is anyone who is US based aware of access for the 6Bone >project through a dial-up account from a non-participating ISP? This >service provider AT&T Worldnet, so far has not moved in the direction that >this list is moving into. (Nor or they even aware of the 6Bone, as of today >1/10/2000) I kind of doubt that you will find commercial IPv6 service today. Speaking without certainty, the 6Bone is so far an experimental arrangement, vendors are unlikely to sell access to an experiment (that they don't completely control). Another part of the infrastructure still needed to be upgraded is DNS. There are no DNS servers (in general release) capable of supporting IPv6 in full. ISC is working on BIND version 9, and that won't be out (for testing) for a few months yet. It will have support for A6 records. IMHO. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From burgess@mitre.org Tue Jan 11 15:47:46 2000 From: burgess@mitre.org (David Burgess) Date: Tue, 11 Jan 2000 09:47:46 -0600 Subject: IPv6 address/port format References: <200001101530.PAA12945@orchard.arlington.ma.us> Message-ID: <387B50A2.17E67EE7@mitre.org> Bill Sommerfeld wrote: > > > "Dwayne C . Litzenberger" said: > > > I'm not really knowledgeable about this, but what is a good, standard way > > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > > address.:port (dot-colon) would be good (and it already works with domain > > > names), but I haven't seen this done yet. > > > > > Any thoughts? > > > > I've seen people use both "IPv6-addr port" (space sep.) and > > "IPv6-addr/port". I think I really like using '/', and haven't yet > > found a place where that will cause problems except for in URIs. > > It's too easily confused with network prefixes.. (IPv6-addr/prefixlen). > > How am I supposed to know whether 3ffe:1ce1:0:b5::1/64 should be > parsed as an pair or as a network prefix? > The obvious answer is, of course, by context. If I were to tell you to connect to 3ffe:1ce1:0:b5::1/64, then you would connect to service 64. If I was talking about routing issues, then the 64 would be the prefix length. In spite of that, I think the slash is still too problematic once we get into the WWW. There are places where the context is ambiguous. For example, the following URI should be perfectly reasonable: http://3ffe:1ce1:0:b5::1/1019/ Where 1019 is the directory on the web server that points to some website I'm hosting. The only tractable way to solve the problem is to come up with a different service port method. Since we're tossing suggestions around, how about putting the service number is square brackets. I can't think of a place where that would hurt us (except at the Unix shell prompt). Something like 3ffe:1ce1:0:b5::1[1019] would be doable.... Another suggestion would be to reverse the IPv4 semantics for dotted quad:service. For example, "3ffe:1ce1:0:b5::1.1019" might work. Since there are no valid v4 addresses in the 0.0.0.x or 0.0.1.x blocks, we wouldn't even have to worry about 32 bit v4 address representations. Without at least one more '.', it's fairly obvious that the suffix isn't an address component. From stephenb@uk.uu.net Tue Jan 11 16:21:51 2000 From: stephenb@uk.uu.net (stephenb@uk.uu.net) Date: Tue, 11 Jan 2000 16:21:51 +0000 (GMT) Subject: IPv6 address/port format In-Reply-To: <387B50A2.17E67EE7@mitre.org> Message-ID: <200001111635.IAA25840@tnt.isi.edu> On 11 Jan, David Burgess wrote: > > > Bill Sommerfeld wrote: >> >> > "Dwayne C . Litzenberger" said: >> > > I'm not really knowledgeable about this, but what is a good, standard way >> > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think >> > > address.:port (dot-colon) would be good (and it already works with domain >> > > names), but I haven't seen this done yet. >> > >> > > Any thoughts? >> > >> > I've seen people use both "IPv6-addr port" (space sep.) and >> > "IPv6-addr/port". I think I really like using '/', and haven't yet >> > found a place where that will cause problems except for in URIs. >> >> It's too easily confused with network prefixes.. (IPv6-addr/prefixlen). >> >> How am I supposed to know whether 3ffe:1ce1:0:b5::1/64 should be >> parsed as an pair or as a network prefix? >> > > The obvious answer is, of course, by context. If I were to tell you to > connect to 3ffe:1ce1:0:b5::1/64, then you would connect to service 64. > If I was talking about routing issues, then the 64 would be the prefix > length. > > In spite of that, I think the slash is still too problematic once we > get into the WWW. There are places where the context is ambiguous. For > example, the following URI should be perfectly reasonable: > > http://3ffe:1ce1:0:b5::1/1019/ > > Where 1019 is the directory on the web server that points to some > website I'm hosting. The only tractable way to solve the problem is to > come up with a different service port method. > > Since we're tossing suggestions around, how about putting the service > number is square brackets. I can't think of a place where that would > hurt us (except at the Unix shell prompt). Something like > 3ffe:1ce1:0:b5::1[1019] would be doable.... > > Another suggestion would be to reverse the IPv4 semantics for dotted > quad:service. For example, "3ffe:1ce1:0:b5::1.1019" might work. Since > there are no valid v4 addresses in the 0.0.0.x or 0.0.1.x blocks, we > wouldn't even have to worry about 32 bit v4 address representations. > Without at least one more '.', it's fairly obvious that the suffix isn't > an address component. > The / referance whould only cause confusion, why not have something slightly representative of IP @ a port number. Just a thought. 3ffe:1ce1:0:b5::1>64 -- ---------------------------------- E-Mail: stephenb@uk.uu.net Phone: +44 (0)1223 581051 Stephen Burley EMEA Registrar UUNET ---------------------------------- From lewis@tislabs.com Tue Jan 11 20:42:14 2000 From: lewis@tislabs.com (Edward Lewis) Date: Tue, 11 Jan 2000 15:42:14 -0500 Subject: IPv6 address/port format In-Reply-To: <387B50A2.17E67EE7@mitre.org> References: <200001101530.PAA12945@orchard.arlington.ma.us> Message-ID: At 10:47 AM -0500 1/11/00, David Burgess wrote: >In spite of that, I think the slash is still too problematic once we >get into the WWW. There are places where the context is ambiguous. For I agree, but FWIW, an escaped slash (%-something-something) is legal in an URL. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From dlitz@cheerful.com Tue Jan 11 13:40:28 2000 From: dlitz@cheerful.com (Dwayne C . Litzenberger) Date: Tue, 11 Jan 2000 07:40:28 -0600 Subject: IPv6 address/port format (summary of valid chars) In-Reply-To: <20000111034713.A2280@trout>; from eeyem@u.washington.edu on Tue, Jan 11, 2000 at 03:47:13AM -0800 References: <20000111034713.A2280@trout> Message-ID: <20000111074027.A1248@dlitz.dyn.dhs.org> --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2000 at 03:47:13AM -0800, eeyem@u.washington.edu wrote: > On Tue, Jan 11, 2000 at 12:44:14PM +0800, James Bromberger wrote: > > This leaves us with: > > ! @ % ^ > > * =3D + > >=20 > > I kind of like @: > > ::ffff:127.0.0.1@80 > >=20 > >=20 > > So a URl would look like: > > http://::ffff:127.0.0.1@80/ > >=20 > > And isf we can user service names (a la /etc/services): > > http://::ffff:127.0.0.1@www/ > >=20 > > It also kind of makes sense as 'at port 80'. The only problem I can > > see is perl - the @ array token needs to be escaped to \@ - but since > > this is already the case with email addresses in perl, this should > > not be too big a deal. We're not exactly reinventing the wheel here. > > The only problem comes with user education - that when a novice sees > > @, they currently think 'email'. Overloading > > this may cause some confusion. >=20 > @ is already used in URIs to indicate passwords. > http://user:password@host:port/path, IIRC. >=20 > Also, Ian McKellar pointed out that: > > Of course !, % and * (And sometimes ^) have special shell meanings too. >=20 > So if you want to be absolutely correct, you must use one of: > > =3D + >=20 > Two choices. Pathetic, eh? >=20 I've seen both ::ffff:127.0.0.1.:80 (dot-colon as the separator), and [::ffff:127.0.0.1]:80 ([] as the separator), and both would be better than using =3D or +.=20 I suggest using [addr]:port, as it's the easiest to read, and is already the "standard". -- "If you continue running Windows, your system may become unstable."=20 -- Windows 95 BSOD Dwayne C. Litzenberger - dlitz@cheerful.com Please always Cc to me when replying to me on the lists. Advertising Policy: http://www.redrival.com/dlitz/spamoff.html GnuPG Public Key: http://www.redrival.com/dlitz/gpgkey.asc Fingerprint: 0535 F7CF FF5F 8547 E5A5 695E 4456 FB6C BC39 A4B0 --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEAREBAAYFAjh7MssACgkQRFb7bLw5pLAhcACfWM2O30SLAJjh/RdsJgF4J5QG JB8An0MOFA+P9l66d/cja7MfHxERTLGL =2gX5 -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From mhw@wittsend.com Wed Jan 12 02:15:04 2000 From: mhw@wittsend.com (Michael H. Warfield) Date: Tue, 11 Jan 2000 21:15:04 -0500 Subject: IPv6 address/port format In-Reply-To: <387B50A2.17E67EE7@mitre.org>; from burgess@mitre.org on Tue, Jan 11, 2000 at 09:47:46AM -0600 References: <200001101530.PAA12945@orchard.arlington.ma.us> <387B50A2.17E67EE7@mitre.org> Message-ID: <20000111211504.A10106@alcove.wittsend.com> On Tue, Jan 11, 2000 at 09:47:46AM -0600, David Burgess wrote: > Bill Sommerfeld wrote: > > > "Dwayne C . Litzenberger" said: > > > > I'm not really knowledgeable about this, but what is a good, standard way > > > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > > > address.:port (dot-colon) would be good (and it already works with domain > > > > names), but I haven't seen this done yet. > > > > > > > Any thoughts? > > > I've seen people use both "IPv6-addr port" (space sep.) and > > > "IPv6-addr/port". I think I really like using '/', and haven't yet > > > found a place where that will cause problems except for in URIs. > > It's too easily confused with network prefixes.. (IPv6-addr/prefixlen). > > How am I supposed to know whether 3ffe:1ce1:0:b5::1/64 should be > > parsed as an pair or as a network prefix? > The obvious answer is, of course, by context. If I were to tell you to > connect to 3ffe:1ce1:0:b5::1/64, then you would connect to service 64. > If I was talking about routing issues, then the 64 would be the prefix > length. Bzzzt... Wrong answer... Firewall rule: Deny access to 3ffe:1ce1:0:b5::1/96 Are you saying to restrict the rule to port 96 on that host or are you saying restrict the rule to any port on the /96 subnet. It's ambigous to attempt to parse it without knowledge of the data contents you are attempting to parse and THAT'S unacceptable as a consequence. Overloading the '/' is going to be ambiguous in some contexts and I see no way to avoid that. [...] Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From hswu@ns.6test.edu.cn Wed Jan 12 04:02:43 2000 From: hswu@ns.6test.edu.cn (Haisang Wu) Date: Wed, 12 Jan 2000 12:02:43 +0800 (CST) Subject: IPv6 address/port format In-Reply-To: <387B50A2.17E67EE7@mitre.org> from David Burgess at "Jan 11, 2000 9:47:46 am" Message-ID: <200001120403.MAA23852@ns.6test.edu.cn> How about this: We still use / in the routing case and in the dir case. : and . should still be used in IPv6 address format. But when we express port, we use [] to include the IPv6 addresses or even domain name, other syntax kept the same as now. for instance, the following are expressed in tranditional ways: www.ipv6.net ---> 3ffe:1ce1:xxx:xxxx:xxx:xxxx:xxxx:xxxx 10.20.30.40 ---> (mapping IPv6) ::10.20.30.40 54.2 ::ffff:10.20.30.40 ::xxxx:xxxx ::ffff:xxxx:xxxx but for port 80 on www.ipv6.net, use [www.ipv6.net]:80 [3ffe:1ce1:xxx:xxxx:xxxx:xxxx:xxxx:xxxx]:80 and for urls: http://[..v6 address..]:port/dir/dir..... > > Since we're tossing suggestions around, how about putting the service > number is square brackets. I can't think of a place where that would > hurt us (except at the Unix shell prompt). Something like > 3ffe:1ce1:0:b5::1[1019] would be doable.... > > Another suggestion would be to reverse the IPv4 semantics for dotted > quad:service. For example, "3ffe:1ce1:0:b5::1.1019" might work. Since > there are no valid v4 addresses in the 0.0.0.x or 0.0.1.x blocks, we > wouldn't even have to worry about 32 bit v4 address representations. > Without at least one more '.', it's fairly obvious that the suffix isn't > an address component. > > From alimuddin.mohammad@boeing.com Wed Jan 12 19:54:53 2000 From: alimuddin.mohammad@boeing.com (Mohammad, Alimuddin) Date: Wed, 12 Jan 2000 11:54:53 -0800 Subject: Joining the 6bone Message-ID: Hi, The Boeing Bellevue campus in Seattle would like to get connected to the 6bone. What is the easiest/best way to do this?? Any help in this regard would be greatly appreciated. Also, would it be possible to access the 6bone, from behind a firewall??? Thanks. ---Alim From fink@es.net Wed Jan 12 21:25:51 2000 From: fink@es.net (Bob Fink) Date: Wed, 12 Jan 2000 13:25:51 -0800 Subject: Joining the 6bone In-Reply-To: Message-ID: <4.2.2.20000112132155.00ca4260@imap2.es.net> --=====================_167141344==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Alim, At 11:54 AM 1/12/00 -0800, Mohammad, Alimuddin wrote: >Hi, > >The Boeing Bellevue campus in Seattle would like to get connected to the >6bone. >What is the easiest/best way to do this?? Any help in this regard would >be greatly >appreciated. Besides reading all the writeups on the 6bone.net pages, you do need to find a 6bone pTLA/pNLA network that will host your site's connection. Anyway, please read the how to join the 6bone page at and get back in touch with me privately with any questions you may have. >Also, would it be possible to access the 6bone, from behind a firewall??? Yes, if your firewall manager doesn't mind you punching a virtual network hole through it for the IPv6 over IPv4 packets that will flow through it (presuming you are doing a tunnel and not a native connect). Bob --=====================_167141344==_.ALT Content-Type: text/html; charset="us-ascii" Alim,

At 11:54 AM 1/12/00 -0800, Mohammad, Alimuddin wrote:
Hi,

The Boeing Bellevue campus in Seattle would like to get connected to the 6bone.
What  is the easiest/best way to do this?? Any help in this regard would be greatly
appreciated.

Besides reading all the writeups on the 6bone.net pages, you do need to find a 6bone pTLA/pNLA network that will host your site's connection.

Anyway, please read the how to join the 6bone page at <http://www.6bone.net/6bone_hookup.html> and get back in touch with me privately with any questions you may have.


Also, would it be possible to access the 6bone, from behind a firewall???

Yes, if your firewall manager doesn't mind you punching a virtual network hole through it for the IPv6 over IPv4 packets that will flow through it (presuming you are doing a tunnel and not a native connect).


Bob
--=====================_167141344==_.ALT-- From sekiya@ISI.EDU Wed Jan 12 22:30:40 2000 From: sekiya@ISI.EDU (Yuji Sekiya) Date: Thu, 13 Jan 2000 07:30:40 +0900 Subject: Joining the 6bone In-Reply-To: In your message of "Wed, 12 Jan 2000 11:54:53 -0800" References: Message-ID: At Wed, 12 Jan 2000 11:54:53 -0800, Mohammad, Alimuddin wrote: Hello Alimuddin, > The Boeing Bellevue campus in Seattle would like to get connected to the 6bone. > What is the easiest/best way to do this?? Any help in this regard would be greatly > appreciated. Can we help you ? We can accept your tunnel request. > Also, would it be possible to access the 6bone, from behind a firewall??? You can access the 6bone if your firewall allows to pass IPv4 packets which protocol # are 41. Regards. -- Yuji Sekiya From pontus@lysator.liu.se Thu Jan 13 09:40:23 2000 From: pontus@lysator.liu.se (Pontus Lidman) Date: Thu, 13 Jan 2000 10:40:23 +0100 (MET) Subject: IPv6-enabled Linux (was: RE: Tunelling with Solaris 8 <-> Linux) In-Reply-To: <7D29C1B86A55D3119EF400A0C9E9597638EAAE@DELG001A> Message-ID: On Thu, 16 Dec 1999, Raizada Manoj wrote: > Hi all > > I am trying to get the Linux freeware with IPV6 implementation. Could > someone help me to get the source code with the installation guidelines. Debian GNU/Linux (http://www.debian.org) version 2.2 has IPv6-enabled network tools, and packages for IPv6-enabled web servers, mail servers, ssh etc. Regards, Pontus -- Pontus Lidman, pontus@mathcore.com, Software Engineer No matter how cynical you get, it's impossible to keep up. Scene: www.dc-s.com | MUD: tyme.envy.com 6969 | irc: irc.quakenet.eu.org From rene.mayrhofer@vianova.at Thu Jan 13 11:29:50 2000 From: rene.mayrhofer@vianova.at (Rene Mayrhofer) Date: Thu, 13 Jan 2000 11:29:50 +0000 Subject: IPv6 address/port format References: <200001120403.MAA23852@ns.6test.edu.cn> Message-ID: <387DB72E.EFFC451C@vianova.at> Haisang Wu wrote: > > How about this: > We still use / in the routing case and in the dir case. : and . should > still be used in IPv6 address format. But when we express port, we use [] > to include the IPv6 addresses or even domain name, other syntax kept the > same as now. > for instance, the following are expressed in tranditional ways: > www.ipv6.net ---> 3ffe:1ce1:xxx:xxxx:xxx:xxxx:xxxx:xxxx > 10.20.30.40 ---> (mapping IPv6) ::10.20.30.40 54.2 > ::ffff:10.20.30.40 > ::xxxx:xxxx > ::ffff:xxxx:xxxx > but for port 80 on www.ipv6.net, > use [www.ipv6.net]:80 > [3ffe:1ce1:xxx:xxxx:xxxx:xxxx:xxxx:xxxx]:80 > and for urls: http://[..v6 address..]:port/dir/dir..... Seems the best solution to me, as a very new user of IPv6. It is the closest solution compared to IPv4 Syntax. Rene Mayrhofer From maray@fsz.bme.hu Thu Jan 13 12:26:10 2000 From: maray@fsz.bme.hu (MARAY Tamas) Date: Thu, 13 Jan 2000 13:26:10 +0100 (MET) Subject: IPv6 address/port format In-Reply-To: from Edward Lewis at "Jan 11, 2000 03:42:14 pm" Message-ID: <200001131226.NAA25176@bagira.iit.bme.hu> > > How about this: > > We still use / in the routing case and in the dir case. : and . should > > still be used in IPv6 address format. But when we express port, we use [] > > to include the IPv6 addresses or even domain name, other syntax kept the > > same as now. > > for instance, the following are expressed in tranditional ways: > > www.ipv6.net ---> 3ffe:1ce1:xxx:xxxx:xxx:xxxx:xxxx:xxxx > > 10.20.30.40 ---> (mapping IPv6) ::10.20.30.40 54.2 > > ::ffff:10.20.30.40 > > ::xxxx:xxxx > > ::ffff:xxxx:xxxx > > but for port 80 on www.ipv6.net, > > use [www.ipv6.net]:80 > > [3ffe:1ce1:xxx:xxxx:xxxx:xxxx:xxxx:xxxx]:80 > > and for urls: http://[..v6 address..]:port/dir/dir..... > > Seems the best solution to me, as a very new user of IPv6. It is the > closest solution compared to IPv4 Syntax. Wrong. Conflicts with the UNIX shell. Tamas Maray From kaos@ocs.com.au Thu Jan 13 13:35:52 2000 From: kaos@ocs.com.au (Keith Owens) Date: Fri, 14 Jan 2000 00:35:52 +1100 Subject: IPv6 address/port format In-Reply-To: Your message of "Thu, 13 Jan 2000 13:26:10 BST." <200001131226.NAA25176@bagira.iit.bme.hu> Message-ID: <7073.947770552@ocs3.ocs-net> On Thu, 13 Jan 2000 13:26:10 +0100 (MET), MARAY Tamas wrote: >> > and for urls: http://[..v6 address..]:port/dir/dir..... >> >> Seems the best solution to me, as a very new user of IPv6. It is the >> closest solution compared to IPv4 Syntax. > >Wrong. Conflicts with the UNIX shell. Right, if you care about proposed standards. RFC 2732 says to use http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html If you disagree with RFC 2732, take it up with the Internet standards process. In any case, there are a lot of characters that conflict with the Unix shell, all of which are valid in the pathname section of a URL. '?' means "any character" to some shells, does that mean we forbid its use for CGI scripts? From maray@fsz.bme.hu Thu Jan 13 14:17:14 2000 From: maray@fsz.bme.hu (MARAY Tamas) Date: Thu, 13 Jan 2000 15:17:14 +0100 (MET) Subject: IPv6 address/port format In-Reply-To: <7073.947770552@ocs3.ocs-net> from Keith Owens at "Jan 14, 2000 00:35:52 am" Message-ID: <200001131417.PAA02415@bagira.iit.bme.hu> > >Wrong. Conflicts with the UNIX shell. > > Right, if you care about proposed standards. RFC 2732 says to use > > http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > > If you disagree with RFC 2732, take it up with the Internet standards > process. > > In any case, there are a lot of characters that conflict with the Unix > shell, all of which are valid in the pathname section of a URL. '?' > means "any character" to some shells, does that mean we forbid its use > for CGI scripts? Of course not. That is an unlucky case and we must live with it since we have no impact on it anymore. But why shouldn't we create a solution for IPv6 URL syntax which satisfies all the requirements if we are still in time and position? If we choose the syntax watchfully, such kind of conflicts can be avoided. Sincerely, Tamas Maray From sgunderson@bigfoot.com Thu Jan 13 18:15:36 2000 From: sgunderson@bigfoot.com (Steinar H. Gunderson) Date: Thu, 13 Jan 2000 18:15:36 +0000 Subject: IPv6 address/port format In-Reply-To: <200001131226.NAA25176@bagira.iit.bme.hu>; from maray@fsz.bme.hu on Thu, Jan 13, 2000 at 01:26:10PM +0100 References: <200001131226.NAA25176@bagira.iit.bme.hu> Message-ID: <20000113181536.A13498@uio.no> On Thu, Jan 13, 2000 at 01:26:10PM +0100, MARAY Tamas wrote: >Wrong. Conflicts with the UNIX shell. There are multiple UNIX shells, or at least multiple shells in use on UNIX (and UNIX-like) systems. I don't know if this conflicts with all of them, but I doubt it. Your argument is valid, but no matter which standard we choose, we will run into conflicts. We'll just have to find out how to minimize those conflicts. /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/ From rene.mayrhofer@vianova.at Thu Jan 13 19:07:56 2000 From: rene.mayrhofer@vianova.at (Rene Mayrhofer) Date: Thu, 13 Jan 2000 19:07:56 +0000 Subject: IPv6 address/port format References: <200001131417.PAA02415@bagira.iit.bme.hu> Message-ID: <387E228C.1F2CB906@vianova.at> MARAY Tamas wrote: > > > >Wrong. Conflicts with the UNIX shell. > > > > Right, if you care about proposed standards. RFC 2732 says to use > > > > http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html > > > > If you disagree with RFC 2732, take it up with the Internet standards > > process. > > > > In any case, there are a lot of characters that conflict with the Unix > > shell, all of which are valid in the pathname section of a URL. '?' > > means "any character" to some shells, does that mean we forbid its use > > for CGI scripts? > > Of course not. That is an unlucky case and we must live with it > since we have no impact on it anymore. But why shouldn't we create a > solution for IPv6 URL syntax which satisfies all the requirements > if we are still in time and position? If we choose the syntax watchfully, > such kind of conflicts can be avoided. But I think that there is another point that has to be taken into account: Users must live with the solution. When we want a smooth upgrade from IPv4 to IPv6 (OK, as smooth as it can be anyway), then the change on the user interface should be minimized. Remember, the majority of people using the Internet does not care about IP, they only use their tools like Web-browsers or email-clients. I think it is very important for the acceptance of IPv6 that users should not notice the change at all. With URLs, there would only be a very small change if the above format would be used. But you are completely right: There is a problem with UNIX shells that can be solved easier when we think about it now. Is there an easy way to cope with it without changing the format for URLs ? Can the "[" and "]" simply be escaped in the shells ? This should be possible when the tools are aware of it. cheers, Rene Mayrhofer From nathan@rtfm.net Thu Jan 13 21:44:09 2000 From: nathan@rtfm.net (Nathan Dorfman) Date: Thu, 13 Jan 2000 16:44:09 -0500 Subject: IPv6 address/port format In-Reply-To: <20000113181536.A13498@uio.no>; from Steinar H. Gunderson on Thu, Jan 13, 2000 at 06:15:36PM +0000 References: <200001131226.NAA25176@bagira.iit.bme.hu> <20000113181536.A13498@uio.no> Message-ID: <20000113164408.B73420@rtfm.net> On Thu, Jan 13, 2000 at 06:15:36PM +0000, Steinar H. Gunderson wrote: > On Thu, Jan 13, 2000 at 01:26:10PM +0100, MARAY Tamas wrote: > >Wrong. Conflicts with the UNIX shell. > > There are multiple UNIX shells, or at least multiple shells in > use on UNIX (and UNIX-like) systems. I don't know if this conflicts > with all of them, but I doubt it. Your argument is valid, but no > matter which standard we choose, we will run into conflicts. We'll > just have to find out how to minimize those conflicts. [ and ] are metacharacters in the POSIX-specified standard Unix shell; as well as bash, bash2, ksh, csh, tcsh and zsh. Since this list comprises something like 99% of all Unix shells used, characters marked as reserved by *all* of them are a really bad choice. > /* Steinar */ > -- > Homepage: http://members.xoom.com/sneeze/ -- Nathan Dorfman The statements and opinions in my Unix Admin @ Frontline Communications public posts are mine, not FCC's. "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune From nathan@rtfm.net Thu Jan 13 21:59:11 2000 From: nathan@rtfm.net (Nathan Dorfman) Date: Thu, 13 Jan 2000 16:59:11 -0500 Subject: IPv6 address/port format In-Reply-To: <387E228C.1F2CB906@vianova.at>; from Rene Mayrhofer on Thu, Jan 13, 2000 at 07:07:56PM +0000 References: <200001131417.PAA02415@bagira.iit.bme.hu> <387E228C.1F2CB906@vianova.at> Message-ID: <20000113165910.A74363@rtfm.net> On Thu, Jan 13, 2000 at 07:07:56PM +0000, Rene Mayrhofer wrote: > > Of course not. That is an unlucky case and we must live with it > > since we have no impact on it anymore. But why shouldn't we create a > > solution for IPv6 URL syntax which satisfies all the requirements > > if we are still in time and position? If we choose the syntax watchfully, > > such kind of conflicts can be avoided. > > But I think that there is another point that has to be taken into > account: Users must live with the solution. When we want a smooth > upgrade from IPv4 to IPv6 (OK, as smooth as it can be anyway), then the > change on the user interface should be minimized. > Remember, the majority of people using the Internet does not care about > IP, they only use their tools like Web-browsers or email-clients. > > I think it is very important for the acceptance of IPv6 that users > should not notice the change at all. With URLs, there would only be a > very small change if the above format would be used. > > But you are completely right: There is a problem with UNIX shells that > can be solved easier when we think about it now. Is there an easy way to > cope with it without changing the format for URLs ? Can the "[" and "]" > simply be escaped in the shells ? This should be possible when the tools > are aware of it. % netscape http://[aa:bb:cc:dd:ee:ff:gg:hh]:8080/blah No match. % damn! damn!: Command not found. % logout > cheers, > Rene Mayrhofer -- Nathan Dorfman The statements and opinions in my Unix Admin @ Frontline Communications public posts are mine, not FCC's. "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune From kaos@ocs.com.au Fri Jan 14 00:23:17 2000 From: kaos@ocs.com.au (Keith Owens) Date: Fri, 14 Jan 2000 11:23:17 +1100 Subject: IPv6 address/port format In-Reply-To: Your message of "Thu, 13 Jan 2000 16:59:11 CDT." <20000113165910.A74363@rtfm.net> Message-ID: <16528.947809397@ocs3.ocs-net> On Thu, 13 Jan 2000 16:59:11 -0500, Nathan Dorfman wrote: >% netscape http://[aa:bb:cc:dd:ee:ff:gg:hh]:8080/blah >No match. netscape 'http://[aa:bb:cc:dd:ee:ff:gg:hh]:8080/blah' Standard shell rules for escaping characters. Trying to restrict meta characters in a URL to make the URL "shell compatible" is a waste of time. The pathname can contain *any* character that the target site wants to use, including meta characters and spaces and you have no control over the pathname. To view "filename with spaces.html", you *must* enter the URL in the shell as netscape 'http://www.site.name/filename with spaces.html' The string must be quoted when the pathname contains special characters, what is so different about quoting it when the hostname contains special characters? This problem already occurs, there are lots of filenames on the web with spaces in them. From rali@meitca.com Fri Jan 14 00:54:34 2000 From: rali@meitca.com (Reto Lichtensteiger) Date: Thu, 13 Jan 2000 19:54:34 -0500 (EST) Subject: IPv6 address/port format In-Reply-To: <20000113165910.A74363@rtfm.net> from Nathan Dorfman at "Jan 13, 2000 04:59:11 pm" Message-ID: <200001140054.TAA08247@fnord.meitca.com> Nathan Dorfman wrote: <> % netscape http://[aa:bb:cc:dd:ee:ff:gg:hh]:8080/blah <> No match. <> % damn! <> damn!: Command not found. <> % logout True, but ... % lynx http:\[aa:bb:cc:dd:ee:ff:gg:hh\]:8080/blah Looking up 'http:[aa:bb:cc:dd:ee:ff:gg:hh]' first. . . . NOT that I think this is a good idea, mind ... R -- R A Lichtensteiger rali@meitca.com -or- rali@world.std.com http://www.meitca.com/ITA/People/rali "Yes, you're doing things right, but are you doing the right things?" "Nope. I'm just doing something dumb fast." From stephenb@uk.uu.net Fri Jan 14 00:43:45 2000 From: stephenb@uk.uu.net (Stephen Burley) Date: Fri, 14 Jan 2000 00:43:45 +0000 (GMT) Subject: IPv6 address/port format In-Reply-To: <20000113181536.A13498@uio.no> Message-ID: What is wrong with using > as a direction to a port symbol. We are making far too much of this. White space will do it always has up till now. ---------------------------------- E-Mail: stephenb@uk.uu.net Phone: +44 (0)1223 581051 Stephen Burley EMEA Registrar UUNET ---------------------------------- On Thu, 13 Jan 2000, Steinar H. Gunderson wrote: > On Thu, Jan 13, 2000 at 01:26:10PM +0100, MARAY Tamas wrote: > >Wrong. Conflicts with the UNIX shell. > > There are multiple UNIX shells, or at least multiple shells in > use on UNIX (and UNIX-like) systems. I don't know if this conflicts > with all of them, but I doubt it. Your argument is valid, but no > matter which standard we choose, we will run into conflicts. We'll > just have to find out how to minimize those conflicts. > > /* Steinar */ > -- > Homepage: http://members.xoom.com/sneeze/ > From dancer@zeor.simegen.com Fri Jan 14 01:51:44 2000 From: dancer@zeor.simegen.com (Dancer) Date: Fri, 14 Jan 2000 01:51:44 +0000 Subject: IPv6 address/port format References: <200001131226.NAA25176@bagira.iit.bme.hu> <20000113181536.A13498@uio.no> <20000113164408.B73420@rtfm.net> Message-ID: <387E8130.1C9B7B3F@zeor.simegen.com> Nathan Dorfman wrote: > On Thu, Jan 13, 2000 at 06:15:36PM +0000, Steinar H. Gunderson wrote: > > On Thu, Jan 13, 2000 at 01:26:10PM +0100, MARAY Tamas wrote: > > >Wrong. Conflicts with the UNIX shell. > > > > There are multiple UNIX shells, or at least multiple shells in > > use on UNIX (and UNIX-like) systems. I don't know if this conflicts > > with all of them, but I doubt it. Your argument is valid, but no > > matter which standard we choose, we will run into conflicts. We'll > > just have to find out how to minimize those conflicts. > > [ and ] are metacharacters in the POSIX-specified standard Unix shell; > as well as bash, bash2, ksh, csh, tcsh and zsh. Since this list > comprises something like 99% of all Unix shells used, characters > marked as reserved by *all* of them are a really bad choice. Many characters defined as acceptable in URL's are in some way magic or special to shells. Examples include, but are not limited to: ; ? * ' & That means that when feeding some URL's to tools (like wget) you already have to escape them (with \ or by wrapping them in quotes). Realistically, I don't think entering a URI at shell level with an embedded numeric V6 address is going to be all that common. Nor, do I think that it comprises any more or less care with character escapes than existing URL grammar already requires. D From aljaz@iskratel.si Fri Jan 14 12:37:58 2000 From: aljaz@iskratel.si (Aljaz Tomaz RDSI) Date: Fri, 14 Jan 2000 13:37:58 +0100 Subject: NAT Message-ID: <7E8519F1A7C0D211B0D200A0C93AA60F3D29C3@NTMAIL> Hi all! I know that this topic is not directly associated with IPv6 but I would like to find some information about NAT implementation. NAT has to chage every source/destination IP address and source port every packet outside NAT domain (whole inside network is maped to one legal IP address). For all TCP/UDP communication I found no problem doing that. What about PING (echo request/reply) - ICMP packets. There is no UDP/TCP port. How NAT works in that situation and distinguish packets? Regards, Tomaz From burgess@mitre.org Fri Jan 14 14:45:10 2000 From: burgess@mitre.org (David Burgess) Date: Fri, 14 Jan 2000 08:45:10 -0600 Subject: IPv6 address/port format References: <200001101530.PAA12945@orchard.arlington.ma.us> <387B50A2.17E67EE7@mitre.org> <20000111211504.A10106@alcove.wittsend.com> Message-ID: <387F3676.5E58E228@mitre.org> "Michael H. Warfield" wrote: > > On Tue, Jan 11, 2000 at 09:47:46AM -0600, David Burgess wrote: > > > Bill Sommerfeld wrote: > > > > > "Dwayne C . Litzenberger" said: > > > > > I'm not really knowledgeable about this, but what is a good, standard way > > > > > to show address/port shown in IPv4, IPv6, IPX, etc? I would think > > > > > address.:port (dot-colon) would be good (and it already works with domain > > > > > names), but I haven't seen this done yet. > > > > > > > > > Any thoughts? > > > > > I've seen people use both "IPv6-addr port" (space sep.) and > > > > "IPv6-addr/port". I think I really like using '/', and haven't yet > > > > found a place where that will cause problems except for in URIs. > > > > It's too easily confused with network prefixes.. (IPv6-addr/prefixlen). > > > > How am I supposed to know whether 3ffe:1ce1:0:b5::1/64 should be > > > parsed as an pair or as a network prefix? > > > The obvious answer is, of course, by context. If I were to tell you to > > connect to 3ffe:1ce1:0:b5::1/64, then you would connect to service 64. > > If I was talking about routing issues, then the 64 would be the prefix > > length. > > Bzzzt... Wrong answer... > > Firewall rule: > > Deny access to 3ffe:1ce1:0:b5::1/96 > > Are you saying to restrict the rule to port 96 on that host or are > you saying restrict the rule to any port on the /96 subnet. It's ambigous > to attempt to parse it without knowledge of the data contents you are > attempting to parse and THAT'S unacceptable as a consequence. > > Overloading the '/' is going to be ambiguous in some contexts and > I see no way to avoid that. > > [...] > In the elided section, I bring up a different 'bad case', so I'd say I agree here. The more we think about it, the more it gets strange. The RFC based suggestion (putting the address in square brackets) seems to be the least egregious of the choices I've seen so far. BTW: The NetBSD firewall system uses a separate port directive from the address component of the address, which would dis-ambiguate the event. Using the /nn directive there (in that particular implementation) would still allow for the contextual clues required.... IN SPITE OF THAT I agree that overloading the '/' is genuinely a bad idea. The only two workable solutions that I would consider are to actually adopt the RFC based solution or to do like I suggested before and switch the v4 to v6 semantics for ':' and '.' From perry@piermont.com Fri Jan 14 17:02:51 2000 From: perry@piermont.com (Perry E. Metzger) Date: 14 Jan 2000 12:02:51 -0500 Subject: IPv6 address/port format In-Reply-To: Nathan Dorfman's message of "Thu, 13 Jan 2000 16:44:09 -0500" References: <200001131226.NAA25176@bagira.iit.bme.hu> <20000113181536.A13498@uio.no> <20000113164408.B73420@rtfm.net> Message-ID: <87r9fkoabo.fsf@snark.piermont.com> Nathan Dorfman writes: > [ and ] are metacharacters in the POSIX-specified standard Unix shell; > as well as bash, bash2, ksh, csh, tcsh and zsh. Since this list > comprises something like 99% of all Unix shells used, characters > marked as reserved by *all* of them are a really bad choice. Who the hell cares? No one is going to enter in address literals except in extreme circumstances anyway. They're a mile long. .pm From nathan@rtfm.net Fri Jan 14 17:34:27 2000 From: nathan@rtfm.net (Nathan Dorfman) Date: Fri, 14 Jan 2000 12:34:27 -0500 Subject: IPv6 address/port format In-Reply-To: <87r9fkoabo.fsf@snark.piermont.com>; from Perry E. Metzger on Fri, Jan 14, 2000 at 12:02:51PM -0500 References: <200001131226.NAA25176@bagira.iit.bme.hu> <20000113181536.A13498@uio.no> <20000113164408.B73420@rtfm.net> <87r9fkoabo.fsf@snark.piermont.com> Message-ID: <20000114123427.A18012@rtfm.net> On Fri, Jan 14, 2000 at 12:02:51PM -0500, Perry E. Metzger wrote: > > Nathan Dorfman writes: > > [ and ] are metacharacters in the POSIX-specified standard Unix shell; > > as well as bash, bash2, ksh, csh, tcsh and zsh. Since this list > > comprises something like 99% of all Unix shells used, characters > > marked as reserved by *all* of them are a really bad choice. > > Who the hell cares? No one is going to enter in address literals > except in extreme circumstances anyway. They're a mile long. Bull. Network administrators will still have to deal with addresses. They'd probably also prefer to be able to do this from the Unix shell without a menagerie of backslashes and single quotes. > .pm -- Nathan Dorfman The statements and opinions in my Unix Admin @ Frontline Communications public posts are mine, not FCC's. "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune From perry@piermont.com Fri Jan 14 18:23:26 2000 From: perry@piermont.com (Perry E. Metzger) Date: 14 Jan 2000 13:23:26 -0500 Subject: IPv6 address/port format In-Reply-To: Nathan Dorfman's message of "Fri, 14 Jan 2000 12:34:27 -0500" References: <200001131226.NAA25176@bagira.iit.bme.hu> <20000113181536.A13498@uio.no> <20000113164408.B73420@rtfm.net> <87r9fkoabo.fsf@snark.piermont.com> <20000114123427.A18012@rtfm.net> Message-ID: <87embko6ld.fsf@snark.piermont.com> Nathan Dorfman writes: > On Fri, Jan 14, 2000 at 12:02:51PM -0500, Perry E. Metzger wrote: > > > > Nathan Dorfman writes: > > > [ and ] are metacharacters in the POSIX-specified standard Unix shell; > > > as well as bash, bash2, ksh, csh, tcsh and zsh. Since this list > > > comprises something like 99% of all Unix shells used, characters > > > marked as reserved by *all* of them are a really bad choice. > > > > Who the hell cares? No one is going to enter in address literals > > except in extreme circumstances anyway. They're a mile long. > > Bull. Network administrators will still have to deal with addresses. I've run networks for years and I can't remember myself typing in a URL with an address in it as part of a job. I can remember typing in addresses lots of other times, of course, but not for that. > They'd probably also prefer to be able to do this from the Unix shell > without a menagerie of backslashes and single quotes. Really, who cares. Two single quotes are going to kill people on the rare occassion it shows up? I don't think so. And if it will kill people, this isn't the forum. You could have argued about this in the IETF working group a long time ago (and I assure you it WAS argued about.) Perry From bmanning@ISI.EDU Fri Jan 14 19:04:46 2000 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 14 Jan 2000 11:04:46 -0800 (PST) Subject: IPv6 address/port format In-Reply-To: <87r9fkoabo.fsf@snark.piermont.com> from "Perry E. Metzger" at Jan 14, 2000 12:02:51 PM Message-ID: <200001141904.LAA15707@zed.isi.edu> % Nathan Dorfman writes: % > [ and ] are metacharacters in the POSIX-specified standard Unix shell; % > as well as bash, bash2, ksh, csh, tcsh and zsh. Since this list % > comprises something like 99% of all Unix shells used, characters % > marked as reserved by *all* of them are a really bad choice. % % Who the hell cares? No one is going to enter in address literals % except in extreme circumstances anyway. They're a mile long. % % .pm Well, I care, esp. when rebooting the Internet. :) --bill From richdr@microsoft.com Fri Jan 14 19:05:00 2000 From: richdr@microsoft.com (Richard Draves) Date: Fri, 14 Jan 2000 11:05:00 -0800 Subject: MSR IPv6 Release 1.4 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA219B0@RED-MSG-50> Microsoft Research is please to announce Release 1.4 of our MSR IPv6 stack for Windows NT 4.0 and Windows 2000. See http://www.research.microsoft.com/msripv6 for more details and download information. The release includes freely-available source code as well as precompiled binaries. Major new functionality for this release includes scoped address support in the API and the stack, Plug'n'Play and Power Management on Windows 2000, and automated 6to4 configuration. The scoped address support includes sin6_scope_id, getaddrinfo/getnameinfo, and related changes and APIs. We support site-local addressing with site prefixes (Nordmark's draft) and multi-sited nodes. For literal addresses with scope ids, we use the format "scope-id/address". On Windows 2000, USB and PCMCIA network interfaces can now be added to or removed from the system on the fly and the stack will reconfigure itself accordingly. Similarly, one can disconnect and reconnect network links or hibernate and resume a system and the MSR IPv6 stack will do the right thing. It is possible to dynamically unload and reload the stack without rebooting. The new 6to4cfg program automates 6to4 configuration. The 6to4 transition technique lets IPv6 sites communicate transparently over the IPv4 internet backbone. 6to4cfg makes it very easy to setup a 6to4 gateway router and connect sites to the 6bone via 6to4. See our 6to4 documentation: http://www.research.microsoft.com/msripv6/docs/6to4.htm. And of course, there are many miscellaneous enhancements and fixes. Thanks, Rich From mhw@wittsend.com Fri Jan 14 19:44:41 2000 From: mhw@wittsend.com (Michael H. Warfield) Date: Fri, 14 Jan 2000 14:44:41 -0500 Subject: IPv6 address/port format In-Reply-To: <20000114123427.A18012@rtfm.net>; from nathan@rtfm.net on Fri, Jan 14, 2000 at 12:34:27PM -0500 References: <200001131226.NAA25176@bagira.iit.bme.hu> <20000113181536.A13498@uio.no> <20000113164408.B73420@rtfm.net> <87r9fkoabo.fsf@snark.piermont.com> <20000114123427.A18012@rtfm.net> Message-ID: <20000114144441.B1942@alcove.wittsend.com> On Fri, Jan 14, 2000 at 12:34:27PM -0500, Nathan Dorfman wrote: > On Fri, Jan 14, 2000 at 12:02:51PM -0500, Perry E. Metzger wrote: > > Nathan Dorfman writes: > > > [ and ] are metacharacters in the POSIX-specified standard Unix shell; > > > as well as bash, bash2, ksh, csh, tcsh and zsh. Since this list > > > comprises something like 99% of all Unix shells used, characters > > > marked as reserved by *all* of them are a really bad choice. > > Who the hell cares? No one is going to enter in address literals > > except in extreme circumstances anyway. They're a mile long. > Bull. Network administrators will still have to deal with addresses. > They'd probably also prefer to be able to do this from the Unix shell > without a menagerie of backslashes and single quotes. Bull... Network administrators are ALREADY use to escaping known and various metacharacters all the way back to "bang paths" in E-Mail addresses under csh (bash wasn't around back in those days and sh didn't have ! history) and for UUCP. [Yes, I'm that $$#@ old that I remember and actually used some of that stuff...] It's gotten so it's second nature to either single quote or escape anything with anything even resembling a meta character in it no matter which shell I'm using. That being said, there is the potential for one very real gotcha with this scheme... If one of the URL's gets fed to a perl script, there is the potential for trouble. Why? Because many of the perl scripts are now (hopefully) being coded to watch out for and prohibit certain meta characters because several of them have been used to open security holes. I don't see where [] is likely to open up a security hole but processing in a regex could get "amusing". :-) This actually goes beyond perl, since a lot of apps are scanning for meta characters and other script-kiddie amusements, but perl CGI scripts seem to be the most likely to get burnt. Even sendmail got broken into several times through meta characters tricks, though I don't see this being a problem with sendmail (the port issue that is). This is also much more likely to come up than someone entering in a raw address URL on a command line. > > .pm > -- > Nathan Dorfman The statements and opinions in my > Unix Admin @ Frontline Communications public posts are mine, not FCC's. > "The light at the end of the tunnel is the headlight of an approaching > train." --/usr/games/fortune Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From xidus@xidus.net Fri Jan 14 20:25:53 2000 From: xidus@xidus.net (Jeremy Weatherford) Date: Fri, 14 Jan 2000 12:25:53 -0800 (PST) Subject: IPv6 address/port format In-Reply-To: Message-ID: Using '>' anywhere would be a really bad choice, since it's both a shell redirection character AND an HTML metacharacter. Try making a hyperlink to a URL with a '>' in the address... The best option so far seems to be: http://[aa.bb.cc.dd.ee.ff.gg.hh]:8080/url I don't think this will worsen the problem that already exists with shell metacharacters being present in URLs. Jeremy Weatherford xidus@xidus.net http://xidus.net/ On Fri, 14 Jan 2000, Stephen Burley wrote: > What is wrong with using > as a direction to a port symbol. We are making > far too much of this. White space will do it always has up till now. > > ---------------------------------- > E-Mail: stephenb@uk.uu.net > Phone: +44 (0)1223 581051 > > > Stephen Burley > EMEA Registrar UUNET > ---------------------------------- > > On Thu, 13 Jan 2000, Steinar H. Gunderson wrote: > > > On Thu, Jan 13, 2000 at 01:26:10PM +0100, MARAY Tamas wrote: > > >Wrong. Conflicts with the UNIX shell. > > > > There are multiple UNIX shells, or at least multiple shells in > > use on UNIX (and UNIX-like) systems. I don't know if this conflicts > > with all of them, but I doubt it. Your argument is valid, but no > > matter which standard we choose, we will run into conflicts. We'll > > just have to find out how to minimize those conflicts. > > > > /* Steinar */ > > -- > > Homepage: http://members.xoom.com/sneeze/ > > > From wojboj@lp.net.pl Fri Jan 14 22:44:56 2000 From: wojboj@lp.net.pl (Wojtek Bojdo/l) Date: Fri, 14 Jan 2000 23:44:56 +0100 (CET) Subject: IPv6 address/port format In-Reply-To: <87embko6ld.fsf@snark.piermont.com> Message-ID: On 14 Jan 2000, Perry E. Metzger wrote: > > Bull. Network administrators will still have to deal with addresses. > > I've run networks for years and I can't remember myself typing in a > URL with an address in it as part of a job. I can remember typing in > addresses lots of other times, of course, but not for that. We should think when [ ] should be used.. In telnet we give port after space.. In ftp we often use ncftp and type port in parameter.. I see problems only with lynx and wget... ------------------------------------------------------------- = Wojciech Bojdo/l wojboj@lp.net.pl www.lp.net.pl/~wojboj = [ Nie ma rzeczy niemozliwych - sa tylko nieprawdopodobne ] ------------------------------------------------------------- From fink@es.net Sun Jan 16 01:07:04 2000 From: fink@es.net (Bob Fink) Date: Sat, 15 Jan 2000 17:07:04 -0800 Subject: 6BONE Pre-Qualification for Address Prefix Allocation (6PAPA) Message-ID: <4.2.2.20000115170624.00c06910@imap2.es.net> INTERNET-DRAFT Bob Fink, ESnet January 10, 2000 6BONE Pre-Qualification for Address Prefix Allocation (6PAPA) Abstract This memo describes how the 6bone may be used as a prequalification step during the "bootstrap" phase of sub-TLA assignment by the Regional Internet Registries (RIRs). Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires July 10, 2000. Acknowledgements Ideas in this draft are, in part, contributions of various IETF working groups, the Regional Internet Registries, participants of the 6bone testbed, and the worldwide IPv6 community. Contents Status of this Memo.......................................... Acknowledgements............................................. 1. Introduction............................................. 2. 6BONE Prequalification for sub-TLAs...................... 3. Security Considerations.................................. 4. Change Log............................................... REFERENCES................................................... AUTHOR'S ADDRESS............................................. 1. Introduction This memo describes how the 6bone is used as a prequalification step during the "bootstrap" phase of sub-TLA assignment by the Regional Internet Registries (RIRs). It is based on the following points. 1.1 The 6bone community represented the world-wide IPv6 operational networking community as of early 1999, including all existing IPv6 providers and users in the world, operating under the only IPv6 address allocation and authority in place at that time, i.e., the 3FFE::/16 TLA allocation to the 6bone, documented in [6BONE-TLA]. 1.2 The 6bone uses a well defined top level address structure called a pseudo-TLA (pTLA), documented in [PSEUDO], that is delegated from its 3FFE::/16 allocation, that all top level 6BONE IPv6 transit providers use. 1.3 The 6bone process for allocation of pTLA-s is well defined in section 7 of [HARDEN] and is well accepted by the 6bone community. 1.4 The 6bone community as a whole is willing to provide their knowledge, experience and opinions as part of a process to help "bootstrap" the sub- TLA address allocation process for the RIRs. 2. 6BONE Prequalification for sub-TLAs 2.1 A sub-TLA requestor (sTR) places a sub-TLA request with the appropriate RIR, per the RIR's own sub-TLA procedures, indicating that they intend to use 6bone prequalification. 2.2 The sTR follows the published process for becoming a pTLA as documented in Section 7 of [HARDEN]. (Note that [HARDEN] specifies the minimum time from first joining the 6bone as an end-site network to becoming a pTLA as 3 months.) Those pTLA allocations in effect prior to [HARDEN], or its predecessor RFC2546, are considered to have met all requirements for becoming a pTLA. However, 2.3 still applies. 2.3 An sTR must have operated as a pTLA for at least 3 months, with at least 3 active delegations under its pTLA (either lower level transits or end-sites, or a mix of both), for the sTR to meet the 6bone experience criterion (6EC). 2.4 A 6bone steering group (6SG), consisting of 3-5 persons established by 6bone participant consensus, uses factual operational information and other relevant experience of the sTR to determine if the 6EC has been met. It is expected that the 6SG will respond within 30 days. It is up to the RIR's own policies and procedures to determine what happens if this time is not met. 2.5 After allocation of a sub-TLA to the sTR (by an RIR), the sTR may optionally renumber from the 6bone pTLA prefix to the new sub-TLA prefix, or continue to use their pTLA for multihoming purposes. If the pTLA space becomes over subscribed, the most likely networks to be asked to surrender a pTLA would be those holding production TLA/sub-TLA prefix space. Given the large size of the pTLA space this is not considered likely to ever happen. 3. Security Considerations There are no security considerations of this document as it only specifies a process of recommendations made to IPv6 Address Registries for prequalification for production IPv6 Address Prefix allocations. 4. Change Log Changes since version -00 of the draft: Various rewordings for clarity. Replace [RFC 2546] references with new HARDEN specification now approved as Informational RFC. Notes that pTLAs prior to [HARDEN] and RFC 2546 are legitimate pTLAs, though still 3 months of oeprating experience with at leasts 3 delegations. Removal of the previous 2.2 requirement that the sTR notifies the 6bone list of intent to use the 6PP. In previous 2.4 (now 2.3) clarifies that it is 6bone experience criteria that is being met by the sTR for operating for 3 months. The new 2.4 specifies a 6SG maximum response interval of 30 days, with the RIR being responsible for deciding what to do when this time is exceeded. Removal of any mention or implication that the 6bone community us stating that an sTR is qualified for a sub-TLA allocation. Removal of previous 2.6 regarding time out issues. Removal of section 3. Only meaningful removal was regarding some pTLA-s not qualifying for this process due to the nature of there network. This had been regarded as unfair and unreasonable and there was general agreement to remove this. REFERENCES [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6BONE-TLA] R. Hinden, R. Fink, J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998. [PSEUDO] R. Fink, "6bone pTLA & pNLA Formats", see , January, 2000. [HARDEN] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines", RFC xxxx, December 1999. Replaces RFC 2546. AUTHOR'S ADDRESS Bob Fink, ESnet Lawrence Berkeley National Lab MS 50A-3111 1 Cyclotron Road Berkeley, CA 94720 USA phone: +1 510 486 5692 fax: +1 510 486 4790 email: fink@es.net -end From kre@munnari.OZ.AU Sun Jan 16 08:57:13 2000 From: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 16 Jan 2000 19:57:13 +1100 Subject: IPv6 address/port format In-Reply-To: Your message of "Fri, 14 Jan 2000 12:34:27 CDT." <20000114123427.A18012@rtfm.net> Message-ID: <20286.948013033@munnari.OZ.AU> Date: Fri, 14 Jan 2000 12:34:27 -0500 From: Nathan Dorfman Message-ID: <20000114123427.A18012@rtfm.net> | Bull. Network administrators will still have to deal with addresses. | They'd probably also prefer to be able to do this from the Unix shell | without a menagerie of backslashes and single quotes. It is hard to believe that this ridiculous topic has come up again. Address literals in IPv6 ought to be forbidden everywhere, except for those applications which are configuring IPv6 addresses to interfaces (and as that is generally done automatically, or by DHCP, that really means for most cases, only in DHCP config files). A much better solution for all other uses (all these network managers who just have to use literal addresses) is to have the name to address library routines (the things that call the resolver) have an "override" switch (via an environment variable) that will allow the user to create a file of domain name lookalikes, and associated IP addresses (perhaps only in some locally defined bogus domain - or perhaps only with no dots in the names at all), after which the library simply searches the file for the name, and substitutes the address. Then when someone who for some exotic reason really does need to use a literal address, they just add it to their file, with some shortname label as the domain name, then just use the label in the URL (or any other place where a domain name would work, but for whatever bizarre reason can't work). This is easier for the user faced with using a literal address (no strange syntax, no weird quoting, and the address only needs to be typed once, no matter how many times it has to be referenced) - and much better for applications and systems, which no longer need to deal with this odd special case which is almost neevr going to be used. A side effect is that there's no way to embed a literal address in a web page (or whatever) as there would be no way to get the literal out into the user's file (other than requesting that it be typed in) - this is a feature! kre From hansolofalcon@worldnet.att.net Sun Jan 16 18:27:47 2000 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Sun, 16 Jan 2000 13:27:47 -0500 Subject: Linux and IPv6 Message-ID: <01BF6025.7E46F860.hansolofalcon@worldnet.att.net> Hello from Gregg C Levine Just out of curiosity, does anybody, have an early kernel running IPv6? Most of the ones for Slackware that I have seen with it, are version 2.0.32 and later. The current version of Slackware, is 7.0, if anybody is curious, and they are running Redhat, or Debian, or heck, they made it themselves, out of everybody else's software. Gregg C Levine mailto:hansolofalcon@worldnet.att.net "They were in the wrong place, at the wrong time, naturally they became heroes." Princess Leia Organna of Alderann, Senator "Remember, the Force will be with you." Obi-Wan(Ben) Kenobi, Jedi Knight and, General, (Retired) "No! Try not. Do... or do not. There is no try." - Yoda, Jedi Master "May the Force be with you." Anonymous From hansolofalcon@worldnet.att.net Mon Jan 17 01:09:58 2000 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Sun, 16 Jan 2000 20:09:58 -0500 Subject: Linux and IPv6 Message-ID: <01BF605D.AC916CE0.hansolofalcon@worldnet.att.net> Hello again from Gregg C Levine usually at Jedi Knight Computers I think I mis-stated myself. What I wanted to say, is this: What is the earliest kernel that would support IPv6 functions? Then the rest of it, still applies. Gregg C Levine mailto:hansolofalcon@worldnet.att.net "They were in the wrong place, at the wrong time, naturally they became heroes." Princess Leia Organna of Alderann, Senator "Remember, the Force will be with you." Obi-Wan(Ben) Kenobi, Jedi Knight and, General, (Retired) "No! Try not. Do... or do not. There is no try." - Yoda, Jedi Master "May the Force be with you." Anonymous On Sunday, January 16, 2000 1:28 PM, Gregg C Levine [SMTP:hansolofalcon@worldnet.att.net] wrote: > Hello from Gregg C Levine > Just out of curiosity, does anybody, have an early kernel running IPv6? > Most of the ones for Slackware that I have seen with it, are version 2.0.32 > and later. The current version of Slackware, is 7.0, if anybody is curious, > and they are running Redhat, or Debian, or heck, they made it themselves, > out of everybody else's software. > Gregg C Levine mailto:hansolofalcon@worldnet.att.net > "They were in the wrong place, at the wrong time, naturally they became > heroes." > Princess Leia Organna of Alderann, Senator > "Remember, the Force will be with you." > Obi-Wan(Ben) Kenobi, Jedi Knight and, General, (Retired) > "No! Try not. Do... or do not. There is no try." - Yoda, Jedi Master > "May the Force be with you." Anonymous From kuznet@ms2.inr.ac.ru Mon Jan 17 16:06:26 2000 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Mon, 17 Jan 2000 19:06:26 +0300 (MSK) Subject: Linux and IPv6 In-Reply-To: <01BF605D.AC916CE0.hansolofalcon@worldnet.att.net> from "Gregg C Levine" at Jan 16, 0 08:09:58 pm Message-ID: <200001171606.TAA06351@ms2.inr.ac.ru> Hello! > I think I mis-stated myself. What I wanted to say, is this: What is the > earliest kernel that would support IPv6 functions? linux-2.1.8 Alexey Kuznetsov From stephenb@uk.uu.net Mon Jan 17 15:56:43 2000 From: stephenb@uk.uu.net (stephenb@uk.uu.net) Date: Mon, 17 Jan 2000 15:56:43 +0000 (GMT) Subject: IPv6 address/port format Message-ID: <200001171611.IAA01066@tnt.isi.edu> Hi Ok so we have been round and round on this subject but no one seems to have suggested the obvious. We are using x.x.x.x:nn for ipv4 why not use x:x:x:x.nn for ipv6. I will now don my fire proof vest. Regards, -- ---------------------------------- E-Mail: stephenb@uk.uu.net Phone: +44 (0)1223 581051 Stephen Burley EMEA Registrar UUNET ---------------------------------- From mhw@wittsend.com Mon Jan 17 18:10:45 2000 From: mhw@wittsend.com (Michael H. Warfield) Date: Mon, 17 Jan 2000 13:10:45 -0500 Subject: IPv6 address/port format In-Reply-To: <200001171611.IAA01066@tnt.isi.edu>; from stephenb@uk.uu.net on Mon, Jan 17, 2000 at 03:56:43PM +0000 References: <200001171611.IAA01066@tnt.isi.edu> Message-ID: <20000117131045.C18519@alcove.wittsend.com> On Mon, Jan 17, 2000 at 03:56:43PM +0000, stephenb@uk.uu.net wrote: > Hi > Ok so we have been round and round on this subject but no one > seems to have suggested the obvious. We are using x.x.x.x:nn for > ipv4 why not use x:x:x:x.nn for ipv6. What about the IPv4 compatibility notation? ::130.205.0.20 for my address. Now port would be ::130.205.0.20.80? > I will now don my fire proof vest. > Regards, > -- > ---------------------------------- > E-Mail: stephenb@uk.uu.net > Phone: +44 (0)1223 581051 > > > Stephen Burley > EMEA Registrar UUNET > ---------------------------------- Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From wmaton@ryouko.dgim.crc.ca Mon Jan 17 20:41:01 2000 From: wmaton@ryouko.dgim.crc.ca (William F. Maton) Date: Mon, 17 Jan 2000 15:41:01 -0500 (EST) Subject: Linux and IPv6 In-Reply-To: <200001171606.TAA06351@ms2.inr.ac.ru> Message-ID: On Mon, 17 Jan 2000 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > I think I mis-stated myself. What I wanted to say, is this: What is the > > earliest kernel that would support IPv6 functions? > > linux-2.1.8 2.1.x being a development series kernel, and 2.2.x being the production one. > Alexey Kuznetsov wfms From bound@zk3.dec.com Tue Jan 18 00:32:20 2000 From: bound@zk3.dec.com (Jim Bound) Date: Mon, 17 Jan 2000 19:32:20 -0500 Subject: IPv6 address/port format In-Reply-To: Your message of "Mon, 17 Jan 2000 13:10:45 EST." <20000117131045.C18519@alcove.wittsend.com> Message-ID: <200001180032.TAA0000025749@quarry.zk3.dec.com> >What about the IPv4 compatibility notation? >::130.205.0.20 for my address. Now port would be ::130.205.0.20.80? We could just get rid of IPv4 compatible addresses :---).... /jim From wojboj@lp.net.pl Tue Jan 18 06:13:14 2000 From: wojboj@lp.net.pl (Wojtek Bojdo/l) Date: Tue, 18 Jan 2000 07:13:14 +0100 (CET) Subject: IPv6 address/port format In-Reply-To: <200001180032.TAA0000025749@quarry.zk3.dec.com> Message-ID: On Mon, 17 Jan 2000, Jim Bound wrote: > >What about the IPv4 compatibility notation? > > >::130.205.0.20 for my address. Now port would be ::130.205.0.20.80? > > We could just get rid of IPv4 compatible addresses :---).... we don't need to... When we write IPv4 compatible address it can look: :k.l.m.n:o.p.q.r but it can't look: :k.l.m.n:o.p.q.r.s If our resolver function 'll count how many dot's it got after last : and if there's no next :, and it's 5th dot, it can get it as port. I think it can be good idea, but we should check if it would be hard to implement. -- ------------------------------------------------------------- = Wojciech Bojdo/l wojboj@lp.net.pl www.lp.net.pl/~wojboj = [ No things are impossible - they're only incredible ] ------------------------------------------------------------- From mhw@wittsend.com Tue Jan 18 13:41:39 2000 From: mhw@wittsend.com (Michael H. Warfield) Date: Tue, 18 Jan 2000 08:41:39 -0500 Subject: IPv6 address/port format In-Reply-To: ; from wojboj@lp.net.pl on Tue, Jan 18, 2000 at 07:13:14AM +0100 References: <200001180032.TAA0000025749@quarry.zk3.dec.com> Message-ID: <20000118084139.D25244@alcove.wittsend.com> Just love playing devil's advocate... On Tue, Jan 18, 2000 at 07:13:14AM +0100, Wojtek Bojdo/l wrote: > > On Mon, 17 Jan 2000, Jim Bound wrote: > > > >What about the IPv4 compatibility notation? > > > > >::130.205.0.20 for my address. Now port would be ::130.205.0.20.80? > > > > We could just get rid of IPv4 compatible addresses :---).... > we don't need to... > When we write IPv4 compatible address it can look: > :k.l.m.n:o.p.q.r > but it can't look: > :k.l.m.n:o.p.q.r.s Ok... Pop quiz. ::130.205.1.143 Is that port 143 on system 130.205.1.0 (host 1.0 on network 130.205) or is that host 130.205.1.143? It's a rare case, but legitimate. In IPv4 notation they allow 130.20.1 to be the equivalent of 130.205.1.0 in full. This is BUTT UGLY, IMHO, but apparently legal and I've actually encountered some people using it and pointing it out to me. So this one particular instance is ambiguous, unless we specify, up front, that all four of the dotted quads are specified in full for IPv4 compat notation. > If our resolver function 'll count how many dot's it got after last : > and if there's no next :, and it's 5th dot, it can get it as port. I had parsers that have to do things like that (although you have to do things like that for syntax checking anyways). :-) > I think it can be good idea, but we should check if it would be hard to > implement. > -- > ------------------------------------------------------------- > = Wojciech Bojdo/l wojboj@lp.net.pl www.lp.net.pl/~wojboj = > [ No things are impossible - they're only incredible ] > ------------------------------------------------------------- Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From tlund@nxs.se Wed Jan 19 03:32:12 2000 From: tlund@nxs.se (Tomas Lund) Date: Wed, 19 Jan 2000 04:32:12 +0100 (CET) Subject: IPv6 address/port format In-Reply-To: <20000118084139.D25244@alcove.wittsend.com> Message-ID: On Tue, 18 Jan 2000, Michael H. Warfield wrote: > Ok... Pop quiz. > > ::130.205.1.143 > > Is that port 143 on system 130.205.1.0 (host 1.0 on network 130.205) > or is that host 130.205.1.143? It's a rare case, but legitimate. In > IPv4 notation they allow 130.20.1 to be the equivalent of 130.205.1.0 in [snip] I think you mean 130.205.0.1... [sloth]:~$ telnet 10.1 Trying 10.0.0.1... //tlund From wojboj@lp.net.pl Wed Jan 19 06:14:09 2000 From: wojboj@lp.net.pl (Wojtek Bojdo/l) Date: Wed, 19 Jan 2000 07:14:09 +0100 (CET) Subject: IPv6 address/port format In-Reply-To: <20000118084139.D25244@alcove.wittsend.com> Message-ID: On Tue, 18 Jan 2000, Michael H. Warfield wrote: > Ok... Pop quiz. > > ::130.205.1.143 > > Is that port 143 on system 130.205.1.0 (host 1.0 on network 130.205) > or is that host 130.205.1.143? It's a rare case, but legitimate. In > IPv4 notation they allow 130.20.1 to be the equivalent of 130.205.1.0 in > full. This is BUTT UGLY, IMHO, but apparently legal and I've actually > encountered some people using it and pointing it out to me. So this one > particular instance is ambiguous, unless we specify, up front, that all four > of the dotted quads are specified in full for IPv4 compat notation. but... who want's to telnet to network address port 23? or to look at home page of network addr? ::130.205.1.143..80 can be also a good idea. -- ------------------------------------------------------------- = Wojciech Bojdo/l wojboj@lp.net.pl www.lp.net.pl/~wojboj = [ No things are impossible - they're only incredible ] ------------------------------------------------------------- From mkt@ecs.soton.ac.uk Tue Jan 18 15:13:25 2000 From: mkt@ecs.soton.ac.uk (Mark Thompson) Date: Tue, 18 Jan 2000 15:13:25 +0000 Subject: IPv6 address/port format In-Reply-To: <20000118084139.D25244@alcove.wittsend.com> References: <200001180032.TAA0000025749@quarry.zk3.dec.com> <20000118084139.D25244@alcove.wittsend.com> Message-ID: <20000118151325.B8358@ecs.soton.ac.uk> On 08:41(GMT) 18-01-00, Michael H. Warfield wrote: > > we don't need to... > > When we write IPv4 compatible address it can look: > > :k.l.m.n:o.p.q.r > > but it can't look: > > :k.l.m.n:o.p.q.r.s > > Ok... Pop quiz. > > ::130.205.1.143 > > Is that port 143 on system 130.205.1.0 (host 1.0 on network 130.205) > or is that host 130.205.1.143? It's a rare case, but legitimate. In > IPv4 notation they allow 130.20.1 to be the equivalent of 130.205.1.0 in > full. This is BUTT UGLY, IMHO, but apparently legal and I've actually > encountered some people using it and pointing it out to me. So this one > particular instance is ambiguous, unless we specify, up front, that all four > of the dotted quads are specified in full for IPv4 compat notation. OK, so why not borrow some semantics from prefixlen? ::152.78.65.197/32:23 IPv4 compatible address for IPv4 host 152.78.65.197, which is host 65.197 on network 152.78 (32 bit prefix length), port 23 Fairly succint in that it is not introducing any new concepts (IPv4 uses colons to delimit address from ports). It means that if we're not always expressing the prefix length, we end up with ::152.78.65.197/:23 It gets around the problems highlighted so far, but perhaps isn't as eligant as what people are expecting. Needs more thought :-) Mark/ -- details at: http://www.ecs.soton.ac.uk/info/people/mkt From jabley@patho.gen.nz Wed Jan 19 10:26:27 2000 From: jabley@patho.gen.nz (Joe Abley) Date: Wed, 19 Jan 2000 23:26:27 +1300 Subject: IPv6 address/port format In-Reply-To: ; from wojboj@lp.net.pl on Wed, Jan 19, 2000 at 07:14:09AM +0100 References: <20000118084139.D25244@alcove.wittsend.com> Message-ID: <20000119232625.B12427@patho.gen.nz> On Wed, Jan 19, 2000 at 07:14:09AM +0100, Wojtek Bojdo/l wrote: > but... who want's to telnet to network address port 23? > or to look at home page of network addr? > ::130.205.1.143..80 can be also a good idea. This list used to be for discussion of 6bone operations, before it inexplicably descended into inane chit-chat about URI notation. If this discussion really does have to happen again, can't it happen somewhere else? Joe From woeber@cc.univie.ac.at Wed Jan 19 13:32:57 2000 From: woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 19 Jan 2000 13:32:57 MET Subject: IPv6 address/port format Message-ID: <009E460A.29547528.2@cc.univie.ac.at> => Is that port 143 on system 130.205.1.0 (host 1.0 on network 130.205) => or is that host 130.205.1.143? It's a rare case, but legitimate. In => IPv4 notation they allow 130.20.1 to be the equivalent of 130.205.1.0 in = =[snip] = =I think you mean 130.205.0.1... = =[sloth]:~$ telnet 10.1 =Trying 10.0.0.1... That's exactly why we should avoid room for (different) interpretations. "Everyone" in the routing world would read(expand) 10.1 as 10.1.0.0/16 :-) and I suppose most of the tools (other than your telnet :-) would expand that to 10.1.0.0/32 .... Wilfried. From cross@eng.us.uu.net Wed Jan 19 15:54:04 2000 From: cross@eng.us.uu.net (Chris P. Ross) Date: Wed, 19 Jan 2000 10:54:04 -0500 (EST) Subject: IPv6 address/port format In-Reply-To: Wilfried Woeber, UniVie/ACOnet's message of Wed, 19 January 2000 13:32:57 MET <009E460A.29547528.2@cc.univie.ac.at> References: <009E460A.29547528.2@cc.univie.ac.at> Message-ID: <14469.56860.989804.547352@ballista.eng.us.uu.net> "Wilfried Woeber, UniVie/ACOnet" said: > =[sloth]:~$ telnet 10.1 > =Trying 10.0.0.1... > That's exactly why we should avoid room for (different) interpretations. > "Everyone" in the routing world would read(expand) 10.1 as 10.1.0.0/16 :-) > and I suppose most of the tools (other than your telnet :-) would expand > that to 10.1.0.0/32 .... Actually, it's not that simple. There are defined to be two different interpretations. When talking about *network* addresses, 10.1 is 10.1.0.0 (and, actually, I think the presumed netmask would be /8, not /16, for net 10...). When talking about a *host* address, it's 10.0.0.1. That's the "long established" way to do abreviated dotted-quads. Actually, looking at the man page for inet(3) on my BSD/OS machine, it doesn't even mention the system you're saying "everyone" uses. It only mentions the system of putting the last segment in the right-hand side, scaling it appropriately based on how many segments are in the given address. You can probabaly find this man page on any BSD-based system... - Chris -- Chris P. Ross UUNET Technologies, Inc. cross@eng.us.uu.net R & D / Engineering cross@uu.net From koji@dti.ad.jp Thu Jan 20 00:33:48 2000 From: koji@dti.ad.jp (Koji Kondo) Date: Thu, 20 Jan 2000 09:33:48 +0900 Subject: please add "8.0.8.e.f.f.3.ip6.int." delegation infomation Message-ID: <20000120093348A.koji@dti.ad.jp> Hi, Would you please update your delegation infomation? I have attached the NS records you'll need to add. Thanks, koji -- ; 8.0.8.e.f.f.3.ip6.int. in ns gate.net.dti.ad.jp. in ns ix6.otemachi.dti.ad.jp. ; -- From richdr@microsoft.com Thu Jan 20 18:10:46 2000 From: richdr@microsoft.com (Richard Draves) Date: Thu, 20 Jan 2000 10:10:46 -0800 Subject: FW: reverse lookup for 2002::/16 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21A23@RED-MSG-50> I haven't heard from Bill, does anyone else know about this stuff? Thanks, Rich > -----Original Message----- > From: Richard Draves > Sent: Friday, January 14, 2000 2:46 PM > To: 'manning@isi.edu' > Subject: reverse lookup for 2002::/16 > > Hi Bill, what has to happen so that reserve lookup of 6to4 addresses can > work? Can I send you the address of a DNS server to which you can delegate > the reverse mappings for 2002:836b:4179::/48? > > Thanks, > Rich From fink@es.net Fri Jan 21 01:27:39 2000 From: fink@es.net (Bob Fink) Date: Thu, 20 Jan 2000 17:27:39 -0800 Subject: FW: reverse lookup for 2002::/16 In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101CA21A23@RED-MSG-50> Message-ID: <4.2.2.20000120172541.00abb5c0@imap2.es.net> Rich, AM 1/20/00 -0800, Richard Draves wrote: >I haven't heard from Bill, does anyone else know about this stuff? I don't believe so, but he may have made some backup arrangements (which I will certainly push for if he hasn't), but he will need to tell us. So... we are stuck until he replies. Thanks, Bob From Mounir.Eddabbabi@ensi.rnu.tn Fri Jan 21 20:10:04 2000 From: Mounir.Eddabbabi@ensi.rnu.tn (Mounir Eddabbabi) Date: Fri, 21 Jan 2000 21:10:04 +0100 Subject: video conference tools in IPv6 References: <3801BA29.B060A87E@kt.co.kr> Message-ID: <3888BD1B.E3B06B9B@ensi.rnu.tn> This is a multi-part message in MIME format. --------------76D7784B89F251DA9BCB5897 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ksb wrote: > If you hope to test the video conference on IPv6, > see following URLs. > > http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/experimental/ > http://www-mice.cs.ucl.ac.uk/multimedia/software/vic/ > > Will you send me the test results? > > Thanks. > > -- > Kim, Sahng-Beom / Korea Telecom > TEL : +82-42-870-8322 > FAX : +82-42-870-8329 > E-mail : ksbn@kt.co.kr > -- Hi I've two PCs (FreeBSD 3.2) with INRIA/IPv6 souche. I would like testing vic and vat on IPv6. I've successefully installed them. But I don't know how to succes the demo. This is the configuration of my test bed. \ 6bone / ------------------------------ | tunnel via cselt.it | ------------------------------------- | | ---------------------- --- ---------------------------- | 193.95.37.60 (neo.isetcom.rnu.tn) | | 193.95.37.61 (ploster.isetcom.rnu.tn) | -------------------------- ---------------------------- | ---------------------- --- I've tried that : vat ::1/2244 in both machines (vic too ; vic ::1/2255, but nothing is happened. What should I do ? (tunnel or other configuration that I've missed here) best regards PS. Can I get a conference web site (audio or video) for me connecting and trying that ??? ) This is the configuration for ploster.isetcom.rnu.tn [dabbabi@ploster ~]$ifconfig -au ed1: flags=8843 mtu 1500 inet 193.95.37.61 netmask 0xffffff00 broadcast 193.95.37.255 inet6 3ffe:1001:1:b000:280:c8ff:fe57:f3e2/128 inet6 fe80::280:c8ff:fe57:f3e2/64 ether 00:80:c8:57:f3:e2 sit0: flags=41 mtu 1480 inet6 ::193.95.37.61/96 lladdr 00:00:c1:5f:25:3d cti0: flags=8051 mtu 1480 inet6 ::193.95.37.61/128 --> ::193.95.37.60 lladdr 00:00:c1:5f:25:3d lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1/128 [dabbabi@ploster ~]$cat /etc/rc.ipv6 #!/bin/sh /sbin/sysctl -w net.inet6.ipv6.forwarding=1 /sbin/sysctl -w net.inet6.ipv6.mforwarding=1 /sbin/autoconf6 -asvm ed1 >/tmp/autoconf6 2>&1 /usr/sbin/ndpd-host and this one for neo.isetcom.rnu.tn [dabbabi@neo dabbabi]$ifconfig -au de0: flags=8c43 mtu 1500 inet 192.168.0.1 netmask 0xffff0000 broadcast 192.168.255.255 inet6 fe80::280:c8ff:fe0b:47ab/128 inet6 fe80::280:c8ff:fe0b:47ac/64 ether 00:80:c8:0b:47:ac media: autoselect (10base5/AUI) status: active supported media: autoselect 10base5/AUI 10base2/BNC 10baseT/UTP 10baseT/UTP tl0: flags=8843 mtu 1500 inet 193.95.37.60 netmask 0xffffff00 broadcast 193.95.37.255 inet6 3ffe:1001:1:b000::99/128 inet6 fe80::208:c7ff:fe24:de16/64 ether 00:08:c7:24:de:16 media: autoselect (10baseT/UTP ) supported media: 100baseTX 100baseTX 100base TX 10baseT/UTP autoselect 10base5/AUI 10baseT/UTP 10baseT/UTP sit0: flags=41 mtu 1480 inet6 ::193.95.37.60/96 lladdr 00:00:c1:5f:25:3c sit1: flags=41 mtu 1480 inet6 ::192.168.0.1/112 lladdr 00:00:c0:a8:00:01 cti0: flags=8051 mtu 1480 inet6 3ffe:1001:1:b000::98/128 --> fe80::a3a2:aa84 inet6 ::193.95.37.60/128 --> ::163.162.170.132 inet6 fe80::c15f:253c/128 --> fe80::a3a2:aa84 lladdr 00:00:c1:5f:25:3c lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1/128 [dabbabi@neo dabbabi]$cat /etc/rc.ipv6 #!/bin/sh # IPv6 setup for neo.ipv6.isetcom.rnu.tn (FreeBSD 3.2) # /sbin/sysctl -w net.inet6.ipv6.forwarding=1 /sbin/sysctl -w net.inet6.ipv6.mforwarding=1 /sbin/autoconf6 -asvm tl0 >/tmp/autoconf6 2>&1 /sbin/ifconfig tl0 inet6 firstalias 3ffe:1001:0001:b000::99/128 /sbin/ifconfig de0 inet6 firstalias fe80::280:c8ff:fe0b:47ab/128 /usr/sbin/ndpd-router -s -D 60/20 cti_ifaces=`ifconfig -a|grep -w cti[0-9]*|grep -v UP|awk -F":" '{print $1}'` cti_iface=`echo $cti_ifaces|awk '{print \$1'}` if [ -z $cti_iface ]; then count=`/usr/sbin/sysctl net.inet6.ipv6.cti_count|awk '{print $2+1}'` /usr/sbin/sysctl -w net.inet6.ipv6.cti_count=$count iface=`echo $count -1| bc` cti_iface=`echo cti$iface` fi /sbin/cticonfig -v -s 193.95.37.60 $cti_iface 163.162.170.132 >> /tmp/tb.log /sbin/ifconfig $cti_iface inet6 3ffe:1001:0001:b000::98/128 fe80::a3a2:aa84 alias >> /tmp/tb.log /sbin/ifconfig $cti_iface inet6 first 3ffe:1001:0001:b000::98 >> /tmp/tb.log /sbin/route -n add -inet6 3ffe::/16 fe80::a3a2:aa84 /sbin/route -n add -inet6 5f00::/8 fe80::a3a2:aa84 --------------76D7784B89F251DA9BCB5897 Content-Type: text/x-vcard; charset=us-ascii; name="Mounir.Eddabbabi.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mounir Eddabbabi Content-Disposition: attachment; filename="Mounir.Eddabbabi.vcf" begin:vcard n:Eddabbabi;Mounir tel;home:216-4-896142 x-mozilla-html:FALSE url:http://members.xoom.com/dabbabi/ org:ENSI;RSR adr:;;BP 290 Av Taieb M'Hiri;Ariana;;2080;Tunisia version:2.1 email;internet:Mounir.Eddabbabi@ensi.rnu.tn title:Master Student x-mozilla-cpt:;8864 fn:Mounir Eddabbabi end:vcard --------------76D7784B89F251DA9BCB5897-- From hansolofalcon@worldnet.att.net Mon Jan 24 02:04:24 2000 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Sun, 23 Jan 2000 21:04:24 -0500 Subject: Gathering a consensus Message-ID: <01BF65E5.70011AE0.hansolofalcon@worldnet.att.net> Hello from Gregg C Levine from Jedi Knight Computers I know that there is a large community out there using Linux, and Sun, and FreeBSD, to manage the IPv6 idea. But what about a version of BSD that was successfully ported to the Macintosh? This port is either NetBSD or OpenBSD, depending on the machine configuration, which is yet to be chosen. We are also looking at Linux on the PPC processor configuration, and then on a Mac, or even as a VMEbus system. I, myself, prefer Windows, or Linux, but that is already well known. Please contact me directly with ideas, suggestions, and complaints, especially complaints. Gregg C Levine mailto:hansolofalcon@worldnet.att.net "They were in the wrong place, at the wrong time, naturally they became heroes." Princess Leia Organna of Alderann, Senator "Remember, the Force will be with you." Obi-Wan(Ben) Kenobi, Jedi Knight and, General, (Retired) "No! Try not. Do... or do not. There is no try." - Yoda, Jedi Master "May the Force be with you." Anonymous From plano@alanet.com.br Tue Jan 25 10:18:22 2000 From: plano@alanet.com.br (plano) Date: Tue, 25 Jan 2000 08:18:22 -0200 Subject: No subject Message-ID: <007001bf671d$86db6160$d000a8c0@chico> This is a multi-part message in MIME format. ------=_NextPart_000_0064_01BF670C.BE8AD020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsusbscribe plano@alanet.com.br ------=_NextPart_000_0064_01BF670C.BE8AD020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsusbscribe plano@alanet.com.br
<= /BODY> ------=_NextPart_000_0064_01BF670C.BE8AD020-- From FRajan@alghanim.com Wed Jan 26 05:17:53 2000 From: FRajan@alghanim.com (Flex Rajan) Date: Wed, 26 Jan 2000 08:17:53 +0300 Subject: No subject Message-ID: <388E8381.F9C7944B@alghanim.com> unsusbscribe Frajan@alghanim.com From gilbert@ammb.com.my Wed Jan 26 08:15:45 2000 From: gilbert@ammb.com.my (Gilbert Tan (IS Dept)) Date: Wed, 26 Jan 2000 16:15:45 +0800 Subject: No subject Message-ID: unsusbscribe gilbert@ammb.com.my From root@cc1017114-a.union1.nj.home.com Wed Jan 26 18:37:45 2000 From: root@cc1017114-a.union1.nj.home.com (root) Date: Wed, 26 Jan 2000 13:37:45 -0500 Subject: wrong again Message-ID: <200001261837.NAA01197@cc1017114-a.union1.nj.home.com> send your msg to majordomo@isi.edu From gcampos@campus.cem.itesm.mx Wed Jan 26 19:46:46 2000 From: gcampos@campus.cem.itesm.mx (Gabriela Campos) Date: Wed, 26 Jan 2000 13:46:46 -0600 Subject: (no subject) Message-ID: <388F4F26.3E0B6915@campus.cem.itesm.mx> unsusbscribe gcampos@campus.cem.itesm.mx From boozy@rabelo.eti.br Thu Jan 27 03:03:47 2000 From: boozy@rabelo.eti.br (Boozy) Date: Thu, 27 Jan 2000 01:03:47 -0200 Subject: (KAME-snap 1790) Re: DNS for IPv6 In-Reply-To: <4666.948850423@coconut.itojun.org> References: Message-ID: <200001270314.TAA22901@tnt.isi.edu> Hi, I finished the installation and configuration of bind8 for FreeBSD/KAME but I don't know how I can set the reverse ipv6 address. I read the RFC 1886 (DNS Extensions to support IP version 6), but I didn't understand the "IP6.INT Domain". How can I use it? Where can I find more information about it? Thanks, Luciano Rabelo At 10:33 26/01/2000 +0900, you wrote: > >>I installed bind8 port for FreeBSD/Kame. Where can I get information about its >>configuration? > > read through manpages, and books. there's nothing special about it. > http://www.normos.org/ietf/rfc/rfc1886.txt may be of use. > >itojun > From pontus@lysator.liu.se Thu Jan 27 08:40:11 2000 From: pontus@lysator.liu.se (Pontus Lidman) Date: Thu, 27 Jan 2000 09:40:11 +0100 (MET) Subject: (KAME-snap 1790) Re: DNS for IPv6 In-Reply-To: <200001270314.TAA22901@tnt.isi.edu> Message-ID: On Thu, 27 Jan 2000, Boozy wrote: > Hi, > > I finished the installation and configuration of bind8 for FreeBSD/KAME but > I don't know how I can set the reverse ipv6 address. I read the RFC 1886 > (DNS Extensions to support IP version 6), but I didn't understand the > "IP6.INT Domain". How can I use it? Where can I find more information about > it? You might want to read "IPv6 DNS examples" on http://www.visc.vt.edu/ipv6/doc/dns.html -- Pontus Lidman, pontus@mathcore.com, Software Engineer No matter how cynical you get, it's impossible to keep up. Scene: www.dc-s.com | MUD: tyme.envy.com 6969 | irc: irc.quakenet.eu.org From gsepulve@chilesat.net Thu Jan 27 15:23:04 2000 From: gsepulve@chilesat.net (Guga) Date: Thu, 27 Jan 2000 12:23:04 -0300 Subject: (no subject) Message-ID: <389062D7.CBCBE173@chilesat.net> unsusbscribe gsepulve@chilesat.net From dancer@zeor.simegen.com Fri Jan 28 03:33:17 2000 From: dancer@zeor.simegen.com (Dancer) Date: Fri, 28 Jan 2000 03:33:17 +0000 Subject: Apps and network layers References: Message-ID: <38910DFD.E2C1A4D2@zeor.simegen.com> Luciano Rabelo wrote: > Hi, > > I have some doubts. Applications and services like telnet, ftp, apache > (http), and others, are implemented at application layer. So they wouldn´t > need to be patched to IPv6 because the network layer functions should by > transparency for them. Am I right? If yes, why that programs have patches > to work with IPv6? Will every applications have to be patched? > IPv6 addresses are larger than IPv4 addresses and stored in different structures. More recent API's provide generic containment and encapsulation of addresses so that you do not need to know which type or protocol you are using, but applications older than those API's need to be converted to deal with them. In short, you can't just stuff the result from gethostbyname() into an unsigned int, unless you have a BITS implementation running underneath. D From pwilson@apnic.net Fri Jan 28 04:43:30 2000 From: pwilson@apnic.net (Paul Wilson) Date: Fri, 28 Jan 2000 14:43:30 +1000 Subject: prefix lengths [was Re: stla registry db issue] In-Reply-To: <3868F893.DC849329@hursley.ibm.com> Message-ID: <002f01bf694a$39593ff0$4701a8c0@wilson.staff.apnic.net> Here's a somewhat belated response on this topic, and on the previous thread. In this discussion it seems to me that the critical question is, what defines an ISP? In the v4 world, BigCo may be a large multinational company with a large multihomed infrastructure, which doesn't call itself an ISP but which nevertheless qualifies for a Provider Independent (i.e. portable, globally routable) allocation. On the other hand, SmallCo may provide ISP services, but have a small singly-homed infrastructure and therefore not qualify for a PI allocation (needing instead to get address space from its upstream). Therefore the allocations that RIRs make are not simply dependent on whether the organisation is an "ISP", but rather on a number of other technically-based and objective criteria. We could of course redefine the term "ISP" to mean an organisation that actually receives a PI allocation, but that's not really useful or necessary since the term is so widely used to refer to a bigger class of organisations. In the IPv6 world, we could likewise define an "ISP" as an organisation that qualifies for a /35 allocation and a /29 (subTLA) reservation, and I suspect that this definition is behind some of the previous discussions. In this case it goes without saying that we would never share a /29 among multiple "ISPs", simply because the /29 is reserved for each "ISP". However we must agree that once a /29 has been reserved/allocated to one organisation, there *will* be downstream customer organisations receiving assignments from that address block and using those assignments for ISP activities. But the critical thing is that whether or not they call themselves an ISP (and we don't care) their assignment will be "provider aggregatable" and not entitled to be announced globally. Rather, like any other downstream customer, their prefixes will be aggregated by the upstream provider within its own announcement. I believe it is this type of organisation (the small, downstream ISP) which Kengo Nagahashi was referring to in his original message. Incidentally, I guess such a downstream organisation (call it an ISP or not) could conceivably end up with a /35 or larger assignment, but would still aggregate that within its upstream address block, until such time as it qualified for its own subTLA allocation. Furthermore, my understanding (and correct me if i'm wrong) is that such an organisation could also be multi-homed, having an equal-sized assignment from each of several upstreams, but again having each of its routes aggregated in the global announcements of those upstreams. This may not be the best case, but it surely must be a possible outcome for one of the small ISP that grows a multi-homed infrastructure without yet qualifying for a subTLA. Finally, on the question of advertising prefix lengths longer than /29, it is in fact the proposal of the RIRs that the prefixes announced by any organisation will correspond only to their allocation (anywhere from /16 to /35), and not to their reservation (which would be either /16 or /29). The justification behind this (as discussed with the IAB in Minneapolis last year) is that in a future scenario where many TLA and subTLA blocks were released and allocated, and where routing table expansion again becomes a concern, it is necessary for ISPs to have an objective means available for limiting the size of their routing tables, and the best such means available is to filter on prefix length. The alternative is a huge routing table populated with /16 and /29 prefixes only, where no objective means for route filtering is available, and where bilateral routing agreements would emerge as the only way for an ISP to control its tables. Regards, Paul Wilson APNIC. ______________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3367 0490/82 ---------------------------------------------------------------------- See you at APRICOT 2000! 28 Feb - 2 Mar http://www.apricot2000.ne.kr ---------------------------------------------------------------------- > -----Original Message----- > From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of Brian > E Carpenter > Sent: Wednesday, 29 December 1999 3:51 > To: 6bone@ISI.EDU > Subject: prefix lengths [was Re: stla registry db issue] > > > Folks, > > 2**64 is a big number. It's the square of 2**32 if nobody > noticed. The majority of > BigCos will be able to understand this and use no more than an > SLA. If there are a few > idiot CIOs who insist on more for no good reason, it isn't the > end of the world. > > I am very relaxed about /29s being reserved at this stage of the > life of IPv6, > because 2**29 is also a big number. I'm not recommending any > change in the RIR > guideline of only allocating /35s; all I'm doing is saying that > we must stick > to the rule of not splitting /29s between ISPs. > > If BigCo is 20-homed, and doesn't want to deal with 20 prefixes, > then I can certainly > see a case for them leasing a prefix that can be in the > default-free table. But this > really will be the exception case. What we must do is ensure that > a 2-homed site can > easily deal with 2 prefixes. BTW, how many 6bone sites are > multihomed today? > > Brian > > "Perry E. Metzger" wrote: > > > > "Michael H. Lambert" writes: > > > On Thu, 23 Dec 1999, Bill Manning wrote: > > > > > > > > Er, that is pretty much exactly the point I was trying to make. > > > > If Brian is right and that group is successful in restricting > > > > announcements to /29's, how much space is wasted for the sixty > > > > nodes that form the cluster "www.bigco.com" that has connections > > > > to 20 major ISPs? > > > > > > But is "bigco.com" a transit IPv6 provider? My understanding > is that if > > > it isn't, it should never be allocated its own TLA. It > should receive a > > > small block from each of its ISPs. Or am I missing something? > > > > Anyone out there who thinks they can actually prevent GM or Yahoo or > > the like from getting their own routes announced should talk to an > > anti-trust lawyer. > > > > Perry > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter (IAB Chair) > Program Director, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Attend INET 2000: http://www.isoc.org/inet2000 > Non-IBM email: brian@icair.org > > > From bmanning@ISI.EDU Fri Jan 28 12:14:29 2000 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 28 Jan 2000 04:14:29 -0800 (PST) Subject: prefix lengths [was Re: stla registry db issue] In-Reply-To: <002f01bf694a$39593ff0$4701a8c0@wilson.staff.apnic.net> from "Paul Wilson" at Jan 28, 2000 02:43:30 PM Message-ID: <200001281214.EAA05854@zephyr.isi.edu> % Here's a somewhat belated response on this topic, and on the previous % thread. % % In this discussion it seems to me that the critical question is, what % defines an ISP? And to answer this question it would be prudent to revisit the discussions on this very point in the CIDRd and PIARA wg minutes from 1994-1997. It turns out that the only significant difference between an "ISP" and and "RIR" is whether they announce via a routing protocol some/all of their delegated prefixes to peers. % themselves an ISP (and we don't care) their assignment will be "provider % aggregatable" and not entitled to be announced globally. Rather, like any % other downstream customer, their prefixes will be aggregated by the upstream % provider within its own announcement. the kicker is, once a delegation is made, what enforcement methods are in place? And given the fluid nature of the technology, fixing "entitlements" to specific delegations is downright silly. % is in fact the proposal of the RIRs that the prefixes announced by any % organisation will correspond only to their allocation (anywhere from /16 to % /35), and not to their reservation (which would be either /16 or /29). The % justification behind this (as discussed with the IAB in Minneapolis last % year) is that in a future scenario where many TLA and subTLA blocks were % released and allocated, and where routing table expansion again becomes a % concern, it is necessary for ISPs to have an objective means available for % limiting the size of their routing tables, and the best such means available % is to filter on prefix length. there is zero enforcement capability for this view and attempts to do so, globally, by the RIRs will get the RIRs into some interesting discussions on restraint of trade, at least in the US. ISPs (or those announcing some or all of their delegated prefixen) can use these objective means, ON A CASE BY CASE BASIS, to determin what/if they will filter. % The alternative is a huge routing table populated with /16 and /29 prefixes % only, where no objective means for route filtering is available, and where % bilateral routing agreements would emerge as the only way for an ISP to % control its tables. The picture is not that bleak. While there is a push for migration to strict bilateral agreements, there is an opening to use contracted, neutral route servers to construct routing views based on ISP whim/policy for given points in the topology. Several folks use this service today and I expect it to become more widely used... unless the market collapses into a small handful of providers. Quite frankly, I prefer the dense mesh of 100s of thousands of providers with peering relationships with hundreds of peers instead of hundreds of providers with tens of peers. i.e. address delegation policy should not be based on a presumption of potential peering, at least for IPv6. Sorry for the rant. % Regards, % % Paul Wilson % APNIC. % % ______________________________________________________________________ % Paul Wilson, Director-General, APNIC % http://www.apnic.net ph/fx +61 7 3367 0490/82 % ---------------------------------------------------------------------- % See you at APRICOT 2000! 28 Feb - 2 Mar http://www.apricot2000.ne.kr % ---------------------------------------------------------------------- % % % % > -----Original Message----- % > From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of Brian % > E Carpenter % > Sent: Wednesday, 29 December 1999 3:51 % > To: 6bone@ISI.EDU % > Subject: prefix lengths [was Re: stla registry db issue] % > % > % > Folks, % > % > 2**64 is a big number. It's the square of 2**32 if nobody % > noticed. The majority of % > BigCos will be able to understand this and use no more than an % > SLA. If there are a few % > idiot CIOs who insist on more for no good reason, it isn't the % > end of the world. % > % > I am very relaxed about /29s being reserved at this stage of the % > life of IPv6, % > because 2**29 is also a big number. I'm not recommending any % > change in the RIR % > guideline of only allocating /35s; all I'm doing is saying that % > we must stick % > to the rule of not splitting /29s between ISPs. % > % > If BigCo is 20-homed, and doesn't want to deal with 20 prefixes, % > then I can certainly % > see a case for them leasing a prefix that can be in the % > default-free table. But this % > really will be the exception case. What we must do is ensure that % > a 2-homed site can % > easily deal with 2 prefixes. BTW, how many 6bone sites are % > multihomed today? % > % > Brian % > % > "Perry E. Metzger" wrote: % > > % > > "Michael H. Lambert" writes: % > > > On Thu, 23 Dec 1999, Bill Manning wrote: % > > > > % > > > > Er, that is pretty much exactly the point I was trying to make. % > > > > If Brian is right and that group is successful in restricting % > > > > announcements to /29's, how much space is wasted for the sixty % > > > > nodes that form the cluster "www.bigco.com" that has connections % > > > > to 20 major ISPs? % > > > % > > > But is "bigco.com" a transit IPv6 provider? My understanding % > is that if % > > > it isn't, it should never be allocated its own TLA. It % > should receive a % > > > small block from each of its ISPs. Or am I missing something? % > > % > > Anyone out there who thinks they can actually prevent GM or Yahoo or % > > the like from getting their own routes announced should talk to an % > > anti-trust lawyer. % > > % > > Perry % > % > -- % > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - % > Brian E Carpenter (IAB Chair) % > Program Director, Internet Standards & Technology, IBM % > On assignment for IBM at http://www.iCAIR.org % > Attend INET 2000: http://www.isoc.org/inet2000 % > Non-IBM email: brian@icair.org % > % > % > % % -- --bill From kent.brown@fedex.com Fri Jan 28 14:56:52 2000 From: kent.brown@fedex.com (Kent Brown) Date: Fri, 28 Jan 2000 08:56:52 -0600 Subject: Implementation Help Message-ID: <3891AE34.1B7B8207@fedex.com> I am having problems getting some hosts to communicate on the 6bone and would welcome some assistance. I have a Cisco 4500 configured with the latest IOS for ipv6. It appears to be working correctly, and from the router I can ping any ipv6 address that I have tried. The machines under the router however are having more problems. I have a FreeBSD machine running 3.2 and KAME, and a Sparc Station running Solaris 7 with the ipv6 stack from Sun. >From either of these machines I can ping the default router 3ffe:1cde::1, or my end of the tunnel (3ffe:1cff:0:f2::2), but not the other end (3ffe:1cff:0:f2::1). When the machines first boot, I can only ping the default port, not the tunnel until I replace the default route to point to 3ffe:1cde::1 instead of the Link address that is default in either OS. The router has a single static route of "ipv6 route 3ffe::0/16 3ffe:1cff:0:f2::1". Has anyone else had similar problems, or am I making some glaringly obvious mistake here? Any assistance welcomed.. thanks, Kent Brown kent.brown@fedex.com From darinos@usa.net Sat Jan 29 17:04:38 2000 From: darinos@usa.net (SLAWOMIR BAGINSKI) Date: 29 Jan 00 12:04:38 EST Subject: No subject Message-ID: <20000129170438.16253.qmail@aw163.netaddress.usa.net> unsusbscribe ____________________________________________________________________ Get free email and a permanent address at http://www.amexmail.com/?A=1 From Ivano.Guardini@CSELT.IT Mon Jan 31 18:51:19 2000 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Mon, 31 Jan 2000 19:51:19 +0100 Subject: New version of ASpath-tree Message-ID: <9187FF572943D211B28100805FC130FC011DA917@xrr1.cselt.it> Hi all, this is just to inform you that a new version of ASpath-tree (v3.0) is now available for download at the following URL: http://carmen.cselt.it/ipv6/download.html As many of you already know, ASpath-tree can be used by any site connected to the 6bone BGP4+ cloud to collect a wide range of BGP4+ operational reports (routing tree visualization, automatic detection of unaggregated and invalid prefixes, routing stability analysis, etc.). This new version of the tool has been improved as follows: - added support for the new IANA assigned prefixes (i.e. 6to4 plus sTLA delegations); - added support for Cisco IOS 12.x; - improved execution speed (about 5-10 times faster) and overall efficiency; - many other small changes and improvements almost everywhere. ASpath-tree v3.0 is already up and working here at CSELT. Just have a look at: http://carmen.cselt.it/ipv6 Please do not hesitate to contact me if you need more information. Bye Ivano From fink@es.net Mon Jan 31 23:06:53 2000 From: fink@es.net (Bob Fink) Date: Mon, 31 Jan 2000 15:06:53 -0800 Subject: prefix lengths [was Re: stla registry db issue] In-Reply-To: <002f01bf694a$39593ff0$4701a8c0@wilson.staff.apnic.net> References: <3868F893.DC849329@hursley.ibm.com> Message-ID: <4.2.2.20000131145754.00d5f480@imap2.es.net> Paul, At 02:43 PM 1/28/00 +1000, Paul Wilson wrote: >Here's a somewhat belated response on this topic, and on the previous >thread. > >In this discussion it seems to me that the critical question is, what >defines an ISP? > >In the v4 world, BigCo may be a large multinational company with a large >multihomed infrastructure, which doesn't call itself an ISP but which >nevertheless qualifies for a Provider Independent (i.e. portable, globally >routable) allocation. On the other hand, SmallCo may provide ISP services, >but have a small singly-homed infrastructure and therefore not qualify for a >PI allocation (needing instead to get address space from its upstream). >Therefore the allocations that RIRs make are not simply dependent on whether >the organisation is an "ISP", but rather on a number of other >technically-based and objective criteria. > >We could of course redefine the term "ISP" to mean an organisation that >actually receives a PI allocation, but that's not really useful or necessary >since the term is so widely used to refer to a bigger class of >organisations. > >In the IPv6 world, we could likewise define an "ISP" as an organisation that >qualifies for a /35 allocation and a /29 (subTLA) reservation, and I suspect >that this definition is behind some of the previous discussions. In this >case it goes without saying that we would never share a /29 among multiple >"ISPs", simply because the /29 is reserved for each "ISP". > >However we must agree that once a /29 has been reserved/allocated to one >organisation, there *will* be downstream customer organisations receiving >assignments from that address block and using those assignments for ISP >activities. But the critical thing is that whether or not they call >themselves an ISP (and we don't care) their assignment will be "provider >aggregatable" and not entitled to be announced globally. Rather, like any >other downstream customer, their prefixes will be aggregated by the upstream >provider within its own announcement. > >I believe it is this type of organisation (the small, downstream ISP) which >Kengo Nagahashi was referring to in his original message. > >Incidentally, I guess such a downstream organisation (call it an ISP or not) >could conceivably end up with a /35 or larger assignment, but would still >aggregate that within its upstream address block, until such time as it >qualified for its own subTLA allocation. Furthermore, my understanding (and >correct me if i'm wrong) is that such an organisation could also be >multi-homed, having an equal-sized assignment from each of several >upstreams, but again having each of its routes aggregated in the global >announcements of those upstreams. This may not be the best case, but it >surely must be a possible outcome for one of the small ISP that grows a >multi-homed infrastructure without yet qualifying for a subTLA. > >Finally, on the question of advertising prefix lengths longer than /29, it >is in fact the proposal of the RIRs that the prefixes announced by any >organisation will correspond only to their allocation (anywhere from /16 to >/35), and not to their reservation (which would be either /16 or /29). The >justification behind this (as discussed with the IAB in Minneapolis last >year) is that in a future scenario where many TLA and subTLA blocks were >released and allocated, and where routing table expansion again becomes a >concern, it is necessary for ISPs to have an objective means available for >limiting the size of their routing tables, and the best such means available >is to filter on prefix length. > >The alternative is a huge routing table populated with /16 and /29 prefixes >only, where no objective means for route filtering is available, and where >bilateral routing agreements would emerge as the only way for an ISP to >control its tables. One opinion (mine at a minimum) is that simply filtering on length of prefix does not accomplish any desired result, i.e., that it is not an adequate determiner of any interesting metric. ISP's (especially large ones) will continue to filter based on whatever criteria are imortant to them, and length of prefix alone will not be it. Bob From Marc.Blanchet@viagenie.qc.ca Mon Jan 31 23:19:55 2000 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Mon, 31 Jan 2000 18:19:55 -0500 Subject: quake on IPv6: a first for IPv6! Message-ID: <3896189B.ABFD2B87@viagenie.qc.ca> Good day, On Jan 13th 3h10 am, we played what we think is the first IPv6 multiuser game: the well-known quake using IPv6. Quake source (the quakeforge version) was ported to Freebsd and then ported to freebsd-kame-ipv6 and solaris8-ipv6-ready. Some code was based on ipv6 code for linux-quake from Pontus Lidman (Thanks Pontus). We are currently porting the NT version with the MSR NT stack. Information on the port and source code is available in english at http://www.viagenie.qc.ca/en/quake.shtml and en français à http://www.viagenie.qc.ca/en/quake.shtml . Port was done by Florent Parent and André Cormier of Viagénie. A quake-ipv6 server (running solaris8-ipv6) is available to the community: quake.ipv6.viagenie.qc.ca, so people can play together using IPv6. It is a IPv6-only server: no IPv4. If you need IPv6 connectivity for your computer, you can use our freenet6 service: http://www.freenet6.net. If you want to play with us, the crew here is scheduled to play every friday 16h00 EST (GMT -5:00 I think). comments, support and suggestions are welcome at: quake-v6@viagenie.qc.ca Marc Blanchet, for the team. From Marc.Blanchet@viagenie.qc.ca Mon Jan 31 23:20:36 2000 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Mon, 31 Jan 2000 18:20:36 -0500 Subject: quake on IPv6: a first for IPv6! Message-ID: <389618C4.FC87B697@viagenie.qc.ca> Good day, On Jan 13th 3h10 am, we played what we think is the first IPv6 multiuser game: the well-known quake using IPv6. Quake source (the quakeforge version) was ported to Freebsd and then ported to freebsd-kame-ipv6 and solaris8-ipv6-ready. Some code was based on ipv6 code for linux-quake from Pontus Lidman (Thanks Pontus). We are currently porting the NT version with the MSR NT stack. Information on the port and source code is available in english at http://www.viagenie.qc.ca/en/quake.shtml and en français à http://www.viagenie.qc.ca/en/quake.shtml . Port was done by Florent Parent and André Cormier of Viagénie. A quake-ipv6 server (running solaris8-ipv6) is available to the community: quake.ipv6.viagenie.qc.ca, so people can play together using IPv6. It is a IPv6-only server: no IPv4. If you need IPv6 connectivity for your computer, you can use our freenet6 service: http://www.freenet6.net. If you want to play with us, the crew here is scheduled to play every friday 16h00 EST (GMT -5:00 I think). comments, support and suggestions are welcome at: quake-v6@viagenie.qc.ca Marc Blanchet, for the team.