From owner-ipng@sunroof.eng.sun.com Sat Mar 1 08:44:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07895; Sat, 1 Mar 1997 08:39:19 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07888; Sat, 1 Mar 1997 08:39:11 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA26341; Sat, 1 Mar 1997 08:39:48 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA17369 for ; Sat, 1 Mar 1997 08:37:36 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA13185; Sat, 1 Mar 1997 11:30:13 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23736; Sat, 1 Mar 1997 11:30:11 -0500 Message-Id: <9703011630.AA23736@wasted.zk3.dec.com> To: thomas.eklund@era-t.ericsson.se Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3119) Re: IPv6 performance In-Reply-To: Your message of "Fri, 28 Feb 97 11:40:39 +0100." <3316B627.5073@era-t.ericsson.se> Date: Sat, 01 Mar 97 11:30:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 623 IPv6 appears to run 40-50% faster than IPv4 across the board based on hack engineering tests presently at our end. But we also cleaned up a lot in BSD kernel like parts too. I am trying to get $$$ now to do all the standard tests to verify real specs (e.g. webstones, laddis, inett). These of course needed to be ported to IPv6.,... /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sun Mar 2 14:46:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08515; Sun, 2 Mar 1997 14:41:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08508; Sun, 2 Mar 1997 14:41:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA07606; Sun, 2 Mar 1997 14:42:03 -0800 Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA00608 for ; Sun, 2 Mar 1997 14:40:10 -0800 Received: from ftp.com by ftp.com ; Sun, 2 Mar 1997 17:42:03 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Sun, 2 Mar 1997 17:42:03 -0500 Received: from ftp16.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id RAA27350; Sun, 2 Mar 1997 17:39:28 -0500 Message-Id: <199703022239.RAA27350@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: hollbach@nortel.ca, ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 3121) RE: (ngtrans) Re: IPv6 performance Date: Sun, 02 Mar 1997 17:41:34 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1780 >>Reply to your message of 3/1/97 5:57 PM >=20 > This is very interesting, although i'm not sure exactly what is meant by > IPv6 running 40-50 % faster.. >=20 > if some community-minded souls would volunteer to publish their exact > methodology and test results, peer review and analysis could begin. >=20 > publically available results could be a very useful "marketing" tool for > those of us who want to help IPv6 overcome organizational-inertia and > actually get deployed. I'd suggest that we hold off promising better throughput until we've got a specific explanation on why IPv6 will always be faster than IPv4: the easy counterargument is that the router doesn't have a lot of v6 network entries to look through at this point or that the end host has fewer pcb's with v6 addresses in them that the search for a match is much faster. I'd rather know why now than have to figure out why later on when someone is saying "but you said it'd be faster"... The lack of a checksum in the IPv4 header might be one factor, but I doubt that time involved in calculating and verifying it over a 20-byte length would explain a 40% improvement. > p.s. to avoid bothering the protocol-developers, any follow-ups > should probably move to the ngtrans list? i've copied it on this note It's been said that the v6 protocol developers are sufficiently bothered that one more mail message couldn't possibly do too much harm ;-) ; besides, I'd suspect ngtrans is a subset of ipng anyway.. -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 05:42:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA09259; Mon, 3 Mar 1997 05:36:46 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA09252; Mon, 3 Mar 1997 05:36:39 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA14812; Mon, 3 Mar 1997 05:37:17 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA05987; Mon, 3 Mar 1997 05:35:32 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA06846; Mon, 3 Mar 1997 08:31:39 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA12821; Mon, 3 Mar 1997 08:31:37 -0500 Message-Id: <9703031331.AA12821@wasted.zk3.dec.com> To: "Andrew Hollbach" Cc: bound@zk3.dec.com, thomas.eklund@era-t.ericsson.se, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: (IPng 3122) Re: IPv6 performance In-Reply-To: Your message of "01 Mar 97 17:20:00 EST." <199703012251.RAA15078@mail12.digital.com> Date: Mon, 03 Mar 97 08:31:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 409 I would suggest this move to the implementors list and its not an ietf issue. This has nothing to do with transition. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 09:21:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09496; Mon, 3 Mar 1997 09:14:40 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09489; Mon, 3 Mar 1997 09:14:36 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07267; Mon, 3 Mar 1997 09:15:16 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA23201; Mon, 3 Mar 1997 09:14:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA02476; Wed, 26 Feb 1997 01:13:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA06651; Wed, 26 Feb 1997 01:13:52 -0800 Received: from netra.soft.net (netra.soft.net [164.164.128.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA03357 for ; Wed, 26 Feb 1997 01:13:45 -0800 Received: from samar.sas.soft.net by netra.soft.net (SMI-8.6/SMI-SVR4) id JAA09538; Wed, 26 Feb 1997 09:41:08 -0500 Received: from sangar.sasi.ernet.in (root@edsac.sas.soft.net [164.164.56.130]) by samar.sas.soft.net (8.7.5/8.7.5) with ESMTP id OAA16226 for ; Wed, 26 Feb 1997 14:43:55 +0530 Received: from india9.sasi.ernet.in (india9.sasi.ernet.in [202.21.147.13]) by sangar.sasi.ernet.in (8.7.5/8.7.5) with ESMTP id OAA19675 for ; Wed, 26 Feb 1997 14:48:42 +0500 Received: from sashp105 (sashp105 [202.21.147.105]) by india9.sasi.ernet.in (8.7.1/8.7.1) with ESMTP id OAA21856 for ; Wed, 26 Feb 1997 14:42:19 +0500 (GMT+0500) From: Anoop Kulkarni Received: (anoop@localhost) by sashp105 (8.6.12/16.2) id EAA03089 for ipng@sunroof.eng.sun.com; Wed, 26 Feb 1997 04:34:52 -0500 Message-Id: <199702260934.EAA03089@sashp105> Subject: (IPng 3123) IPv6 and mobility. To: ipng@sunroof.eng.sun.com (IPv6 Mailing List) Date: Wed, 26 Feb 97 14:34:52 IST Mailer: Elm [revision: 70.85] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4373 Hello, I have just joined this list so forgive me if my question is a repeat, but am interested in knowing about the so-called mobility support in IPv6. Does this mean that it is going to be completely different from Mobile IP as implemented in IPv4? I am also not quite sure about what is meant by 'support for mobility' in IPv6. The term is used more often in the rfc's but not essentially well elucidated. Does it mean that the IP header would carry this information? Any pointers are most welcome. Thanks in advance, with best regards, Anoop Kulkarni -- ______________________________________________________________________________ | Home : anoop kulkarni, |Office: anoop kulkarni, A2, Pioneer Residency,| Silicon Automation Systems (I) Pvt Ltd HAL III Stage, | 1137, Hundred feet road, Indiranagar, Bangalore - 560 075 | Bangalore - 560 038 - INDIA E-Mail: anoop@sas.soft.net |Phone : (9180)5281229 ext 3019 ______________________________|_______________________________________________ From owner-ipng@sunroof.eng.sun.com Sat Mar 1 14:45:24 1997 Return-Path: Received: from sunroof.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20124; Sat, 1 Mar 1997 14:45:24 -0800 Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08029; Sat, 1 Mar 1997 14:44:45 -0800 Date: Sat, 1 Mar 1997 14:44:45 -0800 From: owner-ipng@sunroof.eng.sun.com Message-Id: <199703012244.OAA08029@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from ["Andrew Hollbach" ] Content-Length: 2319 X-Lines: 53 Status: RO From hollbach@nortel.ca Sat Mar 1 14:44:36 1997 Return-Path: Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08022; Sat, 1 Mar 1997 14:44:36 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA15207; Sat, 1 Mar 1997 14:45:12 -0800 Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA20653; Sat, 1 Mar 1997 14:43:03 -0800 Message-Id: <199703012243.OAA20653@mercury.Sun.COM> Received: from bcarsfba.ott.bnr.ca by bcarsde4.localhost; Sat, 1 Mar 1997 17:37:50 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <02865-0@bcarsfba.bnr.ca>; Sat, 1 Mar 1997 17:20:31 -0500 Date: 01 Mar 1997 17:20 EST Sender: "Andrew Hollbach" To: bound@zk3.dec.com Cc: thomas.eklund@era-t.ericsson.se, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: "Andrew Hollbach" Subject: re:(IPng 3119) Re: IPv6 performance content-length: 1274 This is very interesting, although i'm not sure exactly what is meant by IPv6 running 40-50 % faster.. if some community-minded souls would volunteer to publish their exact methodology and test results, peer review and analysis could begin. publically available results could be a very useful "marketing" tool for those of us who want to help IPv6 overcome organizational-inertia and actually get deployed. thanks.. Andy p.s. to avoid bothering the protocol-developers, any follow-ups should probably move to the ngtrans list? i've copied it on this note In message "(IPng 3119) Re: IPv6 performance", 'bound@zk3.dec.com' writes: >IPv6 appears to run 40-50% faster than IPv4 across the board based on >hack engineering tests presently at our end. But we also cleaned up a >lot in BSD kernel like parts too. I am trying to get $$$ now to do all >the standard tests to verify real specs (e.g. webstones, laddis, inett). >These of course needed to be ported to IPv6.,... > >/jim >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 09:22:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09506; Mon, 3 Mar 1997 09:15:00 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09499; Mon, 3 Mar 1997 09:14:56 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07356; Mon, 3 Mar 1997 09:15:36 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA23228; Mon, 3 Mar 1997 09:15:06 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA02476; Wed, 26 Feb 1997 01:13:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA06651; Wed, 26 Feb 1997 01:13:52 -0800 Received: from netra.soft.net (netra.soft.net [164.164.128.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA03357 for ; Wed, 26 Feb 1997 01:13:45 -0800 Received: from samar.sas.soft.net by netra.soft.net (SMI-8.6/SMI-SVR4) id JAA09538; Wed, 26 Feb 1997 09:41:08 -0500 Received: from sangar.sasi.ernet.in (root@edsac.sas.soft.net [164.164.56.130]) by samar.sas.soft.net (8.7.5/8.7.5) with ESMTP id OAA16226 for ; Wed, 26 Feb 1997 14:43:55 +0530 Received: from india9.sasi.ernet.in (india9.sasi.ernet.in [202.21.147.13]) by sangar.sasi.ernet.in (8.7.5/8.7.5) with ESMTP id OAA19675 for ; Wed, 26 Feb 1997 14:48:42 +0500 Received: from sashp105 (sashp105 [202.21.147.105]) by india9.sasi.ernet.in (8.7.1/8.7.1) with ESMTP id OAA21856 for ; Wed, 26 Feb 1997 14:42:19 +0500 (GMT+0500) From: Anoop Kulkarni Received: (anoop@localhost) by sashp105 (8.6.12/16.2) id EAA03089 for ipng@sunroof.eng.sun.com; Wed, 26 Feb 1997 04:34:52 -0500 Message-Id: <199702260934.EAA03089@sashp105> Subject: (IPng 3124) IPv6 and mobility. To: ipng@sunroof.eng.sun.com (IPv6 Mailing List) Date: Wed, 26 Feb 97 14:34:52 IST Mailer: Elm [revision: 70.85] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4373 Hello, I have just joined this list so forgive me if my question is a repeat, but am interested in knowing about the so-called mobility support in IPv6. Does this mean that it is going to be completely different from Mobile IP as implemented in IPv4? I am also not quite sure about what is meant by 'support for mobility' in IPv6. The term is used more often in the rfc's but not essentially well elucidated. Does it mean that the IP header would carry this information? Any pointers are most welcome. Thanks in advance, with best regards, Anoop Kulkarni -- ______________________________________________________________________________ | Home : anoop kulkarni, |Office: anoop kulkarni, A2, Pioneer Residency,| Silicon Automation Systems (I) Pvt Ltd HAL III Stage, | 1137, Hundred feet road, Indiranagar, Bangalore - 560 075 | Bangalore - 560 038 - INDIA E-Mail: anoop@sas.soft.net |Phone : (9180)5281229 ext 3019 ______________________________|_______________________________________________ From owner-ipng@sunroof.eng.sun.com Sat Mar 1 14:45:24 1997 Return-Path: Received: from sunroof.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20124; Sat, 1 Mar 1997 14:45:24 -0800 Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08029; Sat, 1 Mar 1997 14:44:45 -0800 Date: Sat, 1 Mar 1997 14:44:45 -0800 From: owner-ipng@sunroof.eng.sun.com Message-Id: <199703012244.OAA08029@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from ["Andrew Hollbach" ] Content-Length: 2319 X-Lines: 53 Status: RO From hollbach@nortel.ca Sat Mar 1 14:44:36 1997 Return-Path: Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08022; Sat, 1 Mar 1997 14:44:36 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA15207; Sat, 1 Mar 1997 14:45:12 -0800 Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA20653; Sat, 1 Mar 1997 14:43:03 -0800 Message-Id: <199703012243.OAA20653@mercury.Sun.COM> Received: from bcarsfba.ott.bnr.ca by bcarsde4.localhost; Sat, 1 Mar 1997 17:37:50 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <02865-0@bcarsfba.bnr.ca>; Sat, 1 Mar 1997 17:20:31 -0500 Date: 01 Mar 1997 17:20 EST Sender: "Andrew Hollbach" To: bound@zk3.dec.com Cc: thomas.eklund@era-t.ericsson.se, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: "Andrew Hollbach" Subject: re:(IPng 3119) Re: IPv6 performance content-length: 1274 This is very interesting, although i'm not sure exactly what is meant by IPv6 running 40-50 % faster.. if some community-minded souls would volunteer to publish their exact methodology and test results, peer review and analysis could begin. publically available results could be a very useful "marketing" tool for those of us who want to help IPv6 overcome organizational-inertia and actually get deployed. thanks.. Andy p.s. to avoid bothering the protocol-developers, any follow-ups should probably move to the ngtrans list? i've copied it on this note In message "(IPng 3119) Re: IPv6 performance", 'bound@zk3.dec.com' writes: >IPv6 appears to run 40-50% faster than IPv4 across the board based on >hack engineering tests presently at our end. But we also cleaned up a >lot in BSD kernel like parts too. I am trying to get $$$ now to do all >the standard tests to verify real specs (e.g. webstones, laddis, inett). >These of course needed to be ported to IPv6.,... > >/jim >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 11:08:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10024; Mon, 3 Mar 1997 11:01:59 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10017; Mon, 3 Mar 1997 11:01:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA01082; Mon, 3 Mar 1997 11:02:30 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA14885 for ; Mon, 3 Mar 1997 11:00:43 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC27DC.10A8AF30@SNOOPY>; Mon, 3 Mar 1997 14:06:18 -0500 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Subject: (IPng 3125) Re: 2 faced DNS is here to stay Date: Mon, 3 Mar 1997 14:06:17 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1003 kre wrote: > Then the DNS can return to me all the addresses your host owns, > even link-local. I can determine from the global addresses > returned that I must be on the same cable as you are, and so pick > the link local address if I prefer. Further, my resolver could > do all that - applications need not necessarily be bothered. It seems like a waste of bandwidth to ship link local addresses around the Internet, when they are typically not going to be useful to the requesting system. I still think a mechanism of the same limited scope as the addresses is appropriate in this case. And that's what this 2-faced DNS is all about...applying a limiting scope (site-local) to a global address service. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 11:31:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10066; Mon, 3 Mar 1997 11:26:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10059; Mon, 3 Mar 1997 11:25:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA07393; Mon, 3 Mar 1997 11:26:32 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA25324 for ; Mon, 3 Mar 1997 11:24:47 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA30946; Tue, 4 Mar 1997 06:26:02 +1100 (from kre@munnari.OZ.AU) To: "Harrington, Dan" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3126) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Mon, 03 Mar 1997 14:06:17 CDT." Date: Tue, 04 Mar 1997 06:25:59 +1100 Message-Id: <3322.857417159@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2158 Date: Mon, 3 Mar 1997 14:06:17 -0500 From: "Harrington, Dan" Message-ID: It seems like a waste of bandwidth to ship link local addresses around the Internet, That's probably true, and an alternate method to discover a link local address to use when doing so seems appropriate would be an entirely reasonable thing to do - eg: get the global address back, notice that it is attached to a local cable, then send a packet to that address asking "what's your link local address on this interface, and its lifetime", and then send the SYN packet (or whatever) to that address instead of the global one. You could do the same for site local addresses when the prefix indicates that the global address is in the same site. The details of this aren't important (right now, clearly mechanisms may need to be specified). What is important, is the notion that some DNS server can make this decision for you, instead of doing it in the end host is bogus. And that's what this 2-faced DNS is all about...applying a limiting scope (site-local) to a global address service. The problem is that it is assuming that addresses are always sought from the DNS from a local server. This is something that the DNS people (of whom I am sort of one) are trying to actively stop, though that's just a by product. That is, sites should have multiple servers, and they shouldn't all be local - at least one should be someplace remote. When multiple servers exist for a domain, at various times, all of them will be queried to seek answers from time to time - partly to measure response times and determine which server is best to ask. That is, in many entirely reasonable configurations you can almost guarantee that local queries will be sent to remote sites to be answered. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 11:57:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10105; Mon, 3 Mar 1997 11:50:52 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10098; Mon, 3 Mar 1997 11:50:44 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA13538; Mon, 3 Mar 1997 11:51:22 -0800 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA03532 for ; Mon, 3 Mar 1997 11:49:42 -0800 Received: from elmo.uu.net by relay5.UU.NET with ESMTP (peer crosschecked as: elmo.UU.NET [153.39.245.203]) id QQcfhv12450; Mon, 3 Mar 1997 14:51:21 -0500 (EST) Received: from elmo.uu.net (localhost.UU.NET [127.0.0.1]) by elmo.uu.net (8.7.5/8.7.3) with ESMTP id OAA16497; Mon, 3 Mar 1997 14:51:20 -0500 (EST) Message-Id: <199703031951.OAA16497@elmo.uu.net> To: Robert Elz cc: "Harrington, Dan" , ipng@sunroof.eng.sun.com, mo@elmo.uu.net Subject: (IPng 3127) Re: 2 faced DNS is here to stay In-reply-to: Your message of "Tue, 04 Mar 1997 06:25:59 +1100." <3322.857417159@munnari.OZ.AU> Date: Mon, 03 Mar 1997 14:51:20 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 497 however.... using an address with the minimally-required scope to reach the destination is important for insulating a site from externalities as much as possible. that means "site-local" whenever possible. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 12:23:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10223; Mon, 3 Mar 1997 12:18:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10216; Mon, 3 Mar 1997 12:17:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA20044; Mon, 3 Mar 1997 12:18:31 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA14994 for ; Mon, 3 Mar 1997 12:16:49 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA23725; Tue, 4 Mar 1997 07:18:04 +1100 (from kre@munnari.OZ.AU) To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3128) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Mon, 03 Mar 1997 14:51:20 CDT." <199703031951.OAA16497@elmo.uu.net> Date: Tue, 04 Mar 1997 07:18:02 +1100 Message-Id: <7194.857420282@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 928 Date: Mon, 03 Mar 1997 14:51:20 -0500 From: "Mike O'Dell" Message-ID: <199703031951.OAA16497@elmo.uu.net> using an address with the minimally-required scope to reach the destination is important for insulating a site from externalities as much as possible. Sure, I agree with that. The question would seem to be how that address should be discovered. My point has been that a DNS server (unless we add lots of constraints that don't now exist) simply doesn't have the knowledge to make the decision, it needs to be made by the end node, which does (or should) have that knowledge. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 12:39:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10245; Mon, 3 Mar 1997 12:33:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10238; Mon, 3 Mar 1997 12:33:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA23223; Mon, 3 Mar 1997 12:34:28 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA19971 for ; Mon, 3 Mar 1997 12:32:47 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA14194; Tue, 4 Mar 1997 07:34:17 +1100 (from kre@munnari.OZ.AU) To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3129) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Mon, 03 Mar 1997 15:23:12 CDT." Date: Tue, 04 Mar 1997 07:34:16 +1100 Message-Id: <7204.857421256@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1730 Date: Mon, 03 Mar 1997 15:23:12 -0500 From: Mike O'Dell Message-ID: compare the prefix of the requestor to the (possible) prefix(es) of the translation of the name BIND used to try to do that (for IPv4) - with just the aim of sorting the addresses so the "best" one would be presented first, and the client, which was pretty dumb, would tend to use the best address. Experience has taught us that this doesn't work very well at all, and more recent implementations have the client do the address sorting, with the server staying well clear (with the server actually rotating the addresses so clients that don't care which they use tend to be spread over all the available addresses). It seems easy, but there are enough "hard cases" out there (multi homes hosts, which send perhaps from an interface connected to one site to find an address which turns out to be local to a site connected to another interface) that it really has proven better to let the end node make the decisions - it has all the information. Then of course there are DNS caches - they retrieve information from authoritative servers, and hand it out to others that request from them - the server that suplied the information can't possibly know either that it is a cache that is requesting it, nor the identities of all of the clients that may request information from the cache. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 12:58:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10335; Mon, 3 Mar 1997 12:53:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10328; Mon, 3 Mar 1997 12:52:53 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA27393; Mon, 3 Mar 1997 12:53:30 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA28162 for ; Mon, 3 Mar 1997 12:51:51 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfhx06370; Mon, 3 Mar 1997 15:23:13 -0500 (EST) Message-Id: To: Robert Elz cc: ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 3130) Re: 2 faced DNS is here to stay In-reply-to: Your message of "Tue, 04 Mar 1997 07:18:02 +1100." <7194.857420282@munnari.OZ.AU> Date: Mon, 03 Mar 1997 15:23:12 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 784 actually it's pretty easy. compare the prefix of the requestor to the (possible) prefix(es) of the translation of the name if the requestor's prefix matches one, include the "site-local" version in the response set with the highest preference resolvers then simply choose the highest precedence, or build-in knowledge of the site-local prefix and pick that one when offered. that way even off-site resolvers can return the right thing and it will get picked it really doesn't seem too hard -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 13:53:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10505; Mon, 3 Mar 1997 13:47:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10498; Mon, 3 Mar 1997 13:47:38 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA14631; Mon, 3 Mar 1997 13:48:16 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA22219 for ; Mon, 3 Mar 1997 13:46:36 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id QAA18804; Mon, 3 Mar 1997 16:47:42 -0500 Date: Mon, 3 Mar 1997 16:47:42 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703031647.ZM18802@seawind.bellcore.com> In-Reply-To: "Mike O'Dell" "(IPng 3127) Re: 2 faced DNS is here to stay" (Mar 3, 2:51pm) References: <199703031951.OAA16497@elmo.uu.net> X-Mailer: Z-Mail (3.2.1 10oct95) To: "Mike O'Dell" , Robert Elz Subject: (IPng 3131) Re: 2 faced DNS is here to stay Cc: "Harrington, Dan" , ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1213 Well, there is a down side to using "site local", and in fact any addressing plan that requires the enforcement of boundaries. If your site just grows moderately big, there will be backdoors, and confusion. Take the example a a visiting guest from org X going to org Y. Attach the PC to a local Ethernet, thanks the host, obtains a "local" address -- in fact, obtains 3 local addresses: Link local, local Ethernet. Site local, within org Y Global address, say YY.FOO Next thing, a tunnel is set between the laptop and org X's firewall. The laptop now obtains two more addresses: Site local, within org X Global address, say XX.FOO When the laptop wants to do a local print out, using the printer next door, it presumably uses the "Site local, within org Y" address. If it wants to access the pop3 account of user X, it presumably uses the "Site local, within org X" address. Isn't that cool ? -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 14:44:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA10565; Mon, 3 Mar 1997 14:38:30 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA10558; Mon, 3 Mar 1997 14:38:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02425; Mon, 3 Mar 1997 14:38:59 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA15158 for ; Mon, 3 Mar 1997 14:37:13 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC27FA.4EDFAC40@SNOOPY>; Mon, 3 Mar 1997 17:42:47 -0500 Message-ID: From: "Harrington, Dan" To: "'kre@munnari.OZ.AU'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3132) Re: 2 faced DNS is here to stay Date: Mon, 3 Mar 1997 17:42:46 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1834 Hi kre, > And that's what this 2-faced DNS is all about...applying > a limiting scope (site-local) to a global address service. > > The problem is that it is assuming that addresses are always sought > from the DNS from a local server. This is something that the DNS > people (of whom I am sort of one) are trying to actively stop, > though that's just a by product. It depends upon what you mean by "a local server". By that I imagine one that is logically local, not necessarily physically local. > That is, sites should have multiple servers, and they shouldn't all > be local - at least one should be someplace remote. When multiple > servers exist for a domain, at various times, all of them will be > queried to seek answers from time to time - partly to measure > response times and determine which server is best to ask. That is, > in many entirely reasonable configurations you can almost guarantee > that local queries will be sent to remote sites to be answered. And that's fine, as long as it can be communicated to the remote DNS server that the query may have local significance, in which case something like a site-local address may be returned. Unfortunately, it smacks of policy and sounds like a bear to configure, and I can't imagine a straightforward way to implement it...but it still sounds appealing if it would help insulate local systems from changes in the wider world. Dan P.S. I believe the alternate term used last week was "context sensitive" DNS, instead of "two faced". I prefer Janus server... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 15:39:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10874; Mon, 3 Mar 1997 15:34:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10867; Mon, 3 Mar 1997 15:34:00 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA22437; Mon, 3 Mar 1997 15:34:37 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA09017 for ; Mon, 3 Mar 1997 15:32:58 -0800 Received: from gungnir.fnal.gov ("port 35502"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IG2OEG2HXS0003UF@FNAL.FNAL.GOV>; Mon, 03 Mar 1997 17:34:36 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA28813; Mon, 03 Mar 1997 17:34:35 -0600 Date: Mon, 03 Mar 1997 17:34:35 -0600 From: Matt Crawford Subject: (IPng 3133) Re: 2 faced DNS is here to stay In-reply-to: "01 Mar 1997 10:28:07 +1100." <"1705.857172487"@munnari.OZ.AU> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Message-id: <199703032334.RAA28813@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ If I have my laptop configured to use my standard (home) DNS > server, and I want to continue using that ..., and > I come and visit you, and plug my laptop into the same ethernet > as you are connected to - then I want to make a connection to > your host. > > I go to my DNS, which ... sees my request comes from a global > address, does the lookup for me ..., gets back your host's address, > which will be the global address, according to the current draft ... Rather than make you wait for the "PAL 1" minutes and conclusions, I'll tell you my solution. 1. If you're two-faced, never do recursion for an off-site DNS client. If you aren't authoritative, give authority records and additional info only. 2. If you are authoritative, compare the client's prefix to all the AAAA records for the target of the query. If any match, give the site-local AAAA only. We didn't dig into a lot of cases at length. There's probably a missing detail about clients using on-site non-authoritatve servers as forwarders. By all means, feel free to help with this. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 3 16:57:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA11132; Mon, 3 Mar 1997 16:52:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA11125; Mon, 3 Mar 1997 16:52:17 -0800 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA19306; Mon, 3 Mar 1997 16:52:55 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA24702 for ; Mon, 3 Mar 1997 16:52:54 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA19598; Tue, 4 Mar 1997 11:52:22 +1100 (from kre@munnari.OZ.AU) To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3134) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Mon, 03 Mar 1997 17:34:35 MDT." <199703032334.RAA28813@gungnir.fnal.gov> Date: Tue, 04 Mar 1997 11:52:16 +1100 Message-Id: <7277.857436736@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3300 Date: Mon, 03 Mar 1997 17:34:35 -0600 From: Matt Crawford Message-ID: <199703032334.RAA28813@gungnir.fnal.gov> Rather than make you wait for the "PAL 1" minutes and conclusions, Thanks, it is kind of difficult discussing an issue where the whole underlying rationale may have changed in the interim... 1. If you're two-faced, never do recursion for an off-site DNS client. There are reasons why servers might want to act that way anyway, 2 faced (or "context sensitive") or not - the price is that local users of the servers cannot, when travelling away from home, continue to use them. I don't think this actually solves the caching problem though, which it seems intended to do, as the problem there is other random servers (either inside or outside the site) that look up the info, and then based upon what they receive, distribute that to others (inside and outside the site). We didn't dig into a lot of cases at length. There's probably a missing detail about clients using on-site non-authoritatve servers as forwarders. By all means, feel free to help with this. Before we spend a lot of time looking into all the devious cases that might apply, can I ask why it is that we want to do this? I see 3 reasons that might make sense (there are probably more). 1) is Brian Carpenter's 'some sites are going to want to do this anyway', which is certainly true. 2) is 'we have to have 2 faced DNS servers because nodes that know only their site local addresses can't work otherwise', which was Mike's GSE draft-00's rationale (and if things were done as the draft suggested, certainly is a requirement). 3) is 'using site local addresses is better when they work, and a 2 faced DNS server is a way to communicate that information to the clients' Now if 1 is the reason, then we can have this discussion, but I don't think we need to have it in a hurry - the result might be a "HowTo" doc, and if needed restrictions could be imposed upon what is possible to do with this setup (such as no travelling mobile nodes accessing it). That's fine. If 2 is why we're doing this, then I'm still looking for an explanation of why we want to hide all the prefixes from the end nodes. Note that I have no idea if the meeting last week decided to go along with that, or if this is no longer relevant. If 3 is the answer, then what we should be doing is considering the range of options by which the end node could discover that using the site local address is the thing to do, and what that site local address is, rather than assuming that 2 faced DNS servers are the way to do it. Then, if that concludes that the DNS solution really is the best one, then we can look see how it might be managed. If that decision was taken last week, I'd like to hear the arguments, along with any other possibilities discussed, and why they were rejected. If something else if the rationale for 2 faced DNS servers, then please explain. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 04:05:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA11699; Tue, 4 Mar 1997 04:00:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA11692; Tue, 4 Mar 1997 04:00:34 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA24993; Tue, 4 Mar 1997 04:01:12 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA26613 for ; Tue, 4 Mar 1997 03:59:40 -0800 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id OAA05175; Tue, 4 Mar 1997 14:01:07 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id OAA24469; Tue, 4 Mar 1997 14:01:04 +0200 (EET) Message-Id: <199703041201.OAA24469@harakka.cs.tut.fi> Subject: (IPng 3135) IPv6 priority field usage? To: ipng@sunroof.eng.sun.com Date: Tue, 4 Mar 1997 14:01:02 +0200 (EET) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2072 Hi, Having read the IPng meeting minutes from San Jose, (see excerpt below) I wonder what is the status of priority field usage ? Steve promised to write up email message about this subject but I haven't seen such in the list (btw, xerox ftp site for IPv6 is empty). Since this proposed/approved(?) change is quite essential from the applications point of view, it is very strange that this isn't explained or discussed anywhere. Can somebody enlight me what is the status of ipv6 header's priority field usage ? Is it for applications or mainly for ISPs only ? ----clip clip from IPv6 meeting minutes---------------------------------- Priority Field / Steve Deering Deering proposed at the Montreal meeting to change the definition of the priority field and make it reserved. The original intent was to: - Generalized "drop-preference" provides the wrong incentive, encourages sending packet that won't be delivered - Potential other uses for those bits (e.g., "RED" bit, Clark's in/out-of-profile bit, ISP-private use. This proposal was disliked by people who want to favor interactive traffic over dialup or wireless links. Steve Deering proposed a new definition: - Declare that 4 bits of Priority are rewritable by routers/ISPs for private purposes (and exclude from authentication header). - Priority bits have no significance to receivers - Convention: Sender sets low order bit to mean interactive traffic. o Delay more important than throughput o Suggests that routers/ISPs use other bits before touching the "interactive bit". o Affects queuing only, not routing (since re-writable). Deering will write up as a email message and send to list. ------------------------------------------------------------- Petri ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 04:54:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA11734; Tue, 4 Mar 1997 04:48:49 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA11727; Tue, 4 Mar 1997 04:48:42 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA29748; Tue, 4 Mar 1997 04:49:19 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA09296 for ; Tue, 4 Mar 1997 04:47:48 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id HAA09686; Tue, 4 Mar 1997 07:40:17 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03392; Tue, 4 Mar 1997 07:40:15 -0500 Message-Id: <9703041240.AA03392@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3136) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Mon, 03 Mar 97 17:34:35 CST." <199703032334.RAA28813@gungnir.fnal.gov> Date: Tue, 04 Mar 97 07:40:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 343 Matt, We need to define how we know if DNS two-faced. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 06:05:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA11834; Tue, 4 Mar 1997 06:00:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA11827; Tue, 4 Mar 1997 06:00:05 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA07739; Tue, 4 Mar 1997 06:00:42 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA00568 for ; Tue, 4 Mar 1997 05:59:13 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA18117; Tue, 4 Mar 1997 08:53:52 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA08518; Tue, 4 Mar 1997 08:53:49 -0500 Message-Id: <9703041353.AA08518@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: (IPng 3137) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Mon, 03 Mar 97 15:23:12 EST." Date: Tue, 04 Mar 97 08:53:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3225 Mike, >actually it's pretty easy. > >compare the prefix of the requestor to the (possible) prefix(es) of the >translation of the name Here is an example so I can understand what folks want DNS to do: garcia.trip.dead.com IN AAAA 4F::ee:cd:aa:01:45:ff:ac:1e IN AAAA FED0::ee:cd:aa:01:45:ff:ac:1e The first AAAA is a global provider based unicast address the second is a site local address. I am not parsing what you mean by "prefix(es) of the translation name"? What does that mean? If you mean parse the name at the resolver from the DNS query to see if its in the same site as the client then I understand. But was not sure if thats what you mean or not? >if the requestor's prefix matches one, include the "site-local" version >in the response set with the highest preference 1) In the case of gethostbyaddr() at the client: The problem is that the originating nodes request may not be seen by the downstream server (forwarders in between). Clearly the resolver can search/match on prefix type via the gethostent structure. But the client or resolver has no way of telling if the corresponding node is within its site unless it looks at the name and sees .dead.com is in fact in its site. That is overhead for a resolver or client application. 2) In the case of gethostbyname2() at the client: If the client provides a site-local or global address it will get back garcia.trip.dead.com whether site-local or global is used with AF_INET6? >resolvers then simply choose the highest precedence, or build-in knowledge >of the site-local prefix and pick that one when offered. >that way even off-site resolvers can return the right thing and it will >get picked >it really doesn't seem too hard It adds additional logic and test&mask to the Hosts and it costs something. I can't put any cost in Hosts without justification just as you cannot take any performance hits at UUNET without justification. For a WWW server or an Online-Transaction application the extra processing costs something, imagine 8000 hits per minute in either of the above applications. That means at least 200,000 additional instructions executed per minute on a Server. I am not saying don't do this or follow this thru but what does not seem hard does not mean it is good to do or without cost. And it appears to me everytime we want to do something new it costs us host vendors. So I want to make sure this is all useful. Also the resolver code is already complex and this adds more complexity which means more time to debug and test new releases. So what does not seem hard to a "user" of DNS is another matter to us implementors, and where to put such functionality. It might be better in the server which is also possible and the caching will reduce the 200,000 instructions at each client to one central place. So lets not say its in the resolver until us implementors get time to check this out OK. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 06:18:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA11853; Tue, 4 Mar 1997 06:13:36 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA11846; Tue, 4 Mar 1997 06:13:28 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA09644; Tue, 4 Mar 1997 06:14:05 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA05830 for ; Tue, 4 Mar 1997 06:12:36 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA25701; Tue, 4 Mar 1997 08:59:51 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA07391; Tue, 4 Mar 1997 08:59:48 -0500 Message-Id: <9703041359.AA07391@wasted.zk3.dec.com> To: Robert Elz Cc: Matt Crawford , ipng@sunroof.eng.sun.com Subject: (IPng 3138) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Tue, 04 Mar 97 11:52:16 +1100." <7277.857436736@munnari.OZ.AU> Date: Tue, 04 Mar 97 08:59:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 855 Kre, The interim meeting decided to not do GSE. I hope we will see minutes soon. But people did think we should do more where possible to make easier the classical renumbering problem at hand to be better solved. Like using globally unique ESDs, having DNS use RG+ESD RRs and synthesizing them at the server. Two-Face DNS was an issue that folks felt need to be discussed. Also can GSE be used to make existing provider based addressing more efficient. But the essential bottom line is rewriting of packets will not happen today in IPv6 as proposed in GSE. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 06:47:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA11896; Tue, 4 Mar 1997 06:41:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA11889; Tue, 4 Mar 1997 06:41:34 -0800 From: bmanning@ISI.EDU Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA15830; Tue, 4 Mar 1997 06:42:10 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA16050 for ; Tue, 4 Mar 1997 06:40:42 -0800 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 4 Mar 1997 06:42:12 -0800 Posted-Date: Tue, 4 Mar 1997 06:41:52 -0800 (PST) Message-Id: <199703041441.AA00607@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 4 Mar 1997 06:41:52 -0800 Subject: (IPng 3139) Re: 2 faced DNS is here to stay To: bound@zk3.dec.com Date: Tue, 4 Mar 1997 06:41:52 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9703041353.AA08518@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Mar 4, 97 08:53:49 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 725 > Here is an example so I can understand what folks want DNS to do: > > garcia.trip.dead.com IN AAAA 4F::ee:cd:aa:01:45:ff:ac:1e > IN AAAA FED0::ee:cd:aa:01:45:ff:ac:1e > > The first AAAA is a global provider based unicast address the second is > a site local address. > Humm... I had thought we had agreed to not put site-local addresses in the DNS. but... if we do, how do we do the ptr mapping? --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 06:50:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA11905; Tue, 4 Mar 1997 06:44:40 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA11898; Tue, 4 Mar 1997 06:44:30 -0800 From: bmanning@ISI.EDU Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA16653; Tue, 4 Mar 1997 06:45:06 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA17049 for ; Tue, 4 Mar 1997 06:43:38 -0800 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 4 Mar 1997 06:45:08 -0800 Posted-Date: Tue, 4 Mar 1997 06:44:49 -0800 (PST) Message-Id: <199703041444.AA00617@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 4 Mar 1997 06:44:49 -0800 Subject: (IPng 3140) Re: 2 faced DNS is here to stay To: bound@zk3.dec.com Date: Tue, 4 Mar 1997 06:44:49 -0800 (PST) Cc: kre@munnari.OZ.AU, crawdad@fnal.gov, ipng@sunroof.eng.sun.com In-Reply-To: <9703041359.AA07391@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Mar 4, 97 08:59:47 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 569 > Like using globally unique ESDs, having DNS use RG+ESD RRs and > synthesizing them at the server. Is this the same issue as we had with placing NSAP nets in the DNS or are there fixed bounds on the RG part? If so, do the RG bits roughly equate to an RDI type of thing? -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 07:42:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA11994; Tue, 4 Mar 1997 07:36:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA11987; Tue, 4 Mar 1997 07:36:15 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04153; Tue, 4 Mar 1997 07:36:52 -0800 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA06292 for ; Tue, 4 Mar 1997 07:35:22 -0800 Received: from elmo.uu.net by relay5.UU.NET with ESMTP (peer crosschecked as: elmo.UU.NET [153.39.245.203]) id QQcfkw13647; Tue, 4 Mar 1997 10:36:54 -0500 (EST) Received: from elmo.uu.net (localhost.UU.NET [127.0.0.1]) by elmo.uu.net (8.7.5/8.7.3) with ESMTP id KAA00414; Tue, 4 Mar 1997 10:36:49 -0500 (EST) Message-Id: <199703041536.KAA00414@elmo.uu.net> To: bmanning@ISI.EDU cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 3141) Re: 2 faced DNS is here to stay In-reply-to: Your message of "Tue, 04 Mar 1997 06:41:52 PST." <199703041441.AA00607@zed.isi.edu> Date: Tue, 04 Mar 1997 10:36:49 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 384 we don't need to put the site-local version in the DNS it can be constructed from the other pieces ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 07:45:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12006; Tue, 4 Mar 1997 07:38:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA11999; Tue, 4 Mar 1997 07:37:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04640; Tue, 4 Mar 1997 07:38:30 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA06998 for ; Tue, 4 Mar 1997 07:37:00 -0800 Received: from gungnir.fnal.gov ("port 35695"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IG3M2HL5060004B6@FNAL.FNAL.GOV>; Tue, 04 Mar 1997 09:38:29 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA29953; Tue, 04 Mar 1997 09:38:28 -0600 Date: Tue, 04 Mar 1997 09:38:28 -0600 From: Matt Crawford Subject: (IPng 3142) Re: 2 faced DNS is here to stay In-reply-to: "03 Mar 1997 15:23:12 EST." <"QQcfhx06370.199703032023"@rodan.UU.NET> To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com Message-id: <199703041538.JAA29953@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ actually it's pretty easy. I think it's possible, but not quite that easy. > compare the prefix of the requestor to the (possible) prefix(es) of the > translation of the name If the original client consults a server which forwards the query to you, you don't have the correct information to do this. If you censor some data (equivalently, fail to include some data) on the basis of the address of the forwarder, the forwarder can't put that data back in. See my previous message for a scheme which is but slightly more elaborate. > if the requestor's prefix matches one, include the "site-local" version > in the response set with the highest preference Preference? This is something new. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 07:49:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12016; Tue, 4 Mar 1997 07:41:17 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12009; Tue, 4 Mar 1997 07:41:02 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA05509; Tue, 4 Mar 1997 07:41:40 -0800 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA08396 for ; Tue, 4 Mar 1997 07:40:10 -0800 Received: from elmo.uu.net by relay2.UU.NET with ESMTP (peer crosschecked as: elmo.UU.NET [153.39.245.203]) id QQcfkw16182; Tue, 4 Mar 1997 10:41:37 -0500 (EST) Received: from elmo.uu.net (localhost.UU.NET [127.0.0.1]) by elmo.uu.net (8.7.5/8.7.3) with ESMTP id KAA00470; Tue, 4 Mar 1997 10:41:37 -0500 (EST) Message-Id: <199703041541.KAA00470@elmo.uu.net> To: Matt Crawford cc: ipng@sunroof.eng.sun.com Subject: (IPng 3143) Re: 2 faced DNS is here to stay In-reply-to: Your message of "Tue, 04 Mar 1997 09:38:28 CST." <199703041538.JAA29953@gungnir.fnal.gov> Date: Tue, 04 Mar 1997 10:41:36 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 398 sorry - my mistake somehow in my mind i made dns consistent some things have preference, others don't sigh -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 11:57:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12536; Tue, 4 Mar 1997 11:50:23 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12529; Tue, 4 Mar 1997 11:50:12 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16268; Tue, 4 Mar 1997 11:50:48 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA03530 for ; Tue, 4 Mar 1997 11:49:21 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA08408; Tue, 4 Mar 1997 14:44:07 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13668; Tue, 4 Mar 1997 14:44:05 -0500 Message-Id: <9703041944.AA13668@wasted.zk3.dec.com> To: Cc: bound@zk3.dec.com, kre@munnari.OZ.AU, crawdad@fnal.gov, ipng@sunroof.eng.sun.com Subject: (IPng 3145) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Tue, 04 Mar 97 06:44:49 PST." <199703041444.AA00617@zed.isi.edu> Date: Tue, 04 Mar 97 14:44:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 893 >> Like using globally unique ESDs, having DNS use RG+ESD RRs and >> synthesizing them at the server. >Is this the same issue as we had with placing NSAP nets in the DNS >or are there fixed bounds on the RG part? If so, do the RG bits >roughly equate to an RDI type of thing? Yes. I envision the RG being its own record though and the ESD being its own record. This way one RG can be fabraicated or supplied as a global RG at the top zone maybe with other permanent RGs like the generic site local address. The trick is to synthesize them so its transparent to the query response to the resolver. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 11:57:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12527; Tue, 4 Mar 1997 11:50:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12520; Tue, 4 Mar 1997 11:49:53 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16169; Tue, 4 Mar 1997 11:50:29 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA03363 for ; Tue, 4 Mar 1997 11:49:03 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA29433; Tue, 4 Mar 1997 14:40:30 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13298; Tue, 4 Mar 1997 14:40:23 -0500 Message-Id: <9703041940.AA13298@wasted.zk3.dec.com> To: Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 3144) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Tue, 04 Mar 97 06:41:52 PST." <199703041441.AA00607@zed.isi.edu> Date: Tue, 04 Mar 97 14:40:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2036 Bill, > Here is an example so I can understand what folks want DNS to do: > > garcia.trip.dead.com IN AAAA 4F::ee:cd:aa:01:45:ff:ac:1e > IN AAAA FED0::ee:cd:aa:01:45:ff:ac:1e > > The first AAAA is a global provider based unicast address the second is > a site local address. > Humm... I had thought we had agreed to not put site-local > addresses in the DNS. > > but... if we do, how do we do the ptr mapping? Well another thing that happened at the Interim meeting was that it was suggested that DNS do a "whats your name" ICMP message to get the names for nodes when requested. This was once proposed by Bill Simpson some time ago. The other issue will PTR records be stored as they are today in the reverse mapped order? Bill this is not to you............. Also I am not taking seriously any messages to this list that sound like "handwaving" e.g. Well don't worry we will just make them work or they can be fabricated. What the heck does that mean. This is the I*Engineering task force. Can we please start using detailed technical responses instead of handwaving. Bill Manning is asking very important technical questions I think they deserver well thought out technical answers. I am board with all the handwaving going on of late on this list. I am not trying to be nasty but I can't just sit here and deal with the hand waving anymore. I know many others in the IPng wg feel as I do and have stated this to me privately. I am just the kind of person who will say it. Its OK to say > "I don't know how this would be done but what about this idea". THen we are discussing ideas which is fine but realize they need the test of will they work in an implementation and what will be the cost. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 13:44:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA12920; Tue, 4 Mar 1997 13:38:30 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA12913; Tue, 4 Mar 1997 13:38:18 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA14734; Tue, 4 Mar 1997 13:38:53 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA21193 for ; Tue, 4 Mar 1997 13:37:27 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA26931; Wed, 5 Mar 1997 08:36:11 +1100 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3146) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Tue, 04 Mar 1997 08:59:47 CDT." <9703041359.AA07391@wasted.zk3.dec.com> Date: Wed, 05 Mar 1997 08:36:08 +1100 Message-Id: <7521.857511368@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4756 Date: Tue, 04 Mar 97 08:59:47 -0500 From: bound@zk3.dec.com Message-ID: <9703041359.AA07391@wasted.zk3.dec.com> The interim meeting decided to not do GSE. Hmm - I'd go find and quote the bit from the ietf rules about meeting decisions needing to be confirmed on the mailing list, as if this meant what it seems to say I think I'd object. However I kind of suspect that that isn't what it means, so ... I hope we will see minutes soon. Me too. I also hope they'll give reasons, not just "the meeting decided..." or they'll be useless. But people did think we should do more where possible to make easier the classical renumbering problem at hand to be better solved. That's equivalent to "people like apple pie". Like using globally unique ESDs, Ah good. Next is how they're to be used.... having DNS use RG+ESD RRs and synthesizing them at the server. Ah yes, Matsataka Otha proposed this (approximately) in some WG or other a couple of years (or so) ago. I have (some time ago now) asked him to write a draft on it. Otha-san - get your keyboard out! Two-Face DNS was an issue that folks felt need to be discussed. But why? Just academic curiosity on how it could be done? That's just fine as a motive for those with an interest, but unless we have some actual use in mind where this would be required, I don't see the point of wasting a lot of WG time on it (expecially not in a non-DNS based WG where most of the people who really know the DNS and the issues that affect it don't hang out). Also can GSE be used to make existing provider based addressing more efficient. I don't understand that question. But the essential bottom line is rewriting of packets will not happen today in IPv6 as proposed in GSE. Ah, Ok, if that is what you meant by "decided not to do GSE" then I doubt there will be many objections. But as I said before (wrt the 8+8 draft) the rewriting part of all of this is a trivially minor point of the issue at hand. For some reason Mike chose to dress it up a lot in the GSE draft, and make it seem important. That part never was. There are two issues here that we need to consider - issues that really do matter, and which the GSE draft (and 8=8 before it) were also concerned with. The first is how the IPv6 address is constructed, and how the various parts are allocated. The second is what parts of the address (given the address must be used, as that's all there is) are used in higher level protocol pseudo checksums, and for connection identification. Those two issues are critical - the first because it will affect how hosts (especially) build the addresses in the first place (autoconf). The second because it affects the way the TCP/UDP implementations in the hosts will be built. Get those two set, and all the rest of the stuff can wait for later (years if necessary) and can be added incrementally, in fact will have to be added incrementally, as there'll be no way to make incompatible changes. Now we still can. In a later message you said ... Also I am not taking seriously any messages to this list that sound like "handwaving" to an extent I agree - but only to an extent. In some cases the details don't matter now - the reason for the handwaving is to attempt to show that doing things one way will prevent one style of future extension, whereas another way would not. Filling in the details at that point can be counter productive, for two reasons. One because it simply wastes time, and second, and more important, because it starts of a side track of argument about the intricate details of something only ever intended as an example. And finally, in yet another message ... That means at least 200,000 additional instructions executed per minute on a Server. (referring to adding some extra code into hosts). Jim - given your company makes hosts now that easily do 18 (US) billion instructions per minute, a cost of 200000 instructions per minute (or 1/1000 of one percent of the processor capacity) seems hardly worth worrying about too much - your average GUI frill wastes much more than that. (Base level PC's are getting towards that speed as well, by the time IPv6 is widespread, they'll be beyond it). Having the hosts's resolver do a little extra work so it picks an address that will have better long term stability seems like an excellent use of a few cpu cycles to me. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 14:55:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA12987; Tue, 4 Mar 1997 14:49:56 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA12980; Tue, 4 Mar 1997 14:49:49 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA05319; Tue, 4 Mar 1997 14:50:27 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA23064 for ; Tue, 4 Mar 1997 14:49:02 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA25234; Tue, 4 Mar 1997 17:39:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32167; Tue, 4 Mar 1997 17:39:17 -0500 Message-Id: <9703042239.AA32167@wasted.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3147) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Wed, 05 Mar 97 08:36:08 +1100." <7521.857511368@munnari.OZ.AU> Date: Tue, 04 Mar 97 17:39:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 784 Handwaving is handwaving... I don't agree with you. Its not of value when your down to the nitty gritty and some of think we are. Nothing else to say other than I really disagree with most of what you seem to support to the extent that your on one end of the polar coordinate and I at the other. Not a problem but I see no point in further discourse on this subject until the minutes come out. But if your going to use handwaving per the TCP/UDP discussion I will just delete your mail. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 4 22:53:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA13579; Tue, 4 Mar 1997 22:48:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA13572; Tue, 4 Mar 1997 22:48:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA09782; Tue, 4 Mar 1997 22:48:54 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA18981 for ; Tue, 4 Mar 1997 22:47:34 -0800 Received: from spruce.ipsilon.com (dialin2.Ipsilon.COM [205.226.3.242]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id WAA25258; Tue, 4 Mar 1997 22:48:49 -0800 Message-Id: <3.0.1.32.19970304224723.00739b7c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 04 Mar 1997 22:47:23 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3148) IPng Interim Meeting Minutes Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_857573243==_" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 29697 --=====================_857573243==_ Content-Type: text/plain; charset="us-ascii" Attached are the minutes for the IPng Interim meeting held on February 27 & 28 to discuss the GSE (aka 8+8) proposal. Overall the meeting went very well. The two days were spend reviewing and discussing the proposal in detail. The results of the meeting include a much better understanding of the issues regarding renumbering and many important improvements to IPv6. See the attached minutes for further detail. Bob __________________________________________________________________________ --=====================_857573243==_ Content-Type: text/plain; charset="us-ascii" IPng Working Group February 27 & 28, 1997 Palo Alto, CA USA Bob Hinden, Steve Deering Co-Chairs Meeting hosted by Allyn Romanow / Sun Microsystems, Inc. Many thinks to Allyn and Sun for this service to the IETF. The minutes were taken by Bob Hinden. ---------------------------------------------------------------------- ---------------------------------------------------------------------- Agenda ------- Thursday Introduction Review Agenda 8+8 Overview Detailed Review Uniqueness of ESD's DNS forward lookups DNS reverse lookups DNS Structure TCP/UDP Connection Identification Effects on Applications Rewriting of RG (inbound, outbound) Lunch Continuation of Detailed Review Map RG into current Internet Rehoming Site Multihoming Site Rehoming Multihomed Site Rehoming Small Provider Multihoming Small Provider Rehoming Multihomed Small Provider Summary of Discussions Friday Review Remaining Agenda Review impact on existing specifications Base IPv6 Specification Addressing Architecture Provider Based Addressing Documents Neighbor Discovery Address Autoconfiguration IPoverFoo ICMP Lunch New Documents which Need to be Written GSE Specification ESD Guidelines RG Allocation Impact on Implementations Summary and Conclusions Review of Agenda ---------------- Discussion about purpose of meeting and outcome of meeting. Possible outcomes: 1) Working group will not adopt GSE proposal. 2) Working group will adopt proposal. 3) Working group leaning toward adoption, but there important missing pieces that must be specified before the working group can make final the decision What problems is this solving? Suggestion was made to generate list of pro's and con's Problems being Solved / Mike O'Dell ----------------------------------- Goals and Non-Goals Goals: Thinks biggest problem in internet is complexity of routing computation in the backbones (where there are no default routes). Specifically, the cost of BGP computations increases as internet grows and policy issues become more complex. Thinks computation grow is exponential. Issue is that from a routing perspective the backbone is relatively flat. Why is this better than current provider based design? Current provider based topology schemes rely on renumbering sites to improve route computation. He thinks the aggregation model for provider based addressing has potential for catastrophic collapse. What could happen is that a few very large sites will refuse to renumber (i.e., lawyers go to court), and that will effectively stop everyone from renumbering. CIDR has worked well, but will not continue into the future. GSE deals with this problem by keeping changes resulting from renumbering the Internet local to edge of site, and keeps changes from propagating into the site. Internal routing infrastructure is isolated from external changes. Proposal allows backbone routing topology to change independently of sites without having to get the sites involved in. Advantage is allows backbone renumbering to happen independently from site renumbering. Allows Multihoming without increasing size of backbone routing. This is important because more and more sites are becoming Multihomed. Also helps second tier providers to change their first tier providers without forcing their customers to renumber (and potentially losing their customers). This is a very important benefit. Comment by Masataka Ohta: Doesn't think completely solves multihoming, but is a good first step. Non Goals: Does not solve mobility problem. Does not keep TCP connections alive during renumbering. It would be nice to have TCP connections survive loss of one connection when multihomed. Uniqueness of ESD's -------------------- 6Byte IEEE Mac's are proper subset of 8byte IEEE-1394 (firewire) addresses. Are they unique enough? Dimitry Haskin said he doesn't like using MAC addresses for ESD's. He would like something which has same properties of current IP address. Discussion about how most sites will use MAC, while still allowing sites to use something else if desired. Jim Bound thinks it is unique enough. ESD should be eight bytes long. Discussion about this. Thomas Narten: What are the consequences if there is a collision? Easy to detect on a link, but hard to detect globally. Steve Deering suggested that it is a relatively low probability event. We could later build in additional mechanism to help deal with this. Are IEEE1394 addresses compatible with SMDS addresses? Not an issue, SMDS addresses are E.164. Erik Nordmark: Think they are unique enough. Hinden: Thinks MAC address will be unique enough. He mentioned that MAC only addressing has been used successfully in large bridged networks and in large IPX networks. Also, IPX networks are mostly PC which is the area where there has been the most concern about duplicate MAC address. Bound: Do we have a consensus on uniqueness? Questions about systems (such as Sun's) which only have one MAC per Node? Long discussion. Group concluded that IEEE Mac addresses are unique enough to serve as globally unique ESD's. Does ESD need to have structuring? ---------------------------------- Masataka Ohta: Thought they should have structure for security. Discussion about this point, concluding that structure was not necessary for the purpose. Jim Bound: This all requires changes to DNS. Everyone agreed. He does not think there is a need for structure in an ESD. Assumption that to do reverse mapping is more difficult if there is not some structure in ESD. Discussion of this point. Discussion evolved into what are requirements for reverse mappings of ESD's. Alternative suggestion was made for ICMP "Who Are You" with ICMP "I Am XXX" message returning DNS name to perform this reverse mapping function. We will need manual defined ESD space, but this should be the exception. Most nodes will not need to use. Discussion about Adding Routing Goop Records to the DNS ------------------------------------------------------- Proposing to add "site names" to DNS. Would correspond to routing group for site. Could reverse lookup RG to "site name". "Site name" is not the same as DNS suffix. Important to only do connection identification using only ESD, not RG+ESD. This will allow future development of secure RG redirect later to improve transport behavior when RG changes. Assumption that site renumbering was relatively infrequent, not a frequent "real time" event. Discussion about use of RG as identifier for site and effects on firewalls. There will not be inverse lookups of IPv6 addresses! It will be replaced by ICMP "Who Are You" message. Matt Crawford raised issue about rate limiting "Who Are You" messages. He is concerned if senders don't cache answers. This could create a heavy load of "Who Are You" message. An alternative is to have the DNS servers send the "Who Are You" message when the receive a reverse mapping request. This seems to be a good idea. Rough consensus of the group is that ESD's do not need to have structure. Dimitry Haskin pointed out that for links which do not have MAC such as PPP serial links we can no longer auto-configure these links. ESD's for these links will have to be manually assigned. This is about the same as IPv4 operation today, but not as good as what the current IPv6 over PPP specification provides. Is this an acceptable limitation? Discussion about use of random numbers as ESD tokens. Are they unique enough, etc. Not much agreement on using random numbers as ESD tokens. Mike O'Dell Presentation on Multihoming ------------------------------------- Provider Provider 1 2 +----+ +----+ | | | | | | | | |PBR | |PBR | +--x-+ +-x--+ | | RG1| | RG2 | | +--x-----x--+ | SBR SBR | | | | Site | +-----------+ If RG1 link fails, then Provider PBR tunnels traffic which would have been sent to the site via RG1 and sends it to the Provider 2 via RG2. Requires that both PBR in site 1 & 2, and SBR's understand that tunnel has been created. If TCP saves RG when SYN packet is received for connection, and never switches to RG received in subsequent packets, it can protect against it's connections being hijacked. Long discussion, even more complicated pictures and scenarios. Hinden asked question of how this was different/better from what can be done with current IPv6 specifications. Not clear what the win is here for multihoming. Erik Nordmark made observation that if node remembers all of the RG's returned from the original DNS lookup, then it would be OK for it to switch to one of the returned RG's if packet started arriving from a different one. Rebecca Nitzen talked about how in this scheme it will be very easy to load share multihomed site. Traffic in both directions will follow the same route. The only thing necessary to do is divide the primary default between the ISP connections. Might also be possible to return DNS replies for the site to divide the load by replying with the appropriate RG based on where the requester is. TCP/UDP Connection Identification --------------------------------- Pseudo header checksum always use ESD. Do we require all unicast to work the same way? Yes. OK for provider addresses which been autoconfigured. Important to require all addressing plans to have same characteristic. How about multicast addresses? Include an ESD? Discussion about what to do when node starts receiving packets with new routing goop. When node does not have any other information, node should drop packet. If node thinks the new routing goop is valid (perhaps by having received it in original DNS lookup) then it can reply and start sending to new Routing Goop. Need to look at what happens if routing goop is corrupted? This needs analysis to access the impact. Long discussion about if some of the RG could be included in the checksum. Allison proposed having the host include it's RG in checksum. Not clear how source node would get RG. Makes rewriting RG on in bound traffic impossible (?). This could be viewed as a hybrid proposal. Mike O'Dell suggested that TCP should not bind to a particular RG for remote side until three way handshake is completed. General comment made that it is important that this proposal not change TCP protocol. No TCPng!!!!!! Long discussion about what happens if RG is corrupted. Worst case is when first SYN packet is corrupted because connection will never be established. Erik Nordmark asked would implementing this architecture make it harder to make changes to TCP later in the future? What is the effect of hiding RG from the host? Matt Crawford proposed that we continue to rewrite RG, do not include RG in pseudo checksum, non-established TCP treat packets with different RG as different connections, for any UDP or TCP in established state pass all packets to application, connected socket for any transport do not update outgoing RG address. Long discussion about connection identification, checksums, what happens when RG changes, etc. Jim Bound stated that renumbering while important was it was not the top of the list of what his customers wanted. --------------------------------------------------------------------------- Friday --------------------------------------------------------------------------- Introduction to meeting. Today will continue detailed review of proposal. Start with DNS issues. Continue to work through the list: Uniqueness of ESD's DNS forward lookups DNS reverse lookups DNS structure (effect on caching, performance) TCP/UDP Connection Identification Effects on Applications Rewriting of RG (inbound, outbound) Effect on V6 mobility, multicast, anycast DNS Forward lookups ------------------- What if site is multihomed, does requester get multiple DNS entries? Two-Faced DNS Solution: Remote DNS are sort of part of local universe, so they need to know site RG and provide appropriate answer. Jim Bound: Thinks the split between RG records and AAA will work. Suggested list of topics to discuss on DNS: - Boot strapping DNS delegation records - How do replies get fabricated - What new record Types - Two faced DNS - Dynamic Update to RG (for renumbering) Boot strapping DNS delegation records ------------------------------------- Need to have hard coded address of DNS servers. For example to get to foo.sun.com, .com server needs to have address of ns.sun.com. This is way IPv4 works today. Discussion focus on making DNS servers have addresses which are not renumbered. This should work as long as there are not too many DNS servers. Need to update DNS servers when RG changes. Likewise this is essentially the same as IPv4 and a general IPv6 issue not specific to this proposal. When site renumbers, it must change it's DNS servers. When an ISP renumbers it must make it transparent to sites. O'Dell suggested that if DNS servers get RG info from routers this could be made easier. Problem could be made less severe if the top level name servers had addresses which were not renumbered. We could support some amount of non-renumbered addresses for important servers. Important to identify where in DNS there are hardwired addresses. Thomas Narten: This is a generic point about renumbering. Not specific to this proposal. What new record Types ------------------------------ RG Record AAA (Deering suggested calling it "aAA") How do replies get fabricated ------------------------------ Matt Thomas suggested that AAA record be split into Subnet + ESD record (AA) Matt Crawford agreed this would be a good idea. We do need a site record for RG? General conclusion that splitting the DNS records was a good idea even if proposal not adopted in whole. Two Faced DNS ------------- Server has to have information to know what kind of reply to send. If RG of source address from request is same as RG which was to be in the reply it should substitute site local RG. Matt Crawford described a problem where DNS queries are forwarded between servers, RG will be lost as request goes between sites and backbone and this will not be work. General conclusion that these topics needs an owner to describe how all of this works. Dynamic Update to RG (for renumbering) -------------------------------------- Decided this was a future need and was not required now for this proposal. Effects on Applications ----------------------- - Prohibition of Storing non-refreshed non-ESD addresses. Not specific to this proposal. General renumbering (and transition to IPv6) issue. - Use only ESD for peer identification (not address) - Avoid carrying addresses in payload - Flow identification. Probably need to only use ESD instead of whole address. - Effect on reassembly - All packet identification needs to use ESD's - Effect on routing header? If RH is to be replied then BR would have to fix up RG inside of RH. This happens on both first exit BR and final BR. Not clear if it is important to make source routes RH reversible. Border router (which may not be one of the SR hops) will have to know to look inside of RH to rewrite appropriate RG's. Might be better to embed DNS names in packets because they are global and can be looked up. Comment that overall this adds complexity for programmers. They would need to have good understand of RG, subnet, ESD's, addresses, and how they interact.. Prior to this proposal they only need to understand addresses. - Effects on tunnels. If tunnel crosses site boundary, end points must perform BR functions. Which router does rewriting? Long discussion on how this works. End point of tunnel needs to be able to rewrite destination RG w/ site prefix. Host-Host secure IPSEC tunnels require hosts to be able to recognize that the RG (actually it's own) is one of it's interface and accept the packet. Anytime you tunnel it in effect requires all tunnel end points to be border routers. They need to be able to rewrite RG on exit and entry. Renumbering breaks all configured tunnels. - Addresses in MIB's and Address in SNMP Traps. Makes it harder for agents. - ICMP error messages. Returned packet has packet with error. Need to only look at ESD to match error reply. Steve Deering's fortune cookies from lunch ------------------------------------------ "A thrilling time is in your immediate future" "Avert misunderstanding by calm, poise, and balance" "He who hurries cannot walk with dignity" "If your desires are not extravagant they will be granted" "Simplicity and clarity should be your theme in dress" "Strong and bitter words indicate a weak cause" "The best prophet of the future is the past" "The laws sometimes sleep, but never die" "Time is precious, but truth is more precious than time" "What's vice today may be virtue tomorrow" "Wise men learn more from fools, than fools from the wise" "You have a quiet and unobtrusive nature" "You will be recognized and honored as a community leader" TCP Connection Identification / Matt Crawford --------------------------------------------- If checksum doesn't cover RG, and we want to accept packets from different RG's, there are a few problems. Short of full authentication is not acceptable and doesn't cover many problem cases. Propose Set of Rules: 1. Accept any source RG on incoming packets and deliver to application. Only use ESD for this. 2. For Active TCP "Open" and all UDP: Application specifies destination RG. Do what application says. 3. For Passive TCP Open: Always use the First RG you saw. Based on 3., if source RG is corrupted connection will never open. Application will have to try new connection with different port numbers. Corrupted destination is not a problem. Packet will be misdelivered and discarded, retransmission will get to correct site, connection will open. Because never switching RG, multihomed connection will be broken if RG changes. Also applies to rehoming. The approach does help when there are two different RG exit paths and routing changes which causes a different RG to start being used in the middle of the connection. Nordmark noted that this makes connection identification easier than existing IPv6 because only need to look at ESD instead of list of possible addresses. Also suggested that it might be worse because sender doesn't know anything changed. Future transports could be developed which allow complete separation of RG and ESD which had other connection identifications mechanisms, authentication, etc. Conclusions ----------- Deering asked group for their overall impression of what people think now Mike O'Dell: He draws several conclusions: Thinks it is unreasonable to move forward with the current proposal. Thinks there are a number of things which are worth pursing. There are a bunch of pieces which we think we should do. This has really pushed our thinking about what it means to renumber. Most of hard questions dealt with impact of renumbering. He is perfecting willing to not go forward with his as main proposal. Thinks we should see what we can extract and move forward. Steve Deering: Can we still get some of these advantages with current scheme? Mike O'Dell: Long term requirement is to control aggregation topology independent of getting sites to participate. That was the fundamental goal. This proposal does not enable this in toto. Still other things which need to be done. Questions is what pieces should we take? Jim Bound: Likes some of the parts of GSE, does not like some of current parts of provider based addressing. There are lots of pieces here which are improvements. Main thing didn't like was the renumbering approach. Dimitry Haskin: Agree with Mike that at this point proposal is not deployable. Too much risk involved. When meeting started he thought it was feasible, but now thinks it is not possible. Should we continue working on proposal as research project? Not practical for deployment now. Could have a transition mechanism. Lixia Zhang: Thinks fundamental problem is renumbering. DNS still needs work. Charlie Perkins: Agree this is too much definition to be done in time for IPv6 deployment. Likes separation of address into ESD and locator. Might make other problems easier in the future. John Stewart: Advantage he sees of independent of rewriting packets is aggressive aggregation. This proposal does it by rewriting of addressing. Wondering if there is a middle ground with provider based addressing but changing with [???] Take best pieces of each approach. There are lots of subtle transport issues that we may not understand yet. Mike O'Dell: Believes that large structure proposal used is a much better model for aggregation than provider based addressing. Margaret Forsythe: Thinks the addressing part is inherently useful. Could have something like this, but do not need to take full advantage of this now. New transport protocols could take advantage of protocol. Allison Mankin: A lot of the attractions are ones which are ones which we have been striving for in the IPng area. Thinks would be a shame if we didn't pursue this. Thinks we should pursue some parts of GSE in transitional way. Erik Nordmark: Thinks it would be useful to take advantage of ESD's. We could use for connection identification. Bob Hinden: Suggested that it is good to require an ESD in all addresses. This may have advantages for multihoming (sites and nodes) and permit new transport protocols to be developed which take full advantage. Jim Bound: Will put out draft why renumbering is not important. Location and identification is not going to work for a long time. John Stewart: Ramification of large routing tables along with increase with things like multihoming. Reasons why we now need to aggregate from leaf up. Single homed sites do not need any information about routing (just default), they don't much want any pain to renumber. We should put the work of renumbering in places which need flexibility. Multihomed sites. Alex Conta: Thinks current provider based addressing scheme is good. Reason we thought that provider based scheme was thing to do, because we thought there would be problems with separate identification and location. We now have a better view of the costs of renumbering. We should document this. Cost to site, provider, etc. Could also conclude the multihoming problem is not solved by node-id and locators. GSE did seem to provide better form of aggregation. We should continue looking for better forms of aggregation. Conclusions we draw today are the high costs for using GSE to improve aggregation. Dimitry Haskin: Does not like requirement to make ESD in all addresses. He is opposed to this. Thinks price of administration is too high. Matt Thomas: Like the ICMP "Who Are You" message and putting it in DNS server. Dan Harrington: Renumbering is hard, we now know better. Need support to support multihoming without breaking aggregation. Matt Crawford: Hope that by 3:30pm we will list topics to pursue. For now have the sense of the room but thinks that it is something that is worth going forward with but don't have time to fully pursue. Should do a few small things now to allow options later. Possibilities: - PCB Lookup Rules - Pseudo checksum rules - "Who Are You" you message - 8 byte node id - Two faced DNS ? O'Dell added: - Split records in DNS - Revisit provider based addressing model. Problematic. - Minimal address is to split Steve Deering: Keep term "Routing Goop"!!! Erik Nordmark: Argument to make two faced DNS is to isolate site from changes would be to return site local addresses in site to site local communication. Reduces the risk of a failure of renumbering from disrupting site communication. Allison Mankin: Should remove "registry" field from provider based addressing. We can work to improve this. Steve Deering: TCP depends on it's weak security by depending on address providing both location and identification. TCPng could do different things which allow separation. Jim Bound: Seconds large structure internet draft. Provider based document was compromise. Thinks we can do better. Agrees about TCP weak security. Bob Hinden: Suggested that if connection identification is limited to ESD and pseudo-checksum covers full addresses (essential providing packet integrity) that it would be easier to support multihomed sites and nodes. TCP would then accept packet sent from any interface of multihomed node and/or received on any interface, but avoids the problems relating to corrupted source addresses. Masataka Ohta: Hope that many things can be made to work with GSE. Would like pursue as an informational RFC. Thomas Narten: Will need a two faced DNS if we are using site local addresses. Allison Mankin: There should be work done to develop a new transport which could just work with ESD's. Next Steps ---------- Steve Deering broke out parts of proposal to see what parts the working group could move forward. Node ID: Change from 6 bytes to 8 bytes. This would break provider based addressing documents. Discussion about keeping 6byte MAC or expanding to allow 8 bytes. Deering polled group. Most people thought we should change to make room for 8byte MAC. Brief discussion and poll to put structure in ESD's to allow lookup. Strong consensus to not add structure to ESD's. Group initially agreed that low order 8 bytes would be required to be globally unique. This will make it harder for links without built in MAC addresses. More discussion. Now less clear that there is a consensus on making ESD globally unique. Conclusion is to review the ESD issue at the Memphis IETF. We need more data before we can make a final decision. RG Structure: General agreement to rewrite provider based addressing specifications. We can make a number of improvements. PCB look up rules: Document now, but decision depends on making globally unique ID's. Also applies to flow identification, fragment identification, etc. Checksum: Don't change pseudo checksum algorithm. Will continue to include full IPv6 source and destination addresses. Two faced DNS is useful for site local address. Work on how to use site local addresses for intra-site communication. Summarized into the following table: Legend: X = do not adopt Y = adopt * = needs more study X Rewriting by routers X Name for Sites & Mapping to/from RG * ESD's Y RG structure * PCB Lookup rules X Pseudo checksum rules Y 8byte node ID Y Two faced DNS for site local Y Resolve DNS via ICMP "Who Are You" Y DNS response synthesis * Auto-Injection of prefixes into sites Y Inter-provider partition healing protocol(s) * Use only site-local prefixes for intra-site communication * How much of address is AH * Flow identification change * SA Ident change Actions Items for Memphis ------------------------- 1. Minutes for this meeting, and meeting report / Bob Hinden 2. "WhoAreYou" ICMP Message / Matt Crawford 3. Modify Link Name Draft / Dan Harrington 4. Synthesized AAAA Replies / Jim Bound , Mike O'Dell 5. Revised Provider Based Addressing and Addr Architecture / Mike O'Dell and Bob Hinden 6. Unique ID's (ESD's) Assignment, Mike O'Dell, Allison Mankin, Matt Thomas 7. Experimental Addresses Rewrite: Bob Hinden 8. IPoverEthernet/FDDI : Matt Crawford 9. IPoverPPP: Dimitry Haskin 10. Lessons from meeting: Thomas Narten, John Stewart, Allison Mankin, Lixia Zhang, Matt Crawford Work We Think Other People Should Do ------------------------------------ 1. Non-corrosive multihoming of sites (partition homing) 2. Auto-aggregation of public topology 3. Auto-aggregation of site topology 4. Auto prefix dissemination in site 5. Auto prefix acquisition by sites 6. DNS vs. Renumbering Meeting End ----------- Next meeting will be at the Memphis IETF. Sessions are schedule for Thursday and Friday. --------------------------------------------------------------------- --------------------------------------------------------------------- --=====================_857573243==_-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 02:55:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA13729; Wed, 5 Mar 1997 02:50:31 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA13722; Wed, 5 Mar 1997 02:50:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA15126; Wed, 5 Mar 1997 02:51:00 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id CAA15188 for ; Wed, 5 Mar 1997 02:49:39 -0800 Received: by mail.noris.net id <35135-756>; Wed, 5 Mar 1997 11:52:23 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3149) Re: Comments on GSE Date: 5 Mar 1997 11:50:36 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 43 Message-ID: <5fjj5s$30d$1@work.smurf.noris.de> References: <882.857005802@munnari.OZ.AU> <19970227024649.11884.qmail@mail.ocs.com.au> <857012330.4951@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1409 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2255 Keith Owens writes: > On Thu, 27 Feb 1997 12:10:02 +1100, > Robert Elz wrote: > > Even if the secrets are true public keys, if Mallory is on a router > between Alice and Bob, he can still intercept the initial handshake and > substitute his public key in both directions. Without a key registry, > neither Alice nor Bob can tell that they are talking to Mallory instead > of each other. Once again Mallory can send redirect messages and > highjack the session. If M is in fact a router between A and B, it doesn't need to send any redirect messages. It can just redirect all packages from B to /dev/null and impersonate B directly. > There is also the overhead of generating a true > private/public key set for each connection. > You don't really need one. All you need is a random number. On initial SYN, send an option with the MD5 of that number. On renumber, send the number itself. The destination host can verify that you are you by simply MD5ing the random number and comparing. In fact, once the recipient knows that MD5 key (end-to-end option of the first packet sent to the destination), any renumbering can be done with an ICMP message when a packet with the old RG is received. Obviously, a redirect message also needs to contain an MD5 of a new random number so that the _next_ redirect can be processed in the same manner. NB: All of this depends on the fact that hosts know their RG and, know when it changes. I don't think there's any way around this. -- Can I have an IMPULSE ITEM instead? -- Zippy the Pinhead -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 06:49:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA13941; Wed, 5 Mar 1997 06:44:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA13934; Wed, 5 Mar 1997 06:44:34 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA18679; Wed, 5 Mar 1997 06:45:11 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA11151 for ; Wed, 5 Mar 1997 06:43:56 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA30347; Wed, 5 Mar 1997 09:35:40 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14215; Wed, 5 Mar 1997 09:35:37 -0500 Message-Id: <9703051435.AA14215@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 3150) Wisdom from a Production User Date: Wed, 05 Mar 97 09:35:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2848 I received the attached from a customer who is a customer for many on this list too. It is imperative after Memphis that we fast-track any update to "an" IPv6 addressing plan that users can use today and that the 6bone can migrate too that will make it part of the Internet to start IPv6 deployment. I think we have done a good job to test out the core specs and new specs are moving now to add to that core. A lot of folks are sitting at connectathon right now testing IPv6 on that track. I think if we can nail down an addressing plan that will appease more than the present one and avoid the art of "compromise" users will be able to do what this users deems important. I think we can and it is in the same spirit of what I have heard from all customers wanting to use the larger IPv6 address space and all the new technology features of IPv6 for networking. But I think we all need to be cautious on two points: 1. Don't use DNS as a dumping ground for what we cannot solve, and whether we like it or not BIND is the pervasive implementation of DNS and tweeking it can be very dangerous so we need to be smart and detailed what we want do and then make sure again. I am in that code almost daily determining the best way to integrate with stateless addr conf and DHCPv6, and I think its the largest Internet application in the industry as far as lines of codes and complexity. We need to be very careful. 2. In July 1993 at the IETF Amsterdam meeting (we should have another meeting there I love that city) at an IPng BOF, Vint Cerf cautioned us as a very Sr. Member of the Tech Community to understand that part of why the Internet is successful, is because in its engineering design cost was part of the trade-off process. /jim ------------------------------------- Subject: No waves Jim, One still does not know how to design addressing for any network using IPv6. One still does not know what to request from the NIC (or ARIN, or whatever). One can't design a network with handwaving - One needs standards and procedures, preferably that have been tested and shown to work. Until a network designer understands the relationship between network topology and addressing, no successful network design can be done. On a personal note, I cannot fathom the answer to the relationship question from either "8+8" or "GSE". I also question the wisdom of anything but modest changes in BIND and resolver code. ------------------------------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 07:37:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13980; Wed, 5 Mar 1997 07:31:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13973; Wed, 5 Mar 1997 07:31:46 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06334; Wed, 5 Mar 1997 07:32:24 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA28660 for ; Wed, 5 Mar 1997 07:31:02 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfon01862; Wed, 5 Mar 1997 10:29:44 -0500 (EST) Message-Id: To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 3151) Re: Wisdom from a Production User In-reply-to: Your message of "Wed, 05 Mar 1997 09:35:36 EST." <9703051435.AA14215@wasted.zk3.dec.com> Date: Wed, 05 Mar 1997 10:29:43 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 645 Jim, i appreciate the enthusiasm of "early adopters", but anyone who is contemplating putting IPv6 (from anyone) into "production" any time soon is playing with fire in a fireworks factory. encouraging people that this attitude is anywhere close reasonable is doing *everyone* a disservice. it will blow up in our faces and discredit IPv6 when it does. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 07:46:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13991; Wed, 5 Mar 1997 07:40:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13984; Wed, 5 Mar 1997 07:40:26 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA09406; Wed, 5 Mar 1997 07:41:05 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA02282 for ; Wed, 5 Mar 1997 07:39:49 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA07430; Wed, 5 Mar 1997 10:28:12 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24060; Wed, 5 Mar 1997 10:28:08 -0500 Message-Id: <9703051528.AA24060@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 3152) Re: IPng Interim Meeting Minutes In-Reply-To: Your message of "Tue, 04 Mar 97 22:47:23 PST." <3.0.1.32.19970304224723.00739b7c@mailhost.ipsilon.com> Date: Wed, 05 Mar 97 10:28:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3914 Bob, Thanks for the timely minutes this is great... On the statement of a draft I will write why renumbering won't work in the minutes. I want to clarify what that statement means to me, the effort, and propogation of the effort. I think in the IETF we have determined that renumbering is important and for some cases the idea of rehoming (keeping connections across dynamic renumbering and moving complete networking state between nodes). But, the first need customers have is to get IPv6 as soon as possible so it can be deployed and implemented to give them more address space and access to the new features of IPv6. So if solving the classic renumbering problem will hold up IPv6 for even 1 year then that is not good and an alternative strategy is needed to accomodate renumbering. Also security, performance, and ease of use cannot be sacrificed for renumbering. And most of all it cannot cost a lot more either in administration or as a direct result of increased cost from vendors. What I am going to develop is a "White Paper" on the networking and implementation problems with renumbering and write it mostly as an engineer as opposed to a pure architect. It will depict the problem states and the changes to resolve those problem states, but also depict the implementation changes to solve those problem states. I will also depict how IPv6 resolves many of these problems at the site via Stateless Addr Conf, DHCPv6, Dyn Upd to DNS, Router Renumbering (need your draft at Memphis if possible), Multihoming, Dyanamic Reassignment of Addresses to Support Rehoming, etc. etc. So it will state the problem and then state where IPv6 can fix it and what else needs to be done. I will in this work define a mechanism for auto-injection of prefixes from an ISP to a site, which I have been complaining about since big-i four years ago, so I am just going to develop a solution for study. I did not say it would be a draft and thats fine if it is. I plan on delivering this work to the IETF at the Munich meeting in Aug 97 and present it as a technical presentation to the entire community. I intend to have a co-author and have name in mind from the PIER effort in the IETF if they will accept and can do this work with me. If after this the IETF believes this is a worthwhile Info RFC thats fine with me. Also I have no more time to join other mail lists or other IETF efforts so I will run this by IPng WG. But, regardless this work after Aug 97 will be used for Industry education at Trade Show tutorials-talks, as input to the U.S. Government Internet Task Forces at hand to have a complete vision of the Internet, or for Internet/2 project, or whatever. This entire space is completely misunderstood and needs to be clearly articulated what the issues are and the effect to the Internet. It will also clearly articulate why anyone wanting to seriously do the Internet into the next century will want IPv6 and want it now. I believe for the Internet to become a "dial-tone" in the next century renumbering is important, but not as has been proposed in my opinion of late. The bigger issue is autoconfiguration and autoregistration. Thats why stateless addr conf is not done without DHCPv6 and Dynamic Updates to DNS to make autoregistration complete, as I have argued since the inception of the IPng Directorate (this is in response to the DHCP bashing that took place at the interim meeting I claim those who do it in IPv6 just don't get it). So what I am not going to do is hang out in the IETF for two years chasing handwaving exercises that have nothing to do with solving the problem. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 08:53:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14128; Wed, 5 Mar 1997 08:44:56 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14121; Wed, 5 Mar 1997 08:44:49 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23590; Wed, 5 Mar 1997 08:45:27 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA00113 for ; Wed, 5 Mar 1997 08:44:11 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA16531; Wed, 5 Mar 1997 11:20:03 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26366; Wed, 5 Mar 1997 11:19:57 -0500 Message-Id: <9703051619.AA26366@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 3153) Re: Wisdom from a Production User In-Reply-To: Your message of "Wed, 05 Mar 97 10:29:43 EST." Date: Wed, 05 Mar 97 11:19:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5359 Mike, >i appreciate the enthusiasm of "early adopters", but >anyone who is contemplating putting IPv6 (from anyone) into >"production" any time soon is playing with fire in a fireworks factory. Presently all kits I know of for early adopters state that the IPv6 stack is for testing and anlaysis of IPv6, and cannot be used in production networks "right now". So there is no fire here at all. But IPv6 is in "field test". I believe that field test needs to go on for the next 12-18 months. Then deployment will begin in one of several manners. IPv6 NAT will be deployed so users at sites can begin to use IPv6 internally to take advantage of the address space and new features of IPv6. IPv6 will be used by some ISPs on the edges and translate IPv4 to IPv6 building new backbones btw themselves with IPv6. I have heard this from Europe and Asia, and a few small ISPs in the U.S. Depending on the aggressiveness of the vendors things could begin to happen just before the 12 month window. I believe some ISPs may even provide home users and some others a better rate on their connection if they will begin to use IPv6 addresses, but that means that the core Internet Applications need to be ready (e.g. FTP, Telnet, PPP, PING, WWW Browser, etc.). So there are multiple deployment scenarios and work to do. I could put FTP Software stack on my PC at home now and do IPv6 as a note if I had an address. >encouraging people that this attitude is anywhere close reasonable is >doing *everyone* a disservice. it will blow up in our faces and >discredit IPv6 when it does. I am encouraging the people and the industry to start field-test. That is critical. For vendors, ISPs, and NAPs. I believe those doing it now will reap the benefits "first" from IPv6 as users, vendors, ISPs, or whatever. If one wants to sit it out that is fine. The key to capitalism and leadership is risk, tempered with "common sense". No one is not using common sense. But I also feel many in the IETF are simply not educated about what IPv6 can do. Such as the use of valid and preferred timers for addr conf and DHCPv6. These are very powerful variables that permit serious renumbering at the link and site , with network administration and common sense. Do I think we should not deploy IPv6 until all the admins tasks are automated? Absolutely NOT. I know this first hand will work cause I have implemented and tested it and so far that code and function has held up at 3 interoperability events. Now to add DHCPv6 and Dyn Upds to DNS. So I hope my intentions are clear from the above and enthusiasm as you put it. Though I don't think it is as much as enthusiasm as I get off on things being shipped and used more than abstractions. But also while your giving me this admonishment. I would like you to do the same to all the Internauts who have proposed and supported anything and everything to slow down IPv6. A lot of what I do is to counter those threads in the IETF and I intend to do so continuously. I am told I am doing a good job of that too. This entire effort is proceeding well as a standard project at this point: 1. Generation of ideas and architecture. We have some of the brightest people in the 'world' working on IPv6 and expanding the Deering/Hinden model of the core IPv6 architecture. I also believe that a lot of the slow down of IPv6 is from people whose ideas for IPng were simply not chose )--> sour grapes. I have no time for that personally. 2. Implementation of those ideas in leading vendor products. 3. Testing of the IPv6 core architecture and implementations on the 6bone and at the UNH Interoperability events and now Sun Connectathon this week. 4. Excellent implementors working with the architects to verify implementation/architecture needs/tradeoffs aree defined. 5. A market that is clearly developing for several reasons because of address space exhaustion, routing table inefficiency, autoconfiguration/autoregistration, and IPv6 is just superior to IPv4 in all aspects. Security is mandatory for one thing. Also many large users are evolving to a new Internet model and in the process of design and architecture revision to their networks. It would not be prudent to not plan on IPv6 tomorrow at these user sites. Thus why many of us are getting calls to leave engineering and come discuss IPv6 (which is real killer until we get our field personel trained to do this). 6. Real customers and users on this mailing list and in the market beginning field-test of IPv6. The Early Adopters. 7. Unit/System test is integrated and pursuing well. So its in process and moving well. Its not done but it is close so I don't probably agree with you what "soon" means. But no one including me is saying its completely ready yet. I think the additions to our addressing plan from GSE need to be incorporated to make a solid plan users can use to define their network design. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 08:55:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14137; Wed, 5 Mar 1997 08:46:31 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14130; Wed, 5 Mar 1997 08:46:22 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23949; Wed, 5 Mar 1997 08:47:00 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA01017 for ; Wed, 5 Mar 1997 08:45:45 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA18064; Wed, 5 Mar 1997 11:39:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA04304; Wed, 5 Mar 1997 11:39:35 -0500 Message-Id: <9703051639.AA04304@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3154) IPv6 and Printers and Toaster-Net Date: Wed, 05 Mar 97 11:39:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1506 Yesterday I spoke with a printer engineer about IPv6. Yikes this will take some doing for printer firmware to get to IPv6. Is there any work we need to do in the IETF other than the IPv6 mibs? Today most printers use bootp (yuck...) but with IPv6 the use of multicast and a site local address should be advantageous in addition the printer can create a link-local address but that don't help getting to the printer from off the link. I am not sure a printer can afford a complete stack for IPv6 to do ND and hear RAs. Sooo...hhh this gets to what in the IPng Directorate came up as "Toaster-Net". Do we need a lightweight protocol for Toaster-Net for IPv6. DHCPv6 client would be a lot too and assumes an upper layer stack and UDP so that I think is a non-starter. For initial deployment the printers can use private v4 addresses via the hybrid IPv6 stack machines. But this means we all still have to mess with bootp. We have gotten rid of it in DHCPv6 and I think we need a lightweight toaster-net protocol architecture defined for discussion maybe? Any takers on the list who have the time to work on this? And I can help at least to discuss the "model" we used in DHCPv6 to get it started? ??? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 08:56:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14146; Wed, 5 Mar 1997 08:46:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14139; Wed, 5 Mar 1997 08:46:38 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24011; Wed, 5 Mar 1997 08:47:17 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA01136 for ; Wed, 5 Mar 1997 08:46:02 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfot26577; Wed, 5 Mar 1997 11:47:13 -0500 (EST) Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 3155) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Wed, 05 Mar 1997 10:28:06 EST." <9703051528.AA24060@wasted.zk3.dec.com> Date: Wed, 05 Mar 1997 11:47:13 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 515 one of the reasons we talked about splitting the records in the DNS (and synthesizing AAAA responses from the pieces) is that it dramatically reduces the requirements for DNS Dynamic Update and the attendant security botches. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 08:57:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14155; Wed, 5 Mar 1997 08:47:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA14148; Wed, 5 Mar 1997 08:47:20 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24156; Wed, 5 Mar 1997 08:47:58 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA01440 for ; Wed, 5 Mar 1997 08:46:44 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA09634; Wed, 5 Mar 1997 11:42:32 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03947; Wed, 5 Mar 1997 11:42:30 -0500 Message-Id: <9703051642.AA03947@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3156) DHCPv6/Exts Drafts to Last Call soon Date: Wed, 05 Mar 97 11:42:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 557 Charlie Perkins and I are ready for last call and check out if we can get to PS for the following. The work and discussion will be on dhcpv6 list. But wanted you to know our status. The latest drafts are: draft-ietf-dhc-dhcpv6-09.txt draft-ietf-dhc-v6exts-05.txt /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 10:43:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14484; Wed, 5 Mar 1997 10:38:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14477; Wed, 5 Mar 1997 10:37:53 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA20037; Wed, 5 Mar 1997 10:38:31 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA20963 for ; Wed, 5 Mar 1997 10:37:16 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfpa25626; Wed, 5 Mar 1997 13:35:47 -0500 (EST) Message-Id: To: "James R. Cutler" cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 3158) Re: we need it.... In-reply-to: Your message of "Wed, 05 Mar 1997 13:05:04 EST." Date: Wed, 05 Mar 1997 13:35:47 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1237 i understand your situation. IPv6 has a lot of good things to want. that doesn't change the fact that anyone planning deployment using the current state of "bakedness" as a foundation is playing with fire. no way in the world can you be told anything that can provide anything like a reliable basis for large-scale plans. it's just too early and too little is understood at this point. and it's *very* important to fix the problems as they are uncovered in the field trial before things get frozen. the lack of aggrability in the current "provider-based addressing" plan is a good example of something which has to be fixed or it will surely strangle us long-term. as for frozen, IPv6 ain't even cool. i'm sorry if this is bad news, but better you deal with it now and adjust your expectations. field trials with disposable systems? sure thing. have at it; experience needed and required. anything else, though, is asking for big trouble. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 10:56:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14518; Wed, 5 Mar 1997 10:50:30 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14511; Wed, 5 Mar 1997 10:50:26 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03143; Wed, 5 Mar 1997 10:51:04 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01812; Wed, 5 Mar 1997 10:50:32 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14463; Wed, 5 Mar 1997 10:14:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14401; Wed, 5 Mar 1997 10:15:31 -0800 Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA11246 for ; Wed, 5 Mar 1997 10:14:18 -0800 Received: from nnsp.eds.com (nnsp.eds.com [130.174.32.78]) by ns2.eds.com (8.8.5/8.8.5) with ESMTP id NAA24747; Wed, 5 Mar 1997 13:15:32 -0500 (EST) Received: from [130.175.183.223] (netmac.iscg.eds.com [130.175.183.223]) by nnsp.eds.com (8.8.5/8.8.5) with ESMTP id NAA16752; Wed, 5 Mar 1997 13:14:53 -0500 (EST) X-Sender: jcutle01@info1.iscg.eds.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Mar 1997 13:05:04 -0500 To: "Mike O'Dell" From: "James R. Cutler" Subject: (IPng 3159) Re: Wisdom from a Production User Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1393 Mike, You said, in part, >i appreciate the enthusiasm of "early adopters", but >anyone who is contemplating putting IPv6 (from anyone) into >"production" any time soon is playing with fire in a fireworks factory. I certainly fall into the category of "production user". Possibly some parts of EDS (test groups) will fall into the category of "early adopters". All this is fine. However, as the quote from the "Production User" alludes to, the question of network design well in advance of deployment is critical. As Corporate Registration Authority for several hundred thousand end systems and routers, it fall to me to lead the way within our networks. We cannot today draw an addressing plan for our networks using IPv6. This means that, no matter how gee whiz IPv6 may be, we can have no part of it because we still cannot plan for it. AND, we need it!! JimC - James R. Cutler EDS Mail Stop 4165 800 Tower Drive, Troy, MI 48007-7012 Phone: 810-265-7514 FAX: 810-265-7514 EDS Internal Web: World Wide Web: ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 11:14:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14553; Wed, 5 Mar 1997 11:09:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14546; Wed, 5 Mar 1997 11:09:05 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA29321; Wed, 5 Mar 1997 11:09:42 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA04774 for ; Wed, 5 Mar 1997 11:08:30 -0800 Received: from big-dogs.cisco.com (herndon-dhcp-92.cisco.com [171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id LAA11310; Wed, 5 Mar 1997 11:09:09 -0800 (PST) Message-Id: <3.0.32.19970305140906.006e10f0@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 05 Mar 1997 14:09:09 -0500 To: "James R. Cutler" From: Paul Ferguson Subject: (IPng 3160) Re: we need it.... Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1840 Jim, I'd like to also solicit your input on what the gosh-darned rush is to start full-scale operational deployment of IPv6? Call me an eternal sceptic, but I still do not see evidence of an emergency, or a pressing problem that IPv6 'fixes'. Granted, there are valid reasons why people want to tinker, test, play, etc., but no operational reasons that I'm aware for urgency. I agree it is important to move ahead on development, interoperability trials, etc., so please do not misconstrue my comments as bashing v6. - paul At 01:35 PM 3/5/97 -0500, Mike O'Dell wrote: > >i understand your situation. > >IPv6 has a lot of good things to want. > >that doesn't change the fact that anyone planning deployment >using the current state of "bakedness" as a foundation is playing >with fire. no way in the world can you be told anything that >can provide anything like a reliable basis for large-scale plans. > >it's just too early and too little is understood at this point. and it's >*very* important to fix the problems as they are uncovered in the field >trial before things get frozen. the lack of aggrability in the current >"provider-based addressing" plan is a good example of something which has >to be fixed or it will surely strangle us long-term. > >as for frozen, IPv6 ain't even cool. > >i'm sorry if this is bad news, but better you deal with it now and >adjust your expectations. > >field trials with disposable systems? sure thing. have at it; experience >needed and required. > >anything else, though, is asking for big trouble. > > -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 11:42:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14592; Wed, 5 Mar 1997 11:36:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14585; Wed, 5 Mar 1997 11:36:44 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA08751; Wed, 5 Mar 1997 11:37:21 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16651 for ; Wed, 5 Mar 1997 11:36:08 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA29560; Wed, 5 Mar 1997 14:22:33 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26858; Wed, 5 Mar 1997 14:22:32 -0500 Message-Id: <9703051922.AA26858@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: "James R. Cutler" , bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 3161) Re: we need it.... In-Reply-To: Your message of "Wed, 05 Mar 97 13:35:47 EST." Date: Wed, 05 Mar 97 14:22:31 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1752 Mike, Excuse me. But I realize and agree with you on the addressing architecture. But after that unless you can give clear examples it sounds like you don't know what your talking about in my opinion. Your handwaving again... saying this ain't right without any specifics. What is not done in RFC 1883, 1888, 1933, 1970, 1971, and the other specs. Your issue is the routing cloud and we all agree and we also need an exterior routing protocol. So to defend the many years of work your obviously not aware of I am going to say to the WG: Please don't listen to Mike with out more specfics. Generic statements like "This is bad" is political not technical. Once we have the address plan done then any user can proceed with IPv6 but they also need to know how they get that address. The core pieces are done and the others are in process. Your gloom and doom of where we are is simply NOT true and your wrong. In fact several of your questions at the meeting leads me to believe you don't know how renumbering even works in IPv6 in my opinion. No one has stated IPv6 is ready for production to the degree you are chastizing it and admonishing people like me who have been working on this for four years. Please get it together with specifics so your statements can be verified with details and then discussed to see if they are even valid. ALso did you hear the customer: "We need it" ... Or do you think you know better than the customers? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 12:03:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14637; Wed, 5 Mar 1997 11:57:25 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14630; Wed, 5 Mar 1997 11:57:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA15167; Wed, 5 Mar 1997 11:57:50 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA25188 for ; Wed, 5 Mar 1997 11:56:31 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id LAA21746; Wed, 5 Mar 1997 11:57:10 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199703041201.OAA24469@harakka.cs.tut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Mar 1997 11:59:02 -0800 To: Koskelainen Petri From: Steve Deering Subject: (IPng 3162) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1943 Koskelainen Petri wrote: > Having read the IPng meeting minutes from San Jose, > (see excerpt below) I wonder what is the status of priority field > usage ? > Steve promised to write up email message about this subject but I > haven't seen such in the list Yes, I dropped the ball on that one (I can barely move around my office, the floor is so littered with dropped balls!). Thanks for prodding. > (btw, xerox ftp site for IPv6 is empty). That's normal. The Xerox FTP site is used only occasionally to make documents available during the interval between submission as an ID and their availability in the normal internet-drafts directories. Also, the mailing list archive is kept at Sun -- see the ipng web page (http://playground.sun.com/ipng/) instructions. > Since this proposed/approved(?) change is quite essential from the > applications point of view, it is very strange that this isn't explained > or discussed anywhere. Actually, the excerpt from the minutes that you posted does a pretty good job of describing the proposed change of semantics for the Priority field: > - Declare that 4 bits of Priority are rewritable by routers/ISPs for > private purposes (and exclude from authentication header). > - Priority bits have no significance to receivers > - Convention: Sender sets low order bit to mean interactive traffic. > o Delay more important than throughput > o Suggests that routers/ISPs use other bits before touching the > "interactive bit". > o Affects queuing only, not routing (since re-writable). Do you (or does anyone else) have any comments in favor or against such a change? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 12:24:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA14670; Wed, 5 Mar 1997 12:18:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA14663; Wed, 5 Mar 1997 12:18:46 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA21417; Wed, 5 Mar 1997 12:19:23 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA03774 for ; Wed, 5 Mar 1997 12:18:11 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfph23795; Wed, 5 Mar 1997 15:16:49 -0500 (EST) Message-Id: To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 3163) Re: we need it.... In-reply-to: Your message of "Wed, 05 Mar 1997 14:22:31 EST." <9703051922.AA26858@wasted.zk3.dec.com> Date: Wed, 05 Mar 1997 15:16:44 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 556 Jim, a very wise man, in fact, the fellow who made the decision to have MILNET go with TCP/IP instead of OSI, has a saying apropos this situation When you want it bad, you get it bad. And of course, when you want it in the worst way, boy, is that how you get it. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 13:03:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA14747; Wed, 5 Mar 1997 12:58:07 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA14740; Wed, 5 Mar 1997 12:58:00 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA01091; Wed, 5 Mar 1997 12:58:36 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA18903 for ; Wed, 5 Mar 1997 12:57:22 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfpg22970; Wed, 5 Mar 1997 15:12:43 -0500 (EST) Message-Id: To: bound@zk3.dec.com cc: "James R. Cutler" , ipng@sunroof.eng.sun.com Subject: (IPng 3164) Re: we need it.... In-reply-to: Your message of "Wed, 05 Mar 1997 14:22:31 EST." <9703051922.AA26858@wasted.zk3.dec.com> Date: Wed, 05 Mar 1997 15:12:39 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 627 jim, i am being quite specific. i am no more hand-waving than you are. the exiting IPv6 "provider-based addressing" design does not aggegate in any way useful for sustaining the growth of the internet. the aggregation is based on organizations, not any kind of topology. this is why i'm going to work with Bob Hinden on revising it. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 14:09:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14978; Wed, 5 Mar 1997 14:03:45 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14971; Wed, 5 Mar 1997 14:03:34 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA18759; Wed, 5 Mar 1997 14:04:00 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA15994 for ; Wed, 5 Mar 1997 14:02:40 -0800 Received: from gungnir.fnal.gov ("port 36206"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IG5DSACGGY00065G@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Wed, 05 Mar 1997 16:03:33 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA03156; Wed, 05 Mar 1997 16:03:33 -0600 Date: Wed, 05 Mar 1997 16:03:33 -0600 From: Matt Crawford Subject: (IPng 3165) 64-bit node IDs To: ipng@sunroof.eng.sun.com Message-id: <199703052203.QAA03156@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA15003; Wed, 5 Mar 1997 14:13:30 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14996; Wed, 5 Mar 1997 14:13:20 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA21922; Wed, 5 Mar 1997 14:13:33 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA19685 for ; Wed, 5 Mar 1997 14:12:00 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA16609; Wed, 5 Mar 1997 17:02:53 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA10983; Wed, 5 Mar 1997 17:02:52 -0500 Message-Id: <9703052202.AA10983@wasted.zk3.dec.com> To: Paul Ferguson Cc: "James R. Cutler" , ipng@sunroof.eng.sun.com Subject: (IPng 3166) Re: we need it.... In-Reply-To: Your message of "Wed, 05 Mar 97 14:09:09 EST." <3.0.32.19970305140906.006e10f0@lint.cisco.com> Date: Wed, 05 Mar 97 17:02:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 797 Paul, No one is saying rush and make mistakes. So in that sense there is no rush. I don't see the point in dicking around with it either. This is the last time I will say this OK. Segments of the market need IPv6 right now. They do not want to use private addresses, they do not want to wait to define their 5 year networking plans/designs, and they surely do not want to take it up the proverbial tunnel dealing with the Internet. IPv4 should be dead but its not, but its dying and everyone knows it. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 14:29:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA15025; Wed, 5 Mar 1997 14:24:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA15018; Wed, 5 Mar 1997 14:23:52 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA25343; Wed, 5 Mar 1997 14:24:31 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA23873 for ; Wed, 5 Mar 1997 14:23:20 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA11994; Wed, 5 Mar 1997 17:19:56 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21603; Wed, 5 Mar 1997 17:19:55 -0500 Message-Id: <9703052219.AA21603@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 3167) Re: we need it.... In-Reply-To: Your message of "Wed, 05 Mar 97 15:16:44 EST." Date: Wed, 05 Mar 97 17:19:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1585 Mike, >a very wise man, in fact, the fellow who made the decision to have >MILNET go with TCP/IP instead of OSI, has a saying apropos this situation > When you want it bad, you get it bad. Well I don't have much use for cliches and specificallly ones that I don't believe are not always true. I also don't want it bad and surely don't want it to be bad. What I want is to focus on whats wrong which must be defined and fix it. Thats all. Are their parts that still need fixing yes. In fact I probably know the parts that are broken very well as I try to imagine deploying it. Just to port the applications that are needed for initial production deployment is an awesome task and requires engineering coders to get this done. >And of course, when you want it in the worst way, boy, is that how you get it. No one is saying deploy IPv6 right now. But its time to view it from that perspective which will permit us to flush out bugs we simply would not see otherwise. For example, I believe now that the IPv4 compatible address is completely useless. I am building a deployment scenario presently with IPv6 NAT and it is totally incomplete. What my diagrams depict are the parts that are not done yet. But I do have boxes checked off and that is the part I am thinking your missing. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 14:58:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA15103; Wed, 5 Mar 1997 14:52:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA15095; Wed, 5 Mar 1997 14:51:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02498; Wed, 5 Mar 1997 14:52:32 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA03994 for ; Wed, 5 Mar 1997 14:51:21 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id RAA23890; Wed, 5 Mar 1997 17:49:53 -0500 Date: Wed, 5 Mar 1997 17:49:53 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703051749.ZM23888@seawind.bellcore.com> In-Reply-To: bound@zk3.dec.com "(IPng 3152) Re: IPng Interim Meeting Minutes" (Mar 5, 10:28am) References: <9703051528.AA24060@wasted.zk3.dec.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: bound@zk3.dec.com, Bob Hinden Subject: (IPng 3168) Re: IPng Interim Meeting Minutes Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2562 Renumbering is important, but CIDR basically imposes two different kinds of renumbering: 1) renumbering a site when the site owner decide to change provider, 2) renumbering all the clients of an ISP if that ISP decides to change its transit provider. By and large I assert that (1) is OK but that (2) is not. In the first case, a customer wants to reap some benefits and is probably ready to bear a modest cost -- a very modest cost indeed if we do a good job of making renumbering automatic. In the second case, even a very modest cost is unacceptable, basically because the ones who decide are not the ones who pay. Forcing small ISPs to renumber more often than large ISP flies in the face of fair competition and, in fact, is an obvious call for some form of regulation. I think that we have to devise an addressing plan where small ISPs are never forced to renumber. We can probably do that with a NAP based addressing structure. If ISPs have a NAP of reference, and if the most significant bits of their address identify that NAP, then two results are achieved: 1) we guarantee some form of aggregation, the routing tables scale as the number of NAPs, not the number of ISPs in the world. 2) we allow the routing table to be arbitrarily precise. If a small ISP becomes very large, then the various transit providers may elect to not aggregate its prefix, and use a complete entry for that ISP in the routing table. Now, I have almost heard Tony Li yell "what of free transit" when I wrote the previous paragraphs. Well, it all depends on how you organize the NAP. Sure, you cannot selectively prohibit reception. However, you may certainly insist on bilateral peering when it comes to accepting traffic from an ISP, e.g. only provide an ISP with a transit route if a contractual agreement has been reached. In short, we can implement a policy were "senders pay", which creates an open market for transit routes. To summarize, I propose to use provider based addressing for the network leaves, NAP based or geographical based addressing for the ISP. I think that this combination greatly enhance the stability of the network, without requiring any exotic routing technology. In fact, it can be implemented with BGP. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 14:59:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA15112; Wed, 5 Mar 1997 14:52:48 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA15105; Wed, 5 Mar 1997 14:52:38 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02705; Wed, 5 Mar 1997 14:53:16 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA04333 for ; Wed, 5 Mar 1997 14:52:05 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA05678; Wed, 5 Mar 1997 17:48:48 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23406; Wed, 5 Mar 1997 17:48:46 -0500 Message-Id: <9703052248.AA23406@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, "James R. Cutler" , ipng@sunroof.eng.sun.com Subject: (IPng 3169) Re: we need it.... In-Reply-To: Your message of "Wed, 05 Mar 97 15:12:39 EST." Date: Wed, 05 Mar 97 17:48:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4058 Mike, >i am being quite specific. i am no more hand-waving than you are. In the next paragraph you are yes. And if you had said that until the aggregation is done IPv6 cannot be deployed. I would totally agree with you. But you made a blind generic statement about IPv6 in general. Thats what I was referring to as handwaving. >the exiting IPv6 "provider-based addressing" design does not aggegate in >any way useful for sustaining the growth of the internet. the aggregation >is based on organizations, not any kind of topology. this is why i'm >going to work with Bob Hinden on revising it. I agree with you 1000%. Look I admit this is hard for me. I saw your draft back in Oct 96. I knew then the provider based scheme was broken and your idea was the key to the correct addressing architecture. But we had to have 2 months discussion, an IETF meeting, no work during the Dec Holidays, then 2 more months discussion, and then an Interim meeting that cost my company $1300.00 in T&E. When I knew that the provider based address spec had to be fixed from your ideas. That was 5 months ago. I just cannot take the freakin rate we have to work at I find it completely horrible and frustrating. Any business that would operate this way would go out of business its just too slowww.. But it is faster than other stds worlds I have lived in. But why can't we make it better? Also fixing the above is one piece Mike not the entire IPv6 infrastructure. I think we can fix that fast and add some new pieces see below. Like you and I need to work on those RF + aAA Records before Memphis!!!! Here is what is working and what needs to be done: Working: IPv6 Base Spec References. Neighbor Discovery Autoconfiguration DNS Server, Resolver, AAAA Records (over IPv4 only though) APIs ICMP Spec IPsec (needs key mgmt and API) How to port Applications and Utilities Transition Mechanisms Multicast on Links PMTU Discovery IPv6 over Foo Ripng and Packet Forwarding Multilink interface support (like Multihome). Close but needs more/some implemnentation and in some cases more work on spec: OSPFv3 (I think Done ??? as far as spec) DHCPv6 Dyn Upds DNS IPsec Key Mgmt/APIs Exterior Routing Protocol (needs spec work) Addressing Plan (needs spec work) IPv6 MIBs IPv6 over ATM Service Location Protocol How to access Anycast or Reachability (needs spec work). Router Renumbering (needs a spec) Mobile for IPv6 Dynamic Rehoming of Addresses (needs more spec work) Multicast Routing for IPv6 (this is a big hole) Then we need parts that are not IETF things but are supplier things: Application/Utility Ports (e.g. rlogin, NFS, rsh, WWW Browser, etc) Strategic ISV Ports (e.g. Oracle, Netscape, PATRAN/NASTRAN). Firewall supporting IPv6. NAT for IPv6 internal site and external site. BIND/DNS native over IPv6. NAT requirements for DNS. Porting Guides for Vendor Platforms. Site IPv6 / IPv4 interoperation Guidelines. I am sure there are others in each category. But none of this is complex or should take a lot of time to define. What will take time is to test it. If we can get the Addressing Plan and Exterior Routing Protocol defined and selected by May 97 we can have it widely implemented and tested on the 6bone by Sept 97 in my opinion. During that time we can also poll the user community if they can use it to design networks. I still think it can be deployed within a 12-18 month window given we fill the missing pieces. /jim If we do the minimal changes suggested from the Interim meeting except for DNS I think that can be done quickly by most implementors of IPv6. The DNS parts are more hard and why we need to think about them. But last night I started to look at where I would and how I would process RGs and aAA records. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 17:13:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15479; Wed, 5 Mar 1997 17:04:38 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15472; Wed, 5 Mar 1997 17:04:29 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA09975; Wed, 5 Mar 1997 17:05:06 -0800 Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA24871 for ; Wed, 5 Mar 1997 17:03:57 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id UAA10904; Wed, 5 Mar 1997 20:01:15 -0500 (EST) Date: Wed, 5 Mar 1997 20:01:15 -0500 (EST) From: Scott Bradner Message-Id: <199703060101.UAA10904@newdev.harvard.edu> To: bound@zk3.dec.com, hinden@ipsilon.com, huitema@bellcore.com Subject: (IPng 3170) Re: IPng Interim Meeting Minutes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 603 -- If ISPs have a NAP of reference, and if the most significant bits of their address identify that NAP, then two results are achieved: -- that makes an assumption of the connectivity of ISPs that is not based in the real world, or you are proposing that the ISPs select randomly their high-order address bits. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 17:13:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15488; Wed, 5 Mar 1997 17:04:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15481; Wed, 5 Mar 1997 17:04:44 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA10024; Wed, 5 Mar 1997 17:05:20 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA24932 for ; Wed, 5 Mar 1997 17:04:11 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfqa23370; Wed, 5 Mar 1997 20:05:15 -0500 (EST) Message-Id: To: huitema@bellcore.com (Christian Huitema) cc: ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 3171) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Wed, 05 Mar 1997 17:49:53 EST." <9703051749.ZM23888@seawind.bellcore.com> Date: Wed, 05 Mar 1997 20:05:15 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 419 What is a NAP and why do you think they will continue to exist? but i do like that you are arguing for "Large Structures" (grin) -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 17:14:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15497; Wed, 5 Mar 1997 17:05:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15490; Wed, 5 Mar 1997 17:05:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA10186; Wed, 5 Mar 1997 17:06:14 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA25149 for ; Wed, 5 Mar 1997 17:05:05 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfqa23406; Wed, 5 Mar 1997 20:06:13 -0500 (EST) Message-Id: To: huitema@bellcore.com (Christian Huitema) cc: ipng@sunroof.eng.sun.com Subject: (IPng 3172) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Wed, 05 Mar 1997 17:49:53 EST." <9703051749.ZM23888@seawind.bellcore.com> Date: Wed, 05 Mar 1997 20:06:13 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 397 you assert that "Renumbering when sites change providers is OK". and what if the sites assert otherwise? -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 17:48:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15556; Wed, 5 Mar 1997 17:42:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15549; Wed, 5 Mar 1997 17:41:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA17934; Wed, 5 Mar 1997 17:42:31 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA08599 for ; Wed, 5 Mar 1997 17:41:22 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id RAA10776; Wed, 5 Mar 1997 17:42:26 -0800 Message-Id: <199703060142.RAA10776@puli.cisco.com> To: "Mike O'Dell" cc: ipng@sunroof.eng.sun.com Subject: (IPng 3173) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Wed, 05 Mar 97 20:05:15 EST." Date: Wed, 05 Mar 97 17:42:26 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 736 Mike, > What is a NAP A NAP is a provider (whether one like it or not). > and why do you think they will continue to exist? They'll exist as any other providers. Requiring connection to a NAP for the purpose of aggregation is no different than requiring connection to any other ISP for the purpose of aggregation. Yakov. P.S. One may look at the slides Tony Li and myself presented at the last IEPG meeting to get more insights on this issue. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 17:49:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15587; Wed, 5 Mar 1997 17:43:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15570; Wed, 5 Mar 1997 17:43:28 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA18369; Wed, 5 Mar 1997 17:44:00 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA09272 for ; Wed, 5 Mar 1997 17:42:43 -0800 Received: from [128.3.9.22] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 5 Mar 1997 17:43:30 -0800 X-Sender: rlfink@cnrmail.lbl.gov Message-Id: In-Reply-To: <199703052203.QAA03156@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 5 Mar 1997 17:43:29 -0800 To: Matt Crawford , ipng@sunroof.eng.sun.com From: Bob Fink LBNL Subject: (IPng 3174) Re: 64-bit node IDs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1744 Matt, At 2:03 PM -0800 3/5/97, Matt Crawford wrote: ... >...(Since it will take a while to >get any IEEE documents, I'd appreciate anyone sending me any >definitive information or pointers they have.) ... I got the folowing from Geoff Thompson, chair of 802.3, and Gary Robinson (head of standards at Sun) when I asked about the 8-byte addresses. Hope it helps. Bob ==============from Geoff The definitive master list of IEEE 802 mac address vendor codes is called the OUI list. Not all of it is public. It is kept by Iris Ringel in the IEEE Standards Office. The subset of it that is public is posted on SPA at http://stdsbbs.ieee.org/products/index.html http://stdsbbs.ieee.org/products/oui/ouilst.html I don't know anything about the 8-byte version even though I probably should. Gary Robinson may know something. I'll query him by copy of this message. Geoff ================from Gary A couple of years ago the IEEE Registration Authority Committee, RAC, which oversees the IEEE RA decided to form an additional OUI to be sure we did not run out of OUIs. This is called the XOUI, or extended OUI, and consists of 64 bits/8 octets or incorrectly referred to as 8 bytes. (Just as bad as saying Baud when we all know its bits/sec) There should be a explanation of the IEEE RA Web page about the 64 bit OUI, if it is not there then request a copy from Dave James. dvj@apple.com If I can be of any further help, please ask Gary == ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 18:35:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA15707; Wed, 5 Mar 1997 18:30:16 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA15700; Wed, 5 Mar 1997 18:30:07 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA28346; Wed, 5 Mar 1997 18:30:44 -0800 Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA26669 for ; Wed, 5 Mar 1997 18:29:37 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id VAA11224; Wed, 5 Mar 1997 21:29:03 -0500 (EST) Date: Wed, 5 Mar 1997 21:29:03 -0500 (EST) From: Scott Bradner Message-Id: <199703060229.VAA11224@newdev.harvard.edu> To: mo@uu.net, yakov@cisco.com Subject: (IPng 3175) Re: IPng Interim Meeting Minutes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 518 -- Requiring connection to a NAP for the purpose of aggregation is no different than requiring connection to any other ISP for the purpose of aggregation. -- and if an ISP rehomes from one "NAP" to another should they renumber? Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 20:23:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA15755; Wed, 5 Mar 1997 20:17:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA15748; Wed, 5 Mar 1997 20:17:46 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA11985; Wed, 5 Mar 1997 20:18:24 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA25492 for ; Wed, 5 Mar 1997 20:17:17 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA29052; Wed, 5 Mar 1997 23:10:20 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30151; Wed, 5 Mar 1997 23:10:18 -0500 Message-Id: <9703060410.AA30151@wasted.zk3.dec.com> To: huitema@bellcore.com (Christian Huitema) Cc: bound@zk3.dec.com, Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 3176) Re: IPng Interim Meeting Minutes In-Reply-To: Your message of "Wed, 05 Mar 97 17:49:53 EST." <9703051749.ZM23888@seawind.bellcore.com> Date: Wed, 05 Mar 97 23:10:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1979 Christian, >Renumbering is important, but CIDR basically imposes two different kinds >of renumbering: > >1) renumbering a site when the site owner decide to change provider, > >2) renumbering all the clients of an ISP if that ISP decides to change > its transit provider. >By and large I assert that (1) is OK but that (2) is not. In the first >case, a customer wants to reap some benefits and is probably ready to >bear a modest cost -- a very modest cost indeed if we do a good job >of making renumbering automatic. In the second case, even a very modest >cost is unacceptable, basically because the ones who decide are not the >ones who pay. Forcing small ISPs to renumber more often than large ISP >flies in the face of fair competition and, in fact, is an obvious call >for some form of regulation. And #2 is really unacceptable to any large corporation that acts as an ISP too. #2 is what I mean't when users want not part of taking it up the proverbial tunnel when I responded to Paul earlier. >To summarize, I propose to use provider based addressing for the network >leaves, NAP based or geographical based addressing for the ISP. I think >that this combination greatly enhance the stability of the network, >without requiring any exotic routing technology. In fact, it can be >implemented with BGP. But don't you think Mike's LSID creates exactly what your asking for and the NAPs would below that LSID. In addition I think it will permit the free transit routing which I think important by agreeement too. I might be misunderstanding? Below the LSIDs flat routing can occur or aggregate. With what your proposing it would be a level 2 aggregation right? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 20:30:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA15765; Wed, 5 Mar 1997 20:24:23 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA15758; Wed, 5 Mar 1997 20:24:12 -0800 From: bound@ZK3.DEC.COM Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA12663; Wed, 5 Mar 1997 20:24:51 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA26692 for ; Wed, 5 Mar 1997 20:23:43 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA21041; Wed, 5 Mar 1997 23:18:41 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01844; Wed, 5 Mar 1997 23:18:40 -0500 Message-Id: <9703060418.AA01844@wasted.zk3.dec.com> To: Yakov Rekhter Cc: "Mike O'Dell" , ipng@sunroof.eng.sun.com Subject: (IPng 3177) Re: IPng Interim Meeting Minutes In-Reply-To: Your message of "Wed, 05 Mar 97 17:42:26 PST." <199703060142.RAA10776@puli.cisco.com> Date: Wed, 05 Mar 97 23:18:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 354 Yakov, Do you got a www ptr to the slides (.ps? or .ppt?? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 5 20:56:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA15805; Wed, 5 Mar 1997 20:51:33 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA15798; Wed, 5 Mar 1997 20:51:25 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA15705; Wed, 5 Mar 1997 20:52:03 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA03009 for ; Wed, 5 Mar 1997 20:50:56 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA03103; Wed, 5 Mar 1997 23:49:54 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA07396; Wed, 5 Mar 1997 23:49:53 -0500 Message-Id: <9703060449.AA07396@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3178) Re: 64-bit node IDs In-Reply-To: Your message of "Wed, 05 Mar 97 16:03:33 CST." <199703052203.QAA03156@gungnir.fnal.gov> Date: Wed, 05 Mar 97 23:49:53 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2005 Matt, I think we need to follow your lead here. I am trying to find 1212 and 1394 online some place too for you. If we can get Gary Robinson to comment on this whole thing from Sun to you offline that would be really good per Bob Finks mail. If anyone knows Gary does. I am asking Jim Isaak at Digital too. Without globally unique ESDs the idea of using the low-order 8bytes for connection identification for the PCBs pretty much falls apart. So I think we need to consider that in our tradeoffs here too. Also Matt Thomas presented me with an idea Friday night (Matt is at Connectathon and may be offline). The idea is that with IPsec when using the address for the key and the sequence number if the RG changes (meaning we have are using a defined ESD that is globally unique) the security code knows the RG changed and the sequence number that is higher than drifting packets that are late. IPsec will renegotiate because the RG changed but can accept the packet if it trusts the ESD. But here is the big win. IPsec can set a PCB_NOTIFY to the transport layer and tell the PCB mods the RG has changed so change your PCB. If this works it completely eliminates the need for the binding update for dynamic addresses or rehoming that Charlie Perkins and I are working on. No one should do a binding update without security. IPsec has the sequence number and replay prototection inherent. The code for the PCB change at the transport is minimal and I looked at it today if this will work with IPsec. But we need the globally unique ESD. So I hear you on the bogus ND packets and though I can't believe I would support it, it might be OK if we get other big wins. Thats my input at this point. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 03:53:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA16155; Thu, 6 Mar 1997 03:47:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA16148; Thu, 6 Mar 1997 03:47:15 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA02973; Thu, 6 Mar 1997 03:47:54 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA18663 for ; Thu, 6 Mar 1997 03:46:51 -0800 Received: from kaarne.cs.tut.fi (petkos@kaarne.cs.tut.fi [130.230.3.2]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id NAA12979 for ; Thu, 6 Mar 1997 13:47:53 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by kaarne.cs.tut.fi (8.8.5/8.8.4) id NAA24227 for ipng@sunroof.Eng.Sun.COM; Thu, 6 Mar 1997 13:47:52 +0200 (EET) Message-Id: <199703061147.NAA24227@kaarne.cs.tut.fi> Subject: (IPng 3179) Re: IPv6 priority field usage? To: ipng@sunroof.eng.sun.com Date: Thu, 6 Mar 1997 13:47:52 +0200 (EET) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2350 > >Actually, the excerpt from the minutes that you posted does a pretty good >job of describing the proposed change of semantics for the Priority field: > >> - Declare that 4 bits of Priority are rewritable by routers/ISPs for >> private purposes (and exclude from authentication header). >> - Priority bits have no significance to receivers >> - Convention: Sender sets low order bit to mean interactive traffic. >> o Delay more important than throughput >> o Suggests that routers/ISPs use other bits before touching the >> "interactive bit". >> o Affects queuing only, not routing (since re-writable). > >Do you (or does anyone else) have any comments in favor or against such a >change? > I was just asking the status of that proposed change. Is it now "official" or not. But I assume that it is still a proposition.. Anyway, I'm against the change. I'd like to keep the 4 bits priority field for end-to-end communication although I admit that there are some problems in it (it might encourage users to send unnecessary data to network). Since it is expected that end-to-end resource reservations (rsvp et al) are not available in world-wide Internet (at least for unicast) there should be some tools available for sender to improve the quality of its own stream. Best way to achieve this is to classify packets. There might be some hyper advanced video/audio codec and only sender knows what are the most/least important packets. In the case of no source marked 4 bits priority property, source will send all the packets anyway. (so it doesn't help to change the meaning of priority field) But if we have the source marked priority property then the quality degration in the case of congestion is much smoother. In most cases quality is still usable, e.g. video layer3 and 4 level packets are dropped but layer1-2 still arrive to their destination and receiver can still see the video. So, I'd like to keep the original meaning of priority field, especially because of the emerging layered media techniques. Petri ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 05:02:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA16296; Thu, 6 Mar 1997 04:56:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA16289; Thu, 6 Mar 1997 04:56:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA10741; Thu, 6 Mar 1997 04:57:18 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA02965 for ; Thu, 6 Mar 1997 04:56:17 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id EAA03098; Thu, 6 Mar 1997 04:56:44 -0800 Message-Id: <199703061256.EAA03098@puli.cisco.com> To: Scott Bradner cc: ipng@sunroof.eng.sun.com Subject: (IPng 3180) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Wed, 05 Mar 97 21:29:03 EST." <199703060229.VAA11224@newdev.harvard.edu> Date: Thu, 06 Mar 97 04:56:44 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 724 Scott, > Requiring connection to a NAP for the purpose of aggregation > is no different than requiring connection to any other ISP > for the purpose of aggregation. > -- > > and if an ISP rehomes from one "NAP" to another should they renumber? Just like when an ISP rehomes from one upstream ISP to another. As I said in my previous e-mail, look at the slides that Tony Li and myself presented at the last IEPG. It is all there... Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 05:38:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA16375; Thu, 6 Mar 1997 05:32:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA16368; Thu, 6 Mar 1997 05:31:59 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA16031; Thu, 6 Mar 1997 05:32:37 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA12224 for ; Thu, 6 Mar 1997 05:31:36 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id FAA24457; Thu, 6 Mar 1997 05:29:56 -0800 Message-Id: <199703061329.FAA24457@puli.cisco.com> To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 3181) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Wed, 05 Mar 97 23:18:39 EST." <9703060418.AA01844@wasted.zk3.dec.com> Date: Thu, 06 Mar 97 05:29:56 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 430 Jim, > Do you got a www ptr to the slides (.ps? or .ppt?? It is on ftp-eng.cisco.com under /ftp/yakov/spa-vs-pac.ppt (PowerPoint format). Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 05:41:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA16397; Thu, 6 Mar 1997 05:34:44 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA16377; Thu, 6 Mar 1997 05:32:59 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA16148; Thu, 6 Mar 1997 05:33:38 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA12467; Thu, 6 Mar 1997 05:32:37 -0800 Received: from big-dogs.cisco.com (herndon-dhcp-92.cisco.com [171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id FAA15244; Thu, 6 Mar 1997 05:33:35 -0800 (PST) Message-Id: <3.0.32.19970306083329.0071650c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Mar 1997 08:33:36 -0500 To: bound@zk3.dec.com From: Paul Ferguson Subject: (IPng 3182) Reality check [Was: Re: we need it.... ] Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3882 [added ngtrans] Jim, At 05:02 PM 3/5/97 -0500, bound@zk3.dec.com wrote: >Paul, > >No one is saying rush and make mistakes. So in that sense there is no >rush. I don't see the point in dicking around with it either. This is >the last time I will say this OK. Segments of the market need IPv6 >right now. They do not want to use private addresses, they do not want >to wait to define their 5 year networking plans/designs, and they surely >do not want to take it up the proverbial tunnel dealing with the >Internet. > I hesitated in responding to this, since we've been down this rat hole many times before, but wanted to clarify a couple of issues. One might suggest that address allocation strategies when dealing with IPv6 will not be all too dissimilar to address allocation strategies within the IPv4 space, but I digress. I do not disagree that ongoing standardization and development of IPv6 technologies should move full steam ahead, but there are (as you have pointed out) more than a few peripheral technologies that need to move ahead insofar as IPv6 compatibility, as well. Quite to the contrary, I believe we should be actively looking to rectify all shortcomings and incompatibilities to make IPv6 actually work when the appropriate time comes to deploy it. However, the issues which you have so succinctly indicated as reasons which customers wish to migrate to IPv6, in my opinion, are inadequate. And (dare I say it) customers are not always right. This is not to say that customers do not want IPv6, but perhaps we should also explore why they want it, help them understand what problems they think they have *today*, what problems IPv6 might solve, what problems IPv6 will not solve, and perhaps methods to assist them in correcting these problems today in IPv4. I would suggest that many customers which I have discussed this with have an impression that, since the solution to the problems they are faced with today are 'too hard', they have a vision of IPv6 as a magic bullet and an 'easy' way to fix the 'problem'. This is twisted logic, as the problems they will encounter trying to deploy IPv6 in the short term will, by far, outweigh the problem they have today with IPv4. Of course, this is only my opinion, so take it at face value. The problems which we have today in the global Internet are primarily due to instability in the routing system (for various reasons which are orthogonal to this discussion), and dramatically increasing the address space will only compound these issues. I would emphatically agree with Mike O'Dell that a rush to deploy IPv6 in the near term in the commodity Internet is a headlong leap into disaster. And in fact, the majority of large Internet service providers are cognizant of these issues. I am optimistic, however, that efforts such as the Internet2 Project will provide a research -like infrastructure where IPv6 deployment can be measured and analyzed. There are some very serious issues which need to be discussed on wide-scale deployment of IPv6, it's impact on the global routing system, how aggregation will be affected, etc. I would suggest that what we need in the IETF is a working group to explore these issues. I'm not sure that NGTrans is the appropriate forum, although I'd certainly like to hear comments in this regard. >IPv4 should be dead but its not, but its dying and everyone knows it. > The question is not whether IPv4 is dying, but rather, how long it will live. I would suggest that analogy that Mark Twain once used is apropos; "Reports of my death are greatly exaggerated." - paul >/jim > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 06:27:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA16474; Thu, 6 Mar 1997 06:21:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA16467; Thu, 6 Mar 1997 06:21:31 -0800 From: bmanning@ISI.EDU Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA23761; Thu, 6 Mar 1997 06:22:09 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA27741; Thu, 6 Mar 1997 06:21:10 -0800 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 6 Mar 1997 06:22:11 -0800 Posted-Date: Thu, 6 Mar 1997 06:21:50 -0800 (PST) Message-Id: <199703061421.AA03757@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Thu, 6 Mar 1997 06:21:51 -0800 Subject: (IPng 3184) Another, Operational view To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Date: Thu, 6 Mar 1997 06:21:50 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4084 > > > Hi Bill, > > > > > > Thanks for removing it. What benefit was it giving you? Surely, an IPv6 > > > compatible IPv4 route is either going to be auto-tunnelled or routed via > > > IPv4. > > > > > > Regards, > > > > > > Guy > > > > Well, call me loony, but I thought that part of the idea behind 6bone was to > > explore/examine the extent of the IPv6 feature set, particularly the -very- > > primitive routing capabilities. > > Absolutely. My question was exactly that, a question. I wasn't sure if > the route should indeed by routed by IPv6 or should be autotunneled or > IPv4 routed. I also agree that the currently available routing protocols > do not match what we're used to with IPv4. This can lead to us making > some statements based on what we think would be best because it works that > way in v4. Well, maybe some things _should_ work differently than > expected based on IPv4. > > > I think the injection of this "spurious" route raised a couple of interesting > > questions. One respones was, "its confusing" and there are your assertions > > above about autotunneling or routed via IPv4. A careful examination of > > the prefix I injected will show that the IPv4 equivalent is never supposed > > to be routed in the IPv4 infrastructure. A rough equal to the RFC 1918 > > blocks. > > OK. So that raises the question, how do you deal with these addresses? > Do you ignore them all? Do you ignore those which should be unroutable? > Do you mutate them into IPv6 routes and route them that way? If so, what > do you do with the route 0::0/96 which is another 'martian' default? > > I certainly think that the injection of IPv6 compatible IPv4 addresses is > confusing. However, that's because, AFAIK, there's been no statement as > to what should happen in those circumstances so router and host stack > developers could have dealt with this in many ways. My personal opinion is > that such routes should not be dealt with as IPv6 routes because they are > only compatible addresses which are dealt with by either autotunneling or > conversion back to IPv4. If, in the future, you have an IPv6 address > derived from your IPv4 address (but not using :: or ::ffff:) > then that should be automagically rewritten in IPv6 notation and dealt > with appropriately as an IPv6 route. Remember, these are my opinions and > are up there to be shot down by reasoned argument :-) > > > I think that before we, as operators, start making restrictive choices on > > IPv6 routing implementations, we should really have better criteria that > > the subjective assertions that have thus far been made. > > I agree. It's just human nature to say "This doesn't work the way I > expected it to" based on an incomplete understanding of the system or > "this doesn't work the way my old system did, I want it changed". You > will always get an initial reaction from a bunch of people like those > currently looking at 6bone. That's the kind of people that do this kind > of work. > > What we really want is to be able to setup routing with policy and all > that wonderful stuff. RIPng is not designed for this and should not be > changed to do this. We're only using RIPng because there's no better > alternative right now. Once or IDRPv6 > are developed and/or more widely used, then many of the problems we are > currently experiencing with trying to route a global network using an IGP > will be forgotten. > > I hope this put's my ideas. It's not supposed to be a statement of where > we _must_ go. > > Regards, > > Guy > > > > -- > > --bill Further discussion on this topic seemed to indicate a strong value in prefixes of the form ::192.0.2.0/96 as a transition method. More bits to chew on. :) -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 06:27:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA16465; Thu, 6 Mar 1997 06:21:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA16458; Thu, 6 Mar 1997 06:21:03 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA23704; Thu, 6 Mar 1997 06:21:41 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA27600 for ; Thu, 6 Mar 1997 06:20:40 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcfsb13149; Thu, 6 Mar 1997 09:21:36 -0500 (EST) Message-Id: To: Yakov Rekhter cc: Scott Bradner , ipng@sunroof.eng.sun.com Subject: (IPng 3183) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Thu, 06 Mar 1997 04:56:44 PST." <199703061256.EAA03098@puli.cisco.com> Date: Thu, 06 Mar 1997 09:21:36 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 344 glad to see you supporting "large structures" (grin) -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 07:37:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16617; Thu, 6 Mar 1997 07:32:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16610; Thu, 6 Mar 1997 07:31:53 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA17128; Thu, 6 Mar 1997 07:32:33 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA25249 for ; Thu, 6 Mar 1997 07:31:31 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id KAA24336; Thu, 6 Mar 1997 10:32:23 -0500 Date: Thu, 6 Mar 1997 10:32:23 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703061032.ZM24334@seawind.bellcore.com> In-Reply-To: Scott Bradner "(IPng 3170) Re: IPng Interim Meeting Minutes" (Mar 5, 8:01pm) References: <199703060101.UAA10904@newdev.harvard.edu> X-Mailer: Z-Mail (3.2.1 10oct95) To: "Mike O'Dell" , Scott Bradner Subject: (IPng 3185) Re: IPng Interim Meeting Minutes Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3270 Scott, Mike, Jim, Thanks for the comments. Basically, I am proposing to use geographic addressing for ISP. My main concern here is about the establishment of a free competition. I have some reason to believe that this concern could well be shared by legislators and regulators. Geographic addressing has a definitive number of advantages from that point of view: 1) With geographic addressing, you basically pay for what you send, not for what you receive. This creates a lot of market flexibility, because you can choose at any time the transit provider through which you will send data, without only strictly local changes to your routing tables. 2) Geographic addressing is actually a misnomer, because we are concerned with network topology, not geography, and because some networks, e.g. wireless, do not have a clear geographic locality. The network topology equivalent of a geographic metropolis is a NAP, an aggregation point for a given routing prefix. 3) NAPs do exist today -- call them CIX, FIX or Gigapop, they definitely exist. They don't carry all the traffic, and in fact they don't have to. The only requirement I see, if we want to implement some form of geographic addressing, is some limited form of one way connectivity. Let's model a NAP as a big hunking router that speaks BGPv6 or IDRP. A geographic NAP serving one prefix would peer with whoever wants to do business with that prefix, and announce exactly one reachable prefix to its peers -- the geographic prefix of the area. It will only accept announcement for "longer matching" prefixes within that area, thus only providing intra-area connectivity. 4) The restricted peering basically removes the "free transit" pitfall. ISPs connected to the NAP could only speak to the Internet at large if they obtain peerings from transit providers -- or if they connect to other metropolis by themselves. The economic model is sound: you pay for what you send. 5) Yes, this is a twist of today's topology. But it is in fact an enforceable twist, in particular one that can be enforced by local legislatures, e.g. by a decree that "if you want to sell Internet services to the population of New Provence, you have to be able to send all packets bound to the New Provence prefix to the New provence NAP." This is the main answer to Mike's question "why do you think (NAP) will continue to exist." 6) The main interest there is that it removes the need to classify providers by size, or to establish a hierarchy of providers. This is then strictly delegated to market forces. An ISP that becomes large just ends up with its longer-matching prefix distributed all over the world. 7) Because the economic model is sound, anyone can in fact become an ISP -- no judgement requested by numbering authorities. This means that large corporations can do it as well. But then, they will indeed have to negotiate peering with the transit providers, and pay the corresponding costs. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 07:58:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16655; Thu, 6 Mar 1997 07:52:31 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16648; Thu, 6 Mar 1997 07:52:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA21300; Thu, 6 Mar 1997 07:53:01 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA03419; Thu, 6 Mar 1997 07:52:00 -0800 Received: (dkatz@localhost) by puli.cisco.com (8.6.12/8.6.5) id HAA28118; Thu, 6 Mar 1997 07:53:01 -0800 Date: Thu, 6 Mar 1997 07:53:01 -0800 From: Dave Katz Message-Id: <199703061553.HAA28118@puli.cisco.com> To: pferguso@cisco.com CC: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-reply-to: Paul Ferguson's message of Thu, 06 Mar 1997 08:33:36 -0500 <3.0.32.19970306083329.0071650c@lint.cisco.com> Subject: (IPng 3186) Reality check [Was: Re: we need it.... ] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 558 The question is not whether IPv4 is dying, but rather, how long it will live. I would suggest that analogy that Mark Twain once used is apropos; "Reports of my death are greatly exaggerated." Or to paraphrase Frank Zappa, "IPv4 isn't dead, it only smells bad." ;-) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 08:18:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16831; Thu, 6 Mar 1997 08:08:16 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16815; Thu, 6 Mar 1997 08:07:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24422; Thu, 6 Mar 1997 08:08:21 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09738 for ; Thu, 6 Mar 1997 08:07:19 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA22756; Thu, 6 Mar 1997 11:08:12 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id LAA85606; Thu, 6 Mar 1997 11:08:13 -0500 Received: from cabomba.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA13244; Thu, 6 Mar 1997 11:07:55 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id KAA00413; Thu, 6 Mar 1997 10:12:26 -0500 Message-Id: <199703061512.KAA00413@hygro.raleigh.ibm.com> To: "James R. Cutler" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3190) Re: Wisdom from a Production User In-Reply-To: Your message of "Wed, 05 Mar 1997 13:05:04 EST." Date: Thu, 06 Mar 1997 10:12:26 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1174 Jim, > We cannot today draw an addressing plan for our networks using IPv6. I don't follow this statement, probably because I don't understand what you mean by "drawing up an addressing plan". It is a given (and has been for a long time) that end sites will be given the equivalent of 2 bytes of subnet routing space for numbering links within an end site. From a planning perspective, it shouldn't matter what the upper bytes of the addresses will be, since they are a prefix obtained from outside the site (i.e., provider, etc.) and the exact bit value of that portion of addresses just shouldn't matter. I would think that from a planning perspective, the tough job is how to map the 2 bytes worth of internal routing onto the current and future physical topology. That can be done independent of the actual address you will be using. Or am I missing something more fundamental? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 08:18:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16822; Thu, 6 Mar 1997 08:07:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16797; Thu, 6 Mar 1997 08:07:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24410; Thu, 6 Mar 1997 08:08:16 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09702 for ; Thu, 6 Mar 1997 08:07:14 -0800 Received: from rtpdce02.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA47672; Thu, 6 Mar 1997 11:08:10 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id LAA42156; Thu, 6 Mar 1997 11:08:12 -0500 Received: from cabomba.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA13248; Thu, 6 Mar 1997 11:07:56 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id KAA00394; Thu, 6 Mar 1997 10:10:57 -0500 Message-Id: <199703061510.KAA00394@hygro.raleigh.ibm.com> To: Paul Ferguson Cc: "James R. Cutler" , ipng@sunroof.eng.sun.com Subject: (IPng 3187) Re: we need it.... In-Reply-To: Your message of "Wed, 05 Mar 1997 14:09:09 EST." <3.0.32.19970305140906.006e10f0@lint.cisco.com> Date: Thu, 06 Mar 1997 10:10:57 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1676 Paul, > I'd like to also solicit your input on what the gosh-darned rush > is to start full-scale operational deployment of IPv6? Call me an > eternal sceptic, but I still do not see evidence of an emergency, > or a pressing problem that IPv6 'fixes'. Deploying v6 will take an incredibly long time. If we don't start, we'll never get to the end point. There are real dangers in waiting until the last minute, when there is less wiggle room to make changes and cycle the experience of the poineers back into specs and products. One thing v6 clearly does provide is that it gives end sites the equivalent of a class B address, i.e., 16 bits for internal routing topology in addition to the 6 byte token stateless address autoconfiguration uses. This makes planning for growth a *lot* easier than what one gets with IPv4 today (i.e., here is a small segment -- if you need more space in a year you may be asked to renumber). (Let's skip the debate about how "pressing" this is, since the answer depends a lot on where one sits.) > I agree it is important to move ahead on development, interoperability > trials, etc., so please do not misconstrue my comments as bashing > v6. Let me turn the question around. Just what "pressing" problem do you think IPv6 will *ever* solve? There must be one, or there wouldn't be any point in continuing development, interoperatbility trials, etc. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 08:18:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16823; Thu, 6 Mar 1997 08:07:57 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16799; Thu, 6 Mar 1997 08:07:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24413; Thu, 6 Mar 1997 08:08:16 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09698 for ; Thu, 6 Mar 1997 08:07:13 -0800 Received: from rtpdce03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA306722; Thu, 6 Mar 1997 11:08:09 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id LAA56078; Thu, 6 Mar 1997 11:08:12 -0500 Received: from cabomba.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA13240; Thu, 6 Mar 1997 11:07:55 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id KAA00429; Thu, 6 Mar 1997 10:13:52 -0500 Message-Id: <199703061513.KAA00429@hygro.raleigh.ibm.com> To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3188) Re: IPng Interim Meeting Minutes In-Reply-To: Your message of "Wed, 05 Mar 1997 11:47:13 EST." Date: Thu, 06 Mar 1997 10:13:52 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1002 > one of the reasons we talked about splitting the records in > the DNS (and synthesizing AAAA responses from the pieces) is > that it dramatically reduces the requirements for DNS Dynamic > Update and the attendant security botches. I think I'd phrase that a little differently. DDNS is just as needed as before (having an address is all good and well, but one often still needs a DNS name to go with it). However, splitting the RG part off from the rest of an address makes it possible to change a site's routing goop (prefix) without having to update the entire site's DNS database -- just update the one routing goop entry. Thus, renumbering won't require a massive invocation of DDNS. That's a *huge* win. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 08:17:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16827; Thu, 6 Mar 1997 08:08:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16813; Thu, 6 Mar 1997 08:07:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24420; Thu, 6 Mar 1997 08:08:21 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09754 for ; Thu, 6 Mar 1997 08:07:20 -0800 Received: from rtpdce03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA204684; Thu, 6 Mar 1997 11:08:14 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id LAA49428; Thu, 6 Mar 1997 11:08:16 -0500 Received: from cabomba.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA13252; Thu, 6 Mar 1997 11:07:57 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id KAA00457; Thu, 6 Mar 1997 10:18:02 -0500 Message-Id: <199703061518.KAA00457@hygro.raleigh.ibm.com> To: Robert Elz Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 3189) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Wed, 05 Mar 1997 08:36:08 +1100." <7521.857511368@munnari.OZ.AU> Date: Thu, 06 Mar 1997 10:18:02 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1969 > Two-Face DNS was an issue that folks felt need to be discussed. > But why? Just academic curiosity on how it could be done? One of the key points Mike made clear at the interim meeting was that sites make a big distinction between internal network stability and external connectivity. It is (relatively) OK for an Internet connection to get trashed compared with disrupting to the internal infrastructure. I can relate to that well. Although losing your Internet connection is a (possibly major) inconvenience, it doesn't come close to what happens when (say) your routers get screwed up and everyone's machines freeze (thank you NFS). That means that if ISPs start renumbering parts of the backbone, their changes can't have a ripple effect that causes my infrastructure to go bonkers and cause my intra-site TCP connections to break. One suggestion was for intra-site communication to use site-local addresses, which won't change during a renumbering. One problem that arises with this approach is what happens if your local DNS server crashes and you try contacting a remote DNS server that is one of your secondaries. It needs to return a site-local address in this case. On the other hand, returning site-local addresses to someone else that doesn't reside in the same site *as that site-local address* may cause someone to use a site-local address of the wrong scope (i.e., communication will fail). I personally am not very keen on two-faced DNSs, especially if we *require* them as part of making things work. But the point is that there is a problem here that needs to be thought about, and a two-faced DNS server may be one way of addressing the problem. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 08:32:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16885; Thu, 6 Mar 1997 08:22:56 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16878; Thu, 6 Mar 1997 08:22:36 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27241; Thu, 6 Mar 1997 08:23:15 -0800 Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA16224 for ; Thu, 6 Mar 1997 08:22:14 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id LAA00247 for ipng@sunroof.Eng.Sun.COM; Thu, 6 Mar 1997 11:21:33 -0500 (EST) Date: Thu, 6 Mar 1997 11:21:33 -0500 (EST) From: Scott Bradner Message-Id: <199703061621.LAA00247@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 3192) Re: IPng Interim Meeting Minutes Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 522 Christian, sounds good but the question still is what happens when an ISP deep in the hierarchy moves its location in the hierarchy I'm all for topology-based geographic addressing - in fact that is what I thought that CIDR is Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 08:40:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16927; Thu, 6 Mar 1997 08:34:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16920; Thu, 6 Mar 1997 08:34:15 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA29713; Thu, 6 Mar 1997 08:34:54 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA21428 for ; Thu, 6 Mar 1997 08:33:54 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id IAA00280; Thu, 6 Mar 1997 08:34:20 -0800 Message-Id: <199703061634.IAA00280@puli.cisco.com> To: huitema@bellcore.com (Christian Huitema) cc: ipng@sunroof.eng.sun.com Subject: (IPng 3193) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Thu, 06 Mar 97 10:32:23 EST." <9703061032.ZM24334@seawind.bellcore.com> Date: Thu, 06 Mar 97 08:34:20 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 916 Christian, > 5) Yes, this is a twist of today's topology. But it is in fact an > enforceable twist, in particular one that can be enforced by local > legislatures, e.g. by a decree that "if you want to sell Internet services > to the population of New Provence, you have to be able to send all packets > bound to the New Provence prefix to the New provence NAP." This is the > main answer to Mike's question "why do you think (NAP) will continue to > exist." So, you advocate monopoly ("send all packets bound to the New Provence prefix to the New Provence NAP") as a way of promoting competition. Very interesting logic. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 09:23:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16986; Thu, 6 Mar 1997 09:14:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16979; Thu, 6 Mar 1997 09:14:13 -0800 From: bmanning@ISI.EDU Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA09590; Thu, 6 Mar 1997 09:14:52 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA08449 for ; Thu, 6 Mar 1997 09:13:30 -0800 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 6 Mar 1997 09:14:29 -0800 Posted-Date: Thu, 6 Mar 1997 09:14:08 -0800 (PST) Message-Id: <199703061714.AA04386@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Thu, 6 Mar 1997 09:14:09 -0800 Subject: (IPng 3194) Re: IPng Interim Meeting Minutes To: yakov@cisco.com (Yakov Rekhter) Date: Thu, 6 Mar 1997 09:14:08 -0800 (PST) Cc: huitema@bellcore.com, ipng@sunroof.eng.sun.com In-Reply-To: <199703061634.IAA00280@puli.cisco.com> from "Yakov Rekhter" at Mar 6, 97 08:34:20 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 580 > So, you advocate monopoly ("send all packets bound to the New Provence > prefix to the New Provence NAP") as a way of promoting competition. > Very interesting logic. > > Yakov. Or.... "send all packets bound to the delegated prefix for New Provence to the New Provence ISP".... -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 09:25:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16995; Thu, 6 Mar 1997 09:15:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16988; Thu, 6 Mar 1997 09:15:29 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA09872; Thu, 6 Mar 1997 09:16:08 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA08860 for ; Thu, 6 Mar 1997 09:14:34 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id JAA02972; Thu, 6 Mar 1997 09:15:03 -0800 Message-Id: <199703061715.JAA02972@puli.cisco.com> To: huitema@bellcore.com (Christian Huitema) cc: ipng@sunroof.eng.sun.com Subject: (IPng 3195) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Thu, 06 Mar 97 11:56:06 EST." <9703061156.ZM24476@seawind.bellcore.com> Date: Thu, 06 Mar 97 09:15:03 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1497 Christian, > On Mar 6, 8:34am, Yakov Rekhter wrote: > > Subject: Re: (IPng 3185) Re: IPng Interim Meeting Minutes > > Christian, > > > > > 5) Yes, this is a twist of today's topology. But it is in fact an > > > enforceable twist, in particular one that can be enforced by local > > > legislatures, e.g. by a decree that "if you want to sell Internet > services > > > to the population of New Provence, you have to be able to send all > packets > > > bound to the New Provence prefix to the New provence NAP." This is > the > > > main answer to Mike's question "why do you think (NAP) will continue > to > > > exist." > > > > So, you advocate monopoly ("send all packets bound to the New Provence > > ) as a way of promoting competition. > > Very interesting logic. > > Well, no, I do not actually invoke monopoly. I just have a poor english > style. What I meant was "be able to send any packet bound to the New > Provence prefix to the New Provence NAP, unless indeed you know a shorter > path to the specific destination." Could the New Provence have more than one NAP ? If yes, are there any constraints (aka regulations) wrt operations of these NAPs ? If yes, would you please spell them out ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 09:26:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17027; Thu, 6 Mar 1997 09:18:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17013; Thu, 6 Mar 1997 09:17:47 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA10509; Thu, 6 Mar 1997 09:18:26 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA10160 for ; Thu, 6 Mar 1997 09:17:04 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id JAA03146; Thu, 6 Mar 1997 09:18:03 -0800 Message-Id: <199703061718.JAA03146@puli.cisco.com> To: bmanning@isi.edu cc: ipng@sunroof.eng.sun.com Subject: (IPng 3196) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Thu, 06 Mar 97 09:14:08 PST." <199703061714.AA04386@zed.isi.edu> Date: Thu, 06 Mar 97 09:18:03 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 726 > > So, you advocate monopoly ("send all packets bound to the New Provence > > prefix to the New Provence NAP") as a way of promoting competition. > > Very interesting logic. > > > > Yakov. > > Or.... "send all packets bound to the delegated prefix for New Provence to > the New Provence ISP".... Yes, indeed. As I mentioned before, a NAP isn't that different from an ISP. Changing the terminology isn't going to hide the essence. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 09:37:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17080; Thu, 6 Mar 1997 09:30:13 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17073; Thu, 6 Mar 1997 09:30:08 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA23929; Thu, 6 Mar 1997 09:30:49 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02944; Thu, 6 Mar 1997 09:30:18 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16841; Thu, 6 Mar 1997 08:09:57 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24884; Thu, 6 Mar 1997 08:10:36 -0800 Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA10782 for ; Thu, 6 Mar 1997 08:09:35 -0800 Received: from nnsp.eds.com (nnsp.eds.com [130.174.32.78]) by ns2.eds.com (8.8.5/8.8.5) with ESMTP id LAA06715; Thu, 6 Mar 1997 11:10:36 -0500 (EST) Received: from [130.175.183.223] (netmac.iscg.eds.com [130.175.183.223]) by nnsp.eds.com (8.8.5/8.8.5) with ESMTP id LAA02894; Thu, 6 Mar 1997 11:10:05 -0500 (EST) X-Sender: jcutle01@info1.iscg.eds.com Message-Id: In-Reply-To: <3.0.32.19970305140906.006e10f0@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Mar 1997 11:06:50 -0500 To: Paul Ferguson From: "James R. Cutler" Subject: (IPng 3197) Re: we need it.... Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1557 Y'all, We am not in a "gosh-darned rush". However, the scope of EDS networking and the number of desktops supported is such that I forsee at least an eighteen to twenty-four month delay from the time IPv6 address architecture is made final to any significant changes in our networks. It will take this long to create and verify a new addressing plan and the transition plan which will allow migration without disaster. It is clear that the internet population explosion is just beginning. In a relatively few years (from a business planning viewpoint) we will absolutely require IPv6 address space to meet the demand. Think of China. Think of US Web-TV deployment. We am not in a rush to deploy. We are anxious to get to the point where we can plan our future. JimC >Jim, > >I'd like to also solicit your input on what the gosh-darned rush >is to start full-scale operational deployment of IPv6? Call me an >eternal sceptic, but I still do not see evidence of an emergency, >or a pressing problem that IPv6 'fixes'. - James R. Cutler EDS Mail Stop 4165 800 Tower Drive, Troy, MI 48007-7012 Phone: 810-265-7514 FAX: 810-265-7514 EDS Internal Web: World Wide Web: ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 09:51:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17119; Thu, 6 Mar 1997 09:46:09 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17112; Thu, 6 Mar 1997 09:46:01 -0800 From: EDS@RHQVM21.VNET.IBM.COM Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA17517; Thu, 6 Mar 1997 09:46:04 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA21851 for ; Thu, 6 Mar 1997 09:43:18 -0800 Message-Id: <199703061743.JAA21851@mercury.Sun.COM> Received: from RHQVM21 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3766; Thu, 06 Mar 97 12:44:02 EST Date: Thu, 6 Mar 97 12:25:43 EST To: ipng@sunroof.eng.sun.com Subject: (IPng 3198) Re: IPng Interim Meeting Minutes Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1673 > Let's model a NAP as a big hunking router that speaks BGPv6 > or IDRP. A geographic NAP serving one prefix would peer >with whoever wants to do business with that prefix, and >announce exactly one reachable prefix to its peers -- >the geographic prefix of the area. It will only accept >announcement for "longer matching" prefixes within that >area, thus only providing intra-area connectivity. This idea has many positives; but wouldnt it cause the loss of the ability to have a sort of load splitting effect(on both network links and routers/switches) present when multiple paths to prefixes are announced? Also in this email and the email from last night: >To summarize, I propose to use provider based addressing for the network >leaves, NAP based or geographical based addressing for the ISP. I think >that this combination greatly enhance the stability of the network, >without requiring any exotic routing technology. In fact, it can be >implemented with BGP. In the paragraph above I assume it means "it can be implemented" by taking one of the proposals for carrying IPv6/multiprotocol addresses in BGP from a few months ago and making few modifications. Is the thinking that everything that might be needed for the future/IPng could be done with modifications to BGPv6/IDRP. What are the contemplated/possible modifications? Ed Segal EDS@RHQVM21.VNET.IBM.COM 914 784-3259 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 10:26:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17285; Thu, 6 Mar 1997 10:21:06 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17278; Thu, 6 Mar 1997 10:20:59 -0800 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA27172; Thu, 6 Mar 1997 10:21:37 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA12381 for ; Thu, 6 Mar 1997 10:21:02 -0800 Received: from big-dogs.cisco.com (herndon-dhcp-92.cisco.com [171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id KAA00630; Thu, 6 Mar 1997 10:19:51 -0800 (PST) Message-Id: <3.0.32.19970306131944.0071fa5c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Mar 1997 13:19:51 -0500 To: "James R. Cutler" From: Paul Ferguson Subject: (IPng 3199) Re: we need it.... Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 695 At 11:06 AM 3/6/97 -0500, James R. Cutler wrote: > >It is clear that the internet population explosion is just >beginning. In a relatively few years (from a business planning >viewpoint) we will absolutely require IPv6 address space to >meet the demand. Think of China. Think of US Web-TV deployment. > Again, a method of efficiently aggregating the increased number of prefixes must be demonstrated. - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 10:55:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17358; Thu, 6 Mar 1997 10:49:51 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17351; Thu, 6 Mar 1997 10:49:44 -0800 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA04319; Thu, 6 Mar 1997 10:50:23 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA22523 for ; Thu, 6 Mar 1997 10:50:10 -0800 Received: from big-dogs.cisco.com (herndon-dhcp-92.cisco.com [171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id KAA01295; Thu, 6 Mar 1997 10:20:52 -0800 (PST) Message-Id: <3.0.32.19970306132048.0071fa5c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Mar 1997 13:20:52 -0500 To: Thomas Narten From: Paul Ferguson Subject: (IPng 3200) Re: we need it.... Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 666 At 10:10 AM 3/6/97 -0500, Thomas Narten wrote: > >Let me turn the question around. Just what "pressing" problem do you >think IPv6 will *ever* solve? There must be one, or there wouldn't be >any point in continuing development, interoperatbility trials, etc. > Certainly, increased address space is one benefit, but with this 'benefit' comes other more insidious problems. - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 11:24:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17406; Thu, 6 Mar 1997 11:16:14 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17399; Thu, 6 Mar 1997 11:16:07 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA12262; Thu, 6 Mar 1997 11:16:45 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA12570 for ; Thu, 6 Mar 1997 11:15:44 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id LAA09617; Thu, 6 Mar 1997 11:16:42 -0800 Message-Id: <199703061916.LAA09617@puli.cisco.com> To: Paul Ferguson cc: ipng@sunroof.eng.sun.com Subject: (IPng 3201) Re: we need it.... In-reply-to: Your message of "Thu, 06 Mar 97 13:20:52 EST." <3.0.32.19970306132048.0071fa5c@lint.cisco.com> Date: Thu, 06 Mar 97 11:16:42 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 702 Paul, > >Let me turn the question around. Just what "pressing" problem do you > >think IPv6 will *ever* solve? There must be one, or there wouldn't be > >any point in continuing development, interoperatbility trials, etc. > > > > Certainly, increased address space is one benefit, but with this > 'benefit' comes other more insidious problems. Like the ability to maintain routability to all these addresses. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 11:27:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17415; Thu, 6 Mar 1997 11:18:51 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17408; Thu, 6 Mar 1997 11:18:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA13089; Thu, 6 Mar 1997 11:19:17 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA13716 for ; Thu, 6 Mar 1997 11:17:50 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA10071; Fri, 7 Mar 1997 06:15:59 +1100 (from kre@munnari.OZ.AU) To: Thomas Narten Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 3202) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "Thu, 06 Mar 1997 10:18:02 CDT." <199703061518.KAA00457@hygro.raleigh.ibm.com> Date: Fri, 07 Mar 1997 06:15:58 +1100 Message-Id: <8393.857675758@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1529 Date: Thu, 06 Mar 1997 10:18:02 -0500 From: Thomas Narten Message-ID: <199703061518.KAA00457@hygro.raleigh.ibm.com> > Two-Face DNS was an issue that folks felt need to be discussed. > But why? Just academic curiosity on how it could be done? One of the key points Mike made clear at the interim meeting was that sites make a big distinction between internal network stability and external connectivity. no no no ... Mike has said that on the list too, and I absolutely agree with it. But this is an argument for using site local addresses for site local communications, which is a perfectly fine (even obvious) thing to do. The jump from that to the need for a two faced DNS is a major leap without justification. Sure - a two faced DNS might be a means by which the use of site lcoal addresses for site local communications is encouraged, or perhaps (just perhaps) enforced, but it is most certainly NOT the only way it could be done. If this is the sole remaining justification for this, can we perhaps explore other possible ways, before spending a lot of time worrying about how to force the DNS to do something we might not really need it to do? kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 11:29:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17424; Thu, 6 Mar 1997 11:19:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17417; Thu, 6 Mar 1997 11:19:43 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA13322; Thu, 6 Mar 1997 11:20:20 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA14326 for ; Thu, 6 Mar 1997 11:19:02 -0800 Received: from myname.my.domain (ipsec-grehan.Ipsilon.COM [205.226.14.41]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id LAA15048; Thu, 6 Mar 1997 11:19:25 -0800 Message-ID: <331C7247.446B9B3D@ipsilon.com> Date: Tue, 04 Mar 1997 11:04:39 -0800 From: Peter Grehan X-Mailer: Mozilla 2.01 (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: Paul Ferguson CC: ipng@sunroof.eng.sun.com Subject: (IPng 3203) Re: we need it.... References: <3.0.32.19970306132048.0071fa5c@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 586 Paul Ferguson wrote: > Certainly, increased address space is one benefit, but with this > 'benefit' comes other more insidious problems. I don't know how you could have a more insidious problem than lack of address space: would you care to elaborate the problems that increasing this causes ? Peter. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 11:40:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17487; Thu, 6 Mar 1997 11:32:15 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17476; Thu, 6 Mar 1997 11:31:58 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA17213; Thu, 6 Mar 1997 11:32:36 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA20872; Thu, 6 Mar 1997 11:31:25 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA06350; Thu, 6 Mar 1997 14:21:19 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA29088; Thu, 6 Mar 1997 14:21:16 -0500 Message-Id: <9703061921.AA29088@wasted.zk3.dec.com> To: Paul Ferguson Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: (IPng 3204) Re: Reality check [Was: Re: we need it.... ] In-Reply-To: Your message of "Thu, 06 Mar 97 08:33:36 EST." <3.0.32.19970306083329.0071650c@lint.cisco.com> Date: Thu, 06 Mar 97 14:21:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1258 Paul, If you find my reasons inadequate then you find my customers inadequate. I know what needs to be done to get IPv6 finished and so do others. I view your mail as yet another thread to slow down IPv6. I am going to continue to build it, work in the IETF to finish the pieces, ship Early Adopter kits. and you or no one else is going to IETF the IPv6 effort with yet another working group or more stuff about whats got to be done. If you have a technical work item in IPv6 to develop I am more than glad to work on it as always. My customers are not stupid and I know some that have people working there that are as bright as architects as our finest in the IETF. They want IPv6 and they want it as soon as they can get it. They know they can't get it now and I have told them they can't from me right now anyway. When? I tell I think in 12-18 months. I take your mail to be filerbusting in the IETF and what needs to be worked on is being worked on. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 12:00:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17572; Thu, 6 Mar 1997 11:52:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17565; Thu, 6 Mar 1997 11:51:56 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA22523; Thu, 6 Mar 1997 11:52:34 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA01519 for ; Thu, 6 Mar 1997 11:51:35 -0800 Received: from big-dogs.cisco.com (herndon-dhcp-92.cisco.com [171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id LAA03246; Thu, 6 Mar 1997 11:52:00 -0800 (PST) Message-Id: <3.0.32.19970306145155.006a2f2c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Mar 1997 14:51:58 -0500 To: Peter Grehan From: Paul Ferguson Subject: (IPng 3205) Re: we need it.... Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 837 At 11:04 AM 3/4/97 -0800, Peter Grehan wrote: > >> Certainly, increased address space is one benefit, but with this >> 'benefit' comes other more insidious problems. > > I don't know how you could have a more insidious problem than >lack of address space: would you care to elaborate the problems >that increasing this causes ? > >Peter. > Then you've obviously not thought the problem through completely. I think Yakov did a good job of succinctly stating the resulting problem -- maintaining routability to a vastly increased address space. - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 12:01:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17581; Thu, 6 Mar 1997 11:52:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17574; Thu, 6 Mar 1997 11:52:14 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA22608; Thu, 6 Mar 1997 11:52:52 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA01669 for ; Thu, 6 Mar 1997 11:51:55 -0800 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id LAA11754; Thu, 6 Mar 1997 11:52:24 -0800 Message-Id: <199703061952.LAA11754@puli.cisco.com> To: Peter Grehan cc: ipng@sunroof.eng.sun.com Subject: (IPng 3206) Re: we need it.... In-reply-to: Your message of "Tue, 04 Mar 97 11:04:39 PST." <331C7247.446B9B3D@ipsilon.com> Date: Thu, 06 Mar 97 11:52:23 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 789 Peter, > > Certainly, increased address space is one benefit, but with this > > 'benefit' comes other more insidious problems. > > I don't know how you could have a more insidious problem than > lack of address space: would you care to elaborate the problems > that increasing this causes ? Getting more address space is necessary, but not sufficient. The ability to maintain routability to all these addresses is what makes these addresses useful. Please read RFC2008 for more on this subject. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 12:09:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17612; Thu, 6 Mar 1997 11:57:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17587; Thu, 6 Mar 1997 11:55:27 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA23538; Thu, 6 Mar 1997 11:56:05 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA03229; Thu, 6 Mar 1997 11:54:53 -0800 Received: from big-dogs.cisco.com (herndon-dhcp-92.cisco.com [171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id LAA06917; Thu, 6 Mar 1997 11:55:46 -0800 (PST) Message-Id: <3.0.32.19970306145541.006a44cc@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Mar 1997 14:55:44 -0500 To: bound@zk3.dec.com From: Paul Ferguson Subject: (IPng 3207) Re: Reality check [Was: Re: we need it.... ] Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 558 At 02:21 PM 3/6/97 -0500, bound@zk3.dec.com wrote: > >I take your mail to be filerbusting in the IETF and what needs to be >worked on is being worked on. > Okay, Jim -- I'll stay my remarks. You just seemed to have missed everything that I said, however. *sigh* - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 12:10:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17625; Thu, 6 Mar 1997 11:59:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17617; Thu, 6 Mar 1997 11:59:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA24547; Thu, 6 Mar 1997 12:00:01 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA05377 for ; Thu, 6 Mar 1997 11:58:57 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA19415; Fri, 7 Mar 1997 06:59:42 +1100 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com Subject: (IPng 3208) Re: IPng Interim Meeting Minutes In-Reply-To: Your message of "Thu, 06 Mar 1997 08:34:20 PST." <199703061634.IAA00280@puli.cisco.com> Date: Fri, 07 Mar 1997 06:59:42 +1100 Message-Id: <8420.857678382@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1038 Date: Thu, 06 Mar 97 08:34:20 PST From: Yakov Rekhter Message-ID: <199703061634.IAA00280@puli.cisco.com> So, you advocate monopoly ("send all packets bound to the New Provence prefix to the New Provence NAP") as a way of promoting competition. Yakov - you know better than that. "must be able to send" does not mean "must send". Whether it is a feasible solution or not, Christian's plan for legislatively enforced NAPs is no more a monopoly in any real sense that the use of default routes creates a monopoly. No real packets ever actually have to go that way. See this as similar to "all govt computer purchase must be able to support ISO OSI". So they are (were) able to... big deal. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 12:31:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA17733; Thu, 6 Mar 1997 12:26:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA17726; Thu, 6 Mar 1997 12:25:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA01680; Thu, 6 Mar 1997 12:26:30 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA18065 for ; Thu, 6 Mar 1997 12:25:27 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id PAA24782; Thu, 6 Mar 1997 15:26:20 -0500 Date: Thu, 6 Mar 1997 15:26:20 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703061526.ZM24780@seawind.bellcore.com> In-Reply-To: Yakov Rekhter "(IPng 3195) Re: IPng Interim Meeting Minutes" (Mar 6, 9:15am) References: <199703061715.JAA02972@puli.cisco.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Yakov Rekhter , huitema@bellcore.com (Christian Huitema) Subject: (IPng 3209) Re: IPng Interim Meeting Minutes Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1150 On Mar 6, 9:15am, Yakov Rekhter wrote: > Could the New Provence have more than one NAP ? If yes, are > there any constraints (aka regulations) wrt operations of these NAPs ? > If yes, would you please spell them out ? This is indeed a key question. The basic answer is indeed yes, and the requirement is that all NAP operators that serve the same prefix have to peer with each other, either directly or indirectly. This means, in practice, that all these NAP must have a complete routing table of all the ISP in the same area, e.g. maintained via BGP. Indeed, the request for complete interconnection boils down to a structure were "all NAP of New Provence are equivalent". However, there is a difference between "obtaining connectivity" and "obtaining all the throughput you want". This leaves ample room for market differentitation... -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 13:19:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00471; Thu, 6 Mar 1997 13:10:13 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00464; Thu, 6 Mar 1997 13:10:05 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA11560; Thu, 6 Mar 1997 13:10:43 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA00856 for ; Thu, 6 Mar 1997 08:55:10 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA24478; Thu, 6 Mar 1997 11:56:06 -0500 Date: Thu, 6 Mar 1997 11:56:06 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703061156.ZM24476@seawind.bellcore.com> In-Reply-To: Yakov Rekhter "Re: (IPng 3185) Re: IPng Interim Meeting Minutes" (Mar 6, 8:34am) References: <199703061634.IAA00280@puli.cisco.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Yakov Rekhter , huitema@bellcore.com (Christian Huitema) Subject: (IPng 3210) Re: IPng Interim Meeting Minutes Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1278 On Mar 6, 8:34am, Yakov Rekhter wrote: > Subject: Re: (IPng 3185) Re: IPng Interim Meeting Minutes > Christian, > > > 5) Yes, this is a twist of today's topology. But it is in fact an > > enforceable twist, in particular one that can be enforced by local > > legislatures, e.g. by a decree that "if you want to sell Internet services > > to the population of New Provence, you have to be able to send all packets > > bound to the New Provence prefix to the New provence NAP." This is the > > main answer to Mike's question "why do you think (NAP) will continue to > > exist." > > So, you advocate monopoly ("send all packets bound to the New Provence > ) as a way of promoting competition. > Very interesting logic. Well, no, I do not actually invoke monopoly. I just have a poor english style. What I meant was "be able to send any packet bound to the New Provence prefix to the New Provence NAP, unless indeed you know a shorter path to the specific destination." -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 13:23:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00480; Thu, 6 Mar 1997 13:13:15 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00473; Thu, 6 Mar 1997 13:13:03 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA12359; Thu, 6 Mar 1997 13:13:41 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA08142 for ; Thu, 6 Mar 1997 13:12:35 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id QAA24922; Thu, 6 Mar 1997 16:13:27 -0500 Date: Thu, 6 Mar 1997 16:13:27 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703061613.ZM24920@seawind.bellcore.com> In-Reply-To: Yakov Rekhter "(IPng 3196) Re: IPng Interim Meeting Minutes" (Mar 6, 9:18am) References: <199703061718.JAA03146@puli.cisco.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Yakov Rekhter , bmanning@isi.edu Subject: (IPng 3211) Re: IPng Interim Meeting Minutes Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 599 > Yes, indeed. As I mentioned before, a NAP isn't that different > from an ISP. Changing the terminology isn't going to hide the essence. Well, if you limit the routes exchanges through the NAP to a strict prefix, i.e. local connectivity only, then a NAP is indeed very different from an ISP. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 13:33:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00508; Thu, 6 Mar 1997 13:21:14 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00499; Thu, 6 Mar 1997 13:20:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA14918; Thu, 6 Mar 1997 13:21:31 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA00419 for ; Thu, 6 Mar 1997 08:54:19 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA11150; Thu, 6 Mar 1997 11:44:13 -0500 (EST) Received: from tunsrv2-tunnel.imc.das.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA11197; Thu, 6 Mar 1997 11:44:07 -0500 Message-Id: <3.0.32.19970306084124.0071e5bc@netrix.lkg.dec.com> X-Sender: popmatt@netrix.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Thu, 06 Mar 1997 08:44:05 -0800 To: ipng@sunroof.eng.sun.com From: Matt Thomas Subject: (IPng 3212) Re: 64-bit node IDs Cc: Matt Crawford Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1985 At 04:03 PM 3/5/97 -0600, Matt Crawford wrote: > Updating IPv6-over-{Ethernet, FDDI} for 64 bit node ID's is on my >plate. Accordingly, I'm looking into these new 64 bit IEEE addresses >which were all the buzz at PAL 1. Although I'm not ready to submit >new drafts, there seems to be an interesting point to consider >already. However, that depend on how the ESD draft defines for the format and that hasn't been done yet. > The SCI "tutorial" on the IEEE web site (really just a one page >illustration) shows the OUI in the first 24 bits, with the vendor's >part extended to 40 bits. I've seen no officially blessed mapping >from 48 bit addresses to 64 bits, but it seems clear that the most >natural mapping is to append sixteen zero bits. Thus an ethernet >interface with MAC address 12-34-56-78-9a-bc would have a 64 bit >address token 1234:5678:9abc:0000. (This looks nice for boxes that >want to auto-configure many addresses per interface, doesn't it?) I don't think that's true. From what I've read of EUI-64, the 40 bit field is in MSB format and incremented for each new device. Thus the mapping is 1234:5600:0078:9abc which doesn't cause as much of a problem for neighbor discovery. However, I've been thinking of defining the ESD such that a EUI-64 of 11-22-33-44-55-66-77-88 would result in an ESD of 44-55-11-22-33-66-77-88 thus preserving the current 802 behavour. This will allow ESD-aware implementations to work with non-ESD aware implementations. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 14:06:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00654; Thu, 6 Mar 1997 13:58:18 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00647; Thu, 6 Mar 1997 13:58:10 -0800 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA25100; Thu, 6 Mar 1997 13:58:49 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA18451 for ; Thu, 6 Mar 1997 13:58:48 -0800 Received: by snoopy.agile.com with Internet Mail Service (5.0.1389.3) id <01BC2A50.1C7DAD80@snoopy.agile.com>; Thu, 6 Mar 1997 17:02:02 -0500 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Cc: "'kre@munnari.oz.au'" Subject: (IPng 3213) Re: 2 faced DNS is here to stay Date: Thu, 6 Mar 1997 17:02:01 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2849 Hi kre, > If this is the sole remaining justification for this, can we > perhaps explore other possible ways, before spending a lot of > time worrying about how to force the DNS to do something we might > not really need it to do? In order for a source to know that it can use a site-local prefix for source and destination addresses (which may well be desirable for various reasons, including local policy), it has to either: A) be told to use it B) infer from available information that it should use it C) ask the other system if it can use it D) tell the other system to use it You're correct in pushing back on the two-faced DNS server, but everyone is accustomed to the idea of asking the DNS server what address to use, and being told the answer. So the A-model has a strong intrinsic appeal. Your suggestion of putting the smarts in the resolver sounds to me like the B-model, and that might be reasonable if we now have a hard RG/ESD address format to work with. But I would still worry about the subtleties of doing this right... What of the C-model? Just as we have to store a packet before transmitting if doing on-link Neighbor Discovery, should we have a conceptual on-site Townie Discovery, and send an ICMP message to a destination address using our own site-local address? If the destination responds (with its site-local address), then we cache the global/site-local mapping and carry on using site-local addresses. If our ICMP message hits a site border router, it will return an OFF-SITE Destination message, and we'll use global addresses. Finally, the D-model...we could perhaps define a Hop-by-Hop option to be used when initiating communications with a remote destination, in which to include our own site-local address (and perhaps a checksum delta, just to make the other end's job easier)...again, a site border router would be required to enforce this mechanism, perhaps by zero'ing out the contents of the option. If the destination receives it, it could treat it as it is was the actual source address. And I'm sure there are other mechanisms...and perhaps there are other models I haven't stumbled across. Should we try to enumerate more mechanisms, or start weighing the costs of each of these? A lot comes down to where we want to put the complexity and processing load...on each individual host, in the network layer of both hosts and routers, in the applications (hosts or DNS servers). Where do we want the delays in the system? How static/dynamic should the knowledge be? What else need we worry about? Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 14:37:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00738; Thu, 6 Mar 1997 14:26:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00731; Thu, 6 Mar 1997 14:25:35 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA03426; Thu, 6 Mar 1997 14:26:13 -0800 Received: from cannes.aa.ans.net (cannes.aa.ans.net [198.83.22.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA07076 for ; Thu, 6 Mar 1997 14:24:43 -0800 Received: from cannes.aa.ans.net (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.3) with ESMTP id RAA03320; Thu, 6 Mar 1997 17:25:21 -0500 (EST) Message-Id: <199703062225.RAA03320@cannes.aa.ans.net> To: huitema@bellcore.com (Christian Huitema) cc: "Mike O'Dell" , Scott Bradner , ipng@sunroof.eng.sun.com Subject: (IPng 3214) Re: IPng Interim Meeting Minutes In-reply-to: Your message of "Thu, 06 Mar 1997 10:32:23 EST." <9703061032.ZM24334@seawind.bellcore.com> Date: Thu, 06 Mar 1997 17:25:21 -0500 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1038 >4) The restricted peering basically removes the "free transit" pitfall. >ISPs connected to the NAP could only speak to the Internet at large if >they obtain peerings from transit providers -- or if they connect to other >metropolis by themselves. The economic model is sound: you pay for what >you send. Peering between ISPa and ISPb achives the following two: a. ISPa's customer talk to ISPb's customer only and/or b. ISPa's customer talk to customers of ISPs that ISPb provides transit with. (ISPb is a transit provider in this case.) In most of the cases now-a-days, peering between ISPs just to achive a) alone, not b). Your above peering model eliminates that possibility which happen to be the common practice today. --Jessica ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 14:40:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00747; Thu, 6 Mar 1997 14:28:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00740; Thu, 6 Mar 1997 14:27:50 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04150; Thu, 6 Mar 1997 14:28:24 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA08264; Thu, 6 Mar 1997 14:27:23 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA03434; Thu, 6 Mar 1997 17:21:50 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19320; Thu, 6 Mar 1997 17:21:48 -0500 Message-Id: <9703062221.AA19320@wasted.zk3.dec.com> To: Paul Ferguson Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: (IPng 3215) Re: Reality check [Was: Re: we need it.... ] In-Reply-To: Your message of "Thu, 06 Mar 97 14:55:44 EST." <3.0.32.19970306145541.006a44cc@lint.cisco.com> Date: Thu, 06 Mar 97 17:21:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2134 Paul, Look I am just one person. Don't not defend or state what you want, not that you would. I am just rabbid about this OK. I fully admit in public I Jim Bound will do everything I can to get IPv6 to Full Standard and Deployed. When I see handwaving, stalling, and worse yet any entity who I feel that is holding up IPv6 for any reason I again will do everything to make them defend it. I have watched and listened to so much garbage and filerbusting about IPv6 I am just not going to take it. Enough is enough. Sometimes on IPv6 in the IETF I feel like I am in an ISO refugee camp or something. In this case you want to start yet another working group? You said in your mail (not quoting exactly) and some of these problems may not need IPv6 fix. WHat does that mean "private-addresses" and IPv4 NAT. I don't think we need another working group and I admit I did not see your purpose in your mail? I will re-read it again. I think private addresses and NAT can be done with IPv6 in the next 12 months on Intranets and I do not think we should propogate the use of IPv4 into the customer environment for long term networking planning anymore other than to interoperate with IPv6. Please don't take my mail personal. I know thats hard because of the email interface. But I see no other way to drive my point than to be very intense. I also don't want to miss anyones points and I am completely open to any input unless it is not to further the cause of IPv6 being deployed in the market. In the latter it will have to be explained to me clearly to get my support and for me to shut up. We have some fixing to do and we are working on it (and I just found another bug in FTP I think we may all have for IPv6). Now I feel bad as I usually am in synch with you. Oh well... Beer in Memphis is on me (thats one beer Paul). /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 14:43:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00760; Thu, 6 Mar 1997 14:30:37 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00753; Thu, 6 Mar 1997 14:30:18 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA02677; Thu, 6 Mar 1997 14:30:58 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20627; Thu, 6 Mar 1997 14:30:58 -0800 Date: Thu, 6 Mar 1997 14:30:58 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199703062230.OAA20627@bobo.eng.sun.com> To: kre@munnari.OZ.AU Subject: (IPng 3216) Re: 2 faced DNS is here to stay Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1006 > Sure - a two faced DNS might be a means by which the use of site > lcoal addresses for site local communications is encouraged, or > perhaps (just perhaps) enforced, but it is most certainly NOT the > only way it could be done. Do you have an example of another solution? Does that solution require that each host in a site be configured to know the "site prefix"? The reason I'm asking is because the only solution I can imagine is one where the host receives the global addresses from DNS and somehow determines (based on the address) that the peer is in the same site. It could trivially do this if it knew (all) the site prefix(es). But we don't want to require that all hosts have such information ... Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 15:21:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00944; Thu, 6 Mar 1997 15:12:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00937; Thu, 6 Mar 1997 15:12:18 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA17110; Thu, 6 Mar 1997 15:12:34 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA27029 for ; Thu, 6 Mar 1997 15:11:35 -0800 Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA358202; Thu, 6 Mar 1997 18:12:29 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id SAA87254; Thu, 6 Mar 1997 18:12:29 -0500 Received: from hygro.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17384; Thu, 6 Mar 1997 18:12:12 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id OAA00360; Thu, 6 Mar 1997 14:19:07 -0500 Message-Id: <199703061919.OAA00360@hygro.raleigh.ibm.com> To: Paul Ferguson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3217) Re: we need it.... In-Reply-To: Your message of "Thu, 06 Mar 1997 13:20:52 EST." <3.0.32.19970306132048.0071fa5c@lint.cisco.com> Date: Thu, 06 Mar 1997 14:19:07 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 768 > Certainly, increased address space is one benefit, but with this > 'benefit' comes other more insidious problems. Could you please list those problems (i.e., are we working on them)? Increasing the size of the routing tables doesn't count. Routing table sizes are defined (roughly) by the number of prefixes in the DFZ. How many addresses a prefix covers is irrelvent, so giving end sites lots of address space doesn't imply an increase in the number of prefixes in the DFZ. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 15:35:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00999; Thu, 6 Mar 1997 15:25:51 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00992; Thu, 6 Mar 1997 15:25:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA21074; Thu, 6 Mar 1997 15:26:18 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA02547 for ; Thu, 6 Mar 1997 15:24:58 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id SAA27083; Thu, 6 Mar 1997 18:25:39 -0500 Date: Thu, 6 Mar 1997 18:25:39 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703061825.ZM27081@seawind.bellcore.com> In-Reply-To: Jessica Yu "Re: (IPng 3185) Re: IPng Interim Meeting Minutes" (Mar 6, 5:25pm) References: <199703062225.RAA03320@cannes.aa.ans.net> X-Mailer: Z-Mail (3.2.1 10oct95) To: Jessica Yu , huitema@bellcore.com (Christian Huitema) Subject: (IPng 3218) Re: IPng Interim Meeting Minutes Cc: "Mike O'Dell" , Scott Bradner , ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3286 On Mar 6, 5:25pm, Jessica Yu wrote: > Subject: Re: (IPng 3185) Re: IPng Interim Meeting Minutes > > >4) The restricted peering basically removes the "free transit" pitfall. > >ISPs connected to the NAP could only speak to the Internet at large if > >they obtain peerings from transit providers -- or if they connect to other > >metropolis by themselves. The economic model is sound: you pay for what > >you send. > > Peering between ISPa and ISPb achives the following two: > > a. ISPa's customer talk to ISPb's customer only and/or > b. ISPa's customer talk to customers of ISPs that ISPb provides transit > with. (ISPb is a transit provider in this case.) > > In most of the cases now-a-days, peering between ISPs just to achive a) alone, > not b). Your above peering model eliminates that possibility which happen to > be the common practice today. The idea is that "a NAP does not have to be an ISP." At least, a geographic NAP does not have. Because it is not an ISP, it only offer a very restricted peering. Typically it will: a) allows local ISPs to achieve full local connectivity. That is, if ISP A has been authorized to use an address prefix of the form "area-x.isp-a", and if ISP B has been authorized to use an address prefix of the form "area-x.isp-b", then the NAP guarantees that any customer of will have basic connectivity with any customer of ISP-B. In that case, the BGP information between ISP-A and the NAP will be the following: NAP-X to ISP-A: AS-PATH = SEQUENCE (NAP-x-AS) REACHES area-x.isp-b.*, area-x.isp-c.*, .... area-x.isp-z.* (and nothing else) ISP-A to NAP-X: AS-PATH = SEQUENCE (ISP-A-AS) REACHES area-x.isp-a.* (any path that does not lead to area-x would be ignored) b) allow transit ISPs to aggregate the complete area, without providing free Internet wide transit. In that case, the BGP information between ISP-T (transit) and the NAP will be the following: NAP-X to ISP-A: AS-PATH = SEQUENCE (NAP-x-AS) REACHES area-x.* ISP-T to NAP-X: no announce, unless ISP-T also manages addresses in the area-X prefix directly. The NAP would *NOT* act as a reseller of "transit routes". These routes would have to be bought separately by the various ISPs. The decision to announce an aggregate route or a set of explicit path depends of the "contract" between the provider and the NAP. Managing an explicit list allows for the management of several NAPs in the same area. Hey, i *know* that this is not the current practice. I am proposing to constraint the topology in order to avoid routing explosion, and I believe that the scheme that I just outlined does solve the problem, at least partially, and can be implemented without exotic routing technology. The practical limitation is that geographic addressing, in the current state of the art, can only be offered to large aggregates -- ISPs or large corporations. Managing a Manhattan size routing table would definitely require some exotic technology. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 16:23:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01251; Thu, 6 Mar 1997 16:14:59 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01244; Thu, 6 Mar 1997 16:14:51 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA04418; Thu, 6 Mar 1997 16:15:29 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA22537 for ; Thu, 6 Mar 1997 16:14:30 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id QAA13997; Thu, 6 Mar 1997 16:14:50 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <3.0.32.19970306145155.006a2f2c@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Mar 1997 16:16:42 -0800 To: Paul Ferguson From: Steve Deering Subject: (IPng 3219) Re: we need it.... Cc: Peter Grehan , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2352 Paul Ferguson wrote: > At 11:04 AM 3/4/97 -0800, Peter Grehan wrote: > > > > >> Certainly, increased address space is one benefit, but with this > >> 'benefit' comes other more insidious problems. > > > > I don't know how you could have a more insidious problem than > >lack of address space: would you care to elaborate the problems > >that increasing this causes ? > > Then you've obviously not thought the problem through completely. > > I think Yakov did a good job of succinctly stating the resulting > problem -- maintaining routability to a vastly increased address > space. Paul, Since we IPv6 advocates are sometimes admonished not to indulge in "scare-mongering", I feel obliged to admonish back. This particular line -- that bigger addresses necessarily mean more routes -- is just not true, and I wish people would stop insinuating that it is. If it were true, we had better hurry up and transition to a *smaller* address space, since a 32-bit space is (most would agree) too big to flat-route with today's or near-future routers, and NAT technology threatens to make the whole 32-bit space (minus the Class Ds) available for default-free routing. Route aggregation and address size are largely orthogonal issues. For route aggregation, what matters is how many levels of hierarchy there are and how "populated" each of those levels is, not how many bits there are in the whole address. (Though a larger address makes it more practical to have more layers of hierarchy, and thus better long-term aggregation.) I get this vague feeling that maybe some people think that keeping the address fixed at 32 bits is the way to control route entropy. Surely the real solution lies elsewhere (renumbering technology, topology engineering, whatever). Delaying the migration to IPv6 will not make the aggregation problem go away, and migrating to IPv6 will not make the aggregation problem any worse -- on the contrary, it is likely to make it easier to solve, with its better renumbering support and more space for additional levels of hierarchy. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 17:08:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01396; Thu, 6 Mar 1997 17:00:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01389; Thu, 6 Mar 1997 17:00:12 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA15538; Thu, 6 Mar 1997 17:00:50 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA09473 for ; Thu, 6 Mar 1997 16:59:55 -0800 Received: from big-dogs.cisco.com (herndon-dhcp-92.cisco.com [171.68.53.92]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id RAA20041; Thu, 6 Mar 1997 17:00:48 -0800 (PST) Message-Id: <3.0.32.19970306200044.006e3090@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 06 Mar 1997 20:00:49 -0500 To: Steve Deering From: Paul Ferguson Subject: (IPng 3220) Re: we need it.... Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1125 At 04:16 PM 3/6/97 -0800, Steve Deering wrote: > >I get this vague feeling that maybe some people think that keeping the >address fixed at 32 bits is the way to control route entropy. Surely >the real solution lies elsewhere (renumbering technology, topology >engineering, whatever). Delaying the migration to IPv6 will not make the >aggregation problem go away, and migrating to IPv6 will not make the >aggregation problem any worse -- on the contrary, it is likely to make >it easier to solve, with its better renumbering support and more space for >additional levels of hierarchy. > Steve, Apologies to anyone who think I'm indulging in 'scare mongering,' but the I'm afraid that only time, trial and error will prove out your points. I'm afraid I don't share your optimism. Now back to your regularly scheduled programming. - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 21:12:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA01712; Thu, 6 Mar 1997 21:05:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA01705; Thu, 6 Mar 1997 21:04:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA22700; Thu, 6 Mar 1997 21:05:28 -0800 Received: from mail.ocs.com.au ([203.34.97.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA09709 for ; Thu, 6 Mar 1997 21:04:34 -0800 Received: (qmail 8529 invoked by uid 502); 7 Mar 1997 05:04:29 -0000 Message-ID: <19970307050429.8526.qmail@mail.ocs.com.au> Received: (qmail 8513 invoked from network); 7 Mar 1997 05:04:26 -0000 Received: from ocs4.ocs?net (root@192.168.255.4) by mail.ocs.com.au with SMTP; 7 Mar 1997 05:04:26 -0000 From: Keith Owens To: "Harrington, Dan" cc: ipng@sunroof.eng.sun.com, "'kre@munnari.oz.au'" Subject: (IPng 3221) Re: 2 faced DNS is here to stay In-reply-to: Your message of "Thu, 06 Mar 1997 17:02:01 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Mar 1997 16:08:06 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2159 On Thu, 6 Mar 1997 17:02:01 -0500, "Harrington, Dan" wrote: >In order for a source to know that it can use a site-local >prefix for source and destination addresses (which may well >be desirable for various reasons, including local policy), >it has to either: > > A) be told to use it > B) infer from available information that it should use it > C) ask the other system if it can use it > D) tell the other system to use it Thought experiment. An organisation has a physically partitioned network, sections A and B. There is a fast internal link between A and B, for backup both sections can also communicate via the Internet (each has a slower Internet link). If the internal link is up, A and B can communicate using site-local addresses. If the internal link is down, they must route externally and use Internet addresses. How do they tell which to use? One possibility is to ignore the problem, mandate that site-local addresses can only be used on a "physically well connected" site. Then define "physically well connected" (the hard part). If site-local addresses are acceptable in such a configuration, the decision mechanism must have knowledge of the current routing topology. Adding this to DNS (option A) or to each host (option B) is not really practical. A solution requiring routing knowledge is best left to the routers, options C or D. However both C and D assume that the route will not change after the connection is started. Another problem with this configuration is what to do with existing connections when the route changes from internal to external or vice versa? Given the above, is it sensible to use site-local addresses when there is *any* possibility of packets routing via the Internet? If not, site-local addresses can only be used on an unconnected site or possibly on a site with a single Internet connection. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 22:09:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01744; Thu, 6 Mar 1997 22:01:28 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01737; Thu, 6 Mar 1997 22:01:19 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA00522; Thu, 6 Mar 1997 22:01:57 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA18873 for ; Thu, 6 Mar 1997 22:01:05 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id AAA03265; Fri, 7 Mar 1997 00:55:29 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16299; Fri, 7 Mar 1997 00:55:28 -0500 Message-Id: <9703070555.AA16299@wasted.zk3.dec.com> To: Yakov Rekhter Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3223) Re: IPng Interim Meeting Minutes In-Reply-To: Your message of "Thu, 06 Mar 97 05:29:56 PST." <199703061329.FAA24457@puli.cisco.com> Date: Fri, 07 Mar 97 00:55:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 507 Yakov, >It is on ftp-eng.cisco.com under /ftp/yakov/spa-vs-pac.ppt Thanks I got the slides and I need to study them. I think I get the point of the slides on the first veiwing, but will check again when more awake. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 6 22:26:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01770; Thu, 6 Mar 1997 22:18:29 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01763; Thu, 6 Mar 1997 22:18:22 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA02488; Thu, 6 Mar 1997 22:19:00 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA21413 for ; Thu, 6 Mar 1997 22:18:09 -0800 Received: from [171.69.116.91] ([171.69.116.91]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id WAA00506; Thu, 6 Mar 1997 22:18:53 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <3.0.32.19970306200044.006e3090@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Mar 1997 22:20:27 -0800 To: Paul Ferguson From: Steve Deering Subject: (IPng 3224) Re: we need it.... Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1645 >Apologies to anyone who think I'm indulging in 'scare mongering,' >but the I'm afraid that only time, trial and error will prove out >your points. I'm afraid I don't share your optimism. Paul, It's not optimism that provoked my imprudent response, but pessimism. I'm worried that FUD will kill IPv6 before it gets a fair trial. But I don't think optimism or pessimism need be part of the analysis of whether or not larger addresses necessarily imply less route aggregation. As I see it, the size and volatility of the routing system is bounded by the capacities of available routers and links, the capabilities of the humans that manage them, and the tolerance of the customers for poor service. The ISPs are not going to let their routing systems collapse just because the addresses got bigger. They will continue to have the same tools they have now to keep their loads within their capacities, whether that's forcing customers to renumber, refusing some routes and possibly letting the Internet partition, doing some cooperative topology engineering, or doing something else that hasn't been thought of yet. If you disagree, please explain why. Don't just make allusions to [paraphrasing] "insidious problems that come with increased address space" and then apologize and leave the discussion when the bases of those concerns are questioned. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 7 01:06:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA01862; Fri, 7 Mar 1997 00:58:40 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA01855; Fri, 7 Mar 1997 00:58:31 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA19124; Fri, 7 Mar 1997 00:59:09 -0800 Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA17779 for ; Fri, 7 Mar 1997 00:58:19 -0800 Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id JAA18804; Fri, 7 Mar 1997 09:59:09 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma018583; Fri Mar 7 09:58:11 1997 Received: from hades.mpn.cp.philips.com (hades.mpn.cp.philips.com [130.139.64.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970305) with ESMTP id JAA14440; Fri, 7 Mar 1997 09:58:09 +0100 Received: from pc239.nwm.wan.philips.com (pc239.nwm.wan.philips.com [161.89.1.239]) by hades.mpn.cp.philips.com (8.6.10/8.6.10-1.2a-960910) with SMTP id JAA15760; Fri, 7 Mar 1997 09:57:08 +0100 Message-Id: <1.5.4.32.19970307085655.006c0e6c@hades.mpn.cp.philips.com> X-Sender: rhunter@hades.mpn.cp.philips.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Mar 1997 09:56:55 +0100 To: ipng@sunroof.eng.sun.com From: Ray Hunter Subject: (IPng 3225) Re: 2 faced DNS is here to stay Cc: Keith Owens Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3574 This thought experiment is attempting to do MORE than we have with IPv4. I do not see as an end user of IP that it is a problem that the IETF should address. Today, we use BGP for inter AS routing and OSPF/EIGRP/RIP/whatever for internal site routing. If my internal (subnet) based routing breaks, I don't expect that my external (class based network) routing will fix this. You should mandate that people have to provide their own internal redundancy. That is not unreasonable. People accept that today. Otherwise you are losing the very important disctinction between the internal and external topology which GSE was trying to enforce. I _like_ this strong distinction between internal and external. My expectations for the reliability and performance required for these types of traffic are very different. At 04:08 PM 3/7/97 +1100, you wrote: >On Thu, 6 Mar 1997 17:02:01 -0500, >"Harrington, Dan" wrote: >>In order for a source to know that it can use a site-local >>prefix for source and destination addresses (which may well >>be desirable for various reasons, including local policy), >>it has to either: >> >> A) be told to use it >> B) infer from available information that it should use it >> C) ask the other system if it can use it >> D) tell the other system to use it > >Thought experiment. > >An organisation has a physically partitioned network, sections A and B. >There is a fast internal link between A and B, for backup both sections >can also communicate via the Internet (each has a slower Internet >link). > >If the internal link is up, A and B can communicate using site-local >addresses. If the internal link is down, they must route externally >and use Internet addresses. How do they tell which to use? > >One possibility is to ignore the problem, mandate that site-local >addresses can only be used on a "physically well connected" site. Then >define "physically well connected" (the hard part). > >If site-local addresses are acceptable in such a configuration, the >decision mechanism must have knowledge of the current routing topology. >Adding this to DNS (option A) or to each host (option B) is not really >practical. A solution requiring routing knowledge is best left to the >routers, options C or D. > >However both C and D assume that the route will not change after the >connection is started. Another problem with this configuration is what >to do with existing connections when the route changes from internal to >external or vice versa? > >Given the above, is it sensible to use site-local addresses when there >is *any* possibility of packets routing via the Internet? If not, >site-local addresses can only be used on an unconnected site or >possibly on a site with a single Internet connection. > > >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com > > Ray Hunter on contract to Origin Building VA-130, Postbus 218, 5600MD Eindhoven, The Netherlands. email: Ray.Hunter@mpn.cp.philips.com email: Ray.Hunter@globis.net www: http://www.globis.net/~rhunter phone: +31 40 2787988 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 7 05:20:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA02188; Fri, 7 Mar 1997 05:09:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA02181; Fri, 7 Mar 1997 05:09:44 -0800 From: Martin.Pabst@mch.sni.de Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA08300; Fri, 7 Mar 1997 05:10:22 -0800 Received: from thoth.mch.sni.de (thoth.mch.sni.de [192.35.17.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id FAA17316 for ; Fri, 7 Mar 1997 05:09:33 -0800 Received: from rhodos.mch.sni.de (rhodos.mch.sni.de [139.22.10.131]) by thoth.mch.sni.de (8.8.5/8.8.5) with SMTP id OAA23906 for <@mail:ipng@sunroof.Eng.Sun.COM>; Fri, 7 Mar 1997 14:10:20 +0100 (MET) Date: Fri, 7 Mar 97 14:09 MET Message-ID: <9703071409.AA02440@rhodos.mch.sni.de> To: bound@zk3.dec.com, pferguso@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3226) Re: Reality check Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2844 Paul, I agree with you completely. Rest to say, that I don't understand why we ipv6 engeneers could be pressed by the anxious desires of customers. The only possible menace in an enterprise only and finally can origin from competitors. - Who are the competitors of ipv6? - The impatiant customers seem to be the noisy ones; but I think the quiet majority, including our descendants, the coming generation of IT users, prefer to await a well working and extendable ipv6. Jim, I honour your efforts to bring further ipv6 and to accelerate the discussion. I don't agree with that demonstrated lack of netiquette and politeness, e.g.: > I take your mail to be filerbusting in the IETF and what needs to be > worked on is being worked on. > But if your going to use handwaving per the TCP/UDP discussion I will > just delete your mail. > I think unless we proceed towards this simple approach we will still be > discussing it in 1999, and maybe even not have any running code. > Please don't take my mail personal. I know thats hard because of the > email interface. But I see no other way to drive my point than to be > very intense. That style can't replace any arguments, at least for us technicals. Furthermore, with that hurry up, time can be wasted by excluding existing results. For example, with the integration of Dan's draft on link local address resolution into the recent discussion, the problems with the following would have been evident: > garcia.trip.dead.com IN AAAA 4F::ee:cd:aa:01:45:ff:ac:1e > IN AAAA FED0::ee:cd:aa:01:45:ff:ac:1e > > The first AAAA is a global provider based unicast address the second is > a site local address. Also be aware that with every pressure message you send, you are provoking a lot of meta discussion (wich was about 50% this week). I don't see any necessity nor justification for losing style and forms within the discussions. Beside the inherent danger of every forum of not reaching its aims in time, this I estimate as a real menace of the working group. Martin ------------------------------------------+------------------------------------ Martin Pabst | e-mail: Martin.Pabst@mch.sni.de Siemens Nixdorf Informationssysteme AG | phone: ..49-89-636-48074 OEC HES XP1 | fax: ..49-89-636-48976 Otto-Hahn-Ring 6 / 81739 Munich / Germany | ------------------------------------------+------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 7 07:21:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02383; Fri, 7 Mar 1997 07:13:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02376; Fri, 7 Mar 1997 07:13:18 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA00975; Fri, 7 Mar 1997 07:13:57 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA03600 for ; Fri, 7 Mar 1997 07:13:07 -0800 Received: by snoopy.agile.com with Internet Mail Service (5.0.1389.3) id <01BC2AE0.D41EF210@snoopy.agile.com>; Fri, 7 Mar 1997 10:17:57 -0500 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Cc: "'kaos@ocs.com.au'" Subject: (IPng 3227) Re: 2 faced DNS is here to stay Date: Fri, 7 Mar 1997 10:17:56 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2007 Hi Keith, Thanks for the mail... > An organisation has a physically partitioned network, sections A and B. > There is a fast internal link between A and B, for backup both sections > can also communicate via the Internet (each has a slower Internet > link). > > If the internal link is up, A and B can communicate using site-local > addresses. If the internal link is down, they must route externally > and use Internet addresses. How do they tell which to use? Again, the site-local concept is a logical structure, which must be imposed upon a particular topology by means of policy and infrastructure. If a particular network has the characteristics you describe, it might make more sense to define it as two separate site-local domains (i.e. each end of the fast internal link becomes a site border router). > Given the above, is it sensible to use site-local addresses when there > is *any* possibility of packets routing via the Internet? If not, > site-local addresses can only be used on an unconnected site or > possibly on a site with a single Internet connection. By the current (loosely defined) definition of site-local, no site-local addresses can be routed on the Internet. As described in RFC 1884, site-local address are precisely what to use for an unconnected site...but there are many networks which are internally complex, with tightly controlled/administered points of access to the Internet. They would certainly be eligible for the imposition of site-local address policies...the key for us (in this working group) is to define a mechanism which will be available for those who wish to use it, without unduly burdening implementations and those users who choose not to use site-local. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 7 08:08:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02509; Fri, 7 Mar 1997 08:00:17 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02439; Fri, 7 Mar 1997 08:00:03 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12182; Fri, 7 Mar 1997 08:00:44 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA21951 for ; Fri, 7 Mar 1997 07:59:57 -0800 Received: from gungnir.fnal.gov ("port 36418"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IG7TP3HWR60007NN@FNAL.FNAL.GOV>; Fri, 07 Mar 1997 10:00:42 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA07041; Fri, 07 Mar 1997 10:00:41 -0600 Date: Fri, 07 Mar 1997 10:00:41 -0600 From: Matt Crawford Subject: (IPng 3228) Re: 2 faced DNS is here to stay In-reply-to: "07 Mar 1997 10:17:56 EST." <"D7014D55F851D0118203080009DCE8F102E262"@snoopy.agile.com> To: "Harrington, Dan" Cc: ipng@sunroof.eng.sun.com, "'kaos@ocs.com.au'" Message-id: <199703071600.KAA07041@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ > If the internal link is up, A and B can communicate using site-local > > addresses. If the internal link is down, they must route externally > > and use Internet addresses. How do they tell which to use? As both you and Dan H. said, they could be configured as two sites. Alternatively, their backup link through the internet could take the form of a tunnel between a router in each section of the network. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 7 09:20:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02599; Fri, 7 Mar 1997 09:12:40 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02592; Fri, 7 Mar 1997 09:12:36 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28428; Fri, 7 Mar 1997 09:13:18 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04040; Fri, 7 Mar 1997 09:12:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA01725; Thu, 6 Mar 1997 21:24:30 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA26457; Thu, 6 Mar 1997 21:25:09 -0800 Received: from apnic-ttc.apnic.net (apnic-ttc.apnic.net [203.178.142.242]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA12862 for ; Thu, 6 Mar 1997 21:24:17 -0800 Received: by apnic-ttc.apnic.net; id OAA02927; Fri, 7 Mar 1997 14:14:08 +0900 Received: from unknown(10.0.10.5) by apnic-ttc.apnic.net via smap (g3.0.3) id xma002924; Fri, 7 Mar 97 14:13:44 +0900 Received: from apnic.net (davidc@localhost) by palmtree.jp.apnic.net (8.8.2/8.8.2) with ESMTP id OAA01357; Fri, 7 Mar 1997 14:23:48 +0900 (JST) Message-Id: <199703070523.OAA01357@palmtree.jp.apnic.net> X-Authentication-Warning: palmtree.jp.apnic.net: davidc owned process doing -bs To: Steve Deering cc: Paul Ferguson , Peter Grehan , ipng@sunroof.eng.sun.com, davidc@apnic.net Subject: (IPng 3229) Re: we need it.... In-reply-to: Your message of "Thu, 06 Mar 1997 16:16:42 PST." Date: Fri, 07 Mar 1997 14:23:48 +0900 From: "David R. Conrad" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1842 Steve, In general I agree with your comments, however: >Delaying the migration to IPv6 will not make the aggregation problem >go away, and migrating to IPv6 will not make the aggregation problem >any worse Debatable: I can't count the number of times I (a member of the "prefix police" (by the way, where's my badge?)) have heard the justification "no need to conserve space since IPv6 is coming RSN" and of course, each block the registries allocate (if routed) becomes another unaggregatable routing entry. >-- on the contrary, it is likely to make it easier to solve, with its >better renumbering support Actually, if done "correctly", migrating to IPv6 can significantly reduce the aggregation problem as it will be easier to avoid the allocation mistakes that occured in the past. >and more space for additional levels of hierarchy. This is the part I have trouble understanding. People (I believe yourself included) are very unhappy with the implications of hierarchical addressing implemented via provider based addressing. Yet as far as I'm aware, provider based addressing is expected to be the most likely form of addressing available for production use with IPv6 in the near term. Why, if people are unhappy with hierarchy in v4, are they going to be happier with the same hierarchy under v6? You have the same problems, do you not? It seems to me if IPv6 automatic renumbering could be made to work, you'd have a real carrot to encourage people to migrate. As it is, I don't really see the urgency for migration... Regards, -drc ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 7 10:41:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02794; Fri, 7 Mar 1997 10:32:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02787; Fri, 7 Mar 1997 10:32:19 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA18274; Fri, 7 Mar 1997 10:32:59 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA02342 for ; Fri, 7 Mar 1997 10:32:12 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA08862; Fri, 7 Mar 1997 13:23:49 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20397; Fri, 7 Mar 1997 13:23:44 -0500 Message-Id: <9703071823.AA20397@wasted.zk3.dec.com> To: Cc: pferguso@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 3230) Re: Reality check In-Reply-To: Your message of "Fri, 07 Mar 97 14:09:00 +0700." <9703071409.AA02424@rhodos.mch.sni.de> Date: Fri, 07 Mar 97 13:23:44 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2307 Martin, I hear you. If you don't like my style delete my mail. I have had plenty of off-line mail from many people to keep going. I don't think I was impolite either. As far as meta-pressure. If one can't stand the heat get out of the fire. This is intense stuff and lots to do. I don't know any IT manager that is not concerned about the long term viability of IPv4. It is not just me it is also folks like Bob Metcalfe, and any small ISP I know trying to make a business on the Internet. This is why the Christian Huitema, Mike O'dell, and Yakov Rehkter thread is so important. As far as the link-name draft. I think this is not even close to anything that is top priority. So you have to key in a link-local address use cut/paste. I do believe it is desirable though and needed for user friendliness. But I hope users don't have to mess with link-local addresses long term. Now as an example. Because I say its not top priority that does not meean it is not top priority for the rest of the working group or the IETF. But in this new social world we live in we are supposed to not say what I said above and have a strong opinion. But I don't accept this new social world and don't like it and I don't care at all about being politically correct. I am also not yelling "fire" in a theatre with my consistent agreement that IPv6 is not ready for prime time TV. My fist is also not touching anyones nose. If no one is dead in the morning, in jail, or in the hospital then nothing really happened that bad a friend of mine says. That is extreme but pretty much how I view it. There is a certain type of American that is very intense and I don't think the norm. I am one of them. I am not going to change. I have met non-Americans with my philosophy all over the earth and most have similar backgrounds. So as much as I try to understand other cultures outside of the U.S. and "styles" and even adapt when I can I suggest those outside of the U.S. understand the different American styles too. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 7 17:47:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA03924; Fri, 7 Mar 1997 17:39:25 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA03917; Fri, 7 Mar 1997 17:39:21 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA26421; Fri, 7 Mar 1997 17:40:04 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04375; Fri, 7 Mar 1997 17:39:31 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA03325; Fri, 7 Mar 1997 14:28:47 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA11263; Fri, 7 Mar 1997 14:29:27 -0800 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA06840 for ; Fri, 7 Mar 1997 14:28:44 -0800 Received: from fleck.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA26248; Fri, 7 Mar 97 17:22:00 EST Received: by fleck.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id RAA25231; Fri, 7 Mar 1997 17:29:39 -0500 Date: Fri, 7 Mar 1997 17:29:39 -0500 Message-Id: <199703072229.RAA25231@fleck.IOL.UNH.EDU> To: ipng@sunroof.eng.sun.com Subject: (IPng 3232) Structured ESD / DHCP variant From: Jeremy McCooey Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3864 In the GSE model, a "site" is still identified by its location. Also, it seems that there are but a few uses for an unstructured ESD. The basic arguments against a structured ESD seem to involve (1) the additional demands upon a registry, and (2) the problem of autoconfiguration when many octets of the ESD are used for structure. I feel that GSE+ makes some advances, but in the process it associates the ESD with the location of the node within the site and brings routing into the lower 64 bits. I haven't seen this scheme suggested yet, so I submit it for consideration. Hopefully it will at least inspire someone to come up with a better way of doing this. If ESDs are to be used, I think they should be as useful as possible. ---- Only 24 bits ( or maybe up to 28 bits ) of the ESD are used for identification of a node within a site ( the "NodeID" ). The remaining bits of the ESD are used for identification ( perhaps hierarchical ) of the site itself ( the "SiteID" ). All of these "SiteIDs" would be of the same length, and a single SiteID should be enough for any site, thus minimizing the demands upon a registry. If per-host configuration is done manually, no additional protocol complexity is required. For autoconfiguration, I propose the following steps. [Bootstrapping] First, the node performs standard DAD on-link using its MAC address. Link-local addresses need not change. The node appends the lower 64 bits of this address to an advertised prefix. Thus, the full 128 bits of this address are guaranteed to be unique. This address is used solely for communication with the DHCP-like "ESD server." [Client-Server relationship] Using the above "restricted" address, the node requests an ESD from the server. The request would include the MAC address of the requesting node. If the server has no entry in its database, it finds the next available ESD, creates an entry for this MAC address, and returns the ESD to the requesting node. If the server already has an entry in its database for the requesting node, then it returns the previously-allocated ESD. There would need to be some kind of handshaking involved to prevent off-site nodes from creating bogus entries. Note that the process by which a new ESD is chosen could be an administrative decision. The client, upon receipt of its ESD, is then free to form its permanent address and potentially store its ESD in some kind of nonvolatile memory. For those devices without MAC addresses, there are ( at least ) a couple possibilities. For something like a modem pool, one could configure an address pool using some subset of the available NodeIDs. Also, one could set aside some set of NodeIDs for temporary usage on the server itself, and these IDs could be given without a supplied MAC address. This would perhaps require some way to "refresh" the NodeID for extended use. I suspect that many people will frown upon the idea of using a server for autoconfiguration; however, I feel that the benefit of a structured ESD is enough to merit this approach. Consider: Usually this process will occur only when a machine is first used. DNS is used much more often. If you are willing to rely upon DNS a lot of the time, why not rely upon the ESD server a little of the time? :) Jeremy -- +---------------------------------+-------------------+ | Jeremy McCooey | jam@iol.unh.edu | | UNH InterOperability Laboratory | 603-862-0090 | | IP/Routing Consortium | | +---------------------------------+-------------------+ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sun Mar 9 22:59:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA06585; Sun, 9 Mar 1997 22:51:25 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA06578; Sun, 9 Mar 1997 22:51:11 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA28056; Sun, 9 Mar 1997 22:51:51 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id WAA19322 for ; Sun, 9 Mar 1997 22:51:41 -0800 Received: by mail.noris.net id <35197-1533>; Mon, 10 Mar 1997 07:51:36 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3233) Re: IPng Interim Meeting Minutes Date: 10 Mar 1997 07:51:22 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 53 Message-ID: <5g0b1a$1ke$1@work.smurf.noris.de> References: <9703051528.AA24060@wasted.zk3.dec.com> <9703051749.ZM23888@seawind.bellcore.com> <857604532.17950@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1490 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3039 In dist.ipng, article <857604532.17950@noris.de>, huitema@bellcore.com (Christian Huitema) writes: > Renumbering is important, but CIDR basically imposes two different kinds > of renumbering: > > 1) renumbering a site when the site owner decide to change provider, > > 2) renumbering all the clients of an ISP if that ISP decides to change > its transit provider. > Uh, no. Speaking as an ISP, I don't see any difference between and . What we need, in fact, is a reverse routing protocol. A routing protocol specifies external addresses and where to send packets addressed to them. A reverse routing protocol, therefore, specifies internal addresses and who's routing them to us. IMHO, that needs to be not much more than a (preferably authenticated) UDP packet "here's a list of your prefixes and their associated lifetimes" sent on link startup (and every few minutes thereafter) from the ISP to the customer. If that list changes, you find the prefix with the longest lifetime, alert the operator, and start renumbering after, say, half the remaining lifetime of the old prefix. Again IMHO, renumbering is _either_ so easy that it requires no human intervention at all, or we forget about it. There's no middle ground. I'm convinced that it is in fact possible to do "renumbering without human intervention". Fr that, of course, we do in fact need dynamic DNS updates. That includes stuff like "Hello, servers for .com" (or "Hello, old-secondary-server"), "here's our new list of name servers for foo.com and their addresses". Or in fact "Hello, server-of-ISP, this is the address of the DNS server which does our reverse lookup". Which means that the ISP's name server address(es?) and some sort of authorization token need to be included in the packet I alluded above, which is why this all gets very complicated very fast, which is why I'm not convinced that this'll be in the initial IPv6 deployment. But it needs to be there some time afterwards. OK, OK, I'll stop the handwaving. As I said, the basic packet format is pretty easy and an Internet-draft for it is hackupable in a day or so, but because of the DNS implications (I don't yet know anything about the present plans for DynDNS) I think I'll have to punt for now. :-( -- It is fruitless to attempt to indoctrinate a superannuated canine with innovative maneuvers. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 00:29:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA06658; Mon, 10 Mar 1997 00:21:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA06651; Mon, 10 Mar 1997 00:21:44 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA03865; Mon, 10 Mar 1997 00:22:24 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA02949 for ; Mon, 10 Mar 1997 00:22:16 -0800 Received: by mail.noris.net id <35197-2907>; Mon, 10 Mar 1997 09:22:24 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3234) Re: 2 faced DNS is here to stay Date: 10 Mar 1997 09:22:13 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 22 Message-ID: <5g0gbl$3n2$1@work.smurf.noris.de> References: <199703062230.OAA20627@bobo.eng.sun.com> <857690498.7636@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1492 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1204 Erik.Nordmark@Eng.Sun.COM (Erik Nordmark) writes: > > Does that solution require that each host in a site be configured > to know the "site prefix"? Host? Configured? They'll get it from the router/DHCP server/whoever. > [...] > But we don't want to require that all hosts have such information ... Unless we want address rewriting in the routers, which I thought the interim meering has decided we _don't_ want (very sensible, IMHO), then yes, every host does need to know their prefix(es). -- Copywight 1994 Elmer Fudd. All wights wesewved. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 03:30:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA06730; Mon, 10 Mar 1997 03:21:43 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA06723; Mon, 10 Mar 1997 03:21:35 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA15901; Mon, 10 Mar 1997 03:22:18 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA08800 for ; Mon, 10 Mar 1997 03:22:04 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA69370; Mon, 10 Mar 1997 11:22:09 GMT Date: Mon, 10 Mar 1997 11:22:09 GMT Message-Id: <9703101122.AA69370@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3235) Re: IPv6 priority field usage? To: petkos@cs.tut.fi (Koskelainen Petri) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199703061147.NAA24227@kaarne.cs.tut.fi> from "Koskelainen Petri" at Mar 6, 97 01:47:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1265 Petri, > I was just asking the status of that proposed change. > Is it now "official" or not. But I assume that > it is still a proposition.. > > Anyway, I'm against the change. > I'd like to keep the 4 bits priority field for end-to-end communication > although I admit that there are some problems in it > (it might encourage users to send unnecessary data to network). > > Since it is expected that end-to-end resource reservations (rsvp et al) > are not available in world-wide Internet (at least for unicast) > there should be some tools available for sender to improve the quality > of its own stream. Best way to achieve this is to classify > packets. Expected by who? And what timescale are you considering? And in any case, the sender can only improve the quality by paying more; just setting some priority bits doesn't hack it, since it offers no help to a pricing mechanism. If there is no pricing mechanism, no ISP will respect priority bits. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 05:30:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA06889; Mon, 10 Mar 1997 05:22:33 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA06879; Mon, 10 Mar 1997 05:22:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA22171; Mon, 10 Mar 1997 05:23:01 -0800 Received: from mailhub.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA29503 for ; Mon, 10 Mar 1997 05:22:54 -0800 Received: from ford.axion.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Mon, 10 Mar 1997 12:58:49 +0000 Received: from msmsmtp1.comnet.bt.co.uk (actually msmsmtp2.comnet.bt.co.uk) by ford.axion.bt.co.uk with SMTP (PP); Mon, 10 Mar 1997 12:45:57 +0000 Received: by msmsmtp1.comnet.bt.co.uk with Microsoft Mail id <3324019A@msmsmtp1.comnet.bt.co.uk>; Mon, 10 Mar 97 12:42:02 GMT From: "Shorten,J,Jon,NAT22,SHORTEJ M" To: IPng WG Subject: (IPng 3236) Re: IPv6 priority field usage? Date: Mon, 10 Mar 97 12:44:00 GMT Message-ID: <3324019A@msmsmtp1.comnet.bt.co.uk> X-Mailer: Microsoft Mail V3.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1904 unLurking briefly to take issue with the views on prioritisation; it can make a vast difference to end users to prioritise data for some applicatations, the mechanism should be available for users to decide which data should be thrown out first. If you want examples, the best I've found is DLSw, but there are others. Feel free to tell me to get lost if I'm out of line, but it had to be said. The opinions above are mine, not those of my employer or their client Jon Shorten E-Mail : jon.shorten@keepvale.co.uk Network Consultant Keepvale Limited From: (Brian E Carpenter) To: petkos Cc: ipng Subject: (IPng 3235) Re: IPv6 priority field usage? Date: 10 March 1997 11:22 > > Since it is expected that end-to-end resource reservations (rsvp et al) > are not available in world-wide Internet (at least for unicast) > there should be some tools available for sender to improve the quality > of its own stream. Best way to achieve this is to classify > packets. Expected by who? And what timescale are you considering? And in any case, the sender can only improve the quality by paying more; just setting some priority bits doesn't hack it, since it offers no help to a pricing mechanism. If there is no pricing mechanism, no ISP will respect priority bits. Brian Carpenter ---------------------------------------------------------------------------- -- IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 06:18:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06925; Mon, 10 Mar 1997 06:10:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06915; Mon, 10 Mar 1997 06:10:12 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA27670; Mon, 10 Mar 1997 06:10:54 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA13523 for ; Mon, 10 Mar 1997 06:10:48 -0800 Received: from rtpdce03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA35244; Mon, 10 Mar 1997 09:10:29 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA46260; Mon, 10 Mar 1997 09:10:30 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17142; Mon, 10 Mar 1997 09:10:10 -0500 Message-Id: <9703101410.AA17142@ludwigia.raleigh.ibm.com> To: Jeremy McCooey Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3237) Re: Structured ESD / DHCP variant In-Reply-To: Your message of "Fri, 07 Mar 1997 17:29:39 EST." <199703072229.RAA25231@fleck.IOL.UNH.EDU> Date: Mon, 10 Mar 1997 09:10:09 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1817 Jeremy, > Using the above "restricted" address, the node requests an ESD from > the server. This is the functional equivalence of *requiring* that all nodes run DHCP and all sites run DHCP servers. Many folks consider this to be a show stopper. That is, they believe that an important benefit of IPv6 is a stateless autoconfiguration that does not require DHCP. > I suspect that many people will frown upon the idea of using a server > for autoconfiguration; *Requiring* the use of a server is what causes folks heartburn. IPv6 does have a DHCP, and some sites will use it. But not all sites. > however, I feel that the benefit of a structured ESD is enough to > merit this approach. Could you please spell out exactly what those benefits are? At the interim meeting, the (rough) consensus seemed to be that the benefits of a structured ESDs did not outweigh the costs (e.g., requiring the use of something like DHCP). My recollection is that the reasons for wanting a structured ESD space are: 1) easier to insure global uniqueness of nodes. 2) possible to map ESDs into other quantities (e.g., DNS names). The first benefit can (mostly) be obtained through IEEE addresses. The second benefit is viewed as a false benefit -- it requires that folks set up a mechanism/database to do the mappings, something that has failed miserably in practice with today's IPv4 in-addr.arpa DNS tree. If it failed in IPv4, why would it succeed in IPv6? The ICMP "who are you" message was proposed as way of obviating the need for 2. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 06:51:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06945; Mon, 10 Mar 1997 06:42:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06938; Mon, 10 Mar 1997 06:42:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA03491; Mon, 10 Mar 1997 06:43:24 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA23574 for ; Mon, 10 Mar 1997 06:43:19 -0800 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id QAA05791; Mon, 10 Mar 1997 16:43:22 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id QAA03735; Mon, 10 Mar 1997 16:43:18 +0200 (EET) Message-Id: <199703101443.QAA03735@harakka.cs.tut.fi> Subject: (IPng 3238) Re: IPv6 priority field usage? In-Reply-To: <9703101122.AA05368@hursley.ibm.com> from "brian@hursley.ibm.com" at "Mar 10, 97 11:22:09 am" To: brian@hursley.ibm.com Date: Mon, 10 Mar 1997 16:43:16 +0200 (EET) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2602 >> Anyway, I'm against the change. >> I'd like to keep the 4 bits priority field for end-to-end communication >> although I admit that there are some problems in it >> (it might encourage users to send unnecessary data to network). >> >> Since it is expected that end-to-end resource reservations (rsvp et al) >> are not available in world-wide Internet (at least for unicast) >> there should be some tools available for sender to improve the quality >> of its own stream. Best way to achieve this is to classify >> packets. > >Expected by who? And what timescale are you considering? >And in any case, the sender can only improve the quality by >paying more; just setting some priority bits doesn't hack it, >since it offers no help to a pricing mechanism. If there is >no pricing mechanism, no ISP will respect priority bits. I disagree with the "sender can only improve the quality by paying more". Example: Sender have (layered) codec which produces 500 kbit/s which could utilize priority field to separate layers. Now we have two scenarios: 1) no priority bits are available 2) priority bits are available to sender In both cases, same amount of data is sent to network, and if there is no congestation then everything is fine. In the case of congestion, ISP must drop some packets. Let's assume that there is fair share of resources (everybody gets equal amount of router port capacity, e.g 200 kbit/s). In the scenario 1) packets are dropped quite randomly and the quality degration might be fatal. But if we use scenario 2) the quality is still usable because ISP router knows from priority field which packets should be dropped first in the case of congestion. Both scenarios consumes same amount of network capacity (!) In the meeting minutes there was said that the use of priority bits will encourage users to send unnecessary data to network. I don't agree with this. Users will send same amount of data to network anyway but by using priority bits the quality degration in the case of congestion is smoother and the remaining bits (e.g. 200kbit/s) are still useful. In the scenario 1) this 200 kbit/s is useless and just wastes network resources. Needless to say, I'd strongly propose we still keep priority bits and let sender to specify those. Petri Koskelainen ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 07:25:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06969; Mon, 10 Mar 1997 07:17:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06962; Mon, 10 Mar 1997 07:17:27 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA14060; Mon, 10 Mar 1997 07:18:10 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA05434 for ; Mon, 10 Mar 1997 07:18:04 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA109436; Mon, 10 Mar 1997 15:18:08 GMT Date: Mon, 10 Mar 1997 15:18:08 GMT Message-Id: <9703101518.AA109436@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3239) Re: IPv6 priority field usage? To: SHORTEJ@boat.bt.com (Shorten, J, Jon, NAT22, SHORTEJ M) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3324019A@msmsmtp1.comnet.bt.co.uk> from "Shorten,J,Jon,NAT22,SHORTEJ M" at Mar 10, 97 12:44:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2595 Jon, You aren't the least out of line, but neither you nor Petri responded to my point: > If there is > no pricing mechanism, no ISP will respect priority bits. Drop priorities are a valid technical mechanism but ISPs are in it for the money. Brian >- Shorten,J,Jon,NAT22,SHORTEJ M said: > > > unLurking briefly to take issue with the views on prioritisation; it can > make a vast difference to end users to prioritise data for some > applicatations, the mechanism should be available for users to decide which > data should be thrown out first. > > If you want examples, the best I've found is DLSw, but there are others. > > Feel free to tell me to get lost if I'm out of line, but it had to be said. > > The opinions above are mine, not those of my employer or their client > > Jon Shorten E-Mail : jon.shorten@keepvale.co.uk > > Network Consultant > Keepvale Limited > > > From: (Brian E Carpenter) > > To: petkos > Cc: ipng > Subject: (IPng 3235) Re: IPv6 priority field usage? > Date: 10 March 1997 11:22 > > > > > > Since it is expected that end-to-end resource reservations (rsvp et al) > > are not available in world-wide Internet (at least for unicast) > > there should be some tools available for sender to improve the quality > > of its own stream. Best way to achieve this is to classify > > packets. > > Expected by who? And what timescale are you considering? > And in any case, the sender can only improve the quality by > paying more; just setting some priority bits doesn't hack it, > since it offers no help to a pricing mechanism. If there is > no pricing mechanism, no ISP will respect priority bits. > > > Brian Carpenter > ---------------------------------------------------------------------------- > -- > IETF IPng Mailing List FTP archive: > ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 07:39:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06990; Mon, 10 Mar 1997 07:30:34 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06983; Mon, 10 Mar 1997 07:30:24 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA18016; Mon, 10 Mar 1997 07:31:08 -0800 Received: from central-services.east.isi.edu (central-services.east.isi.edu [38.245.76.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA09690 for ; Mon, 10 Mar 1997 07:31:00 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by central-services.east.isi.edu (8.7.5/8.7.3) with SMTP id KAA10653; Mon, 10 Mar 1997 10:30:57 -0500 (EST) Message-Id: <199703101530.KAA10653@central-services.east.isi.edu> X-Authentication-Warning: central-services.east.isi.edu: Host LOCALHOST [127.0.0.1] didn't use HELO protocol To: Koskelainen Petri cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 3241) Re: IPv6 priority field usage? In-reply-to: Your message of "Mon, 10 Mar 1997 16:43:16 +0200." <199703101443.QAA03735@harakka.cs.tut.fi> X-Phone: +1 703 812 3704 From: "John W. Stewart III" Date: Mon, 10 Mar 1997 10:30:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4058 i'm in favor of the change that steve proposed in san jose with today's technology and the packet-per-second performance we expect, the most routers can do with these bits is treat them as an absolute priority (i.e., not a priority compared to other packets from the same source). so if these bits control queueing priority in routers, we can't reasonably expect providers to "just accept" whatever is in them. for example, control and management traffic should have the highest priority, so it would be a bad thing to accept "user" packets with the same priority. this implies that the bits may need to be re-written in-flight. in addition, there are schemes documented in I-Ds for doing simple QOS in v4 with the precedence bits, and i think it would be good not to preclude the same QOS for v6 .. commercial QOS for IP isn't well understood, so if there is some amount of support for it in v4, v6 shouldn't force people to start over again /jws > > > >> Anyway, I'm against the change. > >> I'd like to keep the 4 bits priority field for end-to-end communication > >> although I admit that there are some problems in it > >> (it might encourage users to send unnecessary data to network). > >> > >> Since it is expected that end-to-end resource reservations (rsvp et al) > >> are not available in world-wide Internet (at least for unicast) > >> there should be some tools available for sender to improve the quality > >> of its own stream. Best way to achieve this is to classify > >> packets. > > > >Expected by who? And what timescale are you considering? > >And in any case, the sender can only improve the quality by > >paying more; just setting some priority bits doesn't hack it, > >since it offers no help to a pricing mechanism. If there is > >no pricing mechanism, no ISP will respect priority bits. > > > I disagree with the "sender can only improve the quality by paying more". > > Example: Sender have (layered) codec which produces 500 kbit/s > which could utilize priority field to separate layers. > > Now we have two scenarios: > 1) no priority bits are available > 2) priority bits are available to sender > > In both cases, same amount of data is sent to network, and if > there is no congestation then everything is fine. > > In the case of congestion, ISP must drop some packets. > Let's assume that there is fair share of resources (everybody gets equal > amount of router port capacity, e.g 200 kbit/s). > > > In the scenario 1) packets are dropped quite randomly and the quality > degration might be fatal. But if we use scenario 2) the quality > is still usable because ISP router knows from priority field > which packets should be dropped first in the case of congestion. > > Both scenarios consumes same amount of network capacity (!) > > > In the meeting minutes there was said that the use of priority bits > will encourage users to send unnecessary data to network. > I don't agree with this. > > Users will send same amount of data to network anyway but by using > priority bits the quality degration in the case of congestion > is smoother and the remaining bits (e.g. 200kbit/s) are still useful. > > In the scenario 1) this 200 kbit/s is useless and just wastes > network resources. > > Needless to say, I'd strongly propose we still keep priority bits > and let sender to specify those. > > > > Petri Koskelainen > > > > > > > ---------------------------------------------------------------------------- -- > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/ pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 07:52:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA07009; Mon, 10 Mar 1997 07:42:43 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA07002; Mon, 10 Mar 1997 07:42:32 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA20363; Mon, 10 Mar 1997 07:43:16 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA14120 for ; Mon, 10 Mar 1997 07:43:10 -0800 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id RAA08625; Mon, 10 Mar 1997 17:43:14 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id RAA05518; Mon, 10 Mar 1997 17:43:11 +0200 (EET) Message-Id: <199703101543.RAA05518@harakka.cs.tut.fi> Subject: (IPng 3242) Re: IPv6 priority field usage? In-Reply-To: <199703101530.KAA10653@central-services.east.isi.edu> from "John W. Stewart III" at "Mar 10, 97 10:30:52 am" To: jstewart@isi.edu (John W. Stewart III) Date: Mon, 10 Mar 1997 17:43:10 +0200 (EET) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1013 > for > example, control and management traffic should have the > highest priority, so it would be a bad thing to accept "user" > packets with the same priority. this implies that the bits > may need to be re-written in-flight. in addition, there are Of course routing updates etc are more important than user data. I meant that priority is relative and is to be compared only among other packets in the same flow, not among multiple flows. If I mark half of my packets being lower priority and half of them being higer priority, it has nothing to do with other flows in the router. It is just my way to inform the router, "if possible drop these packets from my flow before dropping my higher priority packets". Petri ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 08:16:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07125; Mon, 10 Mar 1997 08:07:34 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07118; Mon, 10 Mar 1997 08:07:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA24284; Mon, 10 Mar 1997 08:08:10 -0800 Received: from random.glarp.com ([205.169.150.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA24088 for ; Mon, 10 Mar 1997 08:08:04 -0800 Received: from misc.glarp.com (misc.glarp.com [199.117.25.254]) by random.glarp.com (8.8.3/8.7.3) with ESMTP id JAA15106; Mon, 10 Mar 1997 09:07:45 -0700 (MST) Message-Id: <199703101607.JAA15106@random.glarp.com> To: "(Brian E Carpenter)" cc: SHORTEJ@boat.bt.com (Shorten, J, Jon, NAT22, SHORTEJ M), ipng@sunroof.eng.sun.com Subject: (IPng 3243) Re: IPv6 priority field usage? In-reply-to: Your message of "Mon, 10 Mar 1997 15:18:08 GMT." <9703101518.AA109436@hursley.ibm.com> Date: Mon, 10 Mar 1997 09:07:34 -0700 From: Brad Huntting Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1065 > If there is > no pricing mechanism, no ISP will respect priority bits. I wouldn't be so sure... Many ISP's today have monthly/daily/hourly limits on high speed lines; this allows customers to get full DS1 (or more likely DS3) bandwidth for short periods of time while giving the provider the ability to collect extra fees for "excessive" use. Using packet priorities can make such billing schemes both more fair and more reasonable. For example, the provider may choose to tally only "high" priority traffic against the daily limits. Or perhaps have two limits one for total traffic, one for high priority. Such a scheme would allow providers to run their networks closer to saturation while still providing both good service and "unlimited access". just a thought, brad ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 08:35:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07165; Mon, 10 Mar 1997 08:25:48 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07158; Mon, 10 Mar 1997 08:25:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27290; Mon, 10 Mar 1997 08:26:23 -0800 Received: from metro.isi.edu (metro.isi.edu [38.245.76.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA02014 for ; Mon, 10 Mar 1997 08:26:17 -0800 Received: from metro.isi.edu by metro.isi.edu (5.65c/5.61+local-24) id ; Mon, 10 Mar 1997 11:26:18 -0500 Message-Id: <199703101626.AA16415@metro.isi.edu> To: Koskelainen Petri Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3244) Re: IPv6 priority field usage? In-Reply-To: Your message of "Mon, 10 Mar 1997 17:43:10 +0200." <199703101543.RAA05518@harakka.cs.tut.fi> X-Phone: +1 703 812 3704 From: "John W. Stewart III" Date: Mon, 10 Mar 1997 11:26:18 EST Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1493 > > for > > example, control and management traffic should have the > > highest priority, so it would be a bad thing to accept "user" > > packets with the same priority. this implies that the bits > > may need to be re-written in-flight. in addition, there are > > Of course routing updates etc are more important > than user data. > > I meant that priority is relative and is to be compared only > among other packets in the same flow, not among multiple flows. understood. but my point was that i don't think routers can do that yet so i'm loathe to define something that depends on it. this obviously begs the question of router technology timescales and ipv6 deployment timescales... and btw, if you define the priority bits such that they're not comparable across flows, then how do you ensure that, e.g., routing updates get the highest priority? bona fide flow setup? /jws > > If I mark half of my packets being lower priority and half of them being > higer priority, it has nothing to do with other flows in the router. > It is just my way to inform the router, "if possible drop these packets > from my flow before dropping my higher priority packets". > > > > Petri ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 08:36:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07174; Mon, 10 Mar 1997 08:26:34 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07167; Mon, 10 Mar 1997 08:26:20 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27408; Mon, 10 Mar 1997 08:27:03 -0800 Received: from ns.research.att.com (ns.research.att.com [192.20.225.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA02278 for ; Mon, 10 Mar 1997 08:26:58 -0800 Received: from research.att.com ([135.205.32.20]) by ns; Mon Mar 10 11:26:02 EST 1997 Received: from raptor.research.att.com ([135.205.49.32]) by research; Mon Mar 10 11:25:49 EST 1997 Received: from smb.research.att.com (smb-home.research.att.com [135.205.55.9]) by raptor.research.att.com (8.8.5/8.8.5) with SMTP id LAA24457; Mon, 10 Mar 1997 11:25:47 -0500 (EST) Message-Id: <3.0.32.19970310162539.006c11d0@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 10 Mar 1997 16:25:48 -0500 To: "John W. Stewart III" From: "Steven M. Bellovin" Subject: (IPng 3245) Re: IPv6 priority field usage? Cc: Koskelainen Petri , brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, kent@bbn.com, rja@isoc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1610 At 10:30 AM 3/10/97 -0500, John W. Stewart III wrote: >so if these bits >control queueing priority in routers, we can't reasonably >expect providers to "just accept" whatever is in them. for >example, control and management traffic should have the >highest priority, so it would be a bad thing to accept "user" >packets with the same priority. this implies that the bits >may need to be re-written in-flight. It is worth mentioning here something that's take for granted in the ipsec group: changing anything in a packet interacts poorly with cryptography. In particular, AH (currently RFC 1826, though it's being rewritten) specifies that most of the preceeding IP header is included in the AH checksum calculation. Some fields are explicitly excluded (TTL is the obvious one), but if such changes are necessary, we need to know *now*. (There are also some requirements on the Precedence field in rfc793; at the very least, a statement of interpretation is going to be needed if anything can diddle those bits as a matter of course.) Btw -- the question of whether or not the IP header should be included in the AH checksum was discussed at very great length (and of course, very great volume) in the ipsec group. For better or worse, though, the question is considered settled now; I don't think we want to reopen it. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 09:19:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07316; Mon, 10 Mar 1997 09:11:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07309; Mon, 10 Mar 1997 09:10:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA08414; Mon, 10 Mar 1997 09:11:33 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA23665 for ; Mon, 10 Mar 1997 09:11:27 -0800 Received: from gungnir.fnal.gov ("port 36823"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGC31WYI6Q000AV8@FNAL.FNAL.GOV>; Mon, 10 Mar 1997 11:11:31 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id LAA11021; Mon, 10 Mar 1997 11:11:26 -0600 Date: Mon, 10 Mar 1997 11:11:26 -0600 From: Matt Crawford Subject: (IPng 3246) Re: IPv6 priority field usage? In-reply-to: "10 Mar 1997 16:43:16 +0200." <"199703101443.QAA03735"@harakka.cs.tut.fi> To: Koskelainen Petri Cc: ipng@sunroof.eng.sun.com Message-id: <199703101711.LAA11021@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ I disagree with the "sender can only improve the quality by paying more". > Example: Sender have (layered) codec which produces 500 kbit/s > which could utilize priority field to separate layers. > [ ... ] > In the case of congestion, ISP must drop some packets. > Let's assume that there is fair share of resources (everybody gets equal > amount of router port capacity, e.g 200 kbit/s). In that case, a good congestion response would be a mechanism that informs the source to send only 200 kb/s. A bad mechanism would be one which has the entire network carry 500 kb/s as far as the choke point, and 200 kb/s beyond that point. > Both scenarios [random drop or source-prioritized drop] consumes > same amount of network capacity (!) Yes, they do. And they consume more than they should. > Users will send same amount of data to network anyway but by using > priority bits the quality degration in the case of congestion > is smoother and the remaining bits (e.g. 200kbit/s) are still useful. Suppose for a moment that someone (either the sender or the recipient) has to pay for each bit of data that's sent. Then they certainly want to send only the amount that can be delivered! I'm just repeating the argument that convinced me. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 09:40:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07393; Mon, 10 Mar 1997 09:31:43 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07386; Mon, 10 Mar 1997 09:31:38 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09518; Mon, 10 Mar 1997 09:32:23 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06262; Mon, 10 Mar 1997 09:31:49 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06971; Mon, 10 Mar 1997 07:18:33 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA14422; Mon, 10 Mar 1997 07:19:17 -0800 Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA05808 for ; Mon, 10 Mar 1997 07:19:10 -0800 Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) by noknic.nokia.com (8.6.9/8.6.9) with SMTP id RAA23865 for ; Mon, 10 Mar 1997 17:19:14 +0200 Received: (from smap@localhost) by pepper.research.nokia.com (8.6.13/8.6.13) id RAA12919 for ; Mon, 10 Mar 1997 17:19:10 +0200 Received: from nrchub01he.research.nokia.com(131.228.10.247) by pepper.research.nokia.com via smap (V1.3) id sma012885; Mon Mar 10 17:19:04 1997 Received: from Microsoft Mail (PU Serial #1751) by nrchub01he.research.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1997Mar10.161551.1751.532996; Mon, 10 Mar 1997 16:20:58 +0200 From: harri.hakulinen@research.nokia.com (Hakulinen Harri NRC/Tre) To: ipng@sunroof.eng.sun.com ('smtp:ipng@sunroof.Eng.Sun.COM') Message-ID: <1997Mar10.161551.1751.532996@nrchub01he.research.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 10 Mar 1997 16:20:58 +0200 Subject: (IPng 3247) Re: IPv6 priority field Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 566 > From: Brian Carpenter (IBM) > > Petri, > > Anyway, I'm against the change. > > I'd like to keep the 4 bits priority field for end-to-end > > communication although I admit that there are some > > problems in it (it might encourage users to send > > unnecessary data to network). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 12:38:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07908; Mon, 10 Mar 1997 12:29:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07901; Mon, 10 Mar 1997 12:29:25 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA26614; Mon, 10 Mar 1997 12:30:07 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA28554 for ; Mon, 10 Mar 1997 09:22:28 -0800 Received: by mail.noris.net id <35205-11373>; Mon, 10 Mar 1997 18:22:21 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3248) Re: IPv6 priority field usage? Date: 10 Mar 1997 18:21:55 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 37 Message-ID: <5g1fvk$8l4$1@work.smurf.noris.de> References: <9703101122.AA05368@hursley.ibm.com> <199703101443.QAA03735@harakka.cs.tut.fi> <858006694.9512@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1504 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2252 Koskelainen Petri writes: > > In the case of congestion, ISP must drop some packets. > Let's assume that there is fair share of resources (everybody gets equal > amount of router port capacity, e.g 200 kbit/s). > This assumption is invalid. In practice, IP traffic is bursty and whatever happens to overflow the queue during a burst gets dropped on the floor. The router has better things to do than to scan the queue for lower-priority from the same source which it might want to drop. Consider typical traffic across an ISP's router, e.g. 20 customers -- of which one actually uses their priority bits. The router will NOT automagically count packets from different subnetworks to make sure that everybody gets their fair share. The router will either be set to ignore priority, or it'll allow you to set the field to "highest priority" for _all_ data packets, thereby flushing out everybody else -- until everybody catches on, sets their priority field to MAXINT too, and the priority field is as useless as in the first mode. If you want guaranteed bandwidth you'll have to reserve it (we have a "flow label" field reserved in IPng...) so that the router can actually _do_ the counting. Then you can tell your customers what their "fair share" actually is, and charge them more if they need more bandwidth than that. Priority fields might make sense within a flow so that a router can know what to do with traffic that exceeds the reserved bandwidth if there's congestion. However, we don't know yet. -- You are dishonest, but never to the point of hurting a friend. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 13:27:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA08145; Mon, 10 Mar 1997 13:18:45 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA08138; Mon, 10 Mar 1997 13:18:36 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA12842; Mon, 10 Mar 1997 13:19:17 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA10864 for ; Mon, 10 Mar 1997 09:49:58 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id MAA17796; Mon, 10 Mar 1997 12:49:41 -0500 Date: Mon, 10 Mar 1997 12:49:41 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703101249.ZM17794@seawind.bellcore.com> In-Reply-To: "(Brian E Carpenter)" "(IPng 3239) Re: IPv6 priority field usage?" (Mar 10, 3:18pm) References: <9703101518.AA109436@hursley.ibm.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: "(Brian E Carpenter)" , SHORTEJ@boat.bt.com (Shorten, J, Jon, NAT22, SHORTEJ M) Subject: (IPng 3249) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1718 On Mar 10, 3:18pm, (Brian E Carpenter) wrote: > Subject: (IPng 3239) Re: IPv6 priority field usage? > Jon, > > You aren't the least out of line, but neither you nor Petri > responded to my point: > > > If there is > > no pricing mechanism, no ISP will respect priority bits. > > Drop priorities are a valid technical mechanism but ISPs > are in it for the money. Brian, There have been proposals (e.g. by Dave Clark) to use a header bit (or two) for two specific indications, "don't drop" and "don't queue". The "don't queue" bit can be set for real-time traffic, where long delays are just as bad as packet losses -- a plain end-to-end indication. The "don't drop" idea fare well with variation of volume charging, where organizations (or ISP) have some guaranteed capacity as part of their subscription. A policing scheme can be used to check that the "priority" bit is only set for the traffic which is within the profile; the sending organization can decide which packets should be treated with priority, without having to bear the full complexity of RSVP. But then, all this is very much a topic of experimentation. Internetworking requirement, e.g. policing at provider boundaries, may require some flipping of these bits. Another proposed usage of the 4 bits include an indication of congestion, similar in a sense to that of frame relay, which would mean "react as if this packet had been lost". -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 14:20:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08397; Mon, 10 Mar 1997 14:11:43 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA08390; Mon, 10 Mar 1997 14:11:35 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA27183; Mon, 10 Mar 1997 14:12:16 -0800 Received: from postoffice.Reston.mci.net (postoffice.Reston.mci.net [204.70.128.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA06123 for ; Mon, 10 Mar 1997 14:12:12 -0800 Received: from huddle.reston.mci.net ([166.45.3.198]) by postoffice.Reston.mci.net (8.8.5/8.8.5) with SMTP id RAA28711; Mon, 10 Mar 1997 17:11:27 -0500 (EST) Message-Id: <3.0.32.19970310171347.00c7e5b4@mci.net> X-Sender: huddle@mci.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 10 Mar 1997 17:14:18 -0500 To: "Steven M. Bellovin" , "John W. Stewart III" From: Scott Huddle Subject: (IPng 3250) Re: IPv6 priority field usage? Cc: Koskelainen Petri , brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, kent@bbn.com, rja@isoc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2441 I'll support Steve's original point and say these bits should be reserved for the domain of the provider. If TOS effects the queuing of traffic within the network, it'll be essential for providers to be able to manage this resource (network management/control being the obvious example) This necessarily implies that TOS will have to settable by the provider. This also implies that TOS should be excluded from the checksum for the IPSEC work. -scott At 04:25 PM 3/10/97 -0500, Steven M. Bellovin wrote: >At 10:30 AM 3/10/97 -0500, John W. Stewart III wrote: >>so if these bits >>control queueing priority in routers, we can't reasonably >>expect providers to "just accept" whatever is in them. for >>example, control and management traffic should have the >>highest priority, so it would be a bad thing to accept "user" >>packets with the same priority. this implies that the bits >>may need to be re-written in-flight. > >It is worth mentioning here something that's take for granted in the >ipsec group: changing anything in a packet interacts poorly with >cryptography. >In particular, AH (currently RFC 1826, though it's being rewritten) >specifies that most of the preceeding IP header is included in the AH >checksum calculation. Some fields are explicitly excluded (TTL is the >obvious one), but if such changes are necessary, we need to know *now*. >(There are also some requirements on the Precedence field in rfc793; at >the very least, a statement of interpretation is going to be needed if >anything can diddle those bits as a matter of course.) > >Btw -- the question of whether or not the IP header should be included in >the AH checksum was discussed at very great length (and of course, very great >volume) in the ipsec group. For better or worse, though, the question is >considered settled now; I don't think we want to reopen it. > >--------------------------------------------------------------------------- --- >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 16:18:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA08775; Mon, 10 Mar 1997 16:10:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA08768; Mon, 10 Mar 1997 16:10:11 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA27949; Mon, 10 Mar 1997 16:10:53 -0800 Received: from mail.ton.tut.fi (mylly.ton.tut.fi [193.166.80.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA23959 for ; Mon, 10 Mar 1997 16:10:52 -0800 Received: from localhost (veikko@localhost) by mail.ton.tut.fi (8.8.0/8.8.0) with SMTP id CAA07546; Tue, 11 Mar 1997 02:10:50 +0200 (EET) Date: Tue, 11 Mar 1997 02:10:49 +0200 (EET) From: Harri Hakulinen To: ipng@sunroof.eng.sun.com cc: harri.hakulinen@research.nokia.com, petri.koskelainen@research.nokia.com Subject: (IPng 3251) Re: IPv6 priority field usage? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3714 I quess my mailgw ate my previous mail, so I try again. I think that video(phone) is one of the moust important new application areas for IP(v6) networks. Even so important, that it seems reasonable (at least for me) to take it account in this case. That is because when SW-based video coding and decoding is used in IP network and multiplexed with IP tools (e.g. with RTP), it is actually difficult to say where video coding ends and network (protocol) starts. When Petri had his example few mails ago, he said that for layered encoded video streams it makes sense to vary bethween e.g. 500 kbits and 200 kbits. It was of course an simplified example. Other example could be MPEG2 video stream. It consist of B,P and I -frames. I-frames are very important for receivers. If I-frame is not received correctly, basically all following B and P -frames are unusable up to next I-frame. As sender- receiver pair I want to be sure that IP packets containing B and P frames are dropped if something has to be dropped (this is really "oversimplified" MPEG2). So, If video packets are dropped _in_random_way_, damage in picture is easily very big when compared to sender based selection of dropped packets (by using IPv6 priority field). You may say that better way to handle these streams is to use some kind of adaptive method, that is based on real time measured network troughtput. But the problem is, that these kind of methods are relatively slow to react and it is very easy to "see or hear missing packets" from e.g. video/audio stream. In my imagination priority field is used so, that normally highest priority value is used for all traffic. When sender knows, that parts of the traffic are more important than some other parts, he marks lower importance packets by using lower priority. By doing this, sender knows that there is _highest_possibility_ that important packets are received by receiver in the case of network congestion. If the congestion happens, router begins to drop packets that have low priority value. If this is not enough, router has to drop high priority packets also, of course. Here I assume, that router can react much more faster to local congestion than any end-to-end flow control protocol. It could even be nice to specify, that routers should drop low priority packets in advance to avoid more serious (predicted) congestion. As far as I understand, the best way to send video over internet is to use layered video coding with _combination_ of adaptive bandwith usage _and_ priority marked IP(v6) packets. Thats why I don't support the idea of removing moust of application defined priorities. Instead, I think that priority field could be redefined e.g. in the following way (maybe not elegant, but gives an idea): 1st bit defines, if 3 other bits are used by/bethween routers or by end-to-end application. If 1st bit is 1, 3 other bits are used by routers e.g. for routing traffic (I don't know how). If 1st bit is 0, other bits are used by end-to-end application, and routers are not allowed to modify them. Instead, routers must act in congestion situation as I described before. This gives 8 different priorities for application use. Those priorities could also be used to define, which traffic belongs to "my base share of net quota" as someone earlier suggested. - Harri.Hakulinen@research.nokia.com Video laboratory/Network & Terminal technologies Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 21:13:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA09189; Mon, 10 Mar 1997 21:05:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA09182; Mon, 10 Mar 1997 21:05:28 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA15814; Mon, 10 Mar 1997 21:06:11 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA18692 for ; Mon, 10 Mar 1997 21:06:13 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA06693; Mon, 10 Mar 1997 23:59:05 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23084; Mon, 10 Mar 1997 23:59:04 -0500 Message-Id: <9703110459.AA23084@wasted.zk3.dec.com> To: Harri Hakulinen Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3252) Re: IPv6 priority field usage? In-Reply-To: Your message of "Tue, 11 Mar 97 02:10:49 +0200." Date: Mon, 10 Mar 97 23:59:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1009 Hari, Yours and Christian Huitema's responses have made me change my mind. I think we may need the priority bits. The con's so far on this list have all been "business" issues and "intergalactic routing architecture" issues. I think the con is can we better use these bits in the header for IPv6 routers? I would like to see what kinds of things the routers would use these for technically. I think the business issues are clearly valid, but not cast in stone. One question I have for you is: Could we use the flow lable to define priority for video and audio? If not why not? In every case I came up with for use of priority bits for IP applications I can set up a flow if I really want prioritization. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 10 22:01:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA09218; Mon, 10 Mar 1997 21:53:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA09211; Mon, 10 Mar 1997 21:53:28 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA19577; Mon, 10 Mar 1997 21:54:10 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA00262 for ; Mon, 10 Mar 1997 21:54:14 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id VAA02658; Mon, 10 Mar 1997 21:52:52 -0800 Received: from [171.69.126.196] (sl-charm-12.cisco.com [171.69.126.150]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id VAA01521; Mon, 10 Mar 1997 21:52:43 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Mar 1997 21:52:49 -0800 To: Harri Hakulinen From: fred@cisco.com (Fred Baker) Subject: (IPng 3253) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com, harri.hakulinen@research.nokia.com, petri.koskelainen@research.nokia.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1036 At 2:10 AM 3/11/97, Harri Hakulinen wrote: >I think that video(phone) is one of the moust important new >application areas for IP(v6) networks. Even so important, >that it seems reasonable (at least for me) to take it account >in this case. That is because when SW-based video coding and >decoding is used in IP network and multiplexed with IP tools >(e.g. with RTP), it is actually difficult to say where video >coding ends and network (protocol) starts. Anyone who thinks that IP6 should not have a priority field should discuss their views with the principal backbone providers. They may be surprised. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 00:34:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA09269; Tue, 11 Mar 1997 00:27:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA09262; Tue, 11 Mar 1997 00:26:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA04499; Tue, 11 Mar 1997 00:27:33 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA01272 for ; Tue, 11 Mar 1997 00:27:38 -0800 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id KAA06818; Tue, 11 Mar 1997 10:27:32 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id KAA11456; Tue, 11 Mar 1997 10:27:31 +0200 (EET) Message-Id: <199703110827.KAA11456@harakka.cs.tut.fi> Subject: (IPng 3254) Re: IPv6 priority field usage? In-Reply-To: <199703101626.AA16415@metro.isi.edu> from "John W. Stewart III" at "Mar 10, 97 11:26:18 am" To: jstewart@isi.edu (John W. Stewart III) Date: Tue, 11 Mar 1997 10:27:30 +0200 (EET) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 740 > and btw, if you define the priority bits such that they're not > comparable across flows, then how do you ensure that, e.g., > routing updates get the highest priority? bona fide flow setup? > > /jws > Routing updates don't need header priorities. For example, OSPF and ICMP run directly over IPv6 so they have their own protocol id. Those protocol numbers (routing protocols etc.) can be given highest priority in routers. -- Petri Koskelainen ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 01:09:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA09314; Tue, 11 Mar 1997 01:01:23 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA09307; Tue, 11 Mar 1997 01:01:15 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA08197; Tue, 11 Mar 1997 01:01:58 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA08865 for ; Tue, 11 Mar 1997 01:02:02 -0800 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id LAA08294; Tue, 11 Mar 1997 11:01:56 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id LAA12123; Tue, 11 Mar 1997 11:01:54 +0200 (EET) Message-Id: <199703110901.LAA12123@harakka.cs.tut.fi> Subject: (IPng 3255) Re: IPv6 priority field usage? In-Reply-To: <5g1fvk$8l4$1@work.smurf.noris.de> from Matthias Urlichs at "Mar 10, 97 06:21:55 pm" To: smurf@noris.de (Matthias Urlichs) Date: Tue, 11 Mar 1997 11:01:54 +0200 (EET) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1394 > > > > In the case of congestion, ISP must drop some packets. > > Let's assume that there is fair share of resources (everybody gets equal > > amount of router port capacity, e.g 200 kbit/s). > > > This assumption is invalid. In practice, IP traffic is bursty and whatever > happens to overflow the queue during a burst gets dropped on the floor. The > router has better things to do than to scan the queue for lower-priority > from the same source which it might want to drop. You are assuming FIFO queue for router. I think that modern (gigabit) routers have more sophisticated ways to handle this (WFQ, multiple queues etc). Fair share of resources should not be very difficult (router designers can correct me if I'm wrong) to guarantee in modern routers. And "scanning for low-priority packets" can be implemented in many ways and I think that it can be provided with very light extra costs. This source-initiated priority field is so important and useful for future Internet services that this (possible) small overhead in routers is justified. -- Petri Koskelainen Nokia Research Center ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 01:25:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA09339; Tue, 11 Mar 1997 01:17:27 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA09331; Tue, 11 Mar 1997 01:17:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA09675; Tue, 11 Mar 1997 01:18:00 -0800 Received: from manuel.nta.no (manuel.nta.no [128.39.1.196]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA11696; Tue, 11 Mar 1997 01:18:03 -0800 X400-Received: by mta tf in /PRMD=telenor/ADMD=TELEMAX/C=no/; Relayed; Tue, 11 Mar 1997 10:17:49 +0100 Date: Tue, 11 Mar 1997 10:17:49 +0100 X400-Originator: Jan-Kjetil.Andersen@kjeller.fou.telenor.no X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=telenor/ADMD=TELEMAX/C=no/;3794 97/03/11 10:17] Content-Identifier: 3794 97/03/11 Alternate-Recipient: Allowed From: Jan Kjetil Andersen Message-ID: <"3794 97/03/11 10:17*/G=Jan-Kjetil/S=Andersen/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> To: owner-ipng@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: <199703101711.LAA11021@gungnir.fnal.gov> Subject: (IPng 3256) Re: IPv6 priority field usage? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1313 > > I disagree with the "sender can only improve the quality by paying more". > > Example: Sender have (layered) codec which produces 500 kbit/s > > which could utilize priority field to separate layers. > > [ ... ] > > In the case of congestion, ISP must drop some packets. > > Let's assume that there is fair share of resources (everybody gets equal > > amount of router port capacity, e.g 200 kbit/s). > > In that case, a good congestion response would be a mechanism that > informs the source to send only 200 kb/s. A bad mechanism would be > one which has the entire network carry 500 kb/s as far as the choke > point, and 200 kb/s beyond that point. > That respone is not useful if the congestion occurs for one of the receivers in a one to many multicast group. Excuse for the waste of bits if you are only discussing unicast. Jan Kjetil Andersen Phone: (+47) 63 84 83 77; Fax: 63 80 05 11; Home: 63 87 70 52; Pager: 96 50 46 03 email: jan-kjetil.andersen@fou.telenor.no Mail: Telenor FoU, Box 83, N-2007 Kjeller ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 01:43:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA09367; Tue, 11 Mar 1997 01:35:52 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA09360; Tue, 11 Mar 1997 01:35:43 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA11210; Tue, 11 Mar 1997 01:36:25 -0800 Received: from manuel.nta.no (manuel.nta.no [128.39.1.196]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA15367 for ; Tue, 11 Mar 1997 01:36:30 -0800 X400-Received: by mta tf in /PRMD=telenor/ADMD=TELEMAX/C=no/; Relayed; Tue, 11 Mar 1997 10:36:13 +0100 Date: Tue, 11 Mar 1997 10:36:13 +0100 X400-Originator: Jan-Kjetil.Andersen@kjeller.fou.telenor.no X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=telenor/ADMD=TELEMAX/C=no/;3797 97/03/11 10:36] Content-Identifier: 3797 97/03/11 Alternate-Recipient: Allowed From: Jan Kjetil Andersen Message-ID: <"3797 97/03/11 10:36*/G=Jan-Kjetil/S=Andersen/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> To: ipng@sunroof.eng.sun.com Subject: (IPng 3257) Re:IPv6 priority field usage? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1312 > > I disagree with the "sender can only improve the quality by paying more". > > Example: Sender have (layered) codec which produces 500 kbit/s > > which could utilize priority field to separate layers. > > [ ... ] > > In the case of congestion, ISP must drop some packets. > > Let's assume that there is fair share of resources (everybody gets equal > > amount of router port capacity, e.g 200 kbit/s). > > In that case, a good congestion response would be a mechanism that > informs the source to send only 200 kb/s. A bad mechanism would be > one which has the entire network carry 500 kb/s as far as the choke > point, and 200 kb/s beyond that point. > That respone is not useful if the congestion occurs for one of the receivers in a one to many multicast group. Excuse for the waste of bits if you are only discussing unicast. Jan Kjetil Andersen Phone: (+47) 63 84 83 77; Fax: 63 80 05 11; Home: 63 87 70 52; Pager: 96 50 46 03 email: jan-kjetil.andersen@fou.telenor.no Mail: Telenor FoU, Box 83, N-2007 Kjeller ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 03:22:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA09428; Tue, 11 Mar 1997 02:56:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA09421; Tue, 11 Mar 1997 02:55:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA17787; Tue, 11 Mar 1997 02:56:31 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA01268 for ; Tue, 11 Mar 1997 02:56:36 -0800 Received: from shand.reo.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id FAA06166; Tue, 11 Mar 1997 05:52:05 -0500 (EST) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA09161; Tue, 11 Mar 1997 10:52:04 GMT Message-Id: <9703111052.AA09161@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Cc: petkos@cs.tut.fi Subject: (IPng 3258) Re: IPv6 priority field usage? In-Reply-To: Your message of "Tue, 11 Mar 97 10:27:30 +0200." <199703110827.KAA11456@harakka.cs.tut.fi> Date: Tue, 11 Mar 97 10:52:04 +0000 From: (Mike Shand REO2 F/D9 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 799 > Routing updates don't need header priorities. > > For example, OSPF and ICMP run directly over IPv6 so > they have their own protocol id. > > Those protocol numbers (routing protocols etc.) can be given > highest priority in routers. Yes, but its a lot harder to find the "protocol number" in the header (especially if it involves parsing your way through a bunch of extension headers up into the TCP/UDP header to find a port number), than it is to look at some bits in the front of the IPv6 header. Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 03:34:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA09472; Tue, 11 Mar 1997 03:25:09 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA09465; Tue, 11 Mar 1997 03:24:56 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA19829; Tue, 11 Mar 1997 03:25:38 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA06395 for ; Tue, 11 Mar 1997 03:25:44 -0800 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id NAA15785; Tue, 11 Mar 1997 13:25:37 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id NAA15389; Tue, 11 Mar 1997 13:25:35 +0200 (EET) Message-Id: <199703111125.NAA15389@harakka.cs.tut.fi> Subject: (IPng 3259) Re: IPv6 priority field usage? In-Reply-To: <9703111052.AA09161@shand.reo.dec.com> from "shand@shand.reo.dec.com" at "Mar 11, 97 10:52:04 am" To: shand@shand.reo.dec.com Date: Tue, 11 Mar 1997 13:25:34 +0200 (EET) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1305 > > Routing updates don't need header priorities. > > > > For example, OSPF and ICMP run directly over IPv6 so > > they have their own protocol id. > > > > Those protocol numbers (routing protocols etc.) can be given > > highest priority in routers. > > Yes, but its a lot harder to find the "protocol number" in the header > (especially if it involves parsing your way through a bunch of > extension headers up into the TCP/UDP header to find a port number), > than it is to look at some bits in the front of the IPv6 header. > There is "Next Header" field in the header. If it is 2 (ICMP), 89 (OSPF) etc. then it must be given preferred service. Other packets (mainly tcp or udp) may utilize priority fields. Or if it much faster way in routers, then we can use part of priority field for network management information. (like Harri suggested in his earlier mail) Or even one flow label id for network management purposes (like VCI=5 in ATM). Anyway, I didn't mean parsing tcp/udp headers. -- Petri ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 05:42:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA09673; Tue, 11 Mar 1997 05:34:27 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA09666; Tue, 11 Mar 1997 05:34:18 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA29052; Tue, 11 Mar 1997 05:35:00 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA09300 for ; Tue, 11 Mar 1997 05:35:08 -0800 Received: from shand.reo.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA19823; Tue, 11 Mar 1997 08:29:24 -0500 (EST) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA10074; Tue, 11 Mar 1997 13:29:23 GMT Message-Id: <9703111329.AA10074@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3260) Re: IPv6 priority field usage? In-Reply-To: Your message of "Tue, 11 Mar 97 13:25:34 +0200." <199703111125.NAA15389@harakka.cs.tut.fi> Date: Tue, 11 Mar 97 13:29:22 +0000 From: (Mike Shand REO2 F/D9 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 614 > There is "Next Header" field in the header. > If it is 2 (ICMP), 89 (OSPF) etc. then it must be given preferred > service. I was actually thinking of protocols like BGP which run over TCP. (not that I approve of such a practise for exactly the reason that it makes it much harder to give it the required prioritization). Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 06:41:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA09727; Tue, 11 Mar 1997 06:33:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA09720; Tue, 11 Mar 1997 06:33:24 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA06932; Tue, 11 Mar 1997 06:34:05 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA27603 for ; Tue, 11 Mar 1997 06:34:13 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA28061; Wed, 12 Mar 1997 01:33:49 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.eng.sun.com Subject: (IPng 3261) Re: 2 faced DNS is here to stay In-Reply-To: Your message of "10 Mar 1997 09:22:13 BST." <5g0gbl$3n2$1@work.smurf.noris.de> Date: Wed, 12 Mar 1997 01:33:48 +1100 Message-Id: <16957.858090828@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6469 Date: 10 Mar 1997 09:22:13 +0100 From: smurf@noris.de (Matthias Urlichs) Message-ID: <5g0gbl$3n2$1@work.smurf.noris.de> Unless we want address rewriting in the routers, which I thought the interim meering has decided we _don't_ want (very sensible, IMHO), then yes, every host does need to know their prefix(es). No, I understood what Erik was saying, which also in a way relates to the message Keith Owens sent. It isn't impossible for a single "site" (for the purposes of site local addressing) to be made up of several (ie: more than one) sub-sites - each of which has separate global prefixes, but those prefixes are kept local to the sub-sites, and not distributed to anyone not in that sub-site. One example may be an organisation with offices in several (distant) cities, with private links used to link them all together, but where each has a connection to a local ISP, and global addressing (which they use) from that ISP. All external traffic (in and out) uses the "public" Internet, their internal inter-city links are used for internal traffic only. This raises the question of what is a site, really, which is something that I don't think has been defined. That's probably good, any definition is likely to limit future flexibility, it is probably best to allow a "site" to be whatever it is wanted to be. Now Erik said in his question to me (that I have been pondering) > But we don't want to require that all hosts have such information ... [that being all the site's global prefixes] Do we really want that? If so, why? I absolutely understand that we don't want all hosts to configure themselves to make use of all prefixes that the "site" may have running through it, but is there a reason why all hosts cannot know all the prefixes that belong in whatever has been defined as the local "site"? That is, RA messages, in the prefix option, already cover two cases - addresses that are available for autoconfig, and addresses that are "on link". Could we not add a third type "local site" and add an "S" bit in one of the unused bits (there are plenty) so that hosts could know all of the local site prefixes? It may also be that simply not setting either L or A might be enough for this purpose - indicating a prefix that should not be autoconfig'd, and which might, or might not, be on the local link - which is close enough to being equivalent to an address that is someplace else in the site (or might be). I have, over time, become not much of a fan of "information hiding", in general things work out better if information that is available to be known, is in fact made known. It isn't necessary to pay attention to that information if it is not required for your purposes, but it is much easier to ignore information that isn't useful, than to try and discover some information which is being carefully hidden, but which would be very useful to have. I would thus prefer to make all the prefixes that are in use in whatever you choose to define as your site available everywhere inside the site - that is, make that information known everywhere. I would not require that however, some huge sites might easily find that a burden more costly than it is worth. But, as usual when information is hidden, this would impose a cost - that being that site local addressing would not be automatically selected when a host wants to establish a connection to another that is in the same site, but which uses global prefixes none of which are known to the originator. Note, just in case it isn't obvious, failing to use site local addressing doesn't direct packets out to the global internet, routing can still easily keep those internal - the cost is that the connection might (if we can't figure out how to make connections survive addressing changes, and until we do anyway) not survive a change of either of the global prefixes in use for the addresses. Personally I think that this combination provides a solution which is easily workable, adequate, and much simpler both to implement, understand, and maintain, than anything which attempts to require 2 faced DNS servers to function. You would of course note that any DNS server would need to know all the site's prefixes in order to function as a 2 faced server the way that has been proposed - and that many organisations like to make sure that there is a local DNS server available on every (IPv4 terminology) subnet (often not advertised to the world as a server, but known by resolvers internally). All of those servers need to discover what all local prefixes are somehow - and keep that list up to date as the global prefixes change. I'd always imagined that RA messages were used for this purpose (they have all of the characteristics required to pass out this information). Of course, if RA's make the info available to DNS servers, they also make it available to everyone else. But if we decide that RA's won't be handing out this info, from where will the DNS servers be acquiring it? Would we be required to invent a new DNS server only protocol to pass around this information? I assume no-one is proposing manual configuration for this! I also note that there is no existing DNS mechanism (including in dynamic update) that could rationally be bent to serve this purpose - something new would be needed. kre ps: while I'm here, a question about RFC1970. On page 45 it is stated (at the beginning of section 6.2.4) ... A host MUST NOT send Router Advertisement messages at any time. That sounds blatantly obvious - router advertisments are for routers to send, what else could they be. However, it is permitted for a router to indicate that it doesn't want to route packets, by setting the router lifetime field to 0 (see the previous section). Such non-routing routers obviously do send RA packets, otherwise they'd have no place in which they could be setting that lifetime to 0... The question is: What's the difference between a non-routing router, which does send RA packets, and a simple multi homed host, which MUST NOT send RA packets? (Does it depend on the brand name stamped on the front of the box???) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 07:49:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA09784; Tue, 11 Mar 1997 07:41:30 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA09777; Tue, 11 Mar 1997 07:41:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA28612; Tue, 11 Mar 1997 07:42:03 -0800 Received: from central-services.east.isi.edu (central-services.east.isi.edu [38.245.76.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA23612 for ; Tue, 11 Mar 1997 07:42:10 -0800 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by central-services.east.isi.edu (8.7.5/8.7.3) with SMTP id KAA12424; Tue, 11 Mar 1997 10:41:50 -0500 (EST) Message-Id: <199703111541.KAA12424@central-services.east.isi.edu> X-Authentication-Warning: central-services.east.isi.edu: Host LOCALHOST [127.0.0.1] didn't use HELO protocol To: Koskelainen Petri cc: ipng@sunroof.eng.sun.com Subject: (IPng 3262) Re: IPv6 priority field usage? In-reply-to: Your message of "Tue, 11 Mar 1997 10:27:30 +0200." <199703110827.KAA11456@harakka.cs.tut.fi> X-Phone: +1 703 812 3704 From: "John W. Stewart III" Date: Tue, 11 Mar 1997 10:41:37 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1370 > > and btw, if you define the priority bits such that they're not > > comparable across flows, then how do you ensure that, e.g., > > routing updates get the highest priority? bona fide flow setup? > > Routing updates don't need header priorities. > > For example, OSPF and ICMP run directly over IPv6 so > they have their own protocol id. > > Those protocol numbers (routing protocols etc.) can be given > highest priority in routers. as someone else already pointed out, bgp runs over tcp so your proposed prioritization doesn't work. bgp, specifically i-bgp, is just as critical as igps like ospf, so it must have priority over user traffic are people assuming routers' ability to make the priority bits comparable just between packets from the same source? would router vendors care to comment on how doable this is in the near term? and are people willing to specify something that (1) maybe can't be implemented in the near term and (2) takes away something we have in ipv4 (specifically the low-overhead prioritization we get with the precedence bits)? /jws ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 09:22:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10015; Tue, 11 Mar 1997 09:15:15 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10008; Tue, 11 Mar 1997 09:15:06 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16734; Tue, 11 Mar 1997 09:15:49 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01265; Tue, 11 Mar 1997 09:15:49 -0800 Date: Tue, 11 Mar 1997 09:15:49 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199703111715.JAA01265@bobo.eng.sun.com> To: smurf@noris.de Subject: (IPng 3263) Re: 2 faced DNS is here to stay Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1239 > Unless we want address rewriting in the routers, which I thought the > interim meering has decided we _don't_ want (very sensible, IMHO), then > yes, every host does need to know their prefix(es). You are correct in that the interim meeting (which I agree with) felt that rewriting by routers has some problems. This means that the hosts need to know the high-order 8 bytes of their addresses. Thus the hosts will know their SUBNET prefixes (the RG + STP in the GSE terminology). However, this does not imply that all hosts need to know the position of the boundary between the RG and the STP. In fact I would argue that we do not want to require that all hosts know this boundary - not casting the boundary in concrete for all future will give us more flexibility to deploy different addressing schemes down the line. Note that the test for "is the destination in the same site?" is "does the destination RG match one of the senders RGs?". Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 09:50:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10072; Tue, 11 Mar 1997 09:42:53 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10065; Tue, 11 Mar 1997 09:42:43 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA19919; Tue, 11 Mar 1997 09:43:26 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01279; Tue, 11 Mar 1997 09:43:25 -0800 Date: Tue, 11 Mar 1997 09:43:25 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199703111743.JAA01279@bobo.eng.sun.com> To: kre@munnari.OZ.AU Subject: (IPng 3264) Re: 2 faced DNS is here to stay Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4124 > That is, RA messages, in the prefix option, already cover two > cases - addresses that are available for autoconfig, and addresses > that are "on link". Could we not add a third type "local site" > and add an "S" bit in one of the unused bits (there are plenty) > so that hosts could know all of the local site prefixes? It may > also be that simply not setting either L or A might be enough for > this purpose - indicating a prefix that should not be > autoconfig'd, and which might, or might not, be on the local > link - which is close enough to being equivalent to an address > that is someplace else in the site (or might be). Using RA messages is certainly a very interesting possibility. Just to make sure we agree on the semantics: When the destination address falls in a prefix with the 'S' bit set the sender should replace the top N bits (where N is the length of the matching 'S' prefix) with the site local prefix (defined in rfc1884). A question in my mind is if this can be overridden e.g. for hosts that know (somehow?) that they are mobile and might move outside the site. But the ipv6 mobility has some new possibilities when all unicast addresses have a globally unique ESD - but I digress. Note that we ESD style addressing the subnet prefixes will always be 8 bytes. This presumably means that all the prefixes that do not have the 'S' flag set will be 8 bytes. The 'S' prefixes will be shorter - 50 bits should we use the address format in draft-ietf-ipng-gseaddr-00.txt. Thus I expect that in practise the 'S' flag would not be set together with any of the other flags. I don't > I would thus prefer to make all the prefixes that are in use > in whatever you choose to define as your site available > everywhere inside the site - that is, make that information > known everywhere. I agree as long as the prefixes are "dynamic enough". Putting them in RA messages IMHO makes them dynamic enough and also has the advantage that the notion of the "site prefixes" can time out at the same time as all the subnet prefixes that are derived from that site prefix. > Personally I think that this combination provides a solution which > is easily workable, adequate, and much simpler both to implement, > understand, and maintain, than anything which attempts to require > 2 faced DNS servers to function. You've convinced me. Note that in addition to adding this feature to neighbor discovery we should also add it to the "Bob Hinden protocol for propagating prefixes from the border router to the interior routers" (I can't find a draft on this - it was presented at San Jose IETF). > ps: while I'm here, a question about RFC1970. On page 45 it > is stated (at the beginning of section 6.2.4) ... > > A host MUST NOT send Router Advertisement messages at any time. > > That sounds blatantly obvious - router advertisments are for > routers to send, what else could they be. However, it is > permitted for a router to indicate that it doesn't want to route > packets, by setting the router lifetime field to 0 (see the > previous section). Such non-routing routers obviously do send > RA packets, otherwise they'd have no place in which they could > be setting that lifetime to 0... > > The question is: What's the difference between a non-routing > router, which does send RA packets, and a simple multi homed host, > which MUST NOT send RA packets? (Does it depend on the brand > name stamped on the front of the box???) I think the intent is that a router (according to the definition in the spec) can choose not to be a default router by setting the router lifetime field to 0 but other routers can still redirect packets to it. Thus the router would still set the 'R' flag in the NA messages since it is being used to forward packets (not explicitely addressed to itself). Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 10:32:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA10294; Tue, 11 Mar 1997 10:23:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA10287; Tue, 11 Mar 1997 10:23:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA05737; Tue, 11 Mar 1997 10:24:08 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA10800 for ; Tue, 11 Mar 1997 10:24:18 -0800 Received: by snoopy.agile.com with Internet Mail Service (5.0.1389.3) id <01BC2E1E.D4F9AB80@snoopy.agile.com>; Tue, 11 Mar 1997 13:19:21 -0500 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Cc: "'kre@munnari.oz.au'" Subject: (IPng 3265) Re: 2 faced DNS is here to stay Date: Tue, 11 Mar 1997 13:19:20 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3165 Hi Robert, OK, this is another means by which hosts can be told to use site-local addresses, but it still needs to be tied in to the other pieces of the system...having the knowledge does no good with a means to apply the knowledge. > That is, RA messages, in the prefix option, already cover two > cases - addresses that are available for autoconfig, and addresses > that are "on link". Could we not add a third type "local site" > and add an "S" bit in one of the unused bits (there are plenty) > so that hosts could know all of the local site prefixes? It may > also be that simply not setting either L or A might be enough for > this purpose - indicating a prefix that should not be > autoconfig'd, and which might, or might not, be on the local > link - which is close enough to being equivalent to an address > that is someplace else in the site (or might be). Note that unless the L and proposed S bit are mutually exclusive, there will be an issue over the interpretation of the Prefix Length field (currently defined as "The number of leading bits in the Prefix that are valid."). If we go down this path, it might be nice to find a way to provide both on-link and on-site within the single option, rather than have multiple options for the same prefix. In other words, it would be wasteful to send two options: Prefix/Len=48/S-bit/CAFE:DEAD:: Prefix/Len=64/L-bit/CAFE:DEAD:0:1C:: when one would suffice: Prefix/S-bit/S-len=48/L-bit/L-len=64/CAFE:DEAD:0:1C:: But as you said, there seem to be plenty of spare bits to play with. > I would not require that however, some huge sites might easily > find that a burden more costly than it is worth. This is an important point...whatever mechanism we come up with must be universally implementable, but local configurable. > Personally I think that this combination provides a solution which > is easily workable, adequate, and much simpler both to implement, > understand, and maintain, than anything which attempts to require > 2 faced DNS servers to function. What you've described is a start, but for example, in your design the information about what prefixes are site-local comes in at the network layer, via RA's. The next question is, where is that information propogated? If it stays at the network layer, then the forwarding code could look at a given source/dest pair and determine that they were both within site scope. However, by that point the application has selected the [globally-scoped] destination address (presumably based on a DNS response via the resolver), and the transport checksums have been calculated. So the knowledge available at this level is hard to apply to the problem. The obvious alternative is to push the knowledge up to a higher level...and from your earlier mail it sounds like the resolver is the likely spot. The rules will have to be spelled out clearly. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 11 15:56:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10868; Tue, 11 Mar 1997 15:48:27 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10861; Tue, 11 Mar 1997 15:48:19 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA26735; Tue, 11 Mar 1997 15:49:02 -0800 Received: from frankyII.adv.es (fmeana-green.com [194.224.207.28]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA01989 for ; Tue, 11 Mar 1997 15:49:15 -0800 Received: from brainworld (nexus@[194.224.207.203]) by frankyII.adv.es (8.6.12/8.6.9) with ESMTP id AAA29401; Wed, 12 Mar 1997 00:48:09 +0100 Received: from localhost (nexus@localhost) by brainworld (8.7.5/8.6.9) with SMTP id AAA00127; Wed, 12 Mar 1997 00:17:33 +0100 X-Authentication-Warning: brainworld: nexus owned process doing -bs Date: Wed, 12 Mar 1997 00:17:33 +0100 (MET) From: Inigo Gonzalez X-Sender: nexus@brainworld To: Harri Hakulinen cc: ipng@sunroof.eng.sun.com Subject: (IPng 3266) Multimedia and Priority bits (was: IPv6 priority field usage?) In-Reply-To: Message-ID: Organization: Hack The Lies X-Copyright: The content of this letter is intelectual propery of the author MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5588 There are some things we must have in mind when thinking about mutimedia stuff: - As we all know, Multimedia eats a lot of bandwidth. It is desirable to discard a non essential part of any multimedia broadcast in order to save bandwidth. - ITOH Multimedia data cannot be considered as filler traffic as Usenet news. It needs at least a minimum bandwidth in order to obtain a minimum sound and video quality. It shouldn't have the minimum priority value (filler traffic) inside any IP network. =20 - There should be a _base_ priority value for network traffic. This value could be raised or lowered so that anyone will get the bandwidth he needs from his ISP. Problem: Where does priority raising should be done ? client-side or ISP-side ? Should I raise my packets' priority value; or should be changes by my ISP upon agreement ? First option is quite easy to implement. Option two will need some ICMPv6 traffic between the client and the ISP. - If any future protocol has a required chunk of data and a=20 dischardable one, it shouldn't send 'required' data inside an IPv6 packet with high priority, and 'dischardable' data inside lower priority packets. IPv6 is connectionless and there is no guarantee your packets will arrive to destination; even if they have maximum priority. IMHO the solution here should be providing a protocol over IP able to send 'required' data in a connection fashion; and=20 dischardable data in a connectionless fashion. Sending packets with different priority values is unreliable. -- Inigo Gonz=E1lez On Tue, 11 Mar 1997, Harri Hakulinen wrote: >=20 > I quess my mailgw ate my previous mail, so I try again. >=20 > I think that video(phone) is one of the moust important new > application areas for IP(v6) networks. Even so important,=20 > that it seems reasonable (at least for me) to take it account > in this case. That is because when SW-based video coding and > decoding is used in IP network and multiplexed with IP tools > (e.g. with RTP), it is actually difficult to say where video > coding ends and network (protocol) starts.=20 >=20 > When Petri had his example few mails ago, he said that for=20 > layered encoded video streams it makes sense to vary bethween > e.g. 500 kbits and 200 kbits. It was of course an simplified > example. =20 >=20 > Other example could be MPEG2 video stream. It consist of > B,P and I -frames. I-frames are very important for receivers. > If I-frame is not received correctly, basically all following > B and P -frames are unusable up to next I-frame. As sender- > receiver pair I want to be sure that IP packets containing B > and P frames are dropped if something has to be dropped > (this is really "oversimplified" MPEG2). >=20 > So, If video packets are dropped _in_random_way_, damage in > picture is easily very big when compared to sender based > selection of dropped packets (by using IPv6 priority field).=20 >=20 > You may say that better way to handle these streams is to use > some kind of adaptive method, that is based on real time > measured network troughtput. But the problem is, that > these kind of methods are relatively slow to react and it > is very easy to "see or hear missing packets" from e.g. > video/audio stream. >=20 > In my imagination priority field is used so, that normally=20 > highest priority value is used for all traffic. When sender > knows, that parts of the traffic are more important than=20 > some other parts, he marks lower importance packets by using > lower priority. By doing this, sender knows that there is > _highest_possibility_ that important packets are received by > receiver in the case of network congestion. >=20 > If the congestion happens, router begins to drop packets that > have low priority value. If this is not enough, router has to > drop high priority packets also, of course. Here I assume, that > router can react much more faster to local congestion than any > end-to-end flow control protocol. It could even be nice to > specify, that routers should drop low priority packets in advance > to avoid more serious (predicted) congestion. >=20 > As far as I understand, the best way to send video over internet > is to use layered video coding with _combination_ of adaptive > bandwith usage _and_ priority marked IP(v6) packets. Thats why I > don't support the idea of removing moust of application defined > priorities. >=20 > Instead, I think that priority field could be redefined e.g. > in the following way (maybe not elegant, but gives an idea): >=20 > 1st bit defines, if 3 other bits are used by/bethween routers > or by end-to-end application. If 1st bit is 1, 3 other bits are > used by routers e.g. for routing traffic (I don't know how).=20 >=20 > If 1st bit is 0, other bits are used by end-to-end application, > and routers are not allowed to modify them. Instead, routers must > act in congestion situation as I described before.=20 >=20 > This gives 8 different priorities for application use. Those > priorities could also be used to define, which traffic belongs > to "my base share of net quota" as someone earlier suggested. >=20 > - > Harri.Hakulinen@research.nokia.com > Video laboratory/Network & Terminal technologies > Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 12 09:41:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11983; Wed, 12 Mar 1997 09:33:18 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11976; Wed, 12 Mar 1997 09:33:13 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02010; Wed, 12 Mar 1997 09:33:58 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07987; Wed, 12 Mar 1997 09:33:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA11038; Tue, 11 Mar 1997 16:22:43 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA04818; Tue, 11 Mar 1997 16:23:22 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA16148 for ; Tue, 11 Mar 1997 16:23:36 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA32842; Tue, 11 Mar 1997 19:23:20 -0500 Received: from vision.raleigh.ibm.com (vision.raleigh.ibm.com [9.37.177.224]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id TAA49892 for ; Tue, 11 Mar 1997 19:23:19 -0500 Received: by vision.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26956; Tue, 11 Mar 1997 19:23:20 -0500 Message-Id: <9703120023.AA26956@vision.raleigh.ibm.com> X-Mailer: exmh version 1.6.9 8/22/96 To: ipng@sunroof.eng.sun.com Subject: (IPng 3268) Re: IPv6 priority field usage? In-Reply-To: Your message of "Tue, 11 Mar 1997 10:41:37 EST." <199703111541.KAA12424@central-services.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Mar 1997 19:23:18 EST From: Steven L Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5479 John W. Stewart III wrote: > are people assuming routers' ability to make the priority bits > comparable just between packets from the same source? would > router vendors care to comment on how doable this is in the > near term? Can't comment on what other people assume, but the ability to count packets within a flow is a basic requirement of any Integrated Services implementation (for policing/shaping/etc). This capability is associated with a cost; packets must be classified into flows, but IPv6 has been designed with the necessary features to make this reasonably easy, by using the flow label and the source address which are unique per-flow, and of fixed length. The main distinction between IntServ classification and a general per- source fairness mechanism for priority is that IntServ flows are signaled (by RSVP or whatever) and the classifier template and the policing/shaping parameters for each flow are specified, while in the case of "best-effort" flows, there is no classifier/policer set-up. Routers would have to dynamically cache best-effort flow state (by caching source address and possibly flow label, depending on whether fairness was per-sender or per-sender/destination/application) and traffic parameters (such as t_arrival_previous) to be able to arbitrate priority service among flows. Some routers may already be caching source address/flow label (for flows with non-zero flow label), since this is a permitted forwarding mechanism (RFC 1883, pg. 29), but I can imagine that dynamic flow caching and cache management could be quite expensive, depending on the implementation. Another complication is defining a flow's "fair share" of high-priority bandwidth at any given instant. > and are people willing to specify something that > (1) maybe can't be implemented in the near term and (2) takes > away something we have in ipv4 (specifically the low-overhead > prioritization we get with the precedence bits)? I am definitely in the camp which believes that a "drop-preference" bit is a potentially useful feature, especially for applications like two-layer video. Such a feature is useful even for reserved IntServ flows, since I may prefer to drop a packet if it will bring the queueing delay of a subsequent packet which my application has prioritized within some advertised delay bound. Its main utility to video applications is under conditions of transient congestion; under heavy congestion a video application should reshape or should pay for a reservation. I base this reasoning on the research I did for my PhD (which should be published some-year. :) I would be happy to go into detail off-line, but the bottom line of what I observed with the codec I implemented was that the use of a low-priority layer was only advantageous for transient bursts due to frame changes, that the average ratio of low-priority to high-priority traffic for a video application was less than 0.5, and that multiple levels of priority were not advantageous, so I wouldn't argue for more than one drop-preference bit. I can understand the objections to including a drop-preference bit in IPv6, since it gives applications an incentive to flood the network with traffic which should have backed-off. One of the things I think is clever about Steve Deering's "interactive" bit proposal is that it includes both a carrot and a stick; setting the bit may lead to lower queueing delay, but the total throughput of interactive traffic may be bounded (this proposal is vulnerable to similar per-source fairness criticisms). Making the drop- preference bit tenable probably requires a similar stick, such as: - nuke packets with drop-preference set and Next Header != UDP - police the aggregate drop-preference traffic to some rate < link rate (say 25% link rate) even when not under congestion - implement a drop threshold for drop-preference traffic (at a queue delay less than what is considered "congestion") - after an interval of congestion, nuke drop-preference traffic for a period proportional to the length of the congestion interval I suspect that mechanisms such as these will deter applications from abusing the feature, and can be implemented reasonably easily. The ISP of course needs an incentive to honor either the drop-preference or the interactive bit. I think that an argument can be made that supporting separate queues and policers for interactive and low-priority video traffic allows ISPs to satisfy their customer's expectations while operating at a higher utilization. At any rate, I think that at least an interactive bit and a drop-preference bit should be available to the application, with the understanding the the network can overwrite/ignore either of these at will. I'm going to write up a short proposal for this and send it to the list tomorrow. Regards, /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Steven L. Blake slblake@vnet.ibm.com | | Internetworking Technology (919)254-2030 (work) | | IBM Networking Division (919)254-5483 (fax) | | "You like the 'Net? You ain't seen nothin' yet!" | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 06:26:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA13496; Thu, 13 Mar 1997 06:18:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA13489; Thu, 13 Mar 1997 06:18:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA22550; Thu, 13 Mar 1997 06:19:23 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA18437 for ; Thu, 13 Mar 1997 06:19:59 -0800 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id QAA20715; Thu, 13 Mar 1997 16:19:22 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id QAA27192; Thu, 13 Mar 1997 16:19:20 +0200 (EET) Message-Id: <199703131419.QAA27192@harakka.cs.tut.fi> Subject: (IPng 3269) Re: IPv6 priority field usage? In-Reply-To: <9703120023.AA26956@vision.raleigh.ibm.com> from Steven L Blake at "Mar 11, 97 07:23:18 pm" To: slblake@vision.raleigh.ibm.com (Steven L Blake) Date: Thu, 13 Mar 1997 16:19:19 +0200 (EET) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2252 > > I am definitely in the camp which believes that a "drop-preference" bit > is a potentially useful feature, especially for applications like two-layer > video. Such a feature is useful even for reserved IntServ flows, since I [deleted] > reasoning on the research I did for my PhD (which should be published > some-year. :) I would be happy to go into detail off-line, but the bottom > line of what I observed with the codec I implemented was that the use of a > low-priority layer was only advantageous for transient bursts due to frame > changes, that the average ratio of low-priority to high-priority traffic > for a video application was less than 0.5, and that multiple levels of > priority were not advantageous, so I wouldn't argue for more than one > drop-preference bit. That was one implementation and one approach to video coding. Better video codecs, more suitable for layered coding will surely be introduced in the next 10 years or so. Why wouldn't we prepare to that and left at least 2 bits for sender drop-prefedence ? > At any rate, I think that at least an > interactive bit and a drop-preference bit should be available to the > application, with the understanding the the network can overwrite/ignore > either of these at will. If network will quite often overwrite/ignore these bits, then applications can't count of them, and they won't use them. This means than fewer ISPs even support those, and fewer applications use them and fewer ISPs support them and fewer applications use........ (of course there can't be 100% commitment without signaled reservations, but strong propability that drop-prefedence bits are used by ISP there has to be) Anyway, I don's see why ISP would not support priority bits. It's better service for customers with very little extra costs in routers (as pointed out, int-serv routers requires those capabilities anyway) Petri Koskelainen Nokia Research Center ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 06:54:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA13520; Thu, 13 Mar 1997 06:47:38 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA13513; Thu, 13 Mar 1997 06:47:29 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29595; Thu, 13 Mar 1997 06:48:13 -0800 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA28581 for ; Thu, 13 Mar 1997 06:48:39 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Mar 1997 14:47:50 +0000 cc: ipng@sunroof.eng.sun.com Subject: (IPng 3270) Re: IPv6 priority field usage? In-reply-to: Your message of "Thu, 13 Mar 1997 16:19:19 +0200." <199703131419.QAA27192@harakka.cs.tut.fi> Date: Thu, 13 Mar 1997 14:47:48 +0000 Message-ID: <1943.858264468@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1379 there are 3 interesting numbers: 0, 1 and infinity in QoS, this leads to 3 interesting approaches for each of throughput, delay and loss, you can use RSVP, or you can have ToS bits- either have a bit each, or none - if you use RSVP you get to specify complex parameters; otherwise: there is a lot of literature now that shows you can do some neat QoS support with just 2 lvels of priority, and of course some neat layered video work - though there are easy ways to do multiple levels (send on multiple oprts, and set the loss bit differently, send on ,multiple multicast addres, and use RSVP on some or with different parameters on others....) i can't see any reason to do more or less than IPv4 did with TOS bits...and precendence, personally..... as has been said, a single bit is already in use for premium service by some ISPs - have they asked for more? i havnt seen that yet..... how many classes of ticket are there on airlines? hmmm....ok....:-) plz see also the RED manifesto...recently advertised on the end2end-interest list... [draft-irtf-e2e-queue-mgt-recs.ps] cheers jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 07:50:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13570; Thu, 13 Mar 1997 07:43:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13563; Thu, 13 Mar 1997 07:43:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA17773; Thu, 13 Mar 1997 07:44:01 -0800 Received: from mailhub.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA23024 for ; Thu, 13 Mar 1997 07:43:59 -0800 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Thu, 13 Mar 1997 15:37:51 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA22890; Thu, 13 Mar 1997 15:33:00 GMT Date: Thu, 13 Mar 1997 15:33:00 +0000 (GMT) From: George Tsirtsis To: ipng@sunroof.eng.sun.com Cc: ietf-coord@gideon.bt.co.uk Subject: (IPng 3271) Re:IPv6 priority field usage Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2075 >I'll support Steve's original point and say these bits should >be reserved for the domain of the provider. If TOS effects >the queuing of traffic within the network, it'll be essential >for providers to be able to manage this resource (network >management/control being the obvious example) This necessarily >implies that TOS will have to settable by the provider. This >also implies that TOS should be excluded from the checksum >for the IPSEC work. > >-scott We entirely agree with Scott, precedence bits are used in a variety of ways by I SPs because they must have means to manage traffic effectively and provide differential means of huddling customer ports and packets. Trying to define these bits end-to-end is well intentioned. Applications and peer networks may optionally use precedence bits but it is unreasonable to expect them to be supported end to end. QoS WGs (RSVP, QoS routing etc.) are the appropriate places for end to end and QoS issues, unless some clear limitations are identified, for these approaches, in the future. George Tsirtsis -------------------------------------------------------------------------- Network Research Tel : 0044-1473-640756 BT Labs Fax : 0044-1473-640709 Ipswich e-mail: george@gideon.bt.co.uk -------------------------------------------------------------------------- Notice: This contribution has been prepared to assist the IETF as a basis for discussion. It is not a binding proposal on British Telecommunications plc; specifically, British Telecommunications plc reserves the right to modify, delete or amend any statements contained herein. -------------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 09:33:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13759; Thu, 13 Mar 1997 09:26:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13752; Thu, 13 Mar 1997 09:26:12 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA10069; Thu, 13 Mar 1997 09:26:56 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA11750 for ; Thu, 13 Mar 1997 09:27:34 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcgsj07200; Thu, 13 Mar 1997 12:26:48 -0500 (EST) Message-Id: To: Jon Crowcroft cc: ipng@sunroof.eng.sun.com Subject: (IPng 3273) Re: IPv6 priority field usage? In-reply-to: Your message of "Thu, 13 Mar 1997 14:47:48 GMT." <1943.858264468@cs.ucl.ac.uk> Date: Thu, 13 Mar 1997 12:26:48 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 406 re: more priority bits "ISPs haven't asked asked for more" what makes you believe you know what we've asked for?? -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 10:25:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA13950; Thu, 13 Mar 1997 10:16:13 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA13935; Thu, 13 Mar 1997 10:16:01 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA23122; Thu, 13 Mar 1997 10:16:43 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA05366 for ; Thu, 13 Mar 1997 10:17:21 -0800 Received: from [128.3.9.22] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 13 Mar 1997 10:16:44 -0800 X-Sender: rlfink@cnrmail.lbl.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 13 Mar 1997 10:16:41 -0800 To: Matt Crawford From: Bob Fink LBNL Subject: (IPng 3274) some info on 64-bit global IDs Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2339 Matt, I was able to get a bit more info on 64 bit global identifiers, and am in the process of getting more background info through Gary Robinson (will forward it on when I get it). Meanwhile, I've hand entered below some of the relevant info from the one page format tutorial handout I received yesterday from Gary. It seems to show that the two extra bytes are inserted in the middle (as we had heard) and are set to all-ones if they are really an extended 48-bit address being shown in 64-bit form. Bob ======from the 64-bit Global Identifier Format Tutorial handout - 3 Nov 1994 Format ______ You may have a 64-bit global identifier (EUI-64) provided by an authorized manufacturer of these values (in the form of electronically readable chips). The most-significant 24 bits of this value are the company_id value assigned to the manufacturer by the IEEE Registration Authority. The least-significant 40-bit extension identifier is assigned by the manufacturer. For example, assume that a manufacturer's IEEE-assigned company_id value is ACDE48(base 16) and the manufacturer's extension identifier is 234567ABCD(base 16). The EUI-64 value generated from these two numbers is ACDE48234567ABCD(base 16). ... (remainder skipped, it just elaborated bit layouts) Restricted and encapsulated values __________________________________ To support encapsulation of EUI-48 values within a small subset of the EUI-64 values, the first four digits of the manufacturer's extension identifier shall not be FFFF(base 16) or FFFE(base 16). Thus, the 64-bit values of the following form (where 'x' is a arbitrary hexadecimal digit) are never assigned EUI-64 values: xxxxxxFFFFxxxxxx(base 16) (an EUI-48 extension) ccccccFFFEeeeeee(base 16) (reserved by IEEE/RAC) The letters 'c' and 'e' represent hexadecimal digits and sho how the EUI-48 value can be unambiguously encapsulated within the EUI-64 value; the 'c' and 'e' digits represent the company_id and extension-identifier portions of the EUI-64 value respectively. - end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 10:25:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA13951; Thu, 13 Mar 1997 10:16:15 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA13943; Thu, 13 Mar 1997 10:16:09 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05475; Thu, 13 Mar 1997 10:16:54 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA09054; Thu, 13 Mar 1997 10:16:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13683; Thu, 13 Mar 1997 08:23:43 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA26644; Thu, 13 Mar 1997 08:24:28 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA12371 for ; Thu, 13 Mar 1997 08:25:00 -0800 Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA42192; Thu, 13 Mar 1997 11:24:20 -0500 Received: from vision.raleigh.ibm.com (vision.raleigh.ibm.com [9.37.177.224]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id LAA80846 for ; Thu, 13 Mar 1997 11:24:20 -0500 Received: by vision.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29998; Thu, 13 Mar 1997 11:24:20 -0500 Message-Id: <9703131624.AA29998@vision.raleigh.ibm.com> X-Mailer: exmh version 1.6.9 8/22/96 To: ipng@sunroof.eng.sun.com Subject: (IPng 3275) Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Thu, 13 Mar 1997 14:47:48 EST." <1943.858264468@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Mar 1997 11:24:18 EST From: Steven L Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7048 I promised this was going to be short, but ... :) Please consider the following proposal for the use of the IPv6 priority field. I think that it is general enough to provide flexibility both to the host and to the network, while providing substantial benefits to some applications. I will write up a draft for Memphis if there is any interest. Proposed semantics for the IPv6 Priority field 12-Mar-97 +---+---+---+---+ | H | R | D | I | 4-bit IPv6 Priority field +---+---+---+---+ H: High Priority This bit, when set to one, is intended to indicate packets which are critically sensitive to queueing delay and loss. This bit is intended for use by network control protocols, such as ICMP/BGP/ OSPF/etc, whose aggregate thruput is typically a small fraction of the available link capacity. Normal hosts MUST set H=0. Router network control protocol implementations and network management stations MAY set H=1. Edge routers (host's first hop router) SHOULD reset this bit (H=0). Routers SHOULD preferentially schedule packets with H=1 to ensure low queueing delay and low packet loss under congested conditions. (This needs to be specified in the sockets API to priority-enable BGP implementations, right?) R: Reserved Use of this bit by hosts is reserved for future study. Hosts MUST set R=0. Routers MAY use this bit for internal network functions. Edge routers SHOULD reset this bit (R=0) if not used for an internal network function. One possible use of this bit by hosts is to indicate packets of a flow for which the host has transmitted RSVP PATH messages. This might allow optimized implementations of RSVP packet classification within routers. D: Drop Preference This bit, when set to one, is intended to indicate packets, belonging to an application flow, whose loss will not critically impair the performance of that application. One proposed use of this bit by hosts is to indicate packets belonging to an enhancement-layer sub- flow of a multi-layer multimedia flow. An alternative use is to indicate packets within an Integrated Services flow which have failed a policing function at an upstream node. Best-effort flows: Application packets of a flow which is not associated with an Integrated Services reservation MAY set D=1 to indicate those packets whose loss is not critical to the performance of the application. "Drop preference service" is not intended for applications with reliable transport requirements (i.e., requiring retransmission of a lost packet). Applications should expect the probability of loss of packets with D=1 to be significantly larger than the probability of loss of packets with D=0. Applications should expect the network to take measures to restrict the aggregate thruput of traffic with D=1, even under uncongested conditions. Integrated Services flows: Application packets of a flow which is associated with an Integrated Services reservation MAY set D=1 to indicate those packets whose loss is not critical to the performance of the application. Integrated Services implementations which attempt to provide a low or predicted level of queueing delay MAY choose to preferentially drop or schedule as best-effort those packets with D=1. Integrated Services implementations MAY choose to preferentially penalize (e.g., by scheduling as best-effort) those packets within a flow with D=1 in the event that that flow has exceeded its reserved Tspec. Integrated Services implementations MAY choose to exclude some or all of those packets within a flow with D=1 from the flow's policing calculation. Integrated Services implementations MAY choose to set D=1 for packets which have failed a policing function. Hosts MAY set D=1 to indicate packets which request "drop preference" handling. Routers MAY reset D=0, or MAY utilize this bit for internal network functions. One proposed internal network application (paraphrased from Dave Clark's talk; and hopefully not butchered :) of the drop preference bit is to indicate those packets which are "in-profile" (D=0) or "out-of-profile" (D=1) with respect to some traffic policy policing function which has been contractually negotiated between a network and a client (e.g., host, site, ISP). Routers MAY set D=1 for those packets which are "out-of-profile". Routers MAY choose to exclude those packets received with D=1 from the profile policy policing calculation. Routers are RECOMMENDED to preferentially drop packets with the drop preference bit set (D=1). (The idea that hosts should never set D=1 for TCP traffic contradicts the idea that the host may set D=1 for some low-priority TCP flows to influence the policy policing function). I: Interactive This bit, when set to one, is intended to indicate packets belonging to an application flow which is sensitive to queueing delay but which does not have high thruput requirements (e.g., telnet). Applications should expect the network to take measures to restrict the aggregate thruput of traffic with I=1. Hosts MAY set I=1 to indicate those packets which request "interactive service" handling. Routers MAY reset I=0, or MAY utilize this bit for internal network functions. Routers are RECOMMENDED to preferentially schedule packets with the interactive bit set (I=1). * Priority bits have no significance at receivers. Receivers MUST NOT use the value of a priority bit to perform application demultiplexing. * Routers MAY rewrite the 4-bit priority field for internal network functions. * Routers SHOULD utilize the H and R bits for internal network functions before rewriting the D and I bits. * The priority field is intended for packet scheduling only. Routing protocols SHOULD NOT build per-priority routing paths. * The 4-bit priority field MUST be excluded from the AH checksum calculation. * Modify the text on page 28 of RFC 1883: "All packets belonging to the same flow must be sent with the same source address, destination address, priority, and flow label." to exclude priority. Routers SHOULD NOT cache packet priority for opportunistically cached flow-handling state. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 15:15:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14446; Thu, 13 Mar 1997 15:07:29 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14439; Thu, 13 Mar 1997 15:07:19 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA14844; Thu, 13 Mar 1997 15:07:46 -0800 Received: from daleth.canberra.edu.au (daleth.canberra.edu.au [137.92.11.173]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA11513 for ; Thu, 13 Mar 1997 15:08:21 -0800 Received: by daleth.canberra.edu.au with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC3057.29D31A80@daleth.canberra.edu.au>; Fri, 14 Mar 1997 09:07:38 +1000 Message-ID: From: "Fischer, Michael" To: "'IPNG'" Subject: (IPng 3276) re: Proposed IPv6 Priority Field Semantics Date: Fri, 14 Mar 1997 09:07:36 +1000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 564 Maybe I am wrong, but in my eyes there is no case in which it makes sense to set more than one bit for one packet (maybe except the R bit). Therefor coding them binary would open a wider range for future definitions. If necessary the R bit could be excluded. - Michael Fischer ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 16:36:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA14538; Thu, 13 Mar 1997 16:29:09 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA14531; Thu, 13 Mar 1997 16:29:00 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA07675; Thu, 13 Mar 1997 16:29:44 -0800 Received: from mail.ton.tut.fi (mylly.ton.tut.fi [193.166.80.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA12986 for ; Thu, 13 Mar 1997 16:30:23 -0800 Received: from localhost (veikko@localhost) by mail.ton.tut.fi (8.8.0/8.8.0) with SMTP id CAA26137; Fri, 14 Mar 1997 02:22:17 +0200 (EET) Date: Fri, 14 Mar 1997 02:22:16 +0200 (EET) From: Harri Hakulinen Reply-To: Harri Hakulinen To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 3277) Re: IPv6 priority field usage? In-Reply-To: <9703110459.AA23084@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1487 On Mon, 10 Mar 1997 bound@zk3.dec.com wrote: > Yours and Christian Huitema's responses have made me change my mind. I > think we may need the priority bits. The con's so far on this list have ... > Could we use the flow lable to define priority for video and audio? If not > why not? In every case I came up with for use of priority bits for IP > applications I can set up a flow if I really want prioritization. I don't think so, because I see that flow label has different function than "drop preference bit". It would probably make sense to use them even together in some cases. Maybe certain type of flows could be used to signalize/help routers to realize that sender-receiver pair is going to use priority bits. You may argue, that layered video coding model could also be realized using different flows/reservations for different layers. That might allow receiver to select only those that he can get at certain time. But I still think that priorities are needed to "smooth" things and somehow I feel that drop preference fits better to internet than (reserved) flows altogether. - Harri.Hakulinen@research.nokia.com Video laboratory/Network & Terminal technologies Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 17:03:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA14569; Thu, 13 Mar 1997 16:55:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA14562; Thu, 13 Mar 1997 16:55:11 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA14017; Thu, 13 Mar 1997 16:55:55 -0800 Received: from mail.ton.tut.fi (mylly.ton.tut.fi [193.166.80.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA22823 for ; Thu, 13 Mar 1997 16:56:37 -0800 Received: from localhost (veikko@localhost) by mail.ton.tut.fi (8.8.0/8.8.0) with SMTP id CAA26251; Fri, 14 Mar 1997 02:55:46 +0200 (EET) Date: Fri, 14 Mar 1997 02:55:45 +0200 (EET) From: Harri Hakulinen To: Inigo Gonzalez cc: ipng@sunroof.eng.sun.com Subject: (IPng 3278) Re: Multimedia and Priority bits (was: IPv6 priority field usage?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2984 On Wed, 12 Mar 1997, Inigo Gonzalez wrote: > There are some things we must have in mind when thinking > about mutimedia stuff: For me multimedia means something that you can get from web page now. Lets discuss on media or directly video&audio. > - As we all know, Multimedia eats a lot of bandwidth. It is > desirable to discard a non essential part of any multimedia > broadcast in order to save bandwidth. Define "non essential". Is it something over certain bandwith, screen size, frame rate, picture quality or what ? > - ITOH Multimedia data cannot be considered as filler traffic as > Usenet news. It needs at least a minimum bandwidth in order to > obtain a minimum sound and video quality. It shouldn't have the > minimum priority value (filler traffic) inside any IP network. Depending on your application, all video traffic that goes over certain minimum requirements can be seen as filler traffic. That could be a way to act like a good Internet citicen... > - There should be a _base_ priority value for network traffic. This > value could be raised or lowered so that anyone will get the bandwidth > he needs from his ISP. Problem: Where does priority raising should > be done ? client-side or ISP-side ? Should I raise my packets' > priority value; or should be changes by my ISP upon agreement ? > First option is quite easy to implement. Option two will need > some ICMPv6 traffic between the client and the ISP. I wonder if this works. If other users raise their priority to get more, obviously I _have_to_ raise my priority to get same share that I get before those other people raise their priority. And so on and so on ... > - If any future protocol has a required chunk of data and a > dischardable one, it shouldn't send 'required' data inside an > IPv6 packet with high priority, and 'dischardable' data inside > lower priority packets. I have just opposite view ;) > IPv6 is connectionless and there is no > guarantee your packets will arrive to destination; even if they > have maximum priority. That is true. But you cannot use TCP for video, it does not work. > IMHO the solution here should be providing a protocol over IP > able to send 'required' data in a connection fashion; and > dischardable data in a connectionless fashion. Sending packets > with different priority values is unreliable. If you consider RSVP reservation as connection, this might work in some cases. But for video you have to use udp-like protocols and it is unreliable anyway. - Harri.Hakulinen@research.nokia.com Video laboratory/Network & Terminal technologies Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 17:36:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14617; Thu, 13 Mar 1997 17:28:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14610; Thu, 13 Mar 1997 17:28:00 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA21167; Thu, 13 Mar 1997 17:28:43 -0800 Received: from mail.ton.tut.fi (mylly.ton.tut.fi [193.166.80.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA04174 for ; Thu, 13 Mar 1997 17:29:25 -0800 Received: from localhost (veikko@localhost) by mail.ton.tut.fi (8.8.0/8.8.0) with SMTP id DAA26363; Fri, 14 Mar 1997 03:28:41 +0200 (EET) Date: Fri, 14 Mar 1997 03:28:40 +0200 (EET) From: Harri Hakulinen To: Steven L Blake cc: ipng@sunroof.eng.sun.com Subject: (IPng 3279) Re: IPv6 priority field usage? In-Reply-To: <9703120023.AA26956@vision.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1385 On Tue, 11 Mar 1997, Steven L Blake wrote: > I am definitely in the camp which believes that a "drop-preference" bit > is a potentially useful feature, especially for applications like two-layer > video. ... > low-priority layer was only advantageous for transient bursts due to frame > changes, that the average ratio of low-priority to high-priority traffic > for a video application was less than 0.5, and that multiple levels of > priority were not advantageous, so I wouldn't argue for more than one > drop-preference bit. I think that only one drop-preference bit is maybe not futureproof solution. It might be that in the future we need more "guided intelligence" in the network than we can predict now. There has not been so much research in this area yet (up to my kowledge). In moust cases codecs have been optimized for certain specific constant bit rates, due to limitations of network or other parts of the system (memory). BTW,can you give any references to codecs that you used ? - Harri.Hakulinen@research.nokia.com Video laboratory/Network & Terminal technologies Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 18:07:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14703; Thu, 13 Mar 1997 17:58:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14696; Thu, 13 Mar 1997 17:58:46 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA26989; Thu, 13 Mar 1997 17:59:30 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA14109 for ; Thu, 13 Mar 1997 18:00:13 -0800 Received: by rodan.UU.NET id QQcgtr29340; Thu, 13 Mar 1997 20:59:31 -0500 (EST) Date: Thu, 13 Mar 1997 20:59:31 -0500 (EST) From: mo@UU.NET (Mike O'Dell) Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 3280) a modest number of "SQ" bits... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 690 i have to come down on the side of having a modest number of Service Quality bits carried in the packet one way or another. if carving them off the flow id is the solution, so be it. but there needs to be a way to do this short of setting up "flows" across large infrastructures. this kind of thing is going to be happening with IPv4 and it won't be something people will be willing to give up.... -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 18:21:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14737; Thu, 13 Mar 1997 18:10:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14722; Thu, 13 Mar 1997 18:10:19 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA29033; Thu, 13 Mar 1997 18:11:02 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA18674 for ; Thu, 13 Mar 1997 18:11:46 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id SAA27233; Thu, 13 Mar 1997 18:11:02 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id SAA02197; Thu, 13 Mar 1997 18:11:00 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 18:11:02 -0800 To: Steven L Blake From: fred@cisco.com (Fred Baker) Subject: (IPng 3281) Proposed IPv6 Priority Field Semantics Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4376 At 11:24 AM 3/13/97, Steven L Blake wrote: > H: High Priority > > This bit, when set to one, is intended to indicate packets which > are critically sensitive to queueing delay and loss. This bit is > intended for use by network control protocols, such as ICMP/BGP/ > OSPF/etc, whose aggregate thruput is typically a small fraction > of the available link capacity. > > Normal hosts MUST set H=0. Router network control protocol > implementations and network management stations MAY set H=1. > Edge routers (host's first hop router) SHOULD reset this bit (H=0). > > Routers SHOULD preferentially schedule packets with H=1 to ensure > low queueing delay and low packet loss under congested conditions. > > (This needs to be specified in the sockets API to priority-enable > BGP implementations, right?) My customers are telling me this should be a range, not a bit. IPv4's three bit field appears to be adequate, two bits may be enough, but one bit is not the best idea. It should be settable by the host (in the VoIP case, only the host knows it is VoIP), and should be overwritable by the router in the case of administrative controls. By the way, specifying *how* priority should be implemented is out of scope - there are a number of approaches possible, and the one that I cannot recommend is the one that IPv4 specifies. You want to use it as a class selector in class based queuing, a weight selector in weighted fair queuing, or a drop preference in RED. Which brings us to... > D: Drop Preference > > This bit, when set to one, is intended to indicate packets, belonging > to an application flow, whose loss will not critically impair the > performance of that application. One proposed use of this bit by > hosts is to indicate packets belonging to an enhancement-layer sub- > flow of a multi-layer multimedia flow. An alternative use is to > indicate packets within an Integrated Services flow which have > failed a policing function at an upstream node. I would suggest that priority is in fact a drop preference. If I am sending a stream and labelling some packets with a higher priority than others, and the network is being forced to drop something, it will drop the lower priority traffic first. > I: Interactive > > This bit, when set to one, is intended to indicate packets belonging > to an application flow which is sensitive to queueing delay but which > does not have high thruput requirements (e.g., telnet). Applications > should expect the network to take measures to restrict the aggregate > thruput of traffic with I=1. This is really not a good idea. Interactivity is an attribute of the traffic more than an attribute of the application. For example, if I am running telnet or X Windows and I decide to display a file on the screen, at that moment the application is acting as a file transfer, not an exchoplx interaction. A classic example is what X does with mouse movements - imagine a long stream of small TCP segments that say "the mouse moved, the mouse moved." The way you want to deal with this attribute is to run a WFQ or etc, and let traffic which has low queue occupancy garner the benefits of the queuing algorithm, and force traffic with higher queue occupancy to share the available resource nicely. That you have to do on a flow basis, not a traffic attribute basis. Frankly, I think you want the same breakout that IPv4 has - two or three bits of priority, and a few TOS bits. We are getting requests for limited TOS routing, which we are implementing using policy route maps. For example, you might send IP Multicast to a satellite link that distributes it to a number of geographically distinct points, and but send unicast by the more usual routes, or other approaches. And you will want the TOS bits to be settable by the application or administrativesly. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 13 18:21:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14738; Thu, 13 Mar 1997 18:10:40 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14730; Thu, 13 Mar 1997 18:10:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA29042; Thu, 13 Mar 1997 18:11:06 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA18689 for ; Thu, 13 Mar 1997 18:11:49 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id SAA27241; Thu, 13 Mar 1997 18:11:06 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id SAA02200; Thu, 13 Mar 1997 18:11:04 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Mar 1997 18:11:07 -0800 To: "John W. Stewart III" From: fred@cisco.com (Fred Baker) Subject: (IPng 3282) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2232 At 10:41 AM 3/11/97, John W. Stewart III wrote: >are people assuming routers' ability to make the priority bits >comparable just between packets from the same source? Would >router vendors care to comment on how doable this is in the >near term? Let's put it this way. IPv4 precedence has been in there since the publication of RFC 791, but was not widely implemented until quite recently. It became implemented for two reasons: - an application that needed it - customer requirements to support that application the applications in question are (a) multi-media, which in the Voice-on-IP case is probably better served (as Huston and Rose point out in their draft on the subject) by something lightweight than by something heavy-weight. Imagine an RSVP session each way for each 8 KBPS VoIP session on a 622 MBPS link... (b) SNA/DLSW, which wants the network to give better service to certain traffic over others (c) administrative weighting of traffic by ISPs and backbone providers, which want to provide a "you pay more $$$, you get a better worst case in your service." Note that all of the above are selecting among traffic overall, not traffic as originated by a source. The point is not that a particular source wants better service for some of its traffic than for others, the point is that certain applications require a certain class of service from the network, or that there are administrative reasons to sort traffic use. Making IPv6 precedence somehow associate with the source address doesn't map to the ambient application requirements. What will router vendors do? Router vendors will do what their customers tell them makes their applications work well. If the choice is between IPv6 with some idiotic association, and IPv4 with an IP Precedence mapping that maps well to applications, customers will tell their router vendors to do whatever it takes to make IPv4 have a *real*long*lifetime*. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 02:46:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA15131; Fri, 14 Mar 1997 02:38:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA15124; Fri, 14 Mar 1997 02:37:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA16024; Fri, 14 Mar 1997 02:38:38 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA21178 for ; Fri, 14 Mar 1997 02:39:26 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20794; Fri, 14 Mar 1997 10:38:37 GMT Date: Fri, 14 Mar 1997 10:38:37 GMT Message-Id: <9703141038.AA20794@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3283) priority v. flow model (was: Re: IPv6 priority field usage?) To: ipng@sunroof.eng.sun.com In-Reply-To: from "Harri Hakulinen" at Mar 14, 97 02:22:16 am Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 740 Harri, ..... > > But I still think that priorities are needed to "smooth" things and > somehow I feel that drop preference fits better to internet than > (reserved) flows altogether. > You're assuming that we stay with the present internet rather than trying to move to an Integrated Services internet. This assumption may be false. Priorities and drop preference may be a tactical requirement but may not be our long-term strategy. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 03:27:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA15178; Fri, 14 Mar 1997 03:19:15 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA15171; Fri, 14 Mar 1997 03:19:05 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA20181; Fri, 14 Mar 1997 03:19:48 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA29835 for ; Fri, 14 Mar 1997 03:20:36 -0800 Received: by mail.noris.net id <35245-20488>; Fri, 14 Mar 1997 12:19:46 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3284) Re: Proposed IPv6 Priority Field Semantics Date: 14 Mar 1997 12:19:32 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 65 Message-ID: <5gbc84$7ju$1@work.smurf.noris.de> References: <1943.858264468@cs.ucl.ac.uk> <9703131624.AA29998@vision.raleigh.ibm.com> <858280362.7812@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1540 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3162 Steven L Blake writes: > > Please consider the following proposal for the use of the IPv6 priority > field. I think that it is general enough to provide flexibility both > to the host and to the network, while providing substantial benefits to > some applications. I will write up a draft for Memphis if there is any > interest. > Interest. > Normal hosts MUST set H=0. Router network control protocol > implementations and network management stations MAY set H=1. > Edge routers (host's first hop router) SHOULD reset this bit (H=0). > That means that either Priority should be excluded from whatever the IPSEC people are including in their crypto sums, or that the router should instead send an ICMP problem back. I prefer the second alternative, actually; routers should not gratuitiously alter packet contents. > R: Reserved > Use of this bit by hosts is reserved for future study. > > D: Drop Preference > This bit, when set to one, is intended to indicate packets, belonging > to an application flow, whose loss will not critically impair the > performance of that application. One proposed use of this bit by You're implying two levels of "droppability". That doesn't seem to be enough for graceful degradation-of-service. I'd rather use two bits, or... > bit is to indicate those packets which are "in-profile" (D=0) or > "out-of-profile" (D=1) with respect to some traffic policy policing > function which has been contractually negotiated between a network > and a client (e.g., host, site, ISP). Routers MAY set D=1 for those > packets which are "out-of-profile". Routers MAY choose to exclude > those packets received with D=1 from the profile policy policing > calculation. > ... maybe better, separate these two functions. > * Routers MAY rewrite the 4-bit priority field for internal network > functions. I'd rather not. If a router needs to remember some internal state, it should associate the state with the packet without altering the packet. > "All packets belonging to the same flow must be sent with the > same source address, destination address, priority, and flow label." > > to exclude priority. Routers SHOULD NOT cache packet priority for > opportunistically cached flow-handling state. > Right. -- We are all so much together and yet we are all dying of loneliness. --A. Schweitzer -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 05:05:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA15347; Fri, 14 Mar 1997 04:57:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA15340; Fri, 14 Mar 1997 04:57:34 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA28370; Fri, 14 Mar 1997 04:58:16 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA17643 for ; Fri, 14 Mar 1997 04:59:03 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.7.3) with ESMTP id FAA21085; Fri, 14 Mar 1997 05:58:14 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id FAA07951; Fri, 14 Mar 1997 05:58:13 -0700 (MST) Message-Id: <199703141258.FAA07951@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 14 Mar 1997 05:58:13 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: fred@cisco.com (Fred Baker), "John W. Stewart III" Subject: (IPng 3285) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 947 > Let's put it this way. IPv4 precedence has been in there since the > publication of RFC 791, but was not widely implemented until quite > recently. It became implemented for two reasons: > > - an application that needed it > - customer requirements to support that application > > the applications in question are > ... There is one other use of the IPv4 priority field that has not been mentioned. The SLIP and PPP drivers in 4.4BSD stacks look at the TOS, and if it's low-delay, put the outgoing packet onto the "fast queue" instead of the normal output queue. Do other vendors that provide SLIP/PPP use this field in a similar fashion? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 06:08:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA15410; Fri, 14 Mar 1997 05:59:18 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA15403; Fri, 14 Mar 1997 05:59:09 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA05455; Fri, 14 Mar 1997 05:59:51 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA02067 for ; Fri, 14 Mar 1997 06:00:42 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA21280; Fri, 14 Mar 1997 08:59:34 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id IAA38830; Fri, 14 Mar 1997 08:59:31 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA12036; Fri, 14 Mar 1997 08:59:10 -0500 Message-Id: <9703141359.AA12036@ludwigia.raleigh.ibm.com> To: fred@cisco.com (Fred Baker) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3286) Re: IPv6 priority field usage? In-Reply-To: Your message of "Thu, 13 Mar 1997 18:11:07 PST." Date: Fri, 14 Mar 1997 08:59:10 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 900 fred@cisco.com (Fred Baker) writes: > (c) administrative weighting of traffic by ISPs and backbone providers, which > want to provide a "you pay more $$$, you get a better worst case in your > service." Are you saying that ISP border routers are rewriting the precedence bits in the IPv4 header to give better service to customers with $$$$$$ and worse service to those with just a $? If so, someone better go talk to the IPSec folks. The IPSec Authentication Header calculation includes the precedence/priority bits. If those bits get modified during transit, some customers will not be amused... Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 06:08:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA15419; Fri, 14 Mar 1997 05:59:52 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA15412; Fri, 14 Mar 1997 05:59:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA05515; Fri, 14 Mar 1997 06:00:24 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA02212 for ; Fri, 14 Mar 1997 06:01:15 -0800 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA16462; Fri, 14 Mar 1997 09:00:25 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA16474; Fri, 14 Mar 1997 09:00:24 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18962; Fri, 14 Mar 1997 09:00:01 -0500 Message-Id: <9703141400.AA18962@ludwigia.raleigh.ibm.com> To: Steven L Blake Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3287) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Thu, 13 Mar 1997 11:24:18 EST." <9703131624.AA29998@vision.raleigh.ibm.com> Date: Fri, 14 Mar 1997 09:00:01 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2386 Steven L Blake writes: > H: High Priority > Normal hosts MUST set H=0. Router network control protocol > implementations and network management stations MAY set H=1. > Edge routers (host's first hop router) SHOULD reset this bit > (H=0). One gotcha: BGP is carried in TCP packets which traverse multiple hops; such packets shouldn't get their priorities reset by routers. And if the packets are encrypted using IPSec, a router has no way of knowing which packets carry BGP traffic. > R: Reserved > One possible use of this bit by hosts is to indicate packets of a > flow for which the host has transmitted RSVP PATH messages. This > might allow optimized implementations of RSVP packet classification > within routers. Not sure I understand the above. If you are looking for a way to signal to routers that these packets should be examined and processed differently (i.e., they contain RSVP info), there is a proposed "router alert" option for this. Or if you are saying that the bit tells router "you should have RSVP-created state associated with this packet", doesn't a non-zero Flow Label the same function? > Best-effort flows: > Applications > should expect the network to take measures to restrict the aggregate > thruput of traffic with D=1, even under uncongested > conditions. Hmm... Are you saying the network *should* discard some fraction of D=1 traffic, even if it is uncongested? What purpose does this serve? As a general comment, I am not entirely comfortable with the notion that a host sets the priority bits, but that routers are free to rewrite them for their own purposes. This is likely to lead to problems when packets traverse multiple ISPs each with their own policies. If in practice each ISP resets priorities for its own purposes, the initial settings created by the originating source have no value. Even worse, applications will *think* they have value, but the network won't act on those values in ways applications expect. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 07:00:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA15532; Fri, 14 Mar 1997 06:52:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA15525; Fri, 14 Mar 1997 06:52:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA15492; Fri, 14 Mar 1997 06:53:01 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA19002 for ; Fri, 14 Mar 1997 06:53:53 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcgvr15110; Fri, 14 Mar 1997 09:52:57 -0500 (EST) Message-Id: To: Thomas Narten cc: fred@cisco.com (Fred Baker), ipng@sunroof.eng.sun.com Subject: (IPng 3288) Re: IPv6 priority field usage? In-reply-to: Your message of "Fri, 14 Mar 1997 08:59:10 -0400." <9703141359.AA12036@ludwigia.raleigh.ibm.com> Date: Fri, 14 Mar 1997 09:52:57 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2164 well, the ISP edge routers don't *have* to suppress priority information, but the first time a site gets a bill 2x what they were expecting because somebody inside the site wanted their FTP to go faster, the edge router at the site will start suppressing them. i'm finally beginning to understand the problem here. all the mechanisms are free from any notion of authorization policy. there is a "divide and conquer" inductive approach being assumed for network design, and while useful for some purposes, it fails to acknowledge, and thererfore accomodate, the operational realities of admimistrative domains and the policies they chose to execute. the induction is that if one router is a network, then a network of 2 routers is a network, and on and on. and if a mechanism will work with one router, two routers, etc, then it should work across the whole network. but that denies the existance of boundaries between organizations. just to make it clear, there are (at least) large global networks, smaller regional networks, enterprise networks, organizations within enterprises, workgroups, and individual machines. all of these may have very, very different policies governing "what should work", and if so, how, and all these issues hand on this point - they each get to say what will work and what won't, and an architecture which excessively dictates the policies they can pursue for perfectly justifiable economic reasons will fail to be adopted. Yes, there are tensions, ambiguities, and downright contradictions here. that means one of our primary responsibilities is to tease-out those issues illuminate them in as strong a light as possible, and make very very sure people understand the issues and alternatives so that they can make cost-benefit tradeoffs. to the degree they do not have alternatives, there better be a very strong story as to why. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 07:21:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15562; Fri, 14 Mar 1997 07:13:07 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15555; Fri, 14 Mar 1997 07:12:58 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA21745; Fri, 14 Mar 1997 07:13:42 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA26786 for ; Fri, 14 Mar 1997 07:14:34 -0800 Received: from rtpdce03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA29782; Fri, 14 Mar 1997 10:13:42 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id KAA56178 for ; Fri, 14 Mar 1997 10:13:42 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA12134; Fri, 14 Mar 1997 10:13:19 -0500 Message-Id: <9703141513.AA12134@ludwigia.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3289) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Thu, 13 Mar 1997 18:11:02 PST." Date: Fri, 14 Mar 1997 10:13:19 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 874 Just in case folks have forgotten, ISPs already have 4 bits in the IPv6 header they can muck with safely: the version field. As long as its value gets reset to '6' before the packet is delivered to its destination, ISPs can do with it as they like (e.g., use it for priority, identify $$ paying customers, etc.). And ISPs could make agreements with their neighbors to further extend the boundaries of who interprets the field as something other then the version field. Indeed, would it break anything at this point to simply redefine those bits "for use by routers as they see fit"? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 07:49:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15607; Fri, 14 Mar 1997 07:40:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15600; Fri, 14 Mar 1997 07:40:34 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA29438; Fri, 14 Mar 1997 07:41:19 -0800 Received: from lachman.com ([192.35.52.14]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA06605 for ; Fri, 14 Mar 1997 07:42:07 -0800 Received: from ra.lachman.com (ra.lachman.com [192.35.52.29]) by lachman.com (8.7.1/8.7.1) with SMTP id JAA07704 for ; Fri, 14 Mar 1997 09:41:14 -0600 (CST) Received: from tiny.lachman.com.i88 by ra.lachman.com (4.1/SMI-4.1) id AA13333; Fri, 14 Mar 97 09:41:13 CST Date: Fri, 14 Mar 97 09:41:13 CST Message-Id: <9703141541.AA13333@ra.lachman.com> Received: by tiny.lachman.com.i88 (4.1/SMI-4.1) id AA13304; Fri, 14 Mar 97 09:43:48 CST From: "Bradley A. Bosch" To: ipng@sunroof.eng.sun.com Subject: (IPng 3290) Re: IPv6 priority field usage? In-Reply-To: <9703101122.AA69370@hursley.ibm.com> References: <199703061147.NAA24227@kaarne.cs.tut.fi> <9703101122.AA69370@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3042 This seems to have bounced the first time.... (Another lurker opens his mouth in support of a simple priority field) Brian E. Carpenter writes: > And in any case, the sender can only improve the quality by > paying more; just setting some priority bits doesn't hack it, > since it offers no help to a pricing mechanism. If there is > no pricing mechanism, no ISP will respect priority bits. You seem to be assuming that the interior of the global Internet (with a capital I) is the only place packets might need to be prioritized. What about the very common case of corporate remote access where the only routers involved may very well all be owned by the users own company. Why should a complex resource reservation protocol be required to set up a labeled flow just to prevent a user's background file transfer from causing a 5 second latency for (perhaps the same user's) interactive (telnet, rlogin, ssh, voice) traffic? Another example is off-peak hours use of the Internet where the first and last hop links may (today) be the main bottle neck. Surely, my ISP will be willing to perform priority queuing for traffic on the links I pay for (or I can always try to find an ISP who will). I know from personal experience that even this simple capability would improve my interactive response times when I am connected to work from my home and my coworkers are using our (rather narrow) pipe from the office to the Internet for FTP or SMTP, etc. If more router vendors implemented this capability using the TOS bits in IPv4 today, I might be more productive when I work at home. Even if the routers inside the Internet choose to ignore these bits (routers shouldn't modify them in any case) for packets with no negotiated QOS, they would be useful on the end links. I can see that a policy of dropping low priority packets first inside the Internet might encourage misuse of this field, but why not give ISPs a way to identify interactive traffic? Routers which are not so short of memory that they are dropping packets might want to use the priority bits to queue interactive traffic ahead of bulk transfers (even if only in cases where no packets are being dropped). It seems to me that if the standards specify what type of traffic should be labeled in what way, the protocol and application developers will most likely play by the rules. If they won't, the core Internet routers can just ignore these bits. I understand that the global Internet is not likely to provide a guaranteed QOS without economic compensation, but I see no reason that best effort delivery can't be made more efficient and useful through careful use of a priority field. --Brad Bosch TCP/IP protocol development group, Computer Associates Int. brad@lachman.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 08:35:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15804; Fri, 14 Mar 1997 08:27:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15797; Fri, 14 Mar 1997 08:26:58 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA11368; Fri, 14 Mar 1997 08:27:43 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA25316 for ; Fri, 14 Mar 1997 08:28:12 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA03170; Fri, 14 Mar 97 08:25:38 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id IAA03188; Fri, 14 Mar 1997 08:27:40 -0800 Date: Fri, 14 Mar 1997 08:27:40 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199703141627.IAA03188@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3291) Re: Proposed IPv6 Priority Field Semantics X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1749 Thomas, > > Just in case folks have forgotten, ISPs already have 4 bits in the > IPv6 header they can muck with safely: the version field. As long as > its value gets reset to '6' before the packet is delivered to its > destination, ISPs can do with it as they like (e.g., use it for > priority, identify $$ paying customers, etc.). And ISPs could make > agreements with their neighbors to further extend the boundaries of > who interprets the field as something other then the version field. > > Indeed, would it break anything at this point to simply redefine those > bits "for use by routers as they see fit"? > Are you suggesting the elimination of the version field? This may break the header compression specification. Maybe not. In addition some implementations (ours for example) may be dependent on the version field. We could rewrite our code but I would hope that we wouldn't need to do that simply because the IPng working group can't agree on how to make appropriate use of the 28 bits which have already been set aside for priorities and flows and what not. As far as I know the IPSec authentication checksums do not include the priority or the flow label in the calculation. If I am correct about this then these bits are a blank slate which can be used end-to-end or hop-by-hop. In my opinion we have plenty of bits we just need to decide what to do with them. Adding four more bits doesn't make the decision any easier. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 08:41:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15827; Fri, 14 Mar 1997 08:32:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15810; Fri, 14 Mar 1997 08:32:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12481; Fri, 14 Mar 1997 08:33:01 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA28095 for ; Fri, 14 Mar 1997 08:33:52 -0800 Received: by mail.noris.net id <35234-24859>; Fri, 14 Mar 1997 17:32:50 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3292) Re: IPv6 priority field usage? Date: 14 Mar 1997 17:32:32 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 30 Message-ID: <5gbuj0$9g2$1@work.smurf.noris.de> References: <9703141359.AA12036@ludwigia.raleigh.ibm.com> <858352926.24223@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1551 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1940 "Mike O'Dell" writes: > well, the ISP edge routers don't *have* to suppress priority > information, but the first time a site gets a bill 2x what they > were expecting because somebody inside the site wanted their > FTP to go faster, the edge router at the site will start > suppressing them. > Why would they suppress them? I'm more in favor of kicking the FTP sender's butt, i.e. sending an ICMP message back, and/or simply ignoring the priority bits you don't like the looks of. It's very tempting to tell the router "this guy sends politically-incorrect bits here, so we'll just fix the packet and send it along". Unfortunately, it's wrong (IMHO). The sender, in setting those bits, expects something to happen when they're set. Rather than going merrily along and breaking the application (for instance, Router 1 clears the D bit of the more-important half of an audio stream, Router 2 drops random packets, and the end user gets shoddy sound without knowing what's wrong, let alone whom to kick in order to fix the problem), it's make more sense to either tell the application, i.e., send an appropriate ICMP message back, or to ignore the bits, so that at least Router 2 has a chance to do its work correctly. -- Last yeer I kudn't spel Progarmmer Now I are won. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 09:24:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15993; Fri, 14 Mar 1997 09:16:23 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15986; Fri, 14 Mar 1997 09:16:15 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA22500; Fri, 14 Mar 1997 09:16:58 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA17696 for ; Fri, 14 Mar 1997 09:17:50 -0800 Received: from spruce.ipsilon.com (dialin2.Ipsilon.COM [205.226.3.242]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA09891; Fri, 14 Mar 1997 09:15:48 -0800 Message-Id: <3.0.1.32.19970314091313.00784b9c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 14 Mar 1997 09:13:13 -0800 To: jburgan@BayNetworks.com From: Bob Hinden Subject: (IPng 3293) Request to Advance "Basic Socket Interface Extensions for IPv6" Cc: scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1044 Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-bsd-api-07.txt Pages : 40 Date : 01/30/1997 This version of the draft reflects comments received during the working group last call. It was discussed at the IPng w.g. session held at the Dec '96 IETF where the working group agreed to do a working group last call and then submit it to the IESG to be published as an Informational RFC. Bob Hinden / Steve Deering IPng Working Group Co-Chairs ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 09:57:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16048; Fri, 14 Mar 1997 09:49:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16041; Fri, 14 Mar 1997 09:49:04 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA01632; Fri, 14 Mar 1997 09:49:42 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA02062 for ; Fri, 14 Mar 1997 09:50:30 -0800 Received: from rtpdce02.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA54854; Fri, 14 Mar 1997 12:49:34 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id MAA34864; Fri, 14 Mar 1997 12:49:32 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA13100; Fri, 14 Mar 1997 12:49:12 -0500 Message-Id: <9703141749.AA13100@ludwigia.raleigh.ibm.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3295) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Fri, 14 Mar 1997 08:27:40 PST." <199703141627.IAA03188@feller.mentat.com> Date: Fri, 14 Mar 1997 12:49:12 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1683 > Are you suggesting the elimination of the version field? Well, I am at least asking why not. The original motivation for having the version field went away with the decision that link layers would have be able to identify that the packets they are transporting as being IPv6. So in theory, the version bits in the IPv6 header aren't needed anymore. I look at it as wasting 4 header bits, something that I certainly can't get excited about. So the next question is, what would break if those bits were redefined so that IPv6 stacks could no longer assume they contained a '6'? > In addition some implementations (ours for example) may be dependent on > the version field. In major ways? > We could rewrite our code but I would hope that we > wouldn't need to do that simply because the IPng working group can't agree > on how to make appropriate use of the 28 bits which have already been set > aside for priorities and flows and what not. I don't think the issue is just that the IPng WG can't agree on how to define the Flow Label or Priority bits. I think we're wasting 4 bits in the header for no good reason. That rubs me wrong. > As far as I know the IPSec authentication checksums do not include the > priority or the flow label in the calculation. RFC 1827 says only the Hop Limit is excluded. It is of course possible that we may want to add additional fields for exclusion. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 10:14:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16191; Fri, 14 Mar 1997 10:06:52 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16184; Fri, 14 Mar 1997 10:06:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA06687; Fri, 14 Mar 1997 10:07:23 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA10404 for ; Fri, 14 Mar 1997 10:08:09 -0800 Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA27692; Fri, 14 Mar 1997 13:07:01 -0500 Received: from vision.raleigh.ibm.com (vision.raleigh.ibm.com [9.37.177.224]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id NAA33250; Fri, 14 Mar 1997 13:07:02 -0500 Received: by vision.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29684; Fri, 14 Mar 1997 13:07:02 -0500 Message-Id: <9703141807.AA29684@vision.raleigh.ibm.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Harri Hakulinen Cc: ipng@sunroof.eng.sun.com Reply-To: slblake@vnet.ibm.com Subject: (IPng 3296) Re: IPv6 priority field usage? In-Reply-To: Your message of "Fri, 14 Mar 1997 03:28:40 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Mar 1997 13:07:00 EST From: Steven L Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2072 Harri Hakulinen wrote: > On Tue, 11 Mar 1997, Steven L Blake wrote: > > I am definitely in the camp which believes that a "drop-preference" bit > > is a potentially useful feature, especially for applications like two-layer > > video. > ... > > low-priority layer was only advantageous for transient bursts due to frame > > changes, that the average ratio of low-priority to high-priority traffic > > for a video application was less than 0.5, and that multiple levels of > > priority were not advantageous, so I wouldn't argue for more than one > > drop-preference bit. > > I think that only one drop-preference bit is maybe not futureproof > solution. It might be that in the future we need more "guided > intelligence" in the network than we can predict now. There has not been One bit only gives limited granularity. But the whole concept of drop preference for best-effort traffic is IMHO only useful in the event of transient congestion, where you are trying to lower the delay/loss probability of some of your other packets. As has already been argued by others, under sustained congestion, you want the sources to back off. It's not clear where the cost/benefit analysis of multiple levels of drop preference (for best-effort without per-source/flow policing) would fall out. For fine-grain QoS control, you really need admission control, and preferably, explicit flow classification/policing/scheduling setup. RSVP/IntServ provides this. Regards, /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Steven L. Blake slblake@vnet.ibm.com | | Internetworking Technology (919)254-2030 (work) | | IBM Networking Division (919)254-5483 (fax) | | "You like the 'Net? You ain't seen nothin' yet!" | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 10:33:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16220; Fri, 14 Mar 1997 10:25:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16211; Fri, 14 Mar 1997 10:24:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA12823; Fri, 14 Mar 1997 10:25:34 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA19474 for ; Fri, 14 Mar 1997 10:26:26 -0800 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA03903; Fri, 14 Mar 97 10:25:33 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA03510; Fri, 14 Mar 1997 10:25:58 -0800 Date: Fri, 14 Mar 1997 10:25:58 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199703141825.KAA03510@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3297) Re: Proposed IPv6 Priority Field Semantics X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2423 Thomas, > > > In addition some implementations (ours for example) may be dependent on > > the version field. > > In major ways? > No. Actually, given what I think you are proposing as a use for the version bits, the change would be sub-trivial I think. The word "rewrite" below was... let us say an exaggeration.:-) Of course I can't speak for other people's implementations. > > We could rewrite our code but I would hope that we > > wouldn't need to do that simply because the IPng working group can't agree > > on how to make appropriate use of the 28 bits which have already been set > > aside for priorities and flows and what not. > > I don't think the issue is just that the IPng WG can't agree on how to > define the Flow Label or Priority bits. I think we're wasting 4 bits > in the header for no good reason. That rubs me wrong. > I agree that bit wasting is bad. I just don't want to see us scrounging the rest of the header for bits when we seem to have plenty of bits which we can't decide how to use. If it turns out that we need these bits to implement the type of opaque router tag you are proposing I would have no objection since an implementation would be free to overwrite the bits as needed. At this point I doubt very much that we need to scrounge these bits. > > As far as I know the IPSec authentication checksums do not include the > > priority or the flow label in the calculation. > > RFC 1827 says only the Hop Limit is excluded. It is of course possible > that we may want to add additional fields for exclusion. > I was fairly certain that I heard Ran Atkinson state at the last IPSec session I attended that some later, possibly not yet complete, version of the IPSec documents had removed all of the priority and flow bits from the AH computation. I believe this change was prompted by some vendors who were thinking about using the flow label on a hop-by-hop basis. I certainly could be wrong about this. To implement the scheme you have proposed we certainly would need to exclude more bits from the computation since the existing computation includes the version field. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 12:22:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA16439; Fri, 14 Mar 1997 12:14:04 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA16432; Fri, 14 Mar 1997 12:13:49 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA12473; Fri, 14 Mar 1997 12:14:31 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA05983 for ; Fri, 14 Mar 1997 12:15:21 -0800 Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA48988; Fri, 14 Mar 1997 15:14:24 -0500 Received: from vision.raleigh.ibm.com (vision.raleigh.ibm.com [9.37.177.224]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA33164; Fri, 14 Mar 1997 15:14:26 -0500 Received: by vision.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29388; Fri, 14 Mar 1997 15:10:40 -0500 Message-Id: <9703142010.AA29388@vision.raleigh.ibm.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Reply-To: slblake@vnet.ibm.com Subject: (IPng 3298) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Fri, 14 Mar 1997 09:00:01 EST." <9703141400.AA18962@ludwigia.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Mar 1997 15:10:38 EST From: Steven L Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3932 Thomas Narten wrote: > Steven L Blake writes: > > > H: High Priority > > > Normal hosts MUST set H=0. Router network control protocol > > implementations and network management stations MAY set H=1. > > Edge routers (host's first hop router) SHOULD reset this bit > > (H=0). > > One gotcha: BGP is carried in TCP packets which traverse multiple > hops; such packets shouldn't get their priorities reset by > routers. And if the packets are encrypted using IPSec, a router has no > way of knowing which packets carry BGP traffic. I think that, if the routers are re-using the H bit for their own purposes, and if they want to prioritize BGP traffic, then they had better know how to classify them. The notion that routers should be able to re-use the priority field is right there in the San Jose minutes. > > R: Reserved > > > One possible use of this bit by hosts is to indicate packets of a > > flow for which the host has transmitted RSVP PATH messages. This > > might allow optimized implementations of RSVP packet classification > > within routers. > > Not sure I understand the above. If you are looking for a way to > signal to routers that these packets should be examined and processed > differently (i.e., they contain RSVP info), there is a proposed > "router alert" option for this. Or if you are saying that the bit > tells router "you should have RSVP-created state associated with this > packet", doesn't a non-zero Flow Label the same function? Router Alert is currently only used for RSVP signaling packets (e.g., PATH messages). The proposed use of the R bit was to indicate "hey, you might want to classify this packet". Looking for non-zero flow labels would also work, although best-effort flows will also use non-zero flow labels. > > Best-effort flows: > > > Applications > > should expect the network to take measures to restrict the aggregate > > thruput of traffic with D=1, even under uncongested > > conditions. > > Hmm... Are you saying the network *should* discard some fraction of D=1 > traffic, even if it is uncongested? What purpose does this serve? There is an argument (which I haven't seen fully explicated on the list) which states that generalized drop preference encourages bad behavior by sources. Assuming that that is the case, then you want the drop preference service to be lossy or low throughput under all circumstances. > As a general comment, I am not entirely comfortable with the notion > that a host sets the priority bits, but that routers are free to > rewrite them for their own purposes. This is likely to lead to > problems when packets traverse multiple ISPs each with their own > policies. If in practice each ISP resets priorities for its own > purposes, the initial settings created by the originating source have > no value. Even worse, applications will *think* they have value, but > the network won't act on those values in ways applications expect. I would prefer it if we could carve out however n bits we need for the host to specify its service/priority request, and then reserve the rest to the network (or better yet, specify the use of the network bits also). Four bits is scarce, though. Regards, /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Steven L. Blake slblake@vnet.ibm.com | | Internetworking Technology (919)254-2030 (work) | | IBM Networking Division (919)254-5483 (fax) | | "You like the 'Net? You ain't seen nothin' yet!" | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 13:06:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA16505; Fri, 14 Mar 1997 12:57:36 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA16498; Fri, 14 Mar 1997 12:57:25 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA22090; Fri, 14 Mar 1997 12:58:08 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA22460 for ; Fri, 14 Mar 1997 12:59:03 -0800 Received: from rtpdce03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA62534; Fri, 14 Mar 1997 15:57:06 -0500 Received: from vision.raleigh.ibm.com (vision.raleigh.ibm.com [9.37.177.224]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA56120; Fri, 14 Mar 1997 15:57:07 -0500 Received: by vision.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29522; Fri, 14 Mar 1997 15:57:06 -0500 Message-Id: <9703142057.AA29522@vision.raleigh.ibm.com> X-Mailer: exmh version 1.6.9 8/22/96 To: fred@cisco.com (Fred Baker) Cc: ipng@sunroof.eng.sun.com Reply-To: slblake@vnet.ibm.com Subject: (IPng 3299) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Thu, 13 Mar 1997 18:11:02 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Mar 1997 15:57:02 EST From: Steven L Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3981 Fred Baker wrote: > At 11:24 AM 3/13/97, Steven L Blake wrote: > > D: Drop Preference > > > > This bit, when set to one, is intended to indicate packets, belonging > > to an application flow, whose loss will not critically impair the > > performance of that application. One proposed use of this bit by > > hosts is to indicate packets belonging to an enhancement-layer sub- > > flow of a multi-layer multimedia flow. An alternative use is to > > indicate packets within an Integrated Services flow which have > > failed a policing function at an upstream node. > > I would suggest that priority is in fact a drop preference. If I am sending > a stream and labelling some packets with a higher priority than others, and > the network is being forced to drop something, it will drop the lower > priority traffic first. A drop preference bit allows you to specify two levels of loss priority. I think that people usually associate the general term "priority" with the notion of scheduling priority, where "high-priority" packets are scheduled before "low-priority" packets. > > I: Interactive > > > > This bit, when set to one, is intended to indicate packets belonging > > to an application flow which is sensitive to queueing delay but which > > does not have high thruput requirements (e.g., telnet). Applications > > should expect the network to take measures to restrict the aggregate > > thruput of traffic with I=1. > > This is really not a good idea. Interactivity is an attribute of the > traffic more than an attribute of the application. For example, if I am > running telnet or X Windows and I decide to display a file on the screen, > at that moment the application is acting as a file transfer, not an > exchoplx interaction. A classic example is what X does with mouse movements > - imagine a long stream of small TCP segments that say "the mouse moved, > the mouse moved." > > The way you want to deal with this attribute is to run a WFQ or etc, and > let traffic which has low queue occupancy garner the benefits of the > queuing algorithm, and force traffic with higher queue occupancy to share > the available resource nicely. That you have to do on a flow basis, not a > traffic attribute basis. This is a more expensive solution than scheduling the aggregate of all "interactive" traffic. Of course, the aggregate scheduling solution has potential fairness problems, which is why I think there needs to be a feedback mechanism (e.g. thruput control), so that the host is careful about which traffic it requests "interactive service" for. In my mind, there is best-effort service, which is FIFO scheduling and has associated with it a delay-distribution curve with a long tail, but with typically low loss, and then there is IntServ, where there is flow setup, admission control, and the network can tightly control the delay-distribution curve and the loss probability. In between there can be various levels of service priority which can be provided for applications which don't want to go to the expense of flow setup. If these priority mechanisms aren't cheap enough to implement, and if they don't preserve the general notion of fairness between flows, then they won't be useful, and everyone who needs service better than best-effort will wind up using RSVP/IntServ. /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Steven L. Blake slblake@vnet.ibm.com | | Internetworking Technology (919)254-2030 (work) | | IBM Networking Division (919)254-5483 (fax) | | "You like the 'Net? You ain't seen nothin' yet!" | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 17:09:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA17191; Fri, 14 Mar 1997 17:01:14 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA17184; Fri, 14 Mar 1997 17:01:10 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10953; Fri, 14 Mar 1997 17:01:56 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10237; Fri, 14 Mar 1997 17:01:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA17051; Fri, 14 Mar 1997 16:30:44 -0800 From: ocrds@iitk.ernet.in Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA14580; Fri, 14 Mar 1997 16:31:27 -0800 Received: from milan.doe.ernet.in ([202.41.99.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA22405 for ; Fri, 14 Mar 1997 16:32:12 -0800 Received: from iitk.ernet.in (eesun.iitk.ernet.in) by milan.doe.ernet.in (4.1/SMI-4.1) id AA11483; Fri, 14 Mar 97 23:50:22+050 Received: by iitk.ernet.in (Smail3.1.29.1 #1) id m0w5gzR-0009uGC; Sat, 15 Mar 97 05:36 GMT+5:30 Received: from cse.iitk.ernet.in by yamuna.iitk.ernet.in (8.7.5/8.7.3) with SMTP id FAA24536; Sat, 15 Mar 1997 05:26:16 +0530 (IST(+5:30)) Received: from csealpha2 by cse.iitk.ernet.in (4.0/SMI-4.0) id AA08269; Sat, 15 Mar 97 05:32:52 IST Received: by csealpha2; (5.65/1.1.8.2/25Jul95-0312PM) id AA28126; Sat, 15 Mar 1997 05:29:40 +0530 Message-Id: <9703142359.AA28126@csealpha2> Subject: (IPng 3301) FYI: draft-sanghi-pmtudisc-ext-00.txt To: ipng@sunroof.eng.sun.com Date: Sat, 15 Mar 97 5:29:38 IST X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 938 A new Internet-Draft draft-sanghi-pmtudisc-ext-00.txt is available from the on-line Internet-Drafts directories. This draft discusses extensions to the present Path MTU Discovery mechanism. It provides applications finer control over the delay and losses incurred during the PMTU Discovery process. The document proposes two extension header options that allow PMTU Discovery with minimal overheads. The two extension header options provide a pmtu probe mechanism similar to that proposed for IPv4. We believe this can be useful if adopted before significant deployment of IPv6 routers. We would appreciate any comments and suggestions. Sameer ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 18:40:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA17375; Fri, 14 Mar 1997 18:32:39 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA17368; Fri, 14 Mar 1997 18:32:32 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA06303; Fri, 14 Mar 1997 18:33:15 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA01400 for ; Fri, 14 Mar 1997 18:34:14 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id VAA01787; Fri, 14 Mar 1997 21:28:02 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA29116; Fri, 14 Mar 1997 21:28:01 -0500 Message-Id: <9703150228.AA29116@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 3302) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Fri, 14 Mar 97 10:25:58 PST." <199703141825.KAA03510@feller.mentat.com> Date: Fri, 14 Mar 97 21:28:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 409 Really irritates me greatly when people who don't write code for a living keep alluding to a change as not a big deal. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 14 23:53:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA17651; Fri, 14 Mar 1997 23:45:27 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA17644; Fri, 14 Mar 1997 23:45:19 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA06918; Fri, 14 Mar 1997 23:46:02 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA15758 for ; Fri, 14 Mar 1997 23:47:04 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id XAA24461; Fri, 14 Mar 1997 23:45:59 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id XAA02363; Fri, 14 Mar 1997 23:45:56 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Mar 1997 23:46:00 -0800 To: "W. Richard Stevens" From: fred@cisco.com (Fred Baker) Subject: (IPng 3303) Re: IPv6 priority field usage? Cc: "John W. Stewart III" , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 861 At 5:58 AM 3/14/97, W. Richard Stevens wrote: >The SLIP and PPP drivers in 4.4BSD stacks look at the >TOS, and if it's low-delay, put the outgoing packet onto the "fast >queue" instead of the normal output queue. Do other vendors that >provide SLIP/PPP use this field in a similar fashion? hmm. while I understand why they do this, I'd suggest the use of precedence to achieve the same thing. Then the network will do it as wel. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sat Mar 15 10:15:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18118; Sat, 15 Mar 1997 10:06:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18111; Sat, 15 Mar 1997 10:06:25 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA26961; Sat, 15 Mar 1997 10:07:09 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA15641 for ; Sat, 15 Mar 1997 10:08:17 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id KAA29565; Sat, 15 Mar 1997 10:07:10 -0800 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id KAA02442; Sat, 15 Mar 1997 10:07:08 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Mar 1997 10:07:10 -0800 To: slblake@vnet.ibm.com From: fred@cisco.com (Fred Baker) Subject: (IPng 3304) Re: Proposed IPv6 Priority Field Semantics Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4158 At 3:57 PM 3/14/97, Steven L Blake wrote: >> I would suggest that priority is in fact a drop preference. If I am sending >> a stream and labelling some packets with a higher priority than others, and >> the network is being forced to drop something, it will drop the lower >> priority traffic first. > >A drop preference bit allows you to specify two levels of loss priority. >I think that people usually associate the general term "priority" with >the notion of scheduling priority, where "high-priority" packets are >scheduled before "low-priority" packets. Well, "priority" involves several components, one of which is probability of arrival, and one of which is probability of timely arrival. Yes, of course I am familiar with priority queuing techniques such as are described in RFC 791; I am also intimately familiar with how they behave in real networks, and with other queuing algorithms (class based queuing, weighted fair queuing, etc.) which behave in a far superior manner. What I'm getting at is that loss priority is not cleanly separable from probability of timely delivery - those link layer networking services that implement loss priority (Frame Relay, ATM, etc.) implement it as a way to implement delivery priority - they will drop one in favor of delivering the service to the other. And I'm am also specifically pointing out that increased priority should mean "increased probability of timely delivery," not "implement priority queuing." The latter would be most unfortunate, as it has a bug - people will always use the highest priority available to them, and traffic at one priority or a set of priorities is capable of locking out or severely diminishing traffic at a lower priority. I'll tell you some war stories over a beer if you like. >In my mind, there is best-effort service, which is FIFO scheduling >and has associated with it a delay-distribution curve with a long tail, >but with typically low loss, and then there is IntServ, where there is >flow setup, admission control, and the network can tightly control the >delay-distribution curve and the loss probability. In between there >can be various levels of service priority which can be provided for >applications which don't want to go to the expense of flow setup. If >these priority mechanisms aren't cheap enough to implement, and if >they don't preserve the general notion of fairness between flows, then >they won't be useful, and everyone who needs service better than >best-effort will wind up using RSVP/IntServ. I'm familiar with that argument, that best effort implies FIFO. I have to tell you that in many networks, folks want a good deal more than that - they want to distribute use of a line to those who pay for it in proportion to how much they pay (class based queuing), deliver predictable service to all best effort traffic (WFQ), etc. In what it is now fashionable to call the "intranet", these services have been absolutely necessary features for a router to even be considered for purchase for quite a long time, and they are becoming an issue in the internet backbone. Making a proprietary note here, Cisco has a WFQ implementation that applies to best effort traffic, not just integrated services traffic. We deliver improved probability of timely delivery to all telnet traffic crossing such a link, and we do so because the traffic has low queue occupancy, not because the traffic is marked in some way (we don't say "ooh, telnet, give it a good weight") or because there has been a flow setup. Each flow simply gets its own sub-queue (stochastically; it's a hashed set of queues), and the nature of the algorithm delivers the rest. This product has been deployed over a year and is becoming widely used. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 03:57:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA00475; Mon, 17 Mar 1997 03:49:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA00468; Mon, 17 Mar 1997 03:49:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA02319; Mon, 17 Mar 1997 03:50:23 -0800 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA27514 for ; Mon, 17 Mar 1997 03:51:54 -0800 Received: from kaarne.cs.tut.fi (petkos@kaarne.cs.tut.fi [130.230.3.2]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id NAA03853; Mon, 17 Mar 1997 13:50:20 +0200 (EET) From: Koskelainen Petri Received: (from petkos@localhost) by kaarne.cs.tut.fi (8.8.5/8.8.4) id NAA01333; Mon, 17 Mar 1997 13:50:19 +0200 (EET) Message-Id: <199703171150.NAA01333@kaarne.cs.tut.fi> Subject: (IPng 3305) Re: Proposed IPv6 Priority Field Semantics To: fred@stilton.cisco.com Date: Mon, 17 Mar 1997 13:50:19 +0200 (EET) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1964 Fred: >I would suggest that priority is in fact a drop preference. If I am sending >a stream and labelling some packets with a higher priority than others, and >the network is being forced to drop something, it will drop the lower >priority traffic first. ok, you mean that priority bit is comparable among one flow only. That's exactly what I've suggested. (well, perhaps two bits for this purpose if possible) >At 10:41 AM 3/11/97, John W. Stewart III wrote: >>are people assuming routers' ability to make the priority bits fred: >Note that all of the above are selecting among traffic overall, not traffic >as originated by a source. The point is not that a particular source wants >better service for some of its traffic than for others, the point is that >certain applications require a certain class of service from the network, >or that there are administrative reasons to sort traffic use. > >Making IPv6 precedence somehow associate with the source address doesn't >map to the ambient application requirements. hmm..Isn't this just the opposite view ? As far I see, you have two opposite comments about IPv6 priority (or let's say drop-prefedence) field. Can you clarify which one you meant ? 1: IPv6 priority is associated with source address (one flow) and it has meaning only in one sender's flow 2: IPv6 priority is comparable among router traffic in general, not just among one sender's flow I'd like also to hear router vendors view about the router complexity to provide choice 1. Is it possible to implement with tolerable costs in performance ? (with state-of-the-art int-serv routers) Petri ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 04:05:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA00484; Mon, 17 Mar 1997 03:56:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA00477; Mon, 17 Mar 1997 03:55:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA02685; Mon, 17 Mar 1997 03:56:35 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA28633 for ; Mon, 17 Mar 1997 03:58:06 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA76981; Mon, 17 Mar 1997 11:56:34 GMT Date: Mon, 17 Mar 1997 11:56:34 GMT Message-Id: <9703171156.AA76981@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3306) Re: Proposed IPv6 Priority Field Semantics To: ipng@sunroof.eng.sun.com In-Reply-To: <9703141749.AA13100@ludwigia.raleigh.ibm.com> from "Thomas Narten" at Mar 14, 97 12:49:12 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1303 Thomas, > > Are you suggesting the elimination of the version field? > > Well, I am at least asking why not. The original motivation for having > the version field went away with the decision that link layers would > have be able to identify that the packets they are transporting as > being IPv6. Do the current specs say that all link layers MUST provide a separate code point for IPv6? .... > So the next question is, what would break if those bits were redefined > so that IPv6 stacks could no longer assume they contained a '6'? More precisely, don't you mean "IP stacks"? Once you're in IPv6-specific code, you can't possibly care what's in the version # field. So we have two questions: 1. Do we mandate that all link layers MUST provide an IPng code point? 2. If yes, do some implementors need the version # field to demultiplex within their IP stacks? Brian Carpenter (Just to clear our minds: if we get rid of the version # field there is no remaining reason to call this thing IPv6.) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 04:15:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA00606; Mon, 17 Mar 1997 04:07:11 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA00599; Mon, 17 Mar 1997 04:06:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA03248; Mon, 17 Mar 1997 04:07:40 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA00413 for ; Mon, 17 Mar 1997 04:09:10 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17483; Mon, 17 Mar 1997 12:07:36 GMT Date: Mon, 17 Mar 1997 12:07:36 GMT Message-Id: <9703171207.AA17483@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3307) Re: IPv6 priority field usage? To: ipng@sunroof.eng.sun.com In-Reply-To: <9703141541.AA13333@ra.lachman.com> from "Bradley A. Bosch" at Mar 14, 97 09:41:13 am Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3880 Bradley, Large corporate networks are not so different from the public Internet, with multiple cost centres competing for scarce bandwidth. Your argumemt may apply in small networks (I mean with just a few hundred people competing for the resources). But even so I have my doubts; I haven't seen many queuing systems that perform much better just by adding a simple priority scheme. Brian Carpenter >- Bradley A. Bosch said: > > This seems to have bounced the first time.... > > (Another lurker opens his mouth in support of a simple priority field) > > Brian E. Carpenter writes: > > And in any case, the sender can only improve the quality by > > paying more; just setting some priority bits doesn't hack it, > > since it offers no help to a pricing mechanism. If there is > > no pricing mechanism, no ISP will respect priority bits. > > You seem to be assuming that the interior of the global Internet (with > a capital I) is the only place packets might need to be prioritized. > What about the very common case of corporate remote access where the > only routers involved may very well all be owned by the users own > company. Why should a complex resource reservation protocol be > required to set up a labeled flow just to prevent a user's background > file transfer from causing a 5 second latency for (perhaps the same > user's) interactive (telnet, rlogin, ssh, voice) traffic? > > Another example is off-peak hours use of the Internet where the first > and last hop links may (today) be the main bottle neck. Surely, my ISP > will be willing to perform priority queuing for traffic on the links I > pay for (or I can always try to find an ISP who will). I know from > personal experience that even this simple capability would improve my > interactive response times when I am connected to work from my home > and my coworkers are using our (rather narrow) pipe from the office to > the Internet for FTP or SMTP, etc. If more router vendors implemented > this capability using the TOS bits in IPv4 today, I might be more > productive when I work at home. > > Even if the routers inside the Internet choose to ignore these bits > (routers shouldn't modify them in any case) for packets with no > negotiated QOS, they would be useful on the end links. I can see that > a policy of dropping low priority packets first inside the Internet > might encourage misuse of this field, but why not give ISPs a way to > identify interactive traffic? Routers which are not so short of > memory that they are dropping packets might want to use the priority > bits to queue interactive traffic ahead of bulk transfers (even if > only in cases where no packets are being dropped). It seems to me > that if the standards specify what type of traffic should be labeled > in what way, the protocol and application developers will most likely > play by the rules. If they won't, the core Internet routers can just > ignore these bits. > > I understand that the global Internet is not likely to provide a > guaranteed QOS without economic compensation, but I see no reason that > best effort delivery can't be made more efficient and useful through > careful use of a priority field. > > --Brad Bosch > TCP/IP protocol development group, Computer Associates Int. > brad@lachman.com > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 07:53:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00377; Mon, 17 Mar 1997 07:45:52 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00370; Mon, 17 Mar 1997 07:45:43 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA05712; Mon, 17 Mar 1997 07:46:31 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA03938 for ; Mon, 17 Mar 1997 07:48:02 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA14028; Mon, 17 Mar 1997 10:36:00 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16451; Mon, 17 Mar 1997 10:35:52 -0500 Message-Id: <9703171535.AA16451@wasted.zk3.dec.com> To: brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3308) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Mon, 17 Mar 97 11:56:34 GMT." <9703171156.AA76981@hursley.ibm.com> Date: Mon, 17 Mar 97 10:35:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3912 Brian, >Do the current specs say that all link layers MUST provide a >separate code point for IPv6? No. >.... >> So the next question is, what would break if those bits were redefined >> so that IPv6 stacks could no longer assume they contained a '6'? > >More precisely, don't you mean "IP stacks"? Once you're in IPv6-specific >code, you can't possibly care what's in the version # field. >So we have two questions: > >1. Do we mandate that all link layers MUST provide an IPng code point? I don't think the IETF should mandate anything about code points. Next they will mandate how I build my NUD cache which we specifically made sure was stated as conceptual in RFC 1970 which was a good idea as its not the most efficient way to build NUD as suggested in RFC 1970. >2. If yes, do some implementors need the version # field to demultiplex > within their IP stacks? I think a bigger issue is at play here in general about IPv6. Its the issue of changing code base now for implementors. I "personally" believe changes that will make IPv6 more robust are in fact a good idea at this point until we reach Draft Standard status, as long as they are within the guidelines of RFC 1752 and the norm to not break the base Internet architecture. But, I think with our wide and very complete multi-implemenetation set of IPv6 platforms today not listening to the affect to "running-code" changes is not smart or with good vision on the part of the IPng WG. Any implementation should be able to demultiplex on the link-layer type for IPv6. But there is an optimization for transition in the network layer when IPv6 packets are encapsulated within IPv4 packets. Instead of keeping state about protocol ID 41 the packet can be decapsulated and sent directly to ip_???? (I will avoid bsdisms here) routine where the decision is made to use IPv4 or IPv6. This permits code reusability at the ip_???? routine so that state and a jump (e.g. goto, fun(x), LA/EXEC R1) to the IPv6 parse routine at the network layer is not needed. But if we get thru the discussion on the priority bits and they can be used for that and there is consensus then it might be worth it to do the check on protocol ID 41 and the jump for encapsulated IPv6 packets. I also have to check but network sniffers and utilities like tcpdump and BF-packet filter may need changes too. I will look at tcpdump code today and get back to you. I don't know off the top of my head. We have to look at all the ramifications of not using a version number and if it will cause more cost or delay for IPv6. Another point is that the IPv6 discussions depend a lot on where you are coming from as a WG member. If you believe IPv6 is needed very soon then decisions are made with the engineering part of the brain which means trade-offs for time-to-deliver or market. If you make it with the "compture science" part of your brain then you can just do whatever is needed for the next 10 years to get it 100% correct. And there is the middle of the above two options. IPv6. My last point is in my opinion some will support anything if it slows down IPv6 regardless if its a good idea or not. I watch for these evil-doers in all these discussions. If person types of this nature support anything I immediately become suspect. And no I won't tell anyone who I think they are as its pure speculation on my part. >(Just to clear our minds: if we get rid of the version # field there is >no remaining reason to call this thing IPv6.) I think so. It is IPv6 abstractly too. Or we go back to the debate if we call it IPng. But it ain't IPv4. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 08:28:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00606; Mon, 17 Mar 1997 08:21:00 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00599; Mon, 17 Mar 1997 08:20:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA13068; Mon, 17 Mar 1997 08:21:37 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA17833 for ; Mon, 17 Mar 1997 08:23:09 -0800 Received: from gungnir.fnal.gov ("port 38126"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGLTC9VKIU000J11@FNAL.FNAL.GOV>; Mon, 17 Mar 1997 10:21:27 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA26578; Mon, 17 Mar 1997 10:21:27 -0600 Date: Mon, 17 Mar 1997 10:21:26 -0600 From: Matt Crawford Subject: (IPng 3309) Re: Proposed IPv6 Priority Field Semantics In-reply-to: "17 Mar 1997 10:35:51 EST." <"9703171535.AA16451"@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Message-id: <199703171621.KAA26578@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ But there is an optimization for transition in the network layer when > IPv6 packets are encapsulated within IPv4 packets. Instead of keeping > state about protocol ID 41 the packet can be decapsulated and sent > directly to ip_???? (I will avoid bsdisms here) routine where the decision > is made to use IPv4 or IPv6. Actually, proto 41 in IPv6-in-IP. IPv4-in-IP is proto 4. This is another place where the two already have separate code points. IMHO, alloting a separate ethertype for IPv6 was one of the most impure things the IPNGWG did. And there's (at least) one possibility which hasn't been mentioned yet. If someone wants some header bits to play with in an private way, they can go outside of the IP header entirely and extend their encapsulation on their links. This is already going on under names like "tag switching" and "VLAN tagging." _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 08:40:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00647; Mon, 17 Mar 1997 08:31:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00640; Mon, 17 Mar 1997 08:31:30 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15149; Mon, 17 Mar 1997 08:32:16 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA22526 for ; Mon, 17 Mar 1997 08:33:46 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA07042; Mon, 17 Mar 1997 11:32:06 -0500 Date: Mon, 17 Mar 1997 11:32:06 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703171132.ZM7040@seawind.bellcore.com> In-Reply-To: "(Brian E Carpenter)" "(IPng 3306) Re: Proposed IPv6 Priority Field Semantics" (Mar 17, 11:56am) References: <9703171156.AA76981@hursley.ibm.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 3310) Re: Proposed IPv6 Priority Field Semantics Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 987 On Mar 17, 11:56am, (Brian E Carpenter) wrote: > Subject: (IPng 3306) Re: Proposed IPv6 Priority Field Semantics > Thomas, > > > > Are you suggesting the elimination of the version field? > > > > Well, I am at least asking why not. The original motivation for having > > the version field went away with the decision that link layers would > > have be able to identify that the packets they are transporting as > > being IPv6. > > Do the current specs say that all link layers MUST provide a > separate code point for IPv6? The version field is also used by the Header Compression protocol. If you have to steal bits, the flow-id is a much better target. Who uses flows, anyway? -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 09:40:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00772; Mon, 17 Mar 1997 09:32:19 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00765; Mon, 17 Mar 1997 09:32:09 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA04162; Mon, 17 Mar 1997 09:32:55 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA21531 for ; Mon, 17 Mar 1997 09:34:19 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA22448; Mon, 17 Mar 1997 12:16:33 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27481; Mon, 17 Mar 1997 12:16:27 -0500 Message-Id: <9703171716.AA27481@wasted.zk3.dec.com> To: huitema@bellcore.com (Christian Huitema) Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 3311) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Mon, 17 Mar 97 11:32:06 EST." <9703171132.ZM7040@seawind.bellcore.com> Date: Mon, 17 Mar 97 12:16:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 790 >The version field is also used by the Header Compression protocol. If you >have to steal bits, the flow-id is a much better target. Who uses flows, >anyway? You jest correct? the 23 bits we have are precious in the architecture. Do you not believe end-to-end flows are important? Do you not see the advantage of the flow label in a port of RSVP to IPv6 for both the socket address struct and its inherent field in the header. It also will have value for IP switching for IPv6 like with IFMP. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 10:33:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA00870; Mon, 17 Mar 1997 10:21:49 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA00863; Mon, 17 Mar 1997 10:21:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA19735; Mon, 17 Mar 1997 10:22:24 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA15427 for ; Mon, 17 Mar 1997 10:23:53 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id NAA07079; Mon, 17 Mar 1997 13:19:36 -0500 Date: Mon, 17 Mar 1997 13:19:36 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703171319.ZM7077@seawind.bellcore.com> In-Reply-To: bound@zk3.dec.com "Re: (IPng 3310) Re: Proposed IPv6 Priority Field Semantics" (Mar 17, 12:16pm) References: <9703171716.AA27481@wasted.zk3.dec.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: bound@zk3.dec.com, huitema@bellcore.com (Christian Huitema) Subject: (IPng 3312) Re: Proposed IPv6 Priority Field Semantics Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1309 Jim, My statement on flows was indeed partly tongue in cheek. However, I have yet to see a justification on why the flow-id should be 24 bit rather than 16 or 32. The proposed usages are vague, and could use some experimentation or definition. For example, you quote both RSVP and label switching as possible usages, but these two are contradictory -- RSVP requires end to end labels, label switching probably requires labels to be rewritten when you pass network boundaries... Then, in the case of RSVP, I know how we can use the flow-ids. Pass them in the PATH messages, use them in the RSVP. Fine. But do we really need more than 64K flows per source ? On the whole, I have a lot of sympathy for the implementation concerns. My personnal take would be to stay within the 4 bits which we have allocated, and to define their usage. In particular, if these bits can be rewritten by intermediate routers, which I think should be allowed, we have to study the impact on the whole chain (IPSEC). -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 12:44:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01082; Mon, 17 Mar 1997 12:35:45 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01075; Mon, 17 Mar 1997 12:35:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA14116; Mon, 17 Mar 1997 12:36:22 -0800 Received: from digi-data.com (odin.digi-data.com [196.32.33.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA13699 for ; Mon, 17 Mar 1997 12:37:49 -0800 Received: by odin.digi-data.com id <19609>; Mon, 17 Mar 1997 16:35:16 -0400 Date: Mon, 17 Mar 1997 20:37:23 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi Data Systems, Limited X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: mo@uu.net Subject: (IPng 3313) Questions on "GSE an Alternate Addressing Architecture for IPv6" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <97Mar17.163516gmt-0400.19609@odin.digi-data.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2905 Dear Mr. O' Dell, I am reading your Internet draft on GSE entitled , "GSE an Alternate Addressing Architecture for IPv6". Specifically I am writing to clear up my understanding on article 10.2 entitled, "RG for Destination Addresses", on page 15 of your document. Please advise me if I misunderstand anything. By what I understand, we have, AAA Record ::= 8-Byte ESD + ~2-Byte STP = (STP, ESD) RG Record ::= 6-byte Routing Goop = RG Which therefore would give, AAAA Record ::= (RG, AAA) = (RG, STP, ESD). All this is by paragraph 2 of that article. In addition you propose to carry an item called an RG name with an AAA record such that the AAA record is extended thus: AAA Record ::= (RGN, STP, ESD) or (RGN, ZONEINFO) Where ZONEINFO ::= (STP, ESD) and for a typical AAA record the ZONEINFO remains constant while the (RGN, RG) mapping changes whenever the destination site rehomes and as long as there is no change to the internal routing info for the destination site. From the above I have a few questions. Q: Since RGN is to be a full DNS name, does it tend to defeat the dynamic nature of the Routing Goop structuring if it remains constant for a site? Q: Where do I get the data that assigns RGN to a given AAA record ? Q: Could a change in RGN or the (RGN, RG) mapping possibly allow a leakage of information which allows the violation of the basic scheme (assumption) of "Flat Routedness" within a Large System, from the point of view of a higher level or another Large System, in some uncontrollable manner? Does this have any security implications I should worry about? Q: Paragraph 5 of article 10.2 "RG for Destination Addresses" specifies an alternative approach wherby an RG could be delegated to a site border router which would supply the correct RG automatically. There is some ambiguity here. Does it mean a Site Border Router at the destination site or a Site Border Router at the source site? If it is a Site Border Router at the source site, how does this router learn the correct RG? If it is a Site Border Router at the destination site, How does a query arrive? Q: Could the information about the sender's own RG prefix be sent via its Site Border Router's and other routers' Router Advertisement messages together with any other site local info? Does this allow a simplification of the DNS server implementation? -- Yours sincerely, Robert Honore robert@digi-data.com Phone: 623 6658 Fax: 623 0978 Snail Mail: Digi Data systems limited, 96 Wrightson Road, Trinidad, W. I. > I just hope I ain't talkin' nonsense. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 18:50:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01972; Mon, 17 Mar 1997 18:32:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01936; Mon, 17 Mar 1997 18:31:50 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA27630; Mon, 17 Mar 1997 18:32:36 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA28183 for ; Mon, 17 Mar 1997 18:34:17 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id SAA03485; Mon, 17 Mar 1997 18:32:37 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id SAA02780; Mon, 17 Mar 1997 18:32:35 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: References: <9703120023.AA26956@vision.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 1997 11:59:16 -0800 To: Harri Hakulinen From: Fred Baker Subject: (IPng 3314) Re: IPv6 priority field usage? Cc: Steven L Blake , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 583 At 3:28 AM +0200 3/14/97, Harri Hakulinen wrote: >I think that only one drop-preference bit is maybe not futureproof >solution. it's not present-proof. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 18:50:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01977; Mon, 17 Mar 1997 18:32:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01944; Mon, 17 Mar 1997 18:31:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA27643; Mon, 17 Mar 1997 18:32:39 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA28199 for ; Mon, 17 Mar 1997 18:34:20 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id SAA03493; Mon, 17 Mar 1997 18:32:40 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id SAA02786; Mon, 17 Mar 1997 18:32:39 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <9703141513.AA12134@ludwigia.raleigh.ibm.com> References: Your message of "Thu, 13 Mar 1997 18:11:02 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 1997 13:41:38 -0800 To: Thomas Narten From: Fred Baker Subject: (IPng 3316) Re: Proposed IPv6 Priority Field Semantics Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 626 At 10:13 AM -0400 3/14/97, Thomas Narten wrote: >Indeed, would it break anything at this point to simply redefine those >bits "for use by routers as they see fit"? yes - the deployment of IPvN>6 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 18:51:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01979; Mon, 17 Mar 1997 18:32:38 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01958; Mon, 17 Mar 1997 18:31:59 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA27649; Mon, 17 Mar 1997 18:32:43 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA28227 for ; Mon, 17 Mar 1997 18:34:25 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id SAA03506; Mon, 17 Mar 1997 18:32:45 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id SAA02795; Mon, 17 Mar 1997 18:32:44 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <9703141359.AA12036@ludwigia.raleigh.ibm.com> References: Your message of "Thu, 13 Mar 1997 18:11:07 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 1997 13:54:55 -0800 To: Thomas Narten From: Fred Baker Subject: (IPng 3318) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 700 At 8:59 AM -0400 3/14/97, Thomas Narten wrote: >Are you saying that ISP border routers are rewriting the precedence >bits in the IPv4 header to give better service to customers with >$$$$$$ and worse service to those with just a $? yes, that's exactly what I am saying =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 18:51:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01978; Mon, 17 Mar 1997 18:32:30 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01951; Mon, 17 Mar 1997 18:31:56 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA27646; Mon, 17 Mar 1997 18:32:40 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA28210 for ; Mon, 17 Mar 1997 18:34:22 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id SAA03497; Mon, 17 Mar 1997 18:32:42 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id SAA02789; Mon, 17 Mar 1997 18:32:41 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <9703141807.AA29684@vision.raleigh.ibm.com> References: Your message of "Fri, 14 Mar 1997 03:28:40 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 1997 13:43:14 -0800 To: slblake@vnet.ibm.com From: Fred Baker Subject: (IPng 3317) Re: IPv6 priority field usage? Cc: Harri Hakulinen , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1037 At 1:07 PM -0500 3/14/97, Steven L Blake wrote: >One bit only gives limited granularity. But the whole concept of drop >preference for best-effort traffic is IMHO only useful in the event of >transient congestion, where you are trying to lower the delay/loss >probability of some of your other packets. As has already been argued >by others, under sustained congestion, you want the sources to back off. >It's not clear where the cost/benefit analysis of multiple levels >of drop preference (for best-effort without per-source/flow policing) >would fall out. you can decide whom to ask to back off first =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 18:50:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01976; Mon, 17 Mar 1997 18:32:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01940; Mon, 17 Mar 1997 18:31:53 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA27640; Mon, 17 Mar 1997 18:32:38 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAB28194 for ; Mon, 17 Mar 1997 18:34:19 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id SAA03489; Mon, 17 Mar 1997 18:32:38 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id SAA02783; Mon, 17 Mar 1997 18:32:37 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <199703171150.NAA01333@kaarne.cs.tut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Mar 1997 13:39:33 -0800 To: Koskelainen Petri From: Fred Baker Subject: (IPng 3315) Re: Proposed IPv6 Priority Field Semantics Cc: fred@stilton.cisco.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 9463 At 1:50 PM +0200 3/17/97, Koskelainen Petri wrote: >Fred: >>I would suggest that priority is in fact a drop preference. If I am sending >>a stream and labelling some packets with a higher priority than others, and >>the network is being forced to drop something, it will drop the lower >>priority traffic first. > >ok, you mean that priority bit is comparable among one flow only. >That's exactly what I've suggested. >(well, perhaps two bits for this purpose if possible) I'm not at all sure what connection exists between what I said and what you inferred. No, I emphatically do not believe that priority is within a single flow; I do believe that a single flow might be sent at more than one (drop) priority. What I said was that I thought that priority was almost by definition across all flows - it is intended to guide intermediate systems in sorting and supplying bandwidth to the traffic they have in their queues from all flows, not to help them deal with traffic from a single flow. >Can you clarify which one you meant? Certainly. I'm going to go into quite a bit more detail than you ask for, the reason being that you need some context to come up with an appropriate answer in the case. >1: IPv6 priority is associated with source address (one flow) and it has > meaning only in one sender's flow This has no bearing on what I said. >2: IPv6 priority is comparable among router traffic in general, not just > among one sender's flow This is what I said. >I'd like also to hear router vendors view about the router complexity >to provide choice 1. >Is it possible to implement with tolerable costs in performance? >(with state-of-the-art int-serv routers) All things are possible; the important question is "what it would achieve?" You may think, if you like, of two classes of deployed router interfaces (note that I don't say "routers"; the same router might be in each of the classes with respect to a different set of interfaces): - those that deal with tens to hundreds of flows across a given line at a given time, usually found near the edge of the network, and which present a bottleneck between the source and destination of the flows being considered +-------+ +-------+ | | T-1 | | | +---------------+ | | | | | +---+---+ +---+---+ | | /---+---/ /---+---/ - those that deal with hundreds to hundreds of thousands of flows at any given time usually found at transit points. | | T3 | +---+---+ | | --------+ +-------- T3 | | T3 +---+---+ | | T3 | There is a common fallacy that the latter is differentiated from the former by the line speeds in question - the esteemed Dr. John Turner once tried to convince me that an OC-48 ATM interface needed only 256 cells of buffer because such an interface is so fast that no substantive queue ever forms. This is a fallacy - regardless of interface speed, if the input rate exceeds the output rate, a queue will form, and in the second case as I've drawn it, the input rate to any one interface may momentarily be four*T3 (you'll say "why? Three inputs, one output" and I will answer "you can receive traffic on all four T3s...") There is no conceptual difference between an E3 connecting two FDDI rings and a T-1 connecting two Ethernets, if the application is equally able to send data at a rate that congests the link. The difference between the cases is the behavior of traffic in the current Ethernet - the first experiences short term jitter as waves of traffic crash on it as waves of water on a beach, while the latter experiences longer term jitter more comparable to ocean swells. Bring along an application, like medical imaging, that can generate huge bursts at high speed, and you can describe the first case at whatever speed you like. In the former case, where there is a high degree of short term variation, and a single application is able to build a sustained queue for a longish period of time, queuing techniques like WFQ and CBQ are very effective, and differing priorities tend to result in different statistical duration of delay. Priority Queuing - reordering traffic in a strictly linear set of queues - also has a great effect, though often not quite the effect that was desired. Generally, one finds a subset of the active flows drive the line into congestion, and the remainder of the flows are more transaction-oriented - they are starting the connection or stopping it, or are transaction-oriented by the nature of their application. These queues will have a few tens of packets in queue, perhaps half of which are from the few overburdening flows, and the rest are transaction traffic. Network administration will in this case have one of a few policies concerning traffic on interfaces: they want to give a certain application or user precedence (the case contemplated by priority queuing), they want to distribute bandwidth availability according so some policy such as "who is paying for the line" (the case contemplated by class-based queuing), or they want to force the "fast" flows to interleave with each other and give way to transaction traffic (fair or weighted fair queuing). Since there are several messages in queue from each of the overburdening flows and (generally) at most one from the transaction traffic, it is very reasonable to sort traffic, the only serious question is what policy drives the sorting, what algorithm is chosen, and what CPU processing penalty is incurred. At higher speeds, hardware assists may be in order. In queues at transit points in the net, the second case, ambient flows tend to have traffic in flight a good proportion of their time, and so have a message transiting the router at fairly regular intervals. In a TCP file transfer, for example, one sees a certain number of messages for any given flow each round trip time, and TCP tries to make that number approximate the number of routers on the interconnecting path. Generally speaking, the queues have a very small number of messages in them by comparison to the number of flows - a typical T3 backbone link will have on the order of 100-500 messages in queue from perhaps 50,000 to 100,000 active flows, for example. The probability that any two of those messages are from the same flow is therefore exceedingly small. As a result, per-flow queuing techniques are less effective, and we look for other ways to apply policy to traffic. Traffic policies therefore tend to aggregate traffic, giving priority to an application or distributing bandwidth according to some policy. The effect of priority is not to significantly delay some traffic or improve the performance of another - time in queue for the average message is simply not that long - but to determine what should be dropped when that comes up. The arguments for having priority from a given sender have scope within a flow have circled around the idea that a single application might choose to completely discard a subset of its traffic in favor of another set. The case that comes to mind for this is layered encodings of video - one might send a key frame once a second and delta frames at up to 30 times a second, and give priority to the data such that every other delta frame has the least priority, every fourth delta frame has second-least, every eighth a median level, every sixteenth the second most, and the key frame the most priority. In this manner, when traffic meets a bottleneck link (the first type) and there simply isn't bandwidth available to get all the data through, the router can intelligently discard the finest motions and still get coarser motion through. This, however, is the only kind of application that comes to mind where the application itself is well served by differential priority within the same flow - the successive packets of a TCP session do not have different priority, for example. Even in this application, if the use of differing priorities resulted in different delivery sequence (the natural effect of simplistic priority queuing), the application would be compromised. Service providers might use different priorities in the same flow as a way of implementing the moral equivalent of Frame Relay's CIR - "you can get as much through as I have bandwidth for, but if your rate exceeds a token bucket, I will mark the excess 'discard this first'". Again, they probably don't want this to reorder traffic in a flow. It is more a drop/delay priority for them. Applications currently running in the internet are not well served by arbitrary reordering of their traffic by priority, but by changes in discard probability or statistical duration of delay (which is to say, reordering among flows). The question the router must use priority to answer is rarely "how do I group things with respect to a single flow", but "among the flows having traffic in queue at this interface, in what order should I forward their traffic in order to achieve the administrative policy at this point?" I hope that's sufficiently clear. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 20:31:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA02072; Mon, 17 Mar 1997 20:23:23 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA02065; Mon, 17 Mar 1997 20:23:13 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA12910; Mon, 17 Mar 1997 20:23:59 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA27302 for ; Mon, 17 Mar 1997 20:25:40 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA26697; Mon, 17 Mar 1997 23:19:59 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22482; Mon, 17 Mar 1997 23:19:58 -0500 Message-Id: <9703180419.AA22482@wasted.zk3.dec.com> To: huitema@bellcore.com (Christian Huitema) Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 3319) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Mon, 17 Mar 97 13:19:36 EST." <9703171319.ZM7077@seawind.bellcore.com> Date: Mon, 17 Mar 97 23:19:58 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2345 Christian, >My statement on flows was indeed partly tongue in cheek. However, I have >yet to see a justification on why the flow-id should be 24 bit rather than >16 or 32. The proposed usages are vague, and could use some >experimentation or definition. For example, you quote both RSVP and label >switching as possible usages, but these two are contradictory -- RSVP >requires end to end labels, label switching probably requires labels to be >rewritten when you pass network boundaries... Good point and thought it was tongue and cheek but wanted to check. >Then, in the case of RSVP, I know how we can use the flow-ids. Pass them >in the PATH messages, use them in the RSVP. Fine. But do we really need >more than 64K flows per source ? Good point. On the label switching I am only speaking of the ones I know running today for customers not the dream and mass of proposals right now which I will let sort out and see what the IETF answer is, but for today one has to store any label flow-ids in a cache and use it as required to inform the switch when it sees the packet at layer 2. That could just as well be kept in the IPv6 header flow-id. Other ideas come to mind with RSVP even though it is end to end. Another use will be QOS schemes that want to use the flow for feeds that are multicast (e.g. stock quotes, horse race odds, latest movie over cable) that Intranet providers agree upon amongst themselves. Such a scheme does not need a draft and 3 years of discussion in the IETF and can just be used and developed in private enterprise. IPv6 is for the masses not for the IETF. >On the whole, I have a lot of sympathy for the implementation concerns. > My personnal take would be to stay within the 4 bits which we have >allocated, and to define their usage. In particular, if these bits can be >rewritten by intermediate routers, which I think should be allowed, we >have to study the impact on the whole chain (IPSEC). Exactly and blowing away IPsec in anyway to me is just a bad idea so the win has to be pretty big. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 17 21:51:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA02117; Mon, 17 Mar 1997 21:44:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA02110; Mon, 17 Mar 1997 21:43:55 -0800 From: bound@ZK3.DEC.COM Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA20714; Mon, 17 Mar 1997 21:44:41 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA12379 for ; Mon, 17 Mar 1997 21:46:23 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id AAA08775; Tue, 18 Mar 1997 00:37:19 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25416; Tue, 18 Mar 1997 00:37:19 -0500 Message-Id: <9703180537.AA25416@wasted.zk3.dec.com> To: Fred Baker Cc: Koskelainen Petri , fred@stilton.cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 3320) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Mon, 17 Mar 97 13:39:33 PST." Date: Tue, 18 Mar 97 00:37:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 337 Fred, That was awesome on the flows.. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 03:47:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA02237; Tue, 18 Mar 1997 03:39:28 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA02230; Tue, 18 Mar 1997 03:39:19 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA21469; Tue, 18 Mar 1997 03:40:07 -0800 Received: from mail.ton.tut.fi (mylly.ton.tut.fi [193.166.80.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA22152 for ; Tue, 18 Mar 1997 03:41:49 -0800 Received: from localhost (veikko@localhost) by mail.ton.tut.fi (8.8.0/8.8.0) with SMTP id NAA21439; Tue, 18 Mar 1997 13:39:55 +0200 (EET) Date: Tue, 18 Mar 1997 13:39:54 +0200 (EET) From: Harri Hakulinen Reply-To: Harri Hakulinen To: Fred Baker cc: Koskelainen Petri , ipng@sunroof.eng.sun.com Subject: (IPng 3322) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6419 Fred, thanks for the backround information, that was really valuable. On Mon, 17 Mar 1997, Fred Baker wrote: > No, I emphatically do not believe that priority is within a > single flow; I do believe that a single flow might be sent at more than one > (drop) priority. What I said was that I thought that priority was almost by > definition across all flows - it is intended to guide intermediate systems > in sorting and supplying bandwidth to the traffic they have in their queues > from all flows, not to help them deal with traffic from a single flow. I don't understand, how we could "force" end-users to respect predefined priorities, even if carrots and sticks are used. So, for me this means that priority is actually decided in edge-router or firewall or whatever in the basis of administrative policy, not by application itself. > All things are possible; the important question is "what it would achieve?" In my imagination, it is possible that IP networks could be technically superior for video stream type applications (VBR, low to medium bit rate, layered coding) compared to any other network, if some kind of optimization is done in network level (some explanatory comments follow). > Generally speaking, the > queues have a very small number of messages in them by comparison to the > number of flows - a typical T3 backbone link will have on the order of > 100-500 messages in queue from perhaps 50,000 to 100,000 active flows, for > example. The probability that any two of those messages are from the same > flow is therefore exceedingly small. As a result, per-flow queuing > techniques are less effective, and we look for other ways to apply policy > to traffic. There is no doubt, this is the case today. But what happens, when people are starting to use flow-based tools like videophone (32-256kbits ->..) and VOD for (porn)movies (32 kbits -> ... ). Those flows are active all the time. > The arguments for having priority from a given sender have scope within a > flow have circled around the idea that a single application might choose to > completely discard a subset of its traffic in favor of another set. The > case that comes to mind for this is layered encodings of video - one might ... > In this manner, when traffic meets a bottleneck link (the first > type) and there simply isn't bandwidth available to get all the data > through, the router can intelligently discard the finest motions and still > get coarser motion through. This, however, is the only kind of application > that comes to mind where the application itself is well served by > differential priority within the same flow That may well be the only case, where different (drop)priorities are needed. But as I said in my first mail in this subject, In my mind this is one of the moust important new application areas in IP(v6) networks, and for me it makes sense to do some optimization even in IP header for these applications. > Even in this > application, if the use of differing priorities resulted in different > delivery sequence (the natural effect of simplistic priority queuing), the > application would be compromised. That is right, if we are discussing "real time video" etc. flows, like videophone. But there is also different subcases in realtime video. You may consider a case, where you want sharp picture of spekers face and you only slightly add details to backround. In that case backround drawing can have bigger buffers and is not affected by different delivery sequence (RTP, for example has sequence numbers in packets). > Service providers might use different priorities in the same flow as a way > of implementing the moral equivalent of Frame Relay's CIR - "you can get as > much through as I have bandwidth for, but if your rate exceeds a token > bucket, I will mark the excess 'discard this first'". Again, they probably > don't want this to reorder traffic in a flow. It is more a drop/delay > priority for them. Avoiding reordering is obviously good point in this case. So we have different "main-subcases". > Applications currently running in the internet are not well served by > arbitrary reordering of their traffic by priority, but by changes in > discard probability or statistical duration of delay (which is to say, > reordering among flows). The question the router must use priority to > answer is rarely "how do I group things with respect to a single flow", but > "among the flows having traffic in queue at this interface, in what order > should I forward their traffic in order to achieve the administrative > policy at this point?" I still don't fully understand, why different drop priorities inside flow must lead to packet reordering (I obviously have to do my homework). My concern is, that I cannot see any way to compare drop priorities among flows, if different application level protocols (Video codecs) are used (with different speeds). Some kind of codec could have moust of its discardable stuff in e.g. level 4, and finer granularity bethween levels 3 to 1. Other kind of codec could have same amount of stuff in all levels. This means that in congestion, you must first drop level 4 from first one and at least levels 4 and 3 from second one. Because all my concerns are related to some kind of flows, it may make sense to define some kind of combined "pririority inside flow" method. I mean, that some flow ID's could be reserved for flows, tha are not actually reserved by RSVP or any kind of such method. Then those flow-ids could be used with priority field to signal routers that this flow uses different drop priorities inside flow. Other thing is, that I am NOT in favour, that routers should be able to chance fields, that are assigned for applications. I am looking this more from applications point of view and it does not make any sense for me at all. If this can really happen only in intranets or inside one ISPs network, this seems to be more like local policy than IETF issue for me (exept the effects to IP security). - Harri.Hakulinen@research.nokia.com Video laboratory/Network & Terminal technologies Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 06:35:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02463; Tue, 18 Mar 1997 06:26:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02456; Tue, 18 Mar 1997 06:25:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA05881; Tue, 18 Mar 1997 06:26:42 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA08462 for ; Tue, 18 Mar 1997 06:28:28 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA20800; Tue, 18 Mar 1997 09:26:29 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA19206; Tue, 18 Mar 1997 09:26:25 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17066; Tue, 18 Mar 1997 09:26:02 -0500 Message-Id: <9703181426.AA17066@ludwigia.raleigh.ibm.com> To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3324) Redefining the semantics of IPv6 Version field In-Reply-To: Your message of "Mon, 17 Mar 1997 11:32:06 EST." <9703171132.ZM7040@seawind.bellcore.com> Date: Tue, 18 Mar 1997 09:26:02 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 937 > The version field is also used by the Header Compression protocol. Yes, though I don't see right off that this would be difficult to change (it is currently defined as a NOCHANGE meaning that it shouldn't change from one packet to the next). In any case, if the network is allowed to rewrite the 4-bit Priority field of the IPv6 header (as is being discussed in the meta thread) the Header Compression draft may need tweaking anyway. In the current draft, the Priority field is expected to remain contstant for a given "packet stream". Whether or not this assumption holds depends on who rewrites the Priority field and what criteria is used. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 06:41:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02472; Tue, 18 Mar 1997 06:31:38 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02465; Tue, 18 Mar 1997 06:31:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA06737; Tue, 18 Mar 1997 06:32:14 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA10436 for ; Tue, 18 Mar 1997 06:34:00 -0800 Received: from rtpdce03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA10192; Tue, 18 Mar 1997 09:32:06 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA45648; Tue, 18 Mar 1997 09:32:05 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18064; Tue, 18 Mar 1997 09:31:39 -0500 Message-Id: <9703181431.AA18064@ludwigia.raleigh.ibm.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3325) Re: Proposed IPv6 Priority Field Semantics In-Reply-To: Your message of "Mon, 17 Mar 1997 10:21:26 CST." <199703171621.KAA26578@gungnir.fnal.gov> Date: Tue, 18 Mar 1997 09:31:39 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1127 > IMHO, alloting a separate ethertype for IPv6 was one of the most > impure things the IPNGWG did. :-) > And there's (at least) one possibility which hasn't been mentioned > yet. If someone wants some header bits to play with in an private > way, they can go outside of the IP header entirely and extend their > encapsulation on their links. This is already going on under names > like "tag switching" and "VLAN tagging." While this is true, one of the key issues is who does the classifying of the the IP packet into its respective link-layer flow/connection/class/whatever (e.g., which packets get the better services?). Does the node performing the classification have sufficient knowledge readily available to do the classification? Carefully defined bits in the IP header (e.g., Priority) can make this job a whole lot easier. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 07:00:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02496; Tue, 18 Mar 1997 06:49:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02489; Tue, 18 Mar 1997 06:49:46 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA12031; Tue, 18 Mar 1997 06:50:34 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA16966 for ; Tue, 18 Mar 1997 06:52:21 -0800 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA31784; Tue, 18 Mar 1997 09:47:45 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA47266; Tue, 18 Mar 1997 09:47:41 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17336; Tue, 18 Mar 1997 09:47:18 -0500 Message-Id: <9703181447.AA17336@ludwigia.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3326) Redefining the semantics of IPv6 Version field In-Reply-To: Your message of "Mon, 17 Mar 1997 10:35:51 EST." <9703171535.AA16451@wasted.zk3.dec.com> Date: Tue, 18 Mar 1997 09:47:18 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1259 > >Do the current specs say that all link layers MUST provide a > >separate code point for IPv6? > No. But this is also the type of thing that typically never gets documented outright in an RFC. For all practical purposes, however, it is a requirement today. The WG long-ago decided that each link-layer type would need its own demultiplexing key for IPv6 precisely because of the fear that some implementations would barf if an IPv6 packet were accidentally delivered to the IPv4 stack (i.e., it is not safe to use the same link-layer encapsulation for both v4 and v6 packets). Which link-layer type is a counter example? > I think a bigger issue is at play here in general about IPv6. Its the > issue of changing code base now for implementors. I am *very* sympathetic to this point. At the same time, without proposing a strawman, it's pretty difficult to gauge the pros and cons needed to decide whether the potential benefits of a change outweigh the costs. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 07:04:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02515; Tue, 18 Mar 1997 06:54:25 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02508; Tue, 18 Mar 1997 06:54:10 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA13436; Tue, 18 Mar 1997 06:54:58 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA19056 for ; Tue, 18 Mar 1997 06:56:43 -0800 Received: by mail.noris.net id <35207-4240>; Tue, 18 Mar 1997 15:54:45 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3327) Re: Proposed IPv6 Priority Field Semantics Date: 18 Mar 1997 15:53:53 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 42 Message-ID: <5gmaa1$3m6$1@work.smurf.noris.de> References: <858686716.2702@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1580 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2457 In dist.ipng, article <858686716.2702@noris.de>, Harri Hakulinen writes: > > I still don't fully understand, why different drop priorities inside flow > must lead to packet reordering (I obviously have to do my homework). > Usually, prioritizing traffic means sticking the packets into different queues. Usually^2, there's not much high-priority traffic, so the "fast" queue will drain faster and fast packets overtake the slower ones. Alternately, you can of course keep a bunch of counters per priority and drop an incoming packet when "its" counter is at its maximum. But that isn't as flexible, because usually^3 you _want_ eg. Telnet traffic to overtake eg. FTP traffic (or NNTP). > My concern is, that I cannot see any way to compare drop priorities among > flows, if different application level protocols (Video codecs) are used > (with different speeds). Some kind of codec could have moust of its > discardable stuff in e.g. level 4, and finer granularity bethween > levels 3 to 1. Other kind of codec could have same amount of stuff in > all levels. This means that in congestion, you must first drop level 4 > from first one and at least levels 4 and 3 from second one. > That just means that one codec's data is less discardible than the other's. Or at least it should mean that. I imagine that implementors will either choose sensible priorities for their traffic, or they'll find out that most routers will ignore the priorities and thus make their data stream less than useful by the time it comes out on the other end. > Other thing is, that I am NOT in favour, that routers should be able to > chance fields, that are assigned for applications. 100% agreement from me. -- Most of us will never do great things, but we can do small things in a great way. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 08:47:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02753; Tue, 18 Mar 1997 08:36:13 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02742; Tue, 18 Mar 1997 08:35:58 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08687; Tue, 18 Mar 1997 08:36:46 -0800 Received: from basil.cdt.luth.se (basil.cdt.luth.se [130.240.64.67]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA29326 for ; Tue, 18 Mar 1997 08:38:32 -0800 Received: from scarpa (scarpa.cdt.luth.se [130.240.64.46]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id RAA09710; Tue, 18 Mar 1997 17:34:31 +0100 (MET) Received: from scarpa (localhost [127.0.0.1]) by scarpa (SMI-8.6/8.6.12) with ESMTP id RAA13553; Tue, 18 Mar 1997 17:35:19 +0100 Message-Id: <199703181635.RAA13553@scarpa> X-Mailer: exmh version 1.6.7 5/3/96 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: us-ascii To: Thomas Narten Cc: micke@cdt.luth.se, ipng@sunroof.eng.sun.com, huitema@bellcore.com (Christian Huitema) Subject: (IPng 3330) Re: Redefining the semantics of IPv6 Version field In-reply-to: Your message of Tue, 18 Mar 1997 09:26:02 -0400. Date: Tue, 18 Mar 1997 17:35:19 +0100 From: Mikael Degermark Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1983 > > The version field is also used by the Header Compression protocol. > > Yes, though I don't see right off that this would be difficult to > change (it is currently defined as a NOCHANGE meaning that it > shouldn't change from one packet to the next). The problem is not with the compressed headers but with the FULL_HEADERs. In the Header Compression draft, we use the Version field to encode FULL_HEADER types. The draft specifies how to compress any sequence of of IPv4 and IPv6 headers. The first subheader in the FULL_HEADER can then be either an IPv4 or an IPv6 header, and it is thus necessary to convey which one it is to the decompressor. If the Version field is removed, the link layer would have to be able to indicate different kinds of FULL_HEADERs. Some link layers may not have enough code points. It is already difficult to get enough of them for PPP with the current scheme. > In any case, if the network is allowed to rewrite the 4-bit Priority > field of the IPv6 header (as is being discussed in the meta thread) > the Header Compression draft may need tweaking anyway. I don't think it is *needed* (please tell me if I have this backwards). It is clearly stated in the draft that the compressor can use any way it wants to classify packets into "packet streams". We provide some guidelines on how it might be done, but those are guidelines only. We avoided overspecification in order to avoid having to change the draft whenever we found a better way to classify packets or the semantics of fields changed. However, it might be *instructive* to change the Priority field into a DEF field in the guidelines even if it is not strictly necessary. Micke Degermark ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 08:47:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02752; Tue, 18 Mar 1997 08:36:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02737; Tue, 18 Mar 1997 08:35:54 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08678; Tue, 18 Mar 1997 08:36:43 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA29131 for ; Tue, 18 Mar 1997 08:38:15 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA02410; Tue, 18 Mar 1997 11:25:29 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06948; Tue, 18 Mar 1997 11:25:28 -0500 Message-Id: <9703181625.AA06948@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3329) Re: Redefining the semantics of IPv6 Version field In-Reply-To: Your message of "Tue, 18 Mar 97 09:47:18 -0400." <9703181447.AA17336@ludwigia.raleigh.ibm.com> Date: Tue, 18 Mar 97 11:25:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 843 >> I think a bigger issue is at play here in general about IPv6. Its the >> issue of changing code base now for implementors. > >I am *very* sympathetic to this point. At the same time, without >proposing a strawman, it's pretty difficult to gauge the pros and cons >needed to decide whether the potential benefits of a change outweigh >the costs. Good point and I agree completely. But what is creeping featurism for IPv6 and what is really needed? That is something we all should be aware of as we work hard to get to Draft Std for the core specs. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 09:03:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02776; Tue, 18 Mar 1997 08:52:16 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02769; Tue, 18 Mar 1997 08:52:00 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12372; Tue, 18 Mar 1997 08:52:48 -0800 Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA06646 for ; Tue, 18 Mar 1997 08:54:24 -0800 Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id RAA05311; Tue, 18 Mar 1997 17:51:52 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma027849; Tue Mar 18 17:26:56 1997 Received: from hades.mpn.cp.philips.com (hades.mpn.cp.philips.com [130.139.64.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970305) with ESMTP id RAA17417; Tue, 18 Mar 1997 17:26:54 +0100 Received: from pc239.nwm.wan.philips.com (pc239.nwm.wan.philips.com [161.89.1.239]) by hades.mpn.cp.philips.com (8.6.10/8.6.10-1.2a-960910) with SMTP id RAA21928; Tue, 18 Mar 1997 17:25:44 +0100 Message-Id: <1.5.4.32.19970318162516.006db888@hades.mpn.cp.philips.com> X-Sender: rhunter@hades.mpn.cp.philips.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 1997 17:25:16 +0100 To: ipng@sunroof.eng.sun.com From: Ray Hunter Subject: (IPng 3331) Re: Proposed IPv6 Priority Field Semantics Cc: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6228 A lurker writes: I have observed this debate on queueing with some interest, and would like to add the following observations from the perspectives of a network manager. 1. Weighted Fair Queueing is a wondrous thing. WFQ is indeed one of the most interesting features I have seen in a router in a long time. I re-emphasise the point that WFQ per se does not require _any_ header bits. Each WFQ runs independently on a per interface basis. There is no notion of a network wide priority scheme. Which brings me on to my following points.... 2. The emphasis in this forum at the moment seems to be on priority for end to end applications. In many design seminars it is emphasised that the queueing features implmented in routers are a mechanism that tells the router what to do when you can't afford enough bandwidth. IP is hop by hop paradigm based on best effort datagram delivery, so the notion of end to end priority is a new concept and requires new thinking (ala RSVP) There is already a hook in the header (the flow tag) for use by RSVP et al. The target here is to engineer IPv6... not RSVP. 3. Some people in the IETF seem intent on setting a global strategy for priority and drop mechanisms. Having talked to just a few customers within our organisation I can tell you that there is no agreement on what is important, even on this small scale. Some people want to prioritise DECnet over IP (that'll please Jim). Others want file transfer prioritised over everything, because their business relies on sending 500+MB files half way around the world in <24 hours. There is no correct policy for all.....each business has its own priority. 4. Priority for most traffic can only be within an Autonomous System. If people decide to honour priority over an AS boundary, I'm sure they'll expect mucho $$$. I'd sure as hell reset it to default priority if they didn't pay for it explicitly. Otherwise you get the typical escalation of "my stuff is more important that yours." Everyone says I'm priority 1, and no-one wins. I say again: there cannot be one global policy for all. Setting bits based on a priority-list at the edge of each ISP network and letting the intermediate routers fast-switch based on priority field would be a very good thing... assuming of course that you control all the routers. How the priority is set is a policy decision of each ISP, and is beyond the remit of the IETF. 5. Distinguishing flows for intermediate level 2 devices would also seem to me to be very important (not mentioned much on the list) Lots of frame relay switches also have the notion of somewhere around 7 seperate input queues depending on traffic type. The use of a single DE bit is completely inadequate IMHO. The lack of common ground between IP and FR is a real problem to me at the moment. The performance of interactive traffic over some well known vendor's switches is diabolical when you load the input buffer. The point I am making is that there is more than one place in an IP network where stuff is queued. These queues are also normally much slower and longer in the WAN than those in a router. A switch could quite easily look at ip packet headers and do something very useful with that info based on a couple of bits in a fixed position. You cannot expect them to look at flow tags. OK the purists in the OSI will get very excited about this, but it is not much different from promoting FECN/BECN in to DECnet. Again how these are used should be on a policy per connection basis. How the switch queue interacts with the router queue is another place for a vendor to shine. Maybe there can be some work done in the Cisco/Stratacom forum ;-) 6. Distinguishing flows within a session for certain applications also seems useful. The classic examples so far seem to be isochronous services over asynchronous transport (voice over UDP, video over UDP) Do not fall in to the trap of ATM, and try to define every QOS there is. What percentage of stuff will turn out to be pure AAL5, after all that talk?? This is a different semantic from the other notions of priority, based on end to end flows. However, all of this functionality will not fit in 4 bits.... MY CONCLUSIONS: Either you expand the number of bits in the priority field, or you merge the host to host type functionality in to the flow tag, and just keep all 16 possibilities for bulk control for use by routers and notification of layer 2 devices. Applications may set priority fields, but routers are not obliged to honour them. The priority field bits should all definitely be rewritable by the routers. The priority field should therefore be excluded from ipsec checksums. It is the network manager who should determine how his/her network runs, not the users of the network. Any good router vendor should allow you to set these bits based on your policy specific to your network. e.g. well known source and destination port numbers, source address, destination address. Any good switch vendor will start doing mapping between an IP priority and an input queue on the switch. You could still define some portion of the flow tag to be 'well known' for isochronous traffic drop priority. As has already been discussed, there seems to be enough bits here. That field would not be rewritable by intermediate devices, and so can safely be included in the ipsec checksum. This is similar to the level2 switch case I mentioned.... the router just has to be told by the video codec that "this packet is not important." The router does not have to decide, nor even understand, why it is not important. All it sees is a certain pattern in a flow tag, and then queues accordingly. very best regards, Ray Hunter on contract to Origin Building VA-130, Postbus 218, 5600MD Eindhoven, The Netherlands. email: Ray.Hunter@mpn.cp.philips.com email: Ray.Hunter@globis.net www: http://www.globis.net/~rhunter phone: +31 40 2787988 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 09:21:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02829; Tue, 18 Mar 1997 09:10:44 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02821; Tue, 18 Mar 1997 09:10:38 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA27525; Tue, 18 Mar 1997 09:11:27 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12628; Tue, 18 Mar 1997 09:10:49 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA02438; Tue, 18 Mar 1997 05:46:56 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA01219; Tue, 18 Mar 1997 05:47:44 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA24645 for ; Tue, 18 Mar 1997 05:49:30 -0800 Received: from ietf.ietf.org by ietf.org id aa18822; 18 Mar 97 8:49 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3332) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-01.txt Date: Tue, 18 Mar 1997 08:49:43 -0500 Message-ID: <9703180849.aa18822@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3377 --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-01.txt Pages : 10 Date : 03/14/1997 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-over-ppp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970317162728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-over-ppp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970317162728.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 09:26:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02851; Tue, 18 Mar 1997 09:15:54 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02844; Tue, 18 Mar 1997 09:15:48 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28257; Tue, 18 Mar 1997 09:16:38 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12659; Tue, 18 Mar 1997 09:15:59 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02608; Tue, 18 Mar 1997 07:47:03 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA28987; Tue, 18 Mar 1997 07:47:52 -0800 Received: from caipfs.rutgers.edu (caipfs.rutgers.edu [128.6.37.100]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA08965 for ; Tue, 18 Mar 1997 07:49:37 -0800 Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id KAA00134; Tue, 18 Mar 1997 10:45:19 -0500 (EST) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id KAA26664; Tue, 18 Mar 1997 10:45:08 -0500 Date: Tue, 18 Mar 1997 10:45:08 -0500 Message-Id: <199703181545.KAA26664@jenolan.caipgeneral> From: "David S. Miller" To: narten@raleigh.ibm.com CC: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-reply-to: <9703181447.AA17336@ludwigia.raleigh.ibm.com> (message from Thomas Narten on Tue, 18 Mar 1997 09:47:18 -0400) Subject: (IPng 3333) Re: Redefining the semantics of IPv6 Version field Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1237 Date: Tue, 18 Mar 1997 09:47:18 -0400 From: Thomas Narten The WG long-ago decided that each link-layer type would need its own demultiplexing key for IPv6 precisely because of the fear that some implementations would barf if an IPv6 packet were accidentally delivered to the IPv4 stack (i.e., it is not safe to use the same link-layer encapsulation for both v4 and v6 packets). In fact if I recall correctly ip_input() in Net/1 derived stacks (they are out there) don't check the version in the IP header during processing. I'm sure many other older implementations behave the same. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ >< ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 10:31:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03109; Tue, 18 Mar 1997 10:18:11 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03102; Tue, 18 Mar 1997 10:18:00 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA03156; Tue, 18 Mar 1997 10:18:48 -0800 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA15964 for ; Tue, 18 Mar 1997 10:20:37 -0800 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id KAA24431; Tue, 18 Mar 1997 10:18:48 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id KAA02972; Tue, 18 Mar 1997 10:18:47 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 1997 10:11:11 -0800 To: Harri Hakulinen From: Fred Baker Subject: (IPng 3334) Re: Proposed IPv6 Priority Field Semantics Cc: Koskelainen Petri , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5297 At 1:39 PM +0200 3/18/97, Harri Hakulinen wrote: >I don't understand, how we could "force" end-users to respect predefined >priorities, even if carrots and sticks are used. So, for me this means >that priority is actually decided in edge-router or firewall or whatever >in the basis of administrative policy, not by application itself. That can go a couple of ways. I would like to continue to believe that priority 0 means "routine", and would like to believe that applications that know that some priority may be in order (Voice on IP, for example) might ask for more. So I don't see value in attempting to preclude the end station from setting the field in some way (it *has* to set it somehow, in the end - it cannot just send the bits). Having said that, I see no problem with the routers overriding that under administrative control. >Avoiding reordering is obviously good point in this case. So we have >different "main-subcases". >I still don't fully understand, why different drop priorities inside flow >must lead to packet reordering (I obviously have to do my homework). Because, as I pointed out earlier, having separate drop and scheduling priorities makes no sense. In some cases, priority will be implemented as a drop priority, and in some cases it will influence queuing, but it will not do both except as a side effect. The reason I mention delivery sequence is because I'm not sure we yet agree that predicating the definition of the field (priority ordering) on the state of the art in queue management ten years ago makes no sense. The way to handle this is to have an across-flows priority number (and if you want to have different drop priorities within a flow, have the sender diddle the least significant bit in that field), and say that higher priority implies increased probability of timely delivery, which includes increased probability of delivery. Leave it to the routers (and their administrations) to determine what the best local implementation of that is - drop priority or influencing queue weighting. >My concern is, that I cannot see any way to compare drop priorities among >flows, if different application level protocols (Video codecs) are used >(with different speeds). Some kind of codec could have moust of its >discardable stuff in e.g. level 4, and finer granularity bethween >levels 3 to 1. Other kind of codec could have same amount of stuff in >all levels. This means that in congestion, you must first drop level 4 >from first one and at least levels 4 and 3 from second one. If you make it sufficiently complicated, I guarantee that it will not be implemented. No, you really truly have to make the IP6 header the header that the end station uses to tell the network about getting the message across the network, and which the network can treat as a consistent set of values. Make the priority field something the network can take at face value, and tell the application to put numbers into the field consistent with what it means. You are designing a general field, to be used in all applications. Designing it with one case foremost in your mind is likely to make a suboptimal design. I would strongly suggest you get lots of different ways people might use that field in your mind and design something which can then be used in this particular case. >Because all my concerns are related to some kind of flows, it may make >sense to define some kind of combined "pririority inside flow" method. >I mean, that some flow ID's could be reserved for flows, tha are not >actually reserved by RSVP or any kind of such method. Then those flow-ids >could be used with priority field to signal routers that this flow uses >different drop priorities inside flow. I wish I could find value in the flow-id-by-sender approach. I'll apply the same argument there as I apply here - make it sufficiently complicated, and it loses value. Tell me that a router can use the flow id as an index into a table, and in that table it will find whatever it needs to know about a special flow, and I'll buy it (but last time I said that on this list, I got a barrage of upsetness, so I have let that draft expire - we'll just do it at the link layer). Tell me it has to do an expensive lookup, and I once again will say "make it sufficiently complicated, and I guarantee it won't be implemented." >Other thing is, that I am NOT in favour, that routers should be able to >change fields, that are assigned for applications. I am looking this more >from applications point of view and it does not make any sense for me at >all. If this can really happen only in intranets or inside one ISPs >network, this seems to be more like local policy than IETF issue for me >(exept the effects to IP security). I don't think you can tell network administrators that they can't apply administrative policy. This one's water under the bridge. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= It has recently been discovered that research causes cancer in rats. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 10:36:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03118; Tue, 18 Mar 1997 10:23:39 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03111; Tue, 18 Mar 1997 10:23:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA04566; Tue, 18 Mar 1997 10:24:11 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA18448 for ; Tue, 18 Mar 1997 10:25:53 -0800 Received: from ns2.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost2.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP id KAA11966; Tue, 18 Mar 1997 10:20:59 -0800 (PST) for Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns2.BayNetworks.COM (8.8.5/BNET-97/03/12-I) with SMTP id KAA29513; Tue, 18 Mar 1997 10:24:01 -0800 (PST) for Posted-Date: Tue, 18 Mar 1997 10:24:01 -0800 (PST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA19301; Tue, 18 Mar 97 13:23:59 EST Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA26754 for ; Tue, 18 Mar 1997 13:23:52 -0500 Message-Id: <3.0.32.19970318132347.00696670@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Mar 1997 13:23:48 -0500 To: ipng@sunroof.eng.sun.com From: Dimitry Haskin Subject: (IPng 3335) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4134 Hi, There are the following changes in the updated IPv6-over-PPP draft: 1. Changed interface-token to 64 bits (based on the outcome of a recent interim IPv6 meeting). a. replaced all references to 32 bit token with references to 64 bits. b. modified config option message format diagram to allow for 64 bits and added abbreviation to denote most significant byte and least significant byte. c. modified diagram of link-local address which appears in section 5, "Stateless Autoconfiguration and Link-Local Addresses". 2. Fixed up the References section based on the feedback we got on the list. 3. Textual details, such as the new publication date, new expiration date, and bumped the identifier to 01. Thanks, Dimitry >Return-Path: >Posted-Date: Tue, 18 Mar 1997 12:35:32 -0500 (EST) >To: IETF-Announce:;;@ietf.org@jurassic@jurassic@sunroof@Eng.Sun.COM >cc: ipng@sunroof.Eng.Sun.COM >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: (IPng 3332) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-01.txt >Date: Tue, 18 Mar 1997 08:49:43 -0500 >Sender: owner-ipv6 > > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the IPNG Working Group of the > IETF. > > > Title : IP Version 6 over PPP > Author(s) : D. Haskin, E. Allen > Filename : draft-ietf-ipngwg-ipv6-over-ppp-01.txt > Pages : 10 > Date : 03/14/1997 > >The Point-to-Point Protocol (PPP) [1] provides a standard method of >encapsulating Network Layer protocol information over point-to-point links. >PPP also defines an extensible Link Control Protocol, and proposes a family >of Network Control Protocols (NCPs) for establishing and configuring >different network-layer protocols. This >document defines the method for transmission of IP Version 6 [2] packets >over PPP links as well as the Network Control Protocol (NCP) for >establishing and configuring the IPv6 over PPP. It also specifies the >method of forming IPv6 link-local addresses on PPP links. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipngwg-ipv6-over-ppp-01.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-01.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-01.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. > > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 10:49:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03149; Tue, 18 Mar 1997 10:35:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03142; Tue, 18 Mar 1997 10:35:33 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA10119; Tue, 18 Mar 1997 10:36:21 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA23883 for ; Tue, 18 Mar 1997 10:38:10 -0800 Received: from gungnir.fnal.gov ("port 38300"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGNCCU8HVM000KDK@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Tue, 18 Mar 1997 12:36:20 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA29402; Tue, 18 Mar 1997 12:36:20 -0600 Date: Tue, 18 Mar 1997 12:36:20 -0600 From: Matt Crawford Subject: (IPng 3336) Re: Redefining the semantics of IPv6 Version field In-reply-to: "18 Mar 1997 09:47:18 -0400." <"9703181447.AA17336"@ludwigia.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Message-id: <199703181836.MAA29402@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ The WG long-ago decided that each link-layer > type would need its own demultiplexing key for IPv6 precisely because > of the fear that some implementations would barf if an IPv6 packet > were accidentally delivered to the IPv4 stack I recall that session. Or rather, I recall the July 17, 1995 13:00 meeting at which notes from the interim meeting were presented. The reason for a separate IPv6 ethertype 86DD was the existence of certain IPv4 stacks on certain platforms (which coincidently have an "86" in them) which do not have any crack to demultiplex based on the IP version field. Hence no other version of IP can be added to those platforms without demultiplexing at a lower level. A side note, if I may ... I consider it SHOCKING that no published minutes of that interim meeting are available, and that, furthermore, no published minutes of the July 1995 ipngwg meetings are available. Matt Crawford ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 11:55:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03367; Tue, 18 Mar 1997 11:45:32 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03360; Tue, 18 Mar 1997 11:45:22 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16907; Tue, 18 Mar 1997 11:46:09 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA23301 for ; Tue, 18 Mar 1997 11:44:07 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA21838; Tue, 18 Mar 1997 14:42:00 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id OAA88284; Tue, 18 Mar 1997 14:41:59 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17406; Tue, 18 Mar 1997 14:41:33 -0500 Message-Id: <9703181941.AA17406@ludwigia.raleigh.ibm.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3337) Re: Redefining the semantics of IPv6 Version field In-Reply-To: Your message of "Tue, 18 Mar 1997 12:36:20 CST." <199703181836.MAA29402@gungnir.fnal.gov> Date: Tue, 18 Mar 1997 14:41:33 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 8549 Matt, > The reason for a separate IPv6 ethertype 86DD ... At first, I thought I was gonna embarrass myself attempting to compare our relative memories. :-) Luckily, however, my extended memory located something concrete. Thomas ------- Forwarded Message To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng 192) IPv6 ethertype, multicast address mapping, etc. Date: Fri, 16 Jun 1995 18:32:30 PDT From: Steve Deering Sender: owner-ipng@sunroof.Eng.Sun.COM At the ipng working group meeting this week in Mountain View, we had a long discussion about the ethertype issue, and came (with much reluctance, for some of us) to the conclusion that we should indeed use a new ethertype for IPv6 to avoid causing problems for existing, IP-version-challenged devices. According to what Dimitry could learn about the ST-2 deployment experience, the troublesome devices were mostly not-exactly-IP devices, such as bridges and in-line packet encryptors that know just enough about IP to be dangerous. Much as we hated the idea of having to be backwards-compatible with devices that wantonly violated the IP specs, we realized that we would harm IPv6 deployment much more than we would harm the vendors of those braindamaged devices if we were to stand on principles, in this case. Also, the main reason we originally changed SIP from using its own ethertype to using IP's ethertype and a new IP version number was to make it possible to implement SIP without modifying the link-layer drivers to demultiplex on a new ethertype -- in the PC world, some IP stack vendors do not have access to the source code of the link-level drivers over which their stack operates. However, the PC world seems to have settled on some standard driver APIs, such as NDIS, that enable arbitrary new ethertypes to be supported without driver code modification, so it's likely this is not as serious a problem as we originally thought. SO, IPv6 will henceforth use ethertype 86DD (which was originally assigned to SIP by Xerox, the authority for assigning ethertypes) on all links for which IPv4 framing uses ethertype 0800, whether plain (as on Ethernet) or fancy (as on other media that use the gratuitous SNAP header). IPv6 continues to have a version field which all IPv6 implementations are required to test for equality to the value 6. Thus, if you have an integrated IPv4/v6 stack, you may have both ethertypes 0800 and 86DD demultiplex to the same piece of code, which then later uses the IP version field to demultiplex to v4 or v6. However, the alternative implementation is also permitted, where packets are demuxed by ethertype to separate v4 and v6 stacks. Therefore, IPv6 implementations MUST use ethertype 86DD when transmitting IPv6 packets over links that use ethertypes. One nasty consequence of this decision is that we really ought to obtain new code points to identify IPv6 on those media that do not use ethertypes, such as PPP and X.25. Would anyone like to volunteer to do the legwork associated with getting an official code-point assignment for one or more of those non-ethertype-using media? ---- On another Ethernet-related topic, we have never specified how IPv6 multicast addresses are to be mapped to Ethernet multicast addresses. I believe that some of the prototype IPv6 implementations are curently using the same mapping as IPv4, that is, replacing the low-order 23 bits of the ethernet address 01-00-5E-00-00-00 with the low-order 23 bits of the IP multicast address. It would be nice to use a slightly more efficient mapping for IPv6 (extracting 23 bits is sorta fiddly). I propose the following: replace the low-order 32 bits of the ethernet address 33-33-00-00-00-00 with the low-order 32 bits of the IPv6 multicast address. The 33-33- prefix has both the Group (Multicast) bit set and the Locally Administered bit set. (They are the lowest-order and second lowest-order bits, respectively, of the first octet, in the canonical address representation.) It would be more politically correct to use a Universally Administered prefix, but those are handed out by the IEEE at $1000 per 24-bit chunk, which would mean we'd have to pay a quarter of a million dollars to get 32 bits of ethernet multicast address space, even though almost all the the 46 bits of total ethernet multicast address space is unused and will never be used. If we instead use the locally- administered space, we don't have to pay anyone, but we run the hazard of colliding with some other local usage of that 33-33- prefix. I suspect that such collisions are highly improbable (I did check the database of known ethernet address usage maintained at MIT, and there was no known conflict recorded there), but if anyone knows of any existing use of that prefix, please speak up -- I'd like to settle this question before the end of the month. By the way, this mapping would apply to Ethernet and FDDI, but *not* to Token Ring, where most host adapters have insufficient multicast address filtering to deal with proper multicast addresses. Instead, on Token Rings, IPv6 multicast addresses would all be mapped to the single "functional" address already allocated to IP, that is 03-00-00-20-00-00 in canonical form (see RFC 1469, IP Multicast over Token-Ring LANs). ---- Speaking of insufficient multicast address filtering, another issue we discussed at this week's ipng meeting was the problem that Geert Jan de Groot identified of inadequate PC ethernet interfaces. IPv6 depends on ethernet multicast, rather than ethernet broadcast, for basic functions like address resolution and router discovery. If I recall correctly, the problem was that some old ethernet cards for IBM PC compatibles can only choose to hear all multicasts or none. If IPv6 requires them to use multicast, then they will be vulnerable to reception of all multicast traffic, some of which (e.g., audio or video) might cause them to consume all their cycles discarding unwanted multicast in software. (The same problem would, of course, occur if anyone used the broadcast address for high data rate traffic.) We talked about the possibility of requiring a configuration switch in all IPv6 implementations to map some applications' IPv6 multicasts (such as those of the Neighbor Discovery protocol) onto the ethernet broadcast address, while other (high data rate) applications would continue to map to ethernet multicast addresses, but the consensus was that that was just too complicated, and ultimately unworkable (the notion of what is a high data rate app is just too ill-defined). So we decided against such a configuration option. Existing IPv4 implementations on those PCs should not be bothered by the presence of IPv6 traffic on the same ethernets, as long as the PCs continue to disable multicast reception; adding IPv6 to those machines will require an upgrade of their ethernet interfaces (more likely, the machines will be thrown out in a few years anyway, and their replacements ought to be able to handle IPv6 just fine). ---- We need to add IP-over- specifications to the IPv6 document set, starting with IP-over-Ethernet, to cover the issues discussed above plus other link-specific issues, such as how IPv6 link-local addresses and statelessly-autoconfigured addresses are formed on each type of link. Volunteers to write such specifications are invited to get in touch with the chairs and the document editor (rcallon@baynetworks.com, deering@parc.xerox.com, hinden@ipsilon.com). This stuff isn't the only stuff we talked about at the meeting -- we spent most of the time going through the new Neighbor Discovery and Stateless Autoconf docs, plus an initial foray into mobility and alternate unicast addressing plans. Notes from the full meeting are in preparation. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 12:06:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03380; Tue, 18 Mar 1997 11:53:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03373; Tue, 18 Mar 1997 11:53:41 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA21115; Tue, 18 Mar 1997 11:54:29 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA27513 for ; Tue, 18 Mar 1997 11:56:18 -0800 Received: from [128.3.9.22] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Tue, 18 Mar 1997 11:54:25 -0800 X-Sender: rlfink@cnrmail.lbl.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 18 Mar 1997 11:54:21 -0800 To: Matt Crawford From: Bob Fink LBNL Subject: (IPng 3338) slightly more info on 64-bit global IDs Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7007 Matt, This may be all the EUI-64 info I get from central IEEE resource folk, tho I'm still trying. Sorry for the folded lines, but they aren't very interesting :-) Bob =========================================================================== GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY General The IEEE defined 64-bit global identifier (EUI-64) is assigned by a manufacturer who has been assigned a company_id value by the IEEE Registration Authority. The 64-bit identifier is a concatenation of the 24-bit company_id value assigned by the IEEE Registration Authority and a 40bit extension identifier assigned by the organization with that company_id assignment. The IEEE administers the assignments of 24-bit company_id values. The assignments of these values are public, so that a user of a EUI-64 value can identify the manufacturer that provided any value. The IEEE/RAC has no control over the assignments of 40-bit extension identifiers and assumes no liability for assignments of duplicate EUI-64 identifiers assigned by manufacturers. Application restrictions Given the minimal possibilities for consuming EUI-64 identifiers, the IEEE/RAC places minimal restrictions on their use within standards. However, if used within the context of an IEEE standard, such documentation shall be reviewed by the IEEE/RAC for correctness and clarity. The IEEE/RAC shall not otherwise restrict the use of EUI-64 identifiers within standards. If the EUI-64 is referenced within non-IEEE standards, there shall not be any reference to IEEE unless approved by the IEEE/RAC. Distribution restrictions Given the minimal possibilities for consuming EUI-64 identifiers, the IEEE/RAC places minimal restrictions on their redistribution through third parties, as follows: a) Allocation. The EUI-64 values shall be sold within electronically-readable parts; no more than one EUI-64 value shall be contained within each component that is manufactured. b) Packaging. A component containing the EUI-64 value shall have a distinguishing characteristic (such as color or shape) to distinguish it from other commonly-used identifier components. c) Documentation. Readily available documentation (see following page). d) Legal indemnification. Any organization producing EUI-64 values shall indemnify the IEEE from damages arising from duplicate number assignments. The term EUI-64 is trademarked by the IEEE. Companies are allowed to use this term for commercial purposes, but only if their use of this term has been reviewed by the IEEE/RAC and the proposed products using the EUI64 conform to these restrictions. Application documentation As a condition for receiving a company_id assignment, a manufacturer of EUI-64 values accepts the following responsibilities: a) This documentation shall be readily available (at no cost) to any purchaser of EUI-64 values. b) The manufacturer's part specification should include an unambiguous description of how the EUI-64 value is accessed (pin and/or address descriptions). Manufacturer-assigned identifiers The manufacturer identifier assignment allows the assignee to generate approximately 1 trillion (1012) unique EUI-64 values, by varying the last 40 bits. The IEEE intends not to assign another OUI/company_id value to a manufacturer of EUI-64 values until the manufacturer has consumed, in product, the preponderance (more than 90%) of this block of potential unique words. It is incumbent upon the manufacturer to ensure that large portions of the unique word block are not left unused in manufacturing. ================================================================================ 64-BIT GLOBAL IDENTIFIER FORMAT TUTORIAL General The IEEE defined 64-bit global identifier (EUI-64) is assigned by a manufacturer who has been assigned a company_id value by the IEEE Registration Authority. The 64-bit identifier is a concatenation of the 24-bit company_id value assigned by the IEEE Registration Authority and a 40 bit extension identifier assigned by the organization with that company_id assignment. The IEEE administers the assignments of 24-bit company_id values. The assignments of these values are public, so that a user of a EUI-64 value can identify the manufacturer that provided any value. The IEEE/RAC has no control over the assignments of 40-bit extension identifiers and assumes no liability for assignments of duplicate EUI-64 identifiers. Format You may have a 64-bit global identifier (EUI-64) provided by an authorized manufacturer of these values (in the form of electronically-readable chips). The most-significant 24 bits of this value are the company_id value assigned to the manufacturer by the IEEE Registration Authority. The least-significant 40bit extension identifier is assigned by the manufacturer. For example, assume that a manufacturer's IEEE-assigned company_id value is ACDE4816 and the manufacturer's extension identifier is 234567ABCD16. The EUI-64 value generated from these two numbers is ACDE48234567ABCD16, whose byte and bit representations are illustrated below: most significant bit least significant bit A C D E 4 8 2 3 4 5 6 7 A B C D (hex) 1010 1100 1101 1110 0100 1000 0010 0011 0100 0101 0110 0111 1010 1011 1100 1101 (binary) most-significant byte least-significant byte A+0 A+1 A+2 A+3 A+4 A+5 A+6 A+7 (byte address) If provided in byte-addressable media, the original byte-address order of the manufacturer is specified: the most through least significant bytes of the EUI-64 value are contained within the lowest through highest byte addresses, as illustrated above. When transferred to other electronically-readable locations (within a disk file or network packet, for example) the relative ordering of the bytes may be changed, as specified within the applicable standard. Restricted and encapsulated values To support encapsulation of EUI-48 values within a small subset of the EUI-64 values, the first four digits of the manufacturer's extension identifier shall not be FFFF16 or FFFE16. Thus, the 64-bit values of the following form (where 'x' is a arbitrary hexadecimal digit) are never-assigned EUI-64 values: xxxxxxFFFFxxxxxx16 (an EUI-48 extension) ccccccFFFEeeeeee16 (reserved by IEEE/RAC) The letters 'c' and 'e' represent hexadecimal digits and show how the EUI-48 value can be unambiguously encapsulated within the EUI-64 value; the 'c' and 'e' digits represent the company_id and extension-identifier portions of the EUI-48 value respectively. - end ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 12:15:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA03396; Tue, 18 Mar 1997 12:02:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA03383; Tue, 18 Mar 1997 12:01:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA23640; Tue, 18 Mar 1997 12:02:27 -0800 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA00966 for ; Tue, 18 Mar 1997 12:04:12 -0800 Received: from ns3.BayNetworks.COM ([141.251.211.30]) by mailhost3.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP id PAA12826 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with SMTP id VAA28781 Posted-Date: Tue, 18 Mar 1997 21:00:23 +0100 (MET) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA29694; Tue, 18 Mar 97 15:00:20 EST Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA8758; Tue, 18 Mar 1997 15:00:13 -0500 Message-Id: <3.0.32.19970318150008.0068ffb8@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Mar 1997 15:00:09 -0500 To: Matt Crawford , ipng@sunroof.eng.sun.com From: Dimitry Haskin Subject: (IPng 3339) Re: Redefining the semantics of IPv6 Version field Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1661 At 12:36 PM 3/18/97 -0600, Matt Crawford wrote: >> The WG long-ago decided that each link-layer >> type would need its own demultiplexing key for IPv6 precisely because >> of the fear that some implementations would barf if an IPv6 packet >> were accidentally delivered to the IPv4 stack > >I recall that session. Or rather, I recall the July 17, 1995 13:00 >meeting at which notes from the interim meeting were presented. The >reason for a separate IPv6 ethertype 86DD was the existence of >certain IPv4 stacks on certain platforms (which coincidently have an >"86" in them) which do not have any crack to demultiplex based on the >IP version field. Hence no other version of IP can be added to those >platforms without demultiplexing at a lower level. > No, Matt. The implementation concern was not a decisive factor at all (though a separate code point for IPv6 made some implementations simpler and more efficient). The real factor was that there were a great number of IP devices that might fail when v6 packets showed up on links that they were attached too. This would make for one helluva v6 transition story as was painfully proven by the ST-II (aka IPv5) deployment experience. In the ST-II case a separate demux code point was hurriedly invented in the midst of the deployment. Isn't it nice that we as a group were able to learn from past mistakes? Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 13:25:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA03645; Tue, 18 Mar 1997 13:16:04 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA03638; Tue, 18 Mar 1997 13:15:22 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA08681; Tue, 18 Mar 1997 13:16:04 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA02010 for ; Tue, 18 Mar 1997 13:17:50 -0800 Received: from gungnir.fnal.gov ("port 38324"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGNHWRE5EO000KDK@FNAL.FNAL.GOV>; Tue, 18 Mar 1997 15:15:57 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA00033; Tue, 18 Mar 1997 15:15:57 -0600 Date: Tue, 18 Mar 1997 15:15:57 -0600 From: Matt Crawford Subject: (IPng 3340) Re: separate code point for v6 -- was Re: Redefining the semantics of IPv6 Version field In-reply-to: "18 Mar 1997 15:00:09 EST." <"3.0.32.19970318150008.0068ffb8"@pobox.engeast.baynetworks.com> To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Message-id: <199703182115.PAA00033@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ No, Matt. The implementation concern was not a decisive factor at all... Thanks to Dimitry and Thomas for the additional information. I was just going by my memory and notebook, which only included the lame monolithic pre-existing stack argument and an instruction to watch for the minutes (which never appeared). And remember, I didn't say it was a "wrong" or "bad" choice. I called it "impure." Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 13:30:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA03657; Tue, 18 Mar 1997 13:20:33 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA03647; Tue, 18 Mar 1997 13:19:48 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA09582; Tue, 18 Mar 1997 13:20:30 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA03935 for ; Tue, 18 Mar 1997 13:22:19 -0800 Received: from gungnir.fnal.gov ("port 38328"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGNI39N25C000KDK@FNAL.FNAL.GOV>; Tue, 18 Mar 1997 15:20:25 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA00073; Tue, 18 Mar 1997 15:20:11 -0600 Date: Tue, 18 Mar 1997 15:20:11 -0600 From: Matt Crawford Subject: (IPng 3341) Re: slightly more info on 64-bit global IDs In-reply-to: "18 Mar 1997 11:54:21 PST." <"v03007819af54a1de20b6"@[128.3.9.22]> To: Bob Fink LBNL Cc: ipng@sunroof.eng.sun.com Message-id: <199703182120.PAA00073@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03863; Tue, 18 Mar 1997 15:56:16 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03856; Tue, 18 Mar 1997 15:55:37 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA15168; Tue, 18 Mar 1997 15:56:20 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA01794 for ; Tue, 18 Mar 1997 15:58:12 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id SAA17620; Tue, 18 Mar 1997 18:45:10 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20566; Tue, 18 Mar 1997 18:45:09 -0500 Message-Id: <9703182345.AA20566@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3342) Re: Redefining the semantics of IPv6 Version field In-Reply-To: Your message of "Tue, 18 Mar 97 12:36:20 CST." <199703181836.MAA29402@gungnir.fnal.gov> Date: Tue, 18 Mar 97 18:45:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1848 >> The WG long-ago decided that each link-layer >> type would need its own demultiplexing key for IPv6 precisely because >> of the fear that some implementations would barf if an IPv6 packet >> were accidentally delivered to the IPv4 stack > >I recall that session. Or rather, I recall the July 17, 1995 13:00 >meeting at which notes from the interim meeting were presented. The >reason for a separate IPv6 ethertype 86DD was the existence of >certain IPv4 stacks on certain platforms (which coincidently have an >"86" in them) which do not have any crack to demultiplex based on the >IP version field. Hence no other version of IP can be added to those >platforms without demultiplexing at a lower level. Isn't truth interesting. >A side note, if I may ... > >I consider it SHOCKING that no published minutes of that interim >meeting are available, and that, furthermore, no published minutes of >the July 1995 ipngwg meetings are available. Uh... Good point...............history will want this too or if revists are necessary. As I could not get the IETF to add "rationale" to all specs as appendices keeping minutes will at least help. Also if we all stop working on IPv6 and the next generation of IPng WG begins they would know why we did what we did which may save them some time. That is why the IEEE specs have a req for rationale with any standard produced. Not because they are evil and slow. Its like putting comments in your code, telling your grand children where your parents came from, keeping a black book for single life, etc... /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 17:18:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04163; Tue, 18 Mar 1997 17:09:11 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04156; Tue, 18 Mar 1997 17:08:32 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA04139; Tue, 18 Mar 1997 17:09:15 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA01788 for ; Tue, 18 Mar 1997 17:11:08 -0800 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id UAA32331; Tue, 18 Mar 1997 20:03:47 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA28605; Tue, 18 Mar 1997 20:03:44 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id UAA04009; Tue, 18 Mar 1997 20:11:05 GMT Message-Id: <199703182011.UAA04009@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Bob Fink LBNL Cc: Matt Crawford , ipng@sunroof.eng.sun.com Subject: (IPng 3343) Re: slightly more info on 64-bit global IDs In-Reply-To: Your message of "Tue, 18 Mar 1997 11:54:21 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 1997 20:11:04 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1190 Even more stuff. http://www.amdahl.com/ext/CARP/FCA/FCA.html#Standard has lots of information about Fibre Channel. Interestly, there are 2 tutorials on how to use IEEE company_ids with SCSI and with FC. (they are available at ftp://playground.sun.com/pub/IEEEID/ as well). Some (anemic) web pages @ IEEE are: http://www.ieee.org -> "Standards" http://stdsbbs.ieee.org -> "IEEE Standards FAQs" http://stdsbbs.ieee.org/faqs/index.html -> "OUIs" to: http://stdsbbs.ieee.org/faqs/OUI.html I'm still hunting down more information... -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 18 21:09:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA04525; Tue, 18 Mar 1997 21:01:13 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA04518; Tue, 18 Mar 1997 21:00:33 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA00782; Tue, 18 Mar 1997 21:01:15 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA01607 for ; Tue, 18 Mar 1997 21:03:10 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA14354; Tue, 18 Mar 1997 23:54:47 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02232; Tue, 18 Mar 1997 23:54:46 -0500 Message-Id: <9703190454.AA02232@wasted.zk3.dec.com> To: Matt Crawford Cc: Bob Fink LBNL , ipng@sunroof.eng.sun.com Subject: (IPng 3344) Re: slightly more info on 64-bit global IDs In-Reply-To: Your message of "Tue, 18 Mar 97 15:20:11 CST." <199703182120.PAA00073@gungnir.fnal.gov> Date: Tue, 18 Mar 97 23:54:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 783 >Thanks again, Bob. While I was reading your message, my copy of the >IEEE 1212 spec arrived. Like 1394, it's another wrong alley. I >begin to wonder if this EUI-64(tm) is defined in any document, or >exists only by fiat form the IEEE/RAC. If this is true not only have we headed down the wrong alley I think we got mugged too. This has used up a lot of folks time in addition to Matt C. And may have sent us down the wrong path. As it appeared to be a way to get globally unique ESDs. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 19 08:08:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05008; Wed, 19 Mar 1997 07:59:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05001; Wed, 19 Mar 1997 07:58:32 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA26308; Wed, 19 Mar 1997 07:59:14 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA02202 for ; Wed, 19 Mar 1997 08:01:16 -0800 Received: from [128.3.9.22] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 19 Mar 1997 07:58:44 -0800 X-Sender: rlfink@cnrmail.lbl.gov Message-Id: In-Reply-To: <199703191546.JAA01582@gungnir.fnal.gov> References: "18 Mar 1997 20:11:04 GMT." <"199703182011.UAA04009"@whydos.lkg.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Mar 1997 07:58:41 -0800 To: Matt Crawford From: Bob Fink LBNL Subject: (IPng 3345) Re: slightly more info on 64-bit global IDs Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1492 Matt, At 7:46 AM -0800 3/19/97, Matt Crawford wrote: >> http://www.amdahl.com/ext/CARP/FCA/FCA.html#Standard has lots of information >> about Fibre Channel. Interestly, there are 2 tutorials on how to use >> IEEE company_ids with SCSI and with FC. (they are available at >> ftp://playground.sun.com/pub/IEEEID/ as well). > >I see by the last two or so pages (sections 9.5 and 10) that the >EUI-64 is *specified* by the "64-bit Global Identifier Tutorial," >which "will be available from the IEEE web site as final approval by >the IEEE-RAC takes place." Well, I suppose this document may be >identical with the "64-BIT GLOBAL IDENTIFIER FORMAT TUTORIAL" that >Bob posted yesterday, eh? Though we have little info on GUI-64 it doesn't change what the various newer IEEE interfaces are using it for, i.e., a bigger globally unique mac-level identifier. If toaster nets and other very cheap interfaces come into use (and using this GUI-64 id), it will increase the likelihood that IPv4 (and IPv6 as well) will be operating over it. So our need to incorporate this is just as valid (or invalid) as it was when this discussion started. Do you see any reason to not continue trying to accomodate it? Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 19 09:16:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05157; Wed, 19 Mar 1997 09:08:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05140; Wed, 19 Mar 1997 09:07:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA21618; Wed, 19 Mar 1997 09:08:39 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA05376 for ; Wed, 19 Mar 1997 09:10:39 -0800 Received: from gungnir.fnal.gov ("port 38533"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGONKCI0UM000JAV@FNAL.FNAL.GOV>; Wed, 19 Mar 1997 11:08:33 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id LAA01921; Wed, 19 Mar 1997 11:08:30 -0600 Date: Wed, 19 Mar 1997 11:08:30 -0600 From: Matt Crawford Subject: (IPng 3346) Re: slightly more info on 64-bit global IDs In-reply-to: "18 Mar 1997 11:54:21 PST." <"v03007819af54a1de20b6"@[128.3.9.22]> To: Bob Fink LBNL , mankin@isi.edu, matt@lkg.dec.com Cc: ipng@sunroof.eng.sun.com Message-id: <199703191708.LAA01921@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Restricted and encapsulated values > To support encapsulation of EUI-48 values within a small subset of the > EUI-64 values, the first four digits of the manufacturer's extension > identifier shall not be FFFF16 or FFFE16. Thus, the 64-bit values of the > following form (where 'x' is a arbitrary hexadecimal digit) are > never-assigned EUI-64 values: > > xxxxxxFFFFxxxxxx16 (an EUI-48 extension) > ccccccFFFEeeeeee16 (reserved by IEEE/RAC) > > The letters 'c' and 'e' represent hexadecimal digits and show how the > EUI-48 value can be unambiguously encapsulated within the EUI-64 value; the > 'c' and 'e' digits represent the company_id and extension-identifier > portions of the EUI-48 value respectively. But this document has (finally!) appeared on the IEEE web site as http://standards.ieee.org/db/oui/tutorials/EUI64.html, and in that text the roles of FFFF and FFFE are the opposite of the above! Arrgh. I guess I'll consider the text on the IEEE's site as authoritative. It also makes epsilon more sense, having the cccccc and eeeeee in the EUI-48 extension example, and the xxxxxx's in the reserved. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 19 09:47:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05244; Wed, 19 Mar 1997 09:39:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05237; Wed, 19 Mar 1997 09:38:46 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA29326; Wed, 19 Mar 1997 09:39:29 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA19796 for ; Wed, 19 Mar 1997 09:41:31 -0800 Received: from [128.3.9.22] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 19 Mar 1997 09:39:31 -0800 X-Sender: rlfink@cnrmail.lbl.gov Message-Id: In-Reply-To: <199703191708.LAA01921@gungnir.fnal.gov> References: "18 Mar 1997 11:54:21 PST." <"v03007819af54a1de20b6"@[128.3.9.22]> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 19 Mar 1997 09:39:27 -0800 To: Matt Crawford From: Bob Fink LBNL Subject: (IPng 3347) Re: slightly more info on 64-bit global IDs Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1681 At 9:08 AM -0800 3/19/97, Matt Crawford wrote: >Bob sent: >> Restricted and encapsulated values >> To support encapsulation of EUI-48 values within a small subset of the >> EUI-64 values, the first four digits of the manufacturer's extension >> identifier shall not be FFFF16 or FFFE16. Thus, the 64-bit values of the >> following form (where 'x' is a arbitrary hexadecimal digit) are >> never-assigned EUI-64 values: >> >> xxxxxxFFFFxxxxxx16 (an EUI-48 extension) >> ccccccFFFEeeeeee16 (reserved by IEEE/RAC) >> >> The letters 'c' and 'e' represent hexadecimal digits and show how the >> EUI-48 value can be unambiguously encapsulated within the EUI-64 value; the >> 'c' and 'e' digits represent the company_id and extension-identifier >> portions of the EUI-48 value respectively. > >But this document has (finally!) appeared on the IEEE web site as >http://standards.ieee.org/db/oui/tutorials/EUI64.html, and in that >text the roles of FFFF and FFFE are the opposite of the above! > > >Arrgh. I guess I'll consider the text on the IEEE's site as >authoritative. It also makes epsilon more sense, having the cccccc >and eeeeee in the EUI-48 extension example, and the xxxxxx's in the >reserved. I agree. Though it's pretty amazing they published it wrong and still were passing it around as of last week incorrectly! I'll tell Robinson to discard his paper copies. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 19 11:06:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05462; Wed, 19 Mar 1997 10:57:47 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05455; Wed, 19 Mar 1997 10:57:07 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA21067; Wed, 19 Mar 1997 10:57:50 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA25025 for ; Wed, 19 Mar 1997 10:59:54 -0800 Received: from gungnir.fnal.gov ("port 38536"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGORDV0UJ2000JAV@FNAL.FNAL.GOV>; Wed, 19 Mar 1997 12:57:51 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA02149; Wed, 19 Mar 1997 12:57:50 -0600 Date: Wed, 19 Mar 1997 12:57:50 -0600 From: Matt Crawford Subject: (IPng 3348) Re: slightly more info on 64-bit global IDs In-reply-to: "19 Mar 1997 07:58:41 PST." <"v03007807af55bc708aec"@[128.3.9.22]> To: Bob Fink LBNL Cc: ipng@sunroof.eng.sun.com Message-id: <199703191857.MAA02149@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Do you see any reason to not continue trying to accomodate it [EUI-64]? No reason whatsoever. I just wish the specifications were a bit more accessible! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 00:51:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA08591; Fri, 21 Mar 1997 00:44:48 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA08584; Fri, 21 Mar 1997 00:44:10 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA07529; Fri, 21 Mar 1997 00:44:54 -0800 Received: from gandalf.VIDEOPOLE.FR (gandalf.VIDEOPOLE.FR [195.25.50.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA07352 for ; Fri, 21 Mar 1997 00:47:20 -0800 Received: from h4aleche (SMTP.VIDEOPOLE.fr [195.25.50.8]) by gandalf.VIDEOPOLE.FR (post.office MTA v2.0 0813 ID# 0-29039U110) with ESMTP id AAA40 for ; Fri, 21 Mar 1997 09:47:07 +0100 From: "Alexandre CHERIF" To: Subject: (IPng 3349) First message Date: Fri, 21 Mar 1997 09:44:52 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19970321084707161.AAA40@SMTP.VIDEOPOLE.fr> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1019 hello, this is my first day in this list, i hope that every body, would not take care of my englih (pretty bad) i'm a little bit interested by IPng or IPv6, this is just for my information, i know well IPv4 but not IPv6, since yesterday i have print some documents (including rfc 1933). i got just some little question : - did anyone know when will begin the transition (if it has not begun) - where i can find other document about IPv6 implementation - did some try to run an OS with IPv6 implementation such as linux, or any other freeware/shareware OS i hope that my arrived in this list will not disturb anyone ps : i'm not an enigeneer or a professor in computing ; just a personal user. Hello from france regards ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 01:48:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA08645; Fri, 21 Mar 1997 01:40:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA08636; Fri, 21 Mar 1997 01:39:29 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA12461; Fri, 21 Mar 1997 01:40:14 -0800 Received: from aegir.EU.net (aegir.EU.net [193.242.90.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA21377 for ; Fri, 21 Mar 1997 01:42:39 -0800 Received: from aegir.EU.net (localhost.eu.net [127.0.0.1]) by aegir.EU.net (8.8.5/8.8.2) with ESMTP id KAA03748; Fri, 21 Mar 1997 10:40:10 +0100 (MET) Message-Id: <199703210940.KAA03748@aegir.EU.net> To: "Alexandre CHERIF" cc: ipng@sunroof.eng.sun.com Subject: (IPng 3350) Re: First message In-reply-to: Your message of "Fri, 21 Mar 1997 09:44:52 +0100." <19970321084707161.AAA40@SMTP.VIDEOPOLE.fr> From: James Aldridge Date: Fri, 21 Mar 1997 10:40:10 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1604 In message <19970321084707161.AAA40@SMTP.VIDEOPOLE.fr> you write: > hello, > > > this is my first day in this list, > i hope that every body, would not take care of my englih (pretty bad) > > i'm a little bit interested by IPng or IPv6, this is just for my > information, i know well IPv4 but not IPv6, since yesterday i have print > some documents (including rfc 1933). > > i got just some little question : > > - did anyone know when will begin the transition (if it has not begun) Take a look at the 6bone web pages: http://www-cnr.lbl.gov/6bone/ > - where i can find other document about IPv6 implementation > > - did some try to run an OS with IPv6 implementation such as linux, or any > other freeware/shareware OS Take a look at the IPv6 implementations web pages: http://playground.sun.com/pub/ipng/html/ipng-implementations and the IPng pages as a whole at http://playground.sun.com/pub/ipng/html/ipng-main.html Regards, James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 14:34:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09546; Fri, 21 Mar 1997 14:26:10 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09539; Fri, 21 Mar 1997 14:25:59 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA06376; Fri, 21 Mar 1997 14:26:48 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA22410 for ; Fri, 21 Mar 1997 14:29:20 -0800 Received: from gungnir.fnal.gov ("port 39432"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGRR9I1ZCE000OLH@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Fri, 21 Mar 1997 16:26:42 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA08324; Fri, 21 Mar 1997 16:26:42 -0600 Date: Fri, 21 Mar 1997 16:26:42 -0600 From: Matt Crawford Subject: (IPng 3351) revised IPv6-over-ethernet and -FDDI To: ipng@sunroof.eng.sun.com Message-id: <199703212226.QAA08324@gungnir.fnal.gov> MIME-version: (is)1(your).(UA)0(compliant?) Content-type: multipart/mixed; boundary=mimeprimaryboundary Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain I have just sent revised versions of IPv6-over-Ethernet and IPv6-over-FDDI to the internet-drafts editor. The changes involve using EUI-64 interface tokens, putting the bit-pictures into more usual formats, and the occasional small improvement in wording. For the impatient and the keenly interested, I include them below. Matt Crawford --mimeprimaryboundary Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipngwg-ethernet-ntwrks-03.txt" Content-Description: draft-ietf-ipngwg-ethernet-ntwrks-03.txt Content-Transfer-Encoding: quoted-printable IPng Working Group Matt Crawford Internet Draft Fermilab March 21, 1997 Transmission of IPv6 Packets over Ethernet Networks Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. 1. Introduction This memo specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on an Ethernet. 2. Maximum Transmission Unit The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on Expires September 21, 1997 Crawford [Page 1] =0C Internet Draft IPv6 Over Ethernet March 21, 1997 an Ethernet interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value MTU, if any, that MTU option must be ignored. 3. Frame Format IPv6 packets are transmitted in standard Ethernet frames. The Ethernet header contains the Destination and Source Ethernet addresses and the ethernet type code, which must contain the value 86DD hexadecimal. The data field contains the IPv6 header followed immediately by the payload, and possibly padding octets to meet the minimum frame size for Ethernet. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +- -+ | Ethernet | +- -+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +- -+ | Ethernet | +- -+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +- -+ | header | +- -+ | and | +- -+ / payload ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Each tic mark represents one bit.) 4. Stateless Autoconfiguration The interface token [CONF] for an Ethernet interface is the EUI-64 identifier [EUI64] derived from the interface's built-in 48-bit IEEE Expires September 21, 1997 Crawford [Page 2] =0C Internet Draft IPv6 Over Ethernet March 21, 1997 802 address. The OUI of the Ethernet address (the first three octets) becomes the company_id of the EUI-64 (the first three octets). The fourth and fifth octets of the EUI are set to the fixed value FFFE hexadecimal. The last three octets of the Ethernet address become the last three octets of the EUI-64. For example, the interface token for an Ethernet interface whose built-in address is, in hexadecimal and in canonical bit order, 34-56-78-9A-BC-DE would be 34-56-78-FF-FE-9A-BC-DE. A different MAC address set manually or by software should not be used to derive the interface token. An IPv6 address prefix used for stateless autoconfiguration of an Ethernet interface must have a length of 64 bits. 5. Link-Local Addresses The IPv6 link-local address [AARCH] for an Ethernet interface is formed by appending the interface token, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Token | +----------+-----------------------+----------------------------+ 6. Address Mapping -- Unicast The procedure for mapping IPv6 unicast addresses into Ethernet link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is Ethernet. Expires September 21, 1997 Crawford [Page 3] =0C Internet Draft IPv6 Over Ethernet March 21, 1997 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- Ethernet -+ | | +- Address -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 1 (in units of 8 octets). Ethernet Address The 48 bit Ethernet IEEE 802 address, in canonical bit order. This is the address the interface currently responds to, and may be different from the built-in address used to derive the interface token. 7. Address Mapping -- Multicast An IPv6 packet with a multicast destination address DST, consisting of the sixteen octets DST[1] through DST[16], is transmitted to the Ethernet multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[13] | DST[14] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[15] | DST[16] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Considerations Security considerations are not addressed in this memo. Expires September 21, 1997 Crawford [Page 4] =0C Internet Draft IPv6 Over Ethernet March 21, 1997 8. References [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing Architecture", RFC 1884. [CONF] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971. [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970. [EUI64] "64-Bit Global Identifier Format Tutorial", http://standards.ieee.org/db/oui/tutorials/EUI64.html. [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883. 9. Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 630 840-3461 EMail: crawdad@fnal.gov Expires September 21, 1997 Crawford [Page 5] --mimeprimaryboundary Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipngwg-fddi-ntwrks-05.txt" Content-Description: draft-ietf-ipngwg-fddi-ntwrks-05.txt Content-Transfer-Encoding: quoted-printable IPng Working Group Matt Crawford Internet Draft Fermilab March 21, 1997 Transmission of IPv6 Packets over FDDI Networks Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. 1. Introduction This memo specifies the MTU and frame format for transmission of IPv6 packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on an FDDI network. 2. Maximum Transmission Unit FDDI permits a frame length of 4500 octets (9000 symbols), including at least 22 octets (44 symbols) of Data Link encapsulation when long-format addresses are used. Subtracting 8 octets of LLC/SNAP Expires September 21, 1997 Crawford [Page 1] =0C Internet Draft IPv6 Over FDDI March 21, 1997 header, this would, in principle, allow the IPv6 [IPV6] packet in the Information field to be up to 4470 octets. However, it is desirable to allow for the variable sizes and possible future extensions of the MAC header and frame status fields. The default MTU size for IPv6 packets on an FDDI network is therefore 4352 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of a smaller value on each node. If a Router Advertisement is received with an MTU option specifying an MTU larger than the default or the manually configured value, that MTU option may be logged to system management but must be otherwise ignored. For purposes of this document, information received from DHCP is considered "manually configured". 3. Frame Format FDDI provides both synchronous and asynchronous transmission, with the latter class further subdivided by the use of restricted and unrestricted tokens. Only asynchronous transmission with unrestricted tokens is required for FDDI interoperability. Accordingly, IPv6 packets shall be sent in asynchronous frames using unrestricted tokens. The robustness principle dictates that nodes should be able to receive synchronous frames and asynchronous frames sent using restricted tokens. IPv6 packets are transmitted in LLC/SNAP frames, using long-format (48 bit) addresses. The data field contains the IPv6 header and payload and is followed by the FDDI Frame Check Sequence, Ending Delimiter, and Frame Status symbols. Expires September 21, 1997 Crawford [Page 2] =0C Internet Draft IPv6 Over FDDI March 21, 1997 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+ | FC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +- -+ | FDDI | +- -+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +- -+ | FDDI | +- -+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSAP | SSAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTL | OUI ... | +-+-+-+-+-+-+-+-+ + | ... OUI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +- -+ | header | +- -+ | and | +- -+ / payload ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Each tic mark represents one bit.) FDDI Header Fields: FC The Frame Code must be in the range 50 to 57 hexadecimal, inclusive, with the three low order bits indicating the frame priority. The Frame Code should be in the range 51 to 57 hexadecimal, inclusive, for reasons given in the next section. DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA hexadecimal, indicating SNAP encapsulation. Expires September 21, 1997 Crawford [Page 3] =0C Internet Draft IPv6 Over FDDI March 21, 1997 CTL The Control field shall be set to 03 hexadecimal, indicating Unnumbered Information. OUI The Organizationally Unique Identifier shall be set to 000000 hexadecimal. Ethertype The ethernet protocol type ("ethertype") shall be set to the value 86DD hexadecimal. 4. Interaction with Bridges 802.1d MAC bridges which connect different media, for example Ethernet and FDDI, have become very widespread. Some of them do IPv4 packet fragmentation and/or support IPv4 Path MTU discovery [PMTU], many others do not, or do so incorrectly. Use of IPv6 in a bridged mixed-media environment should not depend on support from MAC bridges. For correct operation when mixed media are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node which is connected to a medium with larger default MTU. Multicast packets on such a bridged network must not be larger than the smallest MTU of any of the bridged media. Often, the subnetwork topology will support larger unicast packets to be exchanged between certain pairs of nodes. To take advantage of high-MTU paths when possible, nodes transmitting IPv6 on FDDI should implement the following simple mechanism for "FDDI adjacency detection". A node which implements FDDI adjacency detection and has it enabled on an FDDI interface must set a non-zero LLC priority in all Neighbor Advertisement, Neighbor Solicitation and, if applicable, Router Advertisement frames transmitted on that interface. (In IEEE 802 language, the user_priority parameter of the M_UNITDATA.request primitive must not be zero.) If FDDI adjacency detection has been disabled on an FDDI interface, the priority field of those frames must be zero. Note that an IPv6 frame which originated on an Ethernet, or traversed an Ethernet, before being translated by an 802.1d bridge and delivered to a node's FDDI interface will have zero in the priority field, as required by [BRIDGE]. (There's a fine point here: a conforming bridge may provide a management-settable Outbound User Priority parameter for each port. However, the author is unaware of any product that provides this optional capability and, in any case, the default value for the parameter is zero.) Expires September 21, 1997 Crawford [Page 4] =0C Internet Draft IPv6 Over FDDI March 21, 1997 If a node N1 receives, in an FDDI frame with a non-zero LLC priority, a valid Router Advertisement, Neighbor Advertisement, or Neighbor Solicitation from a node N2, then N1 may send unicast IPv6 packets to N2 with sizes up to the default IPv6 FDDI MTU (4352 octets), regardless of any smaller MTU configured manually or received in a Router Advertisement MTU option. N2 may be the IPv6 destination or the next hop router to the destination. Nodes implementing FDDI adjacency detection must provide a configuration option to disable the mechanism. This option may be used when a smaller MTU is desired for reasons other than mixed- media bridging. By default, FDDI adjacency detection should be enabled. The only contemplated use of the LLC priority field of the FC octet is to aid in per-destination MTU determination. It would be sufficient for that purpose to require only that Router Advertisements, Neighbor Advertisements, and Neighbor Solicitations sent on FDDI always have non-zero priority. However, it may be simpler or more useful to transmit all IPv6 packets on FDDI with non-zero priority. 5. Stateless Autoconfiguration The interface token [CONF] for an FDDI interface is the EUI-64 identifier [EUI64] derived from the interface's built-in 48-bit IEEE 802 address. The OUI of the Ethernet address (the first three octets) becomes the company_id of the EUI-64 (the first three octets). The fourth and fifth octets of the EUI are set to the fixed value FFFE hexadecimal. The last three octets of the Ethernet address become the last three octets of the EUI-64. For example, the interface token for an Ethernet interface whose built-in address is, in hexadecimal and in canonical bit order, 34-56-78-9A-BC-DE would be 34-56-78-FF-FE-9A-BC-DE. A different MAC address set manually or by software should not be used to derive the interface token. An IPv6 address prefix used for stateless autoconfiguration of an FDDI interface must have a length of 64 bits. Expires September 21, 1997 Crawford [Page 5] =0C Internet Draft IPv6 Over FDDI March 21, 1997 6. Link-Local Addresses The IPv6 link-local address [AARCH] for an FDDI interface is formed by appending the interface token, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Token | +----------+-----------------------+----------------------------+ 7. Address Mapping -- Unicast The procedure for mapping IPv6 addresses into FDDI link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is FDDI. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- FDDI -+ | | +- Address -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option fields: Type 1 for Source Link-layer address. 2 for Target Link-layer address. Length 1 (in units of 8 octets). FDDI Address The 48 bit FDDI IEEE 802 address, in canonical bit order. This is the address the interface currently responds to, and may be different from the built-in address used as the address token. Expires September 21, 1997 Crawford [Page 6] =0C Internet Draft IPv6 Over FDDI March 21, 1997 8. Address Mapping -- Multicast An IPv6 packet with a multicast destination address DST, consisting of the sixteen octets DST[1] through DST[16], is transmitted to the FDDI multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[13] | DST[14] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[15] | DST[16] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9. Security Considerations Security considerations are not addressed in this memo. 10. Acknowledgments Erik Nordmark and Matt Thomas contributed to the method for interaction with bridges. 11. References [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing Architecture", RFC 1884. [BRIDGE]ISO/IEC 10038 : 1993 [ANSI/IEEE Std 802.1D] Media access control (MAC) bridges. [CONF] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971. [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970. [EUI64] "64-Bit Global Identifier Format Tutorial", Expires September 21, 1997 Crawford [Page 7] =0C Internet Draft IPv6 Over FDDI March 21, 1997 http://standards.ieee.org/db/oui/tutorials/EUI64.html. [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883. [PMTU] J. Mogul, S. Deering "Path MTU Discovery", RFC 1191. 12. Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 630 840-3461 EMail: crawdad@fnal.gov Expires September 21, 1997 Crawford [Page 8] --mimeprimaryboundary-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 14:56:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09580; Fri, 21 Mar 1997 14:48:25 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09573; Fri, 21 Mar 1997 14:48:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA11255; Fri, 21 Mar 1997 14:49:05 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA01010 for ; Fri, 21 Mar 1997 14:51:39 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id OAA18617 for ; Fri, 21 Mar 1997 14:49:06 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 14:48:44 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 3352) Re: IPv6 priority field usage? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 14323 At 11:59 AM -0800 3/5/97, I wrote: > Do you (or does anyone else) have any comments in favor or against such a > change? I guess I got my answer! :-) All 90 pages of it, when printed out. Having just reviewed all the postings on this topic (so far), I still think my proposal in San Jose is the right thing to do for now. Let me try to take this a piece at a time. (1) Per-Source Drop Priority I originally thought exactly the same as Petri Koskelainen, that drop priorities were a necessary feature to make layered audio&video work well. That's why the IPv6 Priority field is defined the way it is. My mind was changed by persuasive arguments by Steve McCanne and Van Jacobson, who wrote an excellent paper on best-effors multicast delivery of layered video that appeared in the SIGCOMM '96 Proceedings, a copy of which can be found at: ftp://ftp.ee.lbl.gov/papers/mccanne.sigcomm96.ps.gz They pointed out that, if the routers always drop packets from higher- fidelity layers before dropping any packets from lower layers, then (in the absence of per-packet charging, which we can't count on being imposed everywhere soon, if ever) there is no incentive for applications not to just send all the layers all the time. That's the easiest thing for them to do, and it always provides the "optimal" packet delivery from the point of view of the application. However, the harm in sending all layers all the time is that the undeliverable traffic (that is, traffic from the higher layers that will be dropped at a bottleneck router) consumes bandwidth on all the links up to the bottleneck router, bandwidth that might otherwise be productively used by other traffic (e.g., TCP traffic that backed off to make room for the video layers). If, on the other hand, packets from all layers are equally subject to loss at the bottleneck router, then there is the right incentive for an application to "turn off" undeliverable layers, because those layers contribute to the congestion that affects the base layer(s). (In the unicast case, turning layers on and off is accomplished by control messages from receiver to sender; in the multicast case, it is accomplished by the receiver joining and leaving multicast groups, where each layer is sent to a different multicast group address.) But, you say, without drop-priority, I may get loss in my base layer(s) that would not occur with a drop-priority scheme. Sure, but any application designed to run over best-efforts IP must be robust against some amount of loss anyway, whether by using frame interpolation, FEC, or whatever -- after all, there are causes of congestion *other* than competion with your own layers that you ought to be able to cope with. Finally, as several contributors have pointed out, there are significant concerns about the implementation complexity and negative performance consequences of requiring routers to do per-source drop-priority for best-efforts traffic. I think it's premature to argue that the complexity or performance hit is justified because it is on the same order as that needed anyway to support reserved (e.g., RSVP-style) flows -- it's quite likely that most traffic will continue to use unreserved, best-efforts service, such that the cost of keeping state for every best-efforts flow will be significantly, perhaps prohibitively, greater than keeping state for just the reserved flows. And on the performance side, customers are not likely to accept reduced packets-per-second performance for best-efforts traffic based on an argument that it is being penalized no more than reserved traffic. (2) End-to-End Absolute Priority I don't believe that a field that is set by a source application, that specifies the priority of a packet relative to all other packets regardless of source, and that routers are not permitted to overwrite, makes much sense. If routers actually gave preferential treatment to those packets marked at the source with higher priority, large numbers of people would patch their IP implementations to always send packets with the highest priority (and I expect this would be true in corporate "intranet" environments as well), thus defeating the purpose of the priority facility. The problem is: a simple small-integer priority field is not sufficient to authenticate that the sender of high-priority packets is authorized to receive preferential treatment. (Someone suggested the inverse approach, in which the default priority is the highest one and applications can choose to mark some of their packets with lower priority, but I think the time when we can depend on such "good Internet citizenship" is long past.) On the other hand, an absolute priority field that is *rewriteable* by routers seems, based on what people have said here and some existing practice, to be a valuable, maybe essential, tool for enforcing local policy and providing differential service within/across a domain. It does not suffer from the same problem of knowing who is authorized to get what priority -- that becomes a local decision based on such criteria as what interface a packet arrived on (e.g., the interface from the high-paying customer or the cut-rate customer) or whether a packet originated outside or inside the domain (e.g., so internal routing and management packets can be assured precedence over transitting data packets). (3) My proposed "Interactive" bit I proposed designating one header bit to indicate "interactive" traffic, that is, traffic for which delivery delay is more important than throughput, e.g., keystrokes, mouse clicks, RPC calls and returns, maybe compressed audio samples. This indication could be used by routers forwarding onto very slow links to promote the interactive traffic in front of other traffic for better reponsiveness. The assumption is that those routers that paid attention to that bit would, under congestion, bound the throughput of the interactive traffic to some fraction of the link bandwidth, to prevent starvation of the non-interactive traffic and to discourage sources from marking all of their packets as interactive. Thus, setting the bit indicates a willingness to give up one performance metric (throughput) to improve another (delay), rather than being a demand for absolute priority over all other traffic. I think of the Interactive bit as a distillation of the 3 IPv4 TOS bits (Low Delay, High Throughput, High Reliability) -- if we think of the default service as High Throughput, and that all links must have adequately reliability (accomplished through link-layer means for those links not naturally highly reliable), then we need only one bit to select the Low Delay service instead of the High Throughput service. In my original proposal, I suggested that the Interactive bit be rewritebale by routers, but suggested that they touch that bit only as a last resort, when the three other bits are not sufficient for their purposes. The downside of allowing the Interactive bit to be rewriteable is that it can only be used to influence the queueing of a packet, not the routing of a packet, to avoid the looping hazard. I had thought that TOS routing was basically dead, but Fred mentioned that TOS routing is actually getting some use these days, and if geo-synch satellites actually start providing significant bandwidth competition to terrestrial links, TOS routing might finally find its place (e.g., to keep interactive traffic on the ground, while letting high volume traffic be routed over a satellite path when its throughput is greater than the alternative terrestrial path). So I'm now wondering whether we should mandate that the Interactive bit be purely end-to-end, i.e., not subject to router rewrite, or at least include a big warning that the Interactive bit must not be rewritten by anyone who has not taken steps to assure that such a rewrite will not cause packet loops. Comments?? (4) Bitwise-encoding vs. Integer-encoding of the "Priority" bits For the three IPv6 Priority bits other than the Interactive bit, John Stewart suggested that they be specified as a 3-bit integer, from 000 (lowest) to 111 (highest). I think it is more flexible to leave that undefined, in case some ISPs wish to use them in other ways, e.g., a single "Clark bit" plus a 2-bit priority integer. Can that not be left as a local (to a routing domain) decision? As far as building support for priority into routers, a configurable mapping from each possible bit pattern to a specific queue or behavior module would be able to cope with a variety of uses. Also, in case it's not obvious, my proposal does not eliminate the need to have an API function that lets a source set any of the Priority bits. (5) Expanding the number of "free bits" in the IPv6 Header Yes, we could consider poaching on the Version field or the Flow Label field to get more router-writeable bits, if someone had a persuasive argument that we need more bits. As long as we leave the Version field out of the AH authenticator, which I think we should do, a transit domain could safely diddle with the version bits, as long as they were restored on exit from the domain, without us needing to saying anything about that in the specs. I'm a bit reluctant to just undefine the Version field, if for no other reason than to avoid the tedious debate on renaming the protocol to something other than IPv6. (6) Responses to some specific points made on the mailing list > From: "John W. Stewart III" > > providers today depend on the precedence bits to separate > control traffic from user traffic. that assumes a > consistent interpretation of the bits. Only within one provider's cloud, right? > either way, saying that the bits are rewritable is the > important piece. and to be clear, if the bits are being > used to control queueing within a router, then the bits > are *going* to be stomped on. e.g., router requirements > currently says that the bits should *not* be changed... There isn't an IPv6 Routers Requirements spec. (Yet.) > From: "Steven M. Bellovin" > > It is worth mentioning here something that's take for granted in the > ipsec group: changing anything in a packet interacts poorly with > cryptography. > In particular, AH (currently RFC 1826, though it's being rewritten) > specifies that most of the preceeding IP header is included in the AH > checksum calculation. Some fields are explicitly excluded (TTL is the > obvious one), but if such changes are necessary, we need to know *now*. Yes, we understand that -- that was one of the issues I identified in my proposal. But when I brought it up, someone pointed out that the ipsec group had in fact decided to (or was considering a proposal to) exclude the IPv6 Version, Priority, and Flow Label fields from the AH calculation, and I was shown an ipsec draft that said that. Just as you warn us of the importance of consulting with ipsec before making such changes, I was rather peeved that the ipsec WG had not consulted with the ipng WG before considering such a change. > (There are also some requirements on the Precedence field in rfc793; at > the very least, a statement of interpretation is going to be needed if > anything can diddle those bits as a matter of course.) So, what was the outcome for IPv4: is the Precedence field included or excluded from the AH calculation? > Btw -- the question of whether or not the IP header should be included in > the AH checksum was discussed at very great length (and of course, very great > volume) in the ipsec group. For better or worse, though, the question is > considered settled now; I don't think we want to reopen it. But is the identification of exactly which fields of the IP header are excluded settled at this point? Should we beleive the RFC or the more recent draft? > From: Koskelainen Petri > > Fair share of resources should not be very difficult (router designers > can correct me if I'm wrong) to guarantee in modern routers. I'm not a router designer (yet), but I've been assured that it is actually quite difficult/expensive to provide true fair sharing of resources, even assuming you could get everyone to agree on what the granularity of fairness should be (per source? per source-destination pair, per transport-layer-flow?). Managing the book-keeping state (e.g., allocating/freeing per-share records as flows come and go) can be a significant extra burden in the fast path of a router. There are statistical approximations to fair sharing that ameliorate some of the state handling expense, but still impose significant costs on high-speed routers. > From: Steven L Blake > > Proposed semantics for the IPv6 Priority field 12-Mar-97 > > > +---+---+---+---+ > | H | R | D | I | 4-bit IPv6 Priority field > +---+---+---+---+ This is a fine proposal, and perhaps we will evolve to usage similar to what Steven proposes. However, what I am trying to do is get *less* concrete, and to specify as little as possible about the semantics of the Priority field, so that the community and the industry is given maximum freedom to experiment. It is clear from what Fred and others have said that this whole area of Precedence/ToS/QoS/CoS is very much in flux these days, and people are experimenting with a number of different schemes in the IPv4 world. I think it's premature for us to be nailing down precise semantics until more experience has been gained. > From: rstevens@kohala.com (W. Richard Stevens) > > There is one other use of the IPv4 priority field that has not been > mentioned. The SLIP and PPP drivers in 4.4BSD stacks look at the > TOS, and if it's low-delay, put the outgoing packet onto the "fast > queue" instead of the normal output queue. That's what my Interactive bit is for. -------- End of my comments. Sorry for the long-winded message -- I'm using high response volume to try to make up for long response delay. :-) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 15:07:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09628; Fri, 21 Mar 1997 14:57:14 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09621; Fri, 21 Mar 1997 14:57:03 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA13241; Fri, 21 Mar 1997 14:57:52 -0800 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA04133 for ; Fri, 21 Mar 1997 15:00:26 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id OAA19182; Fri, 21 Mar 1997 14:56:37 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199703171621.KAA26578@gungnir.fnal.gov> References: "17 Mar 1997 10:35:51 EST." <"9703171535.AA16451"@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 14:56:15 -0800 To: Matt Crawford From: Steve Deering Subject: (IPng 3353) Re: Proposed IPv6 Priority Field Semantics Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 542 At 8:21 AM -0800 3/17/97, Matt Crawford wrote: > > IMHO, alloting a separate ethertype for IPv6 was one of the most > impure things the IPNGWG did. IMHO, adding an IP version number field to SIP was one of the most impure things the SIP WG did. :-) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 15:23:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA09679; Fri, 21 Mar 1997 15:14:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA09672; Fri, 21 Mar 1997 15:14:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA16997; Fri, 21 Mar 1997 15:15:12 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA10477 for ; Fri, 21 Mar 1997 15:17:46 -0800 Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id SAA12051; Fri, 21 Mar 1997 18:06:18 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA01711; Fri, 21 Mar 1997 18:06:15 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id SAA01230; Fri, 21 Mar 1997 18:16:38 GMT Message-Id: <199703211816.SAA01230@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3354) Re: revised IPv6-over-ethernet and -FDDI In-Reply-To: Your message of "Fri, 21 Mar 1997 16:26:42 CST." <199703212226.QAA08324@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 1997 18:16:37 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1307 > For example, the interface token for an Ethernet interface whose > built-in address is, in hexadecimal and in canonical bit order, > > 34-56-78-9A-BC-DE > > would be > > 34-56-78-FF-FE-9A-BC-DE. That makes the multicasts a little random since the first will always be fixed. In a previous message (that was either incomprehensible or ignored), I suggest doing. FF-FE-34-56-78-9A-BC-DE In other we mangle the EUI-64 in a constant way to maximize variation in the last 4 bytes. If you were using FireWire (1394) with an EUI-64 of 34-56-78-01-23-9A-BC-DE That would create a link token of 01-23-34-56-78-9A-BC-DE That my 2 cents worth... -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 16:10:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09800; Fri, 21 Mar 1997 16:02:19 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09793; Fri, 21 Mar 1997 16:02:11 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA27540; Fri, 21 Mar 1997 16:03:00 -0800 Received: from fontina.cisco.com (fontina.cisco.com [171.69.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA27873 for ; Fri, 21 Mar 1997 16:05:35 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by fontina.cisco.com (8.6.12/8.6.5) with ESMTP id QAA22788; Fri, 21 Mar 1997 16:03:00 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA07146; Fri, 21 Mar 1997 16:00:06 -0800 (PST) Date: Fri, 21 Mar 1997 16:00:06 -0800 (PST) Message-Id: <199703220000.QAA07146@pedrom-ultra.cisco.com> From: Pedro Marques To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3355) revised IPv6-over-ethernet and -FDDI In-Reply-To: <199703212226.QAA08324@gungnir.fnal.gov> References: <199703212226.QAA08324@gungnir.fnal.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 667 >>>>> "Matt" == Matt Crawford writes: Matt> 4. Stateless Autoconfiguration Matt> The interface token [CONF] for an Ethernet interface is Matt> the EUI-64 identifier [EUI64] derived from the interface's Matt> built-in 48-bit IEEE Questions: 1) Why ? 2) What advantage does that bring to all the 802.3 networks out there ? regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 22:30:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10075; Fri, 21 Mar 1997 22:20:44 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10068; Fri, 21 Mar 1997 22:20:30 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA10266; Fri, 21 Mar 1997 22:21:15 -0800 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA06356 for ; Fri, 21 Mar 1997 22:23:54 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by stilton.cisco.com (8.6.12/8.6.5) with ESMTP id WAA11611; Fri, 21 Mar 1997 22:21:15 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 21:05:10 -0800 To: Steve Deering From: Fred Baker Subject: (IPng 3356) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4042 At 2:48 PM -0800 3/21/97, Steve Deering wrote: >(3) My proposed "Interactive" bit > >I think of the Interactive bit as a distillation of the 3 IPv4 TOS bits >(Low Delay, High Throughput, High Reliability) -- if we think of the >default service as High Throughput, and that all links must have adequately >reliability (accomplished through link-layer means for those links not >naturally highly reliable), then we need only one bit to select the Low >Delay service instead of the High Throughput service. >routing was basically dead, but Fred mentioned that TOS routing is actually >getting some use these days, and if geo-synch satellites actually start >providing significant bandwidth competition to terrestrial links, TOS >routing might finally find its place (e.g., to keep interactive traffic on >the ground, while letting high volume traffic be routed over a satellite >path when its throughput is greater than the alternative terrestrial path). Actually, one of the people I hear talking about it the most wants to reroute IP Multicast over a satellite as a way of getting wide geographic distribution with minimal variance in delay between recievers... >So I'm now wondering whether we should mandate that the Interactive bit be >purely end-to-end, i.e., not subject to router rewrite, or at least include >a big warning that the Interactive bit must not be rewritten by anyone who >has not taken steps to assure that such a rewrite will not cause packet >loops. Comments?? I would suggest that it should be rewritable, unless you can demonstrate that policy enforced by something other than the originating host would in fact destroy its utility. >For the three IPv6 Priority bits other than the Interactive bit, John >Stewart suggested that they be specified as a 3-bit integer, from 000 >(lowest) to 111 (highest). I think it is more flexible to leave that >undefined, in case some ISPs wish to use them in other ways, e.g., a single >"Clark bit" plus a 2-bit priority integer. Can that not be left as a local >(to a routing domain) decision? As far as building support for priority >into routers, a configurable mapping from each possible bit pattern to a >specific queue or behavior module would be able to cope with a variety of >uses. IMHO, leaving them to local definition removes the possibility of global utility. I think you should order their values, but leave the implementation of the levels of service to the implementor and adminsitration. >> providers today depend on the precedence bits to separate >> control traffic from user traffic. that assumes a >> consistent interpretation of the bits. > >Only within one provider's cloud, right? not necessarily. For example, Cisco Routers during a route flap will, if necessary, summarily discard all traffic that is not priority 7, believing that priority 7 traffic is necessary to sustain routing. The use of the maximum value to signify "critical to network layer functionality" is a global definition, and a useful one. I have also recommended to the VoIP Forum that it might be useful for them to consider the use of IP Precedence rather than RSVP for voice flows. Dramatically reduces the amount of state an IS Router must carry - but it depends on an end to end undersyanding that higher numeric value means higher precedence. >So, what was the outcome for IPv4: is the Precedence field included or >excluded from the AH calculation? excluded >But is the identification of exactly which fields of the IP header are >excluded settled at this point? Should we beleive the RFC or the more >recent draft? the draft =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don't set off nuclear weapons in Chino, California - there's a $500 fine ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 21 22:30:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10086; Fri, 21 Mar 1997 22:21:09 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA10077; Fri, 21 Mar 1997 22:20:55 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA10312; Fri, 21 Mar 1997 22:21:43 -0800 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA06440 for ; Fri, 21 Mar 1997 22:24:22 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by stilton.cisco.com (8.6.12/8.6.5) with ESMTP id WAA11608; Fri, 21 Mar 1997 22:21:12 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <9703171319.ZM7077@seawind.bellcore.com> References: bound@zk3.dec.com "Re: (IPng 3310) Re: Proposed IPv6 Priority Field Semantics" (Mar 17, 12:16pm) <9703171716.AA27481@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 20:29:22 -0800 To: huitema@bellcore.com (Christian Huitema) From: Fred Baker Subject: (IPng 3357) Re: Proposed IPv6 Priority Field Semantics Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 921 At 1:19 PM -0500 3/17/97, Christian Huitema wrote: >For example, you quote both RSVP and label >switching as possible usages, but these two are contradictory -- RSVP >requires end to end labels, label switching probably requires labels to be >rewritten when you pass network boundaries... > >Then, in the case of RSVP, I know how we can use the flow-ids. Pass them >in the PATH messages, use them in the RSVP. RSVP takes its definition of IP6 flows from IP6, not the other way around. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don't set off nuclear weapons in Chino, California - there's a $500 fine ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sat Mar 22 05:34:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA10411; Sat, 22 Mar 1997 05:26:29 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA10404; Sat, 22 Mar 1997 05:26:21 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA01459; Sat, 22 Mar 1997 05:27:11 -0800 Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA16131 for ; Sat, 22 Mar 1997 05:29:53 -0800 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id IAA03654 for ipng@sunroof.Eng.Sun.COM; Sat, 22 Mar 1997 08:25:28 -0500 (EST) Date: Sat, 22 Mar 1997 08:25:28 -0500 (EST) From: Scott Bradner Message-Id: <199703221325.IAA03654@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 3358) Re: IPv6 priority field usage? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 407 >So, what was the outcome for IPv4: is the Precedence field included or >excluded from the AH calculation? excluded Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sat Mar 22 11:53:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10596; Sat, 22 Mar 1997 11:45:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10589; Sat, 22 Mar 1997 11:45:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA00125; Sat, 22 Mar 1997 11:46:06 -0800 Received: from mail.ton.tut.fi (mylly.ton.tut.fi [193.166.80.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA26714 for ; Sat, 22 Mar 1997 11:48:52 -0800 Received: from localhost (veikko@localhost) by mail.ton.tut.fi (8.8.0/8.8.0) with SMTP id VAA20004 for ; Sat, 22 Mar 1997 21:46:04 +0200 (EET) Date: Sat, 22 Mar 1997 21:46:01 +0200 (EET) From: Harri Hakulinen Reply-To: Harri Hakulinen To: ipng@sunroof.eng.sun.com Subject: (IPng 3359) Re: IPv6 priority field usage? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4687 On Fri, 21 Mar 1997, Steve Deering wrote: > (1) Per-Source Drop Priority > I originally thought exactly the same as Petri Koskelainen, that drop > priorities were a necessary feature to make layered audio&video work well. > That's why the IPv6 Priority field is defined the way it is. My mind was It is not only layered video, that needs drop priority. In moust cases there is kind of "header" information and "bulk data" in same layer video stream. And if you lost packet, that contains certain "header" information, you don't have any use for "bulk data". Of course, you can send (all)headers with every packet and so on, but that is not very elegant way to save bandwith. Brobably biggest difference to current Internet applications (excluding iphone) is that there is no time to do retransmissions (TCP style), if something important is missing... > changed by persuasive arguments by Steve McCanne and Van Jacobson, who > wrote an excellent paper on best-effors multicast delivery of layered video > that appeared in the SIGCOMM '96 Proceedings, a copy of which can be found > at: > ftp://ftp.ee.lbl.gov/papers/mccanne.sigcomm96.ps.gz Very nice paper and work. List of references was also very interesting, but almoust unusable without URLs (of course, many of them are not even available). Similar method probably works also in unicast (UDP/RTP) case bethween sender and receiver. And this works even better, if sender knows that at least someone listens to each layer, so some kind of signaling/sessions should be used also in multicast case. But, it seems that their work was mostly based on simulation. I belive, that if they try this with real video streams, they can immediately SEE in the screen what happens when someone adds a new layer and congested router begins to drop packets in_random_way from _all_layers_. The effect is exactly the same, that you can see with current video tools over internet: In moust cases picture is unusable (very bad or stopped) when packets are dropped (in random way). My comment is, that this is fine method, but you still need drop priority (at least one bit, only for application) to smooth things and help router to make right decisions. This kind of algorithm is not fast enough alone. One bit might be enough, if we assume that there is not very many packets from same flow in the router buffer anyway (as Fred pointed out some time ago) and it is too costly to maintain state for almoust all best-effort flows. Routers should use this bit as a guide to find packets, that should be dropped first (because something must be dropped anyway and applications know, what makes smallest possible harm to them). I still think, that several levels/bits for drop priority would be usable, but that might be more in the scope of new RSVP traffic class or something similar (because routers probably need help to identify those kind of flows and because similar state information is needed). > (Someone suggested the inverse approach, in which the default priority is > the highest one and applications can choose to mark some of their packets > with lower priority, but I think the time when we can depend on such "good > Internet citizenship" is long past.) I think I did that. My point was, that if everyone knows, that packets are dropped anyway, setting drop priority (lower value) for some packets means that I can increase probability that my high priority packets can go thru. In my mind that still works better than on other way (if it is sender based). Fred Baker wrote: >I have also recommended to the VoIP Forum that it might be useful for them >to consider the use of IP Precedence rather than RSVP for voice flows. >Dramatically reduces the amount of state an IS Router must carry - but it >depends on an end to end undersyanding that higher numeric value means >higher precedence. I belive that similarly we must found methods to handle Videophone over IP case. There is almoust as much potential users as for voice only case, but consumed bandwith is bigger. I think that this application area is going to explode within two years and it may cause some unhappy side-effects to current internet (with increasing amount of iphones). For upcoming IPv6 internet there still seems to be time to do something for that. - Harri.Hakulinen@research.nokia.com Video laboratory/Network & Terminal technologies Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Sat Mar 22 16:19:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA10785; Sat, 22 Mar 1997 16:12:05 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA10778; Sat, 22 Mar 1997 16:11:56 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA14813; Sat, 22 Mar 1997 16:12:46 -0800 Received: from safetnet.cit.cornell.edu (SAFETNET.CIT.CORNELL.EDU [132.236.172.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA26575 for ; Sat, 22 Mar 1997 16:15:35 -0800 Received: by safetnet.cit.cornell.edu (1.37.109.23/16.2) id AA173155930; Sat, 22 Mar 1997 19:12:10 -0500 Date: Sat, 22 Mar 1997 19:12:10 -0500 (EST) From: Rachit Siamwalla X-Sender: rs55@safetnet.cit.cornell.edu To: Harri Hakulinen Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3360) Re: IPv6 priority field usage? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3783 > It is not only layered video, that needs drop priority. In moust cases > there is kind of "header" information and "bulk data" in same layer > video stream. And if you lost packet, that contains certain "header" > information, you don't have any use for "bulk data". Of course, you can > send (all)headers with every packet and so on, but that is not very > elegant way to save bandwith. There are several ways to solve that problem, like if the header is small, send it a number of times proportional to the current loss packet rate. I have implemented a simple streaming MPEG video system and this seems to work fine. True, it is not elegant, but it doesn't waste that much bandwith and I think it is a better solution than adding priority bits for several reasons: 1. Adding priority bits will waste bandwith all the way up to the bottleneck router (on the paper by McCanne and Van Jacobson). 2. Adding priority bits will add complexity to router design that is unnecessary. I am not a router expert, but I assume having several priorities makes you have to have several queues and several queue implementation means more cost especially when done in hardware. Router people will not implement priority, because it is an 'extra' feature, and will not affect them too much. Correct me if I am wrong, but I also read somewhere that the TOS bits in IPv4 are not looked at at all by most routers. The TOS bits are very closely related to the prioirity bits in IPv6, so if they are not dealt with now in IPv4, why will they be in IPv6? 3. If you add priority bits people will always put thier packets to the highest priority. The argument that if you set some of your packets with low prioirity that your high prioirty packets will have a higher chance of getting through is not entirely true. If you have large numbers of people sharing the network with you (which will be the case when packets start getting dropped), your low priority packets will be a 'drop' in the bucket when the time comes for packets to be dropped. So you would set all your packets to high prioirity to get all your packets through for free. Basic economics principle says that if there is a free resource, people will use as much as they can of it. The only way for people to be honest with thier priority is to implement more sophisticated queueing techniques in routers, like weighted fair queuing or something like that. However, that also means more cost and a pain in the butt for routers. 4. Retransmission of important frames is not out of the question. If the delay jitter is not too large, and set your timeouts low enough, you can get decent video. I mean, if the probability of a packet being dropped is p, if you retransmit, you get the probably of losing it to be p squared which is very good, especially when p is small to begin with. On my MPEG system, single retransmission gave great picture quality over straight UDP. (1 percent loss rate in I frames over 10 percent with straight UDP). With a good imlementation, the latency should be within 4 times the normal latency (I was not able to test this in my system). That is acceptable in Intranets and should work with nearby nodes in the internet. > should be dropped first (because something must be dropped anyway and > applications know, what makes smallest possible harm to them). This is exactly what I am saying. The applications know is going on, so let the problem be dealt with in the higher layers. Rachit Siamwalla ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 07:16:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12309; Mon, 24 Mar 1997 07:06:46 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12302; Mon, 24 Mar 1997 07:06:35 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04849; Mon, 24 Mar 1997 07:07:24 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA07428 for ; Mon, 24 Mar 1997 07:10:37 -0800 Received: from gungnir.fnal.gov ("port 39509"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGVISVUB7O000QOY@FNAL.FNAL.GOV>; Mon, 24 Mar 1997 09:07:25 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA12317; Mon, 24 Mar 1997 09:07:23 -0600 Date: Mon, 24 Mar 1997 09:07:23 -0600 From: Matt Crawford Subject: (IPng 3361) Re: revised IPv6-over-ethernet and -FDDI In-reply-to: "21 Mar 1997 18:16:37 GMT." <"199703211816.SAA01230"@whydos.lkg.dec.com> To: Matt Thomas Cc: ipng@sunroof.eng.sun.com Message-id: <199703241507.JAA12317@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ idea of 64-bit End System Designators, I wrote: > > For example, the interface token for an Ethernet interface whose > > built-in address is, in hexadecimal and in canonical bit order, > > 34-56-78-9A-BC-DE > > would be > > 34-56-78-FF-FE-9A-BC-DE. And Matt Thomas said > That makes the multicasts a little random since the first will always > be fixed. In a previous message (that was either incomprehensible or > ignored), I suggest doing. > FF-FE-34-56-78-9A-BC-DE It's true that doing the IEEE-defined mapping of MAC to EUI-64, and then using the EUI-64 as-is as the ESD would cause there to be only three variable octets in the MAC address to which a nodes solicited- node multicast address is mapped. This could be bad, because duplicate solicited-node MAC addresses would be more common, or good, because now there's a range of multicast addresses which heavy multicast sources can be instructed to avoid, to get the least chance of accidently swamping some low-powered node's interface with multicasts it doesn't want. One of the co-chairs recently sent around a list of unfinished action items, and one of those was for the two chairs to put out a proposal to length the solicited-node prefix. Despite two queries from me, further details have not been forthcoming. I'm guessing the purpose of lengthening the prefix is to achieve the same good effect I mentioned above. If that prefix is lengthened by 8 bits or more, shuffling the EUI-64 octets would then serve no purpose that I can see. So I'm going to defer consideration of that point. Matt Crawford ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 07:24:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12318; Mon, 24 Mar 1997 07:13:31 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12311; Mon, 24 Mar 1997 07:13:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06586; Mon, 24 Mar 1997 07:14:06 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA10052 for ; Mon, 24 Mar 1997 07:17:18 -0800 Received: from gungnir.fnal.gov ("port 39513"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGVJ16F6KM000QOY@FNAL.FNAL.GOV>; Mon, 24 Mar 1997 09:14:06 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA12349; Mon, 24 Mar 1997 09:14:05 -0600 Date: Mon, 24 Mar 1997 09:14:05 -0600 From: Matt Crawford Subject: (IPng 3362) Re: revised IPv6-over-ethernet and -FDDI In-reply-to: "21 Mar 1997 16:00:06 PST." <"199703220000.QAA07146"@pedrom-ultra.cisco.com> To: Pedro Marques Cc: ipng@sunroof.eng.sun.com Message-id: <199703241514.JAA12349@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ >>>>> "Matt" == Matt Crawford writes: > Matt> 4. Stateless Autoconfiguration > Matt> The interface token [CONF] for an Ethernet interface is > Matt> the EUI-64 identifier [EUI64] derived from the interface's > Matt> built-in 48-bit IEEE > Questions: > 1) Why ? > 2) What advantage does that bring to all the 802.3 networks out there ? This is a result of the tentative decision to use a globally-unique* 64-bit "end system designator" as the second half of an IPv6 address. This was one of the features of O'Dell's GSE that the PAL1 meeting felt was desirable and feasible. You can be sure it will be discussed in Memphis. Matt * Or, as unique as humanly possible. I don't want to go into that now! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 07:32:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12357; Mon, 24 Mar 1997 07:21:18 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12350; Mon, 24 Mar 1997 07:21:03 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA08905; Mon, 24 Mar 1997 07:21:54 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA13251 for ; Mon, 24 Mar 1997 07:25:03 -0800 Received: from rtpdce02.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA37892; Mon, 24 Mar 1997 10:21:45 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id KAA61752; Mon, 24 Mar 1997 10:21:45 -0500 Received: from lig32-225-17-136.us.lig-dial.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17082; Mon, 24 Mar 1997 10:21:14 -0500 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id KAA00587; Mon, 24 Mar 1997 10:20:37 -0500 Message-Id: <199703241520.KAA00587@hygro.raleigh.ibm.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3363) Re: IPv6 priority field usage? In-Reply-To: Your message of "Fri, 21 Mar 1997 14:48:44 PST." Date: Mon, 24 Mar 1997 10:20:37 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2672 Steve, > So I'm now wondering whether we should mandate that the Interactive > bit be purely end-to-end, i.e., not subject to router rewrite, or at > least include a big warning that the Interactive bit must not be > rewritten by anyone who has not taken steps to assure that such a > rewrite will not cause packet loops. Comments?? I would think that the Interactive bit must be end-to-end (and not rewritable by routers). Low bandwidth modem links will likely find this bit quite useful. Such links are frequently the first, and more importantly, the last hop. If the bit is to have any meaning by the time it reaches the last hop (after crossing umpteen ISP domains, each with there own notion of how to rewrite priority bits), I suspect that routers must be told "hands off". > (5) Expanding the number of "free bits" in the IPv6 Header > Yes, we could consider poaching on the Version field or the Flow > Label field to get more router-writeable bits, if someone had a > persuasive argument that we need more bits. As long as we leave the > Version field out of the AH authenticator, which I think we should > do, a transit domain could safely diddle with the version bits, as > long as they were restored on exit from the domain, without us > needing to saying anything about that in the specs. I'm a bit > reluctant to just undefine the Version field, if for no other reason > than to avoid the tedious debate on renaming the protocol to > something other than IPv6. I agree that we don't seem to have a pressing need to scavenge more bits out of the IPv6 header. But I'm a bit puzzled by the AH logic. If an ISP were allowed to modify the bits, so long as they are restored on exit, then having the AH cover those bits works just fine. So I suspect that your suggestion to exclude the bits from the AH is being done to provide future flexibility should routers decide to modify those bits and then not restore them. But if that is the case, there is no need to insist the ISPs restore the bits when a packet exits a domain. Whether or not ISPs are allowed to diddle the Version Field bits is important. I've been convinced that the Degermark et al. Header Compression draft breaks if the Version Field bits are allowed to contain arbitrary values (i.e., values other 4 and 6). It is not immediately obvious to me how to change the draft to remove this requirement. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 08:16:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12440; Mon, 24 Mar 1997 08:07:43 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12433; Mon, 24 Mar 1997 08:07:35 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22674; Mon, 24 Mar 1997 08:08:25 -0800 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA04427 for ; Mon, 24 Mar 1997 08:11:36 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA11378; Mon, 24 Mar 1997 11:06:51 -0500 Date: Mon, 24 Mar 1997 11:06:51 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9703241106.ZM11376@seawind.bellcore.com> In-Reply-To: Thomas Narten "(IPng 3363) Re: IPv6 priority field usage?" (Mar 24, 10:20am) References: <199703241520.KAA00587@hygro.raleigh.ibm.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Thomas Narten , Steve Deering Subject: (IPng 3364) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 910 I have a problem with any form of bit rewriting by the network. Basically, doing so removes information from the packet. For example, if a backbone network arbitrarily resets the priority to zero, that information would not be usable in the destination's intranet, where it may well be needed. A safer mode would be to have two fields, one set by the user as "what I requested", and another that can be reset by each transit network as "what I am ready to grant to this guy." Now, if we get rid of the version field, we get 4 network-writeable fields that can mirror the 4 user-defined priority bits. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 09:03:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12531; Mon, 24 Mar 1997 08:54:59 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12524; Mon, 24 Mar 1997 08:54:49 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA02861; Mon, 24 Mar 1997 08:55:39 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA26566 for ; Mon, 24 Mar 1997 08:58:15 -0800 Received: from gungnir.fnal.gov ("port 39740"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGVMKAURHA000QOY@FNAL.FNAL.GOV>; Mon, 24 Mar 1997 10:55:01 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA12903; Mon, 24 Mar 1997 10:55:00 -0600 Date: Mon, 24 Mar 1997 10:55:00 -0600 From: Matt Crawford Subject: (IPng 3365) Re: IPv6 priority field usage? In-reply-to: "24 Mar 1997 11:06:51 EST." <"9703241106.ZM11376"@seawind.bellcore.com> To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Message-id: <199703241655.KAA12903@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ I have a problem with any form of bit rewriting by the network. > Basically, doing so removes information from the packet. Yes. People are always complaining that the original TTL set by the source is not available at the destination. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 10:18:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA12703; Mon, 24 Mar 1997 10:09:43 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA12696; Mon, 24 Mar 1997 10:09:35 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA22166; Mon, 24 Mar 1997 10:10:25 -0800 Received: from pita.cisco.com (pita.cisco.com [161.44.132.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA04320 for ; Mon, 24 Mar 1997 10:13:38 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by pita.cisco.com (8.6.12/8.6.5) with ESMTP id KAA07575; Mon, 24 Mar 1997 10:10:25 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA10093; Mon, 24 Mar 1997 10:06:37 -0800 (PST) Date: Mon, 24 Mar 1997 10:06:37 -0800 (PST) Message-Id: <199703241806.KAA10093@pedrom-ultra.cisco.com> From: Pedro Marques To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3366) Re: revised IPv6-over-ethernet and -FDDI In-Reply-To: <199703241514.JAA12349@gungnir.fnal.gov> References: <"199703220000.QAA07146"@pedrom-ultra.cisco.com> <199703241514.JAA12349@gungnir.fnal.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1396 >>>>> "Matt" == Matt Crawford writes: >> >>>>> "Matt" == Matt Crawford writes: Matt> 4. Stateless Autoconfiguration The interface token [CONF] Matt> for an Ethernet interface is the EUI-64 identifier [EUI64] Matt> derived from the interface's built-in 48-bit IEEE >> Questions: 1) Why ? 2) What advantage does that bring to all >> the 802.3 networks out there ? Matt> This is a result of the tentative decision to use a Matt> globally-unique* 64-bit "end system designator" as the Matt> second half of an IPv6 address. This was one of the Matt> features of O'Dell's GSE that the PAL1 meeting felt was Matt> desirable and feasible. Matt, If you really really want to do this please do the bit stuffing in the addrconf layer/spec and not at the ethernet encapsulation level. Change the addrconf spec such that hosts accept to form autoconfigured addresses with prefixes smaller than 128 - link token. It will even save you the trouble concerning other medias. Please, don't fix something that isn't broken. regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 10:30:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA12734; Mon, 24 Mar 1997 10:20:09 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA12727; Mon, 24 Mar 1997 10:19:56 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA24739; Mon, 24 Mar 1997 10:20:45 -0800 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA08911 for ; Mon, 24 Mar 1997 10:24:00 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by stilton.cisco.com (8.6.12/8.6.5) with ESMTP id KAA03715; Mon, 24 Mar 1997 10:19:54 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 1997 09:56:07 -0800 To: Harri Hakulinen From: Fred Baker Subject: (IPng 3367) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1366 At 9:46 PM +0200 3/22/97, Harri Hakulinen wrote: >My comment is, that this is fine method, but you still need drop >priority (at least one bit, only for application) to smooth things and >help router to make right decisions. This kind of algorithm is not fast >enough alone. you have not commented on my points concerning this. Something that requires the router to search queues is not likely to happen, especially at the higher end. We simply don't have time for the memory references implied, not to mention architectural questions like "the queue may be an interface between a controller and its controlling processor, and the contents of the queue may not be simultaneously visible to both." I really honestly believe that the best implementation of drop priority is that simple priority gives you a way to weight probability of timely delivery, and in the final analysis, the choice of what gets dropped when we must do so. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don't set off nuclear weapons in Chino, California - there's a $500 fine ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 13:13:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13334; Mon, 24 Mar 1997 13:04:41 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13327; Mon, 24 Mar 1997 13:04:36 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA17998; Mon, 24 Mar 1997 13:05:27 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24498; Mon, 24 Mar 1997 13:04:46 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA13167; Mon, 24 Mar 1997 12:23:24 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA25510; Mon, 24 Mar 1997 12:24:13 -0800 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA05079 for ; Mon, 24 Mar 1997 12:27:27 -0800 Received: (from zubin@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA25568; Mon, 24 Mar 1997 14:23:50 -0600 From: Zubin Dittia Message-Id: <199703242023.OAA25568@dworkin.wustl.edu> Subject: (IPng 3369) Why not recursive goops in GSE? To: mo@uu.net Date: Mon, 24 Mar 1997 14:23:49 -0600 (CST) Cc: ipng@sunroof.eng.sun.com Organization: Washington University in St. Louis Phone: (314)-935-4163 (off), (314)-962-4176 (res), (314)-935-7302 (fax) X-Z: I will not be pushed, filed, stamped, indexed, briefed, debriefed, X-Z: or numbered. My life is my own. X-URL: http://dworkin.wustl.edu/~zubin/ X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1310 Mike, I recently read your draft on GSE addressing, and was left wondering why the "site" is an entity that is treated in a special way by the network. In other words, why does the entire RG for a site have to be inserted in the address when a packet leaves the site? Why not recursively add more bits to the higher order bits of the RG as a packet makes its way up the hierarchy? This would appear to be a generalization of the GSE scheme that would not dictate special treatment for "sites", and would (possibly) make it easier for ISPs to rehome. Doing this would also provide a weak (but possibly sufficient) method of authenticating the source address, since it would limit source address spoofing to within a site (assuming public networks are not compromised). This would in turn enable mechanisms such as redirects to be used more freely in networks. Perhaps this has already been discussed somewhere? Thanks, -Zubin -- Zubin D. Dittia DSc student, Washington University in St. Louis. zubin@dworkin.wustl.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 13:52:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13488; Mon, 24 Mar 1997 13:43:40 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13481; Mon, 24 Mar 1997 13:43:30 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA13407; Mon, 24 Mar 1997 13:44:20 -0800 Received: from mail.ton.tut.fi (mylly.ton.tut.fi [193.166.80.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA07891 for ; Mon, 24 Mar 1997 13:47:34 -0800 Received: from localhost (veikko@localhost) by mail.ton.tut.fi (8.8.0/8.8.0) with SMTP id XAA05652; Mon, 24 Mar 1997 23:43:40 +0200 (EET) Date: Mon, 24 Mar 1997 23:43:38 +0200 (EET) From: Harri Hakulinen Reply-To: Harri Hakulinen To: Fred Baker cc: ipng@sunroof.eng.sun.com Subject: (IPng 3370) Re: IPv6 priority field usage? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4050 On Mon, 24 Mar 1997, Fred Baker wrote: > At 9:46 PM +0200 3/22/97, Harri Hakulinen wrote: > >My comment is, that this is fine method, but you still need drop > >priority (at least one bit, only for application) to smooth things and > >help router to make right decisions. > >... > you have not commented on my points concerning this. Something that > requires the router to search queues is not likely to happen, especially at > the higher end. I am sorry that I have not been able to concentrate this enough. I understand your concern, because I know that you really know how these things work, and I only have some application specifig reqs. I am trying to sell you a following scheme: - drop priority bit is set by application as a guide to routers ( Packet without drop priority bit on is handled just like in current internet. So your only chance to win something is to set that bit and by doing that increase possibility that your "normal", more important packets are delivered to you. Of course, this works only when "critical mass" of applications are using this scheme ) - drop priority does NOT (need) to have any connection to other priorities (e.g rest of priority bits or any administrative priorities ) - Routers have no obligation to react to it (Altought I belive that this is potential "must" for future routers) - Routers may choose to react it for example in following way: When certain link utilization % is reached, router begins to drop packets from _incoming_ side of its queues "in advance". This is done in order to avoid really bad congestion, when you have to drop packets that don't have drop bit on. Packets that are dropped "in advance" are of course those, that are marked by drop priority bit on (by application). The exact value for that % for a given link is implementation specifig and may be one of administrative parameters for a given network (Intranet, ISP net, backbone, ...). I suppose that each queue has some kind of feeder proces or something. So this process can react to some kind of "drop flag" for that queue, and there is no need to do searches over queue to implement this ( altought someone might choose to implement it in that way to make things work even better with finer granularity ). I don't know how big queues are used in high-end backbone routers and I don't know how they exactly work, so I can not make any calculations or papers about this. But I do know, that when you are dealing with (real time) video streams, you have very few possibilities to react congestion situations by end-to-end basis. In the paper that was discussed in previous mails were some calculations about loss rates. They had made calculations over 1, 10 and 100 seconds. I belive that for video streams that is totally irrelevant and missleading. Only thing that matters for me from those figures was loss rate over 1 second period, and that was well over 10 %. That is enough to make things really hard in videodecoder (receiver) side if packets are dropped in random way and you have virtually no possibilities to react that for realtime flows by end-to-end basis. > I really honestly believe that the best implementation of drop priority > is that simple priority gives you a way to weight probability of timely > delivery, and in the final analysis, the choice of what gets dropped > when we must do so. I am not really sure any more what you mean (I have to wake up early tomorrow and read all mails again ;) Packet is either timely delivered or it is first one that is dropped ? ( If that is the case, I don't understand how it maps to my reqs ) - Harri.Hakulinen@research.nokia.com Video laboratory/Network & Terminal technologies Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 14:55:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA13659; Mon, 24 Mar 1997 14:46:55 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA13652; Mon, 24 Mar 1997 14:46:46 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA27897; Mon, 24 Mar 1997 14:47:34 -0800 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA05619 for ; Mon, 24 Mar 1997 14:50:15 -0800 Received: from [171.69.128.116] ([171.69.128.116]) by stilton.cisco.com (8.6.12/8.6.5) with ESMTP id OAA20161; Mon, 24 Mar 1997 14:46:17 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 1997 14:24:58 -0800 To: Harri Hakulinen From: Fred Baker Subject: (IPng 3371) Re: IPv6 priority field usage? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2135 At 11:43 PM +0200 3/24/97, Harri Hakulinen wrote: >- Routers have no obligation to react to it that's a good feature; if I don't have to do it, you can specify anything you want. Just don't plan it being available. :^) >When certain link utilization % is reached, router begins to drop packets >from _incoming_ side of its queues "in advance". This is done in order >to avoid really bad congestion, when you have to drop packets that don't >have drop bit on. this depends on a model where there is one central processor doing all the work, and which therefore knows what each interface is doing. Suppose, just for fun, that you have autonomous CPUs doing distributed forwarding? The information may not be available, or may be out of date. >> I really honestly believe that the best implementation of drop priority >> is that simple priority gives you a way to weight probability of timely >> delivery, and in the final analysis, the choice of what gets dropped >> when we must do so. > >I am not really sure any more what you mean (I have to wake up early >tomorrow and read all mails again ;) > >Packet is either timely delivered or it is first one that is dropped ? I mean that a packet that has higher priority may experience a more advantagous weight (WFQ/CBQ) or a different drop rate (WRED). Listen, packets *are* always delivered in as timely a fashion as possible or dropped. What might differ among packets is "does it move ahead of other traffic in the queue, or does other traffic in the queue move ahead of it". Does it get protected from timing jitter, or does it absorb jitter? I submit that a low priority packet absorbs infinite jitter when the choice comes to queue or drop... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don't set off nuclear weapons in Chino, California - there's a $500 fine ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 24 16:15:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA13921; Mon, 24 Mar 1997 16:06:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA13914; Mon, 24 Mar 1997 16:06:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA16504; Mon, 24 Mar 1997 16:07:32 -0800 Received: from mail.ton.tut.fi (mylly.ton.tut.fi [193.166.80.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA10546 for ; Mon, 24 Mar 1997 16:10:44 -0800 Received: from localhost (veikko@localhost) by mail.ton.tut.fi (8.8.0/8.8.0) with SMTP id CAA06292; Tue, 25 Mar 1997 02:07:22 +0200 (EET) Date: Tue, 25 Mar 1997 02:07:21 +0200 (EET) From: Harri Hakulinen Reply-To: Harri Hakulinen To: Fred Baker cc: ipng@sunroof.eng.sun.com Subject: (IPng 3372) Re: IPv6 priority field usage? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1779 On Mon, 24 Mar 1997, Fred Baker wrote: > At 11:43 PM +0200 3/24/97, Harri Hakulinen wrote: > >When certain link utilization % is reached, router begins to drop packets > >from _incoming_ side of its queues "in advance". This is done in order > >to avoid really bad congestion, when you have to drop packets that don't > >have drop bit on. > this depends on a model where there is one central processor doing all the > work, and which therefore knows what each interface is doing. Suppose, just > for fun, that you have autonomous CPUs doing distributed forwarding? The > information may not be available, or may be out of date. I can not see connection (..) bethween these things. It can not be impossible to share this kind of "flag"/queue/interface information bethween several processors. There might be number of virtual interfaces, but still ... Even if those processors cannot access any shared resource within interface, there must be some kind of control channel that interface can use to "broadcast" its current state to all forwarding processors. And I think that for scheme that I proposed, it does not matter very much if it is *bit* out of date, not very much of course. And I forgot to say earlier, that you can of course have some kind of "ramp" where you begin drop few packets/ given time and then increase that rate if it does not help. - Harri.Hakulinen@research.nokia.com Video laboratory/Network & Terminal technologies Tampere/Finland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 02:05:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA14659; Tue, 25 Mar 1997 01:57:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA14652; Tue, 25 Mar 1997 01:56:53 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA28620; Tue, 25 Mar 1997 01:57:46 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA04643 for ; Tue, 25 Mar 1997 02:01:07 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcijn21133; Tue, 25 Mar 1997 04:57:44 -0500 (EST) Message-Id: To: Zubin Dittia cc: mo@UU.NET (Mike O'Dell), ipng@sunroof.eng.sun.com, varghese@dworkin.wustl.edu, christos@dworkin.wustl.edu Subject: (IPng 3374) Re: Why not recursive goops in GSE? In-reply-to: Your message of "Tue, 25 Mar 1997 00:03:40 CST." <199703250603.AAA02059@dworkin.wustl.edu> Date: Tue, 25 Mar 1997 04:57:43 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 478 the DNS lookup is recursive, but in the later scheme the DNS gets the RG from the routers, so it's not a deep recursion, and the RG insertion and DNS notification come from the same place. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 05:46:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA14924; Tue, 25 Mar 1997 05:36:59 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA14917; Tue, 25 Mar 1997 05:36:50 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA15953; Tue, 25 Mar 1997 05:37:42 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA20559 for ; Tue, 25 Mar 1997 05:41:06 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA16148; Tue, 25 Mar 1997 08:23:41 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17113; Tue, 25 Mar 1997 08:23:39 -0500 Message-Id: <9703251323.AA17113@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3375) Draft DNS aAA and RG Records Date: Tue, 25 Mar 97 08:23:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 10593 This is for your preview. I think the prereq's for us to do this must be completed first but wanted you to have as much time to read this as possible. Its only 5 pages so I am just sending it to you. I am sure the ietfid work is backed up. I am very busy now doing the API and DHCPv6 parts (which is in last call fyi in DHC WG) also working on NAT. So if I don't respond for sometime its not that I am not listening but its time to work and stop talking. /jim ------- Forwarded Message Return-Path: bound Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA12556; Mon, 24 Mar 1997 21:36:25 -0500 Message-Id: <9703250236.AA12556@wasted.zk3.dec.com> To: internet-drafts@cnri.reston.va.us Cc: bound@zk3.dec.com Subject: Draft DNS aAA and RG Records Date: Mon, 24 Mar 97 21:36:25 -0500 From: bound X-Mts: smtp - --------------------------------cut here------------- Internet-Draft Jim Bound IPng Working Group Digital Equipment Corp March 1997 Synthesis of Routing Goop and AAAA Records in IPv6 Status of this Memo This document is a submission to the IPng Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipng@sunroof.eng.sun.com mailing list. This document is not at this time a product of the IPng Working Group, but a proposal to become a product of the IPng Working Group. This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document is a proposal to redefine the existing DNS AAAA resource record into two resource records: an RG record to define the routing topology of an IPv6 address and an aAA record to define the End System Identifier of an IPv6 address. The document will define the synthesis of the RG and aAA record at the DNS primary server, which will return an AAAA record to DNS resolvers. The objective of this work is to split the AAAA record in the DNS into location and identifier to provide future capabilities for dynamic renumbering of addresses. This work was spawned by the GSE - Alternate Addressing Architecture Proposal for IPv6. Bound Expires September 1997 [Page 1] Internet-Draft draft-ietf-ipngwg-dns-rr-rgadd-00.txt March 1997 Table of Contents: 1. Introduction.................................................3 2. Terminology and Definitions..................................3 3. New Resource Record Definitions..............................3 3.1 aAA record type.............................................3 3.2 RG record type..............................................4 3.3 aAA data format.............................................4 3.4 RG data format..............................................4 3.5 AAAA query..................................................4 3.6 Textual format of aAA and RG records........................4 4. Modifications to existing Query Types........................4 5. Security Considerations......................................5 Acknowledgements................................................5 References......................................................5 Authors' Address................................................5 Bound Expires September 1997 [Page 2] Internet-Draft draft-ietf-ipngwg-dns-rr-rgadd-00.txt March 1997 1. Introduction This document is a proposal to redefine the existing DNS AAAA resource record [3,4] into two resource records: an RG record to define the routing topology of an IPv6 address and an aAA record to define the End System Identifier of an IPv6 address. The document will define the synthesis of the RG and aAA record at the DNS primary server, which will return an AAAA record to DNS resolvers. The objective of this work is to split the AAAA record in the DNS into location and identifier to provide future capabilities for dynamic renumbering of addresses. This work was spawned by the GSE - Alternate Addressing Architecture Proposal for IPv6 [5]. The design objective of these two record types is to make it transparent to existing DNS resolvers and the DNS protocol used to query for AAAA records. This proposal is dependent on the IPng WG buying into new definitions via a new addressing architecture proposal, support for clear boundaries for an end system identifier, and the definition of the routing goop to define location for the end system identifier. Upon completion of that work in the WG if it moves forward the author can finish this specification where "????" and "TBD" exists presently. 2. Terminology and Definitions node - A device that implements IPv6. interface - A node's attachment to the link. address - An IP layer identifier for an interface or a set of interfaces. 3. New Resource Record Definitions Two new record types are defined to store a node's IPv6 address. A node that has more than one IPv6 address must have more than one such record or record combinations. 3.1 aAA record type The aAA resource record type is a new record specific to the Internet class that stores a single IPv6 address for a nodes interface. It is an ESD as defined in TBD. The value of the type is TBD (decimal). Bound Expires September 1997 [Page 3] Internet-Draft draft-ietf-ipngwg-dns-rr-rgadd-00.txt March 1997 3.2 RG record type The RG resource record type is a new record specific to the Internet class that stores a single IPv6 address for a nodes location within a routing domain. It is RG as defined in TBD. The value of the type is TBD (decimal). 3.3 aAA data format A ??? bit IPv6 ESD address is encoded in the data portion of an aAA resource record in network byte order (high-order byte first). 3.4 RG data format A ??? bit IPv6 RG address is encoded in the data portion of an RG resource record in network byte order (high-order byte first). 3.5 AAAA query An AAAA [1,2,4] query for a specified domain name in the Internet class returns all associated AAAA resource records in the answer section of a response. The DNS primary server [2] will synthesize the RG and aAA records to produce an AAAA record in the answer section of the response for a query for an AAAA record. A type AAAA query does not perform additional section processing. 3.6 Textual format of aAA and RG records The textual representation of the data portion of an aAA and RG resource record used in a master database file is the textual representation of a IPv6 address as defined in [3 + update for aAA and RG TBD]. 4. Modifications to existing Query Types Query processing as defined for AAAA records [4] would continue to be processed as defined presently for IPv6. The DNS primary server would bee responsible for concatentating the RG and aAA records to respond to an AAAA query from resolvers. There may be multiple RG's defined for each aAA record, and in those cases the DNS primary server after synthesis of RG's to a specific aAA record must return muliple AAAA record types in the answer section of a query response for AAAA records. The exception for the present AAAA records as defined is the IP6.INT Bound Expires September 1997 [Page 4] Internet-Draft draft-ietf-ipngwg-dns-rr-rgadd-00.txt March 1997 domain. The IPng WG at present is discussing a new methodology to obtain addresses for names in a query but use of an ICMP message to determine the name for an address. This needs further investigation to determine it if has an affect on AAAA records. But the same synthesis of RG + aAA records can be done for the reverse address requirement for DNS PTR records [2], to process AAAA reverse lookups in the DNS. 5. Security Considerations Security issues are not discussed in this memo. Acknowledgements The attendees at the IPng Interim WG meeting to review the GSE proposal at Sun Microsystems in Palo Alto, CA on February 27/28, 1997. References [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [2] Mockapetris, P., "Domain Names - Implementation and Specifica- tion", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995. [4] Tompson, S., and Huitema, C. "DNS Extensions to Support IP version 6", RFC 1886, Bellcore, December 1995. [5] O'dell, M. "GSE - An Alternate Addressing Architecture for IPv6" draft-ipngwg-gseaddr-00.txt, UUNET Technologies, Februrary 1997. Authors' Address Jim Bound Digital Equipment Corporation 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Phone: (603) 881-0400 Email: bound@zk3.dec.com Bound Expires September 1997 [Page 5] ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 06:15:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA14969; Tue, 25 Mar 1997 06:07:28 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA14958; Tue, 25 Mar 1997 06:07:17 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA19500; Tue, 25 Mar 1997 06:08:09 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA00253 for ; Tue, 25 Mar 1997 06:11:34 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA19937; Tue, 25 Mar 1997 08:52:12 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22759; Tue, 25 Mar 1997 08:52:10 -0500 Message-Id: <9703251352.AA22759@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3376) Address Architecture and Exterior Routing Protocol Date: Tue, 25 Mar 97 08:52:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2862 Until vendors get marcom and the field trained to walk and talk and install IPv6 for key customers most will tar and gzip the engineers to speak with customers and then gunzip them at the customer when they want to understand IPv6. Here is the latest I am hearing which we have heard before. Note most customers are watching the IETF to see whats happening. It is very public and it appears to many of them we are procrastinating into to much theory and abstractions. This is the general stuff I am hearing I can share and am sure others are hearing the same thing. I think addressing architecture and exterior routing protocol are high priority agenda items for Memphis in my opinion. Also sometimes engineers forget that customers hire computer scientists and architects to build their networks and they are just as knowledgable as us in the discipline of networking. Ignoring that or assuming they don't know is dumb on any engineers part. If you have never seen a customer chew up and spit out a non-technical person trying to sell them the brooklyn bridge to do networking its pretty ugly. 1. Must have complete IPv6 Address Proposal and understand how I will get IPv6 address from a registry (note right now these are large customers who will be their own provider). This is mandatory before we can deploy and would be good even for IPv6 Early Adoption. Suggestion by one large customer was that maybe democracy is not working in the IETF and maybe key vendors should form a coalition and fix this and present it to the IETF and ISPs/NAPs worldwide. Suggest that the 6bone adopt the chosen addressing architecture a.s.a.p. Use real IPv6 addresses not 1897. 2. Must have exterior routing protocol this is mandatory to deploy. Not much input on BGP vs IDRP but am now hearing that the cost to replace routers is an issue. Also many people are running multiprotocols and IPv6 will be another one for some time. I am wondering if this means we need I-IS-IS? 3. UNIX vendors look good and will be first boxes for early adoption be nice if they do routing for IPv6 too. 4. FTP Software for the PC desktop will get early adopters started. Would like to see other PC vendors engaged. 5. Need Server and Router platforms to do early adoption nice to have Cisco ready to go. 6. API work is key to deployment and porting guides. 7. IPv6 NAT a must. 8. Will you commit to product without Draft Standard status? 9. Asssume IPsec and Autoconfig (stateless and stateful) is in everyones implementation and IPsec is mandatory in IPv6 for Hosts. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 08:50:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15376; Tue, 25 Mar 1997 08:41:30 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15369; Tue, 25 Mar 1997 08:41:26 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA00691; Tue, 25 Mar 1997 08:42:18 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA25083; Tue, 25 Mar 1997 08:41:39 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA14462; Mon, 24 Mar 1997 22:02:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA05126; Mon, 24 Mar 1997 22:03:42 -0800 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA16521 for ; Mon, 24 Mar 1997 22:07:03 -0800 Received: (from zubin@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA02059; Tue, 25 Mar 1997 00:03:40 -0600 From: Zubin Dittia Message-Id: <199703250603.AAA02059@dworkin.wustl.edu> Subject: (IPng 3379) Re: Why not recursive goops in GSE? To: mo@UU.NET (Mike O'Dell) Date: Tue, 25 Mar 1997 00:03:40 -0600 (CST) Cc: ipng@sunroof.eng.sun.com, varghese@dworkin.wustl.edu, christos@dworkin.wustl.edu In-Reply-To: from "Mike O'Dell" at Mar 24, 97 05:02:06 pm Organization: Washington University in St. Louis Phone: (314)-935-4163 (off), (314)-962-4176 (res), (314)-935-7302 (fax) X-Z: I will not be pushed, filed, stamped, indexed, briefed, debriefed, X-Z: or numbered. My life is my own. X-URL: http://dworkin.wustl.edu/~zubin/ X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2054 ------------ Mike O'Dell writes: > > yes, that was considered early-on. > > it turns out that the boundary router can know the right > (entire) RG to insert quite easily - that isn't the problem, > and having the packet modified an arbitrary number of times > is both more complex and doesn't buy anything in the end. I suppose my problem was with the fact that you claim the use of recursive DNS lookups to find the destination RG, yet the source RG is inserted by a single router. That assymetry bothers me. If recursive DNS lookups are needed to support ISP rehoming, then isn't there an implicit assumption that an ISP does not have full knowledge of the RG used to reach it? So perhaps it is not an issue at all, and the whole RG is known to every site-border router. But in that case, the DNS server serving the ISP's domain will also know the full RG for the domain, so only one level of recursion is needed for the DNS lookup. But your GSE draft seems to indicate that multiple recursions may be necessary to support seamless ISP rehoming. What am I missing here? > the problems with GSE have more to do with general renumbering > issues - the re-writing hammers on the renumbering problems > quite strongly and in the end chanced out a number of related > issues which had not come to light until then (almost all of > them unrelated to GSE per se, except they were smoked-out by > the implications of GSE re-writing) In one of my discussions with George Varghese, he noticed something interesting about the current GSE proposal -- the destination know's the source's RG, but the source doesn't! Funny how that works... :-) -Zubin. -- Zubin D. Dittia DSc student, Washington University in St. Louis. zubin@dworkin.wustl.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 09:06:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15423; Tue, 25 Mar 1997 08:57:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15413; Tue, 25 Mar 1997 08:56:47 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA29619; Tue, 25 Mar 1997 08:57:34 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA08670 for ; Tue, 25 Mar 1997 09:00:54 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA05839; Tue, 25 Mar 1997 11:39:00 -0500 (EST) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00137; Tue, 25 Mar 1997 11:38:57 -0500 Date: Tue, 25 Mar 1997 11:38:57 -0500 From: Jack McCann Message-Id: <9703251638.AA00137@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3380) Host Reachability Advertisement for IPv6 Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 20741 A new draft should be showing up shortly in the Internet-Drafts directories: Host Reachability Advertisement for IPv6 draft-mccann-ipv6-hra-00.txt Abstract This document describes a mechanism that can be used by IPv6 hosts to communicate information about their address configuration to neighboring routers. In particular, this mechanism is intended to allow multihomed hosts and hosts with anycast addresses to communicate this information to their neighboring routers. This document defines a new ICMPv6 informational message type, a "Host Reachability Advertisement" to carry this information. It also defines a second ICMPv6 message, a "Host Reachability Solicitation", that can be used to trigger Host Reachability Advertisements. I have included the entire document below. This is a rough first draft, I have tried to capture enough of the basics to allow some meaningful discussion to take place. I expect this will be revised and fleshed out if the working group chooses to pursue it. I submit this to the ipng working group for consideration as a working group document. I ask the working group chairs for a small time slot on the agenda for Memphis, just long enough to get a sense of "yes, this is something worth pursuing" or "no, this is not something worth pursuing" in the working group. Comments welcome. - Jack ----------------------------------------------------------------------------- INTERNET-DRAFT J. McCann, Digital Equipment Corporation March 24, 1997 Host Reachability Advertisement for IPv6 draft-mccann-ipv6-hra-00.txt Abstract This document describes a mechanism that can be used by IPv6 hosts to communicate information about their address configuration to neighboring routers. In particular, this mechanism is intended to allow multihomed hosts and hosts with anycast addresses to communicate this information to their neighboring routers. This document defines a new ICMPv6 informational message type, a "Host Reachability Advertisement" to carry this information. It also defines a second ICMPv6 message, a "Host Reachability Solicitation", that can be used to trigger Host Reachability Advertisements. Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Expiration September 24, 1997 draft-mccann-ipv6-hra-00.txt [Page 1] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 Contents Abstract........................................................1 Status of this Memo.............................................1 Contents........................................................2 1. Introduction.................................................3 2. Terminology..................................................3 3. Protocol overview............................................4 3.1. Multihomed Host Example....................................4 3.2. Anycast Example............................................4 4. Message formats..............................................5 4.1. Host Reachability Solicitation message format..............5 4.2. Host Reachability Advertisement message format.............5 5. Protocol Requirements........................................7 5.1. Host specification.........................................7 5.1.1. Sending Host Reachability Solicitations..................7 5.1.2. Processing Received Host Reachability Solicitations......7 5.1.3. Sending Host Reachability Advertisements.................7 5.1.3.1. Sending Unsolicited HRAs...............................7 5.1.3.2. Sending Solicited HRAs.................................8 5.1.4. Processing Received Host Reachability Advertisements.....8 5.2. Router specification.......................................8 5.2.1. Sending Host Reachability Solicitations..................8 5.2.2. Processing Received Host Reachability Solicitations......8 5.2.3. Sending Host Reachability Advertisements.................8 5.2.4. Processing Received Host Reachability Advertisements.....8 5.2.5. Timers...................................................9 5.2.6. Interaction with Neighbor Unreachability Detection (NUD).9 5.3. Protocol constants.........................................9 6. Security considerations......................................9 Acknowledgements................................................9 Appendix A - Issues............................................10 References.....................................................11 Author's Address...............................................12 draft-mccann-ipv6-hra-00.txt [Page 2] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 1. Introduction This document describes a mechanism that can be used by IPv6 hosts to communicate information about their address configuration to neighboring routers. In particular, this mechanism is intended to allow hosts with multiple interfaces and hosts with anycast addresses to communicate this information to their neighboring routers. This document defines a new ICMPv6 informational message type, a "Host Reachability Advertisement" (HRA) to carry this information. HRAs are periodically transmitted. It also defines a second ICMPv6 message, a "Host Reachability Solicitation", (HRS) that can be used to trigger HRAs. The latter message type is intended to allow bootstrapping routers to avoid having to wait for the next periodic HRA. Both messages are for link-local use only. 2. Terminology node - a device that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. host - any node that is not a router. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. interface - a node's attachment to a link. address - an IPv6-layer identifier for an interface or a set of interfaces. packet - an IPv6 header plus payload. link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one piece over a link. draft-mccann-ipv6-hra-00.txt [Page 3] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 3. Protocol overview 3.1. Multihomed Host Example HRA(src=fe80::a1, address1=2::a) ------------------------------------------------------ Link 1 fe80::a1 | 1::a | +-----+ +-----+ | A | | R |---- network +-----+ +-----+ fe80::a2 | 2::a | ------------------------------------------------------ Link 2 HRA(src=fe80::a2, address1=1::a) Host A transmits an HRA on Link 2 to inform router R that address 1::a can be reached through Host A's interface on Link 2 (address fe80::a2). Host A also transmits an HRA on Link 1 to inform router R that address 2::a can be reached through Hosts A's interface on Link 1 (address fe80::a1). 3.2. Anycast Example +-----+ | A | +-----+ fe80::a1 | 3::c ------------------------------------------------------ Link 1 HRA(src=fe80::a1, address1=3::c) | +-----+ | R |---- network +-----+ HRA(src=fe80::b2, address1=3::c) | ------------------------------------------------------ Link 2 fe80::b2 | 3::c +-----+ | B | +-----+ Hosts A and B are both configured with anycast address 3::c. Host A transmits an HRA on Link 1 to inform router R that address 3::c can be reached through Host A's interface on Link 1 (address fe80::a1). Host B transmits an HRA on Link 2 to inform router R that address 3::c can be reached through Host B's interface on Link 2 (address fe80::b2). draft-mccann-ipv6-hra-00.txt [Page 4] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 4. Message formats This section specifies the protocol message format of the Host Reachability Solicitation and the Host Reachability Advertisement. 4.1. Host Reachability Solicitation message format The Host Reachability Solicitation is an ICMPv6 informational message with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Fields: Source Address Link-local unicast address of the sending interface. Destination Address Link-local all-nodes multicast address. Hop Limit 255 Priority 15 ICMPv6 Fields: Type TBD Code TBD Checksum The ICMPv6 checksum. See [ICMPv6]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 4.2. Host Reachability Advertisement message format The Host Reachability Advertisement is an ICMPv6 informational message with the following format: draft-mccann-ipv6-hra-00.txt [Page 5] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address[1] | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address[n] | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Fields: Source Address Link-local unicast address of the sending interface. Destination Address Link-local all-routers multicast address, or for an advertisement triggered by an HRS, this may be the source address from the HRS. Hop Limit 255 Priority 15 ICMPv6 Fields: Type TBD Code TBD Checksum The ICMPv6 checksum. See [ICMPv6]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Address[1..n] One or more 128-bit IPv6 addresses configured on draft-mccann-ipv6-hra-00.txt [Page 6] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 the sending host. The number of addresses n is derived from the packet size. MUST be a unicast address. MUST NOT be a link-local address. Site- local addresses MUST belong to the same site as the sending interface. 5. Protocol Requirements This section specifies the protocol requirements for both hosts and routers. 5.1. Host specification 5.1.1. Sending Host Reachability Solicitations Hosts do not send HRSs. 5.1.2. Processing Received Host Reachability Solicitations A host MUST silently discard any received HRS that does not pass the following validity checks: - The IPv6 Source Address field contains a link-local address. - The IPv6 Hop Limit field has a value of 255. - ICMPv6 Checksum is valid. - ICMPv6 length (derived from the IP length) is 8 octets. A host receiving a valid HRS SHOULD send a HRA as described in the next section. 5.1.3. Sending Host Reachability Advertisements A host MAY send HRAs if configured to do so. The means by which a host is configured to send HRAs is beyond the scope of this document. The remainder of this section applies only to hosts which are configured to send HRAs. 5.1.3.1. Sending Unsolicited HRAs A host periodically multicasts HRAs to the link-local all-routers multicast address. The period is a random amount of time between HRA_PERIOD_MIN and HRA_PERIOD_MAX. The period is reset to a new draft-mccann-ipv6-hra-00.txt [Page 7] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 random value between HRA_PERIOD_MIN and HRA_PERIOD_MAX each time an Unsolicited HRA is sent. 5.1.3.2. Sending Solicited HRAs A host SHOULD send a HRA upon receiving a valid HRS. If the next Unsolicited HRA is scheduled to be sent within HRA_DELAY_MAX time, a separate Solicited HRA does not need to be sent. A Solicited HRA is unicast to the soliciting node. Sending a Solicited HRA SHOULD be delayed for a random amount of time between 0 and HRA_DELAY_MAX. 5.1.4. Processing Received Host Reachability Advertisements Hosts MUST silently ignore received HRAs. 5.2. Router specification 5.2.1. Sending Host Reachability Solicitations A router MAY send a HRS to elicit HRAs from hosts on a link. An HRS is sent to the link-local all-nodes multicast address. 5.2.2. Processing Received Host Reachability Solicitations Routers MUST silently ignore received HRSs. 5.2.3. Sending Host Reachability Advertisements Routers do not send HRAs. 5.2.4. Processing Received Host Reachability Advertisements A router MUST silently discard any received HRA that does not pass the following validity checks: - The IPv6 Source Address field contains a link-local address. - The IPv6 Hop Limit field has a value of 255. - ICMPv6 Checksum is valid. - The packet is properly authenticated (for packets containing an authentication header). draft-mccann-ipv6-hra-00.txt [Page 8] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 Upon receipt of a valid HRA, a router MAY update its routing tables to reflect the information contained in the HRA. A router MAY also communicate this information with other routers. The mechanisms used to accomplish the above are beyond the scope of this specification. 5.2.5. Timers A router that uses reachable address information from an HRA MUST maintain a timer for each address. Each time an HRA is received for an address, the timer is set to HRA_TIMEOUT seconds. If the timer expires, the router MUST consider the address no longer reachable on that path. 5.2.6. Interaction with Neighbor Unreachability Detection (NUD) If Neighbor Unreachability Detection (NUD) [ND] indicates that the source of an HRA is no longer reachable, the router MUST consider addresses received in an HRA from that source no longer reachable on that path. 5.3. Protocol constants HRA_PERIOD_MIN 15 seconds HRA_PERIOD_MAX 45 seconds HRA_DELAY_MAX 5 seconds HRA_TIMEOUT 4 * HRA_PERIOD_MAX 6. Security considerations The HRA provides a mechanism by which reachability information may be injected into the routing system. Routers may require HRAs to be authenticated in configurations where this is considered a threat. Acknowledgements The author wishes to acknowledge the following people for their review and constructive criticism of early drafts of this document: Jim Bound, Jitu Patel, Mike Shand, and Matt Thomas. draft-mccann-ipv6-hra-00.txt [Page 9] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 Appendix A - Issues - Should there be a way for hosts to tell routers that an address contained in a previous HRA is no longer reachable, or is the router timeout sufficient? - Should the HRA carry some sort of metric information for the addresses contained therein? draft-mccann-ipv6-hra-00.txt [Page 10] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 References [ICMPv6] A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995 [ND] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996 draft-mccann-ipv6-hra-00.txt [Page 11] INTERNET-DRAFT draft-mccann-ipv6-hra-00.txt March 24, 1997 Author's Address Jack McCann Digital Equipment Corporation 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Phone: +1 603 881 2608 Fax: +1 603 881 0120 Email: mccann@zk3.dec.com Expiration September 24, 1997 draft-mccann-ipv6-hra-00.txt [Page 12] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 09:53:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15530; Tue, 25 Mar 1997 09:39:53 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15523; Tue, 25 Mar 1997 09:39:48 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09910; Tue, 25 Mar 1997 09:40:42 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA25303; Tue, 25 Mar 1997 09:40:01 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15036; Tue, 25 Mar 1997 07:12:47 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04029; Tue, 25 Mar 1997 07:13:39 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA24478 for ; Tue, 25 Mar 1997 07:17:04 -0800 Received: from ietf.ietf.org by ietf.org id aa10149; 25 Mar 97 10:14 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3383) I-D ACTION:draft-ietf-ipngwg-trans-fddi-net-00.txt Date: Tue, 25 Mar 1997 10:14:06 -0500 Message-ID: <9703251014.aa10149@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3884 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-fddi-net-00.txt Pages : 8 Date : 03/24/1997 This memo specifies the MTU and frame format for transmission of IPv6 packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on an FDDI network. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-trans-fddi-net-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-fddi-net-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970324101933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-fddi-net-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970324101933.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 09:58:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15543; Tue, 25 Mar 1997 09:43:35 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15536; Tue, 25 Mar 1997 09:43:29 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11724; Tue, 25 Mar 1997 09:44:24 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA25336; Tue, 25 Mar 1997 09:43:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15040; Tue, 25 Mar 1997 07:12:51 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04040; Tue, 25 Mar 1997 07:13:42 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA24492 for ; Tue, 25 Mar 1997 07:17:06 -0800 Received: from ietf.ietf.org by ietf.org id aa10196; 25 Mar 97 10:14 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3384) I-D ACTION:draft-ietf-ipngwg-trans-ethernet-00.txt Date: Tue, 25 Mar 1997 10:14:10 -0500 Message-ID: <9703251014.aa10196@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3799 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-ethernet-00.txt Pages : 5 Date : 03/24/1997 This memo specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on an Ethernet. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-trans-ethernet-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-ethernet-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970324102801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-ethernet-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970324102801.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 10:01:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15556; Tue, 25 Mar 1997 09:46:14 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15549; Tue, 25 Mar 1997 09:46:08 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12864; Tue, 25 Mar 1997 09:47:02 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA25363; Tue, 25 Mar 1997 09:46:20 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15467; Tue, 25 Mar 1997 09:08:38 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA02218; Tue, 25 Mar 1997 09:09:30 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA14893 for ; Tue, 25 Mar 1997 09:12:54 -0800 Received: from ietf.ietf.org by ietf.org id aa11351; 25 Mar 97 10:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3385) I-D ACTION:draft-ietf-ipngwg-ipv6-mib-01.txt Date: Tue, 25 Mar 1997 10:16:23 -0500 Message-ID: <9703251016.aa11351@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4070 --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Management Information Base for IP Version 6: Textual Conventions and General Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-mib-01.txt Pages : 40 Date : 03/24/1997 This document is one in the series of documents that provide MIB definitions for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-mib-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970324145010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970324145010.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 10:04:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15571; Tue, 25 Mar 1997 09:48:57 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15561; Tue, 25 Mar 1997 09:48:44 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13944; Tue, 25 Mar 1997 09:49:38 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA25393; Tue, 25 Mar 1997 09:48:57 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15487; Tue, 25 Mar 1997 09:10:34 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA02623; Tue, 25 Mar 1997 09:11:27 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA15751 for ; Tue, 25 Mar 1997 09:14:52 -0800 Received: from ietf.ietf.org by ietf.org id aa11395; 25 Mar 97 10:16 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3386) I-D ACTION:draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt Date: Tue, 25 Mar 1997 10:16:26 -0500 Message-ID: <9703251016.aa11395@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4062 --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Management Information Base for IP Version 6: UDP and TCP Groups Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt Pages : 19 Date : 03/24/1997 This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the UDP and TCP groups are defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970324150550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970324150550.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 10:21:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15744; Tue, 25 Mar 1997 10:05:57 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15737; Tue, 25 Mar 1997 10:05:31 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA16096; Tue, 25 Mar 1997 10:06:23 -0800 Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA11373 for ; Tue, 25 Mar 1997 10:09:47 -0800 Received: (from richier@localhost) by horus.imag.fr (8.8.1/8.6.9) id TAA23832 for ipng@sunroof.Eng.Sun.COM; Tue, 25 Mar 1997 19:06:18 +0100 (MET) Date: Tue, 25 Mar 1997 19:06:18 +0100 (MET) From: Jean-Luc Richier Message-Id: <199703251806.TAA23832@horus.imag.fr> Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 3387) dchp v6 extensions Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2679 I was trying to add the code for analyzing dhcpv6 extensions in tcpdump, and I have a problem with the draft draft-ietf-dhc-v6exts-05.txt: I am unable to write a parser for the extension field of dhcpv6. All extensions use a 16-bit type field, except the pad extension, which is one byte long, with value 0. But this means that I do not see how to parse in a simple way the sequence 00 01 00 06 00 00 00 00 Is this a 0001 option of length 0006, or a pad option, followed by a 0100 option with length 0600 It seems that allowing one option to be one byte long and the others to start with a 16-bit number is ambiguous. I see different solutions, which modify the draft: - Specify that ALL options have a even length. If needed, one can add a TRAILING null byte. The pad option is now 0000 (16 bits). - Specify that all options but the pad have a type >=0x100. That is difficult as all defined options are <= 0x100. - Change the code for pad, for exemple use 0xfe, and forbid options with type from 0xfe00 to 0xfeff. Also I ask for an interpretation of the following text from the draft (paragraph 2): DHCPv6 extensions have the same format as the BOOTP "vendor extensions" defined in RFC 1497 [9]. Extensions may be fixed length or variable length. All extensions except for the pad extension begin with a type field which is two octets long, which uniquely identifies the extension. Fixed length extensions without data consist of only the two octet type field. Only extensions 0 and 65535 are fixed length. All other extensions are variable length with a two octet length field following the type octets. The value of the length octets does not include the two octets specifying the type and length. The length octet is followed by "length" octets of data. In the case of some variable length extensions the length field is a constant but must still be specified. How must I interpret ``does not include the two octets specifying the type and length'', as type and length are both 16 bit numbers. Dose it means that the total length of the option is (length_field+2), or (length_field+4) ? Thanks for any clarification. -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 53, F-38041 GRENOBLE Cedex 9 Tel : (33) 4 76 82 72 32 Fax : (33) 4 76 82 72 87 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 10:41:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15901; Tue, 25 Mar 1997 10:31:59 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15894; Tue, 25 Mar 1997 10:31:55 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16446; Tue, 25 Mar 1997 10:32:48 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA25464; Tue, 25 Mar 1997 10:32:07 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15826; Tue, 25 Mar 1997 10:22:11 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA20307; Tue, 25 Mar 1997 10:23:03 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA18660 for ; Tue, 25 Mar 1997 10:26:26 -0800 Received: from ietf.ietf.org by ietf.org id aa12045; 25 Mar 97 10:17 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3389) I-D ACTION:draft-ietf-ipngwg-ipv6-icmp-mib-01.txt Date: Tue, 25 Mar 1997 10:17:37 -0500 Message-ID: <9703251017.aa12045@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4039 --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Management Information Base for IP Version 6: ICMPv6 Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-icmp-mib-01.txt Pages : 18 Date : 03/24/1997 This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-icmp-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970324164816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-icmp-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970324164816.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 11:10:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA15974; Tue, 25 Mar 1997 11:00:50 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA15967; Tue, 25 Mar 1997 11:00:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA01136; Tue, 25 Mar 1997 11:01:34 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA07136 for ; Tue, 25 Mar 1997 11:04:58 -0800 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.6/8.7.3) with ESMTP id UAA22358 for ; Tue, 25 Mar 1997 20:01:29 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA10922 for ; Tue, 25 Mar 1997 20:01:29 +0100 (MET) Message-Id: <199703251901.UAA10922@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: (IPng 3390) Draft two consequences of GSE on multicast MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <11008.859316483.0@givry.inria.fr> Date: Tue, 25 Mar 1997 20:01:28 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4771 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11008.859316483.1@givry.inria.fr> This is for your preview (it is very short). Francis.Dupont@inria.fr ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11008.859316483.2@givry.inria.fr> Content-Description: draft-dupont-ipv6-gse-multicast-00.txt Network Working Group Francis Dupont Internet-Draft INRIA Expire in six months 1997/03/23 17:50:50MET Implications of the GSE Addressing Scheme to IPv6 Multicast 1. Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa) , nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or ftp.isi.edu (US West Coast). 2. Abstract This document presents some implications for the GSE Addressing Scheme ([1] draft-ietf-ipngwg-gseaddr-00.txt proposal by Mike O'Dell) on IPv6 multicast: a new scope for large structures and a clever way to compare two addresses for the election of a designated router. 3. Introduction The GSE Addressing Scheme cuts IPv6 unicast provider-based addresses into two 8 octet fields, the first one for routing and the second one for an ``end system designator''. The routing part begins with a large structure ID. The scopes defined by the RFC 1884 (IPv6 Addressing Architecture) for multicast addresses in section 2.6 pages 14 and 15 have no value between organization-local (8) and global (E) scopes. The IGMP version 2 proposal (draft-ietf-idmr-igmp-v2-06.txt) specifies an election process for the ``Querier'' multicast router on a physical network (this election process is a part of the DVMRP v3 proposal (draft-ietf-idmr-dvmrp-v3-04.txt) too): the multicast router with the ``lower'' IP address is selected. 4. Large Structure Scope A new scope for large-structure-local scope with the value C (12) is defined. The Address Testing Macro for Basic Socket Interface Extensions for IPv6 (draft-ietf-ipngwg-bsd-api-07.txt) is: int IN6_IS_ADDR_MC_LSLOCAL (const struct in6_addr *); 5. Clever Address Comparison The ESD field is far more stable than the routing half at the beginning of an address and is unique on the link. This document defines the way to compare two addresses: only the tail 8 octets (the ESD field) MUST be compared. The code for the lower test looks like: (((x)->s6_addr[8] < (y)->s6_addr[8]) || (((x)->s6_addr[8] == (y)->s6_addr[8]) && (((x)->s6_addr[9] < (y)->s6_addr[9]) || (((x)->s6_addr[9] == (y)->s6_addr[9]) && (((x)->s6_addr[10] < (y)->s6_addr[10]) || (((x)->s6_addr[10] == (y)->s6_addr[10]) && (((x)->s6_addr[11] < (y)->s6_addr[11]) || (((x)->s6_addr[11] == (y)->s6_addr[11]) && (((x)->s6_addr[12] < (y)->s6_addr[12]) || (((x)->s6_addr[12] == (y)->s6_addr[12]) && (((x)->s6_addr[13] < (y)->s6_addr[13]) || (((x)->s6_addr[13] == (y)->s6_addr[13]) && (((x)->s6_addr[14] < (y)->s6_addr[14]) || (((x)->s6_addr[14] == (y)->s6_addr[14]) && ((x)->s6_addr[15] < (y)->s6_addr[15]))))))))))))))) Obviously one can write far simpler code for a big endian 64 bit architecture. 6. Security Considerations Security considerations are not addressed in this memo. 7. Author's address Francis Dupont INRIA Rocquencourt Domaine de Voluceau B.P. 105 78153 Le Chesnay Cedex FRANCE E-mail: Francis.Dupont@inria.fr ------- =_aaaaaaaaaa0-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 11:28:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA16012; Tue, 25 Mar 1997 11:19:34 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA16005; Tue, 25 Mar 1997 11:19:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA06411; Tue, 25 Mar 1997 11:20:15 -0800 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16013 for ; Tue, 25 Mar 1997 11:23:37 -0800 Received: from coral.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA24662; Tue, 25 Mar 1997 14:19:30 -0500 Date: Tue, 25 Mar 1997 14:19:30 -0500 (EST) From: Ralph Droms To: Jean-Luc Richier Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3391) Re: dchp v6 extensions In-Reply-To: <199703251806.TAA23832@horus.imag.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 929 On Tue, 25 Mar 1997, Jean-Luc Richier wrote: > All extensions use a 16-bit type field, except the pad extension, which is > one byte long, with value 0. > > But this means that I do not see how to parse in a simple way the sequence > > 00 01 00 06 00 00 00 00 > > Is this a 0001 option of length 0006, or a pad option, followed by a 0100 > option with length 0600 If I remember correctly, we discussed this issue briefly at the last IETF meeting; looks like the solution slipped through the cracks. I suggest we discard the 'pad' extension; aligning on 'word boundaries' is machine-dependent and, IMHO, not necessary for DHCP. - Ralph ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 11:43:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA16042; Tue, 25 Mar 1997 11:31:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA16035; Tue, 25 Mar 1997 11:31:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA09898; Tue, 25 Mar 1997 11:32:32 -0800 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA21240 for ; Tue, 25 Mar 1997 11:35:43 -0800 Received: from coral.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA07572; Tue, 25 Mar 1997 14:31:46 -0500 Date: Tue, 25 Mar 1997 14:31:46 -0500 (EST) From: Ralph Droms To: Jean-Luc Richier Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3392) Re: dchp v6 extensions In-Reply-To: <199703251806.TAA23832@horus.imag.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1702 On Tue, 25 Mar 1997, Jean-Luc Richier wrote: > > Also I ask for an interpretation of the following text from the draft > (paragraph 2): > DHCPv6 extensions have the same format as the BOOTP "vendor > extensions" defined in RFC 1497 [9]. Extensions may be fixed length > or variable length. All extensions except for the pad extension > begin with a type field which is two octets long, which uniquely > identifies the extension. Fixed length extensions without data > consist of only the two octet type field. Only extensions 0 and > 65535 are fixed length. All other extensions are variable length > with a two octet length field following the type octets. The value > of the length octets does not include the two octets specifying the > type and length. The length octet is followed by "length" octets > of data. In the case of some variable length extensions the length > field is a constant but must still be specified. > > How must I interpret ``does not include the two octets specifying the type > and length'', as type and length are both 16 bit numbers. > Dose it means that the total length of the option is (length_field+2), or > (length_field+4) ? I believe there is a typo (perhaps a legacy from the one octet tag and length fields in DHCPv4); the relevant text should read: [...] does not include the four octets specifying the type and length. - Ralph ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 13:34:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA16395; Tue, 25 Mar 1997 13:24:05 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA16388; Tue, 25 Mar 1997 13:23:59 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA02049; Tue, 25 Mar 1997 13:24:51 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA25597; Tue, 25 Mar 1997 13:24:12 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA16143; Tue, 25 Mar 1997 12:12:26 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA19972; Tue, 25 Mar 1997 12:13:18 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA08004 for ; Tue, 25 Mar 1997 12:16:41 -0800 Received: from ietf.ietf.org by ietf.org id aa12938; 25 Mar 97 10:22 EST To: IETF-Announce:;@ietf.org@jurassic@jurassic Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 3394) Document Action: Basic Socket Interface Extensions for IPv6 to Informational Date: Tue, 25 Mar 1997 10:22:30 -0500 Message-ID: <9703251022.aa12938@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 618 The IESG has reviewed the Internet-Draft "Basic Socket Interface Extensions for IPv6" and recommends that it be published by the RFC Editor as an Informational RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 15:21:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16627; Tue, 25 Mar 1997 15:12:49 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16620; Tue, 25 Mar 1997 15:12:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA02622; Tue, 25 Mar 1997 15:13:31 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA22860 for ; Tue, 25 Mar 1997 15:16:58 -0800 Received: by mail.noris.net id <35226-16114>; Wed, 26 Mar 1997 00:13:11 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3395) Re: Host Reachability Advertisement for IPv6 Date: 26 Mar 1997 00:12:36 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 10 Message-ID: <5h9m54$1l1$1@work.smurf.noris.de> References: <9703251638.AA00137@wasted.zk3.dec.com> <859310355.10714@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1642 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 623 Jack McCann writes: > [draft-mccann-ipv6-hra-00.txt] This may be a stupid question, but why do we need an additional couple of ICMP messages when there's already the mandatory ND stuff (RFC1970)? -- Nibble - When a little bit isn't enough... -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 16:42:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16866; Tue, 25 Mar 1997 16:33:54 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16859; Tue, 25 Mar 1997 16:33:43 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA04619; Tue, 25 Mar 1997 16:34:34 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA13307; Tue, 25 Mar 1997 16:34:35 -0800 Date: Tue, 25 Mar 1997 16:34:35 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199703260034.QAA13307@bobo.eng.sun.com> To: mccann@zk3.dec.com Subject: (IPng 3396) Re: Host Reachability Advertisement for IPv6 Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 843 > Appendix A - Issues > > - Should there be a way for hosts to tell routers that an address > contained in a previous HRA is no longer reachable, or is the > router timeout sufficient? I think the router should use Neighbor Unreachability Detection on the advertised addresses (just like it does on any other address to which the router is sending packets) to detect when the address becomes unreachable. This would provide timely failover when a node fails in the anycast case and also when an interface fails in the multihomed case. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 17:08:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16916; Tue, 25 Mar 1997 16:59:40 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16909; Tue, 25 Mar 1997 16:59:36 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10887; Tue, 25 Mar 1997 17:00:29 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA25972; Tue, 25 Mar 1997 16:59:48 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16869; Tue, 25 Mar 1997 16:48:08 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA24910; Tue, 25 Mar 1997 16:49:00 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA01042 for ; Tue, 25 Mar 1997 16:52:31 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA01276; Tue, 25 Mar 1997 16:49:00 -0800 Message-Id: <3.0.1.32.19970325164720.006ba490@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 16:47:20 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3398) Updated IPv6 Addressing Architecture draft Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2779 I submitted a new version of the "IP Version 6 Addressing Architecture" to the internet drafts folks that should appear in a few days. The only substantive change is the addition of text describing how IPv6 address prefixes are written. The new text is attached to this message. I did not make any changes based on the topics discussed at the February meeting because I thought more discussion was needed in Memphis. Also, as part of the address prefixes text a new rule is included to make writing the prefixes simpler. There would, of course, be some cost in the code which would have to parse this text. Comments are appreciated. Bob ______________________________________________________________________ 2.3 Text Representation of Address Prefixes The text representation of IPv6 address prefixes is similar to the way IPv4 addresses prefixes are written in CIDR notation. An IPv6 address prefix is represented by the notation: ipv6-address/prefix-length where ipv6-address is an IPv6 address in any of the notations listed in section 2.2, with the extra rule that, if the written address ends in "::", the trailing "::" may be omitted. prefix-length is a decimal value specifying how many of the leftmost contiguous bits of the address comprise the prefix. For example, the following are legal representations of the 60-bit prefix 12AB00000000CD3 (hexadecimal): 12AB:0000:0000:CD30:0000:0000:0000:0000/60 12AB::CD30:0:0:0:0/60 12AB:0:0:CD30::/60 12AB:0:0:CD30/60 The following are NOT legal representations of the above prefix: 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, within any 16-bit chunk of the address 12AB::CD30/60 address to left of "/" expands to 12AB:0000:0000:0000:0000:000:0000:CD30 12AB::CD3/60 address to left of "/" expands to 12AB:0000:0000:0000:0000:000:0000:0CD3 When writing both a node address and a prefix of that node address (e.g., the node's subnet prefix), the two can combined as follows: the node address 12AB:0:0:CD30:123:4567:89AB:CDEF and its subnet number 12AB:0:0:CD30/60 can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 ______________________________________________________________________ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 17:25:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA16952; Tue, 25 Mar 1997 17:14:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA16945; Tue, 25 Mar 1997 17:14:30 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA00400; Tue, 25 Mar 1997 17:15:22 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA11621 for ; Tue, 25 Mar 1997 17:18:53 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA02544; Tue, 25 Mar 1997 17:13:54 -0800 Message-Id: <3.0.1.32.19970325171214.006db23c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 17:12:14 -0800 To: jburgan@BayNetworks.com From: Bob Hinden Subject: (IPng 3399) Request to Advance "TCP and UDP over IPv6 Jumbograms" Cc: scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1137 Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: Title : TCP and UDP over IPv6 Jumbograms Author(s) : David Borman Filename : Pages : 3 Date : August 1996 A working group last call for this document was completed on March 6, 1997. No comments were received during the last call period. Bob Hinden / Steve Deering IPng Working Group Co-Chairs ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 17:29:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA16971; Tue, 25 Mar 1997 17:18:15 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA16958; Tue, 25 Mar 1997 17:17:59 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14036; Tue, 25 Mar 1997 17:18:50 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA13351; Tue, 25 Mar 1997 17:18:51 -0800 Date: Tue, 25 Mar 1997 17:18:51 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199703260118.RAA13351@bobo.eng.sun.com> To: smurf@noris.de Subject: (IPng 3400) Re: Host Reachability Advertisement for IPv6 Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 877 > This may be a stupid question, but why do we need an additional couple of > ICMP messages when there's already the mandatory ND stuff (RFC1970)? ND doesn't contain a mechanism for a host to tell a router which addresses it wants to receive. The assumption is that the router knows one or more subnet prefixes and when forwarding packets the router sends a Neighbor Solicitation provided that the address falls in the subnet prefix. Thus using current ND mechanisms a host can not tell a router that it wants to received packets addressed to an address outside the subnet prefixes. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 20:30:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA17287; Tue, 25 Mar 1997 20:21:39 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA17280; Tue, 25 Mar 1997 20:21:31 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA25576; Tue, 25 Mar 1997 20:22:23 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA00627; Tue, 25 Mar 1997 20:25:55 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA12841; Tue, 25 Mar 1997 23:14:40 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA29004; Tue, 25 Mar 1997 23:14:38 -0500 Message-Id: <9703260414.AA29004@wasted.zk3.dec.com> To: Ralph Droms Cc: Jean-Luc Richier , ipng@sunroof.eng.sun.com, charles.perkins@corp Subject: (IPng 3401) Re: dchp v6 extensions In-Reply-To: Your message of "Tue, 25 Mar 97 14:19:30 EST." Date: Tue, 25 Mar 97 23:14:38 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2589 >> All extensions use a 16-bit type field, except the pad extension, which is >> one byte long, with value 0. >> >> But this means that I do not see how to parse in a simple way the sequence >> >> 00 01 00 06 00 00 00 00 >> >> Is this a 0001 option of length 0006, or a pad option, followed by a 0100 >> option with length 0600 >If I remember correctly, we discussed this issue briefly at the last IETF >meeting; looks like the solution slipped through the cracks. I can't find this in our notes. But I do recall us wanting to use the same pad option as stated in RFC 1883 but that got nixed. I think there is some confusion here and need to check. The first packets you will see in tcpdump after UDP header is the DHCPv6 message type header. This is not fixed and is dependent on if certain fields are present depending on the option within the Message type (e.g. solicit, request, recover, reply). If an extension is present the first one will have a 16bit type and 16bit length. Pad options should only be interpreted within an extension after the extension type and length. We need to fix the words around that so its more clear as I can see the confusion from the above interpretation of the type field. For example in my implementation I just load the type and length into an int and determine the decimal values. At this point I know when the next extension will exist or not exist via the length of the UDP datagram. Then I can look for the end extension too and then note the pad bytes for this extension, if it is present. We had used different schemes and even at one point a "NO MORE" extensions type. But the scheme we came up with at present permits implementations to align or not align on word boundaries. The implementor must check the pad bytes. Flexibility was traded off for reasons which we were told the WG wanted. So mandatory alignment is not a MUST in the exts spec. >I suggest we discard the 'pad' extension; aligning on 'word boundaries' >is machine-dependent and, IMHO, not necessary for DHCP. That can be done today with the protocol it is not required to align on any boundary, but if you want to do it you can. Its not a MUST in the exts draft. Thats why we did it that way. We did get input that alignment is a nice optimization too. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Tue Mar 25 20:34:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA17296; Tue, 25 Mar 1997 20:24:42 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA17289; Tue, 25 Mar 1997 20:24:29 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA25878; Tue, 25 Mar 1997 20:25:21 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA01397; Tue, 25 Mar 1997 20:28:53 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA16946; Tue, 25 Mar 1997 23:17:45 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28820; Tue, 25 Mar 1997 23:17:45 -0500 Message-Id: <9703260417.AA28820@wasted.zk3.dec.com> To: Ralph Droms Cc: Jean-Luc Richier , ipng@sunroof.eng.sun.com, charles.perkins@corp Subject: (IPng 3402) Re: dchp v6 extensions In-Reply-To: Your message of "Tue, 25 Mar 97 14:31:46 EST." Date: Tue, 25 Mar 97 23:17:44 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1990 >> Also I ask for an interpretation of the following text from the draft >> (paragraph 2): >> DHCPv6 extensions have the same format as the BOOTP "vendor >> extensions" defined in RFC 1497 [9]. Extensions may be fixed length >> or variable length. All extensions except for the pad extension >> begin with a type field which is two octets long, which uniquely >> identifies the extension. Fixed length extensions without data >> consist of only the two octet type field. Only extensions 0 and >> 65535 are fixed length. All other extensions are variable length >> with a two octet length field following the type octets. The value >> of the length octets does not include the two octets specifying the >> type and length. The length octet is followed by "length" octets >> of data. In the case of some variable length extensions the length >> field is a constant but must still be specified. >> >> How must I interpret ``does not include the two octets specifying the type >> and length'', as type and length are both 16 bit numbers. >> Dose it means that the total length of the option is (length_field+2), or >> (length_field+4) ? >I believe there is a typo (perhaps a legacy from the one octet tag and >length fields in DHCPv4); the relevant text should read: >[...] does not include the four octets specifying the type and length. Will fix this.... thanks /jim - Ralph ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 00:46:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA17452; Wed, 26 Mar 1997 00:37:21 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA17445; Wed, 26 Mar 1997 00:37:09 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA22507; Wed, 26 Mar 1997 00:38:00 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA24623 for ; Wed, 26 Mar 1997 00:41:35 -0800 Received: by mail.noris.net id <35306-24256>; Wed, 26 Mar 1997 09:37:52 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3403) Re: Host Reachability Advertisement for IPv6 Date: 26 Mar 1997 09:37:39 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 30 Message-ID: <5han8j$9qj$1@work.smurf.noris.de> References: <199703260118.RAA13351@bobo.eng.sun.com> <859340558.18914@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1650 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1736 Erik.Nordmark@Eng.Sun.COM (Erik Nordmark) writes: > > This may be a stupid question, but why do we need an additional couple of > > ICMP messages when there's already the mandatory ND stuff (RFC1970)? > > ND doesn't contain a mechanism for a host to tell a router which > addresses it wants to receive. The assumption is that the router > knows one or more subnet prefixes and when forwarding packets the > router sends a Neighbor Solicitation provided that the address > falls in the subnet prefix. > Of course it does. You just broadcast an Advertisement with the Override flag cleared. Maybe an additional Anycast bit would be of advantage. > Thus using current ND mechanisms a host can not tell a router > that it wants to received packets addressed to an address outside > the subnet prefixes. > My assumption is that the router knows which addresses are permissible anycast addresses. Therefore it can send a ND Solicitation message for it when a packet arrives. -- When guns are outlawed, only outlaws will have guns. -- Art Denman -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 07:31:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA17820; Wed, 26 Mar 1997 07:22:54 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA17813; Wed, 26 Mar 1997 07:22:45 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA08051; Wed, 26 Mar 1997 07:23:36 -0800 Received: from snoopy.agile.com ([198.3.105.221]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA06729 for ; Wed, 26 Mar 1997 07:27:08 -0800 Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC39CF.2B05B8A0@SNOOPY>; Wed, 26 Mar 1997 10:19:20 -0500 Message-ID: From: "Harrington, Dan" To: "'ipng@sunroof.eng.sun.com'" Cc: "'francis@works.ingrid.org'" Subject: (IPng 3407) FYI: BOF on internet host proximity service Date: Wed, 26 Mar 1997 10:19:18 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2829 This is crossposted (with the author's permission) as an FYI. A cursory reading of the abstract and referenced white paper made me think of the site-local addressing problem we were discussing earlier this year. In particular, we debated what an appropriate mechanism might be for a host to determine when another host is within the same logical site, so that site-local addresses may be used. I'm not suggesting that this proposal is the answer, but it might get the creative juices flowing... Dan > ---------- > From: > owner-namedroppers@internic.net[SMTP:owner-namedroppers@internic.net] > on behalf of > owner-namedroppers@opsmail.internic.net[SMTP:owner-namedroppers@opsmai > l.internic.net] > Sent: Monday, March 24, 1997 11:27 PM > To: namedroppers@internic.net > Subject: BOF on internet host proximity service > > > Hi, > > I'll be running a BOF in Memphis on something I'm calling > the Internet Host Proximity Service (HOPS). You can read > a white paper about it at http://www.ingrid.org/hops/wp.html, > and I've attached the abstract below. The BOF has not yet > been given a time slot. > > Like a lot of these sorts of things, the scheme relies > on hacking DNS to, rather than pull the answer to a query > out of a static local database, make a query to the system > that estimates host proximity. This in turn relies on > being able to deduce the location of the host making the > original DNS query from the query finally received by the DNS > server. > > Since my knowledge of DNS isn't so great, especially current > usage, I would appreciate it if any interested people in > this group could show up at the BOF or otherwise give me > feedback on the white paper. > > Thanks much, > > PF > > ps. I'm not on this mailing list, so please copy me on > any replies. > > Abstract > > The majority of Internet applications, such as web access > to a mirrored server, have the characteristic whereby a > "client" application wants to contact not a specific host, > but any, and usually the nearest, of a number of hosts that > can provide the desired information or function. This kind > of host access, however, goes completely unsupported in the > global Internet, and largely unsupported in even private > internets (intranets). This paper proposes an architecture, > called the Host Proximity Service (HOPS) that would allow > for an infrastructure to provide such service. The > architecture proposed here would allow such a service with > no changes to current client or server hosts. > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 08:12:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17852; Wed, 26 Mar 1997 08:04:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17845; Wed, 26 Mar 1997 08:03:54 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA18210; Wed, 26 Mar 1997 08:04:45 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA23161 for ; Wed, 26 Mar 1997 08:08:15 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.7.3) with ESMTP id JAA05506 for ; Wed, 26 Mar 1997 09:04:30 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id JAA04048 for ipng@sunroof.Eng.Sun.COM; Wed, 26 Mar 1997 09:04:29 -0700 (MST) Message-Id: <199703261604.JAA04048@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 26 Mar 1997 09:04:29 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 3408) updated "Advanced Sockets API for IPv6" I-D Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2713 I have just submitted an updated version of this I-D and it should appear in the normal places within the coming days. If you want a copy ASAP, fetch ftp://ftp.kohala.com/pub/rstevens/draft-stevens-advanced-api-02.txt Attached is the list of changes from the previous -01 version. Based on the decreasing number of comments on this draft with each revision, we will ask for any additional comments on this I-D in Memphis and see if it's agreed upon that a last call can be issued. Rich Stevens ----------------------------------------------------------------------- 16. Change History Changes from the February 1997 Edition (-01 draft) - Changed the name of the ip6hdr structure to ip6_hdr (Section 2.1) for consistency with the icmp6hdr structure. Also changed the name of the ip6hdrctl structure contained within the ip6_hdr structure to ip6_hdrctl (Section 2.1). Finally, changed the name of the icmp6hdr structure to icmp6_hdr (Section 2.2). All other occurrences of this structure name, within the Neighbor Discovery structures in Section 2.2.1, already contained the underscore. - The "struct nd_router_solicit" and "struct nd_router_advert" should both begin with "nd6_". (Section 2.2.2). - Changed the name of in6_are_addr_equal to IN6_ARE_ADDR_EQUAL (Section 2.3) for consistency with basic API address testing functions. The header defining this macro is . - getprotobyname("ipv6") now returns 41, not 0 (Section 2.4). - The first occurrence of "struct icmpv6_filter" in Section 3.2 should be "struct icmp6_filter". - Changed the name of the CMSG_LENGTH() macro to CMSG_LEN() (Section 4.3.5), since LEN is used throughout the headers. - Corrected the argument name for the sample implementations of the CMSG_SPACE() and CMSG_LEN() macros to be "length" (Sections 4.3.4 and 4.3.5). - Corrected the socket option mentioned in Section 5.1 to specify the interface for multicasting from IPV6_ADD_MEMBERSHIP to IPV6_MULTICAST_IF. - There were numerous errors in the previous draft that specified that should have been . These have all been corrected and the locations of all definitions is now summarized in the new Section 14 ("Summary of New Definitions"). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 09:23:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17985; Wed, 26 Mar 1997 09:14:33 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17978; Wed, 26 Mar 1997 09:14:29 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18050; Wed, 26 Mar 1997 09:15:22 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA26313; Wed, 26 Mar 1997 09:14:41 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA17797; Wed, 26 Mar 1997 06:46:13 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25653; Wed, 26 Mar 1997 06:47:04 -0800 Received: from ietf.org ([132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA20638 for ; Wed, 26 Mar 1997 06:50:43 -0800 Received: from ietf.ietf.org by ietf.org id aa18627; 26 Mar 97 9:49 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3409) I-D ACTION:draft-ietf-ipngwg-dns-rr-rgadd-00.txt Date: Wed, 26 Mar 1997 09:49:52 -0500 Message-ID: <9703260949.aa18627@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4010 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Synthesis of Routing Goop and AAAA Records in IPv6 Author(s) : J. Bound Filename : draft-ietf-ipngwg-dns-rr-rgadd-00.txt Pages : 5 Date : 03/25/1997 This document is a proposal to redefine the existing DNS AAAA resource record into two resource records: an RG record to define the routing topology of an IPv6 address and an aAA record to define the End System Identifier of an IPv6 address. The document will define the synthesis of the RG and aAA record at the DNS primary server, which will return an AAAA record to DNS resolvers. The objective of this work is to split the AAAA record in the DNS into location and identifier to provide future capabilities for dynamic renumbering of addresses. This work was spawned by the GSE - Alternate Addressing Architecture Proposal for IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-dns-rr-rgadd-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-dns-rr-rgadd-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-dns-rr-rgadd-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970325115137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-rr-rgadd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-rr-rgadd-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970325115137.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 11:00:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18226; Wed, 26 Mar 1997 10:50:44 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18219; Wed, 26 Mar 1997 10:50:36 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA28903; Wed, 26 Mar 1997 10:51:28 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA11673 for ; Wed, 26 Mar 1997 10:55:10 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA08784; Wed, 26 Mar 1997 13:22:06 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20689; Wed, 26 Mar 1997 13:22:00 -0500 Message-Id: <9703261822.AA20689@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com, tkurz@lrc.epfl.ch, leboudec@lrc.epfl.ch, einsiedl@lrc.epfl.ch Subject: (IPng 3410) Excellent Draft on IPv6 Virtual Lans Date: Wed, 26 Mar 97 13:21:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2818 I think we should pursue this work. It also clearly articulates the benefits of IPv6 for Mobile, IP Switching, DHCPv6 as configure tool, and other parts over their existing IPv4 counter parts. This is another reason and benefit of IPv6 over IPv4 customers can think about. This is really good work and has a excellent technical communications and abstractions defined well, as the Header Compression spec does as an example. I attached the Intro and draft name..in cased you missed it on the announce list. Working Group...... Also if you don't know the IAB has sent a request to Bob Hinden and Bob Fink to state the technical benefits of IPv6 over IPv4. I have sent them lots of unsolicited input of course, but this draft should be added to the list for the IAB. p.s. Thorsten, Jean-Yves, Hans ... where do you preceive this work to be discussed. )---> thanks )---> sorry if your on ipngwg list and cc'd you. /jim ------------------------------------------ INTERNET-DRAFT Thorsten Kurz Jean-Yves Le Boudec Hans Joachim Einsiedler LRC, DI-EPFL, Switzerland April 1997 Realizing the Benefits of Virtual LANs by Using IPv6 0. Abstract The benefits that Virtual LANs offer can be realized by using features of an IPv6 network along with small enhancements the IPv6 and DHCPv6 protocol stacks. 1. Introduction Virtual LANs are a widespread special form of LANs (Local Area Networks) enhanced by support for workgroups. A LAN is a collections of hosts which communicate directly on layer 2 without a router between them. All hosts on a LAN share the same layer 3 subnet address, which means communication between the hosts of a LAN remains in the LAN. Thus the layer 3 subnet address forms a broadcast scope which contains all hosts on the LAN. The performance, security and broadcast scope offered by LANs are used to build workgroups i.e. groups of hosts sharing the same servers and resources. Therefore all hosts of a workgroup are attached to the same LAN segment, so that broadcasting can be used for server detection, name resolution and name reservation like as is done by B-nodes in the NetBIOS Protocol [17]. ---------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 13:51:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00328; Wed, 26 Mar 1997 13:41:15 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00317; Wed, 26 Mar 1997 13:40:48 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA08503; Wed, 26 Mar 1997 13:41:43 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA28182 for ; Wed, 26 Mar 1997 13:45:24 -0800 Received: from gungnir.fnal.gov ("port 33010"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGYP5CQRWC000Q8T@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Wed, 26 Mar 1997 15:41:39 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA05968; Wed, 26 Mar 1997 15:41:34 -0600 Date: Wed, 26 Mar 1997 15:41:34 -0600 From: Matt Crawford Subject: (IPng 3411) Router renumbering To: ipng@sunroof.eng.sun.com Message-id: <199703262141.PAA05968@gungnir.fnal.gov> MIME-version: (is)1(your).(UA)0(compliant?) Content-type: multipart/mixed; boundary=mimeprimaryboundary Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain The following first draft version of Router Renumbering has just been sent to the i-d editor, completing the next-to-last of my pending action items. Matt Crawford --mimeprimaryboundary Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipngwg-router-renum-00.txt" Content-Description: draft-ietf-ipngwg-router-renum-00.txt Content-Transfer-Encoding: quoted-printable IPng Working Group Matt Crawford Internet Draft Fermilab Bob Hinden Ipsilon Networks March 26, 1997 Router Renumbering for IPv6 Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. 1. Abstract IPv6 Neighbor Discovery [ND] and Address Autoconfiguration [AA] conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. Expires September 26, 1997 Crawford [Page 1] =0C Internet Draft Router Renumbering March 26, 1997 2. Functional Overview Router Renumbering packets contain a sequence of Prefix Control Operations (PCOs). Each PCO specifies an operation, a Match-Prefix, and zero or more Use-Prefixes. A router processes each PCO in sequence, checking each of its interfaces for an address or prefix which matches the match-prefix. For every interface on which a match is found, the operation is applied. The operation is one of ADD, CHANGE, or SET-GLOBAL to instruct the router to respectively add the Use-Prefixes to the set of configured prefixes, remove the prefix which matched the Match-Prefix and replace it with the Use- Prefixes, or replace all global-scope prefixes with the Use- Prefixes. If the set of Use-Prefixes in the PCO is empty, the ADD operation does nothing and the other two reduce to deletions. Additional information for each use-prefix is included in the Prefix Control Operation: the valid and preferred lifetimes to be included in Router Advertisement Prefix Information Options [ND], and either the L and A flags for the same option, or an indication that they are to be copied from the prefix that matched the match-prefix. It is possible to instruct routers to create new prefixes by combining the use-prefixes in a PCO with some portion of the existing prefix which matched the match-prefix. This simplifies certain operations which are expected to be among the most common. For every use-prefix, the PCO specifies a number of bits which should be copied from the address or prefix which matched the match-prefix and appended to the use-prefix prior to configuring the new prefix on the interface. The copied bits are zero or more bits from the positions immediately beyond the length of the use-prefix. If subnetting information is in the same portion of of the old and new prefixes, this synthesis allows a single Prefix Control Operation to define a new global prefix on every router on a site, while preserving the subnetting structure. Because of the power of the Router Renumbering mechanism, each RR includes a sequence number and an authenticator to guard against replays. Each RR operation is idempotent and so a given message may be retransmitted for improved reliability, as long as its sequence number is current, without concern that it may be processed multiple times. Possibly a site's network manager will want to perform more renumbering, or exercise more detailed control, than can be expressed in a single Router Renumbering packet on the available media. The RR mechanism is most powerful when RR packets are multicast, so IP fragmentation is undesirable. For these reasons, each RR packet contains a "segment number". All RR packets which Expires September 26, 1997 Crawford [Page 2] =0C Internet Draft Router Renumbering March 26, 1997 have a sequence number equal to the highest value seen, and which pass the authentication check, are equally valid and must be processed. However, a router may keep track of the segment numbers of RR messages already processed and avoid reprocessing a message whose sequence number and segment number match a previously processed message. There is also a "Dry Run" indicator which indicates that all routers should process the RR message, but not perform any reconfiguration. It is expected that the effect of an RR message, or the simulated effect of a Dry Run RR message, will be reported to network management by means outside the scope of this document. 3. Definitions 3.1. Requirements Throughout this document, the words that are used to define the significance of the particular requirements are capitalized. These words are: MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. MUST NOT This phrase means the item is an absolute prohibition of this specification. SHOULD This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. MAY This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it Expires September 26, 1997 Crawford [Page 3] =0C Internet Draft Router Renumbering March 26, 1997 enhances the product, for example, another vendor may omit the same item. 3.2. Terminology Address This term always refers to a 128-bit IPv6 address [AARCH]. When referring to bits within an address, they are numbered from 0 to 127, with bit 0 being the first bit of the Format Prefix. Prefix A prefix can be understood as an address plus a length, the latter being an integer in the range 0 to 128 indicating how many leading bits are significant. When referring to bits within a prefix, they are numbered in the same way as the bits of an address. For example, the significant bits of a prefix whose length is L are the bits numbered 0 through L-1, inclusive. Match An address A "matches" a prefix P whose length is L, if the first L bits of A are identical with the first L bits of P. (Every address matches a prefix of length 0.) A prefix P1 with length L1 matches a prefix P2 of length L2 if L1 >=3D L2 and the first L2= bits of P1 and P2 are identical. Prefix Control Operation, Match-Prefix, Use-Prefix These are defined section 2. Matched Prefix The existing prefix or address which matched a Match-Prefix. New Prefix A prefix constructed from a Use-Prefix, possibly including some of the Matched-Prefix. Recorded Sequence Number The highest sequence number found in a valid, authenticated message with a given key MUST be recorded in non-volatile storage along with that key. 3.3. Authentication Algorithms All implementations MUST support Keyed MD5 [MD5] for authentication. Additional algorithms MAY be supported. Expires September 26, 1997 Crawford [Page 4] =0C Internet Draft Router Renumbering March 26, 1997 4. Message Format / / | IPv6 header, extension headers | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / | ICMPv6 RR Header (16 octets) | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / | Zero or more PCOs (variable length) | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / | Authentication Data (16 octets for MD5) | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router Renumbering messages are carried in ICMP packets with Type =3D= TBA. The RR message consists of An RR header, containing the sequence and segment numbers and information about the authentication key and the location and length of the authentication data within the packet; A sequence of Prefix Control Operations, each of variable length; The authentication data, with length dependent on the authentication type. For Keyed MD-5, 16 octets. All fields marked "unused" MUST be set to zero on generation of an RR message. During processing of the message they MUST be included in the authentication check, but otherwise ignored. All implementations which generate Router Renumbering messages MUST support sending them to the All Routers multicast address with Link Local and Site Local scopes, and to unicast addresses of site local and link local formats. All routers MUST be capable of receiving RR messages sent to those multicast addresses and to any of their link local and site local unicast addresses. Implementations MAY support sending and receiving RR messages addressed to other unicast addresses. Expires September 26, 1997 Crawford [Page 5] =0C Internet Draft Router Renumbering March 26, 1997 4.1. Router Renumbering Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SegmentNumber | KeyID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AuthLen | AuthOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SequenceNumber | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA, the ICMP type code assigned to Router Renumbering Code 0 for a normal RR message 1 to indicate a "Dry Run" message. If set to 1, the operations specified in this message SHOULD be simulated, but MUST NOT be not carried out. SegmentNumber An unsigned 15-bit field which enumerates different valid RR messages having the same SequenceNumber and KeyID. KeyID An unsigned 16-bit field that identifies the key used to create and verify the Authentication Data for this RR message. If multiple authentication algorithms are supported by the implementation, the choice of algorithm is implicit in the KeyID. AuthLen An unsigned 16-bit field giving the length in octets of the Authentication Data. AuthOffset An unsigned 16-bit offset, measured in octets, from the beginning of the RR message to the beginning of the Authentication Data. SequenceNumber An unsigned 32-bit sequence number. The sequence number MUST be non-decreasing for all messages sent with the same KeyID. Expires September 26, 1997 Crawford [Page 6] =0C Internet Draft Router Renumbering March 26, 1997 4.2. Prefix Control Operation A Prefix Control Operation has one Match-Prefix Part of 24 octets, followed by zero or more Use-Prefix Parts of 32 octets each. 4.2.1. Match-Prefix Part 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode | OpLength | unused | MatchLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- MatchPrefix -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: OpCode An unsigned 8-bit field specifying the operation to be performed when the associated MatchPrefix matches an interface's prefix or address. Values are: 1 the ADD operation 2 the CHANGE operation 3 the SET-GLOBAL operation OpLength The total length of this Prefix Control Operation, in units of 8 octets. A valid OpLength will always be of the form 4N+3, with N equal to the number of UsePrefix parts (possibly zero). MatchLen An 8-bit unsigned integer between 0 and 128 inclusive specifying the number of initial bits of MatchPrefix which are significant in matching. MatchPrefix The 128-bit prefix to be compared with each interface's prefix or address. Expires September 26, 1997 Crawford [Page 7] =0C Internet Draft Router Renumbering March 26, 1997 4.2.2. Use-Prefix Part 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UseLen | KeepLen | Mask | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V|P| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- UsePrefix -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: UseLen An 8-bit unsigned integer less than or equal to 128 specifying the number of initial bits of UsePrefix to use in creating a new prefix for an interface. KeepLen An 8-bit unsigned integer less than or equal to (128- UseLen) specifying the number of bits of the prefix or address which matched the associated Match-Prefix which should be retained in the new prefix. The retained bits are those at positions UseLen through (UseLen+KeepLen-1) in the matched address or prefix, and they are copied to the same positions in the New Prefix. Mask An 8-bit mask. A 1 bit in any position means that the corresponding flag bit in a Router Advertisement (RA) Prefix Information Option should be set from the Flags field in this Use-Prefix Part. A 0 bit in the Mask means that the RA flag bit should be unchanged by this operation. Flags An 8 bit field which, under control of the Mask field, may be used to initialize the flags in Router Advertisement Prefix Information Options which advertise the New Prefix. Note that only two flags as defined meanings to date: the L (on-link) and A (autonomous Expires September 26, 1997 Crawford [Page 8] =0C Internet Draft Router Renumbering March 26, 1997 configuration) flags. Valid Lifetime A 32-bit unsigned integer which is the number of seconds for which the New Prefix will be valid [ND, SAA]. Preferred Lifetime A 32-bit unsigned integer which is the number of seconds for which the New Prefix will be preferred [ND, SAA]. V A 1-bit flag indicating that the valid lifetime of the New Prefix MUST be effectively decremented in real time. P A 1-bit flag indicating that the preferred lifetime of the New Prefix MUST be effectively decremented in real time. UsePrefix The 128-bit Use-prefix which either becomes or is used in forming (if KeepLen is nonzero) the New Prefix. It MUST NOT have the form of a multicast or link-local address [AARCH]. 4.3. Authentication -- Keyed MD5 When the key and algorithm associated with the KeyID indicate that Keyed MD5 authentication is to be used, the authentication data is generated in accordance with RFC 1321 [MD5]: All fields of the RR header and all the PCOs are filled in. AuthLen will be 16 and AuthOffset will be equal to the length in octets of the RR packet, not including any IPv6 headers. Let RRLength denote that length, which will always be a multiple of 8. The 16 octets of MD5 secret are appended to the RR message, followed by 8 to 64 octets of padding, enough to make the sum of the number of octets in the message, the secret and the padding equal to 56, modulo 64. (The number of octets of padding will be 8 + ((48- RRLength) modulo 64).) The value of the padding will be a single octet with value 80 hexadecimal followed by octets of zeros. Next, the MD5 length is appended, as a 64-bit value, with the most significant 32-bit word first. This length is counted in bits and includes the secret, but not not the padding. This it will be equal to 8*RRLength+128. Finally, the MD5 digest is computed and the result replaces the secret in its position immediately afer the last PCO. The padding Expires September 26, 1997 Crawford [Page 9] =0C Internet Draft Router Renumbering March 26, 1997 and the MD5 length are discarded, as they can be reconstructed by the receiver. The transmitted message includes everything through the MD5 digest only. 5. Message Processing Processing of received Router Renumbering messages consists of three parts: header check, authentication check, and execution. 5.1. Header Check First, the existence and validity of the key indicated by the KeyID are checked. If there is no such valid key, or if the value of AuthLen is not correct for that key, the message MUST be discarded, and SHOULD be logged to network management. Next, the SequenceNumber is compared to the Recorded Sequence Number for the specified key. (If no messages have been received using this key, the recorded number is zero.) This comparison is done with the two numbers considered as simple non-negative integers, not as DNS-style serial numbers. If the SequenceNumber is less than the Recorded Sequence Number for the key, the message MUST be discarded and SHOULD be logged to network management. Finally, if the SequenceNumber in the message is equal to the Recorded Sequence Number, the SegmentNumber MAY be checked. If a correctly authenticated message with the same KeyID, SequenceNumber and SegmentNumber has already been processed, the current message MAY be discarded. If it is discarded, it SHOULD NOT be logged to network management. 5.2. Authentication Check The authentication check is performed over the RR message, without any IP, ICMP or extension headers. In the case of Keyed MD5 it proceeds as follows. First, the authentication data octets are saved, then that portion of the packet is replaced with the MD5 secret. The padding and length fields are appended just as during message generation, and the MD5 digest is computed and compared to the saved value. If the computed digest is not equal to the saved authentication data, the authentication check fails. If the authentication check fails, the message MUST be discarded and SHOULD be logged to network management. Expires September 26, 1997 Crawford [Page 10] =0C Internet Draft Router Renumbering March 26, 1997 If the authentication check passes, and the SequenceNumber is greater than the Recorded Sequence Number for the key, then the list of processed SegmentNumbers, if any, MUST be cleared and the Recorded Sequence Number MUST be updated to the value used in the current message, regardless of subsequent processing errors. 5.3. Execution THIS SECTION IS NOT YET COMPLETED. After succesful processing of all the Prefix Control Operations, an implementation MAY record the SegmentNumber of the packet in a list associated with the KeyID and SequenceNumber. 6. Key Management As with all security methods using keys, it is necessary to change the RR Authentication Key on a regular basis. To provide RR functionality during key changes, implementations MUST be able to store and use more than one Authentication Key at the same time. The Authentication Keys SHOULD NOT be stored or transmitted using algorithms or protocols that have known flaws. Implementations MUST support the storage of more than one key at the same time, MUST associate a specific lifetime (start and end times) and a key identifier with each key, and MUST support manual key distribution (e.g., manual entry of the key, key lifetime, and key identifier on the router console). An infinite key lifetime SHOULD NOT be allowed. If infinite lifetimes are allowed, manual deletion of valid keys MUST be supported; otherwise manual deletion SHOULD be supported. The implementation MAY automatically delete expired keys. 7. Usage Guidelines Using a new authentication key while a previously used key is still valid can open the possibility of a replay attack. The processing rules as given in section 5. specify that routers keep track of the highest sequence number seen for each key, and that messages with that key and seuence number remain valid until either a higher sequence number is seen or the key expires. The difficulty arises when a new key is used to send a message which supersedes the last message sent with another still-valid key. That older message can still be replayed. Expires September 26, 1997 Crawford [Page 11] =0C Internet Draft Router Renumbering March 26, 1997 This vulnerability can be avoided in practice by sending a "NO-OP" message with the old key and a valid new sequence number before using a newer key. This mesage will then become the only one which can be replayed with the old key. An example of a NO-OP message would be one which contains no Prefix Control Operations. Cearly a management station must keep track of the highest sequence number it has used for any authentication key, at least to the extent of being able to generate a larger value when needed. A timestamp may make a good sequence number. 8. Points for Discussion Does the site-local all-routers multicast address exist? RFC1884 sort of glosses over that. If it doesn't, we need a new multicast address to be assigned. The "unusued" fields of the MatchPart could be used to specify another condition in addition to matching a prefix. For example, one of the prefix lifetime timers could be tested against a value. If the messages of several different protocols use the same authentication mechanism, as this draft tries to emulate the Keyed-MD5 authentication proposed for RIPv2, then it's possible for one authenticated message body to be grafted onto a different set of headers and cause at least some confusion, and possibly worse. This can be prevented by placing magic numbers or other fixed data in the packets so that a packet for one protocol is never valid for another. Since RR messages will presumably be generated only by a set network management stations which is disjoint from the set of routers to which they are directed, an asymmetric authentication scheme would be desirable. 9. Security Considerations The Router Renumbering mechanism proposed here is very powerful and prevention of spoofing it is important. Replay of old messages must be prevented, except in the narrow case of idempotent messages which are still valid at the time of replay. We believe the authentication mechanisms included in this specification achieve the necessary protections, so long as authentication keys are not Expires September 26, 1997 Crawford [Page 12] =0C Internet Draft Router Renumbering March 26, 1997 compromised. Authentication keys must be as well protected as is any other access method that allows reconfiguration of a site's routers. Distribution of keys must not expose them or permit alteration, and key lifetimes must be limited. 10. Acknowledgments Some of the key management text was borrowed from "RIP-II MD5 Authentication." (And the loan was repaid in kind.) 11. References [AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 1884. [MD5] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321. [ND] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970. [SAA] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971. 12. Authors' Addresses Matt Crawford Robert M. Hinden Fermilab MS 368 Ipsilon Networks, Inc. PO Box 500 232 Java Drive Batavia, IL 60510 Sunnyvale, CA 94089 USA USA Phone: +1 630 840 3461 Phone: +1 408 990 2004 Email: crawdad@fnal.gov Email: hinden@ipsilon.com Expires September 26, 1997 Crawford [Page 13] --mimeprimaryboundary-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 14:58:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00482; Wed, 26 Mar 1997 14:46:48 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00475; Wed, 26 Mar 1997 14:46:39 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA25543; Wed, 26 Mar 1997 14:47:33 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA29108 for ; Wed, 26 Mar 1997 14:51:16 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id OAA24956; Wed, 26 Mar 1997 14:47:33 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA13021; Wed, 26 Mar 1997 14:43:03 -0800 (PST) Date: Wed, 26 Mar 1997 14:43:03 -0800 (PST) Message-Id: <199703262243.OAA13021@pedrom-ultra.cisco.com> From: Pedro Marques To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3412) Router renumbering In-Reply-To: <199703262141.PAA05968@gungnir.fnal.gov> References: <199703262141.PAA05968@gungnir.fnal.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 944 >>>>> "Matt" == Matt Crawford writes: Matt> This document defines a mechanism called Router Matt> Renumbering ("RR") which allows address prefixes on routers Matt> to be configured and reconfigured almost as easily as the Matt> combination of Neighbor Discovery and Address Matt> Autoconfiguration works for hosts. It provides a means for Matt> a network manager to make updates to the prefixes used by Matt> and advertised by IPv6 routers throughout a site. Matt, the idea seams very usefull but why did you choose to implement this as a protocol on top of icmp and not as an SNMP MIB ? regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 16:35:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00783; Wed, 26 Mar 1997 16:25:33 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00776; Wed, 26 Mar 1997 16:25:20 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA20892; Wed, 26 Mar 1997 16:26:14 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA08617 for ; Wed, 26 Mar 1997 16:29:59 -0800 Received: from gungnir.fnal.gov ("port 33021"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGYUWFBG7W000Q8T@FNAL.FNAL.GOV> for ipng@sunroof.eng.sun.com; Wed, 26 Mar 1997 18:26:14 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id SAA06525; Wed, 26 Mar 1997 18:26:10 -0600 Date: Wed, 26 Mar 1997 18:26:10 -0600 From: Matt Crawford Subject: (IPng 3413) IPv6 "Who-Are-You?" To: ipng@sunroof.eng.sun.com Message-id: <199703270026.SAA06525@gungnir.fnal.gov> MIME-version: 1.0 Content-type: multipart/mixed; boundary=mimeprimaryboundary Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain Well, I sent this in on the deadline day, but I didn't know there was an east-coast deadline hour. So it didn't make it. The upside is *maybe* I'll flesh it out before Memphis and post it to the list again. This was a PAL1 action item. Matt Crawford --mimeprimaryboundary Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipngwg-icmp-name-lookups-00.txt" Content-Description: draft-ietf-ipngwg-icmp-name-lookups-00.txt Content-Transfer-Encoding: quoted-printable IPng Working Group Matt Crawford Internet Draft Fermilab March 26, 1997 IPv6 Name Lookups Through ICMP Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. 1. Abstract IPv4 addresses are translated to fully-qualified domain names (FQDNs) using the DNS. Experience shows that the IN-ADDR.ARPA zones used for this translation tend to be poorly maintained in some cases. In a larger internet with more frequent site renumbering, the maintenance of such zones will be even more difficult. This document describes a protocol for simply asking an IPv6 node to supply its FQDN when needed. The DNS style of delegation is thus eliminated for authority IPv6 address-to-name translations and the routing infrastructure plays that role. Expires September 26, 1997 Crawford [Page 1] =0C Internet Draft Who Are You March 26, 1997 2. ICMPv6 FQDN Messages There are two ICMPv6 [1885] FQDN message, the FQDN Query and the FQDN Reply. They have the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-To-Live | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NameLen | FQDN ... | +-+-+-+-+-+-+-+-+ + / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA1 - FQDN Query (more pronouncably known as Who-Are- You or WRU). TBA2 - FQDN Reply (possibly to be known as Sam-I-Am). Code For FQDN Query, always zero. For FQDN Reply: 0 Indicates that the Time-To-Live field is meaningful 1 Indicates that the responding node cannot provide a meaningful TTL for its Address-to-FQDN association. Checksum The ICMPv6 checksum. ID A 16-bit field to aid in matching replies and requests. Its value is chosen by the querier and copied from a Request to a Reply by the responder. Cookie An opaque 64-bit field to aid in avoiding spoofing. Its value is chosen by the querier and copied from a Request to a Reply by the responder. Expires September 26, 1997 Crawford [Page 2] =0C Internet Draft Who Are You March 26, 1997 Time-To-Live The number of seconds that the name may be cached. For compatibility with DNS [1035], this is a 32-bit signed, 2's-complement number, which must not be negative. NameLen The length in octets of the FQDN, as an 8-bit unsigned integer. FQDN The fully-qualified domain name of the responder, as a sequence of NameLen US-ASCII octets, with periods between the components. The last three fields (Time-To-Live, NameLen and FQDN) are not present in the FQDN Query. 3. Usage The querier constructs an ICMP FQDN Query and sends it to the address whose FQDN is wanted. The ID field's value is chosen for the querier's convenience, and the Cookie should be a random or good pseudo-random value to foil spoofed replies. The responder must fill in the TTL field of the Reply with a meaningful value if possible. That value might be the remaining lifetime of a DHCP lease or the remaining Valid Lifetime of a prefix from which the address was derived through Stateless Autoconfiguration [1970, 1971]. To avoid congesting the internet with ICMP FQDN messages, they should be sent only by a system capable of caching the replies, preferably on behalf of many other potential queriers. A logical to do that caching is in DNS servers. Accordingly, these messages should be used as a "back end" to DNS servers, which can then present clients with an unchanged interface to the FQDN-lookup service. (Or, the independence from DNS-style delegation can be exploited to simplify that interface.) 4. Discussion Because a node can only answer a WRU when it is up and reachable, it may be useful to be able to create a proxy responder for a group of nodes, for example a subnet or a site. Such a mechanism is not addressed here. The responder code may be slightly simplified if the Query is required to have the last three fields present, with 255 octets of Expires September 26, 1997 Crawford [Page 3] =0C Internet Draft Who Are You March 26, 1997 space for the FQDN. The interface between WRU and DNS should be specified here. A simpler interface could be provided to the client by having the DNS server translate PTR queries in a new pseudo-domain for names such as "5F01250083E100000009080020812B32.IP6" into WRU queries. IPsec could be applied to FQDN messages to achieve greater trust in the information obtained, but such a need is probably obviated by applying IPsec directly to some other communication which is going on (or contemplated) between the querier and responder. The FQDN could be transmitted in DNS series-of-labels form, but why? With just a single name allowed as an aswer, we're not after name compression. What does the querier do when there's no meaningful TTL in the reply? 5. Acknowledgments This document is not the first proposal of a direct query mechanism for address-to-name translation. The idea was discussed and deferred in the IPng working group and an experimental RFC [1788] describes such a mechanism for IPv4. 6. References [1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, STD 13. [1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788. [1885] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 1885. [1970] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970. [1971] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971. Expires September 26, 1997 Crawford [Page 4] =0C Internet Draft Who Are You March 26, 1997 7. Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 630 840 3461 Email: crawdad@fnal.gov Expires September 26, 1997 Crawford [Page 5] --mimeprimaryboundary-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 18:48:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01053; Wed, 26 Mar 1997 18:38:00 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01046; Wed, 26 Mar 1997 18:37:36 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA16388; Wed, 26 Mar 1997 18:38:27 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14510; Wed, 26 Mar 1997 18:38:29 -0800 Date: Wed, 26 Mar 1997 18:38:29 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199703270238.SAA14510@bobo.eng.sun.com> To: crawdad@FNAL.GOV Subject: (IPng 3414) Re: Router renumbering Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2993 It is very good that this is being written down. Here are some questions and comments. The document appears to cover reconfiguration but not configuration. Would it be benefitial to add the capability of a new router to request the set of prefixes? Granted that even if such a mechanism is created the new router would still have to be configured with the subnet number part of the prefixes for all its interfaces. But at least the network admin doesn't have to type in all the global prefixes for each new router. The document seems to say that the operations are idempotent which I don't think is true. For instance if I have nodes that use prefix P1 and P2 (but not P3) and I send the sequence: CHANGE prefix P1 to prefix P3 CHANGE prefix P2 to prefix P1 CHANGE prefix P3 to prefix P2 I've accomplished a swap between P1 and P2. Applying this multiple times does not do the same thing as applying it once. Thus there seems to be a lot of opportunity to mess things if routers come and go while these changes are in progress. An alternative would be to: - Periodically advertise all the active prefixes and their lifetimes much like ND router advertisements. This handles additions and deletions. - When there is a prefix change include a change operation in the periodic messages. This change operation must be continously sent until the valid lifetime for the original prefix(es) have expired. This would allow a router to miss an arbitrary number of messages and still not end up with an inconsistent set of prefixes - worst case it would have a subset of the prefixes that are in use. Also, such a scheme would make it impossible to do a second change (like in my swap example above) until the lifetime of the original prefixes has run out i.e. there is less risk of confusion. BTW: Isn't SET-GLOBAL identical to a CHANGE with MatchLen = 0? It seems like the replay protection mechanisms assume that: - when a new router is installed and configured it has to be configured with the current Recorded Sequence Number in order for replay protection to work. - either the RR messages are sent by a single node or that the nodes sending them have to coordinate the sequence numbers since there is only a single Recorded Sequence Number used to check for replays (as far as I can tell). Isn't is possible to rely of an appropriate authentication algorithm for replay protection plus AH headers to avoid adding specific mechanisms to the RR? It seems like if DHCP server hand out stateful addresses they should also be able to receive the RR messages. Using a site-local all-routers address might lead folks to believe that DHCP servers can not "listen in". Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Wed Mar 26 21:57:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA01254; Wed, 26 Mar 1997 21:46:35 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA01247; Wed, 26 Mar 1997 21:46:23 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA05888; Wed, 26 Mar 1997 21:47:16 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAA03308 for ; Wed, 26 Mar 1997 21:51:04 -0800 Received: by mail.noris.net id <35231-15174>; Thu, 27 Mar 1997 06:47:14 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3415) Re: Router renumbering Date: 27 Mar 1997 06:47:04 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 29 Message-ID: <5hd1ko$lta$1@work.smurf.noris.de> References: <199703262141.PAA05968@gungnir.fnal.gov> <199703262243.OAA13021@pedrom-ultra.cisco.com> <859418137.9963@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1660 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1636 In dist.ipng, article <859418137.9963@noris.de>, Pedro Marques writes: > >>>>> "Matt" == Matt Crawford writes: > > the idea seams very usefull but why did you choose to implement this > as a protocol on top of icmp and not as an SNMP MIB ? As an ISP, I could use the RR packet to send an automagic "use this prefix" message to my customer's routers. That'd simplify auto- and reconfiguration tremendously. I don't think the customer would let me remote-configure their router with SNMP. I could do too many other things to that router. Autogenerating a correct SNMP message for this kind of operation is difficult and would probably be a multi-step process, which won't work -- the directly-connected router would have its global address autoconfigured with PPP, presumably, but not all the others behind it. -- When a girl ceases to blush, she has lost the most powerful charm of her beauty. -- Gregory I -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 02:35:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA01464; Thu, 27 Mar 1997 02:24:07 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA01457; Thu, 27 Mar 1997 02:23:57 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA01752; Thu, 27 Mar 1997 02:24:51 -0800 Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id CAA00284 for ; Thu, 27 Mar 1997 02:28:41 -0800 Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id LAA12424; Thu, 27 Mar 1997 11:22:16 +0100 Received: from smtprelay.nl.cis.philips.com(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma012283; Thu Mar 27 11:21:35 1997 Received: from hades.mpn.cp.philips.com (hades.mpn.cp.philips.com [130.139.64.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970305) with ESMTP id LAA20964; Thu, 27 Mar 1997 11:21:34 +0100 Received: from pc239.nwm.wan.philips.com (pc239.nwm.wan.philips.com [161.89.1.239]) by hades.mpn.cp.philips.com (8.6.10/8.6.10-1.2a-960910) with SMTP id LAA08596; Thu, 27 Mar 1997 11:20:22 +0100 Message-Id: <1.5.4.32.19970327101944.00abfc8c@hades.mpn.cp.philips.com> X-Sender: rhunter@hades.mpn.cp.philips.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 1997 11:19:44 +0100 To: Jack McCann From: Ray Hunter Subject: (IPng 3417) Re: Host Reachability Advertisement for IPv6 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4080 At 11:38 AM 3/25/97 -0500, you wrote: > >A new draft should be showing up shortly in the Internet-Drafts >directories: Can you explain something to me? When does it make sense for a multi-homed host to send reachability information out of the other interfaces? Can't you always just create an internal virtual/loopback interface and advertise that out of both interfaces via a proper routing protocol? I can see the attraction of HRA in that it is lightweight to run on the host. However, HRA as documented in the draft strikes me as being very dangerous, because it is an asymmetric operation between the router and the host. It's a routing protocol in that it can update tables in a router, but it's not complete because it cannot update tables in the sender. There is thus potential for two different reachability measures to conflict (even if only temporarily). What happens in the following scenario...? HRA(src=fe80::a1, address1=2::a) ------------------------------------------------------ Link 1 fe80::a1 | 1::a | +-----+ +-----+ | A | | R |---- network +-----+ +-----+ fe80::a2 | 2::a | ------------------------------------------------------ Link 2 HRA(src=fe80::a2, address1=1::a) Say all interfaces are up physically. Say a bridge (level 2 device) fails between the router and the host in link2. HRA's are not then sent to the router, although the host thinks it has sent them. The router waits 4 update times before timing out the route. In the meantime, what is NUD doing? Does the host know that the link to the router has failed via HRA? No, because there is no reverse advertisement from the router for this particular protocol. How else then does the host learn of this type of failure? Here's the danger: the host will learn the link is down by a different method from the router. There is great potential here for routing loops or unnecessary black holing of packets. Where a mechanism does make sense is the scenario of high reliability. Say you have 2 routers with WAN links, AND 2 hosts sharing a disk array and 2 LANs. In this case, all you care about is that pseudo ip address 1 (shared between the 2 hosts) can talk to pseudo ip address 2 (shared between the 2 routers), and that one of the hosts back off from controlling the common disc. --------------------------------------------------------- Link 1 | | | | +-----+ +-----+ +-----+ +-----+ | A |--disc--| B | | R1 |-- network--| R2 | +-----+ +-----+ +-----+ +-----+ | | | | --------------------------------------------------------- Link 2 This is VERY difficult to do with IPv4, and relies on pseudo MAC addresses and horrible proprietary protocols which are different on the host and routers (e.g. Sun assumes everything is a bridge, and re-assigns MAC addresses in the high reliability product, Cisco assumes everything is Cisco, and talks HSRP) If you could demonstrate how this works by say using anycast addresses rather than changing MAC addresses, then that's a very clear win for IPv6. I suspect it's a lot more difficult than you imagine! best regards, Ray Hunter on contract to Origin Building VA-130, Postbus 218, 5600MD Eindhoven, The Netherlands. email: Ray.Hunter@mpn.cp.philips.com email: Ray.Hunter@globis.net www: http://www.globis.net/~rhunter phone: +31 40 2787988 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 03:03:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA01480; Thu, 27 Mar 1997 02:50:15 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA01473; Thu, 27 Mar 1997 02:50:03 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA03861; Thu, 27 Mar 1997 02:50:57 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA05014 for ; Thu, 27 Mar 1997 02:54:47 -0800 Received: from shand.reo.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id FAA26198; Thu, 27 Mar 1997 05:49:19 -0500 (EST) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA06449; Thu, 27 Mar 1997 10:49:17 GMT Message-Id: <9703271049.AA06449@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Cc: shand@shand.reo.dec.com, mccann@zk3.dec.com Subject: (IPng 3418) Re: Host Reachability Advertisement for IPv6 In-Reply-To: Your message of "Tue, 25 Mar 97 11:38:57 EST." <9703251638.AA00137@wasted.zk3.dec.com> Date: Thu, 27 Mar 97 10:49:17 +0000 From: (Mike Shand REO2 F/D9 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3514 Jack, As you might guess, I rather like this idea. Presumably the intent is that (in the multicast case), the advertisements of the "host routes on the wrong subnet" are installed in the router such that they do NOT get higher preference than the subnet routes. Note that this would not happen naturally, since in general a router will select a longer prefix route, and the host routes will be longer prefix than the natrual subnet routes. This of course wouldn't be necessary if the multihomed host advertised both interface addresses on both interfaces (i.e. including a host route on the LAN which contains the natural subnet as well). In your appendix A you list two questions. 1) should there be a way to say an address is no longer reachable. I rather favour putting a holding time in the advertisement for each address (you can see where I'm coming from :-), rather than relying on the router to time it out. I'm somewhat wary of having a "protocol constant" to determine this. For example, if you have a very high reliability scenario you may want the information to time out (and also be refreshed) much more rapidly. This time would (typically) be determined by the individual host. I'm less convinced about the need to have individual addresses with different timeout periods, but I do think you might need the facility to withdraw an address independantly. One way of doing this with a single timer per advertisement would be to send an advertisment with a very short timeout (for all the addresses) followed by one with a longer timeout for all the ones but the one you want to loose. Its probably important to have some mechanism whereby a router can quickly get a refresh of the address availablility state without haveing to wait for a long timeout. i.e. you should be able do somthing like the following 1) router knows about a bunch of addresses with 3 minutes expiry 2) router sets expiry down to a few seconds 3) router send a solicitation 4) any hosts that don't rely within the new expiry loose their addresses. or does this get handled by the router doing NUD? Trouble is you may need a sort of global NUD. You may detect that I have in the back of my mind the ES configuration solicitation of IS-IS :-) Maybe this is not important. 2. Should the addresses carry some sort of metric information? Maybe. This is somewhat related to my point about the relative prefix lengths (which is sort of implicit metric). Metrics would certianly allow a host to say Well you can reach me here, there or over this, but I'd prefer you to reach me here. Is that useful? Maybe. Suppose the host has two interfaces, one is a high speed, and the other is slow (I'd normally say FDDI and Ethernet, but I suppose I'd better come up to date and say Gbit Ethernet and Fast Ehternet :-) The router would naturally (perhaps) prefer the faster interface. But the host might be advertising an address which is to be used for management purposes which has a policy requirement that the traffic is kept off the high speed production time critical LAN of at all possible. Hence you might want to modify the router's natural path selection. This triggers the thought... Why aren't you using RIP for all this stuff? Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 04:08:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA01553; Thu, 27 Mar 1997 03:59:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA01546; Thu, 27 Mar 1997 03:58:42 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA08870; Thu, 27 Mar 1997 03:59:34 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA16354 for ; Thu, 27 Mar 1997 04:03:26 -0800 Received: from shand.reo.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id GAA26309; Thu, 27 Mar 1997 06:52:00 -0500 (EST) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA06556; Thu, 27 Mar 1997 11:51:50 GMT Message-Id: <9703271151.AA06556@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Cc: shand@shand.reo.dec.com Subject: (IPng 3419) Re: Host Reachability Advertisement for IPv6 In-Reply-To: Your message of "Thu, 27 Mar 97 11:19:44 +0100." <1.5.4.32.19970327101944.00abfc8c@hades.mpn.cp.philips.com> Date: Thu, 27 Mar 97 11:51:50 +0000 From: (Mike Shand REO2 F/D9 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1412 Ray, > Does the host know that the link to the router has failed via HRA? > No, because there is no reverse advertisement from the router > for this particular protocol. > > How else then does the host learn of this type of failure? > I suspect it uses NUD > Here's the danger: the host will learn the link is down by > a different method from the router. There is great potential > here for routing loops or unnecessary black holing of packets. While it is desirable that all nodes should simultaneously discover the new topology when a link fails, this is generally unachievable and we have to live with the consequences (temporary loops, blackholes) in most routing protocols. I don't see that this is particulalry different from the case where you have a symmetric protocol which happens to detect failure at different times. The piece which isn't discussed here of course is how the host selects its interface for outbound traffic, and I agree that can be a hard problem. (see my old multihoming draft). > I suspect it's a lot more difficult than you imagine! I'm hoping its a lot easier than *I* imagine :-) Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 09:43:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02039; Thu, 27 Mar 1997 09:31:38 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02032; Thu, 27 Mar 1997 09:31:29 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA11682; Thu, 27 Mar 1997 09:32:24 -0800 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA12686 for ; Thu, 27 Mar 1997 09:36:18 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by trix.cisco.com (8.6.12/8.6.5) with ESMTP id JAA10046; Thu, 27 Mar 1997 09:32:23 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA13845; Thu, 27 Mar 1997 09:27:38 -0800 (PST) Date: Thu, 27 Mar 1997 09:27:38 -0800 (PST) Message-Id: <199703271727.JAA13845@pedrom-ultra.cisco.com> From: Pedro Marques To: smurf@noris.de (Matthias Urlichs) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3421) Re: Router renumbering Newsgroups: dist.ipng In-Reply-To: <5hd1ko$lta$1@work.smurf.noris.de> References: <199703262141.PAA05968@gungnir.fnal.gov> <199703262243.OAA13021@pedrom-ultra.cisco.com> <859418137.9963@noris.de> <5hd1ko$lta$1@work.smurf.noris.de> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 987 >>>>> "Matthias" == Matthias Urlichs writes: Matthias> In dist.ipng, article <859418137.9963@noris.de>, Pedro Matthias> Marques writes: >> >>>>> "Matt" == Matt Crawford writes: >> >> the idea seams very usefull but why did you choose to implement >> this as a protocol on top of icmp and not as an SNMP MIB ? Matthias> As an ISP, I could use the RR packet to send an Matthias> automagic "use this prefix" message to my customer's Matthias> routers. That'd simplify auto- and reconfiguration Matthias> tremendously. Put it the other way... Would you accept such packets from an upstream provider ? ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 09:55:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02051; Thu, 27 Mar 1997 09:42:13 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02044; Thu, 27 Mar 1997 09:42:08 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA14084; Thu, 27 Mar 1997 09:43:05 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28049; Thu, 27 Mar 1997 09:42:23 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA01407; Thu, 27 Mar 1997 01:16:37 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA25625; Thu, 27 Mar 1997 01:17:31 -0800 Received: from mimesweeper.integralis.co.uk (mimesweeper.integralis.co.uk [193.122.60.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA16844 for ; Thu, 27 Mar 1997 01:21:19 -0800 Date: Thu, 27 Mar 1997 01:21:19 -0800 Received: from integd.integralis.co.uk (unverified [193.128.143.14]) by mimesweeper.integralis.co.uk (Integralis SMTPRS 2.02) with SMTP id ; Thu, 27 Mar 1997 09:20:06 +0000 Received: from justin ([193.128.143.160]) by INTEGD.INTEGRALIS.CO.UK (PMDF V5.1-7 #8244) with ESMTP id <01IGZQ2VQIIG0019GR@INTEGD.INTEGRALIS.CO.UK> for ipng@sunroof.Eng.Sun.COM; Thu, 27 Mar 1997 09:18:42 GMT Content-return: allowed From: IPng Mailing List Subject: (IPng 3422) Re: IPng Interim Meeting Minutes To: ipng@sunroof.eng.sun.com Reply-To: ipng@INTEGRALIS.CO.UK Message-Id: <3339CA46.5F50@integralis.com> Organization: INTEGRALIS MIME-Version: 1.0 X-Mailer: Mozilla 4.0b2 (WinNT; I) Content-Type: MULTIPART/MIXED; BOUNDARY="Boundary_[ID_zawiKCVID+anLKkNoWj1NA]" X-Priority: 3 (Normal) References: <01IGYTQPE7QM00167U@INTEGD.INTEGRALIS.CO.UK> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2027 This is a multi-part message in MIME format. --Boundary_[ID_zawiKCVID+anLKkNoWj1NA] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Justin.Clark@integralis.co.uk wrote: I've been background to this mailing list and have come across two terms, ESD and 8+8 that, I cannot find any reference to in the IPng-related RFCs. Please could someone tell me what both 8+8 and ESD are about (ESD is InterfaceID/MAC address related right?). Is this cultivated jargon or have I missed out on a valuable source somewhere? Thanks in advance Justin Clark INTEGRALIS ________________________________________________________ MIMEsweeper has scanned this message and its attachments and found it to be free of all known viruses. info@Integralis.com http://www.integralis.com Innovation, Integration, Integralis ________________________________________________________ --Boundary_[ID_zawiKCVID+anLKkNoWj1NA] Content-Type: text/x-vcard; name=nsmailAE.TMP; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: Card for Justin Clark Content-Disposition: attachment; filename=nsmailAE.TMP BEGIN:VCARD FN:Justin Clark N:Clark;Justin ORG:INTEGRALIS EMAIL;INTERNET:ipng@integralis.com TITLE:Product Management NOTE:IPng Mailing List X-MOZILLA-HTML:T END:VCARD --Boundary_[ID_zawiKCVID+anLKkNoWj1NA] Content-Type: text/x-vcard; name=nsmailHH.TMP; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: Card for Justin Clark Content-Disposition: attachment; filename=nsmailHH.TMP BEGIN:VCARD FN:Justin Clark N:Clark;Justin ORG:INTEGRALIS EMAIL;INTERNET:ipng@integralis.com TITLE:Product Management NOTE:IPng Mailing List X-MOZILLA-HTML:T END:VCARD --Boundary_[ID_zawiKCVID+anLKkNoWj1NA]-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 10:30:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02261; Thu, 27 Mar 1997 10:13:11 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02254; Thu, 27 Mar 1997 10:13:06 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18493; Thu, 27 Mar 1997 10:14:03 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA28144; Thu, 27 Mar 1997 10:13:21 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA01834; Thu, 27 Mar 1997 06:57:47 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01005; Thu, 27 Mar 1997 06:58:41 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA04475 for ; Thu, 27 Mar 1997 07:02:34 -0800 Received: from ietf.ietf.org by ietf.org id aa17047; 27 Mar 97 9:54 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3423) I-D ACTION:draft-ietf-ipngwg-ipv6-arch-00.txt Date: Thu, 27 Mar 1997 09:54:21 -0500 Message-ID: <9703270954.aa17047@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3720 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-ipv6-arch-00.txt Pages : 20 Date : 03/26/1997 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 nodes required addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-arch-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-arch-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-arch-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970326104451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-arch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970326104451.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 10:31:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02271; Thu, 27 Mar 1997 10:15:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02264; Thu, 27 Mar 1997 10:14:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA26825; Thu, 27 Mar 1997 10:15:44 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA03220 for ; Thu, 27 Mar 1997 10:19:39 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA21387; Thu, 27 Mar 1997 10:15:19 -0800 Message-Id: <3.0.1.32.19970327101333.00b51a48@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 27 Mar 1997 10:13:33 -0800 To: ipng@INTEGRALIS.CO.UK From: Bob Hinden Subject: (IPng 3424) Re: IPng Interim Meeting Minutes Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3339CA46.5F50@integralis.com> References: <01IGYTQPE7QM00167U@INTEGD.INTEGRALIS.CO.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 901 Justin, >I've been background to this mailing list and have come across two >terms, ESD and 8+8 that, I cannot find any reference to in the >IPng-related RFCs. > >Please could someone tell me what both 8+8 and ESD are about (ESD is >InterfaceID/MAC address related right?). Is this cultivated jargon or >have I missed out on a valuable source somewhere? See: Title : GSE - An Alternate Addressing Architecture for IPv6 Author(s) : M. O'Dell Filename : draft-ietf-ipngwg-gseaddr-00.txt Pages : 20 Date : 02/24/1997 Then reread the interim meeting minutes. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 10:37:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02297; Thu, 27 Mar 1997 10:21:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02290; Thu, 27 Mar 1997 10:21:10 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA28559; Thu, 27 Mar 1997 10:22:05 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA06117 for ; Thu, 27 Mar 1997 10:25:57 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA21689; Thu, 27 Mar 1997 10:21:32 -0800 Message-Id: <3.0.1.32.19970327101827.00734028@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 27 Mar 1997 10:18:27 -0800 To: Pedro Marques From: Bob Hinden Subject: (IPng 3425) Re: Router renumbering Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199703262243.OAA13021@pedrom-ultra.cisco.com> References: <199703262141.PAA05968@gungnir.fnal.gov> <199703262141.PAA05968@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 599 Pedro, >the idea seams very usefull but why did you choose to implement this >as a protocol on top of icmp and not as an SNMP MIB ? The idea was to be able to easily change all of the routers in a site without having to perform operations (e.g., SNMP, manual configuration, etc.) on each router individually. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 10:56:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02342; Thu, 27 Mar 1997 10:41:16 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02335; Thu, 27 Mar 1997 10:40:57 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA04650; Thu, 27 Mar 1997 10:41:51 -0800 Received: from fontina.cisco.com (fontina.cisco.com [171.69.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA15347 for ; Thu, 27 Mar 1997 10:45:46 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by fontina.cisco.com (8.6.12/8.6.5) with ESMTP id KAA09656; Thu, 27 Mar 1997 10:41:49 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA14067; Thu, 27 Mar 1997 10:37:03 -0800 (PST) Date: Thu, 27 Mar 1997 10:37:03 -0800 (PST) Message-Id: <199703271837.KAA14067@pedrom-ultra.cisco.com> From: Pedro Marques To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3426) Re: Router renumbering In-Reply-To: <3.0.1.32.19970327101827.00734028@mailhost.ipsilon.com> References: <199703262141.PAA05968@gungnir.fnal.gov> <199703262243.OAA13021@pedrom-ultra.cisco.com> <3.0.1.32.19970327101827.00734028@mailhost.ipsilon.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2029 >>>>> "Bob" == Bob Hinden writes: Bob> Pedro, >> the idea seams very usefull but why did you choose to implement >> this as a protocol on top of icmp and not as an SNMP MIB ? Bob> The idea was to be able to easily change all of the routers Bob> in a site without having to perform operations (e.g., SNMP, Bob> manual configuration, etc.) on each router individually. Bob, I still think the problem is much more a management problem and should be solved using something that fits in the current management framework. The idea behind SNMP is that you do have reasonably capable management stations that are able to understand macro commands like the one we want to give here: "renumber all routers to this new prefix". Creating an additional protocol on top of ICMP is not really going to be an advantage in any way and will force us to implement additional mechanisms in our routers. I really think we should solve management problems to management methods. If the problem is the potential lack of capabilities of current management software creating small random protocols to solve particular configuration problems is not going to help at all... According to the IETFs management framework the "right(tm) way" to renumber the routers of a particular AS is to use SNMP to add a new prefix to every routers mib and phase out the old one. We need however a good mib to be able to do it. Your document also takes the approach of using MD5 authentication for the packets themselfs using a shared key... again we should solve the authentication problem using IPsec. Things like SNMP or IPsec are painful to deploy but that is a better option than repeating their functionality endlessly. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 11:35:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02469; Thu, 27 Mar 1997 11:24:03 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02462; Thu, 27 Mar 1997 11:23:52 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16130; Thu, 27 Mar 1997 11:24:46 -0800 Received: from work.smurf.noris.de (work.smurf.noris.de [193.141.54.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA05114 for ; Thu, 27 Mar 1997 11:28:42 -0800 Received: by work.smurf.noris.de id <2648-233> convert rfc822-to-quoted-printable; Thu, 27 Mar 1997 20:24:39 +0100 Subject: (IPng 3427) Re: Router renumbering To: roque@cisco.com (Pedro Marques) Date: Thu, 27 Mar 1997 20:24:32 +0100 (Funky) From: "Matthias Urlichs" Cc: smurf@noris.de, ipng@sunroof.eng.sun.com In-Reply-To: <199703271727.JAA13845@pedrom-ultra.cisco.com> from "Pedro Marques" at Mar 27, 97 09:27:38 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Message-Id: <333ac977.2648-233.a@work.smurf.noris.de> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1751 Hi, Pedro Marques wrote: > > Matthias> As an ISP, I could use the RR packet to send an > Matthias> automagic "use this prefix" message to my customer's > Matthias> routers. That'd simplify auto- and reconfiguration > Matthias> tremendously. > >Put it the other way... >Would you accept such packets from an upstream provider ? Assuming that there is no security problem at my provider's. Further assuming that, if I have more than one provider, the router's security checks prevent prefixes which were added by Key A from deletio= n by Key B, unless Key B is specified to be of higher priority of course. As usual, the question boils down to whether you want to have fully dyn= amic network renumbering or whether you want to do it manually. There's no w= ay one or the other choice will ever be right for everybody, IMHO, so it should be possible to do it if you want it. --=20 The cure for capitalism's failing would require that a government would have to rise above the interests of one class alone. -- Robert L. Heilbroner --=20 Matthias Urlichs \ noris network GmbH / Xlink-POP N=FCrnberg= =20 Schleiermacherstra=DFe 12 \ Linux+Internet / EMail: urlichs@nor= is.de 90491 N=FCrnberg (Germany) \ Consulting+Programming+Networking+etc= 'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 D= E Click here. = 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 11:42:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02492; Thu, 27 Mar 1997 11:30:10 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02485; Thu, 27 Mar 1997 11:29:57 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA17775; Thu, 27 Mar 1997 11:30:49 -0800 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA07927 for ; Thu, 27 Mar 1997 11:34:45 -0800 Received: from rtpdce03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA51706; Thu, 27 Mar 1997 14:30:05 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id OAA37414; Thu, 27 Mar 1997 14:30:07 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20274; Thu, 27 Mar 1997 14:29:34 -0500 Message-Id: <9703271929.AA20274@ludwigia.raleigh.ibm.com> To: Bob Hinden Cc: ipng@INTEGRALIS.CO.UK, ipng@sunroof.eng.sun.com Subject: (IPng 3428) Re: IPng Interim Meeting Minutes In-Reply-To: Your message of "Thu, 27 Mar 1997 10:13:33 PST." <3.0.1.32.19970327101333.00b51a48@mailhost.ipsilon.com> Date: Thu, 27 Mar 1997 14:29:34 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 801 > >I've been background to this mailing list and have come across two > >terms, ESD and 8+8 that, I cannot find any reference to in the > >IPng-related RFCs. > See: > Title : GSE - An Alternate Addressing Architecture for IPv6 > Author(s) : M. O'Dell And coming shortly to an Internet-Drafts directory near you: Title: IPng Analysis of the GSE Proposal draft-ietf-ipng-esd-analysis-00.txt For those who can't wait, grab: ftp://ftp.cs.duke.edu/pub/narten/analysis.out Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 11:57:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02587; Thu, 27 Mar 1997 11:46:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02577; Thu, 27 Mar 1997 11:45:51 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA21604; Thu, 27 Mar 1997 11:46:45 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA15050 for ; Thu, 27 Mar 1997 11:50:41 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcisl04684; Thu, 27 Mar 1997 14:46:32 -0500 (EST) Message-Id: To: Pedro Marques cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 3429) Re: Router renumbering In-reply-to: Your message of "Thu, 27 Mar 1997 10:37:03 PST." <199703271837.KAA14067@pedrom-ultra.cisco.com> Date: Thu, 27 Mar 1997 14:46:31 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 709 it is a fundamental mistake to consider dynamic topology control a "management" issue in the SNMP sense. this is actually something that should be fully self-organizing - something that will never happen if the machinery is "out of band" like SNMP. the current proposal doesn't provide everything required into the future, but it does start down the right road rather than falling into the out-of-band management trap. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 14:34:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA03335; Thu, 27 Mar 1997 14:23:11 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA03328; Thu, 27 Mar 1997 14:23:01 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA25995; Thu, 27 Mar 1997 14:23:56 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA18896 for ; Thu, 27 Mar 1997 14:27:53 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA03361; Thu, 27 Mar 1997 14:23:24 -0800 Message-Id: <3.0.1.32.19970327142138.00b55c8c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 27 Mar 1997 14:21:38 -0800 To: Pedro Marques From: Bob Hinden Subject: (IPng 3430) Re: Router renumbering Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199703271837.KAA14067@pedrom-ultra.cisco.com> References: <3.0.1.32.19970327101827.00734028@mailhost.ipsilon.com> <199703262141.PAA05968@gungnir.fnal.gov> <199703262243.OAA13021@pedrom-ultra.cisco.com> <3.0.1.32.19970327101827.00734028@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1670 Pedro, >I still think the problem is much more a management problem and should be >solved using something that fits in the current management framework. > >The idea behind SNMP is that you do have reasonably capable management >stations that are able to understand macro commands like the one we >want to give here: "renumber all routers to this new prefix". I disagree (of course). There are many cases already where information is installed in routers by means other than SNMP. One example is routing tables. One could imagine a world where we did not have dynamic routing protocols (e.g., OSPF, RIP, BGP, etc.) and installed the routing tables with SNMP. This would not work as well as having routing protocols for many reasons including lack of real time response to changes, wouldn't deal well with router isolations, router rebooting, etc. I think router renumbering (e.g., prefix management) is similar in function to what routing protocols do in networks. It is a case were we want to make a change and want it to be applied to all routers at about the same time (in real time). We want it to be robust and deal with routers coming up and down, routers being isolated, etc. This, in my opinion, moves it out of the realm of SNMP. Bob p.s. This draft is the outcome of a presentation which Geert Jan De Groot and I gave at the last IPng session at the San Jose IETF. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 15:09:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05765; Thu, 27 Mar 1997 14:51:39 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05756; Thu, 27 Mar 1997 14:51:28 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02990; Thu, 27 Mar 1997 14:52:22 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA00466 for ; Thu, 27 Mar 1997 14:56:18 -0800 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA04163; Fri, 28 Mar 1997 09:52:14 +1100 (from kre@munnari.OZ.AU) To: Pedro Marques Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3431) Re: Router renumbering In-Reply-To: Your message of "Thu, 27 Mar 1997 10:37:03 -0800." <199703271837.KAA14067@pedrom-ultra.cisco.com> Date: Fri, 28 Mar 1997 09:52:13 +1100 Message-Id: <28360.859503133@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2020 Date: Thu, 27 Mar 1997 10:37:03 -0800 (PST) From: Pedro Marques Message-ID: <199703271837.KAA14067@pedrom-ultra.cisco.com> I still think the problem is much more a management problem and should be solved using something that fits in the current management framework. I agree with Mike - this is only seen as a management problem because that's how it has traditionally been done (with IPv4 there was little choice). It has to get out of management, and become just a day to day operational issue, like routing. If you like managing the router via SNMP, why are the routing tables not built that way? They could be. There will certainly still be manageable issues related to address assignments - like whether the router should be advertising addresses as autoconfigureable, or must use dhcp, various timer values, etc, and what values should be used in the internal site routing field (the bit between the RG and ESD), etc. but if we can automate address alterations in a way that there is nothing in the site management that has to approve, or distribute, or ... the things, then we certainly should. Note, this doesn't say that a site can't decide to do this stuff manually if it chooses, just that it should not have to be involved. Right now end system users who dial into a net (POTS, ISDN, whatever) and use PPP can have an address allocated to them for their link - but no more than that, let's get to the state where when you dial in your entire network can automatically get a number that works, without any intervention at all. And of course with the same procedures available to those on fixed connections (no more extra priveleges for dial in users...) kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 21:28:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA20029; Thu, 27 Mar 1997 21:19:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA20022; Thu, 27 Mar 1997 21:19:13 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA07608; Thu, 27 Mar 1997 21:20:08 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA06281 for ; Thu, 27 Mar 1997 21:24:09 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id AAA20976; Fri, 28 Mar 1997 00:10:17 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16115; Fri, 28 Mar 1997 00:10:15 -0500 Message-Id: <9703280510.AA16115@wasted.zk3.dec.com> To: Pedro Marques Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 3432) Re: Router renumbering In-Reply-To: Your message of "Thu, 27 Mar 97 10:37:03 PST." <199703271837.KAA14067@pedrom-ultra.cisco.com> Date: Fri, 28 Mar 97 00:10:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1263 Pedro, I really think RR is a good idea. I don't think it would take more than a day or two to implement and testing it in the routers and hosts could happen quickly. Also the entire abstraction is contained in one protocol and very simple to add the prefix to an interface list on an implementation. Using SNMP will require more software, more spec analysis, and it is not contained in a single abstraction strictly from a computer science perspective. What Matt and Bob have done is solve a problem using our existing mechanisms for IPv6 by essentially adding another level of indirection. Also I think most are already listening to the ICMP RAs for autoconfiguration which will drive dyn upds to DNS or use of DHCPv6 and renumbering. Having the RRs as an ICMP msg I think is very elegant. SNMP should not be the dumping ground to solve interface attribute changes anymore than DNS be the dumping ground for database needs. ICMP is a tool for us just like SNMP. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Thu Mar 27 23:19:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA20055; Thu, 27 Mar 1997 23:07:51 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA20048; Thu, 27 Mar 1997 23:07:36 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA18701; Thu, 27 Mar 1997 23:08:30 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id XAA25599 for ; Thu, 27 Mar 1997 23:12:33 -0800 Received: by mail.noris.net id <35283-5620>; Fri, 28 Mar 1997 08:08:20 +0100 Path: noris.net!not-for-mail From: smurf@work.smurf.noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3433) Re: Router renumbering Date: 28 Mar 1997 08:08:02 +0100 Organization: noris network GmbH, Nuernberg, FRG Lines: 14 Message-ID: <5hfqoi$jub$1@work.smurf.noris.de> References: <199703271837.KAA14067@pedrom-ultra.cisco.com> <9703280510.AA16115@wasted.zk3.dec.com> <859528105.4665@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1677 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 754 bound@zk3.dec.com writes: > > perspective. What Matt and Bob have done is solve a problem using our > existing mechanisms for IPv6 by essentially adding another level of > indirection. > Is there any problem that can _not_ be solved by adding another level of indirection? ;-) -- People who believe, "If you can't say anything nice, don't say anything at all," will refuse to talk to you. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 05:33:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA20297; Fri, 28 Mar 1997 05:21:32 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA20290; Fri, 28 Mar 1997 05:21:22 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA15578; Fri, 28 Mar 1997 05:22:16 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23288 for ; Fri, 28 Mar 1997 05:26:23 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA25419; Fri, 28 Mar 1997 08:19:33 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00802; Fri, 28 Mar 1997 08:19:32 -0500 Message-Id: <9703281319.AA00802@wasted.zk3.dec.com> To: smurf@work.smurf.noris.de (Matthias Urlichs) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3434) Re: Router renumbering In-Reply-To: Your message of "28 Mar 97 08:08:02 +0100." <5hfqoi$jub$1@work.smurf.noris.de> Date: Fri, 28 Mar 97 08:19:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 678 Matthias, >> perspective. What Matt and Bob have done is solve a problem using our >> existing mechanisms for IPv6 by essentially adding another level of >> indirection. >Is there any problem that can _not_ be solved by adding another level of >indirection? ;-) I think real QOS, real Virtual Memory/Process Migration on a LAN, and real Artificial Intelligence (not expert system). /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 07:42:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA20395; Fri, 28 Mar 1997 07:31:37 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA20388; Fri, 28 Mar 1997 07:31:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA10148; Fri, 28 Mar 1997 07:32:08 -0800 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA29319 for ; Fri, 28 Mar 1997 07:36:15 -0800 Received: from gungnir.fnal.gov ("port 33050"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IH14TVLNYO0001HX@FNAL.FNAL.GOV>; Fri, 28 Mar 1997 09:32:06 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA09564; Fri, 28 Mar 1997 09:31:57 -0600 Date: Fri, 28 Mar 1997 09:31:57 -0600 From: Matt Crawford Subject: (IPng 3435) Re: Router renumbering In-reply-to: "27 Mar 1997 09:27:38 PST." <"199703271727.JAA13845"@pedrom-ultra.cisco.com> To: Pedro Marques Cc: smurf@noris.de (Matthias Urlichs), ipng@sunroof.eng.sun.com Message-id: <199703281531.JAA09564@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Put it the other way... > Would you accept such packets from an upstream provider ? If I configure an authentication key in my routers which is known to my upstream ISP, I think I have answered this question "yes." Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 10:09:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20642; Fri, 28 Mar 1997 09:53:52 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20635; Fri, 28 Mar 1997 09:53:47 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA21695; Fri, 28 Mar 1997 09:54:42 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28966; Fri, 28 Mar 1997 09:54:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA20547; Fri, 28 Mar 1997 08:38:48 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23395; Fri, 28 Mar 1997 08:39:43 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA24638 for ; Fri, 28 Mar 1997 08:43:50 -0800 Received: from ietf.ietf.org by ietf.org id aa13196; 28 Mar 97 10:03 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3438) I-D ACTION:draft-ietf-ipngwg-router-renum-00.txt Date: Fri, 28 Mar 1997 10:02:44 -0500 Message-ID: <9703281003.aa13196@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4169 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Router Renumbering for IPv6 Author(s) : M. Crawford, R. Hinden Filename : draft-ietf-ipngwg-router-renum-00.txt Pages : 13 Date : 03/27/1997 IPv6 Neighbor Discovery [ND] and Address Autoconfiguration [AA] conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-router-renum-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-router-renum-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970327160809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970327160809.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 10:12:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20704; Fri, 28 Mar 1997 09:58:16 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20697; Fri, 28 Mar 1997 09:58:10 -0800 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA22298; Fri, 28 Mar 1997 09:59:06 -0800 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28993; Fri, 28 Mar 1997 09:58:25 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20584; Fri, 28 Mar 1997 09:14:19 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA01191; Fri, 28 Mar 1997 09:15:11 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA08019 for ; Fri, 28 Mar 1997 09:19:18 -0800 Received: from ietf.ietf.org by ietf.org id aa14096; 28 Mar 97 10:05 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org@jurassic@jurassic cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3439) I-D ACTION:draft-ietf-ipngwg-router-renum-00.txt Date: Fri, 28 Mar 1997 10:05:39 -0500 Message-ID: <9703281005.aa14096@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4169 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Router Renumbering for IPv6 Author(s) : M. Crawford, R. Hinden Filename : draft-ietf-ipngwg-router-renum-00.txt Pages : 13 Date : 03/27/1997 IPv6 Neighbor Discovery [ND] and Address Autoconfiguration [AA] conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-router-renum-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-router-renum-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970327160809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970327160809.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 10:35:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20838; Fri, 28 Mar 1997 10:20:14 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20831; Fri, 28 Mar 1997 10:19:58 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA17266; Fri, 28 Mar 1997 10:20:51 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA05072 for ; Fri, 28 Mar 1997 10:24:59 -0800 Received: from ietf.ietf.org by ietf.org id aa14989; 28 Mar 97 10:10 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3440) I-D ACTION:draft-ietf-ipngwg-esd-analysis-00.txt Date: Fri, 28 Mar 1997 10:10:04 -0500 Message-ID: <9703281010.aa14989@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5572 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPng Analysis of the GSE Proposal Author(s) : M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang Filename : draft-ietf-ipngwg-esd-analysis-00.txt Pages : 53 Date : 03/27/1997 On February 27-28 1997, the IPng Working Group held an interim meeting in Palo Alto, California to consider adopting Mike O'Dell's ``GSE - An Alternate Addressing Architecture for IPv6'' proposal [GSE]. In GSE, 16-byte IPv6 addresses are split into three portions: a globally unique End System Designator (ESD), a Site Topology Partition (STP) and a Routing Goop (RG) portion. The STP corresponds (roughly) to a site's subnet portion of an IPv4 address, whereas the RG identifies the attachment point to the public Internet. Routers use the RG+STP portions of addresses to route packets to the link to which the destination is directly attached; the ESD is used to deliver the packet across the last hop link. An important idea in GSE is that nodes within a Site would not need to know the RG portion of their addresses. Border routers residing between a Site and its Internet connect point would dynamically replace the RG part of source addresses of all outgoing IP datagrams, and the RG part of destination addresses on incoming traffic. This document provides a detailed analysis of the GSE plan. Much of the analysis presented here is an expansion of official meeting minutes, though it also includes issues uncovered by the authors in the process of fully fleshing out the analysis. In summary, the consensus of the attendees of the PAL1 meeting was that having routers rewrite the Routing Goop portion of addresses should not be adopted, though other parts of the GSE plan should (e.g., having globally unique ESDs). After completing the first draft of this document, the authors still strongly concur with this outcome. As a first draft, this document should not be considered to represent the views of the IPng Working Group. Instead, it should be viewed as the rough consensus of the PAL1 attendees and the strong consensus of the five authors. It is hoped that this first draft of the document will be the catalyst for discussions to refine the written analysis, and especially the conclusions, so that after some number of iterations it will represent the consensus of the working group. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-esd-analysis-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-esd-analysis-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970327152453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-esd-analysis-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970327152453.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 11:47:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21020; Fri, 28 Mar 1997 11:34:26 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21013; Fri, 28 Mar 1997 11:34:16 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA06926; Fri, 28 Mar 1997 11:35:10 -0800 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA04172 for ; Fri, 28 Mar 1997 11:39:21 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id LAA02559; Fri, 28 Mar 1997 11:34:40 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA14988; Fri, 28 Mar 1997 11:29:34 -0800 (PST) Date: Fri, 28 Mar 1997 11:29:34 -0800 (PST) Message-Id: <199703281929.LAA14988@pedrom-ultra.cisco.com> From: Pedro Marques To: "Mike O'Dell" Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 3441) Re: Router renumbering In-Reply-To: References: <199703271837.KAA14067@pedrom-ultra.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1181 >>>>> "Mike" == Mike O'Dell writes: Mike> it is a fundamental mistake to consider dynamic topology Mike> control a "management" issue in the SNMP sense. this is Mike> actually something that should be fully self-organizing - Mike> something that will never happen if the machinery is "out of Mike> band" like SNMP. the current proposal doesn't provide Mike> everything required into the future, but it does start down Mike> the right road rather than falling into the out-of-band Mike> management trap. And how is the BGP neighbour configuration going to be modified when you renumber the routers of a domain ? You have to change both the configuration of internal peers which fall under the same autority and request those you peer with you to change their configuration also. Should we go for an in-band or an out-of-band mechanism here ? ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 13:13:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21209; Fri, 28 Mar 1997 13:01:19 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21202; Fri, 28 Mar 1997 13:01:08 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA24335; Fri, 28 Mar 1997 13:02:01 -0800 Received: from mailhost1.BayNetworks.COM (ext-ns3.baynetworks.com [134.177.3.16]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA03713 for ; Fri, 28 Mar 1997 13:06:13 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id MAA17810 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns1.BayNetworks.COM (8.8.5/BNET-97/03/12-I) with SMTP id MAA08757 Posted-Date: Fri, 28 Mar 1997 12:58:30 -0800 (PST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA19860; Fri, 28 Mar 97 15:58:24 EST Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA22450; Fri, 28 Mar 1997 15:58:19 -0500 Message-Id: <3.0.32.19970328155812.006b1ac0@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 15:58:12 -0500 To: Pedro Marques , "Mike O'Dell" From: Dimitry Haskin Subject: (IPng 3442) Re: Router renumbering Cc: Bob Hinden , ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1927 Pedro, IPv6 BGP should use link-local addresses for connections between bgp peers in different domains and site-local addresses can be used for intra-domain connection. It is possible that some bgp route filters would need to be modified at a domain border but this would be a much smaller effort than re-configuring all site routers. I don't think that bgp is a show-stopper. Dimitry At 11:29 AM 3/28/97 -0800, Pedro Marques wrote: >>>>>> "Mike" == Mike O'Dell writes: > > Mike> it is a fundamental mistake to consider dynamic topology > Mike> control a "management" issue in the SNMP sense. this is > Mike> actually something that should be fully self-organizing - > Mike> something that will never happen if the machinery is "out of > Mike> band" like SNMP. the current proposal doesn't provide > Mike> everything required into the future, but it does start down > Mike> the right road rather than falling into the out-of-band > Mike> management trap. > >And how is the BGP neighbour configuration going to be modified when you >renumber the routers of a domain ? >You have to change both the configuration of internal peers which fall >under the same autority and request those you peer with you to change >their configuration also. >Should we go for an in-band or an out-of-band mechanism here ? > >./Pedro. >--------------------------------------------------------------------------- --- >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 13:23:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21227; Fri, 28 Mar 1997 13:10:22 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21220; Fri, 28 Mar 1997 13:10:10 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA26074; Fri, 28 Mar 1997 13:11:03 -0800 Received: from rottweiler.cisco.com (rottweiler.cisco.com [171.69.1.237]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA06490 for ; Fri, 28 Mar 1997 13:15:15 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by rottweiler.cisco.com (8.6.12/8.6.5) with ESMTP id NAA26085; Fri, 28 Mar 1997 13:11:05 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA15062; Fri, 28 Mar 1997 13:05:58 -0800 (PST) Date: Fri, 28 Mar 1997 13:05:58 -0800 (PST) Message-Id: <199703282105.NAA15062@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3443) Re: Router renumbering In-Reply-To: <3.0.32.19970328155812.006b1ac0@pobox.engeast.baynetworks.com> References: <3.0.32.19970328155812.006b1ac0@pobox.engeast.baynetworks.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 801 >>>>> "Dimitry" == Dimitry Haskin writes: Dimitry> Pedro, IPv6 BGP should use link-local addresses for Dimitry> connections between bgp peers in different domains and Dimitry> site-local addresses can be used for intra-domain Dimitry> connection. Dimitry, i don't think you can do that. The reason is that you need to have global addresses as nexthops in the routes so that those addresses can be propagated in internal peering sessions which are usually multihop. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 13:58:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21333; Fri, 28 Mar 1997 13:40:52 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21318; Fri, 28 Mar 1997 13:40:34 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02315; Fri, 28 Mar 1997 13:41:28 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA16578 for ; Fri, 28 Mar 1997 13:45:39 -0800 Received: from ns3.BayNetworks.COM ([141.251.211.30]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id NAA28032 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with SMTP id WAA23720 Posted-Date: Fri, 28 Mar 1997 22:40:49 +0100 (MET) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA23776; Fri, 28 Mar 97 16:40:46 EST Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA26948; Fri, 28 Mar 1997 16:40:40 -0500 Message-Id: <3.0.32.19970328164021.00690a78@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 16:40:22 -0500 To: Pedro Marques , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 3444) Re: Router renumbering Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1200 At 01:05 PM 3/28/97 -0800, Pedro Marques wrote: >>>>>> "Dimitry" == Dimitry Haskin writes: > > Dimitry> Pedro, IPv6 BGP should use link-local addresses for > Dimitry> connections between bgp peers in different domains and > Dimitry> site-local addresses can be used for intra-domain > Dimitry> connection. > >Dimitry, i don't think you can do that. >The reason is that you need to have global addresses as nexthops in the routes >so that those addresses can be propagated in internal peering sessions which >are usually multihop. > >./Pedro. > Yes, bgp needs to advertise global scop addresses as nexthops but it does not mean that global addresses have to be used for peering. I assume that upon renumbering some routes will be dynamically re-advertised with different nexthops according to a new topology but bgp connections themselves don't have to be re-configured. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 13:58:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21336; Fri, 28 Mar 1997 13:40:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21326; Fri, 28 Mar 1997 13:40:40 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02334; Fri, 28 Mar 1997 13:41:35 -0800 Received: from metro.isi.edu (metro.isi.edu [38.245.76.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA16595 for ; Fri, 28 Mar 1997 13:45:45 -0800 Received: from metro.isi.edu by metro.isi.edu (5.65c/5.61+local-24) id ; Fri, 28 Mar 1997 16:41:29 -0500 Message-Id: <199703282141.AA23218@metro.isi.edu> To: Pedro Marques Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com Subject: (IPng 3445) Re: Router renumbering In-Reply-To: Your message of "Fri, 28 Mar 1997 13:05:58 PST." <199703282105.NAA15062@pedrom-ultra.cisco.com> X-Phone: +1 703 812 3704 From: "John W. Stewart III" Date: Fri, 28 Mar 1997 16:41:29 EST Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 908 > Dimitry> Pedro, IPv6 BGP should use link-local addresses for > Dimitry> connections between bgp peers in different domains and > Dimitry> site-local addresses can be used for intra-domain > Dimitry> connection. > > Dimitry, i don't think you can do that. > The reason is that you need to have global addresses as nexthops in the > routes > so that those addresses can be propagated in internal peering sessions which > are usually multihop. it makes sense to me to use site-local addresses as next-hops within a single backbone (i.e., within an I-BGP mesh). what about that doesn't work? /jws ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 14:25:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21371; Fri, 28 Mar 1997 14:06:59 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21362; Fri, 28 Mar 1997 14:06:36 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA07536; Fri, 28 Mar 1997 14:07:29 -0800 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA24910 for ; Fri, 28 Mar 1997 14:11:40 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by trix.cisco.com (8.6.12/8.6.5) with ESMTP id OAA21435; Fri, 28 Mar 1997 14:07:29 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA15170; Fri, 28 Mar 1997 14:02:21 -0800 (PST) Date: Fri, 28 Mar 1997 14:02:21 -0800 (PST) Message-Id: <199703282202.OAA15170@pedrom-ultra.cisco.com> From: Pedro Marques To: "John W. Stewart III" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3446) Re: Router renumbering In-Reply-To: <199703282141.AA23218@metro.isi.edu> References: <199703282105.NAA15062@pedrom-ultra.cisco.com> <199703282141.AA23218@metro.isi.edu> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1372 >>>>> "John" == John W Stewart writes: Dimitry> Pedro, IPv6 BGP should use link-local addresses for Dimitry> connections between bgp peers in different domains and Dimitry> site-local addresses can be used for intra-domain Dimitry> connection. >> Dimitry, i don't think you can do that. The reason is that >> you need to have global addresses as nexthops in the routes so >> that those addresses can be propagated in internal peering >> sessions which are usually multihop. John> it makes sense to me to use site-local addresses as John> next-hops within a single backbone (i.e., within an I-BGP John> mesh). what about that doesn't work? I wasn't refering to the site local part but to link local addresses. But answering your question, consider a Lan: A B C | | | ----+-------+-------+ Both A and B belong to the same AS, C belongs to a different AS. A peers with B and B peers with C. Nexthop announced from A to B cannot be site local, it must be a global address, so that B can propagate it to C. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 14:40:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21412; Fri, 28 Mar 1997 14:24:58 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21405; Fri, 28 Mar 1997 14:24:46 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA12901; Fri, 28 Mar 1997 14:25:41 -0800 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA01869 for ; Fri, 28 Mar 1997 14:29:52 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id OAA02537; Fri, 28 Mar 1997 14:25:41 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA15183; Fri, 28 Mar 1997 14:20:32 -0800 (PST) Date: Fri, 28 Mar 1997 14:20:32 -0800 (PST) Message-Id: <199703282220.OAA15183@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3447) Re: Router renumbering In-Reply-To: <3.0.32.19970328164021.00690a78@pobox.engeast.baynetworks.com> References: <3.0.32.19970328164021.00690a78@pobox.engeast.baynetworks.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1652 >>>>> "Dimitry" == Dimitry Haskin writes: Dimitry> At 01:05 PM 3/28/97 -0800, Pedro Marques wrote: >>>>>>> "Dimitry" == Dimitry Haskin >>>>>>> writes: >> Dimitry> Pedro, IPv6 BGP should use link-local addresses for Dimitry> connections between bgp peers in different domains and Dimitry> site-local addresses can be used for intra-domain Dimitry> connection. >> Dimitry, i don't think you can do that. The reason is that >> you need to have global addresses as nexthops in the Dimitry> routes >> so that those addresses can be propagated in internal peering >> sessions which are usually multihop. >> >> ./Pedro. >> Dimitry> Yes, bgp needs to advertise global scop addresses as Dimitry> nexthops but it does not mean that global addresses have Dimitry> to be used for peering. There is a requirement in BGP that: "A BGP speaker must never advertise an address of a peer to that peer as a next hop". You need a way to match nexthops with peers... The easiest way to do it is require that peer addresses and nexthop addresses be of the same address type. I wouldn't mind at all being wrong here... it would be nice to know if we can get away with link local address peering and if so forward the requirement to the IDR group. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 15:54:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA21614; Fri, 28 Mar 1997 15:37:45 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA21600; Fri, 28 Mar 1997 15:37:17 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA27705; Fri, 28 Mar 1997 15:38:06 -0800 Received: from rottweiler.cisco.com (rottweiler.cisco.com [171.69.1.237]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA10159 for ; Fri, 28 Mar 1997 15:42:19 -0800 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by rottweiler.cisco.com (8.6.12/8.6.5) with ESMTP id PAA00171; Fri, 28 Mar 1997 15:38:07 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA15261; Fri, 28 Mar 1997 15:32:58 -0800 (PST) Date: Fri, 28 Mar 1997 15:32:58 -0800 (PST) Message-Id: <199703282332.PAA15261@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3448) Re: Router renumbering In-Reply-To: <3.0.32.19970328164021.00690a78@pobox.engeast.baynetworks.com> References: <3.0.32.19970328164021.00690a78@pobox.engeast.baynetworks.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1654 >>>>> "Dimitry" == Dimitry Haskin writes: Dimitry> Yes, bgp needs to advertise global scop addresses as Dimitry> nexthops but it does not mean that global addresses have Dimitry> to be used for peering. I assume that upon renumbering Dimitry> some routes will be dynamically re-advertised with Dimitry> different nexthops according to a new topology but bgp Dimitry> connections themselves don't have to be re-configured. Dimitry, considering the issue a bit more, even with link local peering you still do require coordenation between peering AS because of the requirement that nexthops be global. Consider an example: AS 1 AS 2 A B +-------+ fe80::1 fe80::2 5f00:x::1 5f00:y::2 An arbitrary route X annonced from A to B must have as attributes nexthop = [5f00:x::1 fe80::1]. That implies that routers in AS 2 must know when 5f00:x lies. That knowledge cannot be injected via BGP since an announcement of the type route to 5f00:x via 5f00:x::1 is meaningless. That brings us to the conclusion that that knowledge must be external. Since 5f00:x is a prefix of either AS 1 or AS 2 whenever the AS renumber you do require coordination between the two ASes. Corollary: renumbering "large strutures" requires close to global coordination by the current routing protocol tecnology. qed. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Fri Mar 28 16:15:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA21847; Fri, 28 Mar 1997 16:01:59 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA21840; Fri, 28 Mar 1997 16:01:44 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA02412; Fri, 28 Mar 1997 16:02:40 -0800 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA17572 for ; Fri, 28 Mar 1997 16:06:52 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id PAA01629 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns1.BayNetworks.COM (8.8.5/BNET-97/03/12-I) with SMTP id QAA12128 Posted-Date: Fri, 28 Mar 1997 16:02:03 -0800 (PST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA04440; Fri, 28 Mar 97 19:02:05 EST Received: from greenfield.engeast.baynetworks.com (greenfield.corpeast.baynetworks.com [192.32.170.19]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA7760; Fri, 28 Mar 1997 19:01:58 -0500 Message-Id: <3.0.32.19970328190140.0069333c@pobox.engeast.baynetworks.com> X-Sender: dhaskin@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 28 Mar 1997 19:01:41 -0500 To: Pedro Marques , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 3449) Re: Router renumbering Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1420 At 02:20 PM 3/28/97 -0800, Pedro Marques wrote: >>>>>> "Dimitry" == Dimitry Haskin writes: > > >> > Dimitry> Yes, bgp needs to advertise global scop addresses as > Dimitry> nexthops but it does not mean that global addresses have > Dimitry> to be used for peering. > >There is a requirement in BGP that: >"A BGP speaker must never advertise an address of a peer to that peer as >a next hop". >You need a way to match nexthops with peers... > Pedro, I really don't see were the problem is. Consider border routers A and B in different domains sharing a border network with a global scop prefix N. Router A advertises a route R to B with a nexthope N:x. B in turn re-advertise R as is to another router C in its domain. If B needs to forward packets to R it uses ND to resolve N:x since B is directly attached to N. If C wants to forward packets to R, it does a lookup for network N in its IGP table and forwards according to its IGP route to N. This is pretty much how it works today. Note that there is no dependency on addresses used to establish tcp connections between bgp peers. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 05:14:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA23746; Mon, 31 Mar 1997 05:05:02 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA23739; Mon, 31 Mar 1997 05:04:51 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA17822; Mon, 31 Mar 1997 05:05:48 -0800 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id FAA29932 for ; Mon, 31 Mar 1997 05:10:35 -0800 Received: by mail.noris.net id <35200-8996>; Mon, 31 Mar 1997 15:05:39 +0200 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3450) Re: Router renumbering Date: 31 Mar 1997 15:05:07 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 14 Message-ID: <5hocq3$2k2$1@work.smurf.noris.de> References: <3.0.32.19970328164021.00690a78@pobox.engeast.baynetworks.com> <199703282332.PAA15261@pedrom-ultra.cisco.com> <859594488.21874@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1693 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 827 Pedro Marques writes: > > considering the issue a bit more, even with link local peering you > still do require coordenation between peering AS because of the requirement > that nexthops be global. > This may be a stupid question, but where is it ordained that nexthops be global? BGP4 only says "the IP address of...". -- First impressions are of major importance in business matters. -- J. Pierpont Finch -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 06:40:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23889; Mon, 31 Mar 1997 06:28:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23882; Mon, 31 Mar 1997 06:28:15 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA23160; Mon, 31 Mar 1997 06:29:11 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA14190 for ; Mon, 31 Mar 1997 06:34:00 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA14816; Mon, 31 Mar 1997 09:16:27 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23444; Mon, 31 Mar 1997 09:16:21 -0500 Message-Id: <9703311416.AA23444@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3451) Re: Router renumbering In-Reply-To: Your message of "Wed, 26 Mar 97 15:41:34 CST." <199703262141.PAA05968@gungnir.fnal.gov> Date: Mon, 31 Mar 97 09:16:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 651 Matt/Bob, Go with HMAC-MD5...Key-MD5 is deprecated I think in the community. See draft-ietf-dhc-v6exts-05.txt Security/Auth sections for a model that will work. How about an "INJECT" type where the prefix is injected by an upstream provider to a Border Router, while we are doing this...or it could go to an anycast router downstream in the site. Good job.... /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 06:47:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23898; Mon, 31 Mar 1997 06:32:53 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23891; Mon, 31 Mar 1997 06:32:42 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA23454; Mon, 31 Mar 1997 06:33:38 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA15211 for ; Mon, 31 Mar 1997 06:38:26 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA24313; Mon, 31 Mar 1997 09:24:28 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27423; Mon, 31 Mar 1997 09:24:26 -0500 Message-Id: <9703311424.AA27423@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3452) Re: Updated IPv6 Addressing Architecture draft In-Reply-To: Your message of "Tue, 25 Mar 97 16:47:20 PST." <3.0.1.32.19970325164720.006ba490@mailhost.ipsilon.com> Date: Mon, 31 Mar 97 09:24:25 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 461 Bob, Are you going to put in the multicast-assign changes? For example the DHCPv6 address in the draft has changed and is correct in your new multicast-assgn spec? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 06:47:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23907; Mon, 31 Mar 1997 06:33:17 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23900; Mon, 31 Mar 1997 06:33:02 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA23474; Mon, 31 Mar 1997 06:33:58 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA15295 for ; Mon, 31 Mar 1997 06:38:47 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA04487; Mon, 31 Mar 1997 09:17:55 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24616; Mon, 31 Mar 1997 09:17:52 -0500 Message-Id: <9703311417.AA24616@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3453) GSE Analysis Date: Mon, 31 Mar 97 09:17:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 336 Thomas, et al.... Good job excellent analysis. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 06:54:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23919; Mon, 31 Mar 1997 06:38:51 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23909; Mon, 31 Mar 1997 06:38:29 -0800 From: bound@zk3.dec.com Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA23858; Mon, 31 Mar 1997 06:39:24 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA16439 for ; Mon, 31 Mar 1997 06:44:13 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA16667; Mon, 31 Mar 1997 09:22:27 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26619; Mon, 31 Mar 1997 09:22:25 -0500 Message-Id: <9703311422.AA26619@wasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3454) Re: IPv6 "Who-Are-You?" In-Reply-To: Your message of "Wed, 26 Mar 97 18:26:10 CST." <199703270026.SAA06525@gungnir.fnal.gov> Date: Mon, 31 Mar 97 09:22:25 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 794 Matt, Do we want a time field as just another level of replay protection? Also I think we need to nail down how these are stored. I do like the format you suggest for future reverse lookups but it will be a significant change to the bind code as text strings are parsed right-to-left for semantic reasons. I think changing this for addresses is wise but just want to note the implementation effect if we store these suckers, which I think we have to or thrashing will result and be very rude. Good job /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 08:27:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA24121; Mon, 31 Mar 1997 08:18:24 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA24114; Mon, 31 Mar 1997 08:18:06 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA06227; Mon, 31 Mar 1997 08:19:03 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA14480 for ; Mon, 31 Mar 1997 08:23:52 -0800 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA28242; Mon, 31 Mar 1997 08:16:30 -0800 Message-Id: <3.0.1.32.19970331081428.00b860ac@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 31 Mar 1997 08:14:28 -0800 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 3455) Re: Updated IPv6 Addressing Architecture draft Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <9703311424.AA27423@wasted.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 562 Jim, >Are you going to put in the multicast-assign changes? For example the >DHCPv6 address in the draft has changed and is correct in your new >multicast-assgn spec? Good point. I will either put them all in the addressing arch spec, or move them to separate document. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 16:10:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA24948; Mon, 31 Mar 1997 16:01:30 -0800 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA24941; Mon, 31 Mar 1997 16:01:20 -0800 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA26950; Mon, 31 Mar 1997 16:02:20 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA19375; Mon, 31 Mar 1997 16:02:19 -0800 Date: Mon, 31 Mar 1997 16:02:19 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199704010002.QAA19375@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3456) Comments on draft-ietf-ipngwg-esd-analysis-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1197 The document says: 4) Make a clear distinction between the ``locator'' part of an address and the ``identifier'' part of the address. The former is used to route a packet to its end point, the latter is used to identify an end point, independent of the path used to deliver the packet. Although this is a potentially revolutionary change to IPv6 addressing model, existing transport protocols such as TCP and UDP will not take advantage of the split. Future transport protocols (e.g., TCPng), however, may. I think that the benefit of globally unique ESDs will be very low unless TCP and UDP can take advantage of the ESDs from the start. I was looking through the draft for a clear and concise line of argument the back up the above recommendation but I didn't find much. What exactly are the concerns that lead to the above recommendation? Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 17:25:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA25079; Mon, 31 Mar 1997 17:16:19 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA25072; Mon, 31 Mar 1997 17:16:09 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA14437; Mon, 31 Mar 1997 17:17:01 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA17102 for ; Mon, 31 Mar 1997 17:21:53 -0800 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA22454; Tue, 1 Apr 1997 02:16:57 +0100 Date: Tue, 1 Apr 1997 02:16:57 +0100 Message-Id: <9704010116.AA22454@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3457) Re: Comments on draft-ietf-ipngwg-esd-analysis-00.txt To: ipng@sunroof.eng.sun.com In-Reply-To: <199704010002.QAA19375@bobo.eng.sun.com> from "Erik Nordmark" at Mar 31, 97 04:02:19 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1934 Well, first, I second Jim's praise of the draft; it's great, especially for people who weren't there. But I do have the same question as Erik (and it applies to IPSEC as well). This is such a key point in the locator/ identifier debate that the conclusion neds to be justified. It's not as if we have an enormous deployed base of TCP/IPv6 to worry about . Brian Carpenter >- Erik Nordmark said: > > > The document says: > 4) Make a clear distinction between the ``locator'' part of an > address and the ``identifier'' part of the address. The former > is used to route a packet to its end point, the latter is used > to identify an end point, independent of the path used to > deliver the packet. Although this is a potentially revolutionary > change to IPv6 addressing model, existing transport protocols > such as TCP and UDP will not take advantage of the split. Future > transport protocols (e.g., TCPng), however, may. > > I think that the benefit of globally unique ESDs will be very low unless > TCP and UDP can take advantage of the ESDs from the start. > > I was looking through the draft for a clear and concise line of argument > the back up the above recommendation but I didn't find much. > What exactly are the concerns that lead to the above recommendation? > > Erik > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng@sunroof.eng.sun.com Mon Mar 31 18:15:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA25199; Mon, 31 Mar 1997 18:06:08 -0800 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA25192; Mon, 31 Mar 1997 18:05:59 -0800 Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA21799; Mon, 31 Mar 1997 18:06:56 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA29710 for ; Mon, 31 Mar 1997 18:11:52 -0800 Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id VAA30756; Mon, 31 Mar 1997 21:04:00 -0500 (EST) Received: from tunsrv2-tunnel.imc.das.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA20003; Mon, 31 Mar 1997 21:03:54 -0500 Message-Id: <3.0.1.32.19970331210317.00763d60@alphy.lkg.dec.com> X-Sender: popmatt@alphy.lkg.dec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 31 Mar 1997 21:03:17 -0500 To: ipng@sunroof.eng.sun.com From: Matt Thomas Subject: (IPng 3458) draft-thomas-ipv6-esd-00.txt In-Reply-To: <199704010002.QAA19375@bobo.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1726 [this wasn't cc:ed to the list so ...] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Use of End System Designators in IPv6 Author(s) : M. Thomas Filename : draft-thomas-ipv6-esd-00.txt Pages : 6 Date : 03/27/1997 There is a proposal to split unicast IPv6 addresses into two 8 byte quantities. The first 8 bytes will contain routing information which is used to reach a subnetwork. The last 8 bytes will contain a identifier of a node on that subnet. This identifier is globally unique and is called an End System Designator (ESD). The ESD (not the entire 16 byte address) will be used to accept packets and identify connections, among other things. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-thomas-ipv6-esd-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-thomas-ipv6-esd-00.txt -- Matt Thomas Internet: matt@lkg.dec.com UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com